wpa_supplicant-dbus WPA3-SAE support

[GNUser]

Hi Juanito. You are one of the maintainers of wpa_supplicant-dbus x86_64. I am upgrading my home wireless network to WPA3 but wpa_supplicant-dbus was compiled without support (CONFIG_SAE=y is needed).

Do you mind if I recompile this extension to add SAE support? I could also update it from version 2.10 to 2.11 while I'm at it. Other than the new version and the SAE support, no other changes would be made. This is for TCL15 x86_64.

[Juanito]

Sure, please go ahead - I’m away for the next week or so anyway.

[GNUser]

Got it. The updated extension will be in your inbox when you return. Thanks!

[Paul_123]

Are you going pure WPA3?   My router supposedly supports WPA3.  But wpa_supplicant 2.11 with SAE=y still wont connect in pure WPA3 mode (key_mgmt=SAE)   It will connect in SHA256 (key_mgmt=WPA-PSK-SHA256)

iwd however works just fine.  (https://mirrors.edge.kernel.org/pub/linux/network/wireless/)

Some of this may be due to wifi firmware properly supporting SAE too.......

[Paul_123]

I should note that wireless_tools  (iwconfig/iwlist) cannot properly display WPA3 adapter/ap information, you will need to use iw to see that information, which is currently maintained at
 https://mirrors.edge.kernel.org/pub/software/network/iw

[GNUser]

Hi Paul_123.

Are you going pure WPA3?

Yes, that's my intention.

* my AP's firmware supports it and I recompiled hostapd for it to add SAE support
* clients' firmware support it and just now I compiled wpa_supplicant 2.11 with SAE support for them

But it's all wishful thinking until I'm actually home later today and can test it all out. I'm hoping to get away with wpa_supplicant and not have to resort to iwd/eiwd.

Thanks for the heads up regarding wireless_tools. I'm good there--I migrated all my scripts to  iw  several months ago.

[Rich]

Hi GNUser

Hi Paul_123.

Are you going pure WPA3?

Yes, that's my intention. ...

Surely you can maintain backward compatibility.

Yeah, yeah. I know, .... "And don't call me Shirley".

[Paul_123]

Only reason to move to WPA3, would be to close the holes in WPA2.  Maintaining backwards compatibility would defeat the purpose, since the WPA2 holes would still be there.

[GNUser]

Hi Paul_123. My AP is powered by TCL (running updated hostapd with SAE support). Here is what my TCL clients (running updated wpa_supplicant with SAE support) are telling me:

Code: [Select]

$ wpa_cli status
Selected interface 'wlan0'
bssid=xxx
freq=5180
ssid=xxx
id=0
mode=station
wifi_generation=5
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=1
mgmt_group_cipher=BIP
sae_group=19
sae_h2e=0
sae_pk=0
wpa_state=COMPLETED
ip_address=xxx
p2p_device_address=xxx
address=xxx
uuid=xxx
ieee80211ac=1
I think things are looking pretty good Anything you'd tweak?

Hi Rich. I think I'm going to agree with you (as usual) and go with WPA2/WPA3 Transitional (mixed) security in my AP configuration--for the sake of the handful of devices in my home that do not support WPA3 as well as for the sake of my guests (whose devices may or may not support WPA3).

[Paul_123]

Running WPA/Hostapd of the same version definitely makes it easier.

Why complicated things with a mixed WPA2/3 environment.  Since the weak spot is the WPA2 device......The 4way handshake of the WPA2 device is what would get attacked.

[Rich]

Hi Paul_123
I'm not up on the ins and outs of WPA2/WPA3, but being backward
compatible doesn't automatically compromise security if all of your
hardware supports WPA3, does it?

I'm also looking at this from the point of an unsuspecting user running an
update of their installed extensions, and suddenly half of their connected
devices no longer respond. They may not want to or be able to replace
those devices. While it might be possible to get software updates for some of
those devices, I suspect stuff like thermostats, doorbell cameras, additional
security cameras, door locks, refrigerators, stoves, and all of the other
silly IOT stuff out won't have software updates available.

I did do a little reading and the general consensus is WPA2+WPA3 is no better
than running WPA2.

It was also suggested to run the WPA2 stuff on a separate LAN (or VLAN) that's
isolated from the WPA3 LAN.

[Paul_123]

The largest wpa2 risk is a deauth followed by a capture of the 4 way handshake which exposes the encrypted paraphrase….. then a brute force password attack of you passphrase.  While still highly unlikely to the average user with a strong passphrase.  A successful attack would give the person full access.

Isolating wpa2 from your other devices would be a step up in security.

Just the presence of wpa_supplicant 2.11 with SAE enabled will not change anything for the unsuspecting person updating their extensions.  Wpa3/Sae requires different conf entries

[GNUser]

Just the presence of wpa_supplicant 2.11 with SAE enabled will not change anything for the unsuspecting person updating their extensions.  Wpa3/Sae requires different conf entries

This is correct. Using WPA3 requires software that supports it on both ends (i.e., hostapd and wpa_supplicant compiled with SAE support), hardware that supports it on both ends, and configuration (of AP and client) that turns it on.

Missing SAE breaks things for folks that are trying to use WPA3. Adding SAE support does not break things for anyone.

[GNUser]

It was also suggested to run the WPA2 stuff on a separate LAN (or VLAN) that's
isolated from the WPA3 LAN.

This is a really good idea.