Status of dynamic discovery support?

[Stefan Winter]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20160606/4340208c/attachment.sig>