Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
Extracted elements (23)
AES CCM with explicit IV has approximately one-third the overhead of AES CBC mode: 64 bits for the IV versus a full block (128 bits) plus average half-block padding for CBC. The overhead is also constant per packet rather than variable.
An explicit IV field was chosen over reusing the ESP sequence number to decouple per-packet counter block assignment from sequence number assignment. This accommodates architectures where sequence number assignment occurs outside the assurance boundary, where a counter block collision would have disastrous consequences unlike a sequence number collision.
The explicit IV allows the encryptor to use adders, LFSRs, or any other technique that ensures uniqueness, giving implementers flexibility in constant-time vs. variable-time choices without affecting decryptor complexity.
Implementations MUST support a nonce of 11 octets (15 minus L=4).
Implementations MUST support an L value of 4 octets for the CCM length field, which accommodates a full IPv6 Jumbogram.
Implementations MUST support ICV sizes of 8 octets and 16 octets; implementations MAY also support 12 octets. The AES CCM ICV is carried in the Authentication Data field without further encryption.
Implementations MUST support M values of 8 octets and 16 octets for the ICV; implementations MAY support an M value of 12 octets. Only M values that are a multiple of four and at least eight are permitted.
Implementations MUST use fresh keys with AES CCM. Static keys are inappropriate; IKE or IKEv2 SHOULD be used to establish fresh keys.
KEYMAT MUST be three octets longer than needed for the AES key. For 128-bit key: 19 octets (16 key + 3 salt); 192-bit: 27 octets; 256-bit: 35 octets. The trailing 3 octets are the salt.
The AES CCM IV field in the ESP payload MUST be eight octets and MUST be chosen by the encryptor to ensure uniqueness per key.
The default AES key size is 128 bits and implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
The ESP Padding, Pad Length, and Next Header fields MUST be concatenated with the plaintext before encryption. When padding is required, it MUST be generated and checked per ESP conventions.
The Key Length attribute MUST be specified in the IKE Phase 2 exchange and MUST have a value of 128, 192, or 256 bits.
The salt field in the nonce MUST be assigned at the beginning of the security association and MUST NOT be predictable prior to SA establishment, though it need not be secret.
The same IV and key combination MUST NOT be used more than once. AES CCM counter mode reuse is catastrophic, immediately leaking plaintext information.
Packet expansion from AES CCM consists solely of the 8-octet IV prepended to the payload and the ICV (8, 12, or 16 octets) appended. Total overhead is 16 to 24 octets.
IANA assigned three ESP Transform Identifiers for AES CCM with explicit IV: 14 (8-octet ICV), 15 (12-octet ICV), and 16 (16-octet ICV).
AES-128 is vulnerable to birthday attacks after 2^64 encrypted blocks. With ESN allowing up to 2^64 packets per SA, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted or SHOULD use longer AES key sizes (192 or 256 bits).
Counter block reuse with the same key is catastrophic: XORing the same key stream with two different plaintexts allows an attacker who obtains both ciphertexts to recover P1 XOR Q1, from which the individual plaintexts can be separated.
When a single key is used for both directions (not IKE-established), peers have a high probability of selecting the same IV, causing counter block collisions. Implementations permitting same-key bidirectional use MUST ensure the two peers assign different salt values to the SA.
AAD for 32-bit sequence numbers is 8 octets: 4-octet SPI followed by 4-octet sequence number. AAD for 64-bit extended sequence numbers is 12 octets: 4-octet SPI followed by 8-octet ESN (high-order 32 bits first).
The ESP payload for AES CCM is structured as: 8-octet Initialization Vector, followed by variable-length Encrypted Payload, followed by variable-length Authentication Data (ICV).
The nonce is 11 octets: a 24-bit (3-octet) Salt followed by the 64-bit (8-octet) Initialization Vector. The salt occupies bits 8-31 of the counter block and the IV occupies bits 32-95.