Summary

  • RFC 9867 adds ways to mix preshared keys into IKEv2 through IKE_INTERMEDIATE and CREATE_CHILD_SA, including the use of a fresh PPK when a Child SA or IKE SA is created or rekeyed.
  • A CREATE_CHILD_SA response can omit the PPK identity and still create the new SA under ordinary IKEv2 processing. If that fallback violates the initiator's policy, the initiator may immediately delete what the protocol just created.
  • A per-SA PPK-mixing receipt should distinguish exchange completion, PPK selection and confirmation, authorization, creation, policy acceptance, use and deletion. This is Daniel Kade's editorial proposal, not an RFC or IETF mandate.

A green “SA created” event appears decisive. There was an authenticated control channel, the exchange returned, key material was derived, and a new pair of identifiers entered the system. Operations software can count it. A migration dashboard can report it. An auditor can find the record months later and infer that the stronger policy was applied.

RFC 9867 supplies a harder fact: the same created state can be reached without the preshared key that motivated the exchange. That is not necessarily an error. It can be the specified result when PPK use is optional, the responder lacks support or configuration, no offered identity matches, or the two sides associate different values with what looks like the same identity. Protocol progress and protection evidence diverge at exactly the moment a simple dashboard would merge them.

Two extensions, not one quantum-safe label

IKEv2 already has several distinct moments at which cryptographic state can change. The base protocol defines the initial IKE SA, the authenticated exchange, the creation of Child SAs and the rekeying of both Child and IKE SAs. A statement that “the tunnel uses a PPK” omits which SA, which exchange and which derivation produced the keys.

RFC 8784 introduced one way to mix a PPK into IKEv2 session keys. Its design assumes use during initial establishment and preserves a boundary that later work addresses: it does not use the PPK to protect the initial IKE SA itself. RFC 9867 does not erase that mechanism. It defines additional paths.

The first uses IKE_INTERMEDIATE, the pre-authentication exchange defined separately in RFC 9242. An initiator can offer PPK identities; a responder can select one and return a confirmation. Mixing occurs before IKE_AUTH, so the PPK can contribute to the protection of the initial IKE SA and its authentication exchange. When other intermediate key exchanges are also present, the PPK operation must be the last key recalculation before the next exchange. Order is therefore part of the security claim, not an implementation footnote.

The second path uses CREATE_CHILD_SA. It allows a fresh PPK to contribute when a Child SA is created or rekeyed, or when the IKE SA itself is rekeyed, without requiring the entire existing relationship to be torn down. This makes rotation operationally possible. It also creates multiple lineages beneath one long-lived control relationship. The older IKE SA, an existing Child SA, a new Child SA and a rekeyed IKE SA cannot inherit one undifferentiated “PPK protected” badge.

RFC 9370's multiple-key-exchange work and RFC 9838's post-quantum hybrid terminology provide important context, but neither resolves this evidence problem. An algorithm list describes available ingredients. A negotiated exchange describes an event. Neither alone proves which contribution reached the keys for one particular SA.

Identity, matching and authorization are separate

RFC 9867 uses two registered IKEv2 notifications. USE_PPK_INT announces the extension, and PPK_IDENTITY_KEY carries the identity and related confirmation material. IANA records them as notify values 16445 and 16446. Those visible protocol elements support evidence, but they are not the secret and should not be treated as a licence to record it.

The confirmation is derived as the first eight octets of the negotiated pseudorandom function over defined context. It lets the exchange detect the case in which two peers select what appears to be the same PPK identity but hold different PPK values. That is a stronger statement than a configuration match. It is still narrower than complete authorization.

During IKE_INTERMEDIATE, the responder may have to select a PPK before it knows the authenticated identity of the initiator. Once authentication reveals that identity, local policy might say that the selected PPK was not appropriate for this peer. RFC 9867 says the responder should abort in that situation, while allowing continuation if local policy permits it. Possession of matching material and permission to use that material are therefore separate decisions, made with different information at different times.

This boundary is easy to lose in automation. A key-store lookup can say “found.” The confirmation can say “same value.” Authentication can say “this peer.” Policy must still say whether that peer is allowed to establish this SA using that PPK. A single success boolean cannot preserve the sequence.

The SA that succeeds before it fails policy

The sharpest case occurs in CREATE_CHILD_SA. An initiator asks to use a fresh PPK. The responder may not implement the extension, may not be configured for it, may not recognize an offered identity, or may associate a different value with the matching identity. In those cases, its response omits PPK_IDENTITY_KEY, and ordinary IKEv2 processing can nevertheless produce the new SA.

If PPK use was optional for the initiator, that new SA may be accepted and used. If PPK use was mandatory, the same created SA is inappropriate. The initiator may delete it immediately. Both systems behaved consistently with the protocol, yet the lifecycle contains a transient object that a creation counter will misclassify.

Three timestamps are now material: when the SA was created, when local policy evaluated the absence of PPK evidence, and when the SA was deleted or accepted. Packet outcome matters too. Did any protected traffic use the SA before deletion? Did a failover system route traffic through it? Did the peer continue to believe it existed after the initiator removed it? The standard defines the exchange behavior; an operator still owns the evidence needed to answer its operational questions.

“Mandatory” also needs an owner and scope. It can be a policy for one peer, one traffic class, one rekey operation or one migration phase. It is not a property that can be inferred from the presence of PPK-capable software. Optional fallback may be deliberate interoperability policy. The governance failure is not that fallback exists. It is reporting fallback as if the stronger state had been proven.

A receipt for the key transition, not the key

The PPK-mixing receipt proposed here is an editorial control record. It is not an IETF field and should never contain the PPK secret.

For each newly created or rekeyed SA, record the exchange type and the parent IKE-SA lineage. Identify whether the event followed RFC 8784 or one of the RFC 9867 paths. Retain a non-secret PPK identity or privacy-preserving fingerprint, the offered and selected state, the confirmation result, and the moment peer authentication became available. Record the applicable mandatory-or-optional policy on each side as far as it is locally knowable, plus the decision owner and policy version.

Then record derivation order. If multiple intermediate exchanges changed the key material, was the PPK operation last as required for this path? Bind the receipt to the resulting SA identifiers without pretending that identifiers themselves prove protection. Preserve created, accepted, installed, observed-in-use and deleted as separate states. Add the reason for fallback or deletion, the exception owner, the rollback decision and the next review time.

This record has to respect an observability limit. A network trace can show notifications and traffic, but it may not prove private key-schedule state inside an implementation. An implementation event can attest that a contribution was applied without exposing it. Cross-vendor assertions require carefully scoped trust. The receipt should say which component made each observation and which parts remain inferred.

The minimum useful question is not “did IKE succeed?” It is: for this SA, under this lineage and policy, what evidence shows that the intended PPK contribution entered the correct derivation at the correct time, and what happened to the SA after the local decision?

Migration claims should close at the SA boundary

The post-quantum motivation deserves precision. RFC 9867 explains that symmetric primitives are not currently believed to face the same risk from a cryptographically relevant quantum computer as the public-key mechanisms under discussion. Mixing a strong PPK before authentication can therefore add a protection path. That statement is not a prediction that a capable machine exists, a timetable for one, or a certificate that a product or deployment is quantum safe.

Freshness also has a narrow meaning here. The mechanism is useful when a different PPK contributes to the new or rekeyed SA; invoking it with the same old PPK offers no point in that rotation. Operational key custody, entropy, distribution and compromise response remain outside what exchange completion alone can prove.

The strongest migration report will therefore avoid fleet-wide adjectives. It will count exact SAs, exact paths and exact outcomes. Some may be protected through RFC 8784. Some may use the RFC 9867 intermediate path. Some may use fresh PPKs on rekey. Some may validly fall back under optional policy. Some may be created and then deleted because mandatory policy was not satisfied. That is not messy data to compress. It is the actual decision surface.

Protocol design often permits progress because a network must keep operating across uneven implementation and policy. Governance must preserve what kind of progress occurred. RFC 9867 gives operators a flexible transition mechanism. It does not let them turn “created” into evidence that was never collected.

Sources