FreeRADIUS, radsec and dnssec

[Brian Julin]

Alan Dekok wrote:
> On Apr 7, 2017, at 9:53 AM, Brian Julin <BJulin at clarku.edu> wrote:
>> 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?

I meant for the purpose of DNS database changes.

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

Yeah that's why I asked.

>  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.

There's the TLS SNI extension, though.  Which I guess is not entirely
suited to NAI, per https://www.ietf.org/mail-archive/web/radext/current/msg08207.html
I don't know enough of TLS and TLS renegotiation to assess that avenue.

> > 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.

As you note, there are security related benefits to this... but on the flip side, that could result in a rather large number of connections in some situations, no?

>  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.

Hmm... if IDP A decides they are fed up with the crummy service offered by relay B and
changes DNS records directing their road warriors from relay B to relay C, I think they'd
prefer to not have relay B linger around until relay B gets around to updating their cert.

Not that x509 infrastructure can't be made automated to be fast, but DNS offers more
direct top-down control to the IDP with less potential for foot dragging -- it's pretty reliably
in working order given the consequences when it isn't.