[PATCH] Verify MFPC/MFPR capability setting of WPA SM

[Jouni Malinen]

On Sun, Nov 16, 2014 at 11:10:18AM +0000, Stepanov, Max wrote:
> Let's consider the following scenario:
> a. The wpa_supplicant.conf file contains mfp=1, it causes MFPC bit to be switched on in RSN IEs of association request if ieee80211w is not configured in the network block
> b. We want to connect to some AP configured with a regular WPA2-PSK without PMF support (e.g. no MFPC/MFPR in the beacon and probe response). AP doesn't publish PMF capability support, therefor the supplicant network block doesn't contain ieee80211w and key_mgmt value needed for PMF connection.

I'm not sure I understand what you mean with this. If the network block
does not specify ieee80211w, the default value from pmf=1 is used
instead and as such, PMF could be established if the AP were to support
this. Regardless, MFPC=1 should be set in RSN element.

> c. On connection, after successful association EAPOL fails with the following lines in the supplicant log:

Only with an AP that behaves incorrectly..

> 01-08 20:36:56.394 I/wpa_supplicant(  358): wlan0: WPA: CCMP is used, but EAPOL-Key descriptor version (3) is not 2

Could you please share a full wpa_supplicant debug log or wireless
capture showing this?

> It happens with our Sigma setup (Cisco Controller:  AIRCT2504-5-K9 AP: AIRCAP2602I-A-K9, failure of Sigma P2P - tests 5.1.6, 5.1.7).

Maybe that is with an older AP software version.. I cannot reproduce
this with my Cisco setup that uses a pretty recent software build.

> However it sounds like a possible incorrect AP side behavior and even though if dot11RSNAProtectedManagementFramesActivated is true the association request MFPC/MFPR bits still do not match the capability of the selected BSS.
> 
> The patch is about to solve the issue by preventing switching of MFPC/MFPR bits in association request on in this particular case. With the fix the problematic Sigma tests passed without issues.

It would have been useful to identify this reason of interoperability
issue reason in the commit log, but anyway, could you please check
whether this workaround commit addresses the issue with that AP?

http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65
('Work around AP misbehavior on EAPOL-Key descriptor version')

-- 
Jouni Malinen                                            PGP id EFC895FA