Status of dynamic discovery support?

[Alan DeKok]

On May 11, 2016, at 2:46 AM, Stefan Winter <stefan.winter at 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.