802.11 Authentication and Key Management (AKM) and 802.1X-EAP
The 802.1X triangle
Supplicant (client), authenticator (AP/WLC) and authentication server (RADIUS) exchange EAP inside EAPOL. The AP relays EAP without inspecting the method; on success the server returns keying material used to derive the PMK.
EAP types
- EAP-TLS: certificates on both sides; strongest, heaviest PKI burden.
- EAP-TTLS: server certificate, TLS tunnel, any legacy inner method.
- PEAPv0/MS-CHAPv2: server certificate, tunnel, password-based inner authentication. The client is authenticated only by password - never by certificate - so the client must validate the server certificate to resist an evil twin.
- EAP-FAST uses a PAC; LEAP and EAP-MD5 are deprecated. An anonymous outer identity protects the username in the clear.
The 4-way handshake
PMK (from PSK or 802.1X) plus ANonce, SNonce and both MAC addresses derives the PTK (KCK, KEK, TK). Message 1 carries ANonce, 2 carries SNonce and a MIC, 3 installs the GTK, 4 acknowledges. The PTK is never transmitted; the handshake proves both parties hold the PMK. A captured handshake or PMKID enables offline guessing against weak passphrases.
Fast-transition AKMs
FT-802.1X and FT-PSK (802.11r) derive PMK-R0/PMK-R1 keys from the initial full authentication and reuse them inside a mobility domain. PMK caching (OKC) is the older, vendor-driven equivalent.
Rule of thumb
Strength ranking: EAP-TLS, then PEAP/TTLS with enforced certificate validation, then PEAP without validation, then PSK. Any option claiming PEAP authenticates the client with a certificate is wrong.