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

[IAM David Bantz <db AT alaska.edu>]

Yes our network, security and user services groups have heard me describe downsides of simple native supplicant provided domain-qualified username and password:

both the MiM security risk, and the privacy concern of full username in outer identity. They acknowledge greater security and privacy of CAT-configured supplicants, but those are viewed as trade-offs with ease of use.

Our current production eduroam deployment relies on different RADIUS servers (freeRADIUS vs Cisco ISE) and different user authN (TLS with in-house user certificate provisioning vs PEAP) than the new deployment currently broadcasting eduroam-test. I can't see how CAT installers for existing deployment would in any way test installers for a new deployment on different hardware using different user authN; and of course we can't broadcast both as eduroam. Thus our initial deployment and shake-down on a temporary eduroam-test SSID.  I'm happy to be enlightened because as it stands, we're looking at disruption of service to all our existing eduroam supplicants when we do cut over to new servers and authN for eduroam.

David Bantz

U Alaska

On Tue, Oct 16, 2018 at 2:35 AM Stefan Winter <stefan.winter AT restena.lu> wrote:

...there is no need for a test SSID.... you don't need a test /network/. You

just need to test /devices/ on the existing network...

...have you talked to your network and user support groups about
the very real-life risk of credential theft when not verifying that the
username and password are sent to the actual, authorised authentication
server?