home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-ah-hmac-md5-96-00.txt < prev    next >
Text File  |  1997-03-21  |  16KB  |  448 lines
  1.  
  2.  
  3. Network Working Group                                   M. Oehler (NSA)
  4.                                                         R. Glenn (NIST)
  5. Internet Draft                                          March 20, 1997
  6.  
  7.  
  8.           HMAC-MD5-96 IP Authentication with Replay Prevention
  9.                 <draft-ietf-ipsec-ah-hmac-md5-96-00.txt>
  10.  
  11.  
  12. Status of This Memo
  13.  
  14.    Distribution of this memo is unlimited.
  15.  
  16.    This document is an Internet-Draft.  Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups.  Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet Drafts are draft documents valid for a maximum of six
  22.    months, and may be updated, replaced, or obsoleted by other documents
  23.    at any time.  It is not appropriate to use Internet Drafts as
  24.    reference material, or to cite them other than as a ``working draft''
  25.    or ``work in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  29.    Directories on:
  30.  
  31.       ftp.is.co.za (Africa)
  32.       nic.nordu.net (Europe)
  33.       ds.internic.net (US East Coast)
  34.       ftp.isi.edu (US West Coast)
  35.       munnari.oz.au (Pacific Rim)
  36.  
  37. Abstract
  38.  
  39.    This document describes a keyed-MD5 transform to be used in
  40.    conjunction with the IP Authentication Header [RFC-1826]. The
  41.    particular transform is based on [RFC-2104].  A replay prevention
  42.    field is also specified.
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Oehler, Glenn                                                   [Page 1]
  55.  
  56. INTERNET DRAFT               March 20, 1997       Expires September 1997
  57.  
  58.  
  59. Contents
  60.  
  61.    1.  Introduction...................................................3
  62.    1.1    Terminology.................................................3
  63.    1.2    Keys........................................................4
  64.    1.3    Data Size...................................................4
  65.    2.  Packet Format..................................................5
  66.    2.1    Replay Prevention...........................................5
  67.    2.2    Authentication Data Calculation.............................6
  68.    3.  Security Considerations........................................7
  69.    Acknowledgments....................................................7
  70.    References.........................................................8
  71.    Authors' Addresses.................................................8
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Oehler, Glenn                                                   [Page 2]
  111.  
  112. INTERNET DRAFT               March 20, 1997       Expires September 1997
  113.  
  114.  
  115. 1. Introduction
  116.  
  117.    The Authentication Header (AH) [RFC-1826] provides integrity and
  118.    authentication for IP datagrams. The transform specified in this
  119.    document uses a keyed-MD5 mechanism [RFC-2104].  The mechanism uses
  120.    the (key-less) MD5 hash function [RFC-1321] which produces a message
  121.    digest. When combined with an AH Key, Authentication Data is
  122.    produced. This value is placed in the Authentication Data field of
  123.    the AH [RFC-1826]. This value is also the basis for the data
  124.    integrity service offered by the AH protocol.
  125.  
  126.    To provide protection against replay attacks, a Replay Prevention
  127.    field is specified as a transform option.  This field is used to help
  128.    prevent attacks in which a message is stored and re-used later,
  129.    replacing or repeating the original.  The Security Parameters Index
  130.    (SPI) [RFC-1825] is used to determine whether this option is included
  131.    in the AH.
  132.  
  133.    Familiarity with the following documents is assumed: "Security
  134.    Architecture for the Internet Protocol" [RFC-1825], "IP
  135.    Authentication Header" [RFC-1826], and "HMAC: Keyed Hashing for
  136.    Message Authentication" [RFC-2104].
  137.  
  138.    All implementations that claim conformance or compliance with the IP
  139.    Authentication Header specification [RFC-1826] MUST implement this
  140.    HMAC-MD5-96 transform.
  141.  
  142. 1.1 Terminology
  143.  
  144.    In  this  document,  the  words  that  are  used  to   define   the
  145.    significance  of each particular requirement are usually capitalized.
  146.    These words are:
  147.  
  148.    - MUST
  149.  
  150.    This word or the adjective "REQUIRED" means that  the  item  is  an
  151.    absolute requirement of the specification.
  152.  
  153.    - SHOULD
  154.  
  155.    This word or the adjective "RECOMMENDED"  means  that  there  might
  156.    exist  valid reasons in particular circumstances to ignore this item,
  157.    but the full implications should be understood and the case carefully
  158.    weighed before taking a different course.
  159.  
  160.    - MAY
  161.  
  162.    This word or the adjective "OPTIONAL" means that this item is truly
  163.  
  164.  
  165.  
  166. Oehler, Glenn                                                   [Page 3]
  167.  
  168. INTERNET DRAFT               March 20, 1997       Expires September 1997
  169.  
  170.  
  171.    optional.  One vendor might choose to include the item because a
  172.    particular marketplace requires it or because it enhances the product,
  173.    for example; another vendor may omit the same item.
  174.  
  175.    For the purpose of this specification, the terms conformance and
  176.    compliance are synonymous.
  177.  
  178. 1.2 Keys
  179.  
  180.    The "AH Key" is used as a shared secret between two communicating
  181.    parties.  The Key is not a "cryptographic key" as used in a
  182.    traditional sense. Instead, the AH key (shared secret) is hashed with
  183.    the transmitted data and thus, assures that an intervening party
  184.    cannot duplicate the Authentication Data.
  185.  
  186.    Even though an AH key is not a cryptographic key, the rudimentary
  187.    concerns of cryptographic keys still apply. Consider that the
  188.    algorithm and most of the data used to produce the output is known.
  189.    The strength of the transform lies in the singular mapping of the key
  190.    (which needs to be strong) and the IP datagram (which is known) to
  191.    the Authentication Data.  Thus, implementations should, and as
  192.    frequently as possible, change the AH key. Keys need to be chosen at
  193.    random, or generated using a cryptographically strong pseudo-random
  194.    generator seeded with a random seed. [RFC-2104]
  195.  
  196.    All conforming and compliant implementations MUST support a key
  197.    length of 128 bits or less.  Implementations SHOULD support longer
  198.    key lengths as well.  It is advised that the key length be chosen to
  199.    be the length of the hash algorithm output, which is 128 bits for
  200.    MD5.  For other key lengths the following concerns MUST be
  201.    considered.
  202.  
  203.    A key length of zero is prohibited and implementations MUST prevent
  204.    key lengths of zero from being used with this transform, since no
  205.    effective authentication could be provided by a zero-length key.
  206.    Keys having a length less than 128 bits are strongly discouraged as
  207.    it would decrease the security strength of the function.  Keys longer
  208.    than 128 bits are acceptable, but the extra length may not
  209.    significantly increase the function strength.  MD5 operates on 64-
  210.    byte blocks.  Keys longer than 64-bytes are first hashed using MD5.
  211.    The resulting hash is then used to calculate the Authentication Data.
  212.  
  213. 1.3 Data Size
  214.  
  215.    HMAC-MD5 produces a 128-bit value.  HMAC-MD5-96 uses the first or
  216.    left most 96 bits as the Authentication Data.  This procedure is
  217.    known as truncation.  In the case of this transform, truncation is
  218.    used to help maintain 64-bit packet header alignment, eliminate
  219.  
  220.  
  221.  
  222. Oehler, Glenn                                                   [Page 4]
  223.  
  224. INTERNET DRAFT               March 20, 1997       Expires September 1997
  225.  
  226.  
  227.    unnecessary overhead, and potentially provide stronger
  228.    authentication.  [RFC-2104] provides more information on the
  229.    advantages and disadvantages of truncation.
  230.  
  231. 2. Packet Format
  232.  
  233.         +---------------+---------------+---------------+---------------+
  234.         | Next Header   | Length        |           RESERVED            |
  235.         +---------------+---------------+---------------+---------------+
  236.         |                              SPI                              |
  237.         +---------------+---------------+---------------+---------------+
  238.         |                     Replay Prevention                         |
  239.         +---------------+---------------+---------------+---------------+
  240.         |                                                               |
  241.         +                                                               +
  242.         |                     Authentication Data                       |
  243.         +                                                               +
  244.         |                                                               |
  245.         +---------------+---------------+---------------+---------------+
  246.          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
  247.  
  248.    The Next Header, RESERVED, and SPI fields are specified in [RFC-
  249.    1826].  The Length field is the length of the Replay Prevention field
  250.    and the Authentication Data in 32-bit words.  The Length field will
  251.    always be set to 4 (128 bits) for HMAC-MD5-96.
  252.  
  253. 2.1 Replay Prevention
  254.  
  255.    The Replay Prevention field is a 32-bit value used to guarantee that
  256.    each packet exchanged between two parties is different.  Each IPsec
  257.    Security Association specifies whether Replay Prevention is used for
  258.    that Security Association.  The Replay Prevention field is always
  259.    included in the calculation of the Authentication Data. If Replay
  260.    Prevention is NOT in use, the 32-bit value is set to 0, included in
  261.    the calculation of the Authentication Data, and ignored upon receipt
  262.    with regard to checking for replay.  This field is used to help
  263.    prevent attacks in which a message is stored and re-used later,
  264.    replacing or repeating the original.
  265.  
  266.    Replay Prevention SHOULD be implemented.  If Replay Prevention is not
  267.    implemented, the 32-bit field remains are part of the AH and is
  268.    treated as if Replay Prevention is NOT in use (i.e. the 32-bit value
  269.    is set to 0, included in the calculation of the Authentication Data,
  270.    and ignored upon receipt with regard to checking for replay.
  271.  
  272.    The 32-bit field is an up counter starting at a value of 1.
  273.  
  274.    The secret shared key MUST NOT be used for a period of time that
  275.  
  276.  
  277.  
  278. Oehler, Glenn                                                   [Page 5]
  279.  
  280. INTERNET DRAFT               March 20, 1997       Expires September 1997
  281.  
  282.  
  283.    allows the counter to wrap, that is, to transmit more than 2^32
  284.    packets using a single key.
  285.  
  286.    Upon receipt, the replay value is assured to be increasing.  An
  287.    implementation MAY accept out of order packets.  If an "out of order
  288.    window" is supported, an implementation MUST guarantee that any and
  289.    all packets accepted out of order have not arrived before. That is,
  290.    an implementation MUST accept any packet, at most, once.  The size of
  291.    the window is a negotiated value specified by the IPsec Security
  292.    Association.
  293.  
  294.    [ESP-DES-MD5] provides more information on negotiated windows sizes,
  295.    example code that implements a 32 packet replay window, and a test
  296.    routine to show how it could be implemented.
  297.  
  298.    When the destination address is a multicast address and more than one
  299.    sender is sharing the same IPsec Security Association to that
  300.    multicast destination address, then Replay Prevention SHOULD NOT be
  301.    enabled.  When Replay Prevention is desired for a multicast session
  302.    having multiple senders to the same multicast destination address,
  303.    each sender SHOULD have its own IPsec Security Association.
  304.  
  305. 2.2 Authentication Data Calculation
  306.  
  307.    The Authentication Data is the output of the MD5 authentication
  308.    algorithm. This value is calculated over the entire IP datagram.
  309.    Fields within the datagram that are variant during transit and the
  310.    Authentication Data field itself, must contain all zeros prior to the
  311.    computation [RFC-1826].  The Replay Prevention field, used or not, is
  312.    always included in the calculation.
  313.  
  314.    The definition and reference implementation of MD5 appears in [RFC-
  315.    1321].  Let 'text' denote the data to which HMAC-MD5-96 is to be
  316.    applied and K be the message authentication secret key shared by the
  317.    parties.  If K is longer than 64-bytes it MUST first be hashed using
  318.    MD5.  In this case, K is the resulting hash.
  319.  
  320.    We define two fixed and different strings ipad and opad as follows
  321.    (the 'i' and 'o' are mnemonics for inner and outer):
  322.  
  323.       ipad = the byte 0x36 repeated 64 times
  324.       opad = the byte 0x5C repeated 64 times.
  325.  
  326.    To compute HMAC-MD5 over the data `text' we perform
  327.  
  328.       MD5(K XOR opad, MD5(K XOR ipad, text))
  329.  
  330.    The result of which is truncated to 96 bits (retaining the left most
  331.  
  332.  
  333.  
  334. Oehler, Glenn                                                   [Page 6]
  335.  
  336. INTERNET DRAFT               March 20, 1997       Expires September 1997
  337.  
  338.  
  339.    bits) to produce HMAC-MD5-96.
  340.  
  341.    The calculation of the Authentication Data consists of the following
  342.    steps:
  343.  
  344.    (1) append zeros to the end of K to create a 64 byte string (e.g., if
  345.        K is of length 16 bytes it will be appended with 48 zero bytes 0x00)
  346.    (2) XOR (bitwise exclusive-OR) the 64 byte string computed in
  347.        step (1) with ipad
  348.    (3) append the data stream 'text' to the 64 byte string resulting
  349.        from step (2)
  350.    (4) apply MD5 to the stream generated in step (3)
  351.    (5) XOR (bitwise exclusive-OR) the 64 byte string computed in
  352.        step (1) with opad
  353.    (6) append the MD5 result from step (4) to the 64 byte string
  354.        resulting from step (5)
  355.    (7) apply MD5 to the stream generated in step (6)
  356.    (8) use the left most 96 bits of the result obtained in (7) as the final
  357.        result
  358.  
  359.    A similar computation is described in more detail, along with example
  360.    code and performance improvements, in [RFC-2104]. Implementers should
  361.    consult [RFC-2104] for more information on this technique for keying
  362.    a cryptographic hash function.
  363.  
  364. 3. Security Considerations
  365.  
  366.    The security provided by this transform is based on the strength of
  367.    MD5, the correctness of the algorithm's implementation, the security
  368.    of the key management mechanism and its implementation, the strength
  369.    of the associated secret key, and upon the correctness of the
  370.    implementations in all of the participating systems.  [RFC-2104]
  371.    contains a detailed discussion on the strengths and weaknesses of
  372.    HMAC algorithms. [HMAC-TESTS] contains test vectors and example code
  373.    to assist in verifying the correctness of HMAC-MD5 code.
  374.  
  375. Acknowledgments
  376.  
  377.    This document is largely based on text written by Hugo Krawczyk.  The
  378.    format used was derived from work by William Simpson and Perry
  379.    Metzger.  The text on replay prevention is derived from work by Jim
  380.    Hughes.
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Oehler, Glenn                                                   [Page 7]
  391.  
  392. INTERNET DRAFT               March 20, 1997       Expires September 1997
  393.  
  394.  
  395. References
  396.  
  397.  
  398.    [RFC-1825]    R. Atkinson, "Security Architecture for the Internet
  399.                  Protocol", RFC-1852, Naval Research Laboratory, July 1995.
  400.    [RFC-1826]    R. Atkinson, "IP Authentication Header",
  401.                  RFC-1826, August 1995.
  402.    [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
  403.                  RFC-1828, August 1995.
  404.    [RFC-1321]    R. Rivest, "The MD5 Message-Digest Algorithm",
  405.                  RFC-1321, April 1992.
  406.    [RFC-2104]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing
  407.                  for Message Authentication", RFC-2104, February, 1997.
  408.    [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention
  409.                  Security Transform", Internet Draft, September 1996.
  410.    [HMAC-TESTS]  P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
  411.                  Internet Draft, March 1997.
  412.  
  413. Authors' Addresses
  414.  
  415.    Michael J. Oehler
  416.    National Security Agency
  417.    Atn: R23, INFOSEC Research and Development
  418.    9800 Savage Road
  419.    Fort Meade, MD 20755
  420.  
  421.    mjo@tycho.ncsc.mil
  422.  
  423.    Robert Glenn
  424.    NIST
  425.    Building 820, Room 455
  426.    Gaithersburg, MD 20899
  427.  
  428.    rob.glenn@nist.gov
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. Oehler, Glenn                                                   [Page 8]
  447.  
  448.