home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-simpson-esp-des3-x-01.txt < prev    next >
Text File  |  1997-05-20  |  30KB  |  826 lines
  1.  
  2. Network Working Group                                             P Karn
  3. Internet Draft                                                [Qualcomm]
  4.                                                                P Metzger
  5.                                                               [Piermont]
  6.                                                              W A Simpson
  7.                                                             [DayDreamer]
  8. expires in six months                                           May 1997
  9.  
  10.  
  11.                       The ESP Triple DES Transform
  12.                     draft-simpson-esp-des3-x-01.txt
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document is an Internet-Draft.  Internet Drafts are working doc-
  18.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  19.    its Working Groups.  Note that other groups may also distribute work-
  20.    ing documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six
  23.    months, and may be updated, replaced, or obsoleted by other documents
  24.    at any time.  It is not appropriate to use Internet Drafts as refer-
  25.    ence material, or to cite them other than as a ``working draft'' or
  26.    ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  30.    Directories on:
  31.  
  32.       ftp.is.co.za (Africa)
  33.       nic.nordu.net (Europe)
  34.       ds.internic.net (US East Coast)
  35.       ftp.isi.edu (US West Coast)
  36.       munnari.oz.au (Pacific Rim)
  37.  
  38.    Distribution of this memo is unlimited.
  39.  
  40. Abstract
  41.  
  42.    This document describes the "Triple" DES-EDE3-CBC security transform
  43.    for the IP Encapsulating Security Payload (ESP).
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Karn, Metzger & Simpson   expires in six months                 [Page i]
  54. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  55.  
  56.  
  57. 1.  Introduction
  58.  
  59.    The Encapsulating Security Payload (ESP) [RFC-1827] provides confi-
  60.    dentiality for IP datagrams by encrypting the payload data to be pro-
  61.    tected.  This specification describes the ESP use of a variant of of
  62.    the Cipher Block Chaining (CBC) mode of the US Data Encryption Stan-
  63.    dard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].  This
  64.    variant, known as Triple DES (DES-EDE3-CBC), processes each block of
  65.    the plaintext three times, each time with a different key [Tuch-
  66.    man79].
  67.  
  68.    This document assumes that the reader is familiar with the related
  69.    document "Security Architecture for the Internet Protocol"
  70.    [RFC-1825], that defines the overall security plan for IP, and pro-
  71.    vides important background for this specification.
  72.  
  73.    In this document, the key words "MUST, "MUST NOT", "optional", "rec-
  74.    ommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
  75.    described in [RFC-2119].
  76.  
  77.  
  78. 1.1.  Algorithm and Mode
  79.  
  80.                       P1             P2             Pi
  81.                       |              |              |
  82.                IV->->(X)    +>->->->(X)    +>->->->(X)
  83.                       v     ^        v     ^        v
  84.                    +-----+  |     +-----+  |     +-----+
  85.                k1->| Ek1 |  ^ k1->| Ek1 |  ^ k1->| Ek1 |
  86.                    +-----+  |     +-----+  |     +-----+
  87.                       |     ^        |     ^        |
  88.                       v     |        v     |        v
  89.                    +-----+  ^     +-----+  ^     +-----+
  90.                k2->| Dk2 |  | k2->| Dk2 |  | k2->| Dk2 |
  91.                    +-----+  ^     +-----+  ^     +-----+
  92.                       |     |        |     |        |
  93.                       v     ^        v     ^        v
  94.                    +-----+  |     +-----+  |     +-----+
  95.                k3->| Ek3 |  ^ k3->| Ek3 |  ^ k3->| Ek3 |
  96.                    +-----+  |     +-----+  |     +-----+
  97.                       |     ^        |     ^        |
  98.                       +>->->+        +>->->+        +>->->
  99.                       |              |              |
  100.                       C1             C2             Ci
  101.  
  102.    The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo-
  103.    rithm.  In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with
  104.    the first 64-bit (8 octet) plaintext block (P1).  The keyed DES
  105.  
  106.  
  107.  
  108. Karn, Metzger & Simpson   expires in six months                 [Page 1]
  109. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  110.  
  111.  
  112.    function is interated three times, an encryption (Ek1) followed by a
  113.    decryption (Dk2) followed by an encryption (Ek3), and generates the
  114.    ciphertext (C1) for the block.  Each iteration uses an independant
  115.    key: k1, k2 and k3.
  116.  
  117.    For successive blocks, the previous ciphertext block is XOR'd with
  118.    the current plaintext (Pi).  The keyed DES-EDE3 encryption function
  119.    generates the ciphertext (Ci) for that block.
  120.  
  121.    To decrypt, the order of the functions is reversed: decrypt, encrypt,
  122.    decrypt.
  123.  
  124.    Note that when all three keys (k1, k2 and k3) are the same, DES-
  125.    EDE3-CBC is equivalent to DES-CBC.  This property allows the DES-EDE3
  126.    hardware implementations to operate in DES mode without modification.
  127.  
  128.    The "outer" Cipher Block Chaining (CBC) method provides for re-
  129.    synchronization when datagrams are lost.  For more explanation and
  130.    implementation information for Triple DES, see [Schneier95].
  131.  
  132.  
  133. 1.2.  Keys
  134.  
  135.    The secret DES-EDE3 key shared between the communicating parties is
  136.    effectively 168-bits long.  This key consists of three independent
  137.    56-bit quantities used by the DES algorithm.  Each of the three
  138.    56-bit subkeys is stored as a 64-bit (8 octet) quantity, with the
  139.    least significant bit of each octet used as a parity bit.
  140.  
  141.  
  142. 1.2.1.  Weak Keys
  143.  
  144.    DES has 64 known weak keys, including so-called semi-weak keys and
  145.    possibly weak keys [Schneier95, pp 280-282].  The odds of picking one
  146.    at random are low.
  147.  
  148.    For DES-EDE3, there is no requirement to reject weak or complementa-
  149.    tion keys.  Any weakness is obviated by the other keys.
  150.  
  151.  
  152. 1.2.2.  Key Management
  153.  
  154.    When manually configured, 192-bits (24 octets) are configured.  Keys
  155.    with incorrect parity SHOULD be be rejected.
  156.  
  157.    When dynamically configured via a key management protocol, 192-bits
  158.    (24 octets) are returned for each key.  The least significant bit of
  159.    each key octet is ignored (or set to parity when the implementation
  160.  
  161.  
  162.  
  163. Karn, Metzger & Simpson   expires in six months                 [Page 2]
  164. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  165.  
  166.  
  167.    requires).
  168.  
  169.  
  170. 1.3.  Initialization Vector
  171.  
  172.    This mode of DES-EDE3 requires an Initialization Vector (IV) that is
  173.    64-bits (8 octets) in length.
  174.  
  175.    Each datagram contains its own IV.  This IV is intended to be unique
  176.    for the lifetime of the secret DES-EDE3 session-keys.
  177.  
  178.    When manually configured, the 64-bit IV is generated from the 32-bit
  179.    Sequence Number field followed by (concatenated with) the bit-wise
  180.    complement of the same 32-bit value.
  181.  
  182.    When dynamically configured via a key management protocol, the 64-bit
  183.    IV is generated from the 32-bit SPI field followed by (concatenated
  184.    with) the 32-bit Sequence Number field.  The bit-wise complement of
  185.    the 32-bit Sequence Number value is XOR'd with the first 32-bits
  186.    (SPI).
  187.  
  188.    Security Notes:
  189.  
  190.       Including the IV in each datagram ensures that decryption of each
  191.       received datagram can be performed, even when some datagrams are
  192.       dropped, or datagrams are re-ordered in transit.
  193.  
  194.       The manually configured variant is required for backward compati-
  195.       bility.  It is appropriate when the associated SPI is unchanging.
  196.  
  197.       However, in a dynamic environment, the same data stream might be
  198.       sent with more than one SPI.  Including the changed SPI in the IV
  199.       generation prevents analysis based on common leading blocks.
  200.  
  201.       Using the Sequence Number provides an easy method for preventing
  202.       IV repetition, and is sufficiently robust for practical use with
  203.       the DES algorithm.  But, when used alone, cryptanalysis might be
  204.       aided by the rare serendipitous occurrence where a corresponding
  205.       bit position in the first DES block increments in exactly the same
  206.       fashion as the Sequence Number.
  207.  
  208.       No commonly used IP Protocol/Payloads exhibit this property.
  209.       Never-the-less, inclusion of the bit-wise complement ensures that
  210.       Sequence Number bit changes are reflected twice in the IV.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218. Karn, Metzger & Simpson   expires in six months                 [Page 3]
  219. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  220.  
  221.  
  222. 1.4.  Block Size
  223.  
  224.    The DES-EDE3 algorithm operates on blocks of 64-bits (8 octets).
  225.    This often requires padding after the end of the unencrypted payload
  226.    data.
  227.  
  228.    Both input and output result in the same number of octets.  This
  229.    facilitates in-place encryption and decryption.
  230.  
  231.  
  232. 1.5.  Performance
  233.  
  234.    As this specification requires "outer" chaining, it is not possible
  235.    to provide parallel computation for the same data stream.
  236.  
  237.    Phil Karn has tuned DES-EDE3-CBC software to achieve 6.2 Mbps with a
  238.    133 MHz Pentium.  Triple DES is approximately 2.5 times slower than
  239.    "single" DES, because inner permutations may be removed.  Other DES
  240.    speed estimates may be found at [Schneier95, page 279].
  241.  
  242.  
  243.  
  244. 2.  Payload Format
  245.  
  246.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.    |                Security Parameters Index (SPI)                |
  248.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.    |                        Sequence Number                        |
  250.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.    |                                                               |
  252.    ~                          Payload Data                         ~
  253.    |                                                               |
  254.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  255.              ... Padding           |  Pad Length   | Payload Type  |
  256.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  257.    |                                                               |
  258.    ~                    Authenticator (optional)                   ~
  259.    |                                                               |
  260.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  261.  
  262.  
  263.    Security Parameters Index (SPI)
  264.                     4 octets.  Identifies the Security Parameters for
  265.                     this datagram.  The value MUST NOT be zero.
  266.  
  267.    Sequence Number  4 octets.  Provides replay prevention [RFC-yyyy],
  268.                     and is used for calculating the IV, as described
  269.                     earlier.
  270.  
  271.  
  272.  
  273. Karn, Metzger & Simpson   expires in six months                 [Page 4]
  274. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  275.  
  276.  
  277.                     The value begins at one, unless another value is
  278.                     specified by the key management mechanism.
  279.  
  280.                     The value SHOULD NOT repeat during the lifetime of
  281.                     the encryption session-key.  This means that the
  282.                     session-key SHOULD be changed at least as frequently
  283.                     as 2**32 datagrams.
  284.  
  285.    Payload Data     one or more octets.
  286.  
  287.                     Prior to encryption and after decryption, this field
  288.                     begins with the IP Protocol/Payload header specified
  289.                     in the Payload Type field.  Note that in the case of
  290.                     IP-in-IP encapsulation (Payload Type 4), this will
  291.                     be another IP header.
  292.  
  293.    Padding          zero or more octets.
  294.  
  295.                     Prior to encryption, this field is filled with a
  296.                     series of integer values (beginning with zero), to
  297.                     align the Pad Length and Payload Type fields at the
  298.                     end of an eight octet boundary (counted from the
  299.                     beginning of the Payload Data).
  300.  
  301.                     After decryption, it is examined for a valid series
  302.                     of integer values.
  303.  
  304.                     This field is opaque.  That is, the value is set
  305.                     prior to encryption, and is examined only after
  306.                     decryption.
  307.  
  308.    Pad Length       1 octet.  Indicates the size of the Padding field.
  309.                     It does not include the Pad Length and Payload Type
  310.                     fields.  The value typically ranges from 0 to 7, but
  311.                     may be up to 255 to permit hiding of the actual data
  312.                     length.
  313.  
  314.                     This field is opaque.  That is, the value is set
  315.                     prior to encryption, and is examined only after
  316.                     decryption.
  317.  
  318.    Payload Type     1 octet.  Indicates the contents of the Payload Data
  319.                     field, using the IP Protocol/Payload value.  Up-to-
  320.                     date values of the IP Protocol/Payload are specified
  321.                     in the most recent "Assigned Numbers" [RFC-1700].
  322.  
  323.                     This field is opaque.  That is, the value is set
  324.                     prior to encryption, and is examined only after
  325.  
  326.  
  327.  
  328. Karn, Metzger & Simpson   expires in six months                 [Page 5]
  329. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  330.  
  331.  
  332.                     decryption.
  333.  
  334.                     For example, when encrypting an entire IP datagram
  335.                     (Tunnel-Mode), this field will contain the value 4,
  336.                     indicating IP-in-IP encapsulation.
  337.  
  338.    Authenticator    zero or more octets.
  339.  
  340.                     This optional variable-length field contains an
  341.                     Integrity Check Value (ICV) computed over the ESP
  342.                     data after encryption, beginning with the SPI and
  343.                     ending with the Payload Type.  The length of the
  344.                     field depends upon the authentication function
  345.                     selected.
  346.  
  347.                     DES-EDE3-CBC does not provide integrity.  When the
  348.                     ESP data is not otherwise verified (externally using
  349.                     AH or internally by the payload itself), it is rec-
  350.                     ommended (but not required) that an ICV be provided
  351.                     here.  The details of such functions are outside the
  352.                     scope of this document.
  353.  
  354.  
  355.  
  356. 2.1.  Encryption
  357.  
  358.    Perform compression of the plaintext (when configured).
  359.  
  360.    Append zero or more octets of padding to the plaintext, to make its
  361.    modulo 8 length equal to 6.  The padding values begin with the value
  362.    0, and count up to the number of padding octets (zero relative).
  363.  
  364.    Append a Pad Length octet containing the number of padding octets
  365.    just added.
  366.  
  367.       For example, if the plaintext length is 41, the padding values are
  368.       0, 1, 2, 3, 4, and the following Pad Length is 5.
  369.  
  370.    Append a Payload Type octet containing the IP Protocol/Payload value
  371.    which identifies the protocol header that begins the payload.
  372.  
  373.    Provide an Initialization Vector (IV) of the form indicated by the
  374.    SPI.
  375.  
  376.    Encrypt the payload with DES-EDE3 in the outer CBC mode, producing a
  377.    ciphertext of the same length.
  378.  
  379.       Octets are mapped to DES blocks in network order (most significant
  380.  
  381.  
  382.  
  383. Karn, Metzger & Simpson   expires in six months                 [Page 6]
  384. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  385.  
  386.  
  387.       octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload corre-
  388.       sponds to bits 1-8 of the 64-bit DES input block, while octet 7
  389.       (modulo 8) corresponds to bits 57-64 of the DES input block.
  390.  
  391.    When configured, calculate and append the optional Authenticator.
  392.  
  393.    Construct an appropriate IP datagram for the target Destination, with
  394.    the indicated SPI, Sequence Number, and payload.
  395.  
  396.    The Total/Payload Length in the encapsulating IP Header reflects the
  397.    length of the encrypted data, plus the SPI,  Sequence Number,
  398.    padding, Pad Length, Payload Type, and optional Authenticator octets.
  399.  
  400.  
  401. 2.2.  Decryption
  402.  
  403.    The SPI field is removed and examined.  This is used as an index into
  404.    the local Security Parameter table to find the negotiated parameters
  405.    and decryption key.  If the SPI is invalid, then the payload is dis-
  406.    carded, and the "Bad SPI" error is indicated [RFC-xxxx].
  407.  
  408.    The Sequence Number field is removed and examined, and an appropriate
  409.    64-bit IV value is constructed.
  410.  
  411.    When present, remove and verify the optional Authenticator.  If the
  412.    Authenticator is invalid, then the payload is discarded, and the
  413.    "Authentication Failed" error is indicated [RFC-xxxx].
  414.  
  415.    If the length of the data to be decrypted is not an integral multiple
  416.    of eight octets, then the payload is discarded, and the "Decryption
  417.    Failed" error is indicated [RFC-xxxx].
  418.  
  419.    The encrypted part of the payload is decrypted using DES-DED3 in the
  420.    outer CBC mode.
  421.  
  422.    The Payload Type is removed and examined.  If it is unrecognized,
  423.    then the payload is discarded, and the "Decryption Failed" error is
  424.    indicated [RFC-xxxx].
  425.  
  426.    The Pad Length is removed and examined.  If pad checking is config-
  427.    ured, and the padding octets are not the correct values for the Pad
  428.    Length, then the payload is discarded, and the "Decryption Failed"
  429.    error is indicated [RFC-xxxx].
  430.  
  431.    The specified number of pad octets are removed from the end of the
  432.    decrypted payload, and the IP Total/Payload Length is adjusted
  433.    accordingly.
  434.  
  435.  
  436.  
  437.  
  438. Karn, Metzger & Simpson   expires in six months                 [Page 7]
  439. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  440.  
  441.  
  442.    Perform decompression of the plaintext (when configured).  If it is
  443.    invalid, then the payload is discarded, and the "Decompression
  444.    Failed" error is indicated [RFC-xxxx].
  445.  
  446.    The IP Header(s) and the remaining portion of the decrypted payload
  447.    are passed to the protocol processing routine specified by the Pay-
  448.    load Type field.
  449.  
  450.  
  451. Operational Considerations
  452.  
  453.    When used with manual keying, the specification provides only a few
  454.    configurable parameters.
  455.  
  456.    SPI
  457.       Configured SPIs are in the range 1 to 255.
  458.  
  459.    SPI LifeTime (SPILT)
  460.       Manually configured LifeTimes are generally measured in days,
  461.       while dynamic LifeTimes are specified in seconds.
  462.  
  463.       Default: 2,764,800 seconds (32 days).
  464.       Maximum: implementation dependent.
  465.  
  466.  
  467.    Pad Check
  468.       Some earlier implementations used random pad values.
  469.  
  470.       Default: Off.
  471.  
  472.  
  473.    Key
  474.       Three 56-bit keys are configured as a single 192-bit quantity,
  475.       with appropriate parity included.
  476.  
  477.    Each party configures a list of known SPIs and symmetric secret-keys.
  478.  
  479.    In addition, each party configures local policy that determines what
  480.    access (if any) is granted to the holder of a particular SPI.  For
  481.    example, a party might allow FTP, but prohibit Telnet.  Such consid-
  482.    erations are outside the scope of this document.
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493. Karn, Metzger & Simpson   expires in six months                 [Page 8]
  494. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  495.  
  496.  
  497. Security Considerations
  498.  
  499.    Users need to understand that the quality of the security provided by
  500.    this specification depends completely on the strength of the Triple
  501.    DES algorithm, the correctness of that algorithm's implementation,
  502.    the security of the key management mechanism and its implementation,
  503.    the strength of the key [CN94], and upon the correctness of the
  504.    implementations in all of the participating nodes.
  505.  
  506.    It was originally thought that DES might be a group, but it has been
  507.    demonstrated that it is not [CW92].  Since DES is not a group, compo-
  508.    sition of multiple rounds of DES is not equivalent to simply using
  509.    DES with a different key.
  510.  
  511.    Triple DES with independent keys is not, as naively might be
  512.    expected, as difficult to break by brute force as a cryptosystem with
  513.    three times the keylength.  A space/time tradeoff has been shown
  514.    which can brute-force break triple block encryptions in the time
  515.    naively expected for double encryption [MH81].
  516.  
  517.    However, 2DES can be broken with a meet-in-the-middle attack, without
  518.    significantly more complexity than breaking DES requires [ibid], so
  519.    DES-EDE3 with independant keys is actually needed to provide this
  520.    level of security.  An attack on DES-EDE3 using two independent keys
  521.    that is somewhat (sixteen times) faster than any known for indepen-
  522.    dent keys has been shown [OW91].
  523.  
  524.    The cut and paste splicing attack described by [Bell95, Bell96]
  525.    exploits the nature of all Cipher Block Chaining algorithms.  When a
  526.    block is damaged in transmission, on decryption both it and the fol-
  527.    lowing block will be garbled by the decryption process, but all sub-
  528.    sequent blocks will be decrypted correctly.  If an attacker has
  529.    legitimate access to the same key, this feature can be used to insert
  530.    or replay previously encrypted data of other users of the same
  531.    engine, revealing the plaintext.  The usual (ICMP, TCP, UDP) trans-
  532.    port checksum can detect this attack, but on its own is not consid-
  533.    ered cryptographically strong.  In this situation, user or connection
  534.    oriented integrity checking is needed [RFC-1826].
  535.  
  536.    The padding bytes have a predictable value.  They provide a small
  537.    measure of tamper detection on their own block and the previous block
  538.    in CBC mode.  This makes it somewhat harder to perform splicing
  539.    attacks, and avoids a possible covert channel.  This small amount of
  540.    known plaintext does not create any problems for modern ciphers.
  541.  
  542.    Although it is widely believed that DES-EDE3 is substantially
  543.    stronger than DES, as it is less amenable to brute force attack, it
  544.    should be noted that real cryptanalysis of DES-EDE3 might not use
  545.  
  546.  
  547.  
  548. Karn, Metzger & Simpson   expires in six months                 [Page 9]
  549. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  550.  
  551.  
  552.    brute force methods at all.  Instead, it might be performed using
  553.    variants on differential [BS93] or linear [Matsui94] cryptanalysis.
  554.    It should also be noted that no encryption algorithm is permanently
  555.    safe from brute force attack, because of the increasing speed of mod-
  556.    ern computers.
  557.  
  558.    As with all cryptosystems, those responsible for applications with
  559.    substantial risk when security is breeched should pay close attention
  560.    to developments in cryptography, and especially cryptanalysis, and
  561.    switch to other transforms should DES-EDE3 prove weak.
  562.  
  563.  
  564. Change History
  565.  
  566.    Changes from RFC-1851:
  567.  
  568.    Additional explanation of IV calculation.  Inclusion of SPI in IV
  569.    calculation improves IV uniqueness over multiple sessions.
  570.  
  571.    Replaced erroneous text about parallel computation.
  572.  
  573.    Updated performance estimates.
  574.  
  575.    IV field renamed to Sequence.  Only one size is supported.
  576.  
  577.    Clarified to specify "outer" CBC, as originally intended.
  578.  
  579.    Padding is a known series of integers, and is checked upon receipt.
  580.  
  581.    Added compression steps.
  582.  
  583.    Added authentication steps.
  584.  
  585.    Added operational parameters section.
  586.  
  587.    Updated references.
  588.  
  589.    Updated contacts.
  590.  
  591.    Minor editorial changes.
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603. Karn, Metzger & Simpson   expires in six months                [Page 10]
  604. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  605.  
  606.  
  607. Acknowledgements
  608.  
  609.    The basic field naming and layout is based on "swIPe" [IBK93, IB93].
  610.    Additional details follow [RFC-zzzz].
  611.  
  612.    Some of the text of this specification was derived from work by Ran-
  613.    dall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
  614.  
  615.    Phil Karn provided the original Encryption and Decryption text, and
  616.    was the motivator and founding member of the IP Security Working
  617.    Group.
  618.  
  619.    Perry Metzger provided the original Security Considerations text,
  620.    some of which is distributed throughout the document.
  621.  
  622.    William Allen Simpson was responsible for the name and semantics of
  623.    the SPI, the IV calculation technique(s), editing and formatting.
  624.  
  625.    The use of known padding values was suggested in various forms by
  626.    Robert Baldwin, Phil Karn, and David Wagner.  This specification uses
  627.    Self-Describing-Padding [RFC-1570].
  628.  
  629.    Steve Bellovin, Angelos Keromytis, and Rodney Thayer provided useful
  630.    critiques of earlier versions of this draft.
  631.  
  632.  
  633. References
  634.  
  635.    [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
  636.             Strong Integrity", Presentation at the 32nd Internet Engi-
  637.             neering Task Force, Danvers Massachusetts, April 1995.
  638.  
  639.    [Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols",
  640.             Proceedings of the Sixth Usenix Security Symposium, July
  641.             1996.
  642.  
  643.    [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
  644.             the Data Encryption Standard", Berlin: Springer-Verlag,
  645.             1993.
  646.  
  647.    [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
  648.             Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
  649.             253-280, July 1994.
  650.  
  651.    [CW92]   Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a
  652.             Group", Advances in Cryptology -- Crypto '92 Proceedings,
  653.             Berlin: Springer-Verlag, 1993, pp 518-526.
  654.  
  655.  
  656.  
  657.  
  658. Karn, Metzger & Simpson   expires in six months                [Page 11]
  659. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  660.  
  661.  
  662.    [FIPS-46]
  663.             US National Bureau of Standards, "Data Encryption Standard",
  664.             Federal Information Processing Standard (FIPS) Publication
  665.             46, January 1977.
  666.  
  667.    [FIPS-46-1]
  668.             US National Bureau of Standards, "Data Encryption Standard",
  669.             Federal Information Processing Standard (FIPS) Publication
  670.             46-1, January 1988.
  671.  
  672.    [FIPS-74]
  673.             US National Bureau of Standards, "Guidelines for Implement-
  674.             ing and Using the Data Encryption Standard", Federal Infor-
  675.             mation Processing Standard (FIPS) Publication 74, April
  676.             1981.
  677.  
  678.    [FIPS-81]
  679.             US National Bureau of Standards, "DES Modes of Operation"
  680.             Federal Information Processing Standard (FIPS) Publication
  681.             81, December 1980.
  682.  
  683.    [IB93]   Ioannidis, J., and Blaze, M., "The Architecture and Imple-
  684.             mentation of Network-Layer Security Under Unix", Proceedings
  685.             of the Fourth Usenix Security Symposium, Santa Clara Cali-
  686.             fornia, October 1993.
  687.  
  688.    [IBK93]  Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network-
  689.             Layer Security for IP", Presentation at the 26th Internet
  690.             Engineering Task Force, Columbus Ohio, March 1993.
  691.  
  692.    [Matsui94]
  693.             Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
  694.             Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
  695.             Springer-Verlag, 1994.
  696.  
  697.    [MH81]   Merkle, R.C., and Hellman, M., "On the Security of Multiple
  698.             Encryption", Communications of the ACM, v. 24 n. 7, 1981,
  699.             pp. 465-467.
  700.  
  701.    [OW91]   van Oorschot, P.C., and Weiner, M.J.  "A Known-Plaintext
  702.             Attack on Two-Key Triple Encryption", Advances in Cryptology
  703.             -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991,
  704.             pp. 318-325.
  705.  
  706.    [RFC-1570]
  707.             Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994.
  708.  
  709.  
  710.  
  711.  
  712.  
  713. Karn, Metzger & Simpson   expires in six months                [Page 12]
  714. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  715.  
  716.  
  717.    [RFC-1700]
  718.             Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
  719.             1700, USC/Information Sciences Institute, October 1994.
  720.  
  721.    [RFC-1825]
  722.             Atkinson, R., "Security Architecture for the Internet Proto-
  723.             col", RFC-1825, Naval Research Laboratory, July 1995.
  724.  
  725.    [RFC-1826]
  726.             Atkinson, R., "IP Authentication Header", RFC-1826, Naval
  727.             Research Laboratory, July 1995.
  728.  
  729.    [RFC-1827]
  730.             Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
  731.             RFC-1827, Naval Research Laboratory, July 1995.
  732.  
  733.    [RFC-2119]
  734.             Bradner, S., "Key words for use in RFCs to Indicate Require-
  735.             ment Levels", BCP 14, Harvard University, March 1997.
  736.  
  737.    [RFC-xxxx]
  738.             Karn, P., and Simpson, W., "ICMP Security Failures Mes-
  739.             sages", draft-simpson-icmp-ipsec-fail-02.txt, work in
  740.             progress.
  741.  
  742.    [RFC-yyyy]
  743.             Simpson, W., and Wagner, D., "Internet Security Transform
  744.             Enhancements", draft-simpson-ipsec-enhancement-01.txt, work
  745.             in progress.
  746.  
  747.    [RFC-zzzz]
  748.             Karn, P., Metzger, P., and Simpson, W., "The ESP DES-CBC
  749.             Transform", draft-simpson-esp-des1-v2-00.txt, work in
  750.             progress.
  751.  
  752.    [Schneier95]
  753.             Schneier, B., "Applied Cryptography Second Edition", John
  754.             Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7.
  755.  
  756.    [Tuchman79]
  757.             Tuchman, W, "Hellman Presents No Shortcut Solutions to DES",
  758.             IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768. Karn, Metzger & Simpson   expires in six months                [Page 13]
  769. DRAFT                       ESP DES-EDE3-CBC                    May 1997
  770.  
  771.  
  772. Contacts
  773.  
  774.    Comments about this document should be discussed on the ipsec@tis.com
  775.    mailing list.
  776.  
  777.    Questions about this document can also be directed to:
  778.  
  779.       Phil Karn
  780.       Qualcomm, Inc.
  781.       6455 Lusk Blvd.
  782.       San Diego, California  92121-2779
  783.  
  784.           karn@qualcomm.com
  785.           karn@unix.ka9q.ampr.org (preferred)
  786.  
  787.  
  788.       Perry Metzger
  789.       Piermont Information Systems Inc.
  790.       160 Cabrini Blvd., Suite #2
  791.       New York, NY  10033
  792.  
  793.           perry@piermont.com
  794.  
  795.  
  796.       William Allen Simpson
  797.       DayDreamer
  798.       Computer Systems Consulting Services
  799.       1384 Fontaine
  800.       Madison Heights, Michigan  48071
  801.  
  802.           wsimpson@UMich.edu
  803.           wsimpson@GreenDragon.com (preferred)
  804.           bsimpson@MorningStar.com
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823. Karn, Metzger & Simpson   expires in six months                [Page 14]
  824.  
  825.  
  826.