The Use of HMAC-SHA-1-96 within ESP and AH
Extracted elements (15)
A key length of 160-bits was chosen based on RFC-2104 recommendations: key lengths less than the authenticator length decrease security strength, while keys longer than the authenticator length do not significantly increase security strength.
SHA-1 was never developed to be used as a keyed hash algorithm, whereas HMAC had that design criteria from the onset, making the HMAC wrapper essential for security rather than optional.
The authenticator length of 96 bits was selected because it is the default authenticator length specified in the AH specification and meets the security requirements described in RFC-2104.
As of the time of writing, there are no known issues which preclude the use of the HMAC-SHA-1-96 algorithm with any specific ESP cipher algorithm.
RFC-2104 outlines an implementation modification that can improve per-packet performance without affecting interoperability with other HMAC-SHA-1-96 implementations.
A strong pseudo-random function MUST be used to generate the required 160-bit key for HMAC-SHA-1-96.
For use with either ESP or AH, a fixed key length of 160-bits MUST be supported. Key lengths other than 160-bits MUST NOT be supported.
HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding requirements are specified in FIPS-180-1 and are part of the SHA-1 algorithm; no implicit packet padding is required as defined in AH.
HMAC-SHA-1-96 produces a 160-bit authenticator value which is truncated to the first 96 bits for storage in the authenticator field of ESP or AH. Upon receipt, the full 160-bit value is computed and the first 96 bits are compared to the stored value.
For a 64-byte block hash such as HMAC-SHA-1-96, a birthday attack would require successfully processing 2**80 blocks, which is infeasible unless the underlying hash had collisions after processing only 2**30 blocks.
If weak keys for HMAC are ever identified, use of those weak keys must be rejected and replacement keys or a newly negotiated Security Association must be requested. At the time of writing, no weak keys for HMAC were specified.
Periodic key refreshment is a fundamental security practice recommended for HMAC-SHA-1-96 to guard against potential weaknesses, reduce information available to cryptanalysts, and limit damage from exposed keys, even though current attacks do not indicate a specific rekeying frequency.
Security strength depends on the correctness of the algorithm implementation, key management security, strength of the secret key, and correctness of all participating system implementations. RFC-2202 provides test vectors to verify HMAC-SHA-1-96 correctness.
The security of HMAC-SHA-1-96 is based upon the strength of HMAC and, to a lesser degree, SHA-1. At the time of writing there were no practical cryptographic attacks against HMAC-SHA-1-96.
The HMAC-SHA-1-96 authenticator field carries the first 96 bits (12 bytes) of the 160-bit HMAC-SHA-1 output, stored upon sending and compared upon receipt.