Complex eduroam radius design

[Olivier Beytrison]

On 13.11.2012 19:08, Arran Cudbard-Bell wrote:
> 
> On 13 Nov 2012, at 17:23, Olivier Beytrison <olivier at heliosnet.org> wrote:
> 
>> On 13.11.2012 18:03, Phil Mayers wrote:
>>> On 13/11/12 16:38, Olivier Beytrison wrote:
>>>>
>>>> Well not really a solution here. The central LDAP system is one of the
>>>
>>> Fair enough.
>>>
>>>> To summarize, if I proxy the outer tunnel, there will be more load on
>>>> the central server, and I'll add the custom attributes to the outer
>>>> reply in order for the local radius to analyse them and add the
>>>> nas-specific attribute.
>>>
>>> Yes.
>>>
>>>>
>>>> if I proxy the inner tunnel, the TLS is handled by the local radius
>>>> (more CERT to buy), on the central server I add the attributes in the
>>>> normal reply, and the local radius keep doing the authorization part.
>>>> I just have to take care of the encryption between the local and central
>>>> servers. thankfully l2l vpn are already established.
>>>
>>> Yes. However, buying separate certs might not be a good idea as it will
>>> complicate the client setup - they'll all have to come from the same CA
>>> and share the same CN (or you'll have to rely on wildcard CN matching on
>>> the clients).
>>>
>>> For this reason, it might be easier to do all the TLS on the central
>>> servers, and have the same cert on both of them.
>>
>> Another good point indeed. Well this will make the local radius setup
>> fairly easy. Proxy everything to the central one, and just do
>> post-auth/post-proxy section, and manage the accounting.
>>
>> This will also make things easier when people outside our local realm
>> logs in on eduroam, the outer tunnel is proxied to the central radius,
>> which in turn proxies it to the NRO radius ...
> 
> 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'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 ;)

> 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.

> 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 ?

> 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.

> 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 :)

Again in my case I think that going with the topology I described in my
first mail is my best solution in my particular situation. Even if it's
not the most optimal :)

Thanks for your feedback!

Regards,
Olivier B.

> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 
> 

-- 

 Olivier Beytrison
 Network & Security Engineer, HES-SO Fribourg
 Mail: olivier at heliosnet.org