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

[adrian]

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.

[adrian]

add differential link

[bz]

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?

[adrian]

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.

[adrian]

address comments

[adrian]

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.

[bz]

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?

[adrian]

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.

[adrian]

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