A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Thursday, December 17, 2009

WPA/WPA2 broadcast key rotation on a controller

This one is (IMHO) way beyond what you should need to remember for the exam, but I actually dreamed about it last night, so I though I should share the fun!
Special dedication to Kyle, he is the one who raised this issue and found the solution.... :-)
So here is the deal: when you use WPA or WPA2, your wireless client gets 2 keys: one unicast key, for its own traffic to and from the AP, and one broadcast key, which is a common key for all clients in the same cell. This broadcast key is used when the AP sends broadcast messages to all clients in the cell, so it's a shared key.
You may want to rotate those keys, change them every now and then so that a wannabee hacker would not have enough packets using a specific key to even dream of running an attack against your encryption scheme.
Changing the unicast key can be done by setting the EAP session, everytime the session is renewed, so is the unicast key... but the broadcast key is not, because it is shared. On the autonomous APs, you can rotate the broadcast keys from the Security > Encryption Manager page:

You can enable rotation at regular intervals. The gotcha here is that only 802.1X clients can join a network that has this feature enabled.
When using WPA, you can also enable key rotation "on membership termination" (every time a client leaves the cell, the key is rotated for the clients still in the cell), or on "membership capability change" (everytime a client using static WEP enters or leaves the cell, the key is rotated).

Ok, but what about the controllers? How to rotate the broadcast key on the WLC? There is no checkbox, and no CLI command for that... the key is rotated every hour... what? I want this feature for my clients security!!
Kyle found this nice info:
CSCsi27596—The controller lacks a supported way to configure the broadcast key rotation interval. Instead, it is hardcoded to a group key rotation interval of 3600 seconds (1 hour).
Workaround: On the console, configure the hidden command devshell dot1xUpdateBroadcastRekeyTimer(seconds). This command does not work in an SSH or Telnet session and does not survive a reboot.
(Cisco Controller) >devshell dot1xUpdateBroadcastRekeyTimer(86400)
value = 0 = 0x0
I dreamed of it because the example, instead of rotating the key every hour, seems to rotates it every... day (unless 8600 is the max value)! Wow, nice and a lot more secure!

I hope you don't need that for the lab, because this is pushing the system to its limit (and I hope you won't dream of it), but it is fun to know (or at least to know where to find it)...


  1. Is there a way we can have the unicast key rotation set for the clients at regular intervals( without the full authentication occuring) rather than just the broadcast key. We have this option on the Aruba gear. I am just curious whether we can achieve the same on Cisco.

  2. This comment has been removed by the author.

  3. Yes and no! In fact, Cisco is just following the 802.11-2007 standard, by which the unicast key is rotated by renewing the session (this is not what the aruba gear does, it regenerates the key, not the PMK).
    On an autonomous AP, you would type:
    dot1x timeout reauth-period
    On a controller, you would go to WLANs > Advanced > Enable Session Timeout. You can also use the config wlan session-timeout CLI command.
    You can also limit the session from the RADIUS side of course, which would work with any solution without any configuration on the AP/WLC, Cisco or other vendor (as long as AAA override is enabled)...
    I doubt that Cisco will ever enable WPA unicast key rotation to be manually configured, because WPA is getting obsolete (Wi-Fi Alliance will stop certifying WPA products starting next January, WPA does not support 802.11n, so it is going out of the picture soon)...
    IMHO, allowing the user/admin to configure key rotation for WPA2 is more a gadget than anything else (not sure what the practical advantage would be)... just a thought, and I am not Cisco WNBU, but I would not be surprised if most of the guys in the WNBU had the same view...

  4. Hello

    "I dreamed of it because the example, instead of rotating the key every hour, seems to rotates it every... day (unless 8600 is the max value)! Wow, nice and a lot more secure! "

    How can it be a lot more secure? Rotating key every day is more secure than rotating key every hour or every minute? ... :)

  5. Has this command been deprecated? It doesn't seem to work on 7.x.

  6. Yes it is... the devshell hidden command family was deprecated on 7.x, because "it presents a security risk"... looks like someone didn't like devshell ending up on Google. :-(

  7. For those looking for the command, it is now (as of, possibly sooner) available as "config advanced eap bcast-key-interval <120-86400>". I don't see it listed in the command reference guides, but it shows it when you type "config advanced eap ?". The configuration can be confirmed using the "show advanced eap" command.

    So, no need for the devshell anymore for this.

  8. @Anonymous from 2011/09/30: Daily rotation can be more secure than hourly. As an example: someone is sniffing packets from the air, in order to crack the key, they need x number of packets that include the actual handshake. If the rotation happens every hour, then so does the handshake. If it happens daily, then it will take y number of days (rather than y number of hours) for there to be enough handshakes collected to reverse the encryption of the key so that one has the unencrypted key to connect.

  9. mmm what handshake? GTK is transmitted to each client individually using individual client PTK, so there is no broadcast handshake here... plus the GTK is rotated on controllers every time a client leaves, as per 802.11i, so unless there is only one client, the GTK is going to be rotated often anyway... keeping the key longer only gives more chances to hole196 attacks IMHO...

  10. This comment has been removed by the author.

  11. Hay i have a doubt!

    If i set the GTK renewal to 60 seconds in the AP, how the client in the network get to know about the updated GTK everytime. Whether an EAPOL packet is transmitted from AP to client on each renewal?

    While Packet Sniffing, i was not able to capture those packets. I wish to read the specified GTK renewal packet.

  12. Truly the best blog I never got such information before this thanks.
    Zero Up 2.0