Page MenuHomeFreeBSD

net80211: bump maximum key size to 384 bits
Needs ReviewPublic

Authored by adrian on Tue, Apr 23, 11:06 PM.
Referenced Files
Unknown Object (File)
Mon, May 6, 5:55 AM
Unknown Object (File)
Sun, May 5, 7:20 PM
Unknown Object (File)
Tue, Apr 30, 8:12 PM
Unknown Object (File)
Fri, Apr 26, 7:45 PM
Unknown Object (File)
Fri, Apr 26, 5:23 PM
Unknown Object (File)
Fri, Apr 26, 3:42 AM
Unknown Object (File)
Fri, Apr 26, 3:04 AM
Unknown Object (File)
Fri, Apr 26, 2:59 AM

Details

Reviewers
None
Group Reviewers
wireless
Summary

This is needed for SHA-256 and SHA-384 keys.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 57313
Build 54201: arc lint + arc unit

Event Timeline

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

in /theory/ the key struct is flexible, as it has the payload at the end and a len at the beginning.

in /practice/ I saw some weird stuff happen here, so I need to go and revisit it all before i land. I /think/ passing in a larger key request (even with wk_len being set properly) to an older net80211 caused EINVAL to be returned and that could be problematic. However, that's solvable in userland with a bit of fore-thought..

OK, I rebuilt world and found where this breaks userland.

ieee80211_ioctl_setkey() has an explicit length check to ensure the submitted struct matches its own struct.

We could support longer keys by simply removing that check and ensure that the request length and key length fit inside the buffer length provided.
I'm however worried that this length check is hiding some much earlier change in structure size (rather than changing the ioctl value, adding versioning, etc.)

So before I land this particular change, we're going to want to have a discussion about how to make this forward and backward compatible.

wpa_supplicant < net80211 is easy - just handle the size check differently.
wpa_supplicant > net80211 is less easy - it'll need to know about the "old" (128 bit key size) and "new" (larger? 384 bit key size? variable key size?) and retry setting the 128 bit keys using the older API if the newer one fails.

The nice thing here is we can extend the key request struct to include more fields with the change, eg adding support for MFP keys (key slots 5 and 6), key id 0 and 1 for unicast session key switchover, etc, etc.

Maybe we can get away with using i_val == 1 for "version 1" of the ioctl call (as all the previous ones will definitely use i_val == 0) and just trust older kernels to fail if the size check is different?