[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 RFC 4868

Network Working Group                                           S. Kelly
Internet-Draft                                   Aruba Wireless Networks
Intended status: Standards Track                              S. Frankel
Expires: April 1, 2007                                              NIST
                                                      September 28, 2006


                     Using HMAC-SHA-256 With IPsec
                     draft-kelly-ipsec-ciph-sha2-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 1, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification describes the use of the SHA-256 algorithm in
   conjunction with HMAC as a data origin authentication and integrity
   verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
   and also as a PRF for IKEv2.  Two output truncation lengths are
   specified for data origin authentication and integrity verification
   usage, with the corresponding algorithms designated as HMAC-SHA-256-
   128 and HMAC-SHA-256-192.  No truncation is specified for PRF usage,



Kelly & Frankel           Expires April 1, 2007                 [Page 1]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


   and the resulting algorithm is designated as HMAC-SHA-PRF-256.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The HMAC-SHA-256 Algorithms  . . . . . . . . . . . . . . . . .  3
     2.1.  Keying Material  . . . . . . . . . . . . . . . . . . . . .  3
       2.1.1.  Data Origin Authentication and Integrity
               Verification Usage . . . . . . . . . . . . . . . . . .  3
       2.1.2.  Pseudo-Random Function (PRF) Usage . . . . . . . . . .  4
       2.1.3.  Randomness and Key Strength  . . . . . . . . . . . . .  4
       2.1.4.  Key Distribution . . . . . . . . . . . . . . . . . . .  4
       2.1.5.  Refreshing Keys  . . . . . . . . . . . . . . . . . . .  4
     2.2.  Padding  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Using HMAC-SHA-256 As a PRF in IKEv2 . . . . . . . . . . .  6
     2.5.  Interactions with the ESP or IKEv2 Cipher Mechanisms . . .  6
     2.6.  Test Vectors . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     3.1.  HMAC Key Length vs Truncation Length . . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14























Kelly & Frankel           Expires April 1, 2007                 [Page 2]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


1.  Introduction

   This document specifies the use of SHA-256 [SHA2-1] combined with
   HMAC [HMAC] as a data origin authentication and integrity
   verification mechanism for the IPsec AH [AH], ESP [ESP], and IKEv2
   [IKEv2] protocols.  For flexibility, two output truncation lengths
   are specified for the authentication-related variants, with the
   corresponding algorithms designated as HMAC-SHA-256-128 and HMAC-SHA-
   256-192.  In addition, this document specifies use of the underlying
   HMAC-SHA-256 algorithm (without truncation) as a PRF within IKEv2,
   and that variant is designated as HMAC-SHA-PRF-256.  These algorithms
   are collectively referred to below as "the HMAC-SHA-256 algorithms."

   The goal of the PRF variant is to provide a secure pseudo-random
   function suitable for generation of keying material and other
   protocol-specific numeric quantities, while the goal of the
   authentication variants is to ensure that packets are authentic and
   cannot be modified in transit.  The relative security of HMAC-SHA-256
   when used in either case is dependent on the scope of distribution
   and the unpredictability of the associated secret key.  If the key is
   not predictable and known only by the source and destination, these
   algorithms ensure that only parties holding an identical key can
   derive the associated values.


2.  The HMAC-SHA-256 Algorithms

   [SHA2-1] and [SHA2-2] describe the underlying SHA-256 algorithm,
   while [HMAC] describes the HMAC algorithm.  The HMAC algorithm
   provides a framework for inserting various hashing algorithms such as
   SHA-256.  The following sections describe the various characteristics
   and requirements of the HMAC-SHA-256 algorithms.

2.1.  Keying Material

   Requirements for keying material vary depending on usage.  These
   distinctions are described in the following sections.

2.1.1.  Data Origin Authentication and Integrity Verification Usage

   HMAC-SHA-256 is a secret key algorithm.  While no fixed key length is
   specified in [HMAC], this specification requires that for use as an
   integrity algorithm, a fixed key length of 256-bits MUST be
   supported, and key lengths other than 256-bits MUST NOT be supported.
   The 256-bit key length is chosen based on the recommendations in
   [HMAC] (i.e. key lengths less than the authenticator length decrease
   security strength and keys longer than the authenticator length do
   not significantly increase security strength).



Kelly & Frankel           Expires April 1, 2007                 [Page 3]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


2.1.2.  Pseudo-Random Function (PRF) Usage

   IKEv2 uses PRFs for multiple purposes, most notably for generating
   keying material and authentication of the IKE_SA.  The IKEv2
   specification differentiates between PRFs with fixed key sizes and
   those with variable key sizes.

   When the PRF described in this document is used with IKEv2, it is
   considered to have a variable key length, and keys are derived in the
   following way (as specified in [HMAC]):

   o  If the key is exactly 256 bits long, use it as-is.

   o  If the key has fewer than 256 bits, lengthen it to exactly 256
      bits by padding it on the right with zero bits.  However, note
      that [HMAC] strongly discourages a key length less than 256 bits.

   o  If the key is 257 bits or longer, shorten it to exactly 256 bits
      by computing the SHA2-256 hash of the entire key value, and use
      the resulting output value as your HMAC key.

2.1.3.  Randomness and Key Strength

   [HMAC] discusses requirements for key material, including a
   requirement for strong randomness.  Therefore, a strong pseudo-random
   function MUST be used to generate the required 256-bit key for use
   with either HMAC-SHA-256-128 or HMAC-SHA-256-192.  At the time of
   this writing there are no published weak keys for use with HMAC-SHA-
   256.

2.1.4.  Key Distribution

   [ARCH] describes the general mechanism for obtaining keying material
   when multiple keys are required for a single SA (e.g. when an ESP SA
   requires a key for confidentiality and a key for authentication).  In
   order to provide data origin authentication and integrity
   verification, the key distribution mechanism must ensure that unique
   keys are allocated and that they are distributed only to the parties
   participating in the communication.

2.1.5.  Refreshing Keys

   [HMAC] makes the following recommendation with regard to rekeying:
   "Current attacks do not indicate a specific recommended frequency for
   key changes ...  However, periodic key refreshment is a fundamental
   security practice that helps against potential weaknesses of the
   function and keys, and limits the damage of an exposed key."




Kelly & Frankel           Expires April 1, 2007                 [Page 4]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


   Putting this into perspective, this specification requires 256-bit
   keys produced by a strong PRF for use as a MAC.  A brute force attack
   on such keys would take more years to mount than the universe has
   been in existence.  On the other hand, weak keys (e.g. dictionary
   words) would be dramatically less resistant to attack.  It is
   important to take this, along with the threat model for your
   particular application and the current state of the art with respect
   to attacks on SHA-256, into account when determining an appropriate
   upper bound for HMAC key lifetimes

2.2.  Padding

   The HMAC-SHA-256 algorithms operate on 512-bit blocks of data.
   Padding requirements are specified in [SHA2-1] and are part of the
   SHA-256 algorithm, so if you build SHA-256 according to [SHA2-1], you
   do not need to add any additional padding as far as the HMAC-SHA-256
   algorithms specified here are concerned.  With regard to "implicit
   packet padding" as defined in [AH], no implicit packet padding is
   required.

2.3.  Truncation

   The HMAC-SHA-256 algorithms produce a 256-bit authenticator value,
   and this 256-bit value can be truncated as described in [HMAC].  When
   used as a data origin authentication and integrity verification
   algorithm in ESP, AH, or IKEv2, a truncated value using the first 128
   or 192 bits MUST be supported.  No other authenticator value lengths
   are supported by this specification.

   Upon sending, the truncated value is stored within the authenticator
   field.  Upon receipt, the entire 256-bit value is computed and the
   first 128 or 192 bits are compared to the value stored in the
   authenticator field, depending on whether the negotiated algorithm is
   HMAC-SHA-256-128 or HMAC-SHA-256-192.

   [HMAC] discusses potential security benefits resulting from
   truncation of the output MAC value, and in general, encourages HMAC
   users to perform MAC truncation.  In the context of IPsec, a minimum
   truncation length of 128 bits is selected because it corresponds to
   the birthday attack bound, and it simultaneously serves to minimize
   the additional bits on the wire resulting from use of this facility.
   This specification also defines a truncation length of 192 in order
   to provide an alternative to those whose security needs outweigh
   their concern for minimizing bits on the wire.







Kelly & Frankel           Expires April 1, 2007                 [Page 5]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


2.4.  Using HMAC-SHA-256 As a PRF in IKEv2

   The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128 and
   HMAC-SHA-256-192 except that variable-length keys are permitted, and
   the truncation step is NOT performed.  The test vectors below which
   are simply labeled HMAC-SHA-256 may be used to validate
   implementations of HMAC-SHA-PRF-256.

2.5.  Interactions with the ESP or IKEv2 Cipher Mechanisms

   As of this writing, there are no known issues which preclude the use
   of the HMAC-SHA-256 algorithms with any specific cipher algorithm.

2.6.  Test Vectors

   The following test cases for HMAC-SHA-256-192 and HMAC-SHA-256-128
   include the key, the data, and the resulting HMAC.  The values of
   keys and data are either hexadecimal numbers (prefixed by "0x") or
   ASCII character strings (surrounded by double quotes).  If a value is
   an ASCII character string, then the HMAC computation for the
   corresponding test case DOES NOT include the trailing null character
   ('\0') of the string.  The computed HMAC values are all hexadecimal
   numbers.

   These test cases were verified using 3 independent implementations:
   an HMAC wrapper on top of Aaron Gifford's SHA256 implementation
   (http://www.adg.us/computers/sha.html), the BeeCrypt crypto library
   (http://beecrypt.sourceforge.net/) and the Nettle cryptographic
   library (www.lysator.liu.se/~nisse/nettle).  Partial blocks were
   padded as specified in [SHA2-1].

   Test cases 1 and 2 were taken from the SHA-2 FIPS [SHA2-1] and test
   cases 4-10 were borrowed from [HMAC-TEST] with some key sizes adjust-
   ed for HMAC-SHA-256.  These test cases illustrate HMAC-SHA-256 with
   various combinations of input and keysize.  All test cases include
   the computed HMAC-SHA-256; only those with a keysize of 32 bytes (256
   bits) also include the truncated HMAC-SHA-256-128 and HMAC-SHA-256-
   192.













Kelly & Frankel           Expires April 1, 2007                 [Page 6]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


          Test Case #1: HMAC-SHA-256 with 3-byte input and 32-byte key
          Key_len         : 32
          Key             : 0x0102030405060708090a0b0c0d0e0f10
                            1112131415161718191a1b1c1d1e1f20
          Data_len        : 3
          Data            : "abc"

          HMAC-SHA-256    : 0xa21b1f5d4cf4f73a4dd939750f7a066a
                            7f98cc131cb16a6692759021cfab8181

          HMAC-SHA-256-128: 0xa21b1f5d4cf4f73a4dd939750f7a066a

          HMAC-SHA-256-192: 0xa21b1f5d4cf4f73a4dd939750f7a066a
                            7f98cc131cb16a66


          Test Case #2: HMAC-SHA-256 with 56-byte input and 32-byte key
          Key_len         : 32
          Key             : 0x0102030405060708090a0b0c0d0e0f10
                            1112131415161718191a1b1c1d1e1f20
          Data_len        : 56
          Data            : "abcdbcdecdefdefgefghfghighijhijk
                             ijkljklmklmnlmnomnopnopq"

          HMAC-SHA-256    : 0x104fdc1257328f08184ba73131c53cae
                              e698e36119421149ea8c712456697d30

          HMAC-SHA-256-128: 0x104fdc1257328f08184ba73131c53cae

          HMAC-SHA-256-192: 0x104fdc1257328f08184ba73131c53cae
                              e698e36119421149




















Kelly & Frankel           Expires April 1, 2007                 [Page 7]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


          Test Case #3: HMAC-SHA-256 with 112-byte (multi-block) input
                        and 32-byte key
          Key_len         : 32
          Key             : 0x0102030405060708090a0b0c0d0e0f10
                            1112131415161718191a1b1c1d1e1f20
          Data_len        : 112
          Data            : "abcdbcdecdefdefgefghfghighijhijk
                             ijkljklmklmnlmnomnopnopqabcdbcde
                             cdefdefgefghfghighijhijkijkljklm
                             klmnlmnomnopnopq"

          HMAC-SHA-256    : 0x470305fc7e40fe34d3eeb3e773d95aab
                              73acf0fd060447a5eb4595bf33a9d1a3

          HMAC-SHA-256-128: 0x470305fc7e40fe34d3eeb3e773d95aab

          HMAC-SHA-256-192: 0x470305fc7e40fe34d3eeb3e773d95aab
                              73acf0fd060447a5



          Test Case #4:  HMAC-SHA-256 with 8-byte input and 32-byte key
          Key_len         : 32
          Key             : 0x0b repeated 32 times
          Data_len        : 8
          Data            : 0x4869205468657265
          Data            : "Hi There"

          HMAC-SHA-256    : 0x198a607eb44bfbc69903a0f1cf2bbdc5
                              ba0aa3f3d9ae3c1c7a3b1696a0b68cf7

          HMAC-SHA-256-128: 0x198a607eb44bfbc69903a0f1cf2bbdc5

          HMAC-SHA-256-192: 0x198a607eb44bfbc69903a0f1cf2bbdc5
                              ba0aa3f3d9ae3c1c



          Test Case #5:  HMAC-SHA-256 with 28-byte input and 4-byte key
          Key_len         : 4
          Key             : "Jefe"
          Data_len        : 28
          Data            : "what do ya want for nothing?"

          HMAC-SHA-256    : 0x5bdcc146bf60754e6a042426089575c7
                              5a003f089d2739839dec58b964ec3843





Kelly & Frankel           Expires April 1, 2007                 [Page 8]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


          Test Case #6: HMAC-SHA-256 with 50-byte input and 32-byte key
          Key_len         : 32
          Key             : 0xaa repeated 32 times
          Data_len        : 50
          Data            : 0xdd repeated 50 times

          HMAC-SHA-256    : 0xcdcb1220d1ecccea91e53aba3092f962
                              e549fe6ce9ed7fdc43191fbde45c30b0

          HMAC-SHA-256-128: 0xcdcb1220d1ecccea91e53aba3092f962

          HMAC-SHA-256-192: 0xcdcb1220d1ecccea91e53aba3092f962
                              e549fe6ce9ed7fdc



          Test Case #7: HMAC-SHA-256 with 50-byte input and 37-byte key
          Key_len         : 37
          Key             : 0x0102030405060708090a0b0c0d0e0f10
                              1112131415161718191a1b1c1d1e1f20
                              2122232425
          Data_len        : 50
          Data            : 0xcd repeated 50 times

          HMAC-SHA-256    : 0xd4633c17f6fb8d744c66dee0f8f07455
                              6ec4af55ef07998541468eb49bd2e917


          Test Case #8: HMAC-SHA-256 with 20-byte input and 32-byte key
          Key_len         : 32
          Key             : 0x0c repeated 32 times
          Data_len        : 20
          Data            : "Test With Truncation"

          HMAC-SHA-256    : 0x7546af01841fc09b1ab9c3749a5f1c17
                              d4f589668a587b2700a9c97c1193cf42

          HMAC-SHA-256-128: 0x7546af01841fc09b1ab9c3749a5f1c17

          HMAC-SHA-256-192: 0x7546af01841fc09b1ab9c3749a5f1c17
                              d4f589668a587b27










Kelly & Frankel           Expires April 1, 2007                 [Page 9]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


          Test Case #9: HMAC-SHA-256 with 54-byte input and 80-byte key
          Key_len         : 80
          Key             : 0xaa repeated 80 times
          Data_len        : 54
          Data            : "Test Using Larger Than Block-Size Key -
                             Hash Key First"

          HMAC-SHA-256    : 0x6953025ed96f0c09f80a96f78e6538db
                              e2e7b820e3dd970e7ddd39091b32352f


          Test Case #10: HMAC-SHA-256 with 73-byte (multi-block) input
                         and 80-byte key
          Key_len         : 80
          Key             : 0xaa repeated 80 times
          Data_len        : 73
          Data            : "Test Using Larger Than Block-Size Key and
                             Larger Than One Block-Size Data"

          HMAC-SHA-256    : 0x6355ac22e890d0a3c8481a5ca4825bc8
                              84d3e7a1ff98a2fc2ac7d8e064c3b2e6


3.  Security Considerations

   In a general sense, the security provided by the HMAC-SHA-256
   algorithms is based both upon the strength of SHA-256, and upon the
   additional strength derived from the HMAC construct.  At the time of
   this writing there are no practical cryptographic attacks against
   either SHA-256 or HMAC.  However, as with any cryptographic
   algorithm, an important component of HMAC-SHA-256's strength lies in
   the correctness of the algorithm implementation, the security of the
   key management mechanism, the strength of the associated secret key,
   and upon the correctness of the implementation in all of the
   participating systems.  This specification contains test vectors to
   assist in verifying the correctness of HMAC-SHA-256 code, but these
   in no way verify the correctness (or security) of surrounding
   security infrastructure.

3.1.  HMAC Key Length vs Truncation Length

   There are important differences between the security levels afforded
   by HMAC-SHA1-96 and the HMAC-SHA-256-128 and HMAC-SHA-256-192
   algorithms, but there are also considerations which are somewhat
   counter-intuitive.  There are two different axes along which we gauge
   the security of these algorithms: HMAC output length and HMAC key
   length.  If we assume the HMAC key is a well-guarded secret which can
   only be determined through offline attacks on observed values, and



Kelly & Frankel           Expires April 1, 2007                [Page 10]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


   that its length is less than or equal to the output length of the
   underlying hash algorithm, then the key's strength is directly
   proportional to its length.  And if we assume an adversary has no
   knowledge of the HMAC key, then the probability of guessing a correct
   MAC value for any given packet is directly proportional to the HMAC
   output length.

   This specification defines truncation to output lengths of either 128
   or 192 bits.  It is important to note that at this time, it is not
   clear that HMAC-SHA-256 with a truncation length of 128 bits is any
   more secure than HMAC-SHA1 with the same truncation length, assuming
   the adversary has no knowledge of the HMAC key.  This is because in
   such cases, the adversary must predict only those bits which remain
   after truncation.  Since in both cases that output length is the same
   (128 bits), the adversary's odds of correctly guessing the value are
   also the same in either case: 1 in 2^128.  Again, if we assume the
   HMAC key remains unknown to the attacker, then only a bias in one of
   the algorithms would distinguish one from the other.  Currently, no
   such bias is known to exist in either HMAC-SHA1 or HMAC-SHA-256.

   If, on the other hand, the attacker is focused on guessing the HMAC
   key, and we assume that the hash algorithms are indistinguishable
   when viewed as PRF's, then the HMAC key length provides a direct
   measure of the underlying security: the longer the key, the harder it
   is to guess.  This means that with respect to passive attacks on the
   HMAC key, size matters - and the HMAC-SHA-256 algorithms, with their
   256-bit key lengths, provide more security in this regard than HMAC-
   SHA1 (with its 160-bit key length).


4.  IANA Considerations

   For use of HMAC-SHA-256 as a PRF in IKEv2, IANA has assigned the
   following IKEv2 Pseudo-random function (type 2) transform identifier:

   [TBA-1]  for PRF_HMAC_SHA2_256

   For the use of the HMAC-SHA-256 algorithms for data origin
   authentication and integrity verification in IKEv2, ESP or AH, IANA
   has assigned the following IKEv2 integrity (type 3) transform
   identifiers:

   [TBA-2]  for AUTH_HMAC_SHA2_256_128

   [TBA-3]  for AUTH_HMAC_SHA2_256_192






Kelly & Frankel           Expires April 1, 2007                [Page 11]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


5.  Acknowledgements

   Portions of this text were unabashedly borrowed from [HMAC-SHA1], and
   also from [XCBC-PRF].  Thanks to Hugo Krawczyk for comments and
   recommendations on early revisions of this document, and thanks to
   Russ Housley for security-related comments and recommendations.


6.  References

6.1.  Normative References

   [AH]       Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [ARCH]     Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [HMAC-SHA1]
              Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [SHA2-1]   NIST, "Draft FIPS PUB 180-2 'Specifications for the Secure
              Hash Standard'", 2001 MAY, <http://csrc.nist.gov/
              publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.

   [SHA2-2]   NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
              2001 MAY,
              <http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.

6.2.  Informative References

   [HMAC-TEST]
              Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
              SHA-1", RFC 2202, September 1997.

   [XCBC-PRF]



Kelly & Frankel           Expires April 1, 2007                [Page 12]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


              Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
              Internet Key Exchange Protocol (IKE)", RFC 4434,
              February 2006.


Authors' Addresses

   Scott G. Kelly
   Aruba Wireless Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089
   US

   Email: scott@hyperthought.com


   Sheila Frankel
   NIST
   Bldg. 222 Room B264
   Gaithersburg, MD  20899
   US

   Email: sheila.frankel@nist.gov




























Kelly & Frankel           Expires April 1, 2007                [Page 13]

Internet-Draft        Using HMAC-SHA-256 With IPsec       September 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kelly & Frankel           Expires April 1, 2007                [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/