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

[Ralf Paffrath <paffrath AT dfn.de>]

Hi,

we can debate that endlessly. 

To sum up, I think it is not a technical problem what you want us to believe, 
it is more a political decision. The question is do we want a worldwide 
centralise solution for eduroam users to help them configure their devices 
and to support the end user? I say let the NRENs do this you say no let us 
do. From the standpoint of security you are right. In future you can dictate 
how eduroam users configure their devices which eap types are allowed and 
which not. You can force them to use this centralise server if they want 
eduroam to work, technically this is possible. And you can monitor who is 
using the one backend and who not? Consider if we can monitor the eduroam 
user, I don't know whether this is what our customers and especially the 
eduroam users expected.

If you want such a centralise solution you need more manpower and of course 
that costs money. You have to do support for millions of eduroam users and 
thousand of admins. Because as a fed admin in Germany for eduroam I can't do 
support for admins or end users anymore, I have no overview of the whole 
thing, but you have. The only thing I can do is to say go to the people of 
the centralise server they offer the service for configuration and for user 
self service debugging. in eduroam. I can't help you I can check nothing all 
the service tools and the profiles are provided at one backend.

My approach is to develop tools like CAT (not for one backend) or tools for 
monitoring to help the NRENs in doing their job, for supporting admin in turn 
of supporting users. Let us develop this within the GÉANT community, e.g. 
Norway has very good design for CAT user interface, if this could be used for 
decentralised CAT instances would be nice.

Of course there are advantages for one backend but there are disadvantages 
also what you don't should play down.
For Goggle search I have no choice I can use it or use another one. But now I 
can secure the CAT server my self I can get rid of GPL software within the 
templates what is not open source and prevent harm for our customers. If we 
have one backend I can't.

The IdP discover feature in ANDROID doesn't not work because you do not 
support the redirect in the back end for ANDROID. That is different. If you 
have an IdP who wants to deploy an own eduroamCAT XML profile is does not 
work even for cat.eduroam.org! Yes, I know this is a statical model, it is 
not intended. By the way I don't know why sometimes the redirect works and 
sometimes not, maybe this is a bug in discovery feature module. ;-)

As I said it is political not technical and I'm afraid of if we decide for 
one backend we might have many German IdP's who will not use the backend, 
because If they have wishes for new features they might get the answer what I 
got: "We can't help you, it is technically very  hard to solve and we have to 
change the paradigm and cost money and, and , and. You can do it on your own, 
we can't support you."
This is not what our customers are willing to expect.

Greetings Ralf 
On 06 Nov 2015, at 08:58, Stefan Winter 
<stefan.winter AT restena.lu>
 wrote:
> 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
> <0x8A39DC66.asc>

Attachment: smime.p7s
Description: S/MIME cryptographic signature