netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).