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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

> Arguably we're changing more than two things at once, alas. However the
> WiFi / authN backend is independently tested independent of
> device-specific installers; (1) the CAT tools simulating login from
> remote sites were enormously helpful in verifying and tuning set-up for
> receiving and processing eduroam requests from the eduroam federation
> (using a secondary domain we also control so as not to disrupt
> production); (2) simple manual configuration of supplicants verify
> on-site connections.

Ah, I'm happy to hear that the toolset is already of use.

>     I'd suggest to first test CAT on the production SSID. If that works, you
>     can be rather confident that the only changes you'll have to do CAT-side
>     are the adaptation to the new server certificate and server name; after
>     all these are the only two properties of your auth backend which are
>     visible to the outside world, and thus the only thing CAT cares about.
> 
> 
> I don't think that's true; as user authentication is changing from
> EAP-TLS to EAP-PEAP,

Ah. That's indeed a big change. I might have taken my mouth too full
when I wrote our installers can handle two simulateneously :-)

You could however do something on the server-side maybe. See at the end
of the mail.

> there's a fundamental difference in the
> configurations for current and new 802.1X configuration. Unless I am
> badly mistaken, the CAT installers have in themselves no way to fully
> configure our existing eduroam requiring on-demand creation and
> insertion of a user certificate from our current unsupported certificate
> factory. But even supposing such near-magic, installers that create and
> install user certificates consumed by freeRADIUS hardly provide
> confidence in a different set of installers for password authentication
> brokered by Cisco ISE.

FWIW, creating and handing out individual user certificates on demand is
a feature of our new product "eduroam Managed IdP". That one is using
our own CA though, and it is meant to be used by small institutions
without professional on-site user identity management systems. It ,
somewhat intentionally, does not scale to large deployments.

> Such an installer would have to generate a user certificate on the fly
> for the current production on-site eduroam configuration for use with
> EAP-TLS as well as supporting EAP-PEAP for new infrastructure. Perhaps
> all that can be crammed into one installer, but then what's the flow? -
> how does the wireless controller determine which RADIUS server to query?
> if determined by the supplicant, what triggers one or the other request?
> And once a RADIUS server is selected, how does the supplicant know
> whether to use TLS or PEAP for the inner identity? 

Since your old setup is a FreeRADIUS: it can proxy requests :-) So, if a
PEAP user from the new deployment variant authenticates at your current
production SSID (leading to the EAP-TLS server), FreeRADIUS can be
configured with a rule of sorts

"if user is from @newdeploymentrealm && EAP-Type == PEAP => proxy to the
new server"

Even if the realm of old and new deployment is identical - with the EAP
type being part of the condition, you make sure that genuinely old
accounts with EAP-TLS are authenticated on the old server, while new
accounts are sent onwards to your new server. All when incoming from the
same legacy deployment.

The only complication with this is when the old and new realms are
indeed identical - it can still work, but then EAP type negotiation
happens on the old server, and you will have to enable "support" for
PEAP in the first place to allow the client to actually select the EAP type.

You're basically implementing roaming with that, just not necessarily
based on realm but on EAP-Type.

That way, CAT installers for the new PEAP deployment can be used on both
the old and the new deployment; the installers themselves only contain
the new EAP details because the final RADIUS server that authenticates
users is always the new one.

It all depends on whether you're confident enough to change the
FreeRADIUS configuration in this way. It would be a ...fairly advanced
... configuration task.

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

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature