Summary

  • RFC 9930 lets an accepted TEAP resumption bypass Phase 2 entirely, but the shortcut is valid only when the ticket still carries the authenticated credential and authorization state that the server needs now.
  • If new credentials cannot be associated with a ticket, the server must invalidate the ticket and force full reauthentication; cryptographic continuity is not a durable access entitlement.

Authentication systems like remembered work. A completed handshake can be expensive, and repeating inner methods whenever a user or machine reconnects can load the same identity store many times a day. RFC 9930 therefore makes resumption mandatory to support in TEAP and describes it as a material gain in scalability and stability. The gain is real precisely because an accepted resumption does less.

TEAP normally has two phases. Phase 1 uses TLS to build an authenticated, protected tunnel. Phase 2 then carries inner methods and TLVs that can authenticate a user, a machine or both; provision or replace a credential; bind inner methods to the tunnel; and exchange protected results. RFC 6678 supplies the design requirements behind a standard tunnel-based EAP method, while RFC 3748 supplies the wider EAP roles and result model. These layers are related, but they are not interchangeable.

That distinction becomes decisive at one sentence in RFC 9930: when the server agrees to resume, Phase 2 is bypassed entirely. If it declines, a full TLS handshake is followed by Phase 2. Resumption may use server-side cached state or client-side ticket state of the kind defined by RFC 5077. Under TLS 1.3, RFC 8446 uses NewSessionTicket to establish PSK-related state for a future connection. None of those objects contains an automatic declaration that every later access condition is still true.

There is an earlier trap. TLS 1.3 can issue NewSessionTicket after the client's Finished message, before a tunneled EAP method has completed its inner authentication. RFC 9427 treats that timing gap as a potential authentication bypass. A server must not allow a ticket to resume authentication unless the inner method completed successfully. It should delay ticket issue, or invalidate and discard tickets associated with failure. If the server cannot determine inner-authentication status from the ticket, it must assume the work was not completed and run the inner methods before granting access.

Successful inner work also has structure. RFC 9930 requires Intermediate-Result and Crypto-Binding after successful inner methods. The Compound MAC lets the peer and server verify participation in the same tunnel and authentication sequence. It can expose a substitution or binding failure. It does not choose a VLAN, role, ACL, account state or permitted service. A successful Result TLV can still be challenged by a peer whose authentication policy is unsatisfied, and the server's response remains a policy decision.

The harder problem begins after a perfectly valid initial session. Phase 2 can provision or change credentials. RFC 9930 consequently requires subsequent authorization to use the authenticated credentials rather than an anonymous or different Phase 1 identity. The correct authorization must survive resumption as well: new credentials must be associated with the session ticket. If the association cannot be made, the server must invalidate the current session's tickets. The next connection then takes the longer route through full authentication so a current authorization basis can be attached to any replacement ticket.

RFC 9190 generalizes the temporal risk. Peer data, authenticator information and surrounding protocol context can change between the original handshake and resumption. When a changed input could alter authorization, accounting or policy, the decision must be reevaluated. If no safe decision is possible, rejecting resumption and continuing with a full handshake is the recommended boundary. The seven-day TLS 1.3 ticket ceiling is not a seven-day authorization grant; a younger ticket can already be stale.

An operator therefore needs more than a resumption counter. Preserve a hash of the ticket or Session ID; its issuer, issue and expiry times; the source full session; inner-authentication completion; authenticated credential IDs and versions; policy and authenticator context; intervening changes; the reevaluation result; and the accept, reject or invalidate reason. Then record the current authorization separately from the network access server's enforcement receipt and from packet or service observations. RFC 5247 helps identify the EAP key and identity context, but it does not collapse those later facts into the authentication exchange.

This is the minimum-specification bargain described in Heng Lu's work. A shared ticket should carry only the bounded state necessary for interoperability. Future decisions remain localized and accountable. Running code must show which state was actually consulted, and the reality layers must stay visible: ticket, authenticated credential, current policy, authorization, enforcement and outcome. Resumption is most trustworthy when the system can explain what it did not repeat—and why that omission was safe.

Sources