EAP-TLS
termnetworkingsecuritycryptography
Stands for: EAP Transport Layer Security (RFC 5216, EAP Type 13)
Wireless and wired authentication using certificates on both sides, rather than a shared password.
RFC 5216 (Simon, Aboba and Hurst of Microsoft, March 2008, Standards Track, obsoleting RFC 2716) specifies EAP-TLS at EAP Type 13: a TLS handshake carried in EAP packets, in which the server presents a certificate, the client presents one too, and both derive keying material; the RFC defines fragmentation with an L bit (a four-octet TLS Message Length is included) and an M bit (more fragments follow), because a handshake with certificates does not fit in one lock-step EAP packet. The exported keys follow a fixed recipe, the TLS pseudo-random function over the master secret with the label "client EAP encryption" and the two random values, with the first 64 octets as the MSK and the next 64 as the EMSK, which is what the access point turns into link encryption keys. It is the strongest common option because there is no passphrase to share, post or take to a former employer, and each device authenticates as itself. The cost is a certificate lifecycle for every endpoint, which is the reason deployments stall. The frequent misconfiguration is worth naming: a client that does not validate the server's certificate will happily authenticate to an impostor, which turns the strongest option into a credential-harvesting opportunity.
EAP-TLS is the method the other EAP methods are measured against, because it is the one that removes the password. RFC 5216, published in March 2008 by Simon, Aboba and Hurst of Microsoft as a Standards Track document and obsoleting RFC 2716, specifies it at EAP Type 13. The method is a TLS handshake carried inside EAP Request and Response packets: the server presents its certificate, the client presents its own, each verifies the other against its trust anchors, and the handshake's result is keying material for the link. The RFC describes it as providing certificate-based mutual authentication and key derivation, and that combination, both sides proving identity with a certificate and a key coming out of the exchange, is what makes it the strongest option in the family and the only one in which there is no secret a human could write on a sticky note.
The mechanics have one feature that every other TLS-based method inherited. EAP is a lock-step protocol with small packets, and a TLS handshake carrying certificates and chains is not small, so RFC 5216 defines fragmentation: a flags octet with an L bit, meaning a four-octet TLS Message Length field is present, and an M bit, meaning more fragments follow, with the receiver of a fragment answering, in the RFC's words, "with EAP-Type=EAP-TLS and no data". Dozens of round trips between supplicant, switch and RADIUS server are normal, and a slow or lossy link between the switch and the server shows up as authentication timeouts long before it shows up as anything else. Once the handshake completes, the key material is exported by a fixed recipe: the TLS pseudo-random function over the master secret with the label "client EAP encryption" and the client and server random values, producing 128 octets of which the first 64 are the Master Session Key and the next 64 the Extended Master Session Key. The use of those keys, the RFC says, "is specific to the lower layer"; in enterprise Wi-Fi that lower layer is the one that encrypts the link, which is how an 802.1X-authenticated session gets keys of its own without anyone configuring them.
The strength comes with a lifecycle. Every endpoint needs a certificate issued to it, a private key kept on it, renewal before expiry and revocation when the device is lost or retired, and the server needs a certificate the clients will trust. Organisations with a device-management platform and a certificate authority that can enrol devices automatically find this routine; organisations without one find it the reason the project stalls, and often settle for a tunnelled password method on the way. RFC 5216 also notes a privacy limitation: a peer configured to keep its identity private, by withholding its certificate until the server is authenticated, typically cannot authenticate with a server that does not support that option, so privacy is a feature to be designed in on both sides.
The misconfiguration that undoes the method deserves its own paragraph. Mutual authentication is only mutual if the client checks the server's certificate against a trusted authority and an expected name. A supplicant set to skip that check will complete the handshake with any access point that presents a certificate, and while EAP-TLS gives an impostor no password to steal, it gives them an authenticated client to attach to a hostile network, and it trains users to accept whatever appears. The setting is on the client, is enforced by management policy, and should be verified on every device class that joins the network, which is the same discipline PEAP and EAP-TTLS need for a more dangerous reason.
Where it fits: EAP-TLS for every device that can hold a certificate, which today includes laptops, phones and tablets under management and a growing share of printers and controllers; TEAP where machine and user must be proven together or where credentials are to be provisioned inside the tunnel; PEAP and EAP-TTLS where a password back end is the constraint; MAB for the devices that can do nothing at all. The 802.1X entry covers the carriage, the RADIUS entry the server side, and the article on 802.1X and the EAP methods sets the choices side by side.
Also known as: 802.1x, certificate-based wi-fi, eap type 13, mutual tls wi-fi