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

From: Stefan Winter <[email-masked]>
Date: Mon, 04 Mar 2013 16:46:37 +0100

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

-- 
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: Mon, 04 Mar 2013 10:55:48 -0500

This is experimental, right?  I'm trying to figure out how loud to
grumble about the lack of a MTI certificate validation approach.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 04 Mar 2013 17:04:54 +0100

Hi,

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

That's a reasonable concern to have, IMHO. I'd usually agree that the
use of a SAN is a safer bet right now. Unfortunately, we've burnt our
fingers on that one in eduroam already, so I'm somewhat reluctant to go
down that path. Here's the war story.

In an early beta deployment, we also considered the exact mention of the
realm name the only safe thing to do. We used SAN:URI and filled it with
a URN which contained the realm name (that is probably not the most
obvious nor practicable way of doing things, but ... well.. it was an
early beta).

One of the things which are troublesome about this is that we found that
even with dynamic discovery, proxies continued to exist: for most
eduroam IdP's, operation of their own RADIUS/TLS enabled server, caring
to get issued certificates, checking revocation and so on, was seen as
too complex. Instead, they put the first-level aggregation server into
DNS (with their agreement) to catch all their traffic and use normal
RADIUS "routing tables" for the last hop to the actual IdP.

That reduced the number of servers who needed to be "in the know" about
dynamic discovery, and made the whole thing much more easily manageable.
Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of
RADIUS NAI realms. With each realm required to be in the cert, the cert
needs to changed whenever a new realm gets added or deleted. It also
needs to remain in sync in near real-time with what the individual IdPs
put into their DNS.

This makes the whole dynamic discovery model a lot less self-service;
there is always a CA operation involved.

Our model of reverting to a generic "eligible eduroam IdP" (read as:
"... or proxy for an eligible eduroam IdP") restored the self-service
capabilities for the individual IdPs; they could add NAPTRs for their
NAI realm at any time, and no changes on the certificates would be
needed any more.

I'm afraid that manageability issues will prevent the SAN approach from
scaling to large consortia if any kind of aggregation is in use.

Maybe if the SAN could include wildcards things would look better; an
aggregation proxy could be given a cert for "*.lu and foo.net" for example.

This, however, defeats the purpose of impersonation prevention because
then that server could take the place of all .lu NAI realms, even if
some of those want to handle their own business themselves.

So... there's pros and cons. I wonder what you think of the reservations
above.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 04 Mar 2013 17:05:45 +0100

Hi,

> grumble about the lack of a MTI certificate validation approach.

Correct.

Stefan

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 11:10:12 -0500

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

I'm missing something here.  I'm not arguing that eduroam should use
certificate validation. I'm simply arguing that there should be a MTI
certificate validation strategy.  We're documenting a generic mechanism
here, not eduroam practice, right?  I agree we want eduroam to comply
with the spec, but an MTI security mechanism you choose not to use in
your enviroment doesn't violate the spec.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Mar 2013 21:07:46 -0500

Stefan,

Did you consider the use of SNI as part of your solution?  This would allow
for the use a different certificates for each thing you proxy and thus would
reduce the need to re-issue certificates.  The only thing that would be
needed is to add a new certificate for each new proxied realm

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Winter
> Sent: Monday, March 04, 2013 11:05 AM
> To: [email-masked]
> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
> 
> Hi,
> 
> > 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.
> > radsecproxy or freeradius or other radsec implementations could
> > actually implement dnssec validation in the radius proxy right now.
> 
> That's a reasonable concern to have, IMHO. I'd usually agree that the use
of a
> SAN is a safer bet right now. Unfortunately, we've burnt our fingers on
that
> one in eduroam already, so I'm somewhat reluctant to go down that path.
> Here's the war story.
> 
> realm name the only safe thing to do. We used SAN:URI and filled it with a
> URN which contained the realm name (that is probably not the most obvious
> nor practicable way of doing things, but ... well.. it was an early beta).
> 
> even with dynamic discovery, proxies continued to exist: for most eduroam
> IdP's, operation of their own RADIUS/TLS enabled server, caring to get
issued
> certificates, checking revocation and so on, was seen as too complex.
> Instead, they put the first-level aggregation server into DNS (with their
> agreement) to catch all their traffic and use normal RADIUS "routing
tables"
> for the last hop to the actual IdP.
> 
put
> into their DNS.
there is
> always a CA operation involved.
> 
> capabilities for the individual IdPs; they could add NAPTRs for their NAI
realm
> at any time, and no changes on the certificates would be needed any more.
> 
> then that server could take the place of all .lu NAI realms, even if some
of
> those want to handle their own business themselves.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Mar 2013 21:08:16 -0500

Hear Hear!!!!!
Jim

> Of Sam Hartman
> Sent: Monday, March 04, 2013 11:10 AM
> To: Stefan Winter
> Cc: [email-masked]
certificate
> validation strategy.  We're documenting a generic mechanism here, not
> eduroam practice, right?  I agree we want eduroam to comply with the spec,
> but an MTI security mechanism you choose not to use in your enviroment
> doesn't violate the spec.
> 
> --Sam

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Mar 2013 07:02:03 +0200

I would encourage sparing few words for a MTI certificate validation strategy.

- Jouni

---

From: Stefan Winter <[email-masked]>
Date: Wed, 06 Mar 2013 13:31:43 +0100

Hi,

> needed is to add a new certificate for each new proxied realm

Back in the day: no :-)

But looking at SNI now sure looks somewhat promising. It's not a clear
winner though:

SNI as per the current RFC6066 definition includes only DNS hostnames.

The discovery algorithm in this draft will at some point end up at a
host which is responsible for a realm - but that does not mean this
hosts' DNS name is identical to the realm that was being queried. If ID
management is outsourced, the realm and the hostname can be completely
unrelated.

In a "dream world" where SNI would allow SAN:othername as an indication,
this might work pretty well though. It could combine Sam's
"SAN:othername realm=whatever " construct and combine it with a
client-side hint in SNI: please show me a certificate with this
SAN:othername included.

This would nicely bond together the realm, and the verification that the
discovered server is authorised for that particular realm (disregarding
the DNS host name).

As you correctly point out, this would *still* be less than practical in
a large-scale deployment, where an aggregation proxy would need to be
issued "hundreds" of certificates by a CA, but it would at least in
principle be a rather clean approach.

That said, the only way to get other names besides DNS names into SNI
would be by updating RFC6066. Certainly not impossible, but a big caliber.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 06 Mar 2013 13:38:43 +0100

Hi,

> your enviroment doesn't violate the spec.

My issue is not that the MTI mechanism would not be identical to what
eduroam does; far from it.

My issue is that this particular mechanism is known to have scalability
issues by practical experimentation. Of course we could make it MTI
anyway. The consequence might well be that we require code in conforming
servers that is later "never" used because its practical implications
are clumsy.

That would be "specifying MTI for MTI's sake" - without much real value
in the real world, and code being written for no reason other than to
comply with the "law". I don't really like that situation.

Of course our scalability problems could be entirely homemade and not
applicable to the rest of the world, and every other deployer will find
the MTI mechanism as sketched perfectly fine, and the implementation
code will be put to good use.

Then I'd have no issues with specifying this; eduroam would simply be
doing its own thing anyway. It's just that I'm not really convinced that
this is the case.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Mar 2013 07:52:57 -0500

I consider the lack of a MTI validation mechanism (cert or otherwise)
that's credible a fatal flaw for standards-track.  I prefer this spec
have a MTI cert validation mechanism, but would rather see it published
without than not published.