802.1X / EAP - Enterprise Authentication
IEEE 802.1X defines port-based Network Access Control for wired and wireless networks. In Wi-Fi, it is the foundation of WPA2/WPA3-Enterprise - replacing the shared PSK with per-user authentication via EAP (Extensible Authentication Protocol) and a RADIUS server. The PMK produced at the end of EAP flows directly into the 4-Way Handshake to derive the PTK.
The most common 802.1X outage is a client certificate that expired at 3am. The AP log shows association failure. The PCAP shows EAP-Failure in under 500ms. The cert expiry date is visible in neither - but it is the only thing that matters.
Three-Party Architecture
The device requesting access. Implements the client side of EAP. Must validate server certificate (in cert-based methods) to prevent rogue RADIUS attacks. In 802.1X: the entity on the "edge" of the controlled port.
The AP acts as a passthrough proxy. It relays EAP messages between Supplicant and AS. It controls the 802.1X "Controlled Port" - no data traffic until authentication succeeds. AP never sees the password - only the final MSK.
The RADIUS server (FreeRADIUS, Cisco ISE, Microsoft NPS, Aruba ClearPass) validates credentials. Runs EAP method logic. Sends MSK to AP on success. Optionally returns VLAN assignment, QoS policy, session timeout via RADIUS VSAs.
The AP maintains two logical ports per STA association: Uncontrolled Port - always open, passes only EAP (EAPOL) traffic. Controlled Port - blocked until 802.1X authentication completes. Once RADIUS Access-Accept received and 4-Way Handshake completes, Controlled Port transitions to AUTHORIZED - all data traffic flows. On de-authentication or session timeout, port reverts to UNAUTHORIZED immediately.
Authentication Flow - Step by Step
STA signals readiness to authenticate. AP port state: Uncontrolled - only EAP traffic passes. All data frames blocked.
AP requests STA identity. EAP Code=1 (Request), Type=1 (Identity). Begins EAP state machine.
STA responds with identity (user@realm). AP encapsulates in RADIUS Access-Request → AS.
AP forwards EAP to RADIUS (UDP 1812). Includes: NAS-IP, Calling-Station-Id (STA MAC), EAP-Message attribute, RADIUS shared secret MAC.
AS sends challenge. EAP-TLS: server cert + TLS ServerHello. PEAP: TLS tunnel starts (inner method follows). TTLS: TLS tunnel + PAP/CHAP inside.
EAP-TLS: mutual cert exchange, TLS handshake. PEAP: TLS tunnel then MSCHAPv2. FAST: PAC provisioning. Multiple RADIUS Access-Challenge/Access-Request round-trips.
Authentication succeeded. RADIUS sends MSK (Master Session Key) in MS-MPPE-Recv-Key + MS-MPPE-Send-Key attributes. PMK = MSK[0:32]. AP and STA independently derive same PMK.
AP notifies STA. 802.1X port → AUTHORIZED state. 4-Way Handshake begins immediately to derive PTK/GTK. Optional: PMKSA cached for roaming (PMKID = HMAC-SHA1-128(PMK, PMKR0Name||STA_MAC||AP_MAC)).
MSK → PMK → PTK - The Key Chain
This is where 802.1X connects to the 802.11i (WPA2/WPA3) key hierarchy. The MSK derived from EAP becomes the PMK that seeds the 4-Way Handshake - same handshake used in WPA2-PSK, just with a different PMK source.
64 bytes derived by both STA and RADIUS server independently via the EAP method's TLS PRF. RADIUS sends MSK to AP in MS-MPPE-Recv-Key (first 32B) + MS-MPPE-Send-Key (next 32B) RADIUS attributes. Neither the password nor the full MSK transits the air.
PMK = MSK[0:32]. The first 32 bytes of the MSK. Same PMK that WPA2-PSK derives from the passphrase (PBKDF2-HMAC-SHA1). At this point the 802.1X and PSK code paths converge - the 4-Way Handshake proceeds identically.
After successful auth, AP and STA cache the PMK along with the PMKID = HMAC-SHA1-128(PMK, "PMK Name" || BSSID || STA_MAC). On roam to a new AP in the same ESS, STA sends PMKID in Assoc Request → AP verifies → skips 802.1X → jumps straight to 4-Way Handshake (802.11r also uses this).
EAP Methods Comparison
| Method | Authentication | Tunnel | Credential | Pros | Cons | Use case |
|---|---|---|---|---|---|---|
| EAP-TLS | Mutual certificate | No - direct TLS | Client cert + Server cert | Strongest security. No password. Forward secrecy. WPA3-Enterprise Suite-B requires EAP-TLS. | Client cert infrastructure required. Complex deployment. | Healthcare, Finance, WPA3-Enterprise |
| PEAP/MSCHAPv2 | Server cert only | TLS outer, MSCHAPv2 inner | Username + password | No client cert. Easy deployment. Widely supported. | MSCHAPv2 vulnerable to offline dictionary attack if server cert not validated. Supplicant must validate server cert. | Enterprise corporate - most common |
| EAP-TTLS/PAP | Server cert only | TLS outer, PAP inner | Username + password | More flexible inner method. Supports legacy PAP. | PAP sends password in plaintext inside TLS tunnel - secure only because of TLS. | Mixed device environments |
| EAP-FAST | PAC (Protected Access Credential) | TLS using PAC | Username + password or cert | No server cert required for provisioning. Faster re-auth. | PAC provisioning phase must be secured. Less widely supported. | Cisco-heavy environments |
| EAP-SIM / EAP-AKA | SIM card (USIM) | Challenge-response | SIM credentials from HLR/HSS | No user interaction. Carrier-grade. Seamless for mobile. | Requires SIM card. Operator infrastructure. | Mobile network Wi-Fi offload, Hotspot 2.0 |
PEAP and EAP-TTLS require the supplicant to validate the RADIUS server certificate. If the supplicant is configured to "Accept any certificate" or "Do not validate server identity" - an attacker can deploy a rogue RADIUS server with a self-signed cert, intercept PEAP inner MSCHAPv2, and crack the password offline. This is the most common 802.1X misconfiguration in enterprise deployments. Certificate pinning or a private CA with strict supplicant policy closes this attack vector.
Identifying 802.1X in PCAP
eapol // All EAPOL frames (802.1X)
eap // EAP layer frames
eap.code == 1 // EAP Request frames
eap.code == 4 // EAP Failure frames - authentication rejected The most common 802.1X outage pattern in enterprise networks: EAP-TLS client certificates expire silently. The supplicant attempts auth, RADIUS rejects with Access-Reject (EAP-Failure), and the device moves to a captive-portal VLAN or remains unassociated. In PCAP: EAPOL-Start → EAP-Request/Identity → EAP-Response → EAP-Failure in under 500ms. No 4-Way Handshake follows. The cert expiry is invisible at L3 - only visible in the RADIUS server logs or the PCAP EAP exchange. Monitoring certificate renewal and correlating RADIUS Access-Reject rates against cert expiry calendars closes this gap.