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

[Stepanov, Max]

On Sat, Nov 15, 2014 at 11:46, Jouni Malinen wrote:
>>On Wed, Nov 05, 2014 at 03:50:36AM -0500, Ilan Peer wrote:
>> Prevent setting of MFPC/MFPR capabilities of WPA SM in
>> wpa_supplicant_set_suites() function if MFPC is not set in RSN IE of 
>> the selected BSS.
>
>Why? This would make the station non-compliant with the IEEE 802.11 standard. MFPC is set to 1 when
>"dot11RSNAProtectedManagementFramesActivated is true to advertise that protection of robust management
>frames is enabled". That is done regardless of what the target AP advertises.

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.
c. On connection, after successful association EAPOL fails with the following lines in the supplicant log:

01-08 20:36:56.394 D/wpa_supplicant(  358): RX EAPOL - hexdump(len=121): 02 03 00 75 02 00 8b 00 10 00 00 00 00 00 00 00 02 31 3b 6d 96 60 df d9 7e 1a 6d ad ad 80 78 1a ...
01-08 20:36:56.394 D/wpa_supplicant(  358): wlan0: IEEE 802.1X RX: version=2 type=3 length=117
01-08 20:36:56.394 D/wpa_supplicant(  358): WPA: RX EAPOL-Key - hexdump(len=121): 02 03 00 75 02 00 8b 00 10 00 00 00 00 00 00 00 02 31 3b 6d 96 60 df d9 7e 1a 6d ad ad 80 78 1a ...
01-08 20:36:56.394 D/wpa_supplicant(  358): wlan0:   EAPOL-Key type=2
01-08 20:36:56.394 D/wpa_supplicant(  358): wlan0:   key_info 0x8b (ver=3 keyidx=0 rsvd=0 Pairwise Ack)
01-08 20:36:56.394 D/wpa_supplicant(  358): wlan0:   key_length=16 key_data_length=22
01-08 20:36:56.394 D/wpa_supplicant(  358):   replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 02
01-08 20:36:56.394 D/wpa_supplicant(  358):   key_nonce - hexdump(len=32): 31 3b 6d 96 60 df d9 7e 1a 6d ad ad 80 78 1a 54 32 bc 78 79 2a a3 97 65 1a a7 97 33 2e 12 c1 0e
01-08 20:36:56.394 D/wpa_supplicant(  358):   key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01-08 20:36:56.394 D/wpa_supplicant(  358):   key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00
01-08 20:36:56.394 D/wpa_supplicant(  358):   key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00
01-08 20:36:56.394 D/wpa_supplicant(  358):   key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01-08 20:36:56.394 I/wpa_supplicant(  358): wlan0: WPA: CCMP is used, but EAPOL-Key descriptor version (3) is not 2

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).

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.