EAP-TTLS
acronymStands for: EAP Tunneled Transport Layer Security (RFC 5281, EAP Type 21)
EAP Tunneled TLS of RFC 5281, EAP Type 21: a TLS tunnel authenticated by the server, inside which the client can authenticate with almost anything, including PAP, CHAP, MS-CHAP and MS-CHAP-V2 as well as another EAP method.
RFC 5281 (Funk and Blake-Wilson, August 2008, Informational) specifies EAP-TTLSv0 in two phases: a handshake phase in which the server is authenticated by TLS, and a data phase in which the client is authenticated inside the tunnel by "an arbitrary authentication mechanism", which "may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2". That is its difference from PEAP, which only carries EAP inside the tunnel: EAP-TTLS can front a RADIUS or directory backend that only knows how to check a plain password, because PAP inside the tunnel delivers the password to the server in a form it can verify against any store. The RFC allows one-way authentication, the server by certificate and the client by password, and it tells the client that the outer identity "SHOULD NOT include the actual name of the user", using a blank or an anonymous value so that the real identity is only disclosed inside the tunnel. The TTLS server may itself proxy the inner authentication to the user's home AAA server, which is how roaming federations work across administrative domains. As with every tunnelled method, the client must validate the server's certificate or the tunnel protects nothing.
EAP-TTLS was written for the authentication back ends that enterprises actually had: directories and RADIUS servers that could verify a plain password, or a legacy challenge-response, but could not run an EAP method themselves. RFC 5281, published in August 2008 by Funk and Blake-Wilson as an Informational document, specifies EAP-TTLSv0 at EAP Type 21 and describes a two-phase exchange. The handshake phase is a TLS negotiation in which the server authenticates to the client with a certificate and the two derive keys; the client may present a certificate too, but the RFC explicitly allows one-way server authentication. The data phase then runs inside the tunnel, where the client authenticates with "an arbitrary authentication mechanism": the RFC says it "may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2".
That sentence is the practical distinction between EAP-TTLS and PEAP. PEAP tunnels EAP and only EAP, so the inner exchange has to be an EAP method such as EAP-MSCHAPv2, and the back end has to support what that method needs. EAP-TTLS with PAP inside the tunnel hands the server the password itself, protected by TLS on the way, and the server can verify it against anything, including a directory that stores passwords in a form only a plain bind can check. That is why EAP-TTLS/PAP is the usual recommendation when the user store is an LDAP directory without the hashes MSCHAPv2 needs, and why it appears so often in university and federation deployments.
The RFC takes identity privacy seriously. The EAP Identity exchange precedes the tunnel and is visible to anyone listening, so the outer identity "SHOULD NOT include the actual name of the user"; the client should send a blank username or the string anonymous, keeping any realm part needed for routing, and disclose the real identity only in the data phase. Routing is the other feature that made EAP-TTLS a federation protocol: the TTLS server that terminates the tunnel need not hold the user's credential at all. It may act as a proxy, forwarding the inner authentication to the home AAA server of the user's realm, so that a visitor's password is checked by the visitor's own institution while the visited network only learns that the answer was yes.
The security caveats are those of every tunnelled method. The tunnel is only as trustworthy as the client's check of the server certificate; a supplicant that accepts any certificate will build its tunnel with an impostor and deliver its inner credential, which in the PAP case is the password in clear text inside the attacker's tunnel. The inner legacy method adds nothing to security, it only inherits the tunnel's, so the server certificate, the trust anchor on the client and the expected server name are the controls that matter. And because the inner method can be as weak as PAP, the server side must not expose the inner credential to anything outside the TLS termination point: the back-end path from the TTLS server to the directory is a second place a password can be seen.
In the family tree, EAP-TTLS sits beside PEAP as the second of the tunnelled password methods, with EAP-FAST and then TEAP (RFC 7170) as the later generation that added credential provisioning and cryptographic binding of the inner exchange to the outer tunnel. Where a client can hold a certificate, EAP-TLS removes the password from the picture altogether; where it cannot, EAP-TTLS is the method that lets almost any back end participate.
Also known as: ttls, eap-ttlsv0, tunneled tls