HMAC-SHA-2 for IPsec: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
Using the SHA-2 hash family to authenticate and protect IPsec traffic.
Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
@misc{rfc4868,
series = {Request for Comments},
number = 4868,
howpublished = {RFC 4868},
publisher = {RFC Editor},
doi = {10.17487/RFC4868},
url = {https://www.rfc-editor.org/info/rfc4868},
author = {S. Kelly and S. Frankel},
title = {{Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec}},
pagetotal = 21,
year = 2007,
month = may,
} RFC text
Contents
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.
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
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
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.
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".
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.
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.
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
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
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
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+].
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
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
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
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
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
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
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
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.
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
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.
ISO Plain Language
On this page
§1What the RFC Specifies
The document specifies the use of SHA-256, SHA-384 and SHA-512 combined with HMAC as data origin authentication and integrity verification mechanisms for the IPsec Authentication Header, the IPsec Encapsulating Security Payload, IKE and IKEv2. Output truncation is specified for these variants, and the truncated algorithms are named HMAC-SHA-256-128, HMAC-SHA-384-192 and HMAC-SHA-512-256. The truncation lengths follow the birthday bound of each algorithm.
The document also describes untruncated variants of the same algorithms used as pseudo-random functions for IKE and IKEv2, named PRF-HMAC-SHA-256, PRF-HMAC-SHA-384 and PRF-HMAC-SHA-512. The PRF algorithms and the authentication variants are called the HMAC-SHA-256+ algorithms throughout, where the plus sign means the family of algorithms built on SHA-256 and the larger hashes.
The two uses have different aims. The PRF variants provide secure pseudo-random functions for generating keying material and other protocol-specific numbers, while the authentication variants make sure that packets are authentic and cannot be modified in transit. In both cases the security depends on how the secret key is distributed and how unpredictable it is. If the key is unpredictable and known only to the sender and the recipient, then only parties holding the same key can derive the values that go with it.
The RFC covers two uses of the same hash functions. One produces a short tag that travels with a packet, so the receiver can check that nothing changed it. The other produces a long stream of unpredictable bits, used to make the keys that IPsec runs on. Both are only as safe as the key they use.
§2.1The Keys
Three sizes matter and the document defines them precisely. The block size is the size of the data block the underlying hash works on, which is 512 bits for SHA-256 and 1024 bits for SHA-384 and SHA-512. The output length is the size of the hash value, which is 256 bits for SHA-256, 384 bits for SHA-384 and 512 bits for SHA-512. The authenticator length is the size of the authenticator in bits after truncation, and in this specification it is always half the output length of the hash.
For the authentication and integrity use, the key length is fixed. HMAC itself does not fix a key length, but this specification requires that a key length equal to the output length of the hash must be supported and that no other key length may be supported, so 256 bits for HMAC-SHA-256, 384 for SHA-384 and 512 for SHA-512. The reason is in part the advice in the HMAC document itself, that keys shorter than the output length reduce the strength while longer keys do not add much, and in part that variable key lengths would make IPsec implementations disagree with each other.
For the PRF use, key lengths may vary, and the rules for handling a key of any length follow the HMAC document. A key whose length is exactly the block size is used as it is. A shorter key is lengthened to the block size by padding it on the right with zero bits, which the document notes is a case HMAC discourages but which is described here because pre-shared keys for IKE and IKEv2 are often shorter. A key longer than the block size is shortened by computing the hash of the whole key and using that result as the key, which then needs the zero padding described above.
The key itself must come from a strong pseudo-random function, and no weak keys for these algorithms were known when the document was written. The key distribution mechanism has to make sure that unique keys are allocated and handed only to the parties taking part in the communication. The document also recommends refreshing keys periodically, as the HMAC document does, because it limits the damage of a key that is exposed. It notes that a brute force attack on a 256, 384 or 512-bit key would take longer than the universe has existed, while a weak key such as a dictionary word would be far easier to guess, so the lifetime chosen for a key has to take that into account.
When the hash checks a packet, the key must be exactly as long as the hash output: 256, 384 or 512 bits. When the hash generates keys, the key may be any length, and it is padded or hashed to fit. The key itself has to be random, and it has to be replaced from time to time so that a leak does not do lasting harm.
- Authenticator keysFixed length, equal to the hash output: 256, 384 or 512 bits.
- PRF keysAny length, hashed or padded with zeros to the block size.
- Key generationMust come from a strong pseudo-random function.
- Key distributionUnique keys, given only to the parties in the communication.
- RefreshingReplace keys periodically to limit the damage of a leak.
§2.2Padding and Truncation
HMAC with SHA-256 works on 512-bit blocks, and HMAC with SHA-384 or SHA-512 works on 1024-bit blocks. The padding rules are those of the SHA-2 standard itself, so an implementation that follows that standard needs to add nothing further for these algorithms. As far as the implicit packet padding defined for the Authentication Header is concerned, no implicit packet padding is required.
Each algorithm produces a value whose length is the output length of the hash, for example 256 bits for HMAC-SHA-256. For use as an authenticator, that value may be truncated. When the algorithm is used as a data origin authentication and integrity verification mechanism in ESP, AH, IKE or IKEv2, a truncated value using the first nnn/2 bits, exactly half the algorithm output, must be supported, and no other authenticator lengths are supported by this specification.
The sending side stores the truncated value in the authenticator field. The receiving side computes the whole nnn-bit value and compares the first nnn/2 bits with what was stored. The length of half the output was chosen because it corresponds to the birthday attack bound of each algorithm, and at the same time it keeps the number of extra bits on the wire small.
The tag that travels with a packet is half the size of the hash output: 128 bits for SHA-256, 192 for SHA-384 and 256 for SHA-512. The sender puts the first half of the hash in the packet, and the receiver computes the full hash and compares the same half. Half is as much as the birthday bound allows.
§2.4The Two Forms and Their Parameters
PRF-HMAC-SHA-256 is the same algorithm as HMAC-SHA-256-128 except that variable-length keys are permitted and the truncation step is not performed. PRF-HMAC-SHA-384 and PRF-HMAC-SHA-512 are the same as HMAC-SHA-384-192 and HMAC-SHA-512-256 in the same way: variable-length keys are permitted and no truncation is done. So the difference between the two families is only the key length rule and whether the output is cut in half.
The document also states that as of writing there are no known issues that prevent the HMAC-SHA-256+ algorithms from being used with any specific cipher algorithm.
The parameter summary in Section 2.6 gives, for each of the six algorithms, the block size, the output length, the truncation length, the key length and the algorithm type, where var stands for variable. For HMAC-SHA-256-128 the block size is 512, the output 256, the truncation 128 and the key 256, and the type is authentication and integrity. HMAC-SHA-384-192 has block size 1024, output 384, truncation 192 and key 384, and HMAC-SHA-512-256 has block size 1024, output 512, truncation 256 and key 512. The three PRF variants have the same block sizes and output lengths, no truncation, and a variable key length.
The same hash is used in two ways. As an authenticator the key must have a fixed length and the output is cut in half. As a pseudo-random function the key may be any length and the output is used whole. Beyond that the two forms behave identically.
| Algorithm | Block size | Output | Truncated to | Key | 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.7Test Vectors
The document gives test cases for each algorithm, each with a key, some data and the resulting authenticator or PRF value. The keys and the data are written either as ASCII strings in double quotes or as hexadecimal numbers. When a value is an ASCII string, the HMAC computation does not include the trailing null character of the string, and the computed values are all hexadecimal.
The PRF test cases are borrowed from RFC 4231. The first one uses the 20-byte key 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b and the data "Hi There", and gives PRF-HMAC-SHA-256 as b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7, PRF-HMAC-SHA-384 as afd03944d84895626b0825f4ab46907f15f9dadbe4101ec682aa034c7cebc59cfaea9ea9076ede7f4af152e8b2fa9cb6, and PRF-HMAC-SHA-512 as 87aa7cdea5ef619d4ff0b4241a1d6cb02379f4e2ce4ec2787ad0b30545e17cdedaa833b7d6b8a702038b274eaea3f4e4be9d914eeb61f1702e696c203a126854. For testing purposes the PRF output is taken to be the untruncated algorithm output.
The authenticator test cases give the key, the data, the untruncated PRF value and the truncated authenticator side by side, so an implementation can check both. For example, with the 64-byte key of all 0a through 40 bytes and 50 bytes of cd data, PRF-HMAC-SHA-512 is 5e6688e5a3daec826ca32eaea224eff5e700628947470e13ad01302561bab108b8c48cbc6b807dcfbd850521a685babc7eae4a2a2e660dc0e86b931d65503fd2, and the HMAC-SHA-512-256 authenticator is the first half of that value.
The document lists worked examples so that an implementation can check that it computes the same values. Each example gives a key, some data and the expected output, both in full and cut in half.
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
PRF-HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7§3Security Considerations
The security of the HMAC-SHA-256+ algorithms rests on the strength of the underlying hash algorithm and on the extra strength the HMAC construction adds. When the document was written there were no practical cryptographic attacks against SHA-256, SHA-384, SHA-512 or HMAC. As with any cryptographic algorithm, though, a large part of the strength comes from the correctness of the implementation, the security of the key management mechanism, the strength of the secret key and the correctness of the implementation in every participating system.
The document is careful about what its test vectors prove. They help an implementer check that the algorithm computes the right values, but they do not in any way verify the correctness or the security of the surrounding security infrastructure.
The hash functions themselves were not broken when this was written. The real risk lies elsewhere: a wrong implementation, a badly managed key, or a weak key. The worked examples check the arithmetic, not the setup around it.
§3.1Key Length Against Truncation Length
The document compares the new algorithms with the older HMAC-SHA1-96 and finds the comparison less clear-cut than it may appear. There are two axes on which the security is judged: the length of the HMAC output and the length of the HMAC key.
If the key is a well-guarded secret that can only be found by offline attacks, and its length is no greater than the output length of the hash, then the strength of the key is directly proportional to its length. If the attacker knows nothing of the key, then the chance of guessing a correct tag for any given packet is directly proportional to the length of the HMAC output.
On the second axis, the document says plainly that it is not clear that HMAC-SHA-256 truncated to 128 bits is any more secure than HMAC-SHA1 truncated to the same length, for an attacker who knows nothing of the key. Such an attacker has to predict only the bits that survive the truncation, and both algorithms leave 128 bits, so the odds of a correct guess are 1 in 2^128 either way. Only a bias in one of the algorithms would separate them, and no such bias is known in either HMAC-SHA1 or HMAC-SHA-256+.
On the first axis the answer is different. If the attacker is trying to guess the key, and the hash functions are indistinguishable when viewed as pseudo-random functions, then the key length is a direct measure of the security, because a longer key is harder to guess. Here the HMAC-SHA-256+ algorithms give more security than HMAC-SHA1-96, since a longer key is harder to find by an offline attack on observed values.
There are two ways an attacker can get in: guess the tag on a packet, or guess the key. Against the first, a 128-bit tag is just as good whether the hash is SHA-1 or SHA-256, because the attacker only has to match the 128 bits that are kept. Against the second, the longer keys of the SHA-2 algorithms make a real difference, because a longer key takes longer to find.
§4IANA Assignments
The document does not specify the conventions for using SHA-256 and the larger hashes in IKE phase 1 negotiations, but it records the assignments IANA has made. For the IKE hash algorithm attribute, SHA2-256 has the value 4, SHA2-384 the value 5 and SHA2-512 the value 6. For IKE phase 2 negotiations, the authentication algorithm identifiers are HMAC-SHA2-256 as 5, HMAC-SHA2-384 as 6 and HMAC-SHA2-512 as 7.
For use as a pseudo-random function in IKEv2, the transform identifiers of type 2 are PRF_HMAC_SHA2_256 as 5, PRF_HMAC_SHA2_384 as 6 and PRF_HMAC_SHA2_512 as 7. For use as data origin authentication and integrity verification in IKEv2, ESP or AH, the transform identifiers of type 3 are AUTH_HMAC_SHA2_256_128 as 12, AUTH_HMAC_SHA2_384_192 as 13 and AUTH_HMAC_SHA2_512_256 as 14.
The document lists the numbers that name these algorithms when two systems negotiate them: the hash values used in the first phase of IKE, the authentication values used in the second phase, and the transform identifiers used by IKEv2.