While studying for the CWSP exam, I became familiar with the mechanisms of WPA2-Enterprise authentication. After a client has provided the correct credentials, the AP (and the DS behind it) performs what is known as the four-way handshake with the client.
|ACKs not shown for brevity!|
Since anyone within earshot of a wireless network can see its traffic, and since all broadcast traffic is encrypted with the same GTK, there is a possibility that an eavesdropper could collect enough broadcast traffic to guess the key. For this reason the GTK is rotated, or changed, for all stations on the BSSID periodically. The new GTK needs to be delivered securely to each station on the BSSID, which means it needs to be sent via unicast to each station, and encrypted with each station's PTK. The lifetime of the GTK is often called the broadcast key rotation interval, and it specifies how often the GTK must be changed for all stations on a BSSID that uses WPA.
For Cisco lightweight-AP based networks, the default broadcast key rotation interval is 3,600 seconds, or 1 hour. You can see the defined interval by issuing the show advanced eap command.
To see broadcast key rotation in action, it helps to shorten the interval to something manageable. I don't know about you, but I'm not waiting a hour to watch the key rotate.
There are two ways to "watch" the key rotation: via debug or over the air. To see the broadcast key rotation via debug, use debug dot1x all enable. Keep in mind that doing this in a production environment will likely produce a lot of output to the terminal. Here is what you will see when the broadcast key is rotated.
|The Easy Way|
You can see that the AP sends the GTK to the client, and that the AP resets the timer for the next key rotation.
Seeing the key rotation over the air with a packet analyzer is a bit trickier. It's easy to tell when a client associates and completes the 4-way handshake, but what do you look for to see the broadcast key rotation? The key rotation does not decode in Wireshark as an EAPOL packet; the station is already authenticated and the 802.1X port is unblocked.
The client has to be in an awake state to receive the new GTK, so I decided the best way to find the key rotation was to watch power management null-data packets around the time that I expected to see the key rotation take place. I configured my trusty Moto 4G to connect to the WPA2-Enterprise WLAN on my lab AP, and just let it sit without moving a lot of data. Taking a look at my capture, I want to see when a beacon tells my client to wake up, and what happens after that.
To see that, I need the Association ID of my client on the AP, which you can see from the Association Response when the client first connects.
|No Surprise, I'm the only client|
|I'm up, what do you want?|
Immediately after, I see this QoS Data frame sent from the AP to my client. What was interesting about this frame was the Source Address field was the same as the Transmitter Address field. It was not a frame being delivered from an upstream source; it was coming directly from the AP.
|You're going to have to trust me here.|
My client was connected for a while, at least long enough to see two or three broadcast key rotations at the 120 second interval. So I make a Wireshark filter to match frames where the transmitter address is the AP, the Source Address is the AP, and the frame type is data: wlan.ta == bssid && wlan.sa == bssid && wlan.fc == 0x2 .
|Well would you look at that.|
So, you may be asking yourself what happens if a client does not wake up from a sleep state to receive the new GTK. The answer: they are de-authenticated from the BSS. How long will the AP wait, and how many retries will happen before the client is disconnected?
For another blog, perhaps. But I do know for certain that broadcast key rotation intervals that are too short will cause problems for clients that enter power-save states. This is especially true for clients that will not wake up for short DTIM values, like iPhones. It's best to extend the broadcast key interval out past the default of one hour, and make sure your WLANs have DTIM values greater than 2 where applicable (not recommended for voice networks).