Re: WPA problem and eduroam

[Mohacsi Janos <mohacsi@xxxxxxx>]

Hi Stefan,
	I fully support your suggestions...

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Wed, 3 Dec 2008, Stefan Winter wrote:

> Hello,
>
> > > I would change the order:
> > > SSID eduroam1 with WPA/TKIP + WPA2/AES
> > > SSID eduroam with WPA2/AES ony
> > >
> > > I would keep eduroam1 for compatibility reason - if somebody has
> > > problem from WPA2/AES they can switch back to eduroam1 ....
> > To do this would require a serious policy change
>
> So would the introduction of "eduroam2" - this is not foreseen in the policy. 
> I don't see why the integer 1 has any less problems than 2.
>
> > and would completely
> > break down the service. All eduroam TKIP users would suddenly lose
> > connectivity.
> > Doing it the other way round - adding a new "better" SSID would give the
> > users an option to configure this new connection, while still keeping
> > the old one.
>
> If an eduroam site administrator is really concerned about the TKIP breakage, 
> and to such an extent that he wants a separate "clean" AES network, then I 
> would think he will also want to actively discourage his users to still use 
> TKIP (as opposed to passively encourage a move by providing a separate SSID 
> for the "better" network). For such an admin, it may well be appropriate to 
> lock out TKIP users in the first place, and force them to reconfigure their 
> clients - telling them: reconfigure for AES, and *only* if your hardware 
> supports TKIP only use eduroam1 (or, as I would prefer, eduroam-legacy).
>
> > This way they would have something new without giving up the old.
>
> The point is that we *want* to get rid of this old, isn't it? And for 
> profound security reasons even.
>
> Also
> > you will never achieve all sites changing their settings on eduroam, so
> > you will never have a "clean" solution. The new SSID would be
> > implemented from scratch so the institutions only used it if they wanted
> > to start the AES-only service.
>
> It's not clean right now anyway, so we wouldn't lose anything :-)
>
> My personal suggestion to the problem is to send out a "deployment advisory" 
> documenting our suggestions for a smooth move. A quick first shot would be
>
> **************************************
>
> Cipher suite selection for eduroam Service Providers
> ====================================================
>
> The recent breakage of the TKIP encyption algorithm suggests to transition to 
> an AES infrastructure in the short to mid-term future. The following 
> practices are suggested when considering the use of encryption methods.
>
> New deployments
> ---------------
>
> If you are deploying a new eduroam Service Provider, you should provide 
> WPA2/AES only. Since all older encryption schemes either experienced a 
> cryptographic compromise (WEP, WPA/TKIP, WPA2/TKIP) or have limited client 
> compatibility (WPA/AES) it seems unadvisable to introduce such legacy ciphers 
> in new site deployments.
>
> Existing deployments, currently offering WPA/TKIP and WPA2/AES
> --------------------------------------------------------------
>
> Since your network already offers WPA2/AES as an option, you do not 
> necessarily take action. We advise to inform your users about the new 
> shortcomings of WPA/TKIP and encourage them to use WPA2/AES only. You are 
> free to keep your setup as it is right now.
> If you are very concerned about your network security, and want to remove the 
> WPA/TKIP cipher, you are free to do so but should keep legacy clients in mind 
> that currently use WPA/TKIP and cannot or do not care to use WPA2/AES. By 
> turning off WPA/TKIP, these users will not be able to use the service any 
> more. The latter user group (unwilling, but capable of AES) would then need 
> to reconfigure their clients, which may increase helpdesk load. For the 
> former user group (impossible to use AES), you can choose to either leave 
> this user group behind (we strongly suggest to survey your site before doing 
> so, to become aware of the potential impact) or to provide a legacy SSID 
> "eduroam-legacy" which enables WPA/TKIP usage.
>
> Existing deployments, currently offering WPA2/AES only
> ------------------------------------------------------
>
> You win! Nothing to be done!
>
> Existing deployments, currently offering WPA/TKIP only
> ------------------------------------------------------
>
> You should examine your site hardware and firmware (upgrade?) whether it is 
> possible to enable WPA2/AES in addition to WPA/TKIP. If so, you should do so 
> and no further action is necessary. See the section above for SPs with 
> WPA/TKIP and WPA2/AES above for further security considerations.
> If your equipment does definitely not allow you touse WPA2/AES, you should 
> consider buying a new generation of wireless networking equipment.
>
> Existing deployments, currently offering other ciphers
> ------------------------------------------------------
> WPA/AES is a rather exotic cryptographic setting, we suggest configuring 
> WPA2/AES instead.
> WPA2/TKIP is both rather exotic and compromised, we suggest configuring 
> WPA2/AES instead.
> Dynamic WEP is discouraged in eduroam since several years already. If you 
> still have such equipment, we very strongly suggest to upgrade to a new 
> generation of wireless networking equipment which supports modern encryption 
> settings like WPA2/AES.
>
> **************************************
>
> As I wrote this, I realised it would be much easier to determine what action 
> to take or suggest if we had a better overview about the encrpytion ciphers 
> deployed at hotspots right now. This is yet another reason to *use the 
> database* - at occasions like this one, it is vital have a rough idea about 
> our deployment world out there. Please, everybody, try to (make your 
> participants) deliver basic information about the hotspots.
>
> I'm aware that my proposal above will not remain undisputed. It is just to 
> start a discussion for all variants of cipher deployment we have (i.e. make 
> the discussion more fine-grained). I think some of the cases above are rather 
> easy, like (surprise!) the "New deployment" or the AES only one. The others, 
> well, the stage is open. We have to suggest *something* to our participants, 
> whichever variant they offer, so I would very much like to invite a 
> discussion on all the sub-cases we have to consider.
>
> Greetings,
>
> Stefan Winter