home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1829 < prev    next >
Text File  |  1995-08-08  |  19KB  |  608 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            P. Karn
  8. Request for Comments: 1829                                      Qualcomm
  9. Category: Standards Track                                     P. Metzger
  10.                                                                 Piermont
  11.                                                               W. Simpson
  12.                                                               Daydreamer
  13.                                                              August 1995
  14.  
  15.  
  16.                        The ESP DES-CBC Transform
  17.  
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28.  
  29. Abstract
  30.  
  31.    This document describes the DES-CBC security transform for the IP
  32.    Encapsulating Security Payload (ESP).
  33.  
  34.  
  35. Table of Contents
  36.  
  37.      1.     Introduction ..........................................    1
  38.         1.1       Keys ............................................    1
  39.         1.2       Initialization Vector ...........................    1
  40.         1.3       Data Size .......................................    2
  41.         1.4       Performance .....................................    2
  42.  
  43.      2.     Payload Format ........................................    3
  44.  
  45.      3.     Algorithm .............................................    5
  46.         3.1       Encryption ......................................    5
  47.         3.2       Decryption ......................................    5
  48.  
  49.      SECURITY CONSIDERATIONS ......................................    6
  50.      ACKNOWLEDGEMENTS .............................................    7
  51.      REFERENCES ...................................................    8
  52.      AUTHOR'S ADDRESS .............................................   10
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Karn, Metzger & Simpson     Standards Track                     [Page i]
  59.  
  60. RFC 1829                      ESP DES-CBC                    August 1995
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    The Encapsulating Security Payload (ESP) [RFC-1827] provides
  66.    confidentiality for IP datagrams by encrypting the payload data to be
  67.    protected.  This specification describes the ESP use of the Cipher
  68.    Block Chaining (CBC) mode of the US Data Encryption Standard (DES)
  69.    algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
  70.  
  71.    All implementations that claim conformance or compliance with the
  72.    Encapsulating Security Payload specification MUST implement this
  73.    DES-CBC transform.
  74.  
  75.    This document assumes that the reader is familiar with the related
  76.    document "Security Architecture for the Internet Protocol"
  77.    [RFC-1825], which defines the overall security plan for IP, and
  78.    provides important background for this specification.
  79.  
  80.  
  81.  
  82. 1.1.  Keys
  83.  
  84.    The secret DES key shared between the communicating parties is eight
  85.    octets in length.  This key consists of a 56-bit quantity used by the
  86.    DES algorithm.  The 56-bit key is stored as a 64-bit (eight octet)
  87.    quantity, with the least significant bit of each octet used as a
  88.    parity bit.
  89.  
  90.  
  91.  
  92. 1.2.  Initialization Vector
  93.  
  94.    This mode of DES requires an Initialization Vector (IV) that is eight
  95.    octets in length.
  96.  
  97.    Each datagram contains its own IV.  Including the IV in each datagram
  98.    ensures that decryption of each received datagram can be performed,
  99.    even when other datagrams are dropped, or datagrams are re-ordered in
  100.    transit.
  101.  
  102.    The method for selection of IV values is implementation dependent.
  103.  
  104.    Notes:
  105.       A common acceptable technique is simply a counter, beginning with
  106.       a randomly chosen value.  While this provides an easy method for
  107.       preventing repetition, and is sufficiently robust for practical
  108.       use, cryptanalysis may use the rare serendipitous occurrence when
  109.       a corresponding bit position in the first DES block increments in
  110.       exactly the same fashion.
  111.  
  112.  
  113. Karn, Metzger & Simpson     Standards Track                     [Page 1]
  114.  
  115. RFC 1829                      ESP DES-CBC                    August 1995
  116.  
  117.  
  118.       Other implementations exhibit unpredictability, usually through a
  119.       pseudo-random number generator.  Care should be taken that the
  120.       periodicity of the number generator is long enough to prevent
  121.       repetition during the lifetime of the session key.
  122.  
  123.  
  124.  
  125. 1.3.  Data Size
  126.  
  127.    The DES algorithm operates on blocks of eight octets.  This often
  128.    requires padding after the end of the unencrypted payload data.
  129.  
  130.    Both input and output result in the same number of octets, which
  131.    facilitates in-place encryption and decryption.
  132.  
  133.    On receipt, if the length of the data to be decrypted is not an
  134.    integral multiple of eight octets, then an error is indicated, as
  135.    described in [RFC-1825].
  136.  
  137.  
  138.  
  139. 1.4.  Performance
  140.  
  141.    At the time of writing, at least one hardware implementation can
  142.    encrypt or decrypt at about 1 Gbps [Schneier94, p. 231].
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Karn, Metzger & Simpson     Standards Track                     [Page 2]
  169.  
  170. RFC 1829                      ESP DES-CBC                    August 1995
  171.  
  172.  
  173. 2.  Payload Format
  174.  
  175.  
  176.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  177.    |                Security Parameters Index (SPI)                |
  178.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  179.    |                                                               |
  180.    ~                   Initialization Vector (IV)                  ~
  181.    |                                                               |
  182.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  183.    |                                                               |
  184.    ~                          Payload Data                         ~
  185.    |                                                               |
  186.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  187.              ... Padding           |  Pad Length   | Payload Type  |
  188.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  189.  
  190.  
  191.    Security Parameters Index (SPI)
  192.  
  193.       A 32-bit value identifying the Security Parameters for this
  194.       datagram.  The value MUST NOT be zero.
  195.  
  196.    Initialization Vector (IV)
  197.  
  198.       The size of this field is variable, although it is constant for
  199.       all DES-CBC datagrams of the same SPI and IP Destination.  Octets
  200.       are sent in network order (most significant octet first)
  201.       [RFC-1700].
  202.  
  203.       The size MUST be a multiple of 32-bits.  Sizes of 32 and 64 bits
  204.       are required to be supported.  The use of other sizes is beyond
  205.       the scope of this specification.  The size is expected to be
  206.       indicated by the key management mechanism.
  207.  
  208.       When the size is 32-bits, a 64-bit IV is formed from the 32-bit
  209.       value followed by (concatenated with) the bit-wise complement of
  210.       the 32-bit value.  This field size is most common, as it aligns
  211.       the Payload Data for both 32-bit and 64-bit processing.
  212.  
  213.       All conformant implementations MUST also correctly process a
  214.       64-bit field size.  This provides strict compatibility with
  215.       existing hardware implementations.
  216.  
  217.          It is the intent that the value not repeat during the lifetime
  218.          of the encryption session key.  Even when a full 64-bit IV is
  219.          used, the session key SHOULD be changed at least as frequently
  220.          as 2**32 datagrams.
  221.  
  222.  
  223. Karn, Metzger & Simpson     Standards Track                     [Page 3]
  224.  
  225. RFC 1829                      ESP DES-CBC                    August 1995
  226.  
  227.  
  228.    Payload Data
  229.  
  230.       The size of this field is variable.
  231.  
  232.       Prior to encryption and after decryption, this field begins with
  233.       the IP Protocol/Payload header specified in the Payload Type
  234.       field.  Note that in the case of IP-in-IP encapsulation (Payload
  235.       Type 4), this will be another IP header.
  236.  
  237.    Padding
  238.  
  239.       The size of this field is variable.
  240.  
  241.       Prior to encryption, it is filled with unspecified implementation
  242.       dependent (preferably random) values, to align the Pad Length and
  243.       Payload Type fields at an eight octet boundary.
  244.  
  245.       After decryption, it MUST be ignored.
  246.  
  247.    Pad Length
  248.  
  249.       This field indicates the size of the Padding field.  It does not
  250.       include the Pad Length and Payload Type fields.  The value
  251.       typically ranges from 0 to 7, but may be up to 255 to permit
  252.       hiding of the actual data length.
  253.  
  254.       This field is opaque.  That is, the value is set prior to
  255.       encryption, and is examined only after decryption.
  256.  
  257.    Payload Type
  258.  
  259.       This field indicates the contents of the Payload Data field, using
  260.       the IP Protocol/Payload value.  Up-to-date values of the IP
  261.       Protocol/Payload are specified in the most recent "Assigned
  262.       Numbers" [RFC-1700].
  263.  
  264.       This field is opaque.  That is, the value is set prior to
  265.       encryption, and is examined only after decryption.
  266.  
  267.          For example, when encrypting an entire IP datagram (Tunnel-
  268.          Mode), this field will contain the value 4, which indicates
  269.          IP-in-IP encapsulation.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Karn, Metzger & Simpson     Standards Track                     [Page 4]
  279.  
  280. RFC 1829                      ESP DES-CBC                    August 1995
  281.  
  282.  
  283. 3.  Algorithm
  284.  
  285.    In DES-CBC, the base DES encryption function is applied to the XOR of
  286.    each plaintext block with the previous ciphertext block to yield the
  287.    ciphertext for the current block.  This provides for
  288.    re-synchronization when datagrams are lost.
  289.  
  290.    For more explanation and implementation information for DES, see
  291.    [Schneier94].
  292.  
  293.  
  294.  
  295. 3.1.  Encryption
  296.  
  297.    Append zero or more octets of (preferably random) padding to the
  298.    plaintext, to make its modulo 8 length equal to 6.  For example, if
  299.    the plaintext length is 41, 5 octets of padding are added.
  300.  
  301.    Append a Pad Length octet containing the number of padding octets
  302.    just added.
  303.  
  304.    Append a Payload Type octet containing the IP Protocol/Payload value
  305.    which identifies the protocol header that begins the payload.
  306.  
  307.    Provide an Initialization Vector (IV) of the size indicated by the
  308.    SPI.
  309.  
  310.    Encrypt the payload with DES in CBC mode, producing a ciphertext of
  311.    the same length.
  312.  
  313.    Octets are mapped to DES blocks in network order (most significant
  314.    octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload
  315.    corresponds to bits 1-8 of the 64-bit DES input block, while octet 7
  316.    (modulo 8) corresponds to bits 57-64 of the DES input block.
  317.  
  318.    Construct an appropriate IP datagram for the target Destination, with
  319.    the indicated SPI, IV, and payload.
  320.  
  321.    The Total/Payload Length in the encapsulating IP Header reflects the
  322.    length of the encrypted data, plus the SPI, IV, padding, Pad Length,
  323.    and Payload Type octets.
  324.  
  325.  
  326.  
  327. 3.2.  Decryption
  328.  
  329.    First, the SPI field is removed and examined.  This is used as an
  330.    index into the local Security Parameter table to find the negotiated
  331.  
  332.  
  333. Karn, Metzger & Simpson     Standards Track                     [Page 5]
  334.  
  335. RFC 1829                      ESP DES-CBC                    August 1995
  336.  
  337.  
  338.    parameters and decryption key.
  339.  
  340.    The negotiated form of the IV determines the size of the IV field.
  341.    These octets are removed, and an appropriate 64-bit IV value is
  342.    constructed.
  343.  
  344.    The encrypted part of the payload is decrypted using DES in the CBC
  345.    mode.
  346.  
  347.    The Payload Type is removed and examined.  If it is unrecognized, the
  348.    payload is discarded with an appropriate ICMP message.
  349.  
  350.    The Pad Length is removed and examined.  The specified number of pad
  351.    octets are removed from the end of the decrypted payload, and the IP
  352.    Total/Payload Length is adjusted accordingly.
  353.  
  354.    The IP Header(s) and the remaining portion of the decrypted payload
  355.    are passed to the protocol receive routine specified by the Payload
  356.    Type field.
  357.  
  358.  
  359.  
  360. Security Considerations
  361.  
  362.    Users need to understand that the quality of the security provided by
  363.    this specification depends completely on the strength of the DES
  364.    algorithm, the correctness of that algorithm's implementation, the
  365.    security of the key management mechanism and its implementation, the
  366.    strength of the key [CN94], and upon the correctness of the
  367.    implementations in all of the participating nodes.
  368.  
  369.    Among other considerations, applications may wish to take care not to
  370.    select weak keys, although the odds of picking one at random are low
  371.    [Schneier94, p 233].
  372.  
  373.    The cut and paste attack described by [Bell95] exploits the nature of
  374.    all Cipher Block Chaining algorithms.  When a block is damaged in
  375.    transmission, on decryption both it and the following block will be
  376.    garbled by the decryption process, but all subsequent blocks will be
  377.    decrypted correctly.  If an attacker has legitimate access to the
  378.    same key, this feature can be used to insert or replay previously
  379.    encrypted data of other users of the same engine, revealing the
  380.    plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
  381.    this attack, but on its own is not considered cryptographically
  382.    strong.  In this situation, user or connection oriented integrity
  383.    checking is needed [RFC-1826].
  384.  
  385.    At the time of writing of this document, [BS93] demonstrated a
  386.  
  387.  
  388. Karn, Metzger & Simpson     Standards Track                     [Page 6]
  389.  
  390. RFC 1829                      ESP DES-CBC                    August 1995
  391.  
  392.  
  393.    differential cryptanalysis based chosen-plaintext attack requiring
  394.    2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear
  395.    cryptanalysis based known-plaintext attack requiring only 2^43
  396.    plaintext-ciphertext pairs.  Although these attacks are not
  397.    considered practical, they must be taken into account.
  398.  
  399.    More disturbingly, [Weiner94] has shown the design of a DES cracking
  400.    machine costing $1 Million that can crack one key every 3.5 hours.
  401.    This is an extremely practical attack.
  402.  
  403.    One or two blocks of known plaintext suffice to recover a DES key.
  404.    Because IP datagrams typically begin with a block of known and/or
  405.    guessable header text, frequent key changes will not protect against
  406.    this attack.
  407.  
  408.    It is suggested that DES is not a good encryption algorithm for the
  409.    protection of even moderate value information in the face of such
  410.    equipment.  Triple DES is probably a better choice for such purposes.
  411.  
  412.    However, despite these potential risks, the level of privacy provided
  413.    by use of ESP DES-CBC in the Internet environment is far greater than
  414.    sending the datagram as cleartext.
  415.  
  416.  
  417.  
  418. Acknowledgements
  419.  
  420.    This document was reviewed by the IP Security Working Group of the
  421.    Internet Engineering Task Force (IETF).  Comments should be submitted
  422.    to the ipsec@ans.net mailing list.
  423.  
  424.    Some of the text of this specification was derived from work by
  425.    Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
  426.  
  427.    The use of DES for confidentiality is closely modeled on the work
  428.    done for SNMPv2 [RFC-1446].
  429.  
  430.    Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz,
  431.    Dave Mihelcic and Jeffrey Schiller provided useful critiques of
  432.    earlier versions of this draft.
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. Karn, Metzger & Simpson     Standards Track                     [Page 7]
  444.  
  445. RFC 1829                      ESP DES-CBC                    August 1995
  446.  
  447.  
  448. References
  449.  
  450.    [Bell95]  Bellovin, S., "An Issue With DES-CBC When Used Without
  451.             Strong Integrity", Proceedings of the 32nd IETF, Danvers,
  452.             MA, April 1995.
  453.  
  454.    [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
  455.             the Data Encryption Standard", Berlin: Springer-Verlag,
  456.             1993.
  457.  
  458.    [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
  459.             Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
  460.             253-280, July 1994.
  461.  
  462.    [FIPS-46]
  463.             US National Bureau of Standards, "Data Encryption Standard",
  464.             Federal Information Processing Standard (FIPS) Publication
  465.             46, January 1977.
  466.  
  467.    [FIPS-46-1]
  468.             US National Bureau of Standards, "Data Encryption Standard",
  469.             Federal Information Processing Standard (FIPS) Publication
  470.             46-1, January 1988.
  471.  
  472.    [FIPS-74]
  473.             US National Bureau of Standards, "Guidelines for
  474.             Implementing and Using the Data Encryption Standard",
  475.             Federal Information Processing Standard (FIPS) Publication
  476.             74, April 1981.
  477.  
  478.    [FIPS-81]
  479.             US National Bureau of Standards, "DES Modes of Operation"
  480.             Federal Information Processing Standard (FIPS) Publication
  481.             81, December 1980.
  482.  
  483.    [Matsui94]
  484.             Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
  485.             Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
  486.             Springer-Verlag, 1994.
  487.  
  488.    [RFC-1446]
  489.             Galvin, J., and McCloghrie, K., "Security Protocols for
  490.             Version 2 of the Simple Network Management Protocol
  491.             (SNMPv2)", RFC-1446, DDN Network Information Center, April
  492.             1993.
  493.  
  494.    [RFC-1700]
  495.             Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
  496.  
  497. Karn, Metzger & Simpson     Standards Track                     [Page 8]
  498.  
  499. RFC 1829                      ESP DES-CBC                    August 1995
  500.  
  501.  
  502.             RFC-1700, USC/Information Sciences Institute, October 1994.
  503.  
  504.    [RFC-1800]
  505.             Postel, J., "Internet Official Protocol Standards", STD 1,
  506.             RFC-1800, USC/Information Sciences Institute, July 1995.
  507.  
  508.    [RFC-1825]
  509.             Atkinson, R., "Security Architecture for the Internet
  510.             Protocol", RFC-1825, Naval Research Laboratory, July 1995.
  511.  
  512.    [RFC-1826]
  513.             Atkinson, R., "IP Authentication Header", RFC-1826, Naval
  514.             Research Laboratory, July 1995.
  515.  
  516.    [RFC-1827]
  517.             Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
  518.             RFC-1827, Naval Research Laboratory, July 1995.
  519.  
  520.    [Schneier94]
  521.             Schneier, B., "Applied Cryptography", John Wiley & Sons, New
  522.             York, NY, 1994.  ISBN 0-471-59756-2
  523.  
  524.    [Weiner94]
  525.             Wiener, M.J., "Efficient DES Key Search", School of Computer
  526.             Science, Carleton University, Ottawa, Canada, TR-244, May
  527.             1994.  Presented at the Rump Session of Crypto '93.
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552. Karn, Metzger & Simpson     Standards Track                     [Page 9]
  553.  
  554. RFC 1829                      ESP DES-CBC                    August 1995
  555.  
  556.  
  557. Author's Address
  558.  
  559.    Questions about this memo can also be directed to:
  560.  
  561.       Phil Karn
  562.       Qualcomm, Inc.
  563.       6455 Lusk Blvd.
  564.       San Diego, California  92121-2779
  565.  
  566.       karn@unix.ka9q.ampr.org
  567.  
  568.  
  569.       Perry Metzger
  570.       Piermont Information Systems Inc.
  571.       160 Cabrini Blvd., Suite #2
  572.       New York, NY  10033
  573.  
  574.       perry@piermont.com
  575.  
  576.  
  577.       William Allen Simpson
  578.       Daydreamer
  579.       Computer Systems Consulting Services
  580.       1384 Fontaine
  581.       Madison Heights, Michigan  48071
  582.  
  583.       Bill.Simpson@um.cc.umich.edu
  584.           bsimpson@MorningStar.com
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607. Karn, Metzger & Simpson     Standards Track                    [Page 10]
  608.