Summary

  • AES-XCBC-MAC-96 sends the first 96 bits of a 128-bit result as an IPsec authenticator. RFC 3664 used the full 128 bits as IKE’s PRF output instead.
  • RFC 4434 kept that output and the result for 128-bit keys, but removed the single-size key restriction. IKEv2 uses fixed-length semantics for key generation and variable-length semantics for shared-secret authentication.

One construction, three lengths

The important number in this history is not just “128 bits.” In RFC 3566, AES-XCBC-MAC-96 calculates a 128-bit value and sends only its leftmost 96 bits in an ESP or AH authenticator. The receiver calculates the full value and compares those same 96 bits. That shortened field is designed for packet authentication; it is not the whole result the construction can produce. RFC 3566

IKE had a different use for a pseudo-random function. Its output feeds key creation, so RFC 3664 argued that a 96-bit PRF output was too short for long-lived use in IKEv1 or IKEv2. Its adjustment was deliberately narrow: take the AES-XCBC construction and omit the final truncation. The result is a 128-bit PRF output. This does not mean every key produced by IKE is 128 bits; the output is an input to protocol-specific key derivation. RFC 3664

RFC 3664 initially carried over another rule from AES-XCBC-MAC-96: the key had to be exactly 128 bits. The PRF had a full-width output, but a fixed-size input key. For IKE implementations whose shared secret was not that length, the specification boundary was awkward. The later memo did not change the 128-bit result for a 128-bit key. It changed how input keys were normalized before the AES-based operation. RFC 3664 metadata and errata RFC 3664 errata

The 2006 correction was about the input

RFC 4434 removed the exactly-128-bit restriction and made the conversion explicit. A 128-bit key is used unchanged. A shorter key is padded on the right with zero bits until it reaches 128 bits. For a key of 129 bits or more, the PRF is applied again with an all-zero 128-bit key and the longer key as its message; that output becomes the normalized key. The long-key path is not ordinary truncation and should not be described as a general-purpose hash. RFC 4434

That change matters because “same algorithm” can hide two questions: what bytes go on the wire, and what inputs implementations agree to accept. RFC 4434 says 128-bit keys keep the same wire results as RFC 3664. Other lengths are no longer rejected; they are converted to a 128-bit AES key under the new rule. The specified output remains the untruncated 128-bit XCBC value, not the 96-bit ESP/AH authenticator. RFC 4434 metadata and errata RFC 4434 errata

IKEv2 gave the key two jobs

The successor then drew a distinction inside IKEv2. When AES-XCBC-PRF-128 generates keying material, it is treated as a fixed-length PRF: the IKEv2 procedure divides contributions between the two nonces as specified. When the same PRF authenticates a shared secret, RFC 4434 treats it as variable-length, so the secret need not itself be 128 bits. The memo calls this logic “somewhat tortured”; its stated purpose is interoperability between implementations following RFC 3664’s fixed-key rule and those using the more flexible rule. RFC 4306 RFC 4434

This is a small standards revision with a consequential boundary. A PRF can have one output width while the protocol assigns different input-key semantics to different uses. Reading “128” as a universal key size collapses the distinction; reading the 96-bit MAC field as the PRF output collapses a second one. RFC 8221’s later ESP/AH recommendations concern packet-authentication algorithms, not proof of IKE PRF negotiation or implementation behavior. RFC 8221

The record shows a correction to an interface contract, not evidence that a particular implementation failed or that the updated rule became universal in deployed systems. RFC 4434 kept the full-width result, preserved the 128-bit-key case, and spelled out how shorter and longer inputs should reach AES. The history sits in those separate steps: truncate a MAC for a packet field; retain the full value for IKE’s PRF; normalize a key according to the job it performs.

Sources