802.1X Authentication and EAP Methods
This domain tests the three-party authentication model, how EAP messages travel, and which EAP method fits which requirement. Questions typically present a deployment constraint, such as no client certificates or a mixed device population, and ask for the method and its consequence.
The model
The supplicant is the client, the authenticator is the AP or controller, and the authentication server is RADIUS. EAPOL runs between supplicant and authenticator; RADIUS carries the EAP payload between authenticator and server. The authenticator is a pass-through and does not interpret the method. Port-based access control keeps the controlled port closed until authentication succeeds, while the uncontrolled port carries only EAPOL. Reauthentication, session timeout, and idle timeout determine how often keys and authorizations refresh.
Methods and their trade-offs
- EAP-TLS: mutual certificate authentication inside TLS 1.2 or 1.3. Strongest option, but requires PKI on both sides and careful certificate lifecycle management.
- PEAPv0 with EAP-MSCHAPv2: server certificate in phase one, TLS tunnel, inner MSCHAPv2. Ubiquitous and easy, but the inner method exposes credentials to an attacker who can present a certificate the client fails to validate.
- EAP-TTLS: similar tunnel, supports PAP, CHAP, or MSCHAPv2 inside.
- EAP-FAST: PAC-based, no certificate infrastructure required.
- TEAP: RFC 7170, a tunnel supporting multiple inner methods and provisioning.
- EAP-SIM, AKA, AKA prime: carrier credentials.
- EAP-MD5 and LEAP: no meaningful mutual authentication or weak challenge-response. Avoid.
Identity privacy
The EAP-Response/Identity travels outside the tunnel. Configure clients with an anonymous outer identity so the real username is only visible inside the protected phase.
Worked example
A laptop authenticates at boot with a computer certificate, then the user authenticates with PEAP-MSCHAPv2 after logon. The AP must permit machine authentication before user logon, and the RADIUS policy must distinguish machine from user accounts with different authorization results. If the user later reports failure, and the capture shows a completed TLS handshake followed by an EAP-Failure, the certificate is not the problem, the inner method or the account state is.
Traps that cost marks
- Assuming the AP can read the EAP conversation; it cannot.
- Selecting EAP-MD5 because it interoperates, ignoring that it provides no server authentication.
- Overlooking RADIUS shared secret strength and the Message-Authenticator when troubleshooting EAP failures.
- Ignoring that identity sent in the clear outside the tunnel enables username enumeration.