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

[Stefan Paetow <Stefan.Paetow AT jisc.ac.uk>]

Ohhhh, this is interesting, Martin.

We recently had an institution with a certificate rollover and this would've 
been very useful at the time. I'll include this in our (UK) eduroam guidance 
on certificate rollovers. :-)

With Kind Regards

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp AT jabber.dev.ja.net
skype: stefan.paetow.janet

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. 
GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, 
Bristol, BS2 0JA. T 0203 697 5800.



> On 2 Oct 2019, at 10:46, Martin Pauly <pauly AT hrz.uni-marburg.de> wrote:
> 
> Hi all,
> 
> tl;dr warning: This is about how to survive with users still using 
> passwords.
> I know EAP-TLS is better.
> 
> While the idea of device-specific credentials certainly is a laudable
> approach to mitigate the effect of a successful Evil Twin attack on eduroam 
> ...
> 
>> The device MAC address is sent along with the username in RADIUS. An
>> attacker can trivially steal the entire combination of device-username,
>> device-password and device-MAC.
>> Since MAC addresses can be changed on many OSes, the attacker now has a
>> valid and working credential on his own device of choice.
> 
> ... this is a crucial point. Harvesting the MAC address for re-use
> is just as easy as stealing a password (or MS-CHAP hash).
> 
>> That is why the eduroam policy is very explicit about server-side
>> validation: you need to instruct your users to configure server-side
>> validation, and need to supply them with the means to do so (i.e. tell
>> them about CA and expected server name). This is in section 6.3.2 of the
>> (European) eduroam Service Definition:
> 
> This is also important (and laudable), but reality differs two-fold:
> 
> 1. Admins/helpdesks give their users junk instructions
> A random example (of dozens) I recently came across:
> https://www.chapman.edu/campus-services/information-systems/_files/android-setup.pdf
> 
> 2. Most users neither read the docs nor understand them nor adhere to them.
> 
> We have (like many others) churned out correct docs for a decade now, 
> written our
> own CAT predecessors, created Apple .mobileconfigs, an finally gladly 
> switched to cat.eduroam.org.
> When all German universities and colleges faced the end of life of our 
> common root certificate in
> July 2019, most institutions had addresses this by a trick best called
> "Certificate selection by outer identity"
> (name borrowed from 
> https://help.uis.cam.ac.uk/service/wi-fi/other#server-selection)
> You insert a fork into your RADIUS server config, and deliver a server cert 
> from the new PKI
> to those clients that present a special outer ID. You deliver the old cert 
> to everyone else.
> On cat.eduroam.org you prepare this outer ID for your clients, along with 
> the new root cert
> to verify against. So even clients clinging to one cert only can migrate in 
> advance.
> 
> While this scheme worked pretty well for some 100+ institutions, it has an 
> interesting side effect:
> You can now easily see in the server logs who is still using the old 
> pattern, and who has adopted
> the new settings (just an indication, no proof).
> Doing some statistics on this before and after the PKI change was sobering.
> With our staff users, we were able to raise the fraction of seemingly 
> correct clients from 15% to
> to ~40%, but only after a time consuming campaign that involved targeted 
> bulk mails and the like.
> With the 20k+ students, it remained around 8,5%.
> Lesson learned: Users don't care, and you don't control them (except you 
> manage their devices).
> (smaller lesson learned from the campaign: If you get to explain the 
> problem, most of them will understand).
> 
> But then, you can use above information to force them to use your special 
> outer ID
> (which, one hopes, will correlate strongly with the client really verifying 
> the server cert).
> In order to not have to convert 20k students' devices at once, we recently 
> took to an extension
> of our access rights management. We introduced a property called 
> eduroamAnyOuterIdAllowed
> which has been set for all existing accounts. New accounts do not have it.
> The RADIUS server evaluates this property and rejects new accounts with 
> clueless settings.
> No statistics yet, the first ticket related to this just popped up 
> yesterday.
> Of course, we expect the new property to phase out over time.
> 
> BTW: Merits for above ideas largely go to Steffen Klemer of GWDG
> 
>>> This big advantage of my system is that it works...
> 
> Tweaking the outer id works for us _now_, as quickly as we want it to.
> (We can perfectly well enforce the new requirement on existing clients,
> as well as release it on a per-account base if technical problems occur).
> That said, it does require a pretty flexible account backend. Without such,
> you will at least need to take other precautions for those clients unable
> to set the outer ID.
> 
> Martin
> 
> 
> -- 
>  Dr. Martin Pauly     Phone:  +49-6421-28-23527
>  HRZ Univ. Marburg    Fax:    +49-6421-28-26994
>  Hans-Meerwein-Str.   E-Mail: pauly AT HRZ.Uni-Marburg.DE
>  D-35032 Marburg
>