8021X Protocol for Network Authentication

8021X Approach: EAP

8021X 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).

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

8021X Approach: EAP-TLS

With 8021X 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

8021X Approach: EAP-TTLS

By using 8021X 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

8021X Approach: EAP-PEAP

With 8021X 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

8021X Approach: EAP-MD5

One of the legacy 8021X 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 8021X 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