doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc4868.txt b/doc/rfc/rfc4868.txt
new file mode 100644
index 0000000..c077acd
--- /dev/null
+++ b/doc/rfc/rfc4868.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                           S. Kelly
+Request for Comments: 4868                                Aruba Networks
+Category: Standards Track                                     S. Frankel
+                                                                    NIST
+                                                                May 2007
+
+
+     Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This specification describes the use of Hashed Message Authentication
+   Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512
+   algorithms in IPsec.  These algorithms may be used as the basis for
+   data origin authentication and integrity verification mechanisms for
+   the Authentication Header (AH), Encapsulating Security Payload (ESP),
+   Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also
+   as Pseudo-Random Functions (PRFs) for IKE and IKEv2.  Truncated
+   output lengths are specified for the authentication-related variants,
+   with the corresponding algorithms designated as HMAC-SHA-256-128,
+   HMAC-SHA-384-192, and HMAC-SHA-512-256.  The PRF variants are not
+   truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and
+   PRF-HMAC-SHA-512.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 1]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+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 . . . . . . . . . . . . . . . . . .  4
+       2.1.2.  Pseudo-Random Function (PRF) Usage . . . . . . . . . .  4
+       2.1.3.  Randomness and Key Strength  . . . . . . . . . . . . .  5
+       2.1.4.  Key Distribution . . . . . . . . . . . . . . . . . . .  5
+       2.1.5.  Refreshing Keys  . . . . . . . . . . . . . . . . . . .  5
+     2.2.  Padding  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.3.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4.  Using HMAC-SHA-256+ as PRFs in IKE and IKEv2 . . . . . . .  7
+     2.5.  Interactions with the ESP, IKE, or IKEv2 Cipher
+           Mechanisms . . . . . . . . . . . . . . . . . . . . . . . .  7
+     2.6.  HMAC-SHA-256+ Parameter Summary  . . . . . . . . . . . . .  7
+     2.7.  Test Vectors . . . . . . . . . . . . . . . . . . . . . . .  7
+       2.7.1.  PRF Test Vectors . . . . . . . . . . . . . . . . . . .  8
+       2.7.2.  Authenticator Test Vectors . . . . . . . . . . . . . . 11
+   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+     3.1.  HMAC Key Length vs Truncation Length . . . . . . . . . . . 17
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 2]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+1.  Introduction
+
+   This document specifies the use of SHA-256, SHA-384, and SHA-512
+   [SHA2-1] combined with HMAC [HMAC] as data origin authentication and
+   integrity verification mechanisms for the IPsec AH [AH], ESP [ESP],
+   IKE [IKE], and IKEv2 [IKEv2] protocol.  Output truncation is
+   specified for these variants, with the corresponding algorithms
+   designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-
+   256.  These truncation lengths are chosen in accordance with the
+   birthday bound for each algorithm.
+
+   This specification also describes untruncated variants of these
+   algorithms as Pseudo-Random Functions (PRFs) for use with IKE and
+   IKEv2, and those algorithms are called PRF-HMAC-SHA-256, PRF-HMAC-
+   SHA-384, and PRF-HMAC-SHA-512.  For ease of reference, these PRF
+   algorithms and the authentication variants described above are
+   collectively referred to below as "the HMAC-SHA-256+ algorithms".
+
+   The goal of the PRF variants are to provide secure pseudo-random
+   functions 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 distribution scope
+   and unpredictability of the associated secret key.  If the key is
+   unpredictable and known only by the sender and recipient, 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, SHA-384, and
+   SHA-512 algorithms, while [HMAC] describes the HMAC algorithm.  The
+   HMAC algorithm provides a framework for inserting various hashing
+   algorithms such as SHA-256, and [SHA256+] describes combined usage of
+   these algorithms.  The following sections describe the various
+   characteristics and requirements of the HMAC-SHA-256+ algorithms when
+   used with IPsec.
+
+2.1.  Keying Material
+
+   Requirements for keying material vary depending on whether the
+   algorithm is functioning as a PRF or as an authentication/integrity
+   mechanism.  In the case of authentication/integrity, key lengths are
+   fixed according to the output length of the algorithm in use.  In the
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 3]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   case of PRFs, key lengths are variable, but guidance is given to
+   ensure interoperability.  These distinctions are described further
+   below.
+
+   Before describing key requirements for each usage, it is important to
+   clarify some terms we use below:
+
+   Block size:  the size of the data block the underlying hash algorithm
+      operates upon.  For SHA-256, this is 512 bits, for SHA-384 and
+      SHA-512, this is 1024 bits.
+
+   Output length:  the size of the hash value produced by the underlying
+      hash algorithm.  For SHA-256, this is 256 bits, for SHA-384 this
+      is 384 bits, and for SHA-512, this is 512 bits.
+
+   Authenticator length:  the size of the "authenticator" in bits.  This
+      only applies to authentication/integrity related algorithms, and
+      refers to the bit length remaining after truncation.  In this
+      specification, this is always half the output length of the
+      underlying hash algorithm.
+
+2.1.1.  Data Origin Authentication and Integrity Verification Usage
+
+   HMAC-SHA-256+ are secret key algorithms.  While no fixed key length
+   is specified in [HMAC], this specification requires that when used as
+   an integrity/authentication algorithm, a fixed key length equal to
+   the output length of the hash functions MUST be supported, and key
+   lengths other than the output length of the associated hash function
+   MUST NOT be supported.
+
+   These key length restrictions are based in part on the
+   recommendations in [HMAC] (key lengths less than the output length
+   decrease security strength, and keys longer than the output length do
+   not significantly increase security strength), and in part because
+   allowing variable length keys for IPsec authenticator functions would
+   create interoperability issues.
+
+2.1.2.  Pseudo-Random Function (PRF) Usage
+
+   IKE and IKEv2 use PRFs for generating keying material and for
+   authentication of the IKE Security Association.  The IKEv2
+   specification differentiates between PRFs with fixed key sizes and
+   those with variable key sizes, and so we give some special guidance
+   for this below.
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 4]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   When a PRF described in this document is used with IKE or IKEv2, it
+   is considered to have a variable key length, and keys are derived in
+   the following ways (note that we simply reiterate that which is
+   specified in [HMAC]):
+
+   o  If the length of the key is exactly the algorithm block size, use
+      it as-is.
+
+   o  If the key is shorter than the block size, lengthen it to exactly
+      the block size by padding it on the right with zero bits.
+      However, note that [HMAC] strongly discourages a key length less
+      than the output length.  Nonetheless, we describe handling of
+      shorter lengths here in recognition of shorter lengths typically
+      chosen for IKE or IKEv2 pre-shared keys.
+
+   o  If the key is longer than the block size, shorten it by computing
+      the corresponding hash algorithm output over the entire key value,
+      and treat the resulting output value as your HMAC key.  Note that
+      this will always result in a key that is less than the block size
+      in length, and this key value will therefore require zero-padding
+      (as described above) prior to use.
+
+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 key for use with HMAC-
+   SHA-256+.  At the time of this writing there are no published weak
+   keys for use with any HMAC-SHA-256+ algorithms.
+
+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
+
+   Currently, there are no practical attacks against the algorithms
+   recommended here, and especially against the key sizes recommended
+   here.  However, as noted in [HMAC] "...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             Standards Track                     [Page 5]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Putting this into perspective, this specification requires 256, 384,
+   or 512-bit keys produced by a strong PRF for use as a MAC.  A brute
+   force attack on such keys would take longer 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 these points, along with the specific threat
+   model for your particular application and the current state of the
+   art with respect to attacks on SHA-256, SHA-384, and SHA-512 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, while
+   the HMAC-SHA-384 and HMAC-SHA-512 algorithms operate on 1024-bit
+   blocks of data.  Padding requirements are specified in [SHA2-1] as
+   part of the underlying SHA-256, SHA-384, and SHA-512 algorithms, so
+   if you implement 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 each produce an nnn-bit value, where nnn
+   corresponds to the output bit length of the algorithm, e.g., HMAC-
+   SHA-nnn.  For use as an authenticator, this nnn-bit value can be
+   truncated as described in [HMAC].  When used as a data origin
+   authentication and integrity verification algorithm in ESP, AH, IKE,
+   or IKEv2, a truncated value using the first nnn/2 bits -- exactly
+   half the algorithm output size -- 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 nnn-bit value is computed and the
+   first nnn/2 bits are compared to the value stored in the
+   authenticator field, with the value of 'nnn' depending on the
+   negotiated algorithm.
+
+   [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
+   truncation length of nnn/2 bits is selected because it corresponds to
+   the birthday attack bound for each of the HMAC-SHA-256+ algorithms,
+   and it simultaneously serves to minimize the additional bits on the
+   wire resulting from use of this facility.
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 6]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+2.4.  Using HMAC-SHA-256+ as PRFs in IKE and IKEv2
+
+   The PRF-HMAC-SHA-256 algorithm is identical to HMAC-SHA-256-128,
+   except that variable-length keys are permitted, and the truncation
+   step is NOT performed.  Likewise, the implementations of PRF-HMAC-
+   SHA-384 and PRF-HMAC-SHA-512 are identical to those of HMAC-SHA-384-
+   192 and HMAC-SHA-512-256 respectively, except that again, variable-
+   length keys are permitted, and truncation is NOT performed.
+
+2.5.  Interactions with the ESP, IKE, or IKEv2 Cipher Mechanisms
+
+   As of this writing, there are no known issues that preclude the use
+   of the HMAC-SHA-256+ algorithms with any specific cipher algorithm.
+
+2.6.  HMAC-SHA-256+ Parameter Summary
+
+   The following table serves to summarize the various quantities
+   associated with the HMAC-SHA-256+ algorithms.  In this table, "var"
+   stands for "variable".
+
+   +------------------+--------+--------+--------+--------+------------+
+   |    Algorithm     | Block  | Output | Trunc. |  Key   | Algorithm  |
+   |       ID         |  Size  | Length | Length | Length |   Type     |
+   +==================+========+========+========+========+============+
+   | HMAC-SHA-256-128 |   512  |   256  |  128   |  256   | auth/integ |
+   +------------------+--------+--------+--------+--------+------------+
+   | HMAC-SHA-384-192 |  1024  |   384  |  192   |  384   | auth/integ |
+   +------------------+--------+--------+--------+--------+------------+
+   | HMAC-SHA-512-256 |  1024  |   512  |  256   |  512   | auth/integ |
+   +------------------+--------+--------+--------+--------+------------+
+   | PRF-HMAC-SHA-256 |   512  |   256  | (none) |  var   |     PRF    |
+   +------------------+--------+--------+--------+--------+------------+
+   | PRF-HMAC-SHA-384 |  1024  |   384  | (none) |  var   |     PRF    |
+   +------------------+--------+--------+--------+--------+------------+
+   | PRF-HMAC-SHA-512 |  1024  |   512  | (none) |  var   |     PRF    |
+   +------------------+--------+--------+--------+--------+------------+
+
+
+2.7.  Test Vectors
+
+   The following test cases include the key, the data, and the resulting
+   authenticator, and/or PRF values for each algorithm.  The values of
+   keys and data are either ASCII character strings (surrounded by
+   double quotes) or hexadecimal numbers.  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.
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 7]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+2.7.1.  PRF Test Vectors
+
+   These test cases were borrowed from RFC 4231 [HMAC-TEST].  For
+   reference implementations of the underlying hash algorithms, see
+   [SHA256+].  Note that for testing purposes, PRF output is considered
+   to be simply the untruncated algorithm output.
+
+   Test Case PRF-1:
+   Key =          0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b                          (20 bytes)
+
+   Data =         4869205468657265                  ("Hi There")
+
+   PRF-HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
+                      881dc200c9833da726e9376c2e32cff7
+
+   PRF-HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
+                      15f9dadbe4101ec682aa034c7cebc59c
+                      faea9ea9076ede7f4af152e8b2fa9cb6
+
+   PRF-HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
+                      2379f4e2ce4ec2787ad0b30545e17cde
+                      daa833b7d6b8a702038b274eaea3f4e4
+                      be9d914eeb61f1702e696c203a126854
+
+
+   Test Case PRF-2:
+   Key =          4a656665                          ("Jefe")
+
+   Data =         7768617420646f2079612077616e7420  ("what do ya want ")
+                  666f72206e6f7468696e673f          ("for nothing?")
+
+   PRF-HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
+                      5a003f089d2739839dec58b964ec3843
+
+   PRF-HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
+                      9c7ef464f5a01b47e42ec3736322445e
+                      8e2240ca5e69e2c78b3239ecfab21649
+
+   PRF-HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
+                      87bd64222e831fd610270cd7ea250554
+                      9758bf75c05a994a6d034f65f8f0e6fd
+                      caeab1a34d4a6b4b636e070a38bce737
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 8]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case PRF-3:
+   Key            aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaa                          (20 bytes)
+
+   Data =         dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddd                              (50 bytes)
+
+   PRF-HMAC-SHA-256 = 773ea91e36800e46854db8ebd09181a7
+                      2959098b3ef8c122d9635514ced565fe
+
+   PRF-HMAC-SHA-384 = 88062608d3e6ad8a0aa2ace014c8a86f
+                      0aa635d947ac9febe83ef4e55966144b
+                      2a5ab39dc13814b94e3ab6e101a34f27
+
+   PRF-HMAC-SHA-512 = fa73b0089d56a284efb0f0756c890be9
+                      b1b5dbdd8ee81a3655f83e33b2279d39
+                      bf3e848279a722c806b485a47e67c807
+                      b946a337bee8942674278859e13292fb
+
+
+   Test Case PRF-4:
+   Key =          0102030405060708090a0b0c0d0e0f10
+                  111213141516171819                (25 bytes)
+
+   Data =         cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcd                              (50 bytes)
+
+   PRF-HMAC-SHA-256 = 82558a389a443c0ea4cc819899f2083a
+                      85f0faa3e578f8077a2e3ff46729665b
+
+   PRF-HMAC-SHA-384 = 3e8a69b7783c25851933ab6290af6ca7
+                      7a9981480850009cc5577c6e1f573b4e
+                      6801dd23c4a7d679ccf8a386c674cffb
+
+   PRF-HMAC-SHA-512 = b0ba465637458c6990e5a8c5f61d4af7
+                      e576d97ff94b872de76f8050361ee3db
+                      a91ca5c11aa25eb4d679275cc5788063
+                      a5f19741120c4f2de2adebeb10a298dd
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                     [Page 9]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case PRF-5:
+   Key =          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaa                            (131 bytes)
+
+   Data =         54657374205573696e67204c61726765  ("Test Using Large")
+                  72205468616e20426c6f636b2d53697a  ("r Than Block-Siz")
+                  65204b6579202d2048617368204b6579  ("e Key - Hash Key")
+                  204669727374                      (" First")
+
+
+   PRF-HMAC-SHA-256 = 60e431591ee0b67f0d8a26aacbf5b77f
+                      8e0bc6213728c5140546040f0ee37f54
+
+   PRF-HMAC-SHA-384 = 4ece084485813e9088d2c63a041bc5b4
+                      4f9ef1012a2b588f3cd11f05033ac4c6
+                      0c2ef6ab4030fe8296248df163f44952
+
+   PRF-HMAC-SHA-512 = 80b24263c7c1a3ebb71493c1dd7be8b4
+                      9b46d1f41b4aeec1121b013783f8f352
+                      6b56d037e05f2598bd0fd2215d6a1e52
+                      95e64f73f63f0aec8b915a985d786598
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 10]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case PRF-6:
+
+   Key =          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaa                            (131 bytes)
+
+   Data =         54686973206973206120746573742075  ("This is a test u")
+                  73696e672061206c6172676572207468  ("sing a larger th")
+                  616e20626c6f636b2d73697a65206b65  ("an block-size ke")
+                  7920616e642061206c61726765722074  ("y and a larger t")
+                  68616e20626c6f636b2d73697a652064  ("han block-size d")
+                  6174612e20546865206b6579206e6565  ("ata. The key nee")
+                  647320746f2062652068617368656420  ("ds to be hashed ")
+                  6265666f7265206265696e6720757365  ("before being use")
+                  642062792074686520484d414320616c  ("d by the HMAC al")
+                  676f726974686d2e                  ("gorithm.")
+
+   PRF-HMAC-SHA-256 = 9b09ffa71b942fcb27635fbcd5b0e944
+                      bfdc63644f0713938a7f51535c3a35e2
+
+   PRF-HMAC-SHA-384 = 6617178e941f020d351e2f254e8fd32c
+                      602420feb0b8fb9adccebb82461e99c5
+                      a678cc31e799176d3860e6110c46523e
+
+   PRF-HMAC-SHA-512 = e37b6a775dc87dbaa4dfa9f96e5e3ffd
+                      debd71f8867289865df5a32d20cdc944
+                      b6022cac3c4982b10d5eeb55c3e4de15
+                      134676fb6de0446065c97440fa8c6a58
+
+
+2.7.2.  Authenticator Test Vectors
+
+   The following sections are test cases for HMAC-SHA256-128, HMAC-
+   SHA384-192, and HMAC-SHA512-256.  PRF outputs are also included for
+   convenience.  These test cases were generated using the SHA256+
+   reference code provided in [SHA256+].
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 11]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+2.7.2.1.  SHA256 Authentication Test Vectors
+
+   Test Case AUTH256-1:
+   Key =          0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b  (32 bytes)
+
+   Data =         4869205468657265                  ("Hi There")
+
+   PRF-HMAC-SHA-256 = 198a607eb44bfbc69903a0f1cf2bbdc5
+                      ba0aa3f3d9ae3c1c7a3b1696a0b68cf7
+
+   HMAC-SHA-256-128 = 198a607eb44bfbc69903a0f1cf2bbdc5
+
+
+
+   Test Case AUTH256-2:
+   Key =          4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+
+   Data =         7768617420646f2079612077616e7420  ("what do ya want ")
+                  666f72206e6f7468696e673f          ("for nothing?")
+
+   PRF-HMAC-SHA-256 = 167f928588c5cc2eef8e3093caa0e87c
+                      9ff566a14794aa61648d81621a2a40c6
+
+   HMAC-SHA-256-128 = 167f928588c5cc2eef8e3093caa0e87c
+
+
+
+   Test Case AUTH256-3:
+   Key =          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa  (32 bytes)
+
+   Data =         dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddd                              (50 bytes)
+
+   PRF-HMAC-SHA-256 = cdcb1220d1ecccea91e53aba3092f962
+                      e549fe6ce9ed7fdc43191fbde45c30b0
+
+   HMAC-SHA-256-128 = cdcb1220d1ecccea91e53aba3092f962
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 12]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case AUTH256-4:
+   Key =          0102030405060708090a0b0c0d0e0f10
+                  1112131415161718191a1b1c1d1e1f20  (32 bytes)
+
+   Data =         cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcd                              (50 bytes)
+
+   PRF-HMAC-SHA-256 = 372efcf9b40b35c2115b1346903d2ef4
+                      2fced46f0846e7257bb156d3d7b30d3f
+
+   HMAC-SHA-256-128 = 372efcf9b40b35c2115b1346903d2ef4
+
+
+2.7.2.2.  SHA384 Authentication Test Vectors
+
+   Test Case AUTH384-1:
+   Key =          0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b  (48 bytes)
+
+   Data =         4869205468657265                  ("Hi There")
+
+   PRF-HMAC-SHA-384 = b6a8d5636f5c6a7224f9977dcf7ee6c7
+                      fb6d0c48cbdee9737a959796489bddbc
+                      4c5df61d5b3297b4fb68dab9f1b582c2
+
+   HMAC-SHA-384-128 = b6a8d5636f5c6a7224f9977dcf7ee6c7
+                      fb6d0c48cbdee973
+
+
+   Test Case AUTH384-2:
+   Key =          4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+
+   Data =         7768617420646f2079612077616e7420  ("what do ya want ")
+                  666f72206e6f7468696e673f          ("for nothing?")
+
+   PRF-HMAC-SHA-384 = 2c7353974f1842fd66d53c452ca42122
+                      b28c0b594cfb184da86a368e9b8e16f5
+                      349524ca4e82400cbde0686d403371c9
+
+   HMAC-SHA-384-192 = 2c7353974f1842fd66d53c452ca42122
+                      b28c0b594cfb184d
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 13]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case AUTH384-3:
+   Key =          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa  (48 bytes)
+
+   Data =         dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddd                              (50 bytes)
+
+   PRF-HMAC-SHA-384 = 809f439be00274321d4a538652164b53
+                      554a508184a0c3160353e3428597003d
+                      35914a18770f9443987054944b7c4b4a
+
+   HMAC-SHA-384-192 = 809f439be00274321d4a538652164b53
+                      554a508184a0c316
+
+
+   Test Case AUTH384-4:
+   Key =          0102030405060708090a0b0c0d0e0f10
+                  1112131415161718191a1b1c1d1e1f20
+                  0a0b0c0d0e0f10111213141516171819  (48 bytes)
+
+   Data =         cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcd                              (50 bytes)
+
+   PRF-HMAC-SHA-384 = 5b540085c6e6358096532b2493609ed1
+                      cb298f774f87bb5c2ebf182c83cc7428
+                      707fb92eab2536a5812258228bc96687
+
+   HMAC-SHA-384-192 = 5b540085c6e6358096532b2493609ed1
+                      cb298f774f87bb5c
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 14]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+2.7.2.3.  SHA512 Authentication Test Vectors
+
+   Test Case AUTH512-1:
+   Key =          0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+                  0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b  (64 bytes)
+
+   Data =         4869205468657265                  ("Hi There")
+
+   PRF-HMAC-SHA-512 = 637edc6e01dce7e6742a99451aae82df
+                      23da3e92439e590e43e761b33e910fb8
+                      ac2878ebd5803f6f0b61dbce5e251ff8
+                      789a4722c1be65aea45fd464e89f8f5b
+
+   HMAC-SHA-512-256 = 637edc6e01dce7e6742a99451aae82df
+                      23da3e92439e590e43e761b33e910fb8
+
+
+   Test Case AUTH512-2:
+   Key =          4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+                  4a6566654a6566654a6566654a656665  ("JefeJefeJefeJefe")
+
+   Data =         7768617420646f2079612077616e7420  ("what do ya want ")
+                  666f72206e6f7468696e673f          ("for nothing?")
+
+   PRF-HMAC-SHA-512 = cb370917ae8a7ce28cfd1d8f4705d614
+                      1c173b2a9362c15df235dfb251b15454
+                      6aa334ae9fb9afc2184932d8695e397b
+                      fa0ffb93466cfcceaae38c833b7dba38
+
+   HMAC-SHA-512-256 = cb370917ae8a7ce28cfd1d8f4705d614
+                      1c173b2a9362c15df235dfb251b15454
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 15]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   Test Case AUTH512-3:
+   Key =          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+                  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa  (64 bytes)
+
+   Data =         dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddddddddddddddddddddddddddddddd
+                  dddd                              (50 bytes)
+
+   PRF-HMAC-SHA-512 = 2ee7acd783624ca9398710f3ee05ae41
+                      b9f9b0510c87e49e586cc9bf961733d8
+                      623c7b55cebefccf02d5581acc1c9d5f
+                      b1ff68a1de45509fbe4da9a433922655
+
+   HMAC-SHA-512-256 = 2ee7acd783624ca9398710f3ee05ae41
+                      b9f9b0510c87e49e586cc9bf961733d8
+
+
+   Test Case AUTH512-4:
+   Key =          0a0b0c0d0e0f10111213141516171819
+                  0102030405060708090a0b0c0d0e0f10
+                  1112131415161718191a1b1c1d1e1f20
+                  2122232425262728292a2b2c2d2e2f30
+                  3132333435363738393a3b3c3d3e3f40  (64 bytes)
+
+   Data =         cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
+                  cdcd                              (50 bytes)
+
+   PRF-HMAC-SHA-512 = 5e6688e5a3daec826ca32eaea224eff5
+                      e700628947470e13ad01302561bab108
+                      b8c48cbc6b807dcfbd850521a685babc
+                      7eae4a2a2e660dc0e86b931d65503fd2
+
+   HMAC-SHA-512-256 = 5e6688e5a3daec826ca32eaea224eff5
+                      e700628947470e13ad01302561bab108
+
+
+
+
+
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 16]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+3.  Security Considerations
+
+   In a general sense, the security provided by the HMAC-SHA-256+
+   algorithms is based both upon the strength of the underlying hash
+   algorithm, and upon the additional strength derived from the HMAC
+   construct.  At the time of this writing, there are no practical
+   cryptographic attacks against SHA-256, SHA-384, SHA-512, or HMAC.
+   However, as with any cryptographic algorithm, an important component
+   of these algorithms' 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 the algorithm implementation, but these
+   in no way verify the correctness (or security) of the surrounding
+   security infrastructure.
+
+3.1.  HMAC Key Length vs Truncation Length
+
+   There are important differences between the security levels afforded
+   by HMAC-SHA1-96 [HMAC-SHA1] and the HMAC-SHA-256+ algorithms, but
+   there are also considerations that 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 that can only be
+   determined through offline attacks on observed values, and 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
+   192, or 256 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
+   that 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
+
+
+
+Kelly & Frankel             Standards Track                    [Page 17]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+   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 provide
+   more security in this regard than HMAC-SHA1-96.
+
+4.  IANA Considerations
+
+   This document does not specify the conventions for using SHA256+ for
+   IKE Phase 1 negotiations, except to note that IANA has made the
+   following IKE hash algorithm attribute assignments:
+
+   SHA2-256:  4
+
+   SHA2-384:  5
+
+   SHA2-512:  6
+
+   For IKE Phase 2 negotiations, IANA has assigned the following
+   authentication algorithm identifiers:
+
+   HMAC-SHA2-256:  5
+
+   HMAC-SHA2-384:  6
+
+   HMAC-SHA2-512:  7
+
+   For use of HMAC-SHA-256+ as a PRF in IKEv2, IANA has assigned the
+   following IKEv2 Pseudo-random function (type 2) transform
+   identifiers:
+
+   PRF_HMAC_SHA2_256  5
+
+   PRF_HMAC_SHA2_384  6
+
+   PRF_HMAC_SHA2_512  7
+
+   For the use of 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:
+
+   AUTH_HMAC_SHA2_256_128  12
+
+   AUTH_HMAC_SHA2_384_192  13
+
+   AUTH_HMAC_SHA2_512_256  14
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 18]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+5.  Acknowledgements
+
+   Portions of this text were unabashedly borrowed from [HMAC-SHA1] and
+   [HMAC-TEST].  Thanks to Hugo Krawczyk for comments and
+   recommendations on early revisions of this document, and thanks also
+   to Russ Housley and Steve Bellovin for various 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.
+
+   [HMAC-TEST]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
+                224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
+                RFC 4231, December 2005.
+
+   [IKE]        Harkins, D. and D. Carrel, "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [IKEv2]      Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+                RFC 4306, December 2005.
+
+   [SHA2-1]     NIST, "FIPS PUB 180-2 'Specifications for the Secure
+                Hash Standard'", 2004 FEB, <http://csrc.nist.gov/
+                publications/fips/fips180-2/
+                fips180-2withchangenotice.pdf>.
+
+   [SHA256+]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+                (SHA and HMAC-SHA)", RFC 4634, July 2006.
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 19]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+6.2.  Informative References
+
+   [SHA2-2]     NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
+                2001 MAY,
+                <http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.
+
+Authors' Addresses
+
+   Scott G. Kelly
+   Aruba 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             Standards Track                    [Page 20]
+
+RFC 4868        HMAC-SHA256, SHA384, and SHA512 in IPsec        May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Kelly & Frankel             Standards Track                    [Page 21]
+