He was exactly right, and this point raises such an interesting discussion that I want to expand that first blog by talking specifically about the difference between WPA2 and WPA and how these security types impact fast secure roaming and security features.
First, it is important to know that as long as WEP is not supported and TKIP or CCMP are supported, the BSS is considered to be an RSN. However, the encryption cipher(s) in use also dictates how frames will be formatted in the BSS. Specifically, if the network supports WPA2 (AES-CCMP and optionally, TKIP) security, there will be an RSN information element (IE) in many management frames. If the BSS supports WPA security (TKIP) only, the RSN IE will be replaced with a WPA IE. The purpose of a WPA IE is generally the same as an RSN IE, but a few fields are changed or omitted.
It is the omissions in a WPA IE that are interesting. First, as Andrew pointed out in the comment, the preauthentication field is not present in the WPA IE. Guess what that means? That’s right, no preauthentication support. Bummer. However, it is even more significant that the WPA IE also omits the PMKID Count and List fields as well. These fields are used for almost all other types of modern fast secure roaming, such as PMK caching and Opportunistic Key Caching (OKC). The PMKID Count and List field omission also means that these features are not supported. That’s a big deal for anyone wanting to support WPA-Enterprise in mobile environments.
I took the liberty of capturing a few decoded frames to demonstrate the WPA and RSN IE differences. See the links below, which show the WPA and RSN IEs in their entirety.
http://www.cwnp.com/img/tech/WPA_IE_in_beacon.png
http://www.cwnp.com/img/tech/WPA_IE_in_association_request.png
http://www.cwnp.com/img/tech/RSN_IE_in_probe_response.png
http://www.cwnp.com/img/tech/RSN_IE_in_association_request.png
The first image shows a WPA IE in a beacon (using PSK security), which you can compare with the third image, showing an RSN IE in a probe response (using 802.1X/EAP security). Then compare the second and fourth images, showing a WPA IE in an association request and an RSN IE in an association request. I selectively chose a set of screenshots using PSK and a set using 802.1X/EAP to demonstrate the differences you will see in the real-world.
Notice that the OUI is changed from 00:0F:AC to 00:50:F2 (IEEE to Wi-Fi alliance), but the coding of ciphers and authentication types remain the same. There is no preauthentication bit to set in WPA IEs, and there is no PMKID count or list fields in (re)association frames. You may notice that the RSN IE in the association request frame only contains a PMKID Count field but no PMKID List. That is because the PMKID Count is set to 0. Otherwise, there would be a list of the PMKIDs.
Let me point out that if you need to support TKIP for older clients and you can also support CCMP, you can configure the infrastructure for WPA2, enabling support for both ciphers. This will force the infrastructure to use the RSN IE. Of course, you’ll find that any device requiring TKIP probably does not support fast secure roaming anyway, but there are some clients out there to which this applies.
Let me rant for a second. Roaming support in the enterprise today really just sucks. I don’t understand why this isn’t a bigger deal to vendors (especially client and supplicant vendors). Where does this leave customers wanting to support 802.1X/EAP when mobile applications are used? Up a creek. Aside from proprietary solutions (CCKM or Meru Virtual Port/Cell), nothing works adequately. Since vendors are unwilling to put the best foot forward and support working protocols that solve real problems, customers are left choosing one: security or performance. That’s sad. A sarcastic two thumbs up to you, vendors.
Customers, please let all product manufacturers (infrastructure and client vendors) know how important this feature is to you. Eventually, maybe, the Wi-Fi Alliance will build it into the requirements for WPA2-Enterprise certification. Wouldn’t that be nice.
Great follow-up post Marcus! Everyone needs to scream at the top of their lungs at infrastructure and client manufacturers to implement fast roaming support (802.11r specifically) into their products.
-Andrew
MB,
Dude, killer post! All I can say is AMEN BROTHER. I wish I had some clever comment to add, but this is a stellar post…and I got nuthin’ (to add). You’re spot-on about the industry’s need for Voice-Enterprise certification, and it doesn’t look like the Voice-Ent TG at the WFA is moving very quickly (due to a lack of vendor support on both sides of the table unfortunately). It’s chicken/egg I think. Infrastructure vendors won’t jump in because the client-side vendors won’t…and vice-versa.
Just my opinion. Plug-fests keep getting delayed or canceled. OKC isn’t widely supported in the client side, so the industry really needs to step up to Voice-Enterprise in a hurry. Again, nice post!
Devinator
TKIP will drop from the Wi-Fi certification in 2012. I know it isn’t quite soon enough but that should help drive performance. So, maybe in the 2017 timeframe we can turn off TKIP once and for all. Incidentally, WEP doesn’t drop off till 2013.