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