using WPA3 SAE

[Jouni Malinen]

On Tue, May 31, 2022 at 10:44:32AM +0200, Arend van Spriel wrote:
> I am trying to get WPA3 SAE working with brcmfmac driver. Actually it was
> Cypress who added support for that in brcmfmac, but for me it fails now
> because wpa_versions bitmask we get from nl80211 indicates only WPA2. I know
> that wpa_supplicant does not make a difference in the config network block,
> but I did not expect that choice to affect nl80211 API usage. Do you
> consider this a bug in driver_nl80211.c? In nl80211 in the kernel we do not
> check wpa_versions versus key management suites so I guess other vendor
> drivers are more lenient.

Why would one need WPA3 indication to be able to use SAE? SAE was
defined in IEEE Std 802.11-2011, i.e., almost ten years before WPA3 was
launched. It worked and still works just fine without WPA3.
WPA3-Personal just happens to be a marketing name for SAE with PMF
enabled. So no, this is certainly not a bug in driver_nl80211.c, but
IMHO, a somewhat strange constraint in a driver to try to prevent SAE
from being used. No driver should place such arbitrary constraints on
being able to use more secure mechanisms.

I don't see much, if any, real use for the NL80211_WPA_VERSION_3 bit in
nl80211 since it should not result in any difference in driver behavior.
SAE can be used without it being called WPA3-Personal and so can PMF.

All that said, if someone really wants to use NL80211_WPA_VERSION_3 for
something, I don't think I would have anything against making
wpa_supplicant add that bit when including the NL80211_ATTR_WPA_VERSIONS
attribute for cases where both SAE and PMF are enabled for a connection.
I would not promote use of this in any driver, though, since it would
just result in issues with older versions of user space components and
there does is no WPA3 specific functionality that would be enabled (or
disabled) based on that bit.

-- 
Jouni Malinen                                            PGP id EFC895FA