Hello, We're planning to deploy eduroam centrally for all the university of applied science of west-switzerland. (consists of ~27 schools and 25'000 people). On one side, we will have the central radius servers, connected to the central ldap backend which contains all the user account. On the other side, we will have local radius servers (about 7 pairs of servers, because the schools are grouped regionally and under a central management). The idea is the following : User join the WLAN (802.1x, eduroam). the WiFi controller (nas) contact the local radius for authentication, which in turn contact the central radius to authenticate the user. upon successful authentication, the central radius return the Access-Accept along with some custom attribute about the user. The local radius then perform admission control based on those attributes. (selecting the correct vlan, subnet, ect) So I have two questions : 1. is this implementation possible ? 2. If it is possible, will the inner-tunnel for eap-peap and eap-ttls end on the local or central radius, taking in account that the authentication is performed by the central radius. (I'll go for the central one) Thanks in advance for your answers. Best regards, Olivier B. -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
Hello,
We're planning to deploy eduroam centrally for all the university of applied science of west-switzerland. (consists of ~27 schools and 25'000 people).
On one side, we will have the central radius servers, connected to the central ldap backend which contains all the user account.
On the other side, we will have local radius servers (about 7 pairs of servers, because the schools are grouped regionally and under a central management).
The idea is the following : User join the WLAN (802.1x, eduroam). the WiFi controller (nas) contact the local radius for authentication, which in turn contact the central radius to authenticate the user. upon successful authentication, the central radius return the Access-Accept along with some custom attribute about the user. The local radius then perform admission control based on those attributes. (selecting the correct vlan, subnet, ect)
So I have two questions : 1. is this implementation possible ?
Yes.
2. If it is possible, will the inner-tunnel for eap-peap and eap-ttls end on the local or central radius, taking in account that the authentication is performed by the central radius. (I'll go for the central one)
EAP tunnel will end on the end system. Attributes from inside the tunnel can be copied to the outside RADIUS protocol. This attributes can be seen from the NAS. So they can react as configured. Greetings, -- Dr. Michael Schwartzkopff Guardinistr. 63 81375 München Tel: (0163) 172 50 98 Fax: (089) 620 304 13
On 13/11/12 14:45, Olivier Beytrison wrote:
Hello,
We're planning to deploy eduroam centrally for all the university of applied science of west-switzerland. (consists of ~27 schools and 25'000 people).
On one side, we will have the central radius servers, connected to the central ldap backend which contains all the user account.
On the other side, we will have local radius servers (about 7 pairs of servers, because the schools are grouped regionally and under a central management).
The idea is the following : User join the WLAN (802.1x, eduroam). the WiFi controller (nas) contact the local radius for authentication, which in turn contact the central radius to authenticate the user. upon successful authentication, the central radius return the Access-Accept along with some custom attribute about the user. The local radius then perform admission control based on those attributes. (selecting the correct vlan, subnet, ect)
So I have two questions : 1. is this implementation possible ?
Yes. But I would argue it's not ideal (see below).
2. If it is possible, will the inner-tunnel for eap-peap and eap-ttls end on the local or central radius, taking in account that the authentication is performed by the central radius.
It depends what you configure. You can proxy the inner tunnel, or the outer tunnel. If you proxy the outer tunnel, it's encrypted all the way, but the central servers have to do all the TLS. The local servers then do very little (what you refer to as "vlans, subnets, etc.") If you proxy the inner tunnel, the local servers do the TLS, but the traffic to the central servers is only lightly encrypted (by the RADIUS encryption scheme). Whether this matters will depend on your environment. Personally, I would think carefully if this model is right. The local servers don't seem to add much value, and are entirely dependent on the central servers. Have you considered replicating the LDAP database to the local servers?
On 13.11.2012 16:20, Phil Mayers wrote:
On 13/11/12 14:45, Olivier Beytrison wrote:
Hello,
[snip]
So I have two questions : 1. is this implementation possible ?
Yes. But I would argue it's not ideal (see below).
2. If it is possible, will the inner-tunnel for eap-peap and eap-ttls end on the local or central radius, taking in account that the authentication is performed by the central radius.
It depends what you configure. You can proxy the inner tunnel, or the outer tunnel.
If you proxy the outer tunnel, it's encrypted all the way, but the central servers have to do all the TLS. The local servers then do very little (what you refer to as "vlans, subnets, etc.")
Well, that's what I would like to do. We have 7 different IT services running their own network the way they want. The local radius are there to let them freely manage how users access their network.
If you proxy the inner tunnel, the local servers do the TLS, but the traffic to the central servers is only lightly encrypted (by the RADIUS encryption scheme). Whether this matters will depend on your environment.
Not really a matter, as it will rull either over a lan-to-lan ipsec vpn, or with radsec enabled. (still thinking between using radsecproxy or going with freeradius 3 [I know, you need guinea pig ;)])
Personally, I would think carefully if this model is right. The local servers don't seem to add much value, and are entirely dependent on the central servers.
It's not really about value, it's more about letting the local IT services manage how and what the users can access. We're already enforcing this central authentication, if we don't let them a minimum of control, this will lead to an IT Riot :p
Have you considered replicating the LDAP database to the local servers?
Well not really a solution here. The central LDAP system is one of the most complex Novell eDirectory deployment possible. Syncing 7 other ldap servers would just put more load on the actual cluster. The authentication will be made against a dedicated cluster of ldap server which contains only authentication-related informations. 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. 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. Thanks a lot for your answer, gives me a good idea on how I'll do it. Olivier B.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
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.
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 ...
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
On 13 Nov 2012, at 17:23, Olivier Beytrison <olivier@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. 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. 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. 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. 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). 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. 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. -Arran
On 13.11.2012 19:08, Arran Cudbard-Bell wrote:
On 13 Nov 2012, at 17:23, Olivier Beytrison <olivier@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@heliosnet.org
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
Phil Mayers wrote:
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).
Has that actually been tested to work across the gallery of clients? It is my impression that a lot of clients (e.g. IOS) will just barf on any certificate that isn't the first one it encountered on an SSID, unless and until the user gets frustrated and reconfigures. Not that I think running multiple certs offers any real benefit. Perhaps for transitional purposes when expiry dates come up. (Note: this behavior, while not completely secure, is probably as secure as one could expect on a ...ehem... "BYOD" network with a nonconforming user base, and is certainly superior to Android which will trust anything you hand it.) (Oh, also, if anyone wants to play with clients in a test environment by sending them strange certificates at inopportune times, I left some code on github at skids/freeradius-server/tree/clientverify. It is too ugly to propose as a serious patch, though.)
On 11/14/2012 06:54 PM, Brian Julin wrote:
Phil Mayers wrote:
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).
Has that actually been tested to work across the gallery of clients? It is
No. Hence my suggestion that it "might not be a good idea" ;o)
my impression that a lot of clients (e.g. IOS) will just barf on any certificate that isn't the first one it encountered on an SSID, unless and until the user gets frustrated and reconfigures.
Not that I think running multiple certs offers any real benefit. Perhaps for transitional purposes when expiry dates come up.
About the only real use-case I can think of for multiple certs is a desire to use a hardware crypto module for "security" i.e. prevent key exposure.
participants (5)
-
Arran Cudbard-Bell -
Brian Julin -
Michael Schwartzkopff -
Olivier Beytrison -
Phil Mayers