On Wed, Oct 04, 2006 at 01:57:38PM -0400, Dan Williams wrote: > * None > - Crypto: None > - 802.11 Auth: Open System > > * Static WEP > - Keys: up to 4 group keys > - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 > - 802.11 Auth: Open System or Shared Key > - Key Mgmt/Auth: none > > * Dynamic WEP (LEAP?) > - Keys: up to 4 group keys > - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 > - 802.11 Auth: Open System (only?) > - Key Mgmt/Auth: IEEE 802.1x with LEAP or EAP > > * WPA PSK > - Keys: pairwise & group > - Use WPA IEs > - 802.11 Auth: Open System > - Crypto: TKIP or CCMP > - Key Mgmt/Auth: WPA-PSK (elided 802.1x) > > * WPA Enterprise > - Keys: pairwise & group > - Use WPA IEs > - 802.11 Auth: Open System > - Crypto: TKIP or CCMP > - Key Mgmt/Auth: WPA-EAP (full 802.1x) > > * WPA2 PSK > - Keys: pairwise & group > - Use RSN IEs > - 802.11 Auth: Open System > - Crypto: TKIP or CCMP > - Key Mgmt/Auth: WPA-PSK (elided 802.1x) > > * WPA2 Enterprise > - Keys: pairwise & group > - Use RSN IEs > - 802.11 Auth: Open System > - Crypto: TKIP or CCMP > - Key Mgmt/Auth: WPA-EAP (full 802.1x)
This strikes me as overly complicated; to figure out what's necessary
you shoudn't be looking at the WEXT API -- The 802.11 standards are
all you need, and they lay things out fairly clearly, complete with
rx/tx path flowcharts. :)
Essentially, you have two crypto paradigms, pre-802.11i and
post-802.11i. (WPA uses the latter, and LEAP/CCX v1 is mostly the
former; newer ones use the latter)
(Leave out the RSNIE, AuthType and KeyMgmt stuff; while they're
used in the actual key negotiation/derivation, they're separate
problems and have no bearing on the crypto layer. From the driver's
perspective the RSNIE is just an opaque blob to be appended to
beacons,presps and [re]assoc frames, KeyMgmt is purely a matter for
the authenticator/supplicant, and AuthType is just a toggle that
happens to be off for post-802.11i, although LEAP v1 adds some
complications there..)
The old way:
* Four "default" keys. (used globally)
* PrivacyInvoked
* SetDefaultKeyIndex
The new way:
* PrivacyInvoked
* SetProtection (tx&|rx -- essentially "require crypto for a given macaddr)
* SetKeyMapping (one key per macaddr)
Each key has:
* Key type (WEP/TKIP/AES-CCMP/NONE)
* Key length (implied, but WEP can have varying key lengths)
* Key index (only '0' is generally used for unicast frames, but 802.11i
requires use of simultaneous broadcast keys)
* Macaddr (ucast addr or broadcast aka pairwise vs group)
* RxSequence (mainly for bcast aka group keys)
It's fairly easy to implement the old stuff in terms of the new stuff,
if you assume that "if I don't have a per-sta key, just use the
global/bcast key". The 802.11i rx/tx frame path flow handles the old
crypto style just fine.
...Meanwhile. It's foolish to ignore the 802.11 MLME. It lists out
pretty much everything that's necessary to get a working connection, and
looking at its evolution (and changes in the pipeline) shows that it's
impossible to do it all (right) the first time, and that changes, not
just additions, will be necessary.
(Did I mention that I really like how the ALSA people manage this? The
userspace-kernelspace API is effectively private; apps write to the
libs, which do the hard work of maintaining backwards compatibility as
the internals change and get new features, but now I'm really just
armchair quarterbacking, so I'll shut up now.)
> Wheee! So you basically have a bunch of buckets and you just pull shit
> out of them at random, stick it all together, and you've got a wireless
> connection :) Thank you, Cisco. Thank you, Wi-Fi Alliance.
You forgot the part about sacrificing rubber chickens with pulleys
in the middle. While hopping on one foot. Under a new moon.
Bah, it's too early in the morning to be thinking about this stuff.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
pgptme77JcM3O.pgp
Description: PGP signature
