From: Stuffed Crust <pizza@shaftnet.org>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
netdev <netdev@vger.kernel.org>, Jiri Benc <jbenc@suse.cz>,
"John W. Linville" <linville@tuxdriver.com>,
Larry Finger <Larry.Finger@lwfinger.net>,
Jouni Malinen <jkm@devicescape.com>, Thomas Graf <tgraf@suug.ch>
Subject: Re: [RFC] cfg80211 and nl80211
Date: Thu, 5 Oct 2006 09:13:53 -0400 [thread overview]
Message-ID: <20061005131353.GA3432@shaftnet.org> (raw)
In-Reply-To: <1159984658.3287.98.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4325 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-10-05 13:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-28 9:23 [RFC] cfg80211 and nl80211 Johannes Berg
2006-09-29 21:10 ` James Ketrenos
2006-09-30 3:00 ` Michael Wu
2006-10-02 9:08 ` Johannes Berg
2006-09-30 3:14 ` Michael Wu
2006-10-02 16:15 ` Dan Williams
2006-10-02 17:01 ` Dan Williams
2006-10-04 7:41 ` Johannes Berg
2006-10-04 14:19 ` Johannes Berg
2006-10-04 17:57 ` Dan Williams
2006-10-05 7:59 ` Johannes Berg
2006-10-05 13:13 ` Stuffed Crust [this message]
2006-10-05 15:46 ` Jouni Malinen
2006-10-05 16:20 ` Jouni Malinen
2006-10-06 9:41 ` Johannes Berg
2006-10-05 7:47 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061005131353.GA3432@shaftnet.org \
--to=pizza@shaftnet.org \
--cc=Larry.Finger@lwfinger.net \
--cc=dcbw@redhat.com \
--cc=jbenc@suse.cz \
--cc=jkm@devicescape.com \
--cc=johannes@sipsolutions.net \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).