A municipal WLAN review asks what group keys (GTK) protect on a WPA2 network. What is the correct class?
Select an answer to reveal the explanation.
Short Explanation
Unicast gets the per-client PTK; the group chat uses the GTK—like a shared megaphone key for broadcast and multicast to everyone associated. That is the GTK’s job. It is not RADIUS, not all unicast, and not DNS signing.
Full Explanation
On a WPA2 network, group keys (GTK) protect broadcast and multicast frames delivered to associated clients. Municipal WLAN reviews that ask about GTK are testing whether assessors distinguish group protection from pairwise unicast protection and from unrelated AAA or DNS mechanisms. Civic explanations should keep GTK in the 802.11 key hierarchy conversation: necessary for group-addressed frames once clients are associated and authorized on the BSS. Group keys do not encrypt only RADIUS shared secrets between AP and AAA; RADIUS shared secrets are wired/back-end AAA configuration, not the GTK. Group keys do not replace pairwise keys for all unicast TCP sessions; unicast is pairwise (PTK) territory. Group keys are not used solely to sign DNS responses on the guest VLAN; DNS integrity is not the GTK's job in the WLAN key hierarchy. Exam caveat: knowing GTK's broadcast/multicast role is enough—do not invent GTK as a universal citywide signing key. Operational check: in municipal architecture notes, label PTK for per-client unicast and GTK for group frames, and ensure guest VLAN discussions do not conflate portal/DNS controls with 802.11 group keying. If reporting key-management findings, cite observed security mode and client impact rather than generic 'GTK broken' language without evidence.