[POSH] Another use case that suffers: RADIUS dynamic peer discovery

[Stefan Winter <[e-mail]>]

Hi,

sitting in the POSH BoF, I would have had one other use case which
suffers the same problems - but having had so many at the mike, I guess
sending an email to the list is enough.

This is about RADIUS and an almost-finished draft about "Dynamic Server
Discovery". The short story is that a RADIUS client gets an email-style
username from an end-user, uses DNS (NAPTR -> SRV/A/AAAA) to find a
server and then tries to figure out: is that server authoritative for
the _domain_ I got as input.
The discovery process doesn't particularly care about the hostname, just
like in the other use cases. And just like in those, you may operate a
RADIUS proxy which deals with multiple domains, none of which are
cert-wise under its control.

Our problem is a little tougher to crack than those presented IMHO, because:

- DNSSEC+DANE doesn't do the job entirely: RADIUS/TLS connections are
always mutually authenticated, meaning there's a client cert validation
happening - which DANE doesn't specify how to do. We could restrict to
using DNSSEC+DANE for server authz+authn, and declare the client part
out of scope though.

- In the absence of DNSSEC, X.509 service names don't do the job either,
because the discovery starts with NAPTR, and it may or may not traverse
an SRV in the middle; and even if it does, the input to SRV lookup is
untrusted (someone might have manipulated the preceding NAPTR already).

Our solution (or what I currently think is the solution) is to have a
new cert property that encodes the _domain name_ just for the specific
AAA use case. We call our domains "NAI realms", so what I was trying to
get from PKIX folks is a subjectAltName:nAIRealm property. This would
contain the realm and only delegate trust for the NAI realm of a domain
to the cert holder, not of the entire domain per se. I understand from
the SIP presentation that this will hit the ground hard if you expect
actual commercial CAs to issue certs with such a name, but that's less
an issue… RADIUS is typically run for (closed-group) roaming consortia
which can agree on their own CAs. And the certs are validated in a
machine-to-machine manner from RADIUS clients to RADIUS servers, not by
end-users.

I don't have the name from PKIX yet, still being discussed. If POSH had
a less intrusive way of solving this, do go ahead :-) I'll read the draft.

Greetings,

Stefan Winter