rfc1969.txt

RFC 的详细文档！

Network Working Group                                         K. Sklower
Request for Comments: 1969            University of California, Berkeley
Category: Informational                                         G. Meyer
                                                          Spider Systems
                                                               June 1996


                 The PPP DES Encryption Protocol (DESE)

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   The PPP Encryption Control Protocol (ECP) [2] provides a method to
   negotiate and utilize encryption protocols over PPP encapsulated
   links.

   This document provides specific details for the use of the DES
   standard [5, 6] for encrypting PPP encapsulated packets.

Acknowledgements

   The authors extend hearty thanks to Fred Baker of Cisco for helpful
   improvements to the clarity of the document.

Table of Contents

   1. Introduction ................................................    2
   1.1. Motivation ................................................    2
   1.2. Conventions ...............................................    2
   2. General Overview ............................................    2
   3. Structure of This Specification .............................    3
   4. DESE Configuration Option for ECP ...........................    4
   5. Packet Format for DESE ......................................    5
   6. Encryption ..................................................    6
   6.1. Padding Considerations ....................................    6
   6.2. Generation of the Ciphertext ..............................    7
   6.3. Retrieval of the Plaintext ................................    8
   6.4. Recovery after Packet Loss ................................    8
   7. MRU Considerations ..........................................    8
   8. Security Considerations .....................................    9



Sklower & Meyer              Informational                      [Page 1]

RFC 1969                  PPP DES Encryption                   June 1996


   9. References ..................................................    9
   10. Authors' Addresses .........................................   10
   11. Expiration Date of this Draft ..............................   10

1.  Introduction

1.1.  Motivation

   The purpose of this memo is two-fold: to show how one specifies the
   necessary details of a "data" or "bearer" protocol given the context
   of the generic PPP Encryption Control Protocol, and also to provide
   at least one commonly-understood means of secure data transmission
   between PPP implementations.

   The DES encryption algorithm is a well studied, understood and widely
   implemented encryption algorithm.  The DES cipher was designed for
   efficient implementation in hardware, and consequently may be
   relatively expensive to implement in software.  However, its
   pervasiveness makes it seem like a reasonable choice for a "model"
   encryption protocol.

   Source code implementing DES in the "Electronic Code Book Mode" can
   be found in [7].  US export laws forbid the inclusion of
   compilation-ready source code in this document.

1.2.  Conventions

   The following language conventions are used in the items of
   specification in this document:

   o    MUST, SHALL or MANDATORY -- the item is an absolute requirement
        of the specification.

   o    SHOULD or RECOMMENDED -- the item should generally be followed
        for all but exceptional circumstances.

   o    MAY or OPTIONAL -- the item is truly optional and may be
        followed or ignored according to the needs of the implementor.

2.  General Overview

   The purpose of encrypting packets exchanged between two PPP
   implementations is to attempt to insure the privacy of communication
   conducted via the two implementations.  The encryption process
   depends on the specification of an encryption algorithm and a shared
   secret (usually involving at least a key) between the sender and
   receiver.




Sklower & Meyer              Informational                      [Page 2]

RFC 1969                  PPP DES Encryption                   June 1996


   Generally, the encryptor will take a PPP packet including the
   protocol field, apply the chosen encryption algorithm, place the
   resulting cipher text (and in this specification, an explicit
   sequence number) in the information field of another PPP packet.  The
   decryptor will apply the inverse algorithm and interpret the
   resulting plain text as if it were a PPP packet which had arrived
   directly on the interface.

   The means by which the secret becomes known to both communicating
   elements is beyond the scope of this document; usually some form of
   manual configuration is involved.  Implementations might make use of
   PPP authentication, or the EndPoint Identifier Option described in
   PPP Multilink [3], as factors in selecting the shared secret.  If the
   secret can be deduced by analysis of the communication between the
   two parties, then no privacy is guaranteed.

   While the US Data Encryption Standard (DES) algorithm [5, 6] provides
   multiple modes of use, this specification selects the use of only one
   mode in conjunction with the PPP Encryption Control Protol (ECP): the
   Cipher Block Chaining (CBC) mode.  In addition to the US Government
   publications cited above, the CBC mode is also discussed in [7],
   although no C source code is provided for it per se.

   The initialization vector for this mode is deduced from an explicit
   64-bit nonce, which is exchanged in the clear during the negotiation
   phase.  The 56-bit key required by all DES modes is established as a
   shared secret between the implementations.

   One reason for choosing the chaining mode is that it is generally
   thought to require more computation resources to deduce a 64 bit key
   used for DES encryption by analysis of the encrypted communication
   stream when chaining mode is used, compared with the situation where
   each block is encrypted separately with no chaining.  Further, if
   chaining is not used, even if the key is never deduced, the
   communication may be subject to replay attacks.

   However, if chaining is to extend beyond packet boundaries, both the
   sender and receiver must agree on the order the packets were
   encrypted.  Thus, this specification provides for an explicit 16 bit
   sequence number to sequence decryption of the packets.  This mode of
   operation even allows recovery from occasional packet loss; details
   are also given below.

3.  Structure of This Specification

   The PPP Encryption Control Protocol (ECP), provides a framework for
   negotiating parameters associated with encryption, such as choosing
   the algorithm.  It specifies the assigned numbers to be used as PPP



Sklower & Meyer              Informational                      [Page 3]

RFC 1969                  PPP DES Encryption                   June 1996


   protocol numbers for the "data packets" to be carried as the
   associated "data protocol", and describes the state machine.

   Thus, a specification for use in that matrix need only describe any
   additional configuration options required to specify a particular
   algorithm, and the process by which one encrypts/decrypts the
   information once the Opened state has been achieved.

4.  DESE Configuration Option for ECP

   Description

        The ECP DESE Configuration Option indicates that the issuing
        implementation is offering to employ this specification for
        decrypting communications on the link, and may be thought of as
        a request for its peer to encrypt packets in this manner.

        The ECP DESE Configuration Option has the following fields,
        which are transmitted from left to right:


                    Figure 1:  ECP DESE Configuration Option


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |         Initial Nonce ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type

             1, to indicate the DESE protocol.


        Length

             10


        Initial Nonce

             This field is an 8 byte quantity which is used by the peer
             implementation to encrypt the first packet transmitted
             after the sender reaches the opened state.

             To guard against replay attacks, the implementation SHOULD
             offer a different value during each ECP negotiation.  An



Sklower & Meyer              Informational                      [Page 4]

RFC 1969                  PPP DES Encryption                   June 1996


             example might be to use the number of seconds since Jan
             1st, 1970 (GMT/UT) in the upper 32 bits, and the current
             number of nanoseconds relative to the last second mark in
             the lower 32 bits.

             Its formulaic role is described in the Encryption section
             below.

5.  Packet Format for DESE

   Description

        The DESE packets themselves have the following fields:


                Figure 2:  DES Encryption Protocol Packet Format


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Address    |    Control    |     0000      |  Protocol ID  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Seq. No. High | Seq. No. Low  |        Ciphertext ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Address and Control

             These fields MUST be present unless the PPP Address and
             Control Field Compression option (ACFC) has been
             negotiated.

        Protocol ID

             The value of this field is 0x53 or 0x55; the latter
             indicates that ciphertext includes headers for the
             Multilink Protocol, and REQUIRES that the Individual Link
             Encryption Control Protocol has reached the opened state.
             The leading zero MAY be absent if the PPP Protocol Field
             Compression option (PFC) has been negotiated.

        Sequence Number

             These 16-bit numbers are assigned by the encryptor
             sequentially starting with 0 (for the first packet
             transmitted once ECP has reached the opened state.




Sklower & Meyer              Informational                      [Page 5]