12.2 AES, WPA2-Personal and WPA2-Enterprise

Objective 5.2 is where CWNA-109 expects you to identify and configure effective security mechanisms for enterprise WLANs. After you can reject WEP, Shared Key, cloaking, MAC lists, and TKIP, you still need a working design. For most production networks that design is WPA2 with AES-CCMP, either as WPA2-Personal (PSK) on a tightly scoped SSID or as WPA2-Enterprise (802.1X) for people and managed devices. This section teaches AES as the confidentiality and integrity engine, the real limits of a pre-shared key, the 802.1X/RADIUS/EAP trio, and the 4-way handshake as the moment unicast and group keys are installed.

AES-CCMP: encryption and integrity in one protocol

Advanced Encryption Standard (AES) is a block cipher. 802.11 WPA2 uses AES-128 inside CCMP—Counter Mode with CBC-MAC Protocol. Counter mode provides confidentiality of the MSDU. CBC-MAC provides a message integrity code (MIC) so a receiver can detect modification. A 48-bit packet number (PN) supplies uniqueness and replay protection. Together, CCMP replaced TKIP’s RC4 stream and Michael MIC with a construction that 802.11n and later PHYs also require for high-throughput rates.

CCMP does not encrypt the 802.11 MAC header. Source, destination, BSSID, and sequence control remain visible to a protocol analyzer. That is expected: radios still need addresses to deliver frames. Confidentiality applies to the data payload (and to robust management frames when PMF is in use, which section 12.4 covers). If an exam item asks what AES is doing on a WPA2 SSID, the complete answer is confidentiality plus integrity, not “encryption only.”

GCMP (Galois/Counter Mode Protocol) is the related authenticated-encryption protocol used for some very high-throughput PHYs and for WPA3-Enterprise 192-bit mode (GCMP-256). At CWNA depth, know that GCMP exists, that it is also AES-based authenticated encryption, and that ordinary WPA2-Personal/Enterprise SSIDs you configure day-to-day are still CCMP-128 unless a specialist profile says otherwise.

WPA2-Personal: a shared secret with structural limits

WPA2-Personal uses AKM based on a pre-shared key (PSK). The administrator enters a passphrase (8–63 ASCII characters). The station and AP run PBKDF2-SHA1 with the SSID as salt and 4096 iterations to produce a 256-bit PSK that becomes the pairwise master key (PMK). Every authorized device that knows that passphrase can complete the 4-way handshake and install a PTK.

Three limits matter on the exam and on the job.

Offline dictionary on a captured handshake. The 4-way handshake messages are EAPOL frames. If an observer records a complete handshake for a BSS, the mathematics of WPA2-PSK let that observer test passphrase guesses without further contact with the AP. A short dictionary word, a company name plus a year, or a default vendor string falls quickly. A long, random passphrase does not become “un-capturable”; it becomes expensive to guess. That is why passphrase quality is a control, not a substitute for understanding the threat.

One shared secret. There is no per-user identity in standard WPA2-Personal. RADIUS never sees a username. Logs show a MAC address, which is spoofable and often randomized. If a contractor leaves, you cannot disable that person; you change the passphrase for everyone or you leave a former insider on the SSID. Guest posters, reception printouts, and chat messages that contain the PSK are equivalent to handing out the PMK.

Operational blast radius. IoT SSIDs, small offices, and bridging links still use PSK because 802.1X on a sensor is painful. That is a scoped exception, not an enterprise staff design. Some vendors offer per-device PSK (PPSK / identity PSK) that maps each passphrase to a VLAN. Cryptographically those are still PSKs; operationally they improve revocation. They are proprietary extras, not a reason to skip 802.1X for employees.

PSK best practices you should be able to recite: generate a long random passphrase (well beyond eight characters; think a high-entropy string stored in a password manager, not a slogan); unique PSK per SSID; rotate when staff or vendors who knew the key leave, and on a scheduled interval for unattended IoT; never reuse the WLC default; never print the staff PSK on the wall; put printers and badges on a separate SSID/VLAN from employee 802.1X. When the client population can support it, prefer WPA3-SAE (section 12.3) or move people to Enterprise.

WPA2-Enterprise: 802.1X, RADIUS, and EAP

WPA2-Enterprise uses IEEE 802.1X port-based access control. Three roles appear on every exam diagram:

1. Supplicant — the STA (laptop, phone, scanner) running an EAP client.
2. Authenticator — the AP or wireless LAN controller that blocks the port until authorization and that relays EAP.
3. Authentication server — almost always a RADIUS (AAA) server, sometimes fronting LDAP / Active Directory or a certificate store.

The 802.11 association still uses Open System. Then the authenticator starts EAPOL (EAP over LAN). The AP encapsulates EAP in RADIUS Access-Request packets to the AAA server (UDP 1812 by default). The AAA server answers with Access-Challenge until the EAP method succeeds, then Access-Accept carrying keying material derived from the EAP Master Session Key (MSK). The AP and STA treat that material as the PMK. Only then does the 4-way handshake run.

Because each successful EAP exchange yields a fresh PMK, WPA2-Enterprise gives you per-session keys, per-user identity, and revocation (disable the account or certificate). RADIUS attributes can assign VLAN, ACL, or group policy so one SSID serves multiple roles. That is the enterprise reason to prefer 802.1X over PSK for people.

Controller configuration at CWNA depth: create a RADIUS server entry (IP, shared secret, ports 1812/1813), apply it to the WLAN, set WPA2 with CCMP-only, select 802.1X AKM, and confirm the AP management interface can reach AAA. Use a strong RADIUS shared secret, restrict source IPs, and prefer RADIUS over a routed path that is not the client VLAN. If EAP works on the wired test port but wireless fails, look at AP-to-RADIUS reachability, the WLAN’s AAA override, and certificate trust on the supplicant—not at RF first.

EAP methods at CWNA depth: EAP-TLS versus PEAP-MSCHAPv2

EAP-TLS uses certificates on both the server and the supplicant. The TLS handshake mutually authenticates. There is no user password on the air. Compromise of one device is a certificate revoke-and-reissue problem, not a password-reuse problem. The cost is PKI: enrollment (SCEP, MDM, group policy), a trusted CA on every client, and lifecycle for expired device certs. When an organization can operate that PKI, EAP-TLS is the strongest common enterprise method CWNA expects you to name.

PEAP-MSCHAPv2 wraps an inner Microsoft CHAP v2 password exchange inside an outer TLS tunnel to the authentication server. Deployment is easier wherever Active Directory passwords already exist. The security of PEAP collapses if the client does not validate the server certificate (trusted CA, server name, no “trust this AP just once”). Without that check, a hostile AP can present any certificate, terminate the outer TLS, and collect inner credentials. Teach users and MDM profiles to pin or validate the AAA certificate. PEAP is acceptable enterprise practice when that validation is enforced; it is not “equivalent cryptography” to EAP-TLS.

Other names you may see: EAP-TTLS (outer TLS, various inner methods), EAP-FAST (Cisco), and historic LEAP (do not use). For CWNA-109, be ready to contrast certificate-mutual EAP-TLS with tunneled-password PEAP-MSCHAPv2 and to say that server-certificate validation is mandatory for tunneled methods.

The 4-way handshake: PTK and GTK, not a full key tree

After a PMK exists—copied from a PSK or derived from 802.1X—the AP and STA run the 4-way handshake (EAPOL-Key messages). CWNA needs the purpose, not the CWSP expansion of every key name.

The handshake proves both parties possess the same PMK, mixes in nonces and MAC addresses, and derives the Pairwise Transient Key (PTK). The PTK protects unicast traffic between that STA and the AP. The AP also delivers the Group Temporal Key (GTK) so the STA can decrypt broadcast and multicast. When the handshake completes, data frames can be CCMP-protected and the 802.1X port is open.

Remember the order: Open System → association → (optional 802.1X/EAP) → 4-way handshake → encrypted data. Skipping EAP on an Enterprise SSID, or mixing TKIP into that profile, is a configuration error, not an alternative handshake. Implementation bugs in handshakes have been patched by vendors over the years; your job on CWNA is to know what the handshake is for (install PTK/GTK from a PMK) and to keep the PMK source strong.