Summary

  • RFC 5216 defines certificate-based EAP-TLS authentication and key derivation. A valid chain, CertificateVerify and Finished messages establish narrow cryptographic facts; they do not install a VLAN, open a controlled port or prove application delivery.
  • EAP, AAA and lower-layer specifications preserve the distinction. Authorization may be denied after authentication, an authenticator may be unable to provide an authorized service, and possession of EAP keying material does not by itself prove authority to hold it.
  • Operations need a joined receipt chain from certificate policy through EAP result, AAA decision, NAS enforcement and observed traffic. A single green “certificate accepted” state should never inherit the authority of every later stage.

Four green events and one closed port

At 08:14:02 in a deliberately constructed access event, the peer validates the EAP server’s certificate path and name. The server validates the peer certificate. CertificateVerify proves possession of the corresponding private keys. Finished binds both sides to the negotiated TLS transcript. The cryptographic console turns green.

At 08:14:03 the backend evaluates the authenticated certificate identity together with the NAS, port and requested service. It returns a conditional authorization for a particular role and VLAN. A second console turns green.

At 08:14:04 the edge discovers that the requested local service is unavailable. The VLAN is not present in the required forwarding context, so the device cannot enact the authorization. The controlled port remains closed. No DHCP exchange begins, no IPv6 neighbour state forms and no application packet crosses the edge.

At 08:14:20 an executive dashboard built from the first two events reports “EAP-TLS success.” The statement is not fabricated. It is incomplete in exactly the dangerous way: it promotes valid evidence about identity and policy intent into a claim about delivered access.

This is not a report of a real vendor, operator or outage. It is a synthesis of boundaries made explicit across RFC 5216, RFC 3748, RFC 3579 and the EAP key-management framework. The edge case matters because every component can behave correctly while a flattened status remains wrong.

What the certificate actually proves

RFC 5216 defines EAP-TLS as an EAP method using TLS for certificate-based mutual authentication, integrity-protected cipher-suite negotiation, key exchange and key derivation. In a full mutual exchange, certificate-path validation answers whether the presented certificate chains to an accepted trust anchor under the verifier’s policy. CertificateVerify answers whether the endpoint can produce a valid signature with the corresponding private key. Finished answers whether both sides reached the same protected handshake transcript and secrets.

Those are powerful facts. They deserve to be recorded precisely rather than inflated. A certificate subject or SAN can supply authenticated identity material for policy. It does not contain the live state of a switch port, the current capacity of a VLAN, the installation result of an ACL, the integrity of a AAA proxy chain or the reachability of an application.

The distinction became clearer as EAP-TLS evolved. RFC 8996 deprecated TLS 1.0 and 1.1. RFC 9190 defined TLS 1.3 use and changed the handshake and key schedule while retaining RFC 5216 as the base for older negotiated versions. RFC 9965 later added provisioning work around eap.arpa. None of those updates turns cryptographic authentication into an omniscient service monitor.

RFC 9190 is especially direct. Its Authorization section applies to EAP-TLS generally, not only TLS 1.3. Authorization and accounting must rest on authenticated information such as certificate or PSK identity and provisioned resumption state, not the unauthenticated EAP-Response/Identity alone. The EAP-TLS server may also combine that information with facts supplied by the enclosing protocol: authenticator identity, MAC or IP address, port, SSID and other context.

That is not a loophole in authentication. It is the architecture acknowledging that authentication supplies inputs to policy rather than consuming every decision that follows.

EAP already warned against the single green light

RFC 3748 separates authentication-result synchronization from authorization synchronization. Its examples are operationally exact. The EAP server may not see an authorization decision made by a AAA proxy. A AAA server may wait until authentication has succeeded before discovering that authorization cannot be granted. The backend may grant access while the authenticator is temporarily unable to provide it.

Each case defeats a dashboard that treats method completion as delivered connectivity. In the first, the party that made the policy decision is elsewhere. In the second, identity proof is valid while permission is denied. In the third, permission is valid while the enforcement point lacks the requested service.

RFC 4137 models EAP peer and authenticator state machines and their signals to the lower layer. A state-machine output is still an interface event. It says what the EAP machine concluded; it does not secretly poll the switching fabric, address assignment or application path.

The familiar EAP-Success packet therefore needs a bounded reading. It is not worthless, and it is not necessarily public access. It belongs to a protocol conversation whose result still meets AAA policy and lower-layer action. The absence of that distinction is how “certificate accepted,” “authentication passed,” “access granted,” “port open” and “service usable” collapse into one ambiguous counter.

The key exists before its authority is complete

EAP-TLS derives a Master Session Key and Extended Master Session Key. Their freshness and binding matter. Yet RFC 5247 deliberately splits the journey into phases: the EAP method derives material between peer and server; AAA transports appropriate material to the authenticator; a secure-association protocol proves possession and builds transient keys.

The framework then states the crucial limit: proof of possession of keying material does not necessarily prove authorization to hold it. A four-way handshake can show that peer and authenticator possess the same EAP-derived material. By itself, that exchange does not prove the backend authorized this authenticator to receive it.

RFC 4962 makes peer and authenticator authorization a separate requirement. RFC 4017 likewise lists mutual authentication, key strength and authorization as distinct requirements for wireless LAN use. RFC 5295 constrains EMSK-derived root keys by usage and scope rather than treating possession as universal permission.

This is an unusually useful design lesson. Cryptography can prove that a component has a key. It cannot, without additional policy and provenance, prove that the component was entitled to receive the key for this peer, service, location and time. Random-looking bytes do not carry organizational authority inside them.

An Access-Accept is an instruction to a particular edge

In a common pass-through design, the NAS carries EAP between the peer and backend RADIUS service. RFC 3579 distinguishes RADIUS Access-Accept and Access-Reject from the encapsulated EAP material. An Access-Reject requires denial. An Access-Accept closes the authentication phase and can carry authorizations for the edge to apply.

But the edge is not a passive printer. RFC 3579 says a NAS unable to offer a requested service must treat an Access-Accept requesting that unavailable service as an Access-Reject. RFC 3580 warns that a RADIUS packet type and an encapsulated EAP Success or Failure can conflict; the authenticator must base access control on the RADIUS result rather than blindly following the inner packet.

The returned role, VLAN, filter or session limit is therefore a policy instruction whose success must be observed where it is executed. A backend log can prove that it emitted the instruction. It cannot prove that the receiving NAS recognized every attribute, had the required local resource, installed the exact policy or opened the controlled port.

Nor does the edge’s claim prove the final service. A port can be authorized while DHCP fails. A station can receive an address while DNS fails. A path can carry probes while the intended application is denied. Each later layer earns its own receipt.

The NAS can tell two stories

The gap is not limited to missing VLANs. RFC 6677 exists because a pass-through authenticator can describe one network to the peer and another to the AAA infrastructure—the “lying NAS” or “lying provider” problem. Channel binding lets peer and server compare their views of relevant network properties over protected transport.

That mechanism confirms a broader principle: the peer certificate does not authenticate every fact advertised by the access network. SSID, port, visited provider, lower-layer type and service properties have separate sources. They may inform authorization only when their provenance and consistency are checked.

Channel binding itself is not a delivery receipt. It can validate defined context before the peer suffers the consequences of joining an adversarial network. It does not show that the selected VLAN later forwarded, that a firewall admitted the application or that the service remained available five minutes later.

RFC 7542 constrains Network Access Identifier handling. RFC 9427 updates how TLS 1.3 is used across TLS-based EAP types. These documents improve the identities and protocol transitions in the chain; they do not erase the chain.

Resumption preserves a relationship, not every privilege

TLS 1.3 resumption reduces round trips and can avoid repeated certificate work. RFC 9190 says an accepted resumption is authenticated and securely associated with the earlier authentication or resumption. It also requires caution so a resumed session is not granted more privilege than intended for the original session.

The warning matters because several clocks diverge. A ticket can remain cryptographically valid while a certificate is revoked, a device changes role, an employee loses access, a NAS moves, an SSID changes policy or a VLAN is withdrawn. Certificate validity, revocation status, ticket lifetime, authorization lifetime, port session and application result are not one timer.

RFC 9190 also strengthens revocation handling for TLS 1.3 and discusses OCSP stapling because a peer may not have general connectivity until authentication completes. That circularity is operationally revealing: the system sometimes needs carefully provisioned evidence before the network is available. Successful bootstrap still does not prove the network delivered everything after it opened.

Build a receipt chain that can fail honestly

An auditable EAP-TLS deployment should join narrow receipts without allowing one to impersonate the next.

The certificate receipt records trust anchor, exact leaf and chain hashes, validated name, validity window, revocation method and result. The TLS receipt records negotiated version and suite, CertificateVerify result, Finished result and a safe session identifier. Secrets remain secret.

The EAP receipt records method, protected result, exported key identifiers and EAP Success or Failure. The AAA receipt records authenticated peer identity, NAS identity, port and network context, policy version, Access-Accept or Reject and exact authorization attributes. The key-transport receipt records which authenticator was permitted to receive which scoped material.

The enforcement receipt belongs to the NAS. It records attribute recognition, VLAN or role resolution, ACL installation, secure-association completion and controlled-port transition. The service receipt belongs later still: address assignment, neighbour or ARP state, DNS, route, first successful application exchange and failure reason.

This chain should preserve negative states. “Certificate valid; authorization denied” is not a contradictory record. “Access-Accept received; requested service unavailable” is not an embarrassment to be hidden. “Port open; application failed” is not proof that authentication was wrong. Honest separation makes repair faster because it leaves the failed boundary visible.

Sources

  1. RFC 5216
  2. RFC 5216 on Datatracker
  3. RFC 5216 status
  4. RFC 5216 history
  5. RFC 5216 errata
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption