Summary

  • A successful EAP method can establish a bounded authentication result, while policy, AAA attributes, authenticator action and the lower-layer data path still have separate outcomes.
  • A defensible access record preserves the method transcript, outer EAP result, RADIUS packet, authorization decision, key handoff, secure association and first usable connectivity as distinct receipts.

The most revealing EAP failure is not always a bad password. Imagine a peer completing a strong certificate-based method. The backend accepts the credential. A success indication appears in the method transcript. The user nevertheless reaches no network because a session limit denies authorization, the requested VLAN is unsupported, the key reaches the wrong authenticator, or the lower-layer secure association never completes. “Authentication succeeded” remains true at one layer and dangerously incomplete as a description of the session.

That separation is built into RFC 3748, the 2004 Standards Track definition of the Extensible Authentication Protocol. Bernard Aboba is one of its five authors, alongside Larry Blunk, John Vollbrecht, James Carlson and editor Henrik Levkowetz. The attribution matters because the architecture was collective and deliberately modular: EAP is an authentication framework, not a universal access-control system.

Three roles make the first boundary visible. The peer responds on the link. The authenticator initiates EAP and controls the local access point. The EAP server terminates the method. When the authenticator operates in pass-through mode, the server can sit on a backend AAA system while the authenticator relays messages it does not itself understand. A successful method result can therefore be produced far from the device that will open or close the data path.

RFC 3748’s terminology resists a convenient shortcut. It notes that an authenticated peer can still be denied access for policy reasons such as a session limit, and that AAA proxies may influence authorization. Its definition of successful authentication encompasses the decisions of both sides, but its discussion of protected results makes clear that method authentication alone is not always enough to establish willingness to provide access. The useful distinction is not a semantic trick. It is a map of where different operators make different decisions.

The outer success packet is a small receipt

After a method completes successfully, the authenticator sends an EAP packet with Code 3. That packet contains no additional data. It is not acknowledged and is not retransmitted. A peer can sometimes use an appropriate lower-layer success indication when the EAP Success packet was lost. Those rules make the signal practical over links, but they also limit what an isolated packet capture can prove.

An EAP Success proves neither the policy attributes the backend returned nor the local action the authenticator took. A captured packet cannot show by itself that a controlled port opened, that an address was configured, that traffic keys were installed, or that an application exchange crossed the link. Conversely, absence of the packet does not prove failure if the method exchanged protected success indications and the lower layer supplied an allowed success signal. The surrounding state matters.

The protocol also rejects a canned Success sent immediately on connection when the method does not permit completion. That rule blocks a rogue authenticator from bypassing the method conversation. It is another warning against reading the visible four-byte result code without its preceding method state.

RADIUS carries a different verdict

Aboba and P. Calhoun’s RFC 3579 describes a common pass-through arrangement. The NAS encapsulates EAP messages in RADIUS until the server returns Access-Accept or Access-Reject. The NAS must base its access-control decision on that RADIUS packet type, not on an EAP message embedded inside it.

The specification even describes contradictory combinations. An Access-Reject carrying EAP Success should not be sent, but if it arrives, the NAS denies access while the peer may believe authentication succeeded. An Access-Accept carrying EAP Failure can split the conclusions in the opposite direction. The correct lesson is not that such combinations are normal. It is that the EAP result and the AAA authorization verdict are separate fields with separate consumers, and disagreement must remain visible rather than being repaired by inventing a new packet.

Access-Accept itself ends the authentication phase. It may carry instructions for a service, VLAN, filter, priority or limit. A NAS that knows the requested service but cannot provide it must treat the request as failure. A backend can also return different authorizations for different authenticators. The same verified credential can therefore lead to different legitimate outcomes as location, equipment capability, entitlement or session state changes.

Exported keys are not an installed data path

RFC 5247, coauthored by Aboba, Dan Simon and P. Eronen, stretches the evidence chain beyond the method. A key-generating EAP method can export a Master Session Key. The AAA system can transport keying material to the authenticator. A lower-layer secure-association protocol then derives or installs transient keys for actual traffic.

Those are three events, not one. The existence of an MSK does not prove that it reached the intended authenticator, remained inside its authorized scope, produced the expected transient key, or protected a completed association. Server identifiers can also differ between outer and inner exchanges, and a peer may not know in advance which backend server will handle the conversation. Key names, recipients, scope and association identifiers belong in the audit record.

RFC 3748 adds a further demand: after EAP, the lower layer should bind protected data traffic to the entities that completed authentication. Per-packet integrity, authentication and replay protection need to be connected to the EAP-derived keys. Without that binding, later data can be modified, spoofed or replayed even though the authentication transcript looked correct.

The network name can still be wrong

Credentials may be valid across several services. That creates a different risk: a malicious or misconfigured authenticator can advertise one network while connecting the peer to another. RFC 6677 calls this the lying NAS or lying provider problem. Channel binding lets the peer send protected observations about the advertised service so the EAP server can compare them with information received from and stored about the authenticator.

Channel binding is not a slogan that the peer “knows the network”. It is a comparison protocol with named inputs and a result. The record should retain what the peer saw, what the NAS claimed, what the backend expected and which protected method carried the comparison. Without those fields, a valid credential and a strong method can still end at the wrong service.

RFC 5216 supplies the certificate version of the same boundary. EAP-TLS implementations validate the certificate path, but they must also decide whether the represented identities are appropriate and authorized for EAP-TLS in the deployment context. Cryptographic validity is an input to authorization, not a universal replacement for it.

Build the access receipt in order

A useful operational ledger begins before authentication: discovered network name, peer intent, authenticator identity and access port. It then records the chosen EAP method, the protected method result, peer and server identifiers, the outer EAP result, the RADIUS packet type, authorization attributes and the NAS’s local support decision. Key export, key recipient, secure-association transcript and installed-key identifiers follow. Only then come controlled-port state, IP configuration, first usable connectivity and accounting or later disconnect records.

Each element answers a narrower question than “Did the user get online?” That granularity is the point. It can distinguish a rejected credential from a valid credential denied by policy, a successful authorization from an unsupported service, and a completed method from a missing data-path key.

Sources