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