rfc1829.txt

中、英文RFC文档大全打包下载完全版 .

   which identifies the protocol header that begins the payload.

   Provide an Initialization Vector (IV) of the size indicated by the
   SPI.

   Encrypt the payload with DES in CBC mode, producing a ciphertext of
   the same length.

   Octets are mapped to DES blocks in network order (most significant
   octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload
   corresponds to bits 1-8 of the 64-bit DES input block, while octet 7
   (modulo 8) corresponds to bits 57-64 of the DES input block.

   Construct an appropriate IP datagram for the target Destination, with
   the indicated SPI, IV, and payload.

   The Total/Payload Length in the encapsulating IP Header reflects the
   length of the encrypted data, plus the SPI, IV, padding, Pad Length,
   and Payload Type octets.



3.2.  Decryption

   First, the SPI field is removed and examined.  This is used as an
   index into the local Security Parameter table to find the negotiated


Karn, Metzger & Simpson     Standards Track                     [Page 5]

RFC 1829                      ESP DES-CBC                    August 1995


   parameters and decryption key.

   The negotiated form of the IV determines the size of the IV field.
   These octets are removed, and an appropriate 64-bit IV value is
   constructed.

   The encrypted part of the payload is decrypted using DES in the CBC
   mode.

   The Payload Type is removed and examined.  If it is unrecognized, the
   payload is discarded with an appropriate ICMP message.

   The Pad Length is removed and examined.  The specified number of pad
   octets are removed from the end of the decrypted payload, and the IP
   Total/Payload Length is adjusted accordingly.

   The IP Header(s) and the remaining portion of the decrypted payload
   are passed to the protocol receive routine specified by the Payload
   Type field.



Security Considerations

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the DES
   algorithm, the correctness of that algorithm's implementation, the
   security of the key management mechanism and its implementation, the
   strength of the key [CN94], and upon the correctness of the
   implementations in all of the participating nodes.

   Among other considerations, applications may wish to take care not to
   select weak keys, although the odds of picking one at random are low
   [Schneier94, p 233].

   The cut and paste attack described by [Bell95] exploits the nature of
   all Cipher Block Chaining algorithms.  When a block is damaged in
   transmission, on decryption both it and the following block will be
   garbled by the decryption process, but all subsequent blocks will be
   decrypted correctly.  If an attacker has legitimate access to the
   same key, this feature can be used to insert or replay previously
   encrypted data of other users of the same engine, revealing the
   plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

   At the time of writing of this document, [BS93] demonstrated a


Karn, Metzger & Simpson     Standards Track                     [Page 6]

RFC 1829                      ESP DES-CBC                    August 1995


   differential cryptanalysis based chosen-plaintext attack requiring
   2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear
   cryptanalysis based known-plaintext attack requiring only 2^43
   plaintext-ciphertext pairs.  Although these attacks are not
   considered practical, they must be taken into account.

   More disturbingly, [Weiner94] has shown the design of a DES cracking
   machine costing $1 Million that can crack one key every 3.5 hours.
   This is an extremely practical attack.

   One or two blocks of known plaintext suffice to recover a DES key.
   Because IP datagrams typically begin with a block of known and/or
   guessable header text, frequent key changes will not protect against
   this attack.

   It is suggested that DES is not a good encryption algorithm for the
   protection of even moderate value information in the face of such
   equipment.  Triple DES is probably a better choice for such purposes.

   However, despite these potential risks, the level of privacy provided
   by use of ESP DES-CBC in the Internet environment is far greater than
   sending the datagram as cleartext.



Acknowledgements

   This document was reviewed by the IP Security Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the [e-mail] mailing list.

   Some of the text of this specification was derived from work by
   Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

   The use of DES for confidentiality is closely modeled on the work
   done for SNMPv2 [RFC-1446].

   Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz,
   Dave Mihelcic and Jeffrey Schiller provided useful critiques of
   earlier versions of this draft.










Karn, Metzger & Simpson     Standards Track                     [Page 7]

RFC 1829                      ESP DES-CBC                    August 1995


References

   [Bell95]  Bellovin, S., "An Issue With DES-CBC When Used Without
            Strong Integrity", Proceedings of the 32nd IETF, Danvers,
            MA, April 1995.

   [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
            the Data Encryption Standard", Berlin: Springer-Verlag,
            1993.

   [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
            253-280, July 1994.

   [FIPS-46]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46, January 1977.

   [FIPS-46-1]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

   [FIPS-74]
            US National Bureau of Standards, "Guidelines for
            Implementing and Using the Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            74, April 1981.

   [FIPS-81]
            US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.

   [Matsui94]
            Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
            Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
            Springer-Verlag, 1994.

   [RFC-1446]
            Galvin, J., and McCloghrie, K., "Security Protocols for
            Version 2 of the Simple Network Management Protocol
            (SNMPv2)", RFC-1446, DDN Network Information Center, April
            1993.

   [RFC-1700]
            Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,

Karn, Metzger & Simpson     Standards Track                     [Page 8]

RFC 1829                      ESP DES-CBC                    August 1995


            RFC-1700, USC/Information Sciences Institute, October 1994.

   [RFC-1800]
            Postel, J., "Internet Official Protocol Standards", STD 1,
            RFC-1800, USC/Information Sciences Institute, July 1995.

   [RFC-1825]
            Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC-1825, Naval Research Laboratory, July 1995.

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

   [RFC-1827]
            Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
            RFC-1827, Naval Research Laboratory, July 1995.

   [Schneier94]
            Schneier, B., "Applied Cryptography", John Wiley & Sons, New
            York, NY, 1994.  ISBN 0-471-59756-2

   [Weiner94]
            Wiener, M.J., "Efficient DES Key Search", School of Computer
            Science, Carleton University, Ottawa, Canada, TR-244, May
            1994.  Presented at the Rump Session of Crypto '93.
























Karn, Metzger & Simpson     Standards Track                     [Page 9]

RFC 1829                      ESP DES-CBC                    August 1995


Author's Address

   Questions about this memo can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

      [e-mail]


      Perry Metzger
      Piermont Information Systems Inc.
      160 Cabrini Blvd., Suite #2
      New York, NY  10033

      [e-mail]


      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

      [e-mail]
          [e-mail]






















Karn, Metzger & Simpson     Standards Track                    [Page 10]