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.

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 (Azure), 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 Azure, 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.