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

From: "radext issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2013 15:43:15 -0000

#148: Review of dynamic-discovery by Jim Schaad

 1) In section 2.3.3, step 4 - what is to be considered an error at this
 point.  For example, there are a number of odd conditions that can be
 returned from DNSSEC, specifically the "indeterminate" state.

 2) In section 2.3.4 - Given that the above algorithm does not return a TTL
 value in the event of an empty set or define how to know the TTL value -
 what is the TTL value to be used in in paragraph 2 "negative TTL"?

 3) In section 2.3.5 - Does it make sense to return a result, but to
 continue the algorithm and store the result after the timeouts for later
 use?

 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.

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

 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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  dynamic-discovery        |    Version:  1.0
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/148>
radext <http://tools.ietf.org/radext/>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Feb 2013 16:19:15 +0100

On your issue about TLS / Certs / DANE

>  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

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

>  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: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Feb 2013 10:24:40 -0500

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

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

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.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Feb 2013 16:37:42 +0100

Hi,

> 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

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Feb 2013 10:47:49 -0500

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

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.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Feb 2013 12:42:22 -0800

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

> 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.
> 
do
> correct me if I'm wrong!)
> 

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.

> 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:
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.
> > 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.
> 
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: +352 424409 1
> Fax: +352 422473