The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
Extracted elements (19)
AES-GCM-ESP uses a 12-octet nonce (4-octet salt + 8-octet IV) rather than the 11-octet nonce used by AES-CCM-ESP, because GCM is specially optimized for 12-octet nonces; other nonce lengths add unnecessary complexity and delay, particularly in hardware. The extra octet enlarges the salt.
AES-GCM-ESP was designed to combine CTR-mode encryption with a parallelizable authentication mechanism, solving the problem that CTR alone provides no data origin authentication and no standard authentication algorithm can be efficiently implemented at high (10–40 Gbps) data rates.
Implementations MUST support a full-length 16-octet ICV, MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. A zero-length ICV is intentionally disallowed because GCM provides no integrity protection with a zero-length Authentication Tag.
Implementations MUST use an automated key management system, such as IKE, to ensure that the nonce/key uniqueness requirement is met, because reuse is difficult to avoid with statically configured keys.
Implementations SHOULD use an IKE Phase 1 cipher at least as strong as AES-GCM. Use of AES-CBC (RFC 3602) with the same key size as AES-GCM-ESP is RECOMMENDED.
Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which will be less than four octets.
The AES-GCM-ESP IV field MUST be eight octets. For a given key, the IV MUST NOT repeat. The encrypter may use any IV generation method (e.g., counter, LFSR) that meets the uniqueness requirement without coordinating with the decrypter.
The Key Length attribute MUST be specified in the IKE Phase 2 exchange and MUST have a value of 128, 192, or 256 (bits), reflecting the three supported AES key sizes.
The KEYMAT for AES-GCM-ESP MUST be four octets longer than the AES key size: 20 octets for 128-bit keys, 28 octets for 192-bit keys, and 36 octets for 256-bit keys. The extra four octets are used as the nonce salt.
The same nonce and key combination MUST NOT be used more than once. Reusing a nonce/key combination destroys the security guarantees of AES-GCM mode.
Packet expansion from AES-GCM-ESP consists of 8 octets for the IV plus 8, 12, or 16 octets for the ICV, in addition to the 10–13 octets for the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields.
IANA assigned three ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV: 18 (8-octet ICV), 19 (12-octet ICV), and 20 (16-octet ICV).
GCM is provably secure against adaptive chosen-plaintext/ciphertext adversaries under standard assumptions; a break of GCM implies a break of AES. The most critical constraint is that the IV must never repeat for a given key.
Implementations MUST generate a fresh key before encrypting 2^64 blocks of data with a given key, as security decreases slightly with each message. This limit cannot be reached when using 32-bit Sequence Numbers.
Smaller ICV values are more susceptible to forgery attacks. Implementations SHOULD use as large an ICV size as reasonable.
When a key establishment mechanism other than IKE is used and only a single key is established for both peers, ESP implementations that permit use of the same key for both encrypting and decrypting MUST ensure the two peers assign different salt values to the SA to avoid counter block collisions.
The 12-octet GCM nonce is formed by concatenating a 4-octet Salt (constant per SA, SHOULD be unpredictable) with the 8-octet Initialization Vector from the ESP payload.
The AAD includes the SPI and either the 32-bit Sequence Number (8 octets total) or the 64-bit Extended Sequence Number (12 octets total), providing integrity protection for those fields without encryption.
The ESP Payload Data consists of an 8-octet Initialization Vector followed by variable-length Ciphertext. The ICV (AES-GCM Authentication Tag) is appended after the ciphertext.