The EAP-TLS Authentication Protocol
Extracted elements (30)
Fragmentation is built into EAP-TLS rather than relying on lower-layer fragmentation because a single TLS certificate message can be up to 16 MB, far exceeding the RADIUS maximum packet size of 4096 octets or typical link MTUs. EAP's ACK-NAK model makes simple stop-and-wait fragmentation sufficient; no fragment offset field is needed because EAP Identifier provides sequencing.
MSK and EMSK are derived from the TLS master_secret via TLS PRF (a one-way function) so that the TLS master_secret cannot be recovered from the MSK or EMSK unless the PRF is broken. This provides key separation; however, compromise of the master_secret still compromises the MSK and EMSK.
TLS session resumption is supported to provide "fast reconnect" for wireless LAN use cases where a peer re-authenticates frequently. Session continuation is more likely to succeed when EAP authentication is remoted to a backend server shared by multiple authenticators than when the EAP server is co-located with a single authenticator.
A privacy-configured EAP-TLS peer typically cannot authenticate with a server that does not support privacy, as non-privacy servers treat an empty certificate list as a terminal error. EAP-TLS peers SHOULD therefore only be configured for privacy on networks known to support it.
TLS handshake messages SHOULD NOT be fragmented across multiple TLS records if they fit within a single TLS record, in order to ensure interoperability with existing implementations.
An EAP-TLS implementation MUST provide its own support for fragmentation and reassembly because TLS messages (up to 16 MB) can exceed the MTU or the RADIUS maximum packet size of 4096 octets.
An EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in the initial TLS handshake. The server supporting privacy MUST NOT treat an empty certificate list as a terminal condition and MUST bring up the session then send hello_request.
During the EAP-TLS conversation, the EAP peer and server MUST NOT request or negotiate TLS compression. TLS ciphersuite negotiation MUST NOT be used to negotiate the ciphersuites used to secure data traffic (only the EAP conversation).
EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs). They SHOULD also support OCSP. Peers MUST support post-authentication revocation checking when network connectivity is unavailable prior to authentication completion.
Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificates are appropriate and authorized. Implementations SHOULD verify the Extended Key Usage extension (id-kp-serverAuth for server certs, id-kp-clientAuth for peer certs).
Once having received the peer's Identity, the EAP server MUST respond with an EAP-TLS/Start packet (EAP-Type=EAP-TLS, S bit set, no data) to initiate the TLS handshake.
Since the identity in EAP-Response/Identity need not match the certificate identity, EAP-TLS implementations SHOULD NOT require them to be identical. If they differ, the EAP-Response/Identity identity is unauthenticated and SHOULD NOT be used for access control or accounting.
The TLS version offered by both the peer (client_hello) and the server (server_hello) MUST correspond to TLS v1.0 or later. EAP-TLS implementations MUST support TLS v1.0.
To ensure interoperability, EAP-TLS peers and servers MUST support the mandatory-to-implement TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA. Peers and servers SHOULD also support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA.
When an EAP-TLS peer receives an EAP-Request with the M (More fragments) bit set, it MUST respond with an EAP-Response of EAP-Type=EAP-TLS and no data as a fragment ACK. The EAP server MUST wait for this ACK before sending the next fragment and MUST increment the Identifier for each fragment.
Where the subjectAltName field is present in a peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName. NAI identities MUST use rfc822Name in the subjectAltName; use of emailAddress RDN in the subject field is deprecated and MUST NOT be used.
EAP-TLS supports optional privacy by using an anonymous NAI in EAP-Response/Identity and sending an empty client certificate list in the first handshake to avoid disclosing the peer username. The actual peer certificate is transmitted inside the encrypted second TLS session triggered by the server's hello_request.
EAP-TLS key derivation: Key_Material = TLS-PRF-128(master_secret, "client EAP encryption", client.random || server.random); MSK = Key_Material[0..63]; EMSK = Key_Material[64..127]; IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random). The MSK is split into Enc-RECV-Key (MSK[0..31]) and Enc-SEND-Key (MSK[32..63]).
Peer-Id and Server-Id are determined from the subject or subjectAltName fields in certificates. For hosts, dnsName SHOULD be present; for users, rfc822Name conforming to NAI grammar SHOULD be used. Multiple subjectAltName fields are all considered valid identifiers.
The EAP-TLS Session-Id is computed as 0x0D || client.random || server.random, where 0x0D is the EAP-TLS type code. This uniquely identifies the session for key management purposes.
IANA has allocated EAP Type 13 for EAP-TLS. The allocation was updated by this document to replace RFC 2716.
An EAP server implementing restart capability SHOULD impose a per-peer limit on the number of conversation restarts to protect against denial-of-service attacks. It is up to the EAP server whether to allow restarts at all.
EAP-TLS header fields (Code, Identifier, Length, Type, Flags) are not integrity-protected by TLS, so an attacker can modify them. Adding data beyond the Length field could cause buffer overruns. Modifying the Type field could substitute a different TLS-based EAP method, enabling a downgrade attack if the alternative uses the same key derivation formula.
The EAP-TLS security proof (He et al.) relies on the assumption that private key pairs used by the EAP peer and server are not shared with other parties or applications. A backend authentication server supporting EAP-TLS SHOULD NOT use the same certificate for HTTPS.
EAP-TLS base-case mutual authentication proceeds through: EAP-Request/Identity → EAP-Response/Identity → EAP-TLS Start → client_hello → server_hello/certificate/certificate_request/server_hello_done → client certificate/client_key_exchange/certificate_verify/change_cipher_spec/finished → server change_cipher_spec/finished → empty EAP-Response → EAP-Success. Each side verifies the other's certificate and finished message before the final EAP-Success is sent.
On failed peer authentication the EAP server SHOULD send a TLS alert, MUST wait for the peer's EAP-Response, and then MUST send EAP-Failure if the response contains no data. On failed server authentication the peer SHOULD delete the session from cache, MAY send a TLS alert, MUST wait for the EAP server's reply, and the server MUST reply with EAP-Failure.
TLS session resumption shortens the handshake: after client_hello, the server echoes the sessionId and sends only server_hello/change_cipher_spec/finished; the peer responds with change_cipher_spec/finished; then EAP-Success. The ciphersuite MUST match the one negotiated during the original session.
EAP-TLS Request packet: Code (1 octet, value=1), Identifier (1 octet), Length (2 octets), Type (1 octet, value=13), Flags (1 octet: L|M|S|RRRRR), optional TLS Message Length (4 octets, present only when L bit set), TLS Data (variable, TLS record format).
EAP-TLS Response packet: identical layout to Request except Code=2 and Flags field has only L|M|RRRRRR (no S bit). The Identifier MUST match the corresponding Request. Reserved bits MUST be set to zero and MUST be ignored on reception.
Flags octet in EAP-TLS: L bit (bit 0) indicates presence of 4-octet TLS Message Length field and MUST be set on the first fragment of a fragmented message. M bit (bit 1) is set on all but the last fragment. S bit (bit 2, Request only) marks the EAP-TLS Start message.