WPA with TKIP: No Fast Secure Roaming

WPA with TKIP: No Fast Secure Roaming

By CWNP On 11/01/2010 - 15 Comments

In my previous post , I explained a few details about 802.11 preauthentication. There was a great comment after that blog asking/stating how preauthentication works with WPA. It went like this: “Wouldn’t pre-authentication only be valid for an 802.11i (WPA2) RSN network since the 802.11-2007 standard specifically states the pre-authentication capability is advertised in the RSN IE? This would mean that Wi-Fi Alliance pre-standard WPA would not be able to use this feature since it uses the WPA IE, not the RSN IE.” -- Andrew

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.

Tagged with: wi-fi alliance, TKIP, meru, WPA, 802.11r, Voice Enterprise, fast secure roaming, CCKM

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.