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

[Stefan Winter <[e-mail]>]

Hi,

> I disagree.  In general, we require people to have a MTI solution that
> provides what we believe is generally adequate security.  While it's
> fine for eduroam to say that one IDP impersonating another is OK for
> eduroam, I think that's not good enough as a MTI mechanism because there
> are a lot of environments where that distinction would be important.
> 
> So, I do think we need to have rules about what implementations MUST be
> able to support in terms of cert validation and naming configuration.

That's reasonable indeed. I see two ways right now:

- require a deterministic verification that the input I to the algorithm
led to a server responsible for that realm (DNS as the discovery
mechanism could be untrusted then)

- require a trusted lookup i.e. DNSSEC on all lookups

The first one sounds a bit difficult; it would probably have to take the
form of: the realm from I needs to in a deterministic field of the
presented server cert, e.g: SAN:othername="RADIUS-realm:<I>"

The second one sounds much more straightforward: make DNSSEC required,
fail discovery if non-vetted DNS had to be used.

I'd appreciate a "mild" formulation then like that implementations can
optionally be allowed to turn off the DNSSEC requirement if local
deployment circumstances warrant it.

With that said, the second variant sounds like the cleaner path to use
to me.

Comments welcome...

Stefan

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