rfc1969.txt

RFC 的详细文档！


RFC 1969                  PPP DES Encryption                   June 1996


        Ciphertext

             The generation of this data is described in the next
             section.

6.  Encryption

   Once the ECP has reached the Opened state, the sender MUST NOT apply
   the encryption procedure to LCP packets nor ECP packets.

   If the async control character map option has been negotiated on the
   link, the sender applies mapping after the encryption algorithm has
   been run.

   The encryption algorithm is generally to pad the Protocol and
   Information fields of a PPP packet to some multiple of 8 bytes, and
   apply DES in Chaining Block Cipher mode with a 56-bit key K.

   There are a lot of details concerning what constitutes the Protocol
   and Information fields, in the presence or non-presence of Multilink,
   and whether the ACFC and PFC options have been negotiated, and the
   sort of padding chosen.

   Regardless of whether ACFC has been negotiated on the link, the
   sender applies the encryption procedure to only that portion of the
   packet excluding the address and control field.

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to each link separately, then the
   encryption procedure is to be applied to the (possibly extended)
   protocol and information fields of the packet in the Multilink
   Protocol.

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to the bundle, then the multilink
   procedure is to be applied to the resulting DESE packets.

6.1.  Padding Considerations

   Since the DES algorithm operates on blocks of 8 octets, packets which
   are of length not a multiple of 8 octets must be padded.  This can be
   injurious to the interpretation of some protocols which do not
   contain an explicit length field in their protocol headers.
   (Additional padding of the ciphered packet for the purposes of
   transmission by HDLC hardware which requires an even number of bytes
   should not be necessary since the information field will now be of
   length a multiple of 8, and whether or not the packet is of even
   length can be forced by use or absence of a leading zero in the



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


   protocol field).

   For protocols which do have an explicit length field, such as IP,
   IPX, XNS, and CLNP, then padding may be accomplished by adding random
   trailing garbage.  Even when performing the Multilink protocol, if it
   is only being applied to packets with explicit length fields, and if
   care is taken so that all non-terminating fragments (i.e., those not
   bearing the (E)nd bit) are of lengths divisible by 8; then no ill
   effects will happen if garbage padding is applied only to terminating
   fragments.

   For certain cases, such as the PPP bridging protocol when the
   trailing CRC is forwarded or when any bridging is being applied to
   protocols not having explicit length fields, adding garbage changes
   the interpretation of the packet.  The self-describing padding option
   [4] permits unambiguous removal of padded bytes; although it should
   only be used when absolutely necessary as it may inadvertently
   require adding as many as 8 octets to packets that could otherwise be
   left unaltered.

      Consider a packet, which by unlucky circumstance is already a
      multiple of 8 octets, but terminates in the sequence 0x1, 0x2.
      Self-describing padding would otherwise remove the trailing two
      bytes.  For purposes of coexistence with archaic HDLC chips where
      it is necessary to transmit packets of even length, one would
      normally only have to add an additional two octets (0x1, 0x2),
      which could then be removed.  However, since the packet was
      initially a multiple of 8 bytes, an additional 8 bytes would need
      to be added.

6.2.  Generation of the Ciphertext

   In this discussion, E[k] will denote the basic DES cipher determined
   by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
   corresponding decryption mechanism.  The padded plaintext described
   in the previous section then becomes a sequence of 64 bit blocks P[i]
   (where i ranges from 1 to n).  The circumflex character (^)
   represents the bit-wise exclusive-or operation applied to 64-bit
   blocks.

   When encrypting the first packet to be transmitted in the opened
   state let C[0] be the result of applying E[k] to the Initial Nonce
   received in the peer's ECP DESE option; otherwise let C[0] be the
   final block of the previously transmitted packet.







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


   The ciphertext for the packet is generated by the iterative process

                        C[i] = E[k](P[i] ^ C[i-1])

   for i running between 1 and n.

6.3.  Retrieval of the Plaintext

   When decrypting the first packet received in the opened state, let
   C[0] be the result of applying E[k] to the Initial Nonce transmitted
   in the ECP DESE option.  The first packet will have sequence number
   zero.  For subsequent packets, let C[0] be the final block of the
   previous packet in sequence space.  Decryption is then accomplished
   by

                        P[i] = C[i-1] ^ D[k](C[i]),

   for i running between 1 and n.

6.4.  Recovery after Packet Loss

   Packet loss is detected when there is a discontinuity in the sequence
   numbers of consecutive packets.  Suppose packet number N - 1 has an
   unrecoverable error or is otherwise lost, but packets N and N + 1 are
   received correctly.

   Since the algorithm in the previous section requires C[0] for packet
   N to be C[last] for packet N - 1, it will be impossible to decode
   packet N.  However, all packets N + 1 and following can be decoded in
   the usual way, since all that is required is the last block of
   ciphertext of the previous packet (in this case packet N, which WAS
   received).

7.  MRU Considerations

   Because padding can occur, and because there is an additional
   protocol field in effect, implementations should take into account
   the growth of the packets.  As an example, if PFC had been
   negotiated, and if the MRU before had been exactly a multiple of 8,
   then the plaintext resulting combining a full sized data packets with
   a one byte protocol field would require an additional 7 bytes of
   padding, and the sequence number would be an additional 2 bytes so
   that the information field in the DESE protocol is now 10 bytes
   larger than that in the original packet.  Because the convention is
   that PPP options are independent of each other, negotiation of DESE
   does not, by itself, automatically increase the MRU value.





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


8.  Security Considerations

   Security issues are the primary subject of this memo.  This proposal
   relies on exterior and unspecified methods for authentication and
   retrieval of shared secrets.

   It proposes no new technology for privacy, but merely describes a
   convention for the application of the DES cipher to data transmission
   between PPP implementation.

   Any methodology for the protection and retrieval of shared secrets,
   and any limitations of the DES cipher are relevant to the use
   described here.

9.  References

   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, Daydreamer, July 1994.

   [2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider
       Systems, June 1996.

   [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP
       Multilink Protocol (MP)", RFC 1717, UC Berkeley, November 1994.

   [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
       January 1994.

   [5] National Bureau of Standards, "Data Encryption Standard", FIPS
       PUB 46 (January 1977).

   [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
       81 (December 1980).

   [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
       source code in C", John Wiley & Sons, Inc. 1994.  There is an
       errata associated with the book, and people can get a copy by
       sending e-mail to [e-mail].













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


10.  Authors' Addresses

   Keith Sklower
   Computer Science Department
   384 Soda Hall, Mail Stop 1776
   University of California
   Berkeley, CA 94720-1776

   Phone:  [phone]
   EMail:  [e-mail]


   Gerry M. Meyer
   Spider Systems
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

   Phone: (UK) 131 554 9424
   Fax:   (UK) 131 554 0649
   EMail: [e-mail]






























Sklower & Meyer              Informational                     [Page 10]