rfc2419.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2419                 PPP DES Encryption v2            September 1998


6.1.  Padding Considerations

   Since the DES algorithm operates on blocks of 8 octets, plain text
   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.

   Since there is no standard directory of protocols which are
   susceptible to corruption through padding, this can lead to confusion
   over which protocols should be protected against padding-induced
   corruption.  Consequently, this specification requires that the
   unambiguous technique described below MUST be applied to ALL plain
   text packets.

   The method of padding is based on that described for the LCP Self-
   Describing-Padding (SDP) option (as defined in RFC 1570 [4]), but
   differs in two respects: first, maximum-pad value is fixed to be 8,
   and second, the method is to be applied to ALL packets, not just
   "specifically identified protocols".

   Plain text which is not a multiple of 8 octets long MUST be padded
   prior to encrypting the plain text with sufficient octets in the
   sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of
   8 octets.

   Plain text which is already a multiple of 8 octets may require
   padding with a further 8 octets (1, 2, 3 ... 8).  These additional
   octets MUST be appended prior to encrypting the plain text if the
   last octet of the plain text has a value of 1 through 8, inclusive.

   After the peer has decrypted the cipher text, it strips off the
   Self-Describing-Padding octets, to recreate the original plain text.

   Note that after decrypting, only the content of the last octet need
   be examined to determine how many pad bytes should be removed.
   However, the peer SHOULD discard the frame if all the octets forming
   the padding do not match the scheme just described.

   The padding operation described above is performed independently of
   whether or not the LCP Self-Describing-Padding (SDP) option has been
   negotiated.  If it has, SDP would be applied to the packet as a whole
   after it had been ciphered and after the Encryption Protocol
   Identifiers had been prepended.







Sklower & Meyer             Standards Track                     [Page 7]

RFC 2419                 PPP DES Encryption v2            September 1998


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.

   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).




Sklower & Meyer             Standards Track                     [Page 8]

RFC 2419                 PPP DES Encryption v2            September 1998


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.

8.  Differences from RFC 1969

8.1.  When to Pad

   In RFC 1969, the method of Self-Describing Padding was not applied to
   all packets transmitted using DESE.  Following the method of the SDP
   option itself, only "specifically identified protocols", were to be
   padded.  Protocols with an explicit length identifier were exempt.
   (Examples included non-VJ-compressed IP, XNS, CLNP).

   In this speficiation, the method is applied to ALL packets.

   Secondly, this specification is clarified as being completely
   independent of the Self-Describing-Padding option for PPP, and fixes
   the maximum number of padding octets as 8.

8.2.  Assigned Numbers

   Since this specification could theoretically cause misinterpretation
   of a packet transmitted according to the previous specification, a
   new type field number has been assigned for the DESE-bis protocol

8.3.  Minor Editorial Changes

   This specification has been designated a standards track document.
   Some other language has been changed for greater clarity.

9.  Security Considerations

   This proposal is concerned with providing confidentiality solely.  It
   does not describe any mechanisms for integrity, authentication or
   nonrepudiation.  It does not guarantee that any message received has
   not been modified in transit through replay, cut-and-paste or active




Sklower & Meyer             Standards Track                     [Page 9]

RFC 2419                 PPP DES Encryption v2            September 1998


   tampering.  It does not provide authentication of the source of any
   packet received, or protect against the sender of any packet denying
   its authorship.

   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.

10.  References

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

   [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
       1996.

   [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti,
       "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

   [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 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].

   [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.










Sklower & Meyer             Standards Track                    [Page 10]

RFC 2419                 PPP DES Encryption v2            September 1998


11.  Authors' Addresses

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

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


   Gerry M. Meyer
   Cisco Systems Ltd.
   Bothwell House, Pochard Way,
   Strathclyde Business Park,
   Bellshill, ML4 3HB
   Scotland, UK

   Phone: (UK) (pending)
   Fax:   (UK) (pending)
   Email: [e-mail]





























Sklower & Meyer             Standards Track                    [Page 11]

RFC 2419                 PPP DES Encryption v2            September 1998


12.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Sklower & Meyer             Standards Track                    [Page 12]