home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2085 < prev    next >
Text File  |  1997-02-05  |  13KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         M. Oehler
  8. Request for Comments: 2085                                          NSA
  9. Category: Standards Track                                      R. Glenn
  10.                                                                    NIST
  11.                                                           February 1997
  12.  
  13.  
  14.            HMAC-MD5 IP Authentication with Replay Prevention
  15.  
  16. Status of This Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document describes a keyed-MD5 transform to be used in
  27.    conjunction with the IP Authentication Header [RFC-1826]. The
  28.    particular transform is based on [HMAC-MD5].  An option is also
  29.    specified to guard against replay attacks.
  30.  
  31. Table of Contents
  32.  
  33.    1.  Introduction...................................................1
  34.    1.1    Terminology.................................................2
  35.    1.2    Keys........................................................2
  36.    1.3    Data Size...................................................3
  37.    2.  Packet Format..................................................3
  38.    2.1    Replay Prevention...........................................4
  39.    2.2    Authentication Data Calculation.............................4
  40.    3.  Security Considerations........................................5
  41.    Acknowledgments....................................................5
  42.    References.........................................................6
  43.    Authors' Addresses.................................................6
  44.  
  45. 1. Introduction
  46.  
  47.    The Authentication Header (AH) [RFC-1826] provides integrity and
  48.    authentication for IP datagrams. The transform specified in this
  49.    document uses a keyed-MD5 mechanism [HMAC-MD5].  The mechanism uses
  50.    the (key-less) MD5 hash function [RFC-1321] which produces a message
  51.    digest. When combined with an AH Key, authentication data is
  52.    produced. This value is placed in the Authentication Data field of
  53.    the AH [RFC-1826]. This value is also the basis for the data
  54.    integrity service offered by the AH protocol.
  55.  
  56.  
  57.  
  58. Oehler & Glenn              Standards Track                     [Page 1]
  59.  
  60. RFC 2085                        HMAC-MD5                  February 1997
  61.  
  62.  
  63.    To provide protection against replay attacks, a Replay Prevention
  64.    field is included as a transform option.  This field is used to help
  65.    prevent attacks in which a message is stored and re-used later,
  66.    replacing or repeating the original.  The Security Parameters Index
  67.    (SPI) [RFC-1825] is used to determine whether this option is included
  68.    in the AH.
  69.  
  70.    Familiarity with the following documents is assumed: "Security
  71.    Architecture for the Internet Protocol" [RFC-1825], "IP
  72.    Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for
  73.    Message Authentication" [HMAC-MD5].
  74.  
  75.    All implementations that claim conformance or compliance with the IP
  76.    Authentication Header specification [RFC-1826] MUST implement this
  77.    HMAC-MD5 transform.
  78.  
  79. 1.1 Terminology
  80.  
  81.    In  this  document,  the  words  that  are  used  to   define   the
  82.    significance  of each particular requirement are usually capitalized.
  83.    These words are:
  84.  
  85.    - MUST
  86.  
  87.    This word or the adjective "REQUIRED" means that  the  item  is  an
  88.    absolute requirement of the specification.
  89.  
  90.    - SHOULD
  91.  
  92.    This word or the adjective "RECOMMENDED"  means  that  there  might
  93.    exist  valid reasons in particular circumstances to ignore this item,
  94.    but the full implications should be understood and the case carefully
  95.    weighed before taking a different course.
  96.  
  97. 1.2 Keys
  98.  
  99.    The "AH Key" is used as a shared secret between two communicating
  100.    parties.  The Key is not a "cryptographic key" as used in a
  101.    traditional sense. Instead, the AH key (shared secret) is hashed with
  102.    the transmitted data and thus, assures that an intervening party
  103.    cannot duplicate the authentication data.
  104.  
  105.    Even though an AH key is not a cryptographic key, the rudimentary
  106.    concerns of cryptographic keys still apply. Consider that the
  107.    algorithm and most of the data used to produce the output is known.
  108.    The strength of the transform lies in the singular mapping of the key
  109.    (which needs to be strong) and the IP datagram (which is known) to
  110.    the authentication data.  Thus, implementations should, and as
  111.  
  112.  
  113.  
  114. Oehler & Glenn              Standards Track                     [Page 2]
  115.  
  116. RFC 2085                        HMAC-MD5                  February 1997
  117.  
  118.  
  119.    frequently as possible, change the AH key. Keys need to be chosen at
  120.    random, or generated using a cryptographically strong pseudo-random
  121.    generator seeded with a random seed. [HMAC-MD5]
  122.  
  123.    All conforming and compliant implementations MUST support a key
  124.    length of 128 bits or less.  Implementations SHOULD support longer
  125.    key lengths as well.  It is advised that the key length be chosen to
  126.    be the length of the hash output, which is 128 bits for MD5.  For
  127.    other key lengths the following concerns MUST be considered.
  128.  
  129.    A key length of zero is prohibited and implementations MUST prevent
  130.    key lengths of zero from being used with this transform, since no
  131.    effective authentication could be provided by a zero-length key.
  132.    Keys having a length less than 128 bits are strongly discouraged as
  133.    it would decrease the security strength of the function.  Keys longer
  134.    than 128 bits are acceptable, but the extra length may not
  135.    significantly increase the function strength.  A longer key may be
  136.    advisable if the randomness of the key is suspect.  MD5 operates on
  137.    64-byte blocks.  Keys longer than 64-bytes are first hashed using
  138.    MD5.  The resulting hash is then used to calculate the authentication
  139.    data.
  140.  
  141. 1.3 Data Size
  142.  
  143.    MD5 produces a 128-bit value which is used as the authentication
  144.    data.  It is naturally 64 bit aligned and thus, does not need any
  145.    padding for machines with native double words.
  146.  
  147. 2. Packet Format
  148.  
  149.      +---------------+---------------+---------------+---------------+
  150.      | Next Header   | Length        |           RESERVED            |
  151.      +---------------+---------------+---------------+---------------+
  152.      |                              SPI                              |
  153.      +---------------+---------------+---------------+---------------+
  154.      |                     Replay Prevention                         |
  155.      |                                                               |
  156.      +---------------+---------------+---------------+---------------+
  157.      |                                                               |
  158.      +                     Authentication Data                       |
  159.      |                                                               |
  160.      +---------------+---------------+---------------+---------------+
  161.       1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
  162.  
  163.    The Next Header, RESERVED, and SPI fields are specified in [RFC-
  164.    1826].  The Length field is the length of the Replay Prevention field
  165.    and the Authentication Data in 32-bit words.
  166.  
  167.  
  168.  
  169.  
  170. Oehler & Glenn              Standards Track                     [Page 3]
  171.  
  172. RFC 2085                        HMAC-MD5                  February 1997
  173.  
  174.  
  175. 2.1 Replay Prevention
  176.  
  177.    The Replay Prevention field is a 64-bit value used to guarantee that
  178.    each packet exchanged between two parties is different.  Each IPsec
  179.    Security Association specifies whether Replay Prevention is used for
  180.    that Security Association.  If Replay Prevention is NOT in use, then
  181.    the Authentication Data field will directly follow the SPI field.
  182.  
  183.    The 64-bit field is an up counter starting at a value of 1.
  184.  
  185.    The secret shared key must not be used for a period of time that
  186.    allows the counter to wrap, that is, to transmit more than 2^64
  187.    packets using a single key.
  188.  
  189.    Upon receipt, the replay value is assured to be increasing.  The
  190.    implementation may accept out of order packets. The number of packets
  191.    to accept out of order is an implementation detail. If an "out of
  192.    order window" is supported, the implementation shall ensure that any
  193.    and all packets accepted out of order are guaranteed not to have
  194.    arrived before. That is, the implementation will accept any packet at
  195.    most once.
  196.  
  197.    When the destination address is a multicast address, replay
  198.    protection is in use, and more than one sender is sharing the same
  199.    IPsec Security Association to that multicast destination address,
  200.    then Replay Protection SHOULD NOT be enabled.  When replay protection
  201.    is desired for a multicast session having multiple senders to the
  202.    same multicast destination address, each sender SHOULD have its own
  203.    IPsec Security Association.
  204.  
  205.    [ESP-DES-MD5] provides example code that implements a 32 packet
  206.    replay window and a test routine to show how it works.
  207.  
  208. 2.2 Authentication Data Calculation
  209.  
  210.    The authentication data is the output of the authentication algorithm
  211.    (MD5).  This value is calculated over the entire IP datagram. Fields
  212.    within the datagram that are variant during transit and the
  213.    authentication data field itself, must contain all zeros prior to the
  214.    computation [RFC-1826].  The Replay Prevention field if present, is
  215.    included in the calculation.
  216.  
  217.    The definition and reference implementation of MD5 appears in [RFC-
  218.    1321].  Let 'text' denote the data to which HMAC-MD5 is to be applied
  219.    and K be the message authentication secret key shared by the parties.
  220.    If K is longer than 64-bytes it MUST first be hashed using MD5.  In
  221.    this case, K is the resulting hash.
  222.  
  223.  
  224.  
  225.  
  226. Oehler & Glenn              Standards Track                     [Page 4]
  227.  
  228. RFC 2085                        HMAC-MD5                  February 1997
  229.  
  230.  
  231.    We define two fixed and different strings ipad and opad as follows
  232.    (the 'i' and 'o' are mnemonics for inner and outer):
  233.  
  234.              ipad = the byte 0x36 repeated 64 times
  235.              opad = the byte 0x5C repeated 64 times.
  236.    To compute HMAC-MD5 over the data `text' we perform
  237.              MD5(K XOR opad, MD5(K XOR ipad, text))
  238.    Namely,
  239.     (1) append zeros to the end of K to create a 64 byte string
  240.         (e.g., if K is of length 16 bytes it will be appended with 48
  241.         zero bytes 0x00)
  242.     (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step
  243.         (1) with ipad
  244.     (3) append the data stream 'text' to the 64 byte string resulting
  245.         from step (2)
  246.     (4) apply MD5 to the stream generated in step (3)
  247.     (5) XOR (bitwise exclusive-OR) the 64 byte string computed in
  248.         step (1) with opad
  249.     (6) append the MD5 result from step (4) to the 64 byte string
  250.         resulting from step (5)
  251.     (7) apply MD5 to the stream generated in step (6) and output
  252.         the result
  253.  
  254.       This computation is described in more detail, along with example
  255.       code and performance improvements, in [HMAC-MD5]. Implementers
  256.       should consult [HMAC-MD5] for more information on this technique
  257.       for keying a cryptographic hash function.
  258.  
  259. 3. Security Considerations
  260.  
  261.    The security provided by this transform is based on the strength of
  262.    MD5, the correctness of the algorithm's implementation, the security
  263.    of the key management mechanism and its implementation, the strength
  264.    of the associated secret key, and upon the correctness of the
  265.    implementations in all of the participating systems.  [HMAC-MD5]
  266.    contains a detailed discussion on the strengths and weaknesses of
  267.    MD5.
  268.  
  269. Acknowledgments
  270.  
  271.    This document is largely based on text written by Hugo Krawczyk.  The
  272.    format used was derived from work by William Simpson and Perry
  273.    Metzger.  The text on replay prevention is derived directly from work
  274.    by Jim Hughes.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Oehler & Glenn              Standards Track                     [Page 5]
  283.  
  284. RFC 2085                        HMAC-MD5                  February 1997
  285.  
  286.  
  287. References
  288.  
  289.    [RFC-1825]    Atkinson, R., "Security Architecture for the Internet
  290.                  Protocol", RFC 1852, Naval Research Laboratory,
  291.                  July 1995.
  292.    [RFC-1826]    Atkinson, R., "IP Authentication Header",
  293.                  RFC 1826, August 1995.
  294.    [RFC-1828]    Metzger, P., and W. Simpson, "IP Authentication using
  295.                  Keyed MD5", RFC 1828, August 1995.
  296.    [RFC-1321]    Rivest, R., "The MD5 Message-Digest Algorithm",
  297.                  RFC 1321, April 1992.
  298.    [HMAC-MD5]    Krawczyk, H., Bellare, M., and R. Canetti,
  299.                  "HMAC: Keyed-Hashing for Message Authentication",
  300.                  RFC 2104, February 1997.
  301.    [ESP-DES-MD5] Hughes, J., "Combined DES-CBC, MD5, and Replay
  302.                  Prevention Security Transform", Work in Progress.
  303.  
  304. Authors' Addresses
  305.  
  306.    Michael J. Oehler
  307.    National Security Agency
  308.    Atn: R23, INFOSEC Research and Development
  309.    9800 Savage Road
  310.    Fort Meade, MD 20755
  311.  
  312.    EMail: mjo@tycho.ncsc.mil
  313.  
  314.  
  315.    Robert Glenn
  316.    NIST
  317.    Building 820, Room 455
  318.    Gaithersburg, MD 20899
  319.  
  320.    EMail: rob.glenn@nist.gov
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Oehler & Glenn              Standards Track                     [Page 6]
  339.  
  340.