Broadcast Key Rotation in WPA2-Enterprise WLANs

Wireless networks using WPA2-Enterprise security with 802.1X authentication are a common sight in corporate environments. It provides a secure way for devices to communicate over the air.

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!

The purpose of the 4-way handshake is to securely exchange a pair of encryption keys. One of the two keys is the Pairwise Temporal Key, or PTK for short. This key is used to encrypt/decrypt unicast traffic to/from the client. The other key is the Group Temporal Key, or GTK. This key is used to encrypt/decrypt broadcast and multicast traffic for all stations on the BSSID. Because of its purpose, the GTK is also referred to as the broadcast key.

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.

Presto!

The change to the broadcast key interval takes effect after the next scheduled key rotation. If there are clients connected to an AP, you could end up waiting a while. My lab environment had no clients when I made the change.

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

So my association ID is 1. Now I'm going to look for Beacons from the SSID I'm connected to that have the DTIM count value of 0 and are telling my client to wake up.

Wakey Wakey

(Now, I know what you're thinking: If the client is asleep, how can it hear the beacon? This brings up an interesting discussion. The client is supposed to wake up for every DTIM period. The AP doesn't know for sure that the client woke up until it receives a null-data packet from the client indicating that it will stay awake).

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.

The time deltas between those frames are lining up perfectly with the broadcast key rotation interval of 120 seconds.

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?

Hello again

Look at the EAPOL-Key Timeout and Max Retries parameters here. You could infer that the client is given 1 second and two retries before being disconnected. But is that what really determines it?

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).