Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec

This 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 AH , ESP , IKE , and 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.

and describe the underlying SHA-256, SHA-384, and SHA-512 algorithms, while 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.

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: 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. 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. 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.

HMAC-SHA-256+ are secret key algorithms. While no fixed key length is specified in , 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 (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.

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 ): If the length of the key is exactly the algorithm block size, use it as-is. 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 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. 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.

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.

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.

Currently, there are no practical attacks against the algorithms recommended here, and especially against the key sizes recommended here. However, as noted in "...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.

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 as part of the underlying SHA-256, SHA-384, and SHA-512 algorithms, so if you implement according to , 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 , no implicit packet padding is required.

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 . 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. 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.

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.

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

The following table serves to summarize the various quantities associated with the HMAC-SHA-256+ algorithms. In this table, "var" stands for "variable".

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.

These test cases were borrowed from RFC 4231 . For reference implementations of the underlying hash algorithms, see . Note that for testing purposes, PRF output is considered to be simply the untruncated algorithm output.

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+].

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.

There are important differences between the security levels afforded by HMAC-SHA1-96 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.

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: 4 5 6 For IKE Phase 2 negotiations, IANA has assigned the following authentication algorithm identifiers: 5 6 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: 5 6 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: 12 13 14

Portions of this text were unabashedly borrowed from and . 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.