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

[Martin Pauly <pauly AT hrz.uni-marburg.de>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature