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-sha-04.txt < prev    next >
Text File  |  1996-11-19  |  15KB  |  448 lines
  1.  
  2.  
  3. Network Working Group                                   S. Chang (NIST)
  4.                                                         R. Glenn (NIST)
  5.                                                         November 20, 1996
  6. Internet Draft
  7.  
  8.  
  9.            HMAC-SHA IP Authentication with Replay Prevention
  10.                  <draft-ietf-ipsec-ah-hmac-sha-04.txt>
  11.  
  12.  
  13. Status of This Memo
  14.  
  15.    Distribution of this memo is unlimited.
  16.  
  17.    This document is an Internet-Draft.  Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its Areas,
  19.    and its Working Groups.  Note that other groups may also distribute
  20.    working 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
  25.    reference material, or to cite them other than as a ``working draft''
  26.    or ``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. Abstract
  39.  
  40.    This document describes a keyed-SHA transform to be used in
  41.    conjunction with the IP Authentication Header [RFC-1826]. The
  42.    particular transform is based on [HMAC-MD5].  An option is also
  43.    specified to guard against replay attacks.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Chang, Glenn                                                    [Page 1]
  55.  
  56. INTERNET DRAFT             November 20, 1996            Expires May 1997
  57.  
  58.  
  59. Contents
  60.  
  61.    1.  Introduction...................................................3
  62.    1.1    Teminology..................................................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.    Acnowledgements....................................................7
  70.    References.........................................................7
  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. Chang, Glenn                                                    [Page 2]
  111.  
  112. INTERNET DRAFT             November 20, 1996            Expires May 1997
  113.  
  114.  
  115. 1. Introduction
  116.  
  117.    The IP Authentication Header (AH) provides integrity and
  118.    authentication for IP datagrams [RFC-1826]. The transform specified
  119.    in this document uses a keyed-SHA mechanism based on [HMAC-MD5].  The
  120.    mechanism uses the (key-less) SHA hash function [FIPS-180-1] which
  121.    produces a message digest. When combined with an AH Key,
  122.    authentication data is produced. This value is placed in the
  123.    Authentication Data field of the AH [RFC-1826]. This value is also
  124.    the basis for the data integrity service offered by the AH protocol.
  125.  
  126.    To provide protection against replay attacks, a Replay Prevention
  127.    field is included 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-MD5: Keyed-MD5 for
  136.    Message Authentication" [HMAC-MD5].
  137.  
  138.    All implementations that claim conformance or compliance with the IP
  139.    Authentication Header specification [RFC-1826] SHOULD implement this
  140.    HMAC-SHA 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.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Chang, Glenn                                                    [Page 3]
  167.  
  168. INTERNET DRAFT             November 20, 1996            Expires May 1997
  169.  
  170.  
  171. 1.2 Keys
  172.  
  173.    The AH Key is used as a shared secret between two communicating
  174.    parties.  The Key is not a cryptographic key as used in a traditional
  175.    sense. Instead, the AH key (shared secret) is hashed with the
  176.    transmitted data and thus, assures that an intervening party cannot
  177.    duplicate the authentication data.
  178.  
  179.    Even though an AH key is not a cryptographic key, the rudimentary
  180.    concerns of cryptographic keys still apply. Consider that the
  181.    algorithm and most of the data used to produce the output is known.
  182.    The strength of the transform lies in the singular mapping of the key
  183.    (which needs to be strong) and the IP datagram (which is known) to
  184.    the authentication data.  Thus, implementations should, and as
  185.    frequently as possible, change the AH key. Keys need to be chosen at
  186.    random, or generated using a cryptographically strong pseudo-random
  187.    generator seeded with a random seed. [HMAC-MD5]
  188.  
  189.    All conforming and compliant implementations MUST support a key
  190.    length of 160 bits or less.  Implementations SHOULD support longer
  191.    key lengths as well.  It is advised that the key length be chosen to
  192.    be the length of the hash output, which is 160 bits for SHA.  For
  193.    other key lengths the following concerns MUST be considered.
  194.  
  195.    A key length of zero is prohibited and implementations MUST prevent
  196.    key lengths of zero from being used with this transform, since no
  197.    effective authentication could be provided by a zero-length key.  SHA
  198.    operates on 64-byte blocks.  Keys longer than 64-bytes are first
  199.    hashed using SHA.  The resulting hash is then used to calculate the
  200.    authentication data.
  201.  
  202. 1.3 Data Size
  203.  
  204.    SHA generates a message digest of 160 bits. To maintain 64-bit word
  205.    alignment, all conforming and compliant implementations MUST include
  206.    the ability to pad the message digest to 192 bits as described in
  207.    this paragraph. Implementations MAY also include the ability to use
  208.    the 160 bit message digest without the pad when 64-bit alignment is
  209.    not required.  Padding is added by appending 32 zero bits to SHA
  210.    message digest.  The length of the Authentication Data, specified in
  211.    the Length field of the AH in 32-bit words, should include the
  212.    padding bits, if present.  Upon receipt, the value of the padded bits
  213.    MUST be zero and are otherwise ignored.
  214.  
  215. 2. Packet Format
  216.  
  217.         +---------------+---------------+---------------+---------------+
  218.         | Next Header   | Length        |           RESERVED            |
  219.  
  220.  
  221.  
  222. Chang, Glenn                                                    [Page 4]
  223.  
  224. INTERNET DRAFT             November 20, 1996            Expires May 1997
  225.  
  226.  
  227.         +---------------+---------------+---------------+---------------+
  228.         |                              SPI                              |
  229.         +---------------+---------------+---------------+---------------+
  230.         |                     Replay Prevention                         |
  231.         |                                                               |
  232.         +---------------+---------------+---------------+---------------+
  233.         |                                                               |
  234.         +                     Authentication Data                       |
  235.         |                                                               |
  236.         +---------------+---------------+---------------+---------------+
  237.          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
  238.  
  239.    The Next Header, RESERVED, and SPI fields are specified in [RFC-
  240.    1826]. The Length field is the length of the Replay Prevention field
  241.    and the Authentication Data in 32-bit words.
  242.  
  243. 2.1 Replay Prevention
  244.  
  245.    The Replay Prevention field is a 64-bit value used to guarantee that
  246.    each packet exchanged between two parties is different. Each IPsec
  247.    Security Association specifies whether Replay Prevention is used for
  248.    that Security Association.  If Replay Prevention is NOT in use, then
  249.    the Authentication Data field will directly follow the SPI field.
  250.    This field is used to help prevent attacks in which a message is
  251.    stored and re-used later, replacing or repeating the original.
  252.  
  253.    The 64-bit field is an up counter starting at a value of 1.
  254.  
  255.    The secret shared key must not be used for a period of time that
  256.    allows the counter to wrap, that is, to transmit more than 2^64
  257.    packets using a single key.
  258.  
  259.    Upon receipt, the replay value is assured to be increasing.  The
  260.    implementation may accept out of order packets. The number of packets
  261.    to accept out of order is an implementation detail. If an "out of
  262.    order window" is supported, the implementation shall ensure that any
  263.    and all packets accepted out of order are guaranteed not to have
  264.    arrived before. That is, the implementation will accept any packet at
  265.    most once.
  266.  
  267.    When the destination address is a multicast address, replay
  268.    protection is in use, and more than one sender is sharing the same
  269.    IPsec Security Association to that multicast destination address,
  270.    then Replay Protection SHOULD NOT be enabled.  When replay protection
  271.    is desired for a multicast session having multiple senders to the
  272.    same multicast destination address, each sender SHOULD have its own
  273.    IPsec Security Association.
  274.  
  275.  
  276.  
  277.  
  278. Chang, Glenn                                                    [Page 5]
  279.  
  280. INTERNET DRAFT             November 20, 1996            Expires May 1997
  281.  
  282.  
  283.    [ESP-DES-MD5] provides example code that implements a 32 packet
  284.    replay window and a test routine to show how it works.
  285.  
  286. 2.2 Authentication Data Calculation
  287.  
  288.    The computation of the 160-bit SHA digest is described
  289.    in [FIPS-180-1].  The digest is calculated over
  290.    the entire IP datagram. Fields within the datagram that are variant
  291.    during transit and the authentication data field itself must contain
  292.    all zeros prior to the computation [RFC-1826].
  293.    The Replay Prevention field, if present, is included in the calculation.
  294.  
  295.    To compute HMAC-SHA over the data 'text', the following is calculated:
  296.  
  297.        SHA (K XOR opad, SHA (K XOR ipad, text))
  298.  
  299.    K denotes the secret key shared by the parties. If K is longer
  300.    than 64-bytes it MUST first be hashed using SHA.
  301.    In this case, K is the resulting hash.  The variables 'ipad', 'opad'
  302.    denote fixed strings for inner and outer padding respectively.
  303.    The two strings are:
  304.  
  305.        ipad = the byte 0x36 repeated 64 times,
  306.        opad = the byte 0x5C repeated 64 times.
  307.  
  308.    The calculation of the authentication data consists of the following steps:
  309.  
  310.    (1) append zeros to the end of K to create a 64 byte string (e.g., if K is
  311.        of length 20 bytes it will be appended with 44 zero bytes 0x00)
  312.    (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with
  313.        ipad
  314.    (3) concatenate to the 64 byte string resulting from step (2) the data
  315.        stream 'text'
  316.    (4) apply SHA to the stream generated in step (3)
  317.    (5) XOR the 64 byte string computed in step (1) with opad
  318.    (6) concatenate to the 64 byte string resulting from step (5) the SHA result
  319.        of step (4)
  320.    (7) apply SHA to the stream generated in step (6)
  321.    (8) The sender then zero pads the resulting hash to a 64-bit boundary
  322.        for word alignment.  IPv4 implemenations choosing not to pad will not
  323.        zero pad the resulting hash.  The receiver then compares the
  324.        generated 160-bit hash to the first 160-bits of authentication data
  325.        contained in the AH.
  326.  
  327.    A similar computation is described in more detail, along with example
  328.    code and performance improvements, in [HMAC-MD5].  Implementers
  329.    should consult [HMAC-MD5] for more information on this technique
  330.    for keying a cryptographic hash function.
  331.  
  332.  
  333.  
  334. Chang, Glenn                                                    [Page 6]
  335.  
  336. INTERNET DRAFT             November 20, 1996            Expires May 1997
  337.  
  338.  
  339. 3. Security Considerations
  340.  
  341.    The security provided by this transform is based on the strength of
  342.    SHA, the correctness of the algorithm's implementation, the security
  343.    of the key management mechanism and its implementation, the strength
  344.    of the associated secret key, and upon the correctness of the
  345.    implementations in all of the participating systems.
  346.  
  347.    At this time there are no known cryptographic attacks against SHA
  348.    [SCHNEIER].  The 160-bit digest makes SHA more resistant to brute
  349.    force attacks than MD4 and MD5 which produce a 128-bit digest.
  350.  
  351. Acknowledgments
  352.  
  353. This document is largely based on text written by Hugo Krawczyk.  The
  354. format used was derived from work by William Simpson and Perry Metzger.
  355. The text on replay prevention is derived directly from work by Jim
  356. Hughes.
  357.  
  358. References
  359.  
  360.  
  361.    [RFC-1825]    R. Atkinson, "Security Architecture for the Internet Protocol",
  362.                  RFC-1825, August 1995.
  363.    [RFC-1826]    R. Atkinson, "IP Authentication Header",
  364.                  RFC-1826, August 1995.
  365.    [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
  366.                  RFC-1828, August 1995.
  367.    [HMAC-MD5]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5
  368.                  for Message Authentication", Internet Draft, March, 1996.
  369.    [FIPS-180-1]  NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
  370.                  [URL] http://csrc.nist.gov/fips/fip180-1.txt (ascii)
  371.                  [URL] http://csrc.nist.gov/fips/fip180-1.ps  (postscript)
  372.    [SCHNEIER]    B. Schneier, "Applied Cryptography Protocols, Algorithms, and
  373.                  Source Code in C", John Wiley & Sons, Inc. 1994.
  374.    [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention
  375.                  Security Transform", Internet Draft, April, 1996.
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Chang, Glenn                                                    [Page 7]
  391.  
  392. INTERNET DRAFT             November 20, 1996            Expires May 1997
  393.  
  394.  
  395. Authors' Addresses
  396.  
  397.    Shu-jen Chang
  398.    NIST
  399.    Building 820, Room 456
  400.    Gaithersburg, MD 20899
  401.  
  402.    shu-jen.chang@nist.gov
  403.  
  404.    Robert Glenn
  405.    NIST
  406.    Building 820, Room 455
  407.    Gaithersburg, MD 20899
  408.  
  409.    rob.glenn@nist.gov
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. Chang, Glenn                                                    [Page 8]
  447.  
  448.