Re: [radext] #148: Review of dynamic-discovery by Jim Schaad

[Stefan Winter <[e-mail]>]

Hi,

> I strongly favor the first.  I agree that it means that you need to have
> a field in the cert that contains the realm's name.
> There are fairly obvious ways this can be done in a SAN.
> RFc 4985 is an example of how microsoft does this.
> My concern with the dnssec approach is that while it's easy to specify,
> 
> I'm concerned that dnssec APIs are not widely available enough at
> userspace levels outside the resolver that I'd have confidence
> radsecproxy or freeradius or other radsec implementations could actually
> implement dnssec validation in the radius proxy right now.

That's a reasonable concern to have, IMHO. I'd usually agree that the
use of a SAN is a safer bet right now. Unfortunately, we've burnt our
fingers on that one in eduroam already, so I'm somewhat reluctant to go
down that path. Here's the war story.

In an early beta deployment, we also considered the exact mention of the
realm name the only safe thing to do. We used SAN:URI and filled it with
a URN which contained the realm name (that is probably not the most
obvious nor practicable way of doing things, but ... well.. it was an
early beta).

One of the things which are troublesome about this is that we found that
even with dynamic discovery, proxies continued to exist: for most
eduroam IdP's, operation of their own RADIUS/TLS enabled server, caring
to get issued certificates, checking revocation and so on, was seen as
too complex. Instead, they put the first-level aggregation server into
DNS (with their agreement) to catch all their traffic and use normal
RADIUS "routing tables" for the last hop to the actual IdP.

That reduced the number of servers who needed to be "in the know" about
dynamic discovery, and made the whole thing much more easily manageable.
Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of
RADIUS NAI realms. With each realm required to be in the cert, the cert
needs to changed whenever a new realm gets added or deleted. It also
needs to remain in sync in near real-time with what the individual IdPs
put into their DNS.

This makes the whole dynamic discovery model a lot less self-service;
there is always a CA operation involved.

Our model of reverting to a generic "eligible eduroam IdP" (read as:
"... or proxy for an eligible eduroam IdP") restored the self-service
capabilities for the individual IdPs; they could add NAPTRs for their
NAI realm at any time, and no changes on the certificates would be
needed any more.

I'm afraid that manageability issues will prevent the SAN approach from
scaling to large consortia if any kind of aggregation is in use.

Maybe if the SAN could include wildcards things would look better; an
aggregation proxy could be given a cert for "*.lu and foo.net" for example.

This, however, defeats the purpose of impersonation prevention because
then that server could take the place of all .lu NAI realms, even if
some of those want to handle their own business themselves.

So... there's pros and cons. I wonder what you think of the reservations
above.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]