| Message ID | 1415177437-11016-3-git-send-email-ilan.peer@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
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.
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.
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')
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
On Sun, Nov 16, 2014 at 02:55:09PM +0000, Stepanov, Max wrote: > >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. Thanks! > 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. I understand why we need to work around this issue and I just want to make sure we do that properly and not by making wpa_supplicant non-compliant. > 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. I do not consider either of those proper ways of working around the issue.. > 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. It is. > Please let me know if you need more info. Could you please test if this commit without those other changes you described here is enough to fix this for you? commit 9f6a7cddc42811883d6035032854089475f2fc65 Work around AP misbehavior on EAPOL-Key descriptor version http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65 In other words, I would like to get confirmation that the specific AP that you saw this issue with works fine if the station is still including MFPC=1 in RSN element, but allows the AES-128-CMAC version of descriptor version field (3) to be used.
Jouni Malinen wrote: >Could you please test if this commit without those other changes you described here is enough to fix this for you? > >commit 9f6a7cddc42811883d6035032854089475f2fc65 > Work around AP misbehavior on EAPOL-Key descriptor version > >http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65 > >In other words, I would like to get confirmation that the specific AP that you saw this issue with works fine if the station is still including MFPC=1 in RSN element, but allows the AES-128-CMAC version of descriptor version field (3) to be used. Sure. I'll let you know about the results. Max
Max Stepanov wrote: >Jouni Malinen wrote: >>Could you please test if this commit without those other changes you described here is enough to fix this for you? >> >>commit 9f6a7cddc42811883d6035032854089475f2fc65 >> Work around AP misbehavior on EAPOL-Key descriptor version >> >>http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65 > >Sure. I'll let you know about the results. Jouni, all test passed. Thanks a lot! Max
On Mon, Nov 17, 2014 at 03:25:17PM +0000, Stepanov, Max wrote: > Max Stepanov wrote: > >Jouni Malinen wrote: > >>Could you please test if this commit without those other changes you described here is enough to fix this for you? > >> > >>commit 9f6a7cddc42811883d6035032854089475f2fc65 > >> Work around AP misbehavior on EAPOL-Key descriptor version > >> > >>http://w1.fi/cgit/hostap/commit/?id=9f6a7cddc42811883d6035032854089475f2fc65 > > > >Sure. I'll let you know about the results. > > Jouni, all test passed. Thanks a lot! Excellent, thanks!
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c index 5a4d8dc..67aeaa4 100644 --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c @@ -984,6 +984,9 @@ int wpa_supplicant_set_suites(struct wpa_supplicant *wpa_s, struct wpa_ie_data ie; int sel, proto; const u8 *bss_wpa, *bss_rsn, *bss_osen; +#ifdef CONFIG_IEEE80211W + int pmf; +#endif if (bss) { bss_wpa = wpa_bss_get_vendor_ie(bss, WPA_IE_VENDOR_TYPE); @@ -1170,9 +1173,14 @@ int wpa_supplicant_set_suites(struct wpa_supplicant *wpa_s, } wpa_sm_set_param(wpa_s->wpa, WPA_PARAM_MGMT_GROUP, wpa_s->mgmt_group_cipher); - wpa_sm_set_param(wpa_s->wpa, WPA_PARAM_MFP, - (ssid->ieee80211w == MGMT_FRAME_PROTECTION_DEFAULT ? - wpa_s->conf->pmf : ssid->ieee80211w)); + + if (ie.capabilities & WPA_CAPABILITY_MFPC) + pmf = ssid->ieee80211w == MGMT_FRAME_PROTECTION_DEFAULT ? + wpa_s->conf->pmf : ssid->ieee80211w; + else + pmf = 0; + + wpa_sm_set_param(wpa_s->wpa, WPA_PARAM_MFP, pmf); #endif /* CONFIG_IEEE80211W */ if (wpa_sm_set_assoc_wpa_ie_default(wpa_s->wpa, wpa_ie, wpa_ie_len)) {