FreeRADIUS, radsec and dnssec

[Alan DeKok]

On Apr 7, 2017, at 9:53 AM, Brian Julin <BJulin at clarku.edu> wrote:
> This is something I'm a bit unclear on:

https://tools.ietf.org/html/rfc7585

  Stefan wrote a document for this. :)

> How do we deal with a situation where a large number of administratively
> distinct realms decide to pool resources and send all requests to the same
> server?

  Then they're not administratively distinct, are they?

  That could also be an attack vector if the process is implemented insecurely.

>  Does every change to the membership list of that group require a
> new certificate to be generated to change the alternative subject names?

  That would be the way SSL certificates work.

  But only the server certificate has to change, which is easy to do.

> What does a relay do when it gets a request that DNS says should go up
> an established RADSEC pipe, but that RADSEC pipe does not have a
> x509 alt subject corresponding to that realm... tear down the RADSEC pipe and
> renegotiate it to look for a fresher cert, or is  there an in-band mechanism
> for things such as this tucked away in TLS (a spec which I have very limited
> familiarity with)?

  The request gets a new radsec pipe, which is treated as a new connection, and a new destination server.  That server happens to have the same IP and certificate as an existing one, burt that's OK.

  The lookups are realm -> server identity -> IP address, and *not* the other way around.  The server identity and IP address are tracked per realm, and are *not* put into a global table of keyed by IP address.

  You can extend the idea to say that if realm A connects to server X, and the server presents "subject alt names" for realms B, C, and D, it's probably worth adding those realms to the global realm routing table.

  See also https://tools.ietf.org/html/rfc7542#section-3, which talks explicitly about a routing table based on realms.

  There's also the issue where a malicious actor can log in, request a connection (via DNS realm A) to a server B which isn't configured to know about realm A.  If the servers are tracked by IP, that server could be marked "bad".

  Instead, tracking it by realm means that the attack only affects users at realm A.  i.e. the lookup is "realm A -> nope, that server doesn't work", and not "realm B -> server B", followed by "OMG server B is 'wrong'"

  Hmm... I thought that there was some discussion of these issues in the RFC.  Apparently not.

  Alan DeKok.