Hi Jouni,
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.
Regards,
Arend
On May 31, 2022 12:29:43 PM Jouni Malinen <[email protected]> wrote:
> 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.
Thanks, Jouni
Understood.
> 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.
Right. My understanding is that there is no fundamental difference in the
protocol stack.
> 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.
Giving that I probably have to rework stuff in the brcmfmac driver I will
fix this issue along the way.
Regards,
Arend
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