Page MenuHomeFreeBSD

net80211: add new ciphers and RSN flags
Needs ReviewPublic

Authored by adrian on Fri, Apr 19, 2:08 PM.
Referenced Files
Unknown Object (File)
Wed, May 1, 7:11 PM
Unknown Object (File)
Wed, May 1, 5:24 AM
Unknown Object (File)
Sat, Apr 27, 6:52 AM
Unknown Object (File)
Sat, Apr 27, 6:22 AM
Unknown Object (File)
Fri, Apr 26, 1:08 PM
Unknown Object (File)
Fri, Apr 26, 10:33 AM
Unknown Object (File)
Thu, Apr 25, 8:12 PM
Unknown Object (File)
Thu, Apr 25, 8:08 PM

Details

Reviewers
adrian
bz
cc
Group Reviewers
wireless
Summary

These are the rest of the ciphers and RSN flags from 802.11-2016.

  • add the rest of the ciphers from 802.11-2016
  • add the rest of the RSN flags from 802.11-2016

Of special interest here are the extended key ID field for supporting

1 unicast key (to support seamless rekeying w/out dropping frames)

and the MFP (management frame protection) config bits.

This is a no-op; no code is using these new fields.
(In particular, no code in net80211 uses the RSN capability bits;
but that will change when we start on MFP support.)

Diff Detail

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

Event Timeline

bz requested changes to this revision.Fri, Apr 19, 4:47 PM
bz added a subscriber: bz.
bz added inline comments.
sys/net80211/ieee80211.h
1269

Comments are a tab further out here.

1283

Why a comment instead of _256 here for these two?

1284

This is /* Reserved */ for the standard you are citing.

1285

Compered to the plain CCMP which we could also defined double as CCMP_128 the comment here is not needed.

1286

Why not TDLS_256 in this case either? Either we are consistent with all or not?

1290

Above you are using "Table 9-131—Cipher suite selectors" here you are using 9-xx and then (). Why don't keep it as ", Table 9-133 - AKM suite selectors"?

1290

I think the world (other standards) generally call them "Suite B" and I think it would remove confusion if it were added here.

1291

The two comments are encoded in the name so what's the need for them?

1294

, Figure 9-257 - RSN Capabilities field format

1295

How much of this do you actually need in the kernel compared to just the supplicant?

This revision now requires changes to proceed.Fri, Apr 19, 4:47 PM
emaste added inline comments.
sys/net80211/ieee80211.h
1278

Thank you for putting the references in!

1281–1282

reserved?

1285–1288

These are decimal in the spec, any reason not to follow suit? The compiler doesn't care and it's easier for humans to match.

sys/net80211/ieee80211.h
1295

Today? None of them. It's just to get them into the tree.

But soon? We're going to need to use them as part of IE parsing and in IBSS/hostap modes, as we drive a bunch of that initial MLME machinery here in net80211 before we hand it off to the hostapd side to handle key management.

(See how the WPA/WPA2 and cipher flags get used in net80211, we're going to need similar stuff here for MFP and EXT_KEYID_CAPABLE too.)

sys/net80211/ieee80211.h
1281–1282

Yeah, it was used in an early draft for AES-OCB. It never landed in the spec, but we have AES-OCB placeholders still in the code.

(i went looking for the cipher code for this out of morbid curiousity, but couldn't find any!)

I'll review the AKM names a second time; stay tuned.

sys/net80211/ieee80211.h
1281–1282

oh /this/ one is reserved? lemme double check, sorry!

adrian added inline comments.
sys/net80211/ieee80211.h
1290

I'm open to suggestions, esp if they align better with how nl80211 names them.

I based these on the 802.11-2016 names, and it doesn't mention suite-b here ;-)

sys/net80211/ieee80211.h
1290

Not sure where you are looking but the table you referenced actually says does.

".. using a Suite B compliant EAP method .."

I don't know about nl80211, I know from some RFCs in a different world.

adrian marked an inline comment as done.

rename fields

sys/net80211/ieee80211.h
1290

oh lord, yes you're right. I was just looking at the name of the thing, not what was using it. :-) Oops!

updated after looking at wpa's definition of it in the 802.11 spec headers in it:

#define RSN_AUTH_KEY_MGMT_802_1X_SUITE_B RSN_SELECTOR(0x00, 0x0f, 0xac, 11)
#define RSN_AUTH_KEY_MGMT_802_1X_SUITE_B_192 RSN_SELECTOR(0x00, 0x0f, 0xac, 12)

cc requested changes to this revision.Wed, Apr 24, 8:11 PM
cc added a subscriber: cc.
cc added inline comments.
sys/net80211/ieee80211.h
1282–1333

I can find the definition of RSN, OUI, WPA, AKM, etc.

Let me guess the "CSE" inside RSN_CSE_NULL. Is it Cipher Shift Element or Cipher Suite Element? Please help add the comment of this acronyms as I guess it is challenging to read so many acronyms, not even say find these acronyms.

1289

Instead of 0x07, use 7 to keep consistency.

1298

Let me guess the "ASE" inside the RSN_ASE_NONE means "Authentication Suite Element"?

1309

Shall be RSN_ASE_8021X_SUITE_B_256?

1310

I can find the same *_8021X_SUITE_B_192 in Linux, but actually the table says using SHA-384. Confusing? Shall be RSN_ASE_8021X_SUITE_B_384?

1319

I think use CAPABLE as RSN_CAP_MFP_CAPABLE is consistent with it in the Figure 9-257.

This revision now requires changes to proceed.Wed, Apr 24, 8:11 PM
cc requested changes to this revision.Mon, Apr 29, 2:56 PM
cc added inline comments.
sys/net80211/ieee80211.h
1333

The table shows 16 replay counters per PTKSA/GTKSA/STKSA for "Replay counter value 3".

This revision now requires changes to proceed.Mon, Apr 29, 2:56 PM

address comments from cc@

sys/net80211/ieee80211.h
1333

oh good catch!

Individual accept.

Most of the comments were marked "done" and changed some since the original comments but the "RSN AKM suite element" table still has a mix of #define suffixes and comments for the "256" cases? Is this on purpose for some reason beyond this file? At least the TDLS case I had originally asked for _256? I just wonder why not? Can you explain?

sys/net80211/ieee80211.h
1286

This was marked done but never addressed?

adrian added inline comments.
sys/net80211/ieee80211.h
1286

I thought I had made them all internally consistent now?