County public-health clinicians authenticate to the clinic WLAN with usernames and certificates through a RADIUS server. In what order does Enterprise AKM establish security for their sessions?
Select an answer to reveal the explanation.
Short Explanation
Enterprise Wi-Fi is two acts: first prove who you are to RADIUS (802.1X/EAP), then run the 4-way handshake to mint the session keys. Flip that order and you’re hanging locks before you’ve checked the badge.
Full Explanation
County public-health clinicians authenticating with usernames and certificates through RADIUS follow Enterprise AKM in a defined order: 802.1X/EAP authentication yields a PMK, then the 4-way handshake derives and installs pairwise keys (and related group keying) for the session. Identity and master key material come first; confirmed session keys for air confidentiality come second. Flipping that mental model causes clinic teams to chase “encryption problems” when AAA never finished, or to assume AAA success guarantees user-plane keys already exist. Running the 4-way handshake first to create keys and only afterward performing 802.1X so RADIUS can “learn the PMK” reverses the Enterprise sequence. Captive-portal acceptance alone does not replace 802.1X or the 4-way handshake on Enterprise clinical SSIDs. DHCP option 43 provisioning of the PTK before any authentication frame is sent is not how RSN Enterprise keying works. Exam caveat: some fast-roaming optimizations reuse key hierarchy state, but initial association still conceptually rests on authentication producing master key material before pairwise confirmation. Operational check: for a failing clinic tablet, inspect whether Access-Accept occurred and whether EAP completed before analyzing 4-way timeouts—document the ordered checklist in the public-health WLAN runbook.