EAP methods and their security

EAP-TTLS (Tunneled Transport Layer Security)

The EAP-TTLS method is based on the SSL/TLS protocol and creates a secure TLS tunnel between the user device and the RADIUS server. However, the communications inside this tunnel can use several different protocols, including some of the protocols also available directly like MSCHAPv2. While ultimately the security of this communication depends on the security of the second-level protocol (also called: inner authentication), the encrypted tunnel provides protection from most attacks.

The two most common second-level protocols are PAP and MSCHAPv2. PAP (Password Authentication Protocol) is a basic, clear-text authentication method, while MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) is a highly secure protocol with encryption and a challenge-response mechanism. For security purposes, MSCHAPv2 is a better option than PAP.

EAP-TLS (Transport Layer Security)

The EAP-TLS method is fully secure and based on digital certificates. When authenticating, the RADIUS server verifies the validity of the TLS certificate installed on the client device, and then uses information from that certificate (the Subject and possibly additional information from SAN fields) to confirm the identity of the user or the device. For example, the Subject of the certificate can contain an email address or a device ID, which are then verified with the integrated repository such as Active Directory.

While EAP-TLS itself is very simple, what can be regarded as complex is the creation of individual certificates on user devices. This can be done in several ways. For example, the SCEP protocol allows the user device to contact the Portnox SCEP server, send a certificate request based on a template, and get an individual certificate. This is a method used by most unified endpoint management (UEM) solutions, which automatically deploy certificates for EAP-TLS authentication on all managed machines. Another option is to use the Microsoft Server as a CA authority and have it create and distribute user and/or device certificates using GPO.

EAP-TEAP (Tunneled Extensible Authentication Protocol)

The EAP-TEAP method, unlike the methods described above, can authenticate both the user and the device in a single authentication exchange. Older EAP methods authenticate either the user or the device, but not both, which means that a valid set of user credentials can be used from any device, including a personal/untrusted one. EAP-TEAP addresses this by combining both checks into one process, commonly referred to as EAP chaining.

EAP-TEAP was originally developed by Cisco as an open successor to their proprietary EAP-FAST protocol, which provided similar chaining capabilities but was limited to Cisco environments. EAP-TEAP was subsequently standardized by the Internet Engineering Task Force (IETF) as RFC 7170, making it available to any vendor. Largely because of its Cisco origins, EAP-TEAP is the default authentication method in most Cisco Identity Services Engine (ISE) deployments, and organizations migrating from Cisco ISE to Portnox Cloud frequently rely on it already. For general background on EAP methods, see Wikipedia: Extensible Authentication Protocol.

EAP-TEAP authentication takes place in two phases. In the first phase, the client and the RADIUS server establish a mutually authenticated TLS tunnel, in the same way as EAP-TTLS. In the second phase, one or more EAP methods, referred to as inner methods, are executed inside this tunnel to authenticate the device, the user, or both. When two inner methods are used, one authenticating the device and the other authenticating the user, the results are cryptographically bound together into a single outcome, which is what prevents the two credentials from being split or used independently of one another.

Only two EAP methods can currently be used as inner methods within an EAP-TEAP tunnel: EAP-TLS, described above in this topic, and PEAP-MSCHAPv2, which is functionally similar to EAP-TTLS-MSCHAPv2 but uses a different tunnel implementation. These two inner methods can be combined in any order for the primary and secondary authentication, as shown in the following table.

EAP-TEAP on the client side is currently supported only on Windows 10 and Windows 11. Other operating system vendors do not support this protocol. On Linux, support for EAP-TEAP does exist in the source code of wpa_supplicant, the software most Linux distributions use for 802.1X authentication, but it is disabled in every build shipped by mainstream distributions. Users who want EAP-TEAP support on Linux would need to compile wpa_supplicant themselves with this option enabled, since no mainstream distribution currently provides a pre-compiled build with EAP-TEAP support.

Support in authentication repositories

To be able to use a specific protocol in 802.1X communication, each entity involved in the communication must support that protocol. This includes:

• The operating system of the client device such as a laptop or a mobile phone.
• The NAS device such as a network switch or a Wi-Fi access point.
• The RADIUS server responsible for authentication, for example, Portnox Cloud servers.
• The authentication repository provider that the RADIUS server contacts to check the user credentials.

The weak spot of this group is usually the authentication provider. While Microsoft Active Directory supports the secure EAP-TTLS-MSCHAPv2 protocol, most cloud providers such as Microsoft Entra ID, Google Workspace, and Okta support PAP only. And if even one of the listed entities does not support a given protocol, you cannot use this protocol for authentication.

This means, for example, that if your company uses cloud-based authentication in Portnox Cloud, such as the integration with Entra ID, Google Workspace, or Okta, you cannot use EAP-TTLS-MSCHAPv2 with accounts in these repositories. You can only use the less secure EAP-TTLS-PAP.

For your convenience, here is a matrix of the most popular EAP methods and their support in authentication repositories.