Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
Extracted elements (27)
A 32-bit block counter field was chosen despite only 28 bits being needed for the largest IPv6 jumbogram, because a 32-bit field is more convenient for both hardware and software implementations.
AES-CTR overhead (64-bit explicit IV, no padding requirement) is approximately one-third of AES-CBC overhead, which requires a full 128-bit block IV plus average half-block padding. The constant overhead per packet is an additional advantage.
An explicit IV field was chosen over reusing the ESP sequence number field. The ESP extended sequence number (64 bits) was considered as an implicit IV, but an explicit IV was preferred because it decouples per-packet counter block assignment from sequence number semantics, allows any unique-value generation technique (adders, LFSRs), and accommodates FIPS 140 assurance boundary requirements where sequence number assignment may occur outside the boundary.
This document does not specify conventions for using AES-CTR for IKE Phase 1 negotiations; a separate specification and a new Encryption Algorithm Identifier would be needed for Phase 1 use.
A fresh nonce value MUST be assigned for each security association and MUST be assigned at the beginning of the SA. The nonce MUST be unpredictable prior to the beginning of the security association.
AES-CTR implementations MUST employ a non-NULL ESP authentication method, since it is trivial to construct a forged AES-CTR ciphertext from a valid one.
All implementations MUST support the 128-bit AES key size. Implementations MAY also support 192-bit and 256-bit key sizes.
Implementations MUST use AES-CTR in conjunction with an authentication function, such as HMAC-SHA-1-96, because data forgery is trivial with CTR mode alone.
Implementations MUST use fresh keys with AES-CTR. It is inappropriate to use AES-CTR with static keys, as extraordinary measures would be needed to prevent IV reuse across power cycles.
The AES-CTR IV field MUST be eight octets, and the IV MUST be chosen by the encryptor to ensure the same IV value is used only once for a given key.
The Key Length attribute MUST be specified in the IKE Phase 2 exchange with a value of 128, 192, or 256 bits, since AES supports three key lengths.
The KEYMAT requested from IKE MUST be four octets longer than needed for the AES key, with the extra four octets used as the nonce value in the counter block.
The same IV and key combination MUST NOT be used more than once. Any reuse of the per-packet IV with the same nonce and key is catastrophic, immediately leaking information about the plaintext in both packets.
When a 128-bit key is used, implementations MUST use 10 rounds; 192-bit key requires 12 rounds; 256-bit key requires 14 rounds.
AES-CTR encryption XORs plaintext blocks with a key stream generated by AES-encrypting sequential counter block values. The counter block begins as NONCE || IV || ONE and increments by one for each subsequent 128-bit block of key stream.
AES-CTR uses only the AES encrypt operation for both encryption and decryption, making implementations smaller. The final plaintext block may be less than 128 bits; the key stream is truncated to match its length.
For IKE Phase 2, IANA has assigned ESP Transform Identifier 13 for AES-CTR with an explicit IV. This identifier is used in IKE Phase 2 negotiations to select this cipher.
The block counter is a 32-bit big-endian integer starting at one. This construction permits each packet to consist of up to (2^32)-1 blocks (68,719,476,720 octets), sufficient to handle any IPv6 jumbogram.
The nonce is a 32-bit single-use value per security association, providing additional protection against precomputation attacks. The nonce need not be secret but must be unpredictable prior to SA establishment.
IANA assigned ESP Transform Identifier 13 for AES-CTR with an explicit IV.
Data forgery is trivial with CTR mode. An attacker who knows the plaintext can XOR any chosen sequence with the ciphertext, and decryption will yield exactly the attacker's intended plaintext. AES-CTR MUST always be used with ESP authentication.
Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key, because AES ciphertext becomes distinguishable from random values after 2^64 blocks regardless of mode. ESP with Extended Sequence Numbers allows up to 2^64 packets, making this a real concern.
Key stream reuse is catastrophic: if the same counter block values are used for two packets under the same key, XORing the two ciphertexts yields the XOR of the plaintexts, which is sufficient to separate them. Stream ciphers must never be used with static keys.
Precomputation attacks limit the theoretical strength of AES-CTR to 2^(n/2) bits where n is the key length. The unpredictable nonce in the counter block significantly increases the table size an attacker must compute, making longer keys the best countermeasure.
When a mechanism other than IKE establishes only a single key for both peers, there is a high probability of IV collision. ESP implementations that permit the same key for both traffic directions with the same peer MUST ensure the two peers assign different Nonce values.
The 128-bit counter block is structured as: a 32-bit Nonce, a 64-bit Initialization Vector, and a 32-bit Block Counter (big-endian, starting at 1). The counter block is NONCE || IV || ONE.
The ESP payload for AES-CTR consists of an 8-octet Initialization Vector field followed by a variable-length Encrypted Payload, followed by variable-length Authentication Data.