The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
Extracted elements (22)
AES-GMAC is defined as an ESP 'combined mode' (encryption transform) rather than an integrity transform because ESP provides no mechanism for integrity transforms to place an IV within the Payload field; defining it as an encryption transform avoids this limitation and enables the same pipelining as AES-GCM.
All three AES key sizes (128, 192, 256 bits) are supported to mirror AES-GCM-ESP (RFC 4106), reusing that specification's design experience, and to provide future users with high-security options.
ENCR_NULL_AUTH_AES_GMAC is NOT equivalent to AES-GCM-ESP with encryption turned off: in AES-GMAC-ESP the entire ESP Payload is in the AAD (with zero-length plaintext), whereas in AES-GCM-ESP only SPI and Sequence Number are in the AAD and the Payload is the GCM plaintext.
ENCR_NULL_AUTH_AES_GMAC MUST NOT be used in conjunction with any other ESP encryption transform within a particular ESP encapsulation. If confidentiality is desired, GCM ESP (RFC 4106) SHOULD be used instead.
For AH, each AES key length has its own integrity transform identifier; the IKE Key Length attribute MUST NOT be used with AH identifiers, and these AH transforms MUST NOT be used with ESP.
For ESP (ENCR_NULL_AUTH_AES_GMAC), the IKE Key Length attribute MUST be used with each invocation of the transform identifier to indicate key length (128, 192, or 256 bits).
Implementations MUST use an automated key management system, such as IKE (either version), to ensure that the nonce uniqueness requirement is met, because statically configured keys make it difficult to use AES-GMAC securely.
Implementations SHOULD use an IKE Phase 1 cipher at least as strong as AES-GMAC; AES-CBC (RFC 3602) with the same key size as the GMAC transform is RECOMMENDED for Phase 1.
The ICV consists solely of the AES-GMAC Authentication Tag and MUST NOT be truncated; the ICV length is therefore fixed at 16 octets.
The KEYMAT size for ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_GMAC MUST be four octets longer than the AES key size, with the trailing four octets used as the nonce salt value (20, 28, or 36 octets for 128-, 192-, or 256-bit keys respectively).
The same nonce and key combination MUST NOT be used more than once, since reusing a nonce/key combination destroys the security guarantees of AES-GMAC.
AES-GMAC is defined as the special case of AES-GCM in which the plaintext has zero length, producing only an Authentication Tag as output. It provides data origin authentication without confidentiality for use in IPsec ESP and AH.
ENCR_NULL_AUTH_AES_GMAC is defined as an ESP 'combined mode' algorithm rather than an integrity algorithm, registered in IKEv2 as an encryption (Type 1) transform. It performs no encryption and provides no confidentiality.
Packet expansion from ENCR_NULL_AUTH_AES_GMAC is 8 octets for the IV plus 16 octets for the ICV, totaling 24 octets of GMAC-specific overhead, plus the standard 10-13 bytes of ESP header/trailer fields.
IANA assigned IKEv2 integrity (Type 3) transform identifiers 9, 10, and 11 for AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, and AUTH_AES_256_GMAC respectively, and encryption (Type 1) transform identifier 21 for ENCR_NULL_AUTH_AES_GMAC.
GMAC is provably secure under standard cryptographic assumptions (block cipher output under a random key is indistinguishable from random output); a break of GMAC implies a break of the underlying AES cipher. The proof is available in [GCMP].
Implementations MUST generate a fresh key before processing 2^64 blocks of data under a given key, to prevent gradual degradation of security inherent in block cipher modes. This limit cannot be reached when using 32-bit sequence numbers.
The most important security requirement is that the IV never repeats for a given key. Statically configured keys are prohibited; IKE MUST be used. When using a single shared key for bidirectional traffic (non-IKE), peers MUST ensure different salt values to avoid counter block collisions.
In AUTH_AES_GMAC (AH mode), the AH Authentication Data field contains both the 8-octet IV and the 16-octet ICV (Authentication Tag), for a total of 24 octets. No padding is required because 24 octets is a multiple of 64 bits.
The AAD for ENCR_NULL_AUTH_AES_GMAC covers SPI, Sequence Number (32-bit or 64-bit extended), Authenticated Payload, Padding, Pad Length, and Next Header. Two AAD formats are defined corresponding to the two sequence number sizes.
The AES-GMAC nonce is 12 octets: a 4-octet Salt field (assigned at SA establishment, SHOULD be unpredictable) followed by the 8-octet Initialization Vector. The salt remains constant for the life of the security association.
The Initialization Vector (IV) in ENCR_NULL_AUTH_AES_GMAC is placed at the outset of the ESP Payload field and MUST be eight octets long. For a given key, the IV MUST NOT repeat.