Status of dynamic discovery support?
Hello, I recall that a while back there was a student project that implemented dynamic discovery for FreeRADIUS. Did this feature ever make it into mainstream code? Is anybody working on getting this done? Greetings, 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
On May 11, 2016, at 2:46 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
I recall that a while back there was a student project that implemented dynamic discovery for FreeRADIUS. Did this feature ever make it into mainstream code? Is anybody working on getting this done?
There have been a lot of people announcing projects based on FreeRADIUS. Sadly, few have made their code public. In this case, dynamic discovery is about 99% there in v3.1. We've put changes in to support Moonshot, which use dynamic discovery. See the moonshot files in rlm_realm. The next step is to expose the existing code in a simple way. As always, patches are welcome. :) This question reminds me of a discussion I had with Sam at one point about privacy && security issues associated with dynamic discovery. A quick check of RFC 7585 shows that these issues don't seem to be addressed there. Maybe the situation applies more to moonshot, but it's worth a discussion. The problem is that dynamic realms can return pretty much anything. For moonshot, this means not only {hostname; port; protocol; order/preference; Effective TTL} as per RFC 7585 Section 3.4.2, but also certificates. This leads to a possible DoS attack, where a malicious realm returns someone *else's* hostname; port; protocol;, and *intentionally* the wrong certificate. If the list of home servers is global, then a malicious user / realm can cause a proxy to use the wrong certificate for a widely used realm. All proxying to that realm will fail, because the proxy expects the wrong certificate to be used. The solution (and is implemented in FR / moonshot), is that for dynamic realms, the list of home servers is realm-specific. So if "example.com" returns { 192.0.2.13; 1813; RadSec + wrong cert}, then only the users of example.com will be affected. If "example.org" returns { 192.0.2.13; 1813; RadSec + correct cert}, then the users of "example.org" will be able to authenticate. Alan DeKok.
Hi,
There have been a lot of people announcing projects based on FreeRADIUS. Sadly, few have made their code public.
The particular code I had in mind is public, https://github.com/skids/freeradius-server/tree/ddds I recall the author asking many good questions which made RFC7585 better than it was before.
In this case, dynamic discovery is about 99% there in v3.1. We've put changes in to support Moonshot, which use dynamic discovery. See the moonshot files in rlm_realm.
The next step is to expose the existing code in a simple way. As always, patches are welcome. :)
This question reminds me of a discussion I had with Sam at one point about privacy && security issues associated with dynamic discovery. A quick check of RFC 7585 shows that these issues don't seem to be addressed there. Maybe the situation applies more to moonshot, but it's worth a discussion.
The problem is that dynamic realms can return pretty much anything. For moonshot, this means not only {hostname; port; protocol; order/preference; Effective TTL} as per RFC 7585 Section 3.4.2, but also certificates. This leads to a possible DoS attack, where a malicious realm returns someone *else's* hostname; port; protocol;, and *intentionally* the wrong certificate.
Well, RFC7585 doesn't discuss the topic because that mode of discovery is not part of the spec. :-) The spec makes clear that DNS can by default not be trusted, and querying RADIUS/TLS destinations from it may result in connecting to a server with an unacceptable certificate. The CAs to trust does NOT come from the same untrusted DNS infrastructure for a very good reason. CA trust configuration is out-of-band. Call it old-fashioned if you like, I call it "classic and proven" :-)
If the list of home servers is global, then a malicious user / realm can cause a proxy to use the wrong certificate for a widely used realm. All proxying to that realm will fail, because the proxy expects the wrong certificate to be used.
The solution (and is implemented in FR / moonshot), is that for dynamic realms, the list of home servers is realm-specific. So if "example.com" returns { 192.0.2.13; 1813; RadSec + wrong cert}, then only the users of example.com will be affected. If "example.org" returns { 192.0.2.13; 1813; RadSec + correct cert}, then the users of "example.org" will be able to authenticate.
I don't see how the home servers could *not* be realm-specific? RFC7585 result sets query a specific realm name, and get a set of endpoints *for that realm*. 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
On Jun 6, 2016, at 2:55 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
There have been a lot of people announcing projects based on FreeRADIUS. Sadly, few have made their code public.
The particular code I had in mind is public, https://github.com/skids/freeradius-server/tree/ddds
OK. I'll take a look.
The spec makes clear that DNS can by default not be trusted, and querying RADIUS/TLS destinations from it may result in connecting to a server with an unacceptable certificate. The CAs to trust does NOT come from the same untrusted DNS infrastructure for a very good reason.
CA trust configuration is out-of-band. Call it old-fashioned if you like, I call it "classic and proven" :-)
It's not about the CA. It's about the identity of the host vs the identity available in DNS.
I don't see how the home servers could *not* be realm-specific? RFC7585 result sets query a specific realm name, and get a set of endpoints *for that realm*.
That's good. But it's a *positive* correlation. You also need *negative* correlation. i.e. looking up information for realm A gets you the IP / certificate for a particular RADIUS server. Looking up information for realm B does *not* get you that information, even if that IP was somehow associated with realm B. Historically, many RADIUS servers implemented home servers via a global list. For DDNS, the home servers *must* be tied to a realm, and *must not* be globally visible. Alan DeKok.
participants (2)
-
Alan DeKok -
Stefan Winter