MFP and 802.11w support

Answered Question
Sep 23rd, 2010

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.

I have this problem too.
0 votes
Correct Answer by Federico Lovison about 6 years 1 month ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Federico Lovison Wed, 10/13/2010 - 02:17

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 Wed, 10/13/2010 - 06:00

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 Wed, 10/13/2010 - 06:26

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 Mon, 01/07/2013 - 05:48

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

Johannes Luther Mon, 01/07/2013 - 05:56

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 Mon, 01/07/2013 - 06:07

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 Mon, 01/07/2013 - 06:12

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 Mon, 01/07/2013 - 06:15

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 Mon, 01/07/2013 - 08:23

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.

Actions

This Discussion

 

 

Trending Topics - Security & Network