Re: EAP-TTLS/PAP & dynamic WEP

[Dan Williams <dcbw redhat com>]

On Thu, 2006-10-26 at 14:59 +0200, Thomas Liebetraut wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Stefan Schmidt schrieb:
> >> click on the SSID to connect, I am prompted for authentication via key
> >> or passphrase. My options are WEP 64/128-bit ASCII, WEP 64/128-bit
> >> Hex, or WEP 128-bit Passphrase. I don't have a key to give; again, its
> >> a EAP-TTLS/PAP auth with dynamic WEP encryption scheme so they keys
> >> should be obtained automatically after the authentication.
> >
> > This happens due the AP only reports WEP encryption. I _guess_ there
> > is no way to advertise the dynamic WEP key handling. Such
> > advertisement is only posible with the IE from WPA. If I'm wrong here
> > please correct me.
> 
> This may really be a problem for the UI. If there is no way to figure
> out if the WLAN is using 802.1X and 802.1X and WEP appear to be the same
> for the software, we would have to extend the WEP connection dialog that
> pops up when connecting to an unknown WEP network to also provide the
> possibility to select "WPA Enterprise" and "WPA2 Enterprise".
> This reduces the user-friendliness and makes it even less possible to
> configure a wireless network without any knowledge. It's very
> unfortunate that the standards do not provide enough information to be
> user-friendly.

WEP is entirely broken in this regard.  You cannot figure out
Open/Shared Key auth either from the beacon, the user has to know this.
You also cannot know the format of the Passphrase->Key hashing with WEP,
because there are 40 and 104-bit variants of each of the following: hex,
ascii, passphrase.

That's why WPA is such a step forward in usability even, because they
(a) broadcast/advertise the capabilities/config of the access point, and
(b) there is _one_ method of hashing passphrase->key and only one key
type for each auth method.  Of course, that's just the over-the-air
bits, you still have to know something about what's behind the access
point gating your access (RADIUS, etc).

With WEP, I think we made the decision to not be smart about much of
anything, because it's just too easy to get it wrong.

The applet UI bits (and the applet<->NM api bits) were also written
without the flexibility that it became apparent they required.  That's
my fault, but we're stuck with that for 0.6.x unless we can come up with
an API compatibile method of reorganizing the UI dialogs to better work
with all the auth methods and encryption.

There are 3 _different_ things going on here:

1) Encryption (None, WEP, TKIP, CCMP)
2) Authentication (Open, Shared Key, 802.1x, LEAP, WPA, WPA2)
3) Key management (802.1x, WPA, WPA2)

The "brand names" of higher-security WiFi, namely WPA and WPA2, cross
the technical boundaries.  But users expect them, and everybody talks
"having WPA", and all the documentation out there references WPA, so we
can't just ignore it.  Plus, the 3-part distinction above doesn't mean a
lot to many users anyway and we shouldn't be dropping 50 options on them
up front, that's just sick.

In short, we need a way to do phase2 and make stuff like dynamic WEP
more apparent, but we need to do it in a way that doesn't break existing
stuff and that's at least mildly usable.

Dan

> 
> Regards,
> Thomas
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFQLEbxVmZpTAq4IgRAq4IAJsFcCeQ3kmrWTR0cLOdngnNJiShRwCfY6tT
> 3Fn7+7tObJyGv2KjMcS+axc=
> =uCCJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list