rfc1851.txt

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

Network Working Group                                            P. Karn
Request for Comments: 1851                                      Qualcomm
Category: Experimental                                        P. Metzger
                                                                Piermont
                                                              W. Simpson
                                                              Daydreamer
                                                          September 1995


                      The ESP Triple DES Transform


Status of this Memo

   This document defines an Experimental Protocol for the Internet
   community.  This does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.


Abstract

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


Table of Contents

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

     2.     Payload Format ........................................    4

     3.     Algorithm .............................................    6
        3.1       Encryption ......................................    6
        3.2       Decryption ......................................    7

     SECURITY CONSIDERATIONS ......................................    7
     ACKNOWLEDGEMENTS .............................................    8
     REFERENCES ...................................................    9
     AUTHOR'S ADDRESS .............................................   11







Karn, et al                   Experimental                      [Page 1]

RFC 1851                        ESP 3DES                  September 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 a variant of
   of the Cipher Block Chaining (CBC) mode of the US Data Encryption
   Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
   This variant, known as Triple DES (3DES), processes each block of the
   plaintext three times, each time with a different key [Tuchman79].

   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 3DES key shared between the communicating parties is
   effectively 168-bits long.  This key consists of three independent
   56-bit quantities used by the DES algorithm.  Each of the three 56-
   bit subkeys 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 3DES 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, et al                   Experimental                      [Page 2]

RFC 1851                        ESP 3DES                  September 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 3DES 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

   Three DES-CBC implementations may be pipelined in series to provide
   parallel computation.  At the time of writing, at least one hardware
   implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p.
   231].
























Karn, et al                   Experimental                      [Page 3]

RFC 1851                        ESP 3DES                  September 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 3DES 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, et al                   Experimental                      [Page 4]

RFC 1851                        ESP 3DES                  September 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, et al                   Experimental                      [Page 5]

RFC 1851                        ESP 3DES                  September 1995


3.  Algorithm

   The 3DES algorithm is a simple variant on the DES-CBC algorithm.  The
   DES function is replaced by three rounds of that function, an
   encryption followed by a decryption followed by an encryption, each
   with independant keys, k1, k2 and k3.

   Note that when all three keys (k1, k2 and k3) are the same, 3DES is
   equivalent to DES-CBC.  This property allows the 3DES hardware
   implementations to operate in DES mode without modification.

   For more explanation and implementation information for Triple 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.