MFP and 802.11w support

[Johannes Luther]

Hi Community,

I was wondering if Cisco WLAN Controller support the 802.11w protocol.

802.11w does the same as MFP (Management Frame Protection), but is an IEEE standard. It was ratified in 2009.

[Federico Lovison · Accepted solution]

Hi Johannes,

802.11w is actually based on Cisco MFP.

At the moment the Cisco Unified Wireless Solution supports the Cisco MFP, but IEEE 802.11w support is coming in a future software release.

I don't know more details about what version and when this will be released though.

Regards,

Federico

--

If this answers your question please mark the question as "answered" and rate it, so other users can easily find it.

[Johannes Luther]

Hi Federico,

thanks for the answer :-)

I was just wondering, because there are very few CCXv5 Clients. On the other hand I couldn't find any information on 802.11w at the WLAN chip manufacturers like Intel or Dell.

Hopefully this feature will be more popular in the future - either with CCX or 802.11w standard.

[Federico Lovison]

Hi Johannes,

I'm pretty confident that this will be widely implemented in the future, but as you say, also the client manufacturers have to implement this in order to take advantage of the feature.

Otherwise, only Infrastructure MFP can be done... but that's already the case with Cisco MFP... :-)

Regards,

Federico

[kristjan.edvardsson]

does anything need to be configured on the WLC to support 802.11w after it is upgraded to 7.0.230-3 ?

[Johannes Luther]

802.11w was introduced in the 7.4 train - with SW version lower than that, only MFP is possible
(http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn74.html)

802.11w configuration is documented in the 7.4 configuration guide for WLAN

(http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/wlan/config_wlan.html)

In the WLANs you have to set the PMF state from the drop-down list and set the auth key management for it.

Note: Only WPA2 with AES is compatible with 802.11w

I guess it's disabled per default.

[kristjan.edvardsson]

Thanks. I am focusing on 4400 WLC at the moment. I found that Cisco released 7.0.235-3 only to fix this issue with windows 8 and 802.11w. Thats why I was under the impression it should work also on this special code. Is this not right ?

Some info I gathered from the release notes:

There are no new features or enhancements in this release. This release addresses a Microsoft Windows 8 Client interoperability with Cisco Wireless Infrastructure (CSCua29504). For more information, see the Resolved Caveats section.

CSCua29504 Bug Details

Top of Form

802.11w-capable client fails pairwise key handshake   with AES.

Symptom: An 802.11w-capable client, such as a PC running Windows 8, cannot connect to   an SSID using WPA or WPA2 key management with AES encryption. The AP will send   the M1 pairwise key message, but the PC will never respond with M2. With "debug client" in effect, a message similar to the following   will be seen: *dot1xMsgTask: Jun 12 20:23:37.471: 00:11:22:33:44:55 Retransmit failure for EAPOL-Key M1 to mobile 00:11:22:33:44:55, retransmit count 5, mscb deauth count 0 Conditions: Client is 802.11w-capable, wireless infrastructure is CUWN, SSID using   WPA2/AES or WPA/AES. This bug affects CUWN 5.2.178.0 and above, but not CUWN 4.2 or earlier, nor does it affect autonomous IOS APs. Workaround: Use WPA/TKIP or WPA2/TKIP instead. Note that this will limit the client to 802.11g/802.11a data rates. Another workaround is to use a Windows 7, rather than Windows 8 driver, for   the adapter.

[Johannes Luther]

I guess that this only fixes the WPA2 4 way handshake, which fails if the wireless client is 802.11w capable.

I don't think that the WLC will use 802.11w. It just alters the first message of the 4 way handshake, clearly indicating it is not 802.11w capable. At least I think it works this way.

Because I'm curious I'll read in the 802.11w IEEE paper to see how it works

[kristjan.edvardsson]

Yes that is interesting. Peraps the WLAN in question should have client MFP as optional at least. I am helping a customer with this issue. Seems to be only windows 8 phones, not computers. My customer claims that by switching from radius ACS4.2 to MS NPS radius , things work for the windows 8 phones. But I can´t see what radius has to do with this. But that needs to be verified

[Johannes Luther]

It's pretty simple. Windows 8 is the first wireless supplicant, which supports 802.11w natively.

Regarding to Microsoft (http://support.microsoft.com/kb/2749073/en-us), the first message of the WPA 4-way handshake (EAPoL) is malformed. There is a field called "Key information", which contains a few bits for the "key descriptor version" which are not sent correctly. Non 802.11w client don't care about that (at least MS said that).

I captured the M1 message of a WLC with 7.0.116.0 code and with my home TP-Link AP - both running WPA2 PSK (AES).

At least I couldn't see any difference between the "key information" field - oh well.

But nevertheless. I assume the bug fixed version of Cisco corrects the M1 message of the WPA 4-way handshake, so that the Widows 8 client doesn't drop this message any more. Again - no version < 7.4 supports 802.11w

I think the MFP setting optional or off doesn't matter here.

Regarding the MS knowledge base article I also think that the backend RADIUS server doesn't matter here. It's a problem of the WPA 4-way handshake.