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

[Stefan Winter <[e-mail]>]

On your issue about TLS / Certs / DANE

>  4) I find the security considerations to be completely inadequate for this
>  document.
>  Use of a certificate is only going to be valid if the original realm name
>  that is the input the validation routine is what is found and matched in
>  the certificate.  In this case I would not know where in the name or alt
>  name fields of the certificate it would be found.  You cannot validate to
>  the final DNS name as that is now an untrusted value.

That's correct; in eduroam, we've settled for a good-enough solution and
deploy with that: certificates need to come from an agreed set of CAs
and carry a common policy OID which stands for "this is a valid eduroam
IdP" (and there's a second OID for "valid hotspot" for the other side of
the mutual TLS auth).

In combination with DNSSEC, that gives trusted results for the entire
validation process. With DNS (no SEC), a holder of a eduroam IdP
certificate could manipulate another realm's DNS to point to his own
server; i.e. he, as an accredited member of the consortium, could steal
another member's Access-Requests and the dynamic discovery
infrastructure wouldn't notice.

While that's suboptimal, we found that to be a reasonable tradeoff,
partly because the atmosphere inside the consortium is not at all
hostile, but also because such a hijacking would still be noticed by the
wrong EAP termination and the supplicant complaining about an unexpected
EAP server presenting a unexpected server-side credential.

That is a decision for a deployer of the algorithm to make though: the
security considerations say that it's only safe with DNSSEC - which is
true; every deployer is free to draw his own consequences from that.

>  The suggestion of out-of-band validation methods ignores the existence of
>  DANE.

(Preface: I may very well be very mistaken about aspects of DANE. Please
do correct me if I'm wrong!)

We've investigated the opportunities of DANE and it seems much rather
like: DANE ignores the possibility that TLS handshakes can be mutual.
Which is a bummer for things like RADIUS/TLS which /require/ mutual auth.

The problem is that only one side of the job can be done with DANE:
there's a an input to be looked up in DNS, and that input can also be
used to look up TLSA records for use in the later TLS handshake.

However, as soon as the TLS server presented his credential and the
client has verified that this is what is expected, the TLS client sends
his own TLS credential - with no DNS involved whatsoever. It is unclear
to me what the server-side end would do with the incoming data, and
where/how in the DNS tree it would verify that the incoming credential
matches its expectations and that the connecting client is authorised as
part-of-the-club.

It's not like it's impossible; I could sketch a way how this potentially
might work:

- client is required to have a CN or SAN:DNS pointing to an "accredited
hotspot" DNS tree; like CN=restena.lu.hotspot.consortium.com;
- server does TLSA lookup of that CN (and only if suffix is indeed
"hotspot.consortium.com"); if it finds matching data, establish TLS
connection
- DNS domain hotspot.consortium.com is maintained as a registry of
authorised clients, delegated to sub-branches as needed

But unless I'm mistaken, none of this is written in the DANE specs. I
would find it inadequate for the dynamic discovery document to make up
lots of rules on implementing DANE-like things. If there were a document
which specifies client-cert validation with DANE, it would be perfectly
fine to add a pointer to that though.

>  The NAI document suggests that the RADIUS peer is pre-configured with
>  information about certificates or TLS validation data.  The suggested text
>  works in the case that the table says do dynamic lookup and here is the
>  TLS configuration data.  But in other cases it is completely unclear how a
>  TLS-PSK would be found for a dynamic lookup.

I'd say: unless ABFAB people want to have text about the dynamic
negotiation of TLS-PSK keying material with this algorithm (some ABFABs
are known to read the radext list :-) ), I'd feel inclined to write that
PSK cipher suites are not appropriate for use with DNS-based dynamic
discovery.

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]