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

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

Hi,

Am 10.05.21 um 16:29 schrieb Roberto Flor:
> After googling around I found that In December 2020, the  Android 11 QPR1 
> security disabled the ability to select “Do not validate” for the “CA 
> Certificate” dropdown in network settings for a given SSID and changed the 
> supplicant behaviour.
... and Samsung re-enabled (or still has) it, at least in a Student's Galaxy 
A51 with Android 11 we set up last week.

> Note that the changes are in the WPA3 specification, not in Android 
> documentation. This implies that the same issue could be shown up  for other 
> operating systems in the future as the wpa3  spread around.
> See 
> https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v3.0.pdf
>  
> <https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v3.0.pdf>
>    Chapter 5.

> Merging multiple answers I was able to fix  the problem and keep PEAP 
> authentication on Android 11. I had to :
>
>  1. change the radius server certificate, modifying the freeradius server 
> certificate generation to add the new wpa3 extension and the server SAN
>  2.    use the new geteduroam app to install the eduroam configuration, 
> manual configuration is quite complex and unstable

To the best of my knowledge, there are at least two effecst intermingled in 
this discussion threa.
1. No "Do not validate" setting anymore in many devices.
   IMO, the "Do not validate" setting has proven THE most dangerous thing in 
eduroam.
   Setting up a Rogue AP and collection credentials from dozens or hundreds of 
Android (mostly <11) users
   is still technically trivial, although strictly illegal in most cases.
   (We had a legal case last year, the results were sobering, 25% of 800 
clients gave away MS-CHAPv2 credentials).
   I do not miss it, but you may need to set up MDM, an onboarding network or 
local means of
   config transfer such aus USB-OTG, which may mean a lot of work.

2. The "Samsung Bug"
   This, in most current Samsung devices, stubbornly copies the outer ID 
to the inner ID in the client when using PEAP/MS-CHAPv2.
   This will simply have no effect if both IDs are the same. In most Samsung devices, 
having "anonymous" in the
   username part of the outer ID, the error does not occur. Configuring some 
other value WILL trigger the bug
   in most Samsung devices (with the notable exception of the Galaxy S21).
   
The fbk.eu eduroam profile does not set an Outer ID, so both IDs will always be the same.
The unibas.ch profile uses anonymous AT unibas.ch.
The FBK profile will not encounter the Samsung bug.
The unibas.ch profile will work around the Samsung bug.

Configuring _some_ anonymous ID and _requiring_ it on the server side has 
proven to
be a quite effectiv measure against Rogue APs as they prevent naive 
configurations.
(in our investigation, 0% of clients configured with the correct outer ID 
gave away
any credentials).

Will the policy change in WPA3 kill the RogueAP problem?
I doubt it. It will certainly reduce the problem to some degree, but Samsung
does not seem to adhere, and old mobiles are going to stay around for a very
long time.

For now, you _may_ follow JISC's advisory and push your Samsung users to 
EAP-TTLS/PAP if possible.
You _may_ set up a different user group with a profile that only has 
EAP-TTLS/PAP. GWDG has done so,
for example. We currently configure Samsung devices in a half-manual way: 
First run geteduroam,
then exchange PEAP for TTLS (Phase 2 is set to PAP automatically).

Just my 2ct
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