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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Stefan Winter
> Sent: Wednesday, February 27, 2013 7:19 AM
> To: [e-mail]
> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
> 
> 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.

This depends on specific properties of the EAP method being used.  It would
not be true for a simple user name/password EAP method.   I don't know that
there is anything that would prevent a man-in-the-middle attack from
occurring in this situation would might result in leaked credentials and no
failure for the EAP peer to know about.

See Sam's draft in the EMU WG for more details.

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

Given the presence of the second sentence in the paragraph that is not a
statement that I heard from the Security Considerations.

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

I don't know that I agree with this.  A very simple way to use DANE for this
would be

Server gets client certificate
Server extracts client DNS name from certificate
Server does a TLSA lookup on the client DNS name and sees if it matches the
certificate given per DANE rules

Assuming that we are looking a this being a generic proxy, that information
is going to be in the DNS for lookups back.

However I was really only looking at the use of DANE in the same forward
direction that you are doing the discovery.  This means that the mutual auth
question is an interesting one and should be discussed as a reason for
perhaps not using the DANE work.

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

Given that ABFAB is basically doing a completely different dynamic
negotiation, I would be inclined to state that don't use PSK is a reasonable
position.

Jim

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