RFC1829 The ESP DES-CBC Transform

1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. August 1995. (Format: TXT=19291 bytes) (Status: PROPOSED STANDARD)

日本語訳
RFC一覧

参照

Network Working Group                                            P. Karn
Request for Comments: 1829                                      Qualcomm
Category: Standards Track                                     P. Metzger
                                                                Piermont
                                                              W. Simpson
                                                              Daydreamer
                                                             August 1995


                       The ESP DES-CBC Transform



Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


Abstract

   This document describes the DES-CBC security transform for the IP
   Encapsulating Security Payload (ESP).


Table of Contents

     1.     Introduction ..........................................    1
        1.1       Keys ............................................    1
        1.2       Initialization Vector ...........................    1
        1.3       Data Size .......................................    2
        1.4       Performance .....................................    2

     2.     Payload Format ........................................    3

     3.     Algorithm .............................................    5
        3.1       Encryption ......................................    5
        3.2       Decryption ......................................    5

     SECURITY CONSIDERATIONS ......................................    6
     ACKNOWLEDGEMENTS .............................................    7
     REFERENCES ...................................................    8
     AUTHOR'S ADDRESS .............................................   10





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


1.  Introduction

   The Encapsulating Security Payload (ESP) [RFC-1827] provides
   confidentiality for IP datagrams by encrypting the payload data to be
   protected.  This specification describes the ESP use of the Cipher
   Block Chaining (CBC) mode of the US Data Encryption Standard (DES)
   algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].

   All implementations that claim conformance or compliance with the
   Encapsulating Security Payload specification MUST implement this
   DES-CBC transform.

   This document assumes that the reader is familiar with the related
   document "Security Architecture for the Internet Protocol"
   [RFC-1825], which defines the overall security plan for IP, and
   provides important background for this specification.



1.1.  Keys

   The secret DES key shared between the communicating parties is eight
   octets in length.  This key consists of a 56-bit quantity used by the
   DES algorithm.  The 56-bit key is stored as a 64-bit (eight octet)
   quantity, with the least significant bit of each octet used as a
   parity bit.



1.2.  Initialization Vector

   This mode of DES requires an Initialization Vector (IV) that is eight
   octets in length.

   Each datagram contains its own IV.  Including the IV in each datagram
   ensures that decryption of each received datagram can be performed,
   even when other datagrams are dropped, or datagrams are re-ordered in
   transit.

   The method for selection of IV values is implementation dependent.

   Notes:
      A common acceptable technique is simply a counter, beginning with
      a randomly chosen value.  While this provides an easy method for
      preventing repetition, and is sufficiently robust for practical
      use, cryptanalysis may use the rare serendipitous occurrence when
      a corresponding bit position in the first DES block increments in
      exactly the same fashion.


Karn, Metzger & Simpson     Standards Track                     [Page 1]

RFC 1829                      ESP DES-CBC                    August 1995


      Other implementations exhibit unpredictability, usually through a
      pseudo-random number generator.  Care should be taken that the
      periodicity of the number generator is long enough to prevent
      repetition during the lifetime of the session key.



1.3.  Data Size

   The DES algorithm operates on blocks of eight octets.  This often
   requires padding after the end of the unencrypted payload data.

   Both input and output result in the same number of octets, which
   facilitates in-place encryption and decryption.

   On receipt, if the length of the data to be decrypted is not an
   integral multiple of eight octets, then an error is indicated, as
   described in [RFC-1825].



1.4.  Performance

   At the time of writing, at least one hardware implementation can
   encrypt or decrypt at about 1 Gbps [Schneier94, p. 231].

























Karn, Metzger & Simpson     Standards Track                     [Page 2]

RFC 1829                      ESP DES-CBC                    August 1995


2.  Payload Format


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initialization Vector (IV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Payload Data                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Padding           |  Pad Length   | Payload Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Security Parameters Index (SPI)

      A 32-bit value identifying the Security Parameters for this
      datagram.  The value MUST NOT be zero.

   Initialization Vector (IV)

      The size of this field is variable, although it is constant for
      all DES-CBC datagrams of the same SPI and IP Destination.  Octets
      are sent in network order (most significant octet first)
      [RFC-1700].

      The size MUST be a multiple of 32-bits.  Sizes of 32 and 64 bits
      are required to be supported.  The use of other sizes is beyond
      the scope of this specification.  The size is expected to be
      indicated by the key management mechanism.

      When the size is 32-bits, a 64-bit IV is formed from the 32-bit
      value followed by (concatenated with) the bit-wise complement of
      the 32-bit value.  This field size is most common, as it aligns
      the Payload Data for both 32-bit and 64-bit processing.

      All conformant implementations MUST also correctly process a
      64-bit field size.  This provides strict compatibility with
      existing hardware implementations.

         It is the intent that the value not repeat during the lifetime
         of the encryption session key.  Even when a full 64-bit IV is
         used, the session key SHOULD be changed at least as frequently
         as 2**32 datagrams.


Karn, Metzger & Simpson     Standards Track                     [Page 3]

RFC 1829                      ESP DES-CBC                    August 1995


   Payload Data

      The size of this field is variable.

      Prior to encryption and after decryption, this field begins with
      the IP Protocol/Payload header specified in the Payload Type
      field.  Note that in the case of IP-in-IP encapsulation (Payload
      Type 4), this will be another IP header.

   Padding

      The size of this field is variable.

      Prior to encryption, it is filled with unspecified implementation
      dependent (preferably random) values, to align the Pad Length and
      Payload Type fields at an eight octet boundary.

      After decryption, it MUST be ignored.

   Pad Length

      This field indicates the size of the Padding field.  It does not
      include the Pad Length and Payload Type fields.  The value
      typically ranges from 0 to 7, but may be up to 255 to permit
      hiding of the actual data length.

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

   Payload Type

      This field indicates the contents of the Payload Data field, using
      the IP Protocol/Payload value.  Up-to-date values of the IP
      Protocol/Payload are specified in the most recent "Assigned
      Numbers" [RFC-1700].

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

         For example, when encrypting an entire IP datagram (Tunnel-
         Mode), this field will contain the value 4, which indicates
         IP-in-IP encapsulation.








Karn, Metzger & Simpson     Standards Track                     [Page 4]

RFC 1829                      ESP DES-CBC                    August 1995


3.  Algorithm

   In DES-CBC, the base DES encryption function is applied to the XOR of
   each plaintext block with the previous ciphertext block to yield the
   ciphertext for the current block.  This provides for
   re-synchronization when datagrams are lost.

   For more explanation and implementation information for DES, see
   [Schneier94].



3.1.  Encryption

   Append zero or more octets of (preferably random) padding to the
   plaintext, to make its modulo 8 length equal to 6.  For example, if
   the plaintext length is 41, 5 octets of padding are added.

   Append a Pad Length octet containing the number of padding octets
   just added.

   Append a Payload Type octet containing the IP Protocol/Payload value
   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 ipsec@ans.net 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

      karn@unix.ka9q.ampr.org


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

      perry@piermont.com


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

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com






















一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Videobox

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る