After several inspectors leave the permit-counter BSS, the WLAN still needs to refresh keys used for broadcast/multicast frames to remaining stations. Which handshake concept addresses that group-key renewal?
Select an answer to reveal the explanation.
Short Explanation
When someone leaves the party, you don’t always re-key every private whisper—but you do change the shared punch-bowl password. That’s the group key handshake refreshing the GTK for broadcasts still hitting the room.
Full Explanation
After inspectors leave the permit-counter BSS, the WLAN still needs to refresh keys used for broadcast and multicast frames to remaining stations. The group key handshake updates the GTK for group-addressed traffic without requiring a full rewrite of every pairwise concept from scratch as the sole mechanism. That keeps the shared “room announcement” crypto current as membership changes while preserving existing unicast sessions where appropriate. A new SAE commit from each remaining station that only rewrites unicast PTKs does not, by itself, explain GTK renewal for group traffic. DHCP FORCERENEW does not rotate GTK material via option 119 as an 802.11 group-key mechanism. Disabling broadcast in the SSID forever is not a practical substitute for group-key hygiene on a municipal permit counter that still needs group services. Exam caveat: failed group rekey can look like “broadcast/multicast broken after someone left”—correlate STA leave events with GTK handshake failures in controller logs or captures. Operational check: force a controlled client leave on a lab permit-counter SSID, observe the group key handshake, and confirm remaining clients continue to receive a test multicast or broadcast service afterward.