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

[Stepanov, Max]

On Sun, November 16, 2014 15:38, Jouni Malinen wrote:
>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.

That's correct, here I only described the issue scenario and the current implementation details, no complains :-)

>Only with an AP that behaves incorrectly..

Agree, I mentioned this point too...

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

Sure. I'll send you the log file directly - it's too big for the list.

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

Agree too, perhaps it's an older SW AP version, but that's exactly the point. Such APs are already available and used. They may make issues in regular WPA2 connection scenarios. If the end user cannot connect some AP with WPA2-PSK it's not so important to him which side (AP or STA) is right or wrong. You are right, perhaps it makes sense to consider this as an interop adhoc workaround.

>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?

Both commenting pmf=1 in Android's wpa_supplicant.conf or applying this patch not to set MFPC in the association request solved the issue on my side.
In hostap master branch the default wpa_supplicant.conf contains #pmf=0, however wpa_supplicant_template.conf contains pmf=1. This option was added by Dmitry on Sep 4. Patch 9ffd5129 (Android: set pmf=1 to default template). I guess this issue will be common for all Android builds.
 
Please let me know if you need more info.

Regards,
Max