FreeRADIUS, radsec and dnssec
Hi, werecently had a discussion about FreeRADIUS and radsec. The DFN which ist the central hub for the German eduroam wants the universities to migrate to radsec. But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy. They did not tell me yet what the issues were, but as far as I understood they wanted to have a dynamic home server resolution based on realms in eduroam. Basically that seems to be a good idea but the problem is, how to estalish mutual trust with dynamic home servers. Here DNSSEC and especially the TLSA RR comes into play. Is it possible to add trust to FreeRADIUS 3 based on a TLSA RR verified by DNSSEC so my RADIUS server can trust the remote RADIUS server based on the comparison of its server certificate and the according TLSA RR in DNS of the home organisation? I know establishing this kind of mutiual trust work good for e-mail systems. The system is called DANE. See RFC 7671 for detailed information about DANE. Basically this the short version of this mail would be: Can the FreeRADIUS project add DANE authentication and verification of home servers to its features? Mit freundlichen Grüßen, Michael Schwartzkopff -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
On Apr 6, 2017, at 9:07 AM, Michael Schwartzkopff <ms@sys4.de> wrote:
But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy.
TBH, radsecproxy is a bit easier, because it's a dedicated proxy. And it doesn't have configuration for non-proxy functionality, because that doesn't exist.
Basically that seems to be a good idea but the problem is, how to estalish mutual trust with dynamic home servers.
Here DNSSEC and especially the TLSA RR comes into play.
Is it possible to add trust to FreeRADIUS 3 based on a TLSA RR verified by DNSSEC so my RADIUS server can trust the remote RADIUS server based on the comparison of its server certificate and the according TLSA RR in DNS of the home organization?
As always, it's just code. :) The difficulty here is that v3 isn't really set up to do that. The networking code has grown over time, and is pretty fixed in what it can do. Making changes is hard. I've recently been making good progress in v4. The goal there is to pull the transports (UDP, TCP, TLS, etc.) and protocols (RADIUS) out of the server core, and into plugins. Once that's done, adding a new transport should be pretty simple. Just write transport-specific code, and hand it off to the rest of the server for RADIUS processing.
I know establishing this kind of mutiual trust work good for e-mail systems. The system is called DANE. See RFC 7671 for detailed information about DANE.
Basically this the short version of this mail would be: Can the FreeRADIUS project add DANE authentication and verification of home servers to its features?
Yes, but it won't be quick. I'd suggest writing up some notes on the Wiki: http://wiki.freeradius.org/version4/ Make it as detailed as possible, so that implementation becomes straightforward. Alan DeKok.
I did some preliminary work along this line a couple years back (rlm_unbound, rlm_idn, and in an unmerged and probably stale branch on github is the start of the query side of DDDS support.) That took care of finding verified IP addresses for home servers based on a realm name. Also it could be used for simpler purposes in a degenerate mode, like RRDNS for load balancing. But what I implemented was just the part where you find IP addresses, not make them into home servers. Dynamic home servers was the missing ingredient at that time. I have seen indications from the core team that they are working to address this. The further challenge after that is session-aware load balancing correctly through a DNS change, and of course closing the security loop by validating the realm against server certificates. It's a pretty big project when you do more than just simple proxying. I would not expect it to materialize quickly, but people know the need is out there. ________________________________________ From: Freeradius-Users <freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org> on behalf of Michael Schwartzkopff <ms@sys4.de> Sent: Thursday, April 6, 2017 9:07 AM To: FreeRadius users mailing list Subject: FreeRADIUS, radsec and dnssec Hi, werecently had a discussion about FreeRADIUS and radsec. The DFN which ist the central hub for the German eduroam wants the universities to migrate to radsec. But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy. They did not tell me yet what the issues were, but as far as I understood they wanted to have a dynamic home server resolution based on realms in eduroam. Basically that seems to be a good idea but the problem is, how to estalish mutual trust with dynamic home servers. Here DNSSEC and especially the TLSA RR comes into play. Is it possible to add trust to FreeRADIUS 3 based on a TLSA RR verified by DNSSEC so my RADIUS server can trust the remote RADIUS server based on the comparison of its server certificate and the according TLSA RR in DNS of the home organisation? I know establishing this kind of mutiual trust work good for e-mail systems. The system is called DANE. See RFC 7671 for detailed information about DANE. Basically this the short version of this mail would be: Can the FreeRADIUS project add DANE authentication and verification of home servers to its features? Mit freundlichen Grüßen, Michael Schwartzkopff -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
On Apr 6, 2017, at 10:53 AM, Brian Julin <BJulin@clarku.edu> wrote:
Dynamic home servers was the missing ingredient at that time. I have seen indications from the core team that they are working to address this.
It's sort of in v3, for the trust router work. But not in a way that can be sustained moving forward.
The further challenge after that is session-aware load balancing correctly through a DNS change, and of course closing the security loop by validating the realm against server certificates.
It's a pretty big project when you do more than just simple proxying. I would not expect it to materialize quickly, but people know the need is out there.
In v4, all of the proxying is being moved to modules. It means that proxy.conf becomes harder to configure. BUT things like "proxy to 4 destinations" becomes trivial. And, adding dynamic DNS to radsec home servers is just a plugin module. i.e. someone could start on it today. Alan DeKok.
On Apr 6, 2017, at 3:28 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 6, 2017, at 10:53 AM, Brian Julin <BJulin@clarku.edu> wrote:
Dynamic home servers was the missing ingredient at that time. I have seen indications from the core team that they are working to address this.
It's sort of in v3, for the trust router work. But not in a way that can be sustained moving forward.
The further challenge after that is session-aware load balancing correctly through a DNS change, and of course closing the security loop by validating the realm against server certificates.
It's a pretty big project when you do more than just simple proxying. I would not expect it to materialize quickly, but people know the need is out there.
In v4, all of the proxying is being moved to modules. It means that proxy.conf becomes harder to configure. BUT things like "proxy to 4 destinations" becomes trivial.
And, adding dynamic DNS to radsec home servers is just a plugin module. i.e. someone could start on it today.
It's already there pretty much. Just need to add some extra xlats for the different record types. -Arran
Hello Michael,
werecently had a discussion about FreeRADIUS and radsec. The DFN which ist the central hub for the German eduroam wants the universities to migrate to radsec.
But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy.
They did not tell me yet what the issues were, but as far as I understood they wanted to have a dynamic home server resolution based on realms in eduroam.
Basically that seems to be a good idea but the problem is, how to estalish mutual trust with dynamic home servers.
Here DNSSEC and especially the TLSA RR comes into play.
In general, it's a good idea to consider DNSSEC for trust relationships. For E-Mail, this is crucial because one does not know which certificate and CA the other end uses; the trust bootstrap must come from somewhere else. In eduroam however, the RADIUS/TLS trust is pre-existing because all RADIUS servers receive server certificates from the same, one, pre-determined, CA. Additional DNSSEC / TLSA / DANE is then not necessary: if DNS was lieing to you, then you'll end up at a host which can't present a trusted certificate, and then the conversation ends before any payload is exchanged. Greetings, Stefan Winter
Is it possible to add trust to FreeRADIUS 3 based on a TLSA RR verified by DNSSEC so my RADIUS server can trust the remote RADIUS server based on the comparison of its server certificate and the according TLSA RR in DNS of the home organisation?
I know establishing this kind of mutiual trust work good for e-mail systems. The system is called DANE. See RFC 7671 for detailed information about DANE.
Basically this the short version of this mail would be: Can the FreeRADIUS project add DANE authentication and verification of home servers to its features?
Mit freundlichen Grüßen,
Michael Schwartzkopff
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- 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
Stefan WINTER wrote:
In eduroam however, the RADIUS/TLS trust is pre-existing because all RADIUS servers receive server certificates from the same, one, pre-determined, CA.
This is something I'm a bit unclear on: How do we deal with a situation where a large number of administratively distinct realms decide to pool resources and send all requests to the same server? Does every change to the membership list of that group require a new certificate to be generated to change the alternative subject names? What does a relay do when it gets a request that DNS says should go up an established RADSEC pipe, but that RADSEC pipe does not have a x509 alt subject corresponding to that realm... tear down the RADSEC pipe and renegotiate it to look for a fresher cert, or is there an in-band mechanism for things such as this tucked away in TLS (a spec which I have very limited familiarity with)?
On Apr 7, 2017, at 9:53 AM, Brian Julin <BJulin@clarku.edu> wrote:
This is something I'm a bit unclear on:
https://tools.ietf.org/html/rfc7585 Stefan wrote a document for this. :)
How do we deal with a situation where a large number of administratively distinct realms decide to pool resources and send all requests to the same server?
Then they're not administratively distinct, are they? That could also be an attack vector if the process is implemented insecurely.
Does every change to the membership list of that group require a new certificate to be generated to change the alternative subject names?
That would be the way SSL certificates work. But only the server certificate has to change, which is easy to do.
What does a relay do when it gets a request that DNS says should go up an established RADSEC pipe, but that RADSEC pipe does not have a x509 alt subject corresponding to that realm... tear down the RADSEC pipe and renegotiate it to look for a fresher cert, or is there an in-band mechanism for things such as this tucked away in TLS (a spec which I have very limited familiarity with)?
The request gets a new radsec pipe, which is treated as a new connection, and a new destination server. That server happens to have the same IP and certificate as an existing one, burt that's OK. The lookups are realm -> server identity -> IP address, and *not* the other way around. The server identity and IP address are tracked per realm, and are *not* put into a global table of keyed by IP address. You can extend the idea to say that if realm A connects to server X, and the server presents "subject alt names" for realms B, C, and D, it's probably worth adding those realms to the global realm routing table. See also https://tools.ietf.org/html/rfc7542#section-3, which talks explicitly about a routing table based on realms. There's also the issue where a malicious actor can log in, request a connection (via DNS realm A) to a server B which isn't configured to know about realm A. If the servers are tracked by IP, that server could be marked "bad". Instead, tracking it by realm means that the attack only affects users at realm A. i.e. the lookup is "realm A -> nope, that server doesn't work", and not "realm B -> server B", followed by "OMG server B is 'wrong'" Hmm... I thought that there was some discussion of these issues in the RFC. Apparently not. Alan DeKok.
Alan Dekok wrote:
On Apr 7, 2017, at 9:53 AM, Brian Julin <BJulin@clarku.edu> wrote:
How do we deal with a situation where a large number of administratively distinct realms decide to pool resources and send all requests to the same server?
Then they're not administratively distinct, are they?
I meant for the purpose of DNS database changes.
That could also be an attack vector if the process is implemented insecurely.
Yeah that's why I asked.
Does every change to the membership list of that group require a new certificate to be generated to change the alternative subject names?
That would be the way SSL certificates work.
There's the TLS SNI extension, though. Which I guess is not entirely suited to NAI, per https://www.ietf.org/mail-archive/web/radext/current/msg08207.html I don't know enough of TLS and TLS renegotiation to assess that avenue.
What does a relay do when it gets a request that DNS says should go up an established RADSEC pipe, but that RADSEC pipe does not have a x509 alt subject corresponding to that realm... tear down the RADSEC pipe and renegotiate it to look for a fresher cert, or is there an in-band mechanism for things such as this tucked away in TLS (a spec which I have very limited familiarity with)?
The request gets a new radsec pipe, which is treated as a new connection, and a new destination server. That server happens to have the same IP and certificate as an existing one, burt that's OK. The lookups are realm -> server identity -> IP address, and *not* the other way around. The server identity and IP address are tracked per realm, and are *not* put into a global table of keyed by IP address.
As you note, there are security related benefits to this... but on the flip side, that could result in a rather large number of connections in some situations, no?
You can extend the idea to say that if realm A connects to server X, and the server presents "subject alt names" for realms B, C, and D, it's probably worth adding those realms to the global realm routing table.
Hmm... if IDP A decides they are fed up with the crummy service offered by relay B and changes DNS records directing their road warriors from relay B to relay C, I think they'd prefer to not have relay B linger around until relay B gets around to updating their cert. Not that x509 infrastructure can't be made automated to be fast, but DNS offers more direct top-down control to the IDP with less potential for foot dragging -- it's pretty reliably in working order given the consequences when it isn't.
Hi,
How do we deal with a situation where a large number of administratively distinct realms decide to pool resources and send all requests to the same server? Does every change to the membership list of that group require a new certificate to be generated to change the alternative subject names?
Yes. Unless the name is a wildcard name and the new name is already covered by the wildcard. Which (in eduroam at least) is probably common for *.tld proxy servers.
What does a relay do when it gets a request that DNS says should go up an established RADSEC pipe, but that RADSEC pipe does not have a x509 alt subject corresponding to that realm... tear down the RADSEC pipe and renegotiate it to look for a fresher cert, or is there an in-band mechanism for things such as this tucked away in TLS (a spec which I have very limited familiarity with)?
There's (secure) Server/Client-initiated TLS renegotiation (both ways are possible). That happens inband without tearing down the session. (and yes, there's also an INsecure variant of this which made the news a few years back. Don't use that one :-) ) 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
Hi again,
There's (secure) Server/Client-initiated TLS renegotiation (both ways are possible). That happens inband without tearing down the session.
Which, by way of practicalities, is probably not even needed. A change of cert typically means putting a new PEM file on the file system and *restarting the server* to pick up the new file. That tears down any sessions and re-establishes them with the new cert. Problem solved :-) But hey, if not, Secure TLS Renegotiation comes for your rescue anyway. Stefan -- 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
Hi, On 06.04.2017 15:07, Michael Schwartzkopff wrote:
But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy.
They did not tell me yet what the issues were, but as far as I understood they wanted to have a dynamic home server resolution based on realms in eduroam.
at least there seem to be interoperability issues between FR3 (3.0.12) and DFN's radsecproxy (1.6.8, I think). When trying to upgrade my old FR2 servers with FR3, I came cross this: - Proxy relationships are all configured old-style, i.e. with fixes shared secret and DNS CNAMEs (or even IP addresses) - When my traveling users want to use eduroam, all is fine with FR2 on my side. - When I replace it with my new FR3 VM (leaving outside view of CNAME/IP identical), my traveling users are unable to authenticate if and only if my FR3 server talking to DFN's radsecproxy is to terminate the request itself. If there is at least one Proxy step involved on my side, things are fine again. Debugging showed that for every client, the first Access-Request arrives and ist answered by Access-Challenge. The Access-Challenge is then discarded by the radsecproxy, for unknown reasons. Of course, this is not actual reason to recommend a radsecproxy at the boundary of every realm. But putting it in enables you to sort of kill two birds with one stone: You (and they) get the radsec benefits, and the weird issues described above are magically gone. For now, I simply put in the proxy step to get FR2 out of business. As soon as I have converted this to radsec, I will try and see if I can get some more information on that. Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Julin -
Martin Pauly -
Michael Schwartzkopff -
Stefan Winter