RFC: WPA-related API changes

[Dan Williams <dcbw redhat com>]

Hi,

So in the search for WPA (I know it's here somewhere...), there need to
be some API changes for NetworkManager.  These are related to key types
and auth algorithms, and shouldn't impact core functionality much for
apps the depend on NM.

However, I've taken this as an opportunity to look closely at the
current API and how it doesn't quite fit where I think NM should go.
Comments quite welcome.

First, a few key points:

- Current NM APIs are limited to WEP because no drivers supported WPA
last year.  When drivers started to support WPA early this year, every
driver exposed a different WPA interface.  Now that drivers are
consolidating around the new kernel 802.11 stack, and now that
wireless-tools has WPA support built-in, we finally have a sane platform
on which to build our WPA support.

- wireless-tools exposes many constants for wireless-related functions.
NM exposes some constants as well.  I think it's somewhat daft to use
our own.  wireless-tools has finally come to the point where its
constants overlap 110% of NMs, hence we should probably use
wireless-tools now rather than our own.

- Adding WPA and WPA2 to the mix adds a few new ciphers and a some new
authentication algorithms that we really want.  They include TKIP, CCMP,
LEAP, and other 802.1x stuff.  NM doesn't currently know anything about
these.  The keys that these use are different than WEP, and use
different passphrase->key algorithms than WEP.

With these points in mind, here are my ideas on what should happen with
NM.

1) Adopt wireless-tools constants wholesale for keytype and
authentication modes.  While some of these are actually bitfield
positions, that doesn't really matter for us.  The NM API would then
accept constants like IW_AUTH_CIPHER_WEP104 and IW_AUTH_CIPHER_TKIP
rather than stuff like NM_ENC_TYPE_128_BIT_PASSPHRASE.  802.11 auth
methods would map directly to wireless-tools equivalents, such as:

NetworkManager                       wireless-tools
-------------------------------------------------------------------
NM_DEVICE_AUTH_METHOD_NONE           -
NM_DEVICE_AUTH_METHOD_OPEN_SYSTEM    IW_AUTH_ALG_OPEN_SYSTEM
NM_DEVICE_AUTH_METHOD_SHARED_KEY     IW_AUTH_ALG_SHARED_KEY


2) Move higher-level key types to the applets, rather than keeping logic
for them in NetworkManager.  Right now we have the constants for ASCII,
hex, and pass-phrase key types.  Logic for these would get punted to the
info-daemon and its associated applications, like the gnome-applet.  The
info-daemon would be responsible for conversion from the user-visible
type (128/104-bit WEP pass-phrase) to the raw key value and algorithm
type (26-byte key + WEP104).  NetworkManager would only accept the raw
key value, cipher type, and auth algorithm.

This would break existing stored preferences.

The goal here is to move more user-provided details into the applets and
to simplify NetworkManager itself, and provide an API that dovetails
closely with the core system APIs like wireless-tools.

I foresee moving more of this functionality (some of the "smart" bits)
out to the applets and/or clients of NetworkManager rather than keeping
it in NM itself.  As we try to build out the capability of NM past the
original goals of seamless laptop/mobile use, this will get more and
more important.

Comments and thoughts?

Dan