The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

> Since eduroam CAT is a tool I suggest to use it as a tool. What you
> suggest is to set up a global single service a statical one in his
> design.

It's not what we are "suggesting" - it is a consequence of the design
paradigms of eduroam as such. eduroam *is* a global cohesive service,
and our aim towards users is that they can expect a good quality of
service - regardless where they are from, or where they are currently
situated.

In business terms, you can compare this to a global-scale franchise:
there is a central authority which sets out required rules to ensure the
desired baseline quality of service; and the actual service is then
delivered decentralised.

As in all franchises, it is an ongoing question what needs
centralisation, and what can safely be left to decentralisisation
without degrading service levels. The demarcation line certainly is a
thin line to walk on.

I am absolutely a fan of decentralisation where it does not hamper the
level of service we bring to our users. CAT is intentionally open-source
software and you are deploying your own instance for German users since
approx. 2 years now.

There are points where decentralisation does significant hurt though,
and we need to make sure such points are regulated centrally. I'm sure
we can all enumerate plenty of such points in eduroam's long history:

in the beginning, we considered the trinity of IEEE 802.1X OR VPN OR
Captive Portals under the brand name eduroam - a bad idea, we had to
centralise towards one technical platform

Then, we had numerous SSIDs - a bad idea, we had to mandate one SSID
where possible.

We did not have a list of required open ports - a bad idea, and we
changed in a later version of the policy.

We didn't care about WPA vs. WPA2 - a bad idea, we had to move to force
WPA2 support.

As can be seen from above, as operation of eduroam continues, friction
points sometimes arise and we have to ask ourselves the question: can we
let this grow freely, or do we need a central point of view and policy
regulation on it to prevent harm from our users.

> Let decide each NREN whether they want to set up an own CAT or
> not. What is the problem to have separated CAT instances?

In an offline discussion, I gave a very detailed explanation of the
*technical* problem we are starting to encounter just now - precisely
because CAT continues to evolve.

We now support Android; and the de-facto standard distribution for
Android apps is the Google Play Store. We can only upload a binary
version of our app which needs to be pre-set to contact the IdP
discovery API.

Making the API server to contact configurable defeats the purpose of the
app; it is supposed to make eduroam easier to configure by not requiring
to enter configuration details - and an API endpoint configuration is
exactly one of the obscure technical things we do not want users to ever
see.

As a consequence, right now the IdP discovery feature in the Android
works for everyone on the planet except users in Germany because the API
endpoint is different and "our" instance knows nothing about Germany.

That is one of those situations where multiple instances of the CAT
service *do* present harm/inconvenience/annoyance to end users.

I don't know if we are able to kit this problem. It would either require
significant amounts of coding (an API "proxy" which knows how which "n"
CAT servers to query, and merge the results from those servers, and send
the merged results onwards to the app; please contribute code if you
find that a desirable option), or be otherwise unpleasant - it is e.g.
possible to tell the Play Store to exclude an app from specific national
markets.

That last sentence is not meant as a threat - I am merely following your
argument: you want to run the show yourself; okay, but then you have to
go all the way.

> Sorry, but I
> can't follow the security argument if we have one global CAT instance. 

I am not presenting a security argument but a purely operational one:
Some things are going to be broken, like Android IdP discovery.

I can only see the amount of breakage increase. One example.

We are going to introduce new features in CAT 1.2 to allow self-service
debugging for end users. The user can tell us which IdP he's from, and
we try to find out by geolocation where he is, which is likely the
hotspot he is at, and do our best to diagnose the problem.

This requires that the diagnostics tool has a global overview of all
IdPs and their pertinent connection settings and the same global
overview of all the hotspot locations.

Some of this information comes from the eduroam Operations database
(which is BTW global and that is broadly accepted); some other parts are
IdP specific and source themselves from "the" CAT.

If there are multiple partitions of CAT data and access is not
seamlessly possible, the diagnostics will necessarily fail or be of
inferior quality if the required information is not available.

This would again be an item which has negative impact on end users and
needs to be avoided.

> If this instance is hacked/compromised than every single eduroam account
> and even the devices around the world could be in danger. A hacker only
> needs to poison one template and gets all. This would be another worse
> case scenario in eduroam. 

That's true. It is just as true for pretty much every web service on the
internet though. If LinkedIn gets hacked - account info for the whole
planet is at stake. If someone manages to manipulate Google's search
engine backend - he controls the searches of the world.

Would you find it a viable countermeasure that a Google Germany only
allows Germans to search for German web sites?

Splitting a service into numerous independently operating partitions
creates data barriers, with positive and negative consequences. It also
increases the number of partion servers to maintain; which brings
additional risks as in increased attack surface.

I'm very security sensitive and take security arguments serious. But
this argument is so generic that it brings few actionable insights.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature