Complex eduroam radius design

[Arran Cudbard-Bell]

>> 
>> All that *will* be going away eventually, you'll just use RADSec and DNS discovery.
> 
> This will indeed happen eventually, but at this time ... it's not yet
> possible
> 
>> Honestly I don't really see the point of the central server here, other than to interface with the existing eduroam infrastructure, and even then it's mostly lazyness :). If I were implementing this I would terminate the EAP sessions on the local servers, and query LDAP directly from the different sites.
> 
> Could be an idea, but being also in charge of the security, the fact
> that we need an ldap account with the permission to retrieve the
> cleartext password from the eDirectory central password is a big
> concern. I don't want to have such an account configured on the local
> radius servers, allowing too many people to see the cleartext password
> from the 25k users. (Those accounts are not just eduroam accounts, it's
> their global account for ActiveDirectory, Mails, vpn access and so on)

I figured you be running the site servers so the risk of exposure wouldn't really be increased, but if you're actually going to be allowing local admin users root access then yes, that'd be an issue.

>> I'd do this for the following reasons:
>> a) The crypto is spread across multiple hosts, meaning you don't load central servers and the system as a whole scales better.
> 
> Agreed. Fortunately virtual machine are easy to create ;)

Uh, right. I guess if your physical hosts have plenty of cores to spare.

> 
>> b) The likelyhood of packet loss (and EAP authentications timing out) is greatly reduced. Packet loss is a big problem with EAP over RADIUS, if the path between your central RADIUS servers and your site specific ones is in any way unreliable it's not going to work well.
> 
> Also agreed. All the schools are interconnected by Switch, the Swiss
> educational network provider, with lot of 10gig links everywhere. So
> connectivity is not really a concern here I think.

Ah that should be fine. Just if you were planning to use crappy bonded DSL lines.

> 
>> c) LDAP is TCP based and can recover from packet loss far quicker than RADIUS where the normal retransmission interval is ~5 seconds (granted this is configurable, but it's usually not sub second).
> 
> Radsec can run over TCP. Another good reason to go for Freeradius3 and
> use radsec. Btw if I want to test FR3, I guess that it's available on
> git. But I didn't find where and how to get it. any hint ?

Checkout the master branch from github, or:

https://github.com/FreeRADIUS/freeradius-server/archive/master.zip

will always contain the latest bleeding edge version of the src.

> 
>> d) It's possible to build up caches of passwords locally on each site RADIUS server (see rlm_cache) and then failover to that in the event of the central LDAP servers being unavailable, this gives you far greater resilliency. You can't do that if you never see the NT-Password or Cleartext-Password at a site level. 
> 
> Good point. But there will be 2 or 3 central radius servers (maybe with
> the f5 in front for loadbalancing). And the authentication ldap servers
> consist of a pool of 4 active/active ldap servers with the f5
> load-balancer in front. so in term of resiliency it should be ok.

Ok, just make sure you balance on a suitable hash, probably just SRC IP and DST IP in this case. You cannot use randomised load balancing with EAP because the packets that make up the EAP session could end up on different servers, and there's currently no way to synchronise EAP session state between cluster members.

>> As Phil says, you only need one cert. There's absolutely no way that the supplicant can tell which server is presenting the certificate, so the CN validation checks will not fail unless the user has configured a set CN string in their supplicant.
> 
> Thanks for the information, this mean I don't even need a cert per
> central server, I just need, let's say, one cert for
> "eduroam.hes-so.ch". good to know :)

Yep :)

-Arran