Page MenuHomeFreeBSD

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

Authored by adrian on Tue, Apr 23, 10:07 PM.
Referenced Files
Unknown Object (File)
Fri, May 3, 10:22 AM
Unknown Object (File)
Fri, May 3, 2:01 AM
Unknown Object (File)
Fri, May 3, 1:58 AM
Unknown Object (File)
Thu, May 2, 2:08 AM
Unknown Object (File)
Fri, Apr 26, 7:46 PM
Unknown Object (File)
Fri, Apr 26, 5:49 PM
Unknown Object (File)
Fri, Apr 26, 6:08 AM
Unknown Object (File)
Fri, Apr 26, 2:59 AM

Details

Reviewers
None
Group Reviewers
wireless
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 and per-VAP.
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 Skipped
Unit
Tests Skipped
Build Status
Buildable 57439
Build 54327: arc lint + arc unit

Event Timeline

adrian updated this revision to Diff 137580.

add differential link

bz requested changes to this revision.Thu, Apr 25, 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.Thu, Apr 25, 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?