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 20071. 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 20073. 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
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]