Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
updates
- rfc-4306 — Internet Key Exchange (IKEv2) Protocol
Extracted elements (25)
192-bit AES keys are NOT RECOMMENDED throughout this document (both for key length and for AEAD_* algorithm specification) in order to reduce the number of options and simplify interoperability. No AEAD_* algorithms for 192-bit AES keys are specified.
IKEv1 separates encryption from data integrity (via separate Hash or Signature Payloads), which prevents use of authenticated encryption. IKEv2 was designed with an Encrypted Payload that associates encryption and integrity protection together (modeled on ESP), enabling AEAD algorithm usage that is impossible with IKEv1.
This document adopts the RFC 5116 interface where authenticated encryption produces a single ciphertext (C) output incorporating the integrity check, rather than the separate ciphertext and ICV outputs used by RFC 4106/4309. For AES GCM and AES CCM, the RFC 5116 C output is simply the concatenation of the RFC 4106/4309 ciphertext and ICV.
AES GCM usage in IKEv2 uses the same 12-octet nonce format as specified for AES GCM with ESP in RFC 4106, providing compatibility between IKEv2 and ESP usage. Similarly, AES CCM in IKEv2 uses the same 11-octet nonce format as specified for AES CCM with ESP in RFC 4309.
The IKEv2 ENCR Transform Identifiers for AES GCM and AES CCM (14–16, 18–20) were previously allocated by IANA for ESP; this document extends their use to IKEv2 without requiring new IANA allocations. Each AEAD_* algorithm in Section 10.3 corresponds exactly to a specific ENCR Identifier + Key Length Attribute combination.
A 16-octet ICV size SHOULD be used with IKEv2 as appropriate to IKEv2's key exchange functionality. Use of 12-octet ICVs (identifiers 15 and 19) is NOT RECOMMENDED; if an ICV larger than 8 octets is needed, 16-octet ICVs SHOULD be used.
For AES CCM, implementations MUST support ICV sizes of 8 octets and 16 octets, MAY also support 12-octet ICVs, and MUST NOT support other ICV lengths.
For AES GCM, implementations MUST support a full-length 16-octet ICV, MAY support 8 or 12-octet ICVs, and MUST NOT support other ICV lengths.
For AES GCM with the IKEv2 Encrypted Payload, the default nonce format MUST be used and a 12-octet nonce MUST be used. For AES CCM, the default nonce format MUST be used and an 11-octet nonce MUST be used.
Padding MAY contain any value chosen by the sender, and the recipient MUST accept any amount of Padding up to 255 octets. There are no alignment requirements on the Padding field length.
The Initialization Vector (IV) MUST be eight octets for AES GCM and AES CCM. The IV MUST be chosen by the encryptor such that the same IV value is used only once for a given key.
When AES GCM or AES CCM is used with the IKEv2 Encrypted Payload, the SK_ai and SK_ar integrity protection keys are not used; each key MUST be treated as having a size of zero (0) octets.
When an authenticated encryption algorithm is selected for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. If all encryption algorithms in a proposal are authenticated encryption algorithms, the proposal MUST NOT propose any integrity transforms.
When any AES GCM or AES CCM identifier is used, the Key Length attribute MUST be specified with a value of 128, 192, or 256. Use of 192-bit keys is NOT RECOMMENDED; if a key larger than 128 bits is appropriate, a 256-bit AES key SHOULD be used.
AEAD_AES_128_CCM_SHORT uses AES-128 CCM with an 11-octet nonce (q=3), 16-octet authentication tag, K_LEN=16, P_MAX=2^24-1 octets, A_MAX=2^64-1 octets; ciphertext is exactly 16 octets longer than plaintext.
Data integrity coverage via authenticated encryption encompasses the entire IKEv2 message: associated data (A) covers the IKE header through the Encrypted Payload header; the IV is implicitly covered by the integrity check (a successful check verifies the correct IV was used); and the plaintext (payloads, padding, pad length) is covered by the AEAD integrity check.
For AES GCM with a 128-bit AES key, each SK_ei/SK_er encryption key is 20 octets: a 16-octet AES cipher key followed by 4 octets of salt. For AES CCM with a 128-bit key, each key is 19 octets: 16-octet cipher key followed by 3 octets of salt.
IKEv2 ENCR Transform Identifiers for AES CCM: 14 (8-octet ICV), 15 (12-octet ICV), 16 (16-octet ICV). For AES GCM: 18 (8-octet ICV), 19 (12-octet ICV), 20 (16-octet ICV). These identifiers were previously allocated for ESP and are reused for IKEv2.
Ten AEAD_* algorithm variants are defined for IKEv2: four AES GCM variants with 8- and 12-octet ICVs (AEAD_AES_128/256_GCM_8/12), and six AES CCM SHORT variants using an 11-octet nonce (instead of the 12-octet nonce in RFC 5116) with 8, 12, and 16-octet ICVs for both 128- and 256-bit key sizes.
This document adds 10 new entries to the IANA Authenticated Encryption with Associated Data (AEAD) Parameters Registry: AEAD_AES_128_GCM_8 (id 5), AEAD_AES_256_GCM_8 (6), AEAD_AES_128_GCM_12 (7), AEAD_AES_256_GCM_12 (8), AEAD_AES_128_CCM_SHORT (9), AEAD_AES_256_CCM_SHORT (10), AEAD_AES_128_CCM_SHORT_8 (11), AEAD_AES_256_CCM_SHORT_8 (12), AEAD_AES_128_CCM_SHORT_12 (13), AEAD_AES_256_CCM_SHORT_12 (14).
The IV MUST be unique per key to prevent nonce reuse, which would catastrophically compromise AES GCM and AES CCM security. The encryptor MAY use any method ensuring uniqueness, such as a counter or LFSR. All security considerations from RFC 5116, RFC 4106 (Section 10), and RFC 4309 (Section 9) apply; use of AES GCM/CCM with IKEv2 does not create additional security considerations beyond those for ESP.
The Associated Data (A) MUST consist of the IKEv2 message starting from the first octet of the Fixed IKE Header through the last octet of the Encrypted Payload's Payload Header (the fourth octet of the Encrypted Payload), including any payloads between the IKE Header and the Encrypted Payload. The IV and Ciphertext fields MUST NOT be included.
The IKEv2 Encrypted Payload for authenticated encryption consists of: Next Payload (1 octet), C bit + RESERVED (1 octet), Payload Length (2 octets), followed by an Initialization Vector field (length specified by the algorithm) and a Ciphertext field that incorporates the integrity check. No separate ICV field is present.
The IKEv2 Encrypted Payload plaintext (P) consists of: IKE Payloads to be encrypted, followed by Padding (0–255 octets), followed by a 1-octet Pad Length field indicating the number of padding octets.
The nonce (N) for AES GCM and AES CCM uses a partially implicit format: the implicit portion is a salt from IKEv2 keying material (not included in the payload), and the explicit portion is the IV from the Encrypted Payload. The nonce is constructed by concatenating salt then IV.