Summary

  • A Fast-Reconnect-ID is a server-generated pseudonymous NAI that selects an existing EAP-IKEv2 context. A successful lookup does not prove that the presenter holds the context keys.
  • Fast reconnect succeeds only after protected messages 3 and 4 verify under the prior context, new proposal SPIs and fresh nonces are exchanged, EAP-Success is emitted and fresh MSK/EMSK material is derived. Network authorization, key installation, traffic and service remain later receipts.

The operations screen says FRID matched. The value arrived in an EAP-Response/Identity, the realm routed correctly, and a cache row returned an existing context in two milliseconds. Nothing in that sequence shows that the returning device can use the keys stored in that row.

That distinction is the point of RFC 5106, an Experimental EAP method published in February 2008. EAP-IKEv2 reuses IKEv2 mechanisms for mutual authentication and session-key establishment between an EAP server and an EAP peer. Its fast-reconnect option reduces work after a previous successful full run. It does not replace proof with an identifier.

In a full run, the server acts as IKEv2 initiator and the peer as responder. After the optional ordinary identity request and response, messages 3 and 4 negotiate algorithms, Diffie-Hellman material and nonces. Protected message 5 lets the peer authenticate the server; protected message 6 lets the server authenticate the peer. Only then does message 7 carry EAP-Success and only then may the method generate MSK and EMSK.

The future reconnect handle appears inside that protected history. The server may include a Next Fast-ID, or NFID, payload. NFID contains a Fast-Reconnect-ID, or FRID, formatted as a Network Access Identifier. Its username is obfuscated; its realm remains available for AAA routing. The server creates the pseudonym and retains the mapping to the permanent identity and security context.

FRID therefore answers a narrow question: which stored context should the server attempt to use? It is not the permanent identity, a bearer credential or a new authentication transcript. RFC 5106 recommends a fresh, unique pseudonym with a random component. The operator’s reachable EAP servers must keep username components unique, but the namespace remains operationally scoped. No global authority guarantees that another server will understand the value.

That last limitation matters in clustered deployments. The RFC explicitly says it has no mechanism ensuring that a later exchange reaches the same EAP server that generated the pseudonym. An operator may centralize pseudonym mapping across its home servers. Without that facility, a server that cannot understand the pseudonym can ask for the permanent identity. A routing success and a mapping miss are compatible observations; neither is evidence of an impostor by itself.

The peer also has rules. It may initiate fast reconnect with FRID only if the preceding successful full or reconnect exchange supplied the value in NFID. EAP-Response/Identity is mandatory at the start because it carries the candidate FRID. Once the server receives it, local policy still chooses between fast reconnect and a full exchange. A peer must accept the full message 3 even after requesting the shortcut.

These steps create three different receipts before cryptographic proof begins: identity_presented, context_mapped, and policy_selected. Combining them as “authenticated” destroys the diagnostic boundary. A guessed FRID could map. An expired context could remain in a stale cache. A correct mapping could be rejected by policy. A valid returning peer could land on a server without the mapping.

The actual reconnect uses the previous successful context. Messages 3 and 4 resemble an IKE SA rekey. Their encrypted payloads are constructed and checked with keys from the prior exchange. The server chooses a new non-zero proposal SPI and fresh Ni. If it sends a new Diffie-Hellman value, that value must also be fresh and use the group from the earlier full run. The peer decrypts and integrity-verifies message 3, chooses its own new non-zero proposal SPI and fresh Nr, and protects message 4.

The server must then decrypt and integrity-verify message 4. Only receipt of a correct message 4 makes the run successful. That is the evidence missing from the cache hit. The FRID selected a candidate state record; successful use of the record’s old keys across a fresh protected exchange is what moves the protocol forward.

Freshness is visible in the new session. The reconnect derives SKEYSEED from old SK_d, Ni and Nr, and optional new Diffie-Hellman material. It regenerates the EAP-IKEv2 traffic keys. It then derives 128 octets of KEYMAT from new SK_d and the nonces: the first 64 octets become MSK and the second 64 EMSK. RFC 5106 forbids MSK and EMSK generation unless the protocol run completes successfully.

The identifiers expose the same layered design. A reconnect Session-ID uses EAP method type 49 followed by today’s Ni and Nr, so the run receives a new identifier. Peer-ID and Server-ID, by contrast, are taken from the full exchange that created the stored context. The current session, original authenticated principals and presented FRID are related but not interchangeable keys.

Replay handling follows key epochs rather than the pseudonym alone. RFC 5106 considers an attacker replaying an old protected message 3. After a successful reconnect, the attempt should fail because the context keys changed. An audit system therefore needs the context generation and successful-transition boundary. A log that records only the same FRID on two attempts cannot say whether the second packet was a retransmission, a replay against a rotated context, or a valid attempt using a retained last-known-good identifier.

FRID rotation itself needs a transaction boundary. A peer can fail to save a newly issued value. The server should retain at least the most recently used FRID as well as the most recently issued one. If authentication does not complete successfully, it must not overwrite the identifier from the most recent successful exchange. The rule prevents an unconfirmed rotation from erasing the only reconnect path both parties actually share.

That is an unusually useful operational lesson: “sent” is not “stored”, and “newest” is not “confirmed”. A system that commits the replacement mapping when NFID leaves the server can strand a healthy peer. The durable event is the successful exchange associated with the new state, not the intent to rotate.

EAP-Success is also bounded. It confirms method completion from the server’s perspective. It does not prove that AAA policy authorized a particular network service, that an authenticator received and installed the MSK-derived material, that the lower layer opened, that protected traffic flowed or that the application worked. RFC 5247 treats method key export and key management as a larger chain; RFC 4962 frames requirements for cryptographic key management. Each consumer still needs its own receipt.

The absence of channel binding sharpens the limit. RFC 5106’s security summary says channel binding is not supported. The method can authenticate its peer and server context without proving every property of the access network carrying the exchange. A dashboard must not convert EAP method success into an assertion about the visited network, attachment point or service actually delivered.

Identity confidentiality is similarly qualified. FRID hides the username with a server-generated pseudonym, but the realm remains visible so AAA infrastructure can route the request. That is purposeful pseudonymity, not anonymity. Operational telemetry should hash or otherwise protect FRID while preserving enough realm and generation metadata to diagnose mapping and rollover failures.

The historical cryptographic profile also needs separation from present deployment policy. RFC 5106 required interoperability with a 1024-bit MODP group, 3DES and SHA-1-era transforms drawn from its contemporary IKEv2 profile. The fact that an implementation conforms to that Experimental document does not decide whether those algorithms meet a modern organization’s security requirements. Current acceptance belongs to local crypto policy and must be logged independently.

An evidence model can remain compact if it records transitions rather than prose. For issuance, retain a FRID digest, issuing realm/server, context generation, and the successful exchange that made it authoritative. For an attempt, retain the presented digest, mapping result, policy choice, old-key epoch, new proposal SPIs, Ni/Nr digests, optional DH group, message-3 and message-4 verification, EAP result, exported key handles and Session-ID. Never store raw keys merely to improve observability.

Later systems add later records: AAA decision and policy version, authenticator installation, first protected traffic and service probe. Alerts should name the missing edge: frid_unknown, context_generation_mismatch, message3_integrity_failed, message4_integrity_failed, nonce_reuse, spi_reuse, success_without_key_export, authorized_without_install, or installed_without_traffic.

That vocabulary prevents a fast path from becoming a vague one. A FRID lookup can be fast because it selects existing state. The proof still comes from protected messages and fresh derivation. EAP-Success can be decisive for the EAP method while remaining only one input to network access. The user’s service can fail even when every earlier cryptographic receipt is correct.

Sources