Bug#1003907: fails to successfully associate

[Hans-Peter Jansen]

Hi,

based on the findings of Michael Biebl and Masashi Honma on this issue that 
where really helpful, thank you, and thanks to Andrej Shadura for reporting, 
I would like to share my insights, since wpa_supplicant 2.10 hit our openSUSE 
Tumbleweed repositories, and I'm one of the people affected by this.

In short this issue affects people with old wifi hardware trying to connect 
to AVM Fritzboxes, that use "WPA2 + WPA3" security (better known as WPA3 
transition mode), resulting in:

wlp3s0: CTRL-EVENT-ASSOC-REJECT bssid=<mac> status_code=40

Switching the security mode to "WPA2 (CCMP)" in the Fritzbox makes it work,
but this is NOT a desired solution of course, since it will degrade security
for all devices in that wifi network.

Mine is a "Intel Centrino Advanced-N 6205 [Taylor Peak]" from my ten years 
old Lenovo X1 Carbon (Gen 1), and from our bug tracking, we saw "Intel 
Centrino Advanced-N 6235" is affected as well. [1]

With  the change to 2.10, we got among others, full SAE (and PMF) support, 
which in theory is required for proper WPA3 Personal support.

The whole story boils down to: in the unsupported case:

$ iw phy0 info | grep -A9 'Supported Ciphers'        
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CCMP-256 (00-0f-ac:10)
                * GCMP-128 (00-0f-ac:8)
                * GCMP-256 (00-0f-ac:9)

while for a working config, it's:

	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* CMAC-256 (00-0f-ac:13)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)

For PMF, these are required:

* CMAC (00-0f-ac:6)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)

Some drivers contain them, the old Intel iwlwifi driver miss them obviously. 
"Old" in the sense of the driver version, that is contained in Linux kernel 
5.16.6, using firmware 18.168.6.1 6000g2a-6.ucode.

I was able to built a properly working wpa_supplicant package by just 
reverting one hunk [2]:

>From 7a9c36722511ce4df88b76cceceb241d6c6a151e Mon Sep 17 00:00:00 2001
From: Brian Norris <briannorris at chromium.org>
Date: Fri, 28 Feb 2020 15:50:47 -0800
Subject: [PATCH] DBus: Add "sae" to interface key_mgmt capabilities

This will be present when the driver supports SAE and it's included in
the wpa_supplicant build.

Signed-off-by: Brian Norris <briannorris at chromium.org>
---
 doc/dbus.doxygen                        | 2 +-
 wpa_supplicant/dbus/dbus_new_handlers.c | 6 ------
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git b/wpa_supplicant/dbus/dbus_new_handlers.c a/wpa_supplicant/dbus/dbus_new_handlers.c
index c842c50e9..55c5dbc99 100644
--- b/wpa_supplicant/dbus/dbus_new_handlers.c
+++ a/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -2798,12 +2798,6 @@ dbus_bool_t wpas_dbus_getter_capabilities(
 			goto nomem;
 #endif /* CONFIG_WPS */
 
-#ifdef CONFIG_SAE
-		if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_SAE) &&
-		    !wpa_dbus_dict_string_array_add_element(&iter_array, "sae"))
-			goto nomem;
-#endif /* CONFIG_SAE */
-
 #ifdef CONFIG_OWE
 		if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_OWE) &&
 		    !wpa_dbus_dict_string_array_add_element(&iter_array, "owe"))
-- 
2.34.1


In my humble opinion, wpa_supplicant should test for sufficient ciphers, 
and not even try to connect with WPA3 otherwise, in order to cope with 
drivers, that simply don't have the relevant features.

Meanwhile, one of my mates noted the issue in completely different 
constellations [3].

Best,
Pete
--
Life without chameleons is possible, but pointless.

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1195395
[2] https://build.opensuse.org/package/show/home:frispete:Tumbleweed/wpa_supplicant
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2050840