Taskforce Mobility Mailarchive
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