Subject: Re: [TLS] EAP-in-TLS and channel bindings

From: Tom Wu <[email-masked]>
Date: Tue, 5 Apr 2011 14:54:09 -0700

> On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir <ynir at checkpoint.com> wrote:
> > Sure, but those require the verifiers (salted hashes of the passwords) to be stored on the TLS server.
> >
> > I don't think there's a good way to get TLS-SRP to work with a backend AAA server.
>
> I think it's doable IF you have AAA support for SRP verifiers.  But
> most folks who have AAA infrastructures don't have SRP verifiers.  One
> could simply acquire those verifiers over time as users change their
> passwords, but that is a big barrier to adoption.

>From Yaron Sheffer:
> Also, EAP as a generic infrastructure is making steady (albeit slow) progress with channel bindings and the NEA work. And it provides two recently published password-based protocols: https://tools.ietf.org/html/rfc6124 and http://tools.ietf.org/html/rfc5931.

These messages seem to imply that TLS-SRP won't play well with backend AAA servers while RFC6124 (EAP-EKE) and RFC5931 (EAP-pwd) would, but this isn't really true; all strong password protocols need the server to know the password, or some function of it, while the protocol is being negotiated.  If I'm missing something, please let me know.

Tom

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Apr 2011 10:59:38 +0200

Hi Tom.

There is no problem with SRP vs EKE or pwd. The problem is that AAA servers work either with plain passwords (the web server sends the password in an "access-request" and the AAA server returns an "access-accept") or using EAP.  If someone were to pick up James Carlson's work and create an EAP-SRP method, it would work just as well.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Wu
Sent: 06 April 2011 00:54
To: [email-masked]
Subject: Re: [TLS] EAP-in-TLS and channel bindings

Tom

---

From: Tom Wu <[email-masked]>
Date: Wed, 6 Apr 2011 05:49:43 -0700

But if we start out by assuming that existing AAA deployments don't have SRP verifiers, we must also assume that they don't have EAP-pwd or EAP-EKE password data either, so they cannot use any of those strong password protocols right away.

Going forward, AAA infrastructures can add support for SRP verifiers just like they can for EAP-pwd or EAP-EKE password data.  In that case, given that complexity is the enemy of security, I'd say that's a good reason to prefer the simpler TLS-SRP handshake.

Tom

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 2:00 AM
To: Tom Wu; [email-masked]
Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings

Hi Tom.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Wu
Sent: 06 April 2011 00:54
To: [email-masked]
Subject: Re: [TLS] EAP-in-TLS and channel bindings

Tom

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 07:59:14 -0500

> Going forward, AAA infrastructures can add support for SRP verifiers just like they can for EAP-pwd or EAP-EKE password data.  In that case, given that complexity is the enemy of security, I'd say…

As I explained: the point is to allow people to use what they have.
TLS-SRP does not do that.  EAP-in-TLS does.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Apr 2011 15:50:27 +0200

I don't think AAA deployments are going to send SRP verifiers to the servers. They implement a pluginnable platform for all kinds of EAP methods, and you can use any EAP method that you have a plug-in for. Using EAP with RADIUS is defined in RFC 4072.

Microsoft AAA server comes with EAP-MSChapv2, EAP-TLS, EAP-PEAP and optionally EAP-SecurID. Of these, only EAP-MSChapv2 and EAP-SecurID make sense in the TLS context.  If somebody writes plug-ins for EAP-EKE, EAP-Pwd and EAP-SRP (if this is ever defined), that would work as well.

Adding SRP verifiers without EAP requires an extension to RADIUS (or DIAMETER), and that's an issue for a different working group.

So I agree that TLS-SRP is simpler and requires less round-trips. But I don't see how to make it work with existing AAA servers.

Yoav

-----Original Message-----
From: Tom Wu [mailto:[email-masked]] 
Sent: 06 April 2011 15:50
To: Yoav Nir; [email-masked]
Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings

Tom

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 2:00 AM
To: Tom Wu; [email-masked]
Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings

Hi Tom.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Wu
Sent: 06 April 2011 00:54
To: [email-masked]
Subject: Re: [TLS] EAP-in-TLS and channel bindings

Tom

Scanned by Check Point Total Security Gateway.

---

From: Tom Wu <[email-masked]>
Date: Wed, 6 Apr 2011 06:50:59 -0700

> TLS-SRP does not do that.  EAP-in-TLS does.

No, not for strong password protocols it doesn't.  If I don't have AAA support for EAP-EKE or EAP-pwd password data, I can't use either of them.

To use EAP-pwd and EAP-EKE, I need to wait for my AAA backend to support EKE/pwd password data, plus I need to wait for my TLS stack to adopt EAP-in-TLS.  To use TLS-SRP, I need to wait for my AAA backend to support SRP verifiers, and then I'm done, since my TLS stack most likely already has TLS-SRP support.  I suppose it all depends on which parts of the user's environment you assume are fixed and which ones can be upgraded.

Tom

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Apr 2011 15:53:30 +0200

I agree that if I were implementing EAP-in-TLS now, it would be more about EAP-MSChapv2 than any of the good methods.

Still, writing a plug-in for a Microsoft AAA server and for Windows XP/7 is well-documented, and can be done without any further standards action. 

-----Original Message-----
From: Tom Wu [mailto:[email-masked]] 
Sent: 06 April 2011 16:51
To: Nico Williams
Cc: Yoav Nir; [email-masked]
Subject: RE: [TLS] EAP-in-TLS and channel bindings

Tom
 jy u    $>   :-jT r  !

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 09:43:37 -0500

> I don't think AAA deployments are going to send SRP verifiers to the servers. They implement a pluginnable platform for all kinds of EAP methods, and you can use any EAP method that you have a plug…

Great point.  Password verifiers _are_ security-sensitive.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 09:48:19 -0500

> No, not for strong password protocols it doesn't.  If I don't have AAA support for EAP-EKE or EAP-pwd password data, I can't use either of them.

You might have AAA support but not have verifiers, and you could
acquire verifiers slowly, over time, as users change their passwords.

Also, ZKPPs benefit primarily those who can't bootstrap trust into the
devices where the passwords are typed in.  In many enterprises that's
not an issue.

And then there's the ZKPP password verifiers being security-sensitive
(since they are subject to off-line dictionary attacks), so giving
every TLS server access to those is a non-starter.  You _should_ want
EAP-in-TLS for that reason alone!

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 07 Apr 2011 09:55:30 +0200

On 04/06/2011 03:53 PM, Yoav Nir wrote:

> I agree that if I were implementing EAP-in-TLS now, it would be more
> about EAP-MSChapv2 than any of the good methods.

Then it looks more that EAP-in-TLS is to be used as a by-pass method to
include weak authentication algorithms, that would have never be
approved by this WG.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Apr 2011 20:08:29 +0200

> include weak authentication algorithms, that would have never be

I don't see why. EAP-MSChapv2 is in wide use, and is not considered broken when used inside an encrypted transport like TLS or IKE.

Also, creating EAP-EKE/PWD/SRP plug-ins for AAA servers is well documented, and does not require work by any IETF working group.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Apr 2011 17:46:00 +0200

> Also, creating EAP-EKE/PWD/SRP plug-ins for AAA servers is well documented, and does not require work by any IETF working group.

Considering it broken or not depends on your attack scenario and the
deployment scenario. By the definition of EAP-TLS, you know neither.

If for example I use anonymous DH and perform mutual authentication of
peers using EAP and mschapv2, then it is broken. I suppose there
several scenarios where one can combine that and have a useful
protocol. That is the reason the original TLS did not allow
many extensions. To contain the security decisions to protocol
designers, not individual administrators.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 13:54:20 -0500

> designers, not individual administrators.

IMO: a) EAP methods that support cryptographic binding should/must be
used, b) EAP cryptographic binding should/must be used to do RFC5056
channel binding to the TLS connection's tls-unique channel bindings.
The question is whether (a) and (b) are a SHOULD or a MUST, and if it
is not a MUST then what mitigation might or might not be feasible or
acceptable.

Note though that if RFC5056 channel binding is done from the EAP
method to the TLS connection, then your objection is fully dealt with.
 And see the Subject: line in the header :) :)  Simon brought up
channel binding for a reason, namely, that he had the same concerns as
you do.  I have exactly the same concerns as well.  However, Simon and
I believe there's a solution: RFC5056 channel binding.  If you believe
that channel binding is not a solution, please say so and let's figure
out why that might or might not be the case.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Apr 2011 10:43:34 +0200

> out why that might or might not be the case.

My concern was not related to channel bindings, but to the protocol
combination described in the initial message and the fact that
any security guarrantee on the original protocol is turned void by such
combined protocols (one has to reevaluate the security goals and
threats for the new protocol).
Channel bindings indeed provide a better way  to stack security protocols
and authentication in a layered approach.

regards.
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Apr 2011 12:13:27 +0200

> and authentication in a layered approach.

There are two attributes that we consider for EAP methods. They can be key-generating (produce an MSK), in which case that MSK can be used for channel binding, and they can be mutually-authenticating, in which case you are safe to use anonymous D-H. If the method is not mutually-authenticating, the client needs to verify the server certificate.

While these two attributes are orthogonal, in practice the modern methods have both.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 11:50:38 -0500

> threats for the new protocol).

But your concern is addressed by channel binding.  Indeed, I like to
think that the only real concern with respect to adding EAP to TLS
_is_ channel binding.  Any time we layer security technologies we need
to think of composition, and the best, and perhaps only _formal_ tool
that we have for that is channel binding.

> and authentication in a layered approach.

Thanks for the vote of confidence.  Are there any other approaches?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 11:56:24 -0500

> There are two attributes that we consider for EAP methods. They can be key-generating (produce an MSK), in which case that MSK can be used for channel binding, and they can be mutually-authenticati…

Key generation can definitely be used for RFC5056 CB.  EAP
Cryptographic Binding can also be used to implement RFC5056 CB.

I don't understand the comment about mutual authentication though.
Can you expand on that?

Did you mean that the EAP method can authenticate the TLS server's
certficate?  (If so that's one form of RFC5056 CB, using the
tls-server-end-point CB type.)  Or did you mean something else?

There has got to be some binding between EAP and TLS, otherwise you
get into trouble.  But you might be able to use tunneled EAP methods
to deal with otherwise weak EAP methods.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Apr 2011 20:00:40 +0200

> I don't understand the comment about mutual authentication though.

It was in response to Nikos' earlier line: "If for example I use anonymous DH and perform mutual authentication of
peers using EAP and mschapv2, then it is broken."

This is because MS-Chapv2 is vulnerable to dictionary attacks, so it can't be considered mutually-authenticated. If you don't use an ADH ciphersuite, and the client does verify the server certificate, then you don't have this problem.

> to deal with otherwise weak EAP methods.

I intend to use the MSK or a mix of MSK and master secret or extractor to compute a signature similar to the "Finished" message.

I'm not sure whether this is enough for binding, or whether you also need to mix the key into the session resumption state cache, or actually into the secret used for computing extractors.

I think it's not necessary, but what do you think?

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 13:20:21 -0500

> This is because MS-Chapv2 is vulnerable to dictionary attacks, so it can't be considered mutually-authenticated. If you don't use an ADH ciphersuite, and the client does verify the server certifica…

But this is not enough.  You want to protect the method against the
TLS server as well.  After all you might be federating authentication
(OK, that's probably out of scope for your protocol, but then that's
quite limiting, particularly in comparison to the ABFAB work, so I'd
have to wonder why bother with EAP-in-TLS!  see below), and even if
you're not, you'd still want defense in depth, wouldn't you?

So, for weak methods I think you'd want to use tunneling, with the
tunnel end-point located in some server other than the peer of the TLS
client.

> I intend to use the MSK or a mix of MSK and master secret or extractor to compute a signature similar to the "Finished" message.

What you should sign (MAC) is the tls-unique channel bindings data of
the TLS connection.

> I'm not sure whether this is enough for binding, or whether you also need to mix the key into the session resumption state cache, or actually into the secret used for computing extractors.

It's enough binding, provided both peers send a MAC and check the one
received.  But you'll want to associate the authenticated user name
with the TLS session ID.

What is the story regarding federation?  If there isn't one, then I
really have to ask: why bother with this work?  I'd much rather you
pursue draft-williams-tls-sasl-opt + the ABFAB WG GSS-EAP mechanism.
That way you'd get: a) EAP (which is what you want), b) in/over TLS
(also what you want), c) with CB (which you should want), d) plus
federation (which others are bound to want, even if you don't), e)
much more of the crypto worked out for you already (in ABFAB), f) a
fair bit of source code (since much of the Project Moonshot stuff is
open source).  That's a lot of benefits, meriting at least serious
consideration.

(Note also that there's a further one round-trip optimization to make
for draft-williams-tls-sasl-opt by making an optimistic SASL/GS2
mechanism selection and using MIC tokens, one of them PROT_READY, to
do the CB.  If some of those terms mean nothing to you, don't worry --
they are GSS-API specific, and we can go into them later if you choose
to investigate this approach in depth.)

Nico
-- 

Nico
--