EAP-TTLS (Tunneled Transport Layer Security)
This page was last modified on 22 June 2016, at 13:14.
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS- CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange.
EAP-TTLS (Tunneled Transport Layer Security) is designed to provide authentication that is as strong as EAP-TLS, but it does not require that each user be issued a certificate. Instead, only the authentication servers are issued certificates. User authentication is performed by password, but the password credentials are transported in a securely encrypted tunnel established based upon the server certificates.
- After the authentication server determines that the user has made an authentication request, it sends its certificate to the user's system.
- The authentication server's certificate is used to establish a tunnel between the user and the server.
- After the tunnel is established, credentials can be exchanged safely between the server and the user because tunnels encrypt all data in a secure fashion. This stage is called inner authentication.
With EAP-TTLS, you do not need to create a new infrastructure of user certificates. User authentication is performed against the same security database that is already in use on the corporate LAN; for example, SQL or LDAP databases, or token systems.
The routing of the inner authentication request is handled either by means of standard Steel-Belted Radius Carrier authentication request routing, or by means of a directed realm. If your EAP-TTLS tunnel ends at a dedicated server, and you want all the inner authentication requests to be performed by other servers, use standard request routing so the proxy realm target can be determined in a standard fashion (that is, the decoration of the username revealed by inner authentication). If your EAP-TTLS tunnel and inner authentication are handled by the same server, you can use a directed realm to specify which authentication methods handle the inner authentication.