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.