What is 802.1X Extensible Authentication Protocol (EAP)?

EAP
802.1X uses an Extensible Authentication Protocol (EAP) for a challenge and response-based authentication protocol that allows a conversation between a Supplicant (the wireless/wired client) and the RADIUS (the authentication server), via an Authenticator (a wired switch or wireless access point which acts as a proxy). EAP supports multiple authentication methods, some of them are secure and some of them are vulnerable (although old endpoints still support them).

802.1X authentication with Portnox CLEAR
DIAGRAM: An example of how EAP works with Portnox CLEAR.

EAP-TLS
With 802.1X authentication via EAP Transport Layer Security (or EAP-TLS), there is a mutual certificate authentication, as it relies on the Supplicant (endpoint) and RADIUS certificate’s “handshake.”

Advantages:

Mutual certificate authentication
The authentication process takes place inside a secure SSL tunnel
The user/machine certificate is linked to the relevant user/computer identity, which makes stealing attempts useless (in contrast to stolen credentials)
Disadvantages:

The identities are sent in a clear text before the certificates exchange process starts
Deployment and lifecycle maintenance of endpoint certificates might be costly in small environments

EAP-TTLS
By using 802.1X EAP Tunneled Transport Layer Security (or EAP-TTLS) is an extension of EAP-TLS. After the RADIUS is authenticated to the Supplicant by its certificate (including an optional TLS authentication of the Supplicant to the RADIUS), the Supplicant proves its identity via PAP or MSCHAPv2

Advantages:

The authentication process takes place inside a secure SSL tunnel
User identity is not exposed
Can use multiple methods to authenticate inside the tunnel – certificates / user identities
EAP-TTLS can be used for network authentication by Azure Identity when AD-DS is not enabled (MSCHAPv2 is not available)
Disadvantages:

It does not support MSCHCAPv2 without enabling Directory Services with Azure AD (a limitation of Azure AD itself)
Client-side certificate is not required, only optional

EAP-PEAP
With 802.1X authentication via EAP Protected Extensible Authentication Protocol (or EAP-PEAP), only the RADIUS needs a certificate. With that certificate, the endpoints create an encrypted TLS tunnel to pass the authentication details. The most common protocol used to authenticate the endpoints, when using PEAP, is MSCHAPv2 challenge and response, which is used to authenticate both the server (usually Active Directory / Azure AD) and the supplicant (endpoint). The process involves challenge – response where both share a random hash that’s computed with the identity’s credential without sending the password across the network.

The authentication process takes place inside a secured SSL tunnel
User identity is not exposed
Simple deployment – allow the usage of username and password which the end-user is already familiar wit,h such as Active Directory or local account credentials
Disadvantages:

This method requires a password changing policy to remain secure
If the endpoints are not hardened they are exposed to “evil twin” attacks

EAP-MD5
One of the legacy 802.1X approaches of EAP is Message Digest 5 (or EAP-MD5), the RADIUS server sends a random challenge to the Supplicant which generates an MD5 Hash of its credentials and the challenge, which is then sent back to the RADIUS for validation. By using this method of 802.1X authentication, however, the supplicants don’t send their passwords to the RADIUS for validation, but rather use hashes.

Advantages:

EAP-MD5 is compatible with legacy network equipment and older type of endpoints
Disadvantages:

It is exposed to dictionary attack – password “guessing”
Vulnerable to man-in-the-middle attacks since there is no mutual authentication