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

[Stefan Winter <[e-mail]>]

Hi,

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

We (eduroam) require EAP methods capable of mutual authentication
(typically by the EAP server presenting a server certificate) and
require users to validate the server-side identity. It is well possible
that some users neglect to configure the proper checks, and yes, these
would be fooled into connecting to a different EAP server than expect.
It is though, to a very large extent, their own fault then.

But this is a bit of side-track issue not terribly relevant for the spec.

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

Okay, I've made it more explicit in my current working copy:

3.  Security Considerations

   The results from the execution of this algorithm are only trustworthy
   if each of the lookup steps by the name resolution library were
   cryptographically secured; i.e.  if DNSSEC validation was turned on
   during the resolution AND all of the records were in a DNSSEC signed
   zone AND validation of all those records was successful.

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

Sure; it's not rocket science to specify this. It just hasn't been done;
and I would find it undue for this document to invent something on its
own. The proper place for such work would IMHO be in DANE for the
generic use of TLS client authentication. It would be easy to refer to
such a spec and make it a suggested way of verifying TLS keys.

I've added the following text to my working copy' Security Consideration
to make all this spelt out explicitly:

   The use of DNSSEC allows to verify TLS keys inside the DNS using
   DANE.  It is in principle possible to use DANE and TLSA records to
   verify the authenticity, and possibly the authorisation of, a
   discovered RADIUS server by the RADIUS client which executed the
   algorithm.  However, RADIUS/TLS and RADIUS/DTLS require mutual
   authentication; i.e.  the RADIUS client's authenticity and
   authorisation are also verified by the RADIUS server as the client
   establishes the TLS connection.  The DANE specification does not
   currently include a mechanism regarding the validation of a TLS
   credential of a client as it connects to a server (there is not per
   se a DNS label for which to do TLSA lookups).  This makes DANE in its
   current state unsuitable for TLS connections discovered with the
   algorithm in this specification.  If client authentication gets
   covered by future DANE extensions, this situation may change.

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

It is actually quite promising - but client verification being
underspecified currently makes it incomplete. I'll very gladly look at
things again when there is a TLS client verification spec!

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

Good! I've deleted the mention of TLS-PSK from the security
considerations; and clarified the dangers of not using DNSSEC:

   When using DNS without DNSSEC security extensions for at least one of
   the replies to NAPTR, SRV and A/AAAA requests as described in section
   Section 2, the resulting set O can not be trusted.  RADIUS transports
   have an out-of-DNS-band means to verify that the discovery attempt
   led to the intended target: certificate verification using a PKI.  If
   the result set from DNS discovery is not trusted, deployments need to
   take sufficient care to verify during the TLS session establishment
   that they communicate with a peer they expect and deem authorised for
   RADIUS datagram exchange in their roaming environment.

(The last sentence is a cliffhanger to add MTI text how to do this,
depending on the outcome of the other discussion in the thread with Sam)

Greetings,

Stefan

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


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