Summary

  • RFC 9678 authenticates an optional ECDHE exchange inside EAP-AKA' and derives MSK, EMSK and re-authentication material from the resulting shared secret.
  • Its protection for ended past sessions assumes that endpoints have deleted every relevant ephemeral and session key; the protocol transcript cannot prove that operational fact.
  • A credible assurance chain records policy, negotiated algorithms, authenticated completion, downstream key use, session end, every retention surface, destruction and an independent recovery test.

The stored capture and the missing receipt

Imagine a packet capture placed in a restricted archive today. Years later, the long-term key associated with the subscriber is exposed. The incident team replays the old authentication evidence and sees a reassuring fact: the session negotiated the RFC 9678 extension. AT_KDF_FS selected a supported construction, AT_PUB_ECDHE carried ephemeral public values, and the transcript passed its message-authentication checks.

That record answers a precise question. It shows that the peer and server agreed to an ECDHE-influenced key hierarchy under an authenticated EAP-AKA' exchange. It does not show whether the peer kept its private scalar in a crash image, whether the authentication service cached the MSK, whether a gateway exported a session key to diagnostics, or whether a snapshot preserved a recoverable copy after the session was declared closed.

The incident team has evidence of negotiation. It does not yet have evidence of nonrecoverability.

That distinction is the operational centre of RFC 9678. Forward secrecy is often presented as a property of a handshake. In practice it is a property of a completed handshake plus a successful lifecycle: ephemeral contribution, derived-key use, session retirement and destruction of all material whose survival would reopen the past.

What RFC 9678 changes

RFC 9678 was published in March 2025 as a Proposed Standard. It updates the improved Extensible Authentication Protocol method for Authentication and Key Agreement, EAP-AKA', defined by RFC 9048 and preceded by RFC 5448. The extension is optional. It adds ephemeral Elliptic Curve Diffie-Hellman to a method whose trust model otherwise rests heavily on a long-term symmetric key held by the subscriber side and the home-network side.

The threat is temporal. Without an independent ephemeral contribution, an adversary who records protected traffic and later obtains the long-term subscriber key may be able to reconstruct historical session material. RFC 9678 changes the derivation so that the long-term key alone is insufficient for ended sessions that used the extension.

The server sends one or more AT_KDF_FS attributes and an AT_PUB_ECDHE attribute. The peer chooses a supported forward-secrecy KDF under the RFC's ordering rules and returns its public value. The document defines X25519 and P-256 choices. IANA assigns the new attribute types 152 and 153.

The attributes are not loose hints. They are covered by AT_MAC, using authentication material from the existing EAP-AKA' exchange. A network observer cannot silently replace a public value or algorithm selection and still produce the valid transcript expected by the endpoints. The resulting shared secret contributes to MK_ECDHE; the hierarchy then produces K_re, MSK and EMSK.

This is substantive cryptographic work. It is also bounded work. The MAC authenticates the exchange, not the future state of endpoint storage.

Authentication success is not one security outcome

Because the extension is optional, a green authentication result has at least two materially different histories. One session may complete with EAP-AKA' FS. Another may ignore the extension and complete using ordinary EAP-AKA'. Both can be valid authentications; only the first obtains the additional protection against later long-term-key exposure.

Peer and server policies decide whether that difference is acceptable. An operator may permit fallback because older equipment cannot use the extension. Another may require forward secrecy and fail authentication when no mutually supported option exists. RFC 9678 describes how the peer behaves when policy requires the extension, but it does not choose one universal availability-versus-protection answer for every network.

This makes aggregate success rate a misleading executive metric. A migration can show 99.99 per cent successful authentication while a significant legacy population silently remains outside the new property. Conversely, a strict policy can reduce successful access because it refuses a cryptographically weaker path. Neither outcome can be understood from the success counter alone.

An honest dashboard separates capability, offer, selected KDF, authenticated completion, fallback and policy-required failure. It names ordinary EAP-AKA' as ordinary EAP-AKA', rather than borrowing the label of a feature that was merely available somewhere in the estate.

The RFC states the deletion condition

The most important sentence in the security analysis is conditional. An attacker who later obtains the long-term key should not obtain session keys of ended past sessions, assuming those sessions deleted all relevant session key material.

That assumption reaches beyond the wire. An endpoint must destroy the ephemeral private value and the relevant derived session keys. The obligation can extend through process memory, key-management services, hardware accelerators, access gateways, re-authentication caches, debug exports, core dumps, swap, hibernation images, backups and forensic snapshots. A deletion API call in the EAP implementation proves little if another component still owns a copy.

Even the phrase “session ended” needs a defined authority. The EAP method can complete or retire while a lower-layer association remains active. A mobility event can create overlapping contexts. A subscriber database, tunnel endpoint and radio-access element can apply different timers. A process can exit while its dump remains in object storage.

For each key class, an operator needs to know which component can create a copy, which event starts retirement, how long each copy may survive, what mechanism makes it unusable, and how exceptions are exposed. Without that inventory, “deleted” is an aspiration applied to an unknown set.

Re-authentication inherits; it does not repeat

The extension also protects re-authentication material through K_re when the original full authentication used the ECDHE-derived hierarchy. This is valuable, but it is easy to describe incorrectly.

EAP-AKA' re-authentication under RFC 9678 does not perform a new Diffie-Hellman exchange. It inherits security from the original full authentication. A succession of fresh-looking access events can therefore depend on one older ephemeral agreement and on retained re-authentication state.

Monitoring should record the age and reuse count of that state. A policy may force a new full authentication after time, movement, software change or a number of reuses. Calling every re-authentication “fresh ECDHE” would hide the actual cryptographic history and the retention period of K_re.

The downstream path decides the practical gain

EAP exports MSK and EMSK; readers care about the traffic and access associations built from them. That downstream context changes the extension's marginal value.

If IKEv2 later performs its own ephemeral Diffie-Hellman exchange and supplies forward secrecy to a tunnel, EAP-AKA' FS may add a smaller increment for that traffic path. Where link-layer protection or another consumer depends directly on the EAP outputs without an independent forward-secret exchange, the new contribution can be decisive.

The protocol label therefore needs a consumer receipt. Which MSK instance was exported? Which access association consumed it? Did a second handshake add its own forward secrecy? When did that association end? Which downstream device retained key material? A completed EAP exchange without this mapping cannot prove the protection of the data plane named in a board report.

Against which attacker?

RFC 9678 is not a shield against every possession of the long-term key. An active attacker who already holds that key and is present during the current authentication can attack the live exchange and eavesdrop on resulting traffic. The extension's central promise concerns a later compromise: the attacker obtains the long-term secret after an earlier protected session has ended and after relevant session material has been destroyed.

Time must therefore appear in every assurance claim. “The method has forward secrecy” is too broad. A defensible claim identifies the session, confirms the extension, identifies the consumer, establishes an end event, closes the retention inventory and states which later compromise scenario was tested.

A ladder from packet evidence to nonrecoverability

Start with policy receipts from both peer and server: was the extension required, preferred or optional, and was fallback allowed? Record supported algorithms and software versions. Preserve the ordered offer, selected KDF, public values and authenticated completion without retaining private secrets.

Then record that the ECDHE contribution entered the defined hierarchy and bind non-secret identifiers for the MSK, EMSK and K_re contexts to their consumers. Label any fallback explicitly. Record each system's session-end event rather than inventing one universal timestamp.

Build the custody inventory for key material. Destruction receipts must cover every component, not only the EAP process. Retention exceptions—debug logs, snapshots, legal holds or forensic images—belong in the claim instead of outside it.

Finally, conduct an authorized recovery exercise after retirement. Give the test the archived transcript and the later-exposed long-term material. A failed recovery, under a stated scope, is stronger evidence than a configuration flag. It still is not metaphysical proof: the test covers known artifacts and defined techniques. But it joins the protocol claim to the operating reality it depends on.

Publication, adoption and running code

RFC 9678 is a minimum interoperable specification. It defines attributes, algorithms, negotiation and derivation. Local implementations decide availability, fallback, memory handling, retirement and evidence. Publication establishes a common option; it does not establish that a device supports it. Support does not establish that a session selected it. Selection does not establish that every copy was destroyed.

This is the useful hierarchy in Heng Lu's running-code lens. The code point is a coordination artifact. The authenticated transcript is protocol evidence. The endpoint's memory and key handles are implementation reality. The downstream association is operating reality. The recovery exercise is evidence about the historical outcome. Leadership language sits above them and must not collapse them into one green icon.

Forward secrecy becomes credible when every layer carries its own receipt. RFC 9678 supplies an important first half of that chain. Operations must prove the second.

Sources