Status of dynamic discovery support?
Alan DeKok
aland at deployingradius.com
Mon Jun 6 13:14:50 CEST 2016
On Jun 6, 2016, at 2:55 AM, Stefan Winter <stefan.winter at 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.
More information about the Freeradius-Devel
mailing list