EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3
updated by
- rfc-9965 — The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning
updates
- rfc-5216 — The EAP-TLS Authentication Protocol
Extracted elements (31)
EAP-TLS 1.3 provides mandatory privacy (no cleartext peer identity) without extra round trips because TLS 1.3 encrypts the certificate messages natively. The separate HelloRequest-based privacy handshake required by EAP-TLS with TLS 1.2 is eliminated.
OCSP stapling is mandated for EAP-TLS 1.3 servers because the EAP-TLS peer may not have Internet connectivity before authentication completes, making out-of-band revocation checking infeasible during the handshake. TLS 1.3 improves on earlier versions by carrying OCSP in the CertificateEntry for each certificate rather than a separate CertificateStatus message.
When TLS 1.2 is negotiated, RFC 5216 applies to maintain backwards compatibility. This document only defines differences for TLS 1.3; all message flows shown are specific to TLS 1.3 and do not apply to TLS 1.2.
EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous NAIs. A client supporting TLS 1.3 MUST NOT send its username or any other permanent identifier in cleartext in the Identity Response.
EAP-TLS peer implementations MUST support checking certificate revocation after authentication completes and network connectivity is available. An EAP peer SHOULD NOT trust the network until revocation status is verified and MUST use a secure transport to do so.
EAP-TLS peers MUST NOT store resumption PSKs or tickets (and associated cached data) for longer than 604800 seconds (7 days) regardless of the PSK or ticket lifetime.
Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyData message.
Implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator, because new TLS versions could introduce incompatibilities or security issues if not carefully integrated with the EAP state machine.
Implementations MUST NOT set the L (length) bit in unfragmented EAP-TLS messages, but MUST accept unfragmented messages with and without the L bit set.
Key derivation MUST use the full length values specified (128 bytes for Key_Material, 64 bytes for Method-Id). Unlike TLS 1.2, TLS 1.3 does not permit truncating TLS-Exporter output by requesting less data; the full output must be requested.
Post-handshake authentication MUST NOT be used in EAP-TLS. Clients MUST NOT send a post_handshake_auth extension and servers MUST NOT request post-handshake client authentication.
The EAP-TLS peer and server MUST cache data during the initial full handshake sufficient to allow authorization decisions during resumption. If cached data cannot be retrieved securely, resumption MUST NOT be done.
The EAP-TLS server MUST authenticate with a certificate. Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption.
The NewSessionTicket message MUST NOT include an early_data extension; if received, it MUST be ignored.
The psk_dhe_ke key exchange mode MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms, ensuring forward secrecy even if the PSK is later compromised.
To enable resumption with TLS 1.3, the EAP-TLS server MUST send one or more post-handshake NewSessionTicket messages after the initial authentication. Ticket lifetime MUST NOT exceed 604800 seconds (7 days) as specified in TLS 1.3.
Unauthenticated information from EAP-Response/Identity MUST NOT be used for accounting or authorization. Authorization MUST be based on authenticated information such as certificate contents or PSK identity.
When EAP-TLS is used with TLS 1.3, the revocation status of all certificates in the certificate chains MUST be checked (except the trust anchor). EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) per RFC 6066 and Section 4.4.2.1 of RFC 8446.
Whenever an EAP-TLS 1.3 implementation encounters a fatal error condition, it MUST send an appropriate TLS Error alert, strengthening the TLS 1.3 base requirement where alerts are not mandatory after a fatal error.
Even though all certificates are encrypted in TLS 1.3, the server's identity is only protected against passive attackers while the client's identity is protected against both passive and active attackers. The realm portion of the NAI is still visible and may leak privacy-sensitive information if few peers share the same realm.
Without padding, the sizes of EAP-TLS packets leak information about client certificate sizes that can be used to track or identify users. EAP-TLS peers SHOULD use TLS record padding (Section 5.4 of RFC 8446) to reduce this leakage.
For resumption with TLS 1.3, the client sends a ClientHello with pre_shared_key extension. The server responds with ServerHello, EncryptedExtensions, Finished, and optionally a new NewSessionTicket. The peer responds with Finished, followed by the protected success indication exchange.
Key_Material and Method-Id are derived from the TLS exporter_secret using the TLS exporter interface: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type, 128) and Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Type, 64), where Type = 0x0D for EAP-TLS. MSK = Key_Material(0,63), EMSK = Key_Material(64,127).
The EAP-TLS server sends a protected success result indication as an encrypted TLS record with application data 0x00 after successfully processing the client Finished and sending its last handshake message. This MUST NOT be sent before those conditions are met, and afterward no more EAP-Requests may be sent.
The full EAP-TLS 1.3 mutual authentication handshake flow consists of: EAP-Request/Identity, EAP-Response/Identity (anonymous NAI), EAP-Request TLS Start, EAP-Response ClientHello, EAP-Request (ServerHello through TLS Finished), EAP-Response (Certificate/CertVerify/Finished), EAP-Request (Application Data 0x00), EAP-Response (empty), EAP-Success.
This document adds two labels to the IANA "TLS Exporter Labels" registry (RFC 5705): EXPORTER_EAP_TLS_Key_Material (DTLS-OK: N, Recommended: Y) and EXPORTER_EAP_TLS_Method-Id (DTLS-OK: N, Recommended: Y).
EAP headers, identity in Identity Response, EAP-TLS packet header fields, EAP-Success, and EAP-Failure can all be modified, spoofed, or replayed by an attacker; only the TLS-protected data within the exchange has integrity and replay protection.
Resumption introduces a time-of-check time-of-use (TOCTOU) vulnerability: a malicious user could supply different information during resumption than during the initial handshake. If any authorization decision may differ based on changed information, it MUST be reevaluated; if a safe decision is not possible, resumption SHOULD be rejected in favor of a full handshake.
Using the same certificate and resumption cache across different protocols (e.g., EAP and HTTPS) can allow cross-protocol resumption attacks where an attacker authenticates via one protocol and resumes in another, bypassing authorization. Using different certificates and resumption caches per protocol is RECOMMENDED.
EAP-TLS 1.3 state machine: after the TLS Finished exchange, the server may send post-handshake messages (NewSessionTicket) in one or more EAP-Requests; once all post-handshake messages are sent, the server sends Application Data 0x00 (success indication); after receiving the empty EAP-Response, the server transitions to sending EAP-Success only. TLS Error alerts trigger transition to EAP-Failure only.
EAP-TLS fragmentation is provided by a flags octet within EAP-Response/EAP-Request packets and a conditional TLS Message Length field of four octets. A single TLS record including ContentType (1 byte), ProtocolVersion (2 bytes), and length (2 bytes) headers may be up to 16645 octets.