Page MenuHomeFreeBSD

net80211: add initial key management suites from 802.11-2016, APIs to register them
ClosedPublic

Authored by adrian on Apr 23 2024, 10:07 PM.
Referenced Files
Unknown Object (File)
Tue, Nov 26, 3:54 PM
Unknown Object (File)
Sat, Nov 23, 11:38 PM
Unknown Object (File)
Fri, Nov 22, 12:27 PM
Unknown Object (File)
Fri, Nov 22, 3:40 AM
Unknown Object (File)
Fri, Nov 22, 3:40 AM
Unknown Object (File)
Fri, Nov 22, 3:40 AM
Unknown Object (File)
Fri, Nov 22, 3:39 AM
Unknown Object (File)
Fri, Nov 22, 3:39 AM

Details

Summary

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management suites to support!

So, add initial support for net80211 and drivers to announce what
key management suites are supported. These are the list from 802.11-2016
section 9.4.2.25.3 (AKM suites.)

The flags are (a) HW and SW, and (b) global.
Drivers may support more key management suites and are welcome to
announce more; net80211 will only announce ones that we know
net80211 knows "enough" about to support correctly.

(Note: For now are limited to WPA-PSK / WPA2-PSK, which is what
net80211 "supports".)

There /are/ other suites that may be interesting to some people in
the future thta are not part of this set - eg if anyone ever
wants to support the Chinese WAPI standard - so this bitmap is not
specifically just the AKM suites in the RSN OUI.

This should eventually be communicated up to the wpa_supplicant and
hostapd via a replacement driver/vap capabilities call so they know
what to enable rather than just IEEE80211_C_WPA1 / IEEE80211_C_WPA2.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

adrian updated this revision to Diff 137580.

add differential link

bz requested changes to this revision.Apr 25 2024, 3:28 AM
bz added a subscriber: bz.
bz added inline comments.
sys/net80211/ieee80211_crypto.c
161

supported what?

166

Someone will soon by tool remove the duplicate word here so better just not add it.

214

I find this a misalignment (driver vs. hw); I still think of the driver as software and in these cases as "hw" as what can be offloaded.

sys/net80211/ieee80211_var.h
414

Why do you sort them differently to above?

This revision now requires changes to proceed.Apr 25 2024, 3:28 AM
adrian added inline comments.
sys/net80211/ieee80211_crypto.c
214

I'm actually wondering about that specific distinction myself.

I think it'll be a good thing to plan for, for NICs that actually do full MLME (ie, don't use mac80211) and/or don't require full / any wpa_supplicant / hostapd (ie, nl80211 only NICs, through to things like the broadcom NICs that don't even SUPPORT supplicant APIs; you just control them entirely over ioctl APIs.)

Lemme think about this a bit more. I don't think we FULLY have all the pieces abstracted out to support completely smart wifi parts, but it would be a good eventual goal to support.

I just removed the hw caps for now, i'll chase that up later when this stuff has landed and we've had a chance to think about how to support full supplicant/mlme management (like VERY fullmac) NICs.

Is there any implementation for these new functions, i.e., something which updates the drivers or is this just dead wood swimming down the river?

sys/net80211/ieee80211_var.h
415

Can we actually have a different set per-VAP or is this superfluous duplication we need to keep in synch for no benefit?

sys/net80211/ieee80211_var.h
415

Aha, a great question. So, I /believe/ so? Looking at the linux nl80211 API and the wpa driver code for it, they support different different VAP capabilities for different VAP configurations - eg what's supported in p2p may be different to STA.

Honestly I'm not glued to it; I'm happy to yeet the per-VAP placeholders out for now if you'd like and re-introduce it when we hit it.

net80211's driver layer queries the VAP parameters anyway rather than the driver layer parameters (eg - they're querying vap wlan0, not ye olde ic ath0) so we can change this behaviour in net80211/ioctl layer without needing to update driver_bsd.c in wpa.

remove the VAP keymgmt flags for now; will reintroduce it and change the
ioctl API to use that instead when it's necessary.

adrian marked 2 inline comments as done.
This revision was not accepted when it landed; it landed in state Needs Review.May 14 2024, 9:40 PM
This revision was automatically updated to reflect the committed changes.