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-1-96-00.txt < prev    next >
Text File  |  1997-03-20  |  16KB  |  447 lines
  1.  
  2. Network Working Group                                   S. Chang (NIST)
  3.                                                         R. Glenn (NIST)
  4.                                                         March 20, 1997
  5. Internet Draft
  6.  
  7.  
  8.          HMAC-SHA-1-96 IP Authentication with Replay Prevention
  9.                <draft-ietf-ipsec-ah-hmac-sha-1-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-SHA 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. Chang, Glenn                                                    [Page 1]
  54.  
  55. INTERNET DRAFT               March 20, 1997       Expires September 1997
  56.  
  57.  
  58. Contents
  59.  
  60.    1.  Introduction...................................................3
  61.    1.1    Terminology.................................................3
  62.    1.2    Keys........................................................4
  63.    1.3    Data Size...................................................4
  64.    2   Packet Format..................................................5
  65.    2.1    Replay Prevention...........................................5
  66.    2.2    Authentication Data Calculation.............................6
  67.    3.  Security Considerations........................................7
  68.    Acknowledgments....................................................7
  69.    References.........................................................8
  70.    Authors' Addresses.................................................8
  71.  
  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. Chang, Glenn                                                    [Page 2]
  110.  
  111. INTERNET DRAFT               March 20, 1997       Expires September 1997
  112.  
  113.  
  114. 1. Introduction
  115.  
  116.    The IP Authentication Header (AH) provides integrity and
  117.    authentication for IP datagrams [RFC-1826]. The transform specified
  118.    in this document uses a keyed-SHA mechanism based on [RFC-2104].  The
  119.    mechanism uses the (key-less) SHA hash function [FIPS-180-1] which
  120.    produces a message digest. When combined with an AH Key,
  121.    Authentication Data is produced. This value is placed in the
  122.    Authentication Data field of the AH [RFC-1826]. This value is also
  123.    the basis for the data integrity service offered by the AH protocol.
  124.  
  125.    To provide protection against replay attacks, a Replay Prevention
  126.    field is specified as a transform option.  This field is used to help
  127.    prevent attacks in which a message is stored and re-used later,
  128.    replacing or repeating the original.  The Security Parameters Index
  129.    (SPI) [RFC-1825] is used to determine whether this option is included
  130.    in the AH.
  131.  
  132.    Familiarity with the following documents is assumed: "Security
  133.    Architecture for the Internet Protocol" [RFC-1825], "IP
  134.    Authentication Header" [RFC-1826], and "HMAC: Keyed Hashing for
  135.    Message Authentication" [RFC-2104].
  136.  
  137.    All implementations that claim conformance or compliance with the IP
  138.    Authentication Header specification [RFC-1826] SHOULD implement this
  139.    HMAC-SHA-1-96 transform.
  140.  
  141. 1.1 Terminology
  142.  
  143.    In  this  document,  the  words  that  are  used  to   define   the
  144.    significance  of each particular requirement are usually capitalized.
  145.    These words are:
  146.  
  147.    - MUST
  148.  
  149.    This word or the adjective "REQUIRED" means that  the  item  is  an
  150.    absolute requirement of the specification.
  151.  
  152.    - SHOULD
  153.  
  154.    This word or the adjective "RECOMMENDED"  means  that  there  might
  155.    exist  valid reasons in particular circumstances to ignore this item,
  156.    but the full implications should be understood and the case carefully
  157.    weighed before taking a different course.
  158.  
  159.    - MAY
  160.  
  161.    This word or the adjective "OPTIONAL" means that this item is truly
  162.  
  163.  
  164.  
  165. Chang, Glenn                                                    [Page 3]
  166.  
  167. INTERNET DRAFT               March 20, 1997       Expires September 1997
  168.  
  169.  
  170.    optional.  One vendor might choose to include the item because a
  171.    particular marketplace requires it or because it enhances the product,
  172.    for example; another vendor may omit the same item.
  173.  
  174.    For the purpose of this specification, the terms conformance and
  175.    compliance are synonymous.
  176.  
  177. 1.2 Keys
  178.  
  179.    The "AH Key" is used as a shared secret between two communicating
  180.    parties.  The Key is not a "cryptographic key" as used in a
  181.    traditional sense. Instead, the AH key (shared secret) is hashed with
  182.    the transmitted data and thus, assures that an intervening party
  183.    cannot duplicate the Authentication Data.
  184.  
  185.    Even though an AH key is not a cryptographic key, the rudimentary
  186.    concerns of cryptographic keys still apply. Consider that the
  187.    algorithm and most of the data used to produce the output is known.
  188.    The strength of the transform lies in the singular mapping of the key
  189.    (which needs to be strong) and the IP datagram (which is known) to
  190.    the Authentication Data.  Thus, implementations should, and as
  191.    frequently as possible, change the AH key. Keys need to be chosen at
  192.    random, or generated using a cryptographically strong pseudo-random
  193.    generator seeded with a random seed. [RFC-2104]
  194.  
  195.    All conforming and compliant implementations MUST support a key
  196.    length of 160 bits or less.  Implementations SHOULD support longer
  197.    key lengths as well.  It is advised that the key length be chosen to
  198.    be the length of the hash algorithm output, which is 160 bits for
  199.    SHA.  For other key lengths the following concerns MUST be
  200.    considered.
  201.  
  202.    A key length of zero is prohibited and implementations MUST prevent
  203.    key lengths of zero from being used with this transform, since no
  204.    effective authentication could be provided by a zero-length key.  SHA
  205.    operates on 64-byte blocks.  Keys longer than 64-bytes are first
  206.    hashed using SHA.  The resulting hash is then used to calculate the
  207.    Authentication Data.
  208.  
  209. 1.3 Data Size
  210.  
  211.    HMAC-SHA-1 generates a message digest of 160 bits. HMAC-SHA-1-96 uses
  212.    the first or left most 96 bits as the Authentication Data.   This
  213.    procedure is known as truncation.  In the case of this transform,
  214.    truncation is used to help maintain 64-bit packet header alignment,
  215.    eliminate unnecessary overhead, and potentially provided stronger
  216.    authentication.  [RFC-2104] provides more information on the
  217.    advantages and disadvantages of truncation.
  218.  
  219.  
  220.  
  221. Chang, Glenn                                                    [Page 4]
  222.  
  223. INTERNET DRAFT               March 20, 1997       Expires September 1997
  224.  
  225.  
  226. 2. Packet Format
  227.  
  228.         +---------------+---------------+---------------+---------------+
  229.         | Next Header   | Length        |           RESERVED            |
  230.         +---------------+---------------+---------------+---------------+
  231.         |                              SPI                              |
  232.         +---------------+---------------+---------------+---------------+
  233.         |                     Replay Prevention                         |
  234.         +---------------+---------------+---------------+---------------+
  235.         |                                                               |
  236.         +                                                               +
  237.         |                     Authentication Data                       |
  238.         +                                                               +
  239.         |                                                               |
  240.         +---------------+---------------+---------------+---------------+
  241.          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
  242.  
  243.    The Next Header, RESERVED, and SPI fields are specified in [RFC-
  244.    1826]. The Length field is the length of the Replay Prevention field
  245.    and the Authentication Data in 32-bit words.  The Length field will
  246.    always be set to 4 (128 bits) for HMAC-SHA-1-96.
  247.  
  248. 2.1 Replay Prevention
  249.  
  250.    The Replay Prevention field is a 32-bit value used to guarantee that
  251.    each packet exchanged between two parties is different. Each IPsec
  252.    Security Association specifies whether Replay Prevention is used for
  253.    that Security Association.  The Replay Prevention field is always
  254.    included in the calculation of the Authentication Data.  If Replay
  255.    Prevention is NOT in use, the 32-bit value is set to 0, included in
  256.    the calculation of the Authentication Data, and ignored upon receipt
  257.    with regard to checking for replay.  This field is used to help
  258.    prevent attacks in which a message is stored and re-used later,
  259.    replacing or repeating the original.  Replay Prevention SHOULD be
  260.    implemented.
  261.  
  262.    Replay Prevention SHOULD be implemented.  If Replay Prevention is not
  263.    implemented, the 32-bit field remains are part of the AH and is
  264.    treated as if Replay Prevention is NOT in use (i.e. the 32-bit value
  265.    is set to 0, included in the calculation of the Authentication Data,
  266.    and ignored upon receipt with regard to checking for replay.
  267.  
  268.    The 32-bit field is an up counter starting at a value of 1.
  269.  
  270.    The secret shared key MUST NOT be used for a period of time that
  271.    allows the counter to wrap, that is, to transmit more than 2^32
  272.    packets using a single key.
  273.  
  274.  
  275.  
  276.  
  277. Chang, Glenn                                                    [Page 5]
  278.  
  279. INTERNET DRAFT               March 20, 1997       Expires September 1997
  280.  
  281.  
  282.    Upon receipt, the replay value is assured to be increasing.  An
  283.    implementation MAY accept out of order packets.  If an "out of order
  284.    window" is supported, an implementation MUST guarantee that any and
  285.    all packets accepted out of order have not arrived before. That is,
  286.    an implementation MUST accept any packet, at most, once.  The size of
  287.    the window is a negotiated value specified by the IPsec Security
  288.    Association.
  289.  
  290.    [ESP-DES-MD5] provides more information on negotiated windows sizes,
  291.    example code that implements a 32 packet replay window, and a test
  292.    routine to show how it could be implemented.
  293.  
  294.    When the destination address is a multicast address and more than one
  295.    sender is sharing the same IPsec Security Association to that
  296.    multicast destination address, then Replay Prevention SHOULD NOT be
  297.    enabled.  When Replay Prevention is desired for a multicast session
  298.    having multiple senders to the same multicast destination address,
  299.    each sender SHOULD have its own IPsec Security Association.
  300.  
  301. 2.2 Authentication Data Calculation
  302.  
  303.    The Authentication Data is the output of the SHA authentication
  304.    algorithm as described in [FIPS-180-1].  The digest is calculated
  305.    over the entire IP datagram. Fields within the datagram that are
  306.    variant during transit and the Authentication Data field itself must
  307.    contain all zeros prior to the computation [RFC-1826]. The Replay
  308.    Prevention field, used or not, is included in the calculation.
  309.  
  310.    To compute HMAC-SHA-1 over the data 'text', the following is
  311.    calculated:
  312.  
  313.        SHA (K XOR opad, SHA (K XOR ipad, text))
  314.  
  315.    The result of which is truncated to 96 bits (retaining the left most
  316.    bits) to produce HMAC-SHA-1-96.
  317.  
  318.    K denotes the secret key shared by the parties. If K is longer than
  319.    64-bytes, it MUST first be hashed using SHA. In this case, K is the
  320.    resulting hash.  The variables 'ipad', 'opad' denote fixed strings
  321.    for inner and outer padding respectively. The two strings are:
  322.  
  323.        ipad = the byte 0x36 repeated 64 times,
  324.        opad = the byte 0x5C repeated 64 times.
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Chang, Glenn                                                    [Page 6]
  334.  
  335. INTERNET DRAFT               March 20, 1997       Expires September 1997
  336.  
  337.  
  338.    The calculation of the Authentication Data consists of the following
  339.    steps:
  340.  
  341.    (1) append zeros to the end of K to create a 64 byte string (e.g., if K
  342.        is of length 16 bytes it will be appended with 48 zero bytes 0x00)
  343.    (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1)
  344.        with ipad
  345.    (3) concatenate to the 64 byte string resulting from step (2) the data
  346.        stream 'text'
  347.    (4) apply SHA to the stream generated in step (3)
  348.    (5) XOR the 64 byte string computed in step (1) with opad
  349.    (6) concatenate to the 64 byte string resulting from step (5) the SHA
  350.        result of step (4)
  351.    (7) apply SHA to the stream generated in step (6)
  352.    (8) use the left most 96 bits of the result obtained in (7) as the final
  353.        result
  354.  
  355.    A similar computation is described in more detail, along with example
  356.    code and performance improvements, in [RFC-2104].  Implementers
  357.    should consult [RFC-2104] for more information on the HMAC technique
  358.    for keying a cryptographic hash function.
  359.  
  360. 3. Security Considerations
  361.  
  362.    The security provided by this transform is based on the strength of
  363.    SHA, the correctness of the algorithm's implementation, the security
  364.    of the key management mechanism and its implementation, the strength
  365.    of the associated secret key, and upon the correctness of the
  366.    implementations in all of the participating systems.  [RFC-2104]
  367.    contains a detailed discussion on the strengths and weaknesses of
  368.    HMAC algorithms.  [HMAC-TESTS] contains test vectors and example code
  369.    to assist in verifying the correctness of HMAC-SHA-1 code.
  370.  
  371. Acknowledgments
  372.  
  373. This document is largely based on text written by Hugo Krawczyk.  The
  374. format used was derived from work by William Simpson and Perry Metzger.
  375. The text on replay prevention is derived from work by Jim Hughes.
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Chang, Glenn                                                    [Page 7]
  390.  
  391. INTERNET DRAFT               March 20, 1997       Expires September 1997
  392.  
  393.  
  394. References
  395.  
  396.  
  397.    [RFC-1825]    R. Atkinson, "Security Architecture for the Internet Protocol",
  398.                  RFC-1825, August 1995.
  399.    [RFC-1826]    R. Atkinson, "IP Authentication Header",
  400.                  RFC-1826, August 1995.
  401.    [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
  402.                  RFC-1828, August 1995.
  403.    [RFC-2104]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing
  404.                  for Message Authentication", RFC-2104, February, 1997.
  405.    [FIPS-180-1]  NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
  406.                  [URL] http://csrc.nist.gov/fips/fip180-1.txt (ascii)
  407.                  [URL] http://csrc.nist.gov/fips/fip180-1.ps  (postscript)
  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.    Shu-jen Chang
  416.    NIST
  417.    Building 820, Room 456
  418.    Gaithersburg, MD 20899
  419.  
  420.    shu-jen.chang@nist.gov
  421.  
  422.    Robert Glenn
  423.    NIST
  424.    Building 820, Room 455
  425.    Gaithersburg, MD 20899
  426.  
  427.    rob.glenn@nist.gov
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445. Chang, Glenn                                                    [Page 8]
  446.  
  447.