Re: WPA problem and eduroam

["Miroslav Milinovic" <miro@xxxxxxx>]

Tomasz,

> Yes it does, but no university can run AES only without kicking off a
> significant number of users. And if we want to be guest-friendly then we
> should not disable TKIP on our eduroam SSID at least for quite some time.
> The fact that the policy allows us to run: dynamic WEP, WPA/TKIP,
> WPA2/AES is exactly the problem. With a single SSID we have no option
> but allow that, but this network will never work according to the
> scenario "start your device and be on-line". eduroam2 can bring us a lot
> closer to this, and what is more important, opens a path for achieving 
> this.

I do acknowledge the "cypher mash" problem you're pointing to but may 
position is that we should not introduce new mash (SSID based: eduroam, 
eduroam2, eduroam3, ... eduroamx, eduroan-ng?) to resolve the current one. 
That is just closing one and opening another (IMO bigger) problem.

I do fear that by introducing eduroam2 we are making big step back when it 
comes to the usability of the service. In time eduroam2 will be common 
thing, eduroam SSID will "die", and WPA/AES will have a successor ... what 
to do then (with SSIDs)?

On the other hand I do not fear to propose more constrains in the policy or 
least write that WPA/AES is in the "SHOULD status". If at least 50% of our 
users have the equipment that will work Ok with WPA/AES then IMHO we should 
start serious thinking on progressing in that area. We'll never be able to 
satisfy the ones with old or exotics clients - the realistic goal is to 
reduced that number as much as possible.

Regards

Miro