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

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Apr 2011 10:41:34 +0200

Hi,

I want to explain again what I (unsuccessfully) tried to raise during
the presentation.  First it helps to recall the protocol flow with
TLS-in-EAP, from the document:

         Client                                               Server
         ------                                               ------

         ClientHello(*)             -------->
                                                      ServerHello(*)
                                                       (Certificate)
                                                   ServerKeyExchange
                                            EapMsg(Identity-Request)
                                     <--------       ServerHelloDone
         ClientKeyExchange
         (CertificateVerify)
         ChangeCipherSpec
         InterimAuth
         EapMsg(Identity-Reply)     -------->
                                                    ChangeCipherSpec
                                                         InterimAuth
                                                EapMsg(GPSK-Request)
                                    <--------
         EapMsg(GPSK-Reply)         -------->
                                                EapMsg(GPSK-Request)
                                    <--------
         EapMsg(GPSK-Reply)         -------->
                                                     EapMsg(Success)
                                    <--------               Finished
         Finished                   -------->

Note that the "Finished" messages are not sent until AFTER the EAP
exchange.  This means that the "tls-unique" channel binding (which
refers to the Finished messages) is not available to the EAP mechanism.
That means that the EAP mechanism is not able to channel bind to TLS
using "tls-unique", which results in weaker than necessary
authentication as far as I can see.

Do you see the problem now?

I see a few solutions:

1) Specify that when EAP-in-TLS is used, the "tls-unique" channel
binding should use the "InterimAuth" message instead of the "Finished"
message.

2) Specify a channel binding for TLS that doesn't use the "Finished"
message.

3) Specify that you always need to complete a full TLS handshake first,
and then re-handshake and do the EAP handshake during that phase.

There may be other solutions.  At this point I don't have an opinion on
what is a good way to resolve this.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Fri, 1 Apr 2011 13:52:13 +0300

Hi Simon

See below.

> TLS-in-EAP, from the document:

I'm not sure that I do. While I understand an application using the tls-unique channel binding, I don't understand what an EAP method would do with the channel binding. 

The Finished message calculation incorporates the MSK from the EAP method, and that binds the tls-unique that is available to applications to the authentication.

> binding should use the "InterimAuth" message instead of the "Finished"

But the actual authentication happens after the InterimAuth, so that struct is not bound to the authentication.

> and then re-handshake and do the EAP handshake during that phase.

Interestingly, this is the way it's usually done with certificates in the web browser case, so I would expect that this would be the way to use TLS-EAP as well. Authentication happens only in the https://www.example.com/login.html and after that we use anonymous TLS and session cookies. Since the get happens after the first handshake, the server sends a HelloRequest after it gets the "GET login.html" message.  But I don't understand why it's necessary for security.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Scanned by Check Point Total Security Gateway.

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Apr 2011 18:51:20 -0500

On Fri, Apr 1, 2011 at 3:41 AM, Simon Josefsson <[email-masked]> wrote:
> [...]
> [...]

> what is a good way to resolve this.

The situation here is not that different to past proposals to do
GSS-API authentication in TLS.  And the objections to using EAP in TLS
must be similar to the objections to using GSS in TLS -- objections I
myself have.

I strongly encourage the proponents to look at
draft-williams-tls-sasl-opt-04, which is my proposed solution for
mixing SASL/GSS-API and TLS in a round-trip optimal way (though it
could be further optimized by adding an optimistic GSS mechanism
selection and using MIC tokens to do the channel binding).  I believe
the same approach ought to work equally well for EAP.  The nice thing
about my proposal is that it makes no changes to TLS -- it uses TLS
extensions, but it does not change the TLS state machine.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 02 Apr 2011 09:16:26 +0200

Nico Williams <[email-masked]> writes:

> draft-williams-tls-sasl-opt-04

+1.  Your document has the channel binding discussion I was looking for
in EAP-in-TLS.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Sat, 2 Apr 2011 21:00:07 +0300

> extensions, but it does not change the TLS state machine.

Hi Nico,

Thanks for this. One of our earlier versions of our proposal looked like this:
         Client                                               Server
         ------                                               ------

         ClientHello(*)             -------->
                                                      ServerHello(*)
                                                       (Certificate)
                                                   ServerKeyExchange
                                            EapMsg(Identity-Request)
         Finished
                                                            Finished
                                    <--------           EAP-Finished
         EAP-Finished               -------->

The only difference is that InterimAuth is renamed to "Finished", and the last handshake message is renamed to "EAP-Finished". Putting it like this, it looks very much like figure 2 in your draft. The reason we chose to go with InterimAuth in the middle rather EAP-Finished in the end was because the usual semantic for "Finished" is that the application data follows, while we consider the EAP part to be an extension of the handshake that precedes application data. In your draft, the SASL authentication is sent as data.

EAP methods have no use for the tls-unique channel binding. However, I think that whether the EAP message is sent as a handshake message or as application data, the calculation of tls-unique needs to change in case of EAP authentication. Do you think a good value for it would be to take the tls-unique used for the Finished (or "interimAuth") record, concatenate the MSK from EAP, and hash them together?

If a proposal like this is more palatable to the group (and doesn't change the state machine as much), I think this can be worked out.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Sun, 3 Apr 2011 23:36:08 -0500

> The only difference is that InterimAuth is renamed to "Finished", and the last handshake message is renamed to "EAP-Finished". Putting it like this, it looks very much like figure 2 in your draft.…

Indeed!  This is very much like my proposal.  The key is that the
round-trips required by EAP beyond those required by TLS do not hold
up the end of the TLS handshake.  The application can negotiate the
use of EAP in this way via a Hello extensions and then the application
can hold off the start of the normal application data protocol until
after the EAP (or GSS, or SASL, or whatever) exchange completes.

I believe none of the normal objections to earlier proposals apply to
such a design because a) only normal TLS extension slots are used, b)
the TLS state machine is not changed, only the application protocol is
changed.  In fact, no changes should be needed to any TLS
implementation that provides the necessary extensions hooks, and this
is a critical feature.

> EAP methods have no use for the tls-unique channel binding. However, I think that whether the EAP message is sent as a handshake message or as application data, the calculation of tls-unique needs…

I'm not sure that EAP has no use for tls-unique here...  Suppose
you're talking to an MITM (see the Comodo CA compromise...).  Don't
you want to make sure that they are not able to cut-n-paste the EAP
exchange to the real service??  I would think that you do!  In EAP
this would be called "cryptographic binding", not "channel binding" --
we have a sad terminology issue :(

> If a proposal like this is more palatable to the group (and doesn't change the state machine as much), I think this can be worked out.

I have found it very difficult to elicit approving noises from the TLS
WG, but as you know it's quite simple to get the WG to make negative
noises.  I'm not sure how you'd go about getting approving noises
other than to push through and see what happens as your I-D
progresses.

However, as I said, the key test of whether your proposal plays well
with TLS will be whether you need to make any changes to TLS itself.
If you can avoid TLS changes (to the spec, to implementations [except
for the purpose of adding TLS functionality already specified]) then
you're golden.  I'd go further: your work wouldn't even fall under the
TLS WG charter (though you'd still want to give the WG's participants
an opportunity to review your I-D).  In other words: just adjust back
to the protocol design described above and in my I-D and move forward
towards publication.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 03 Apr 2011 21:55:26 -0700

I admit to not knowing what EAP-TLS is, but from reading this message
it seems like the EAP exchange could maybe benefit from defining a new
record type.  Perhaps that's already what's done?  Or is there a reason
to not do that?

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 00:09:18 -0500

> record type.  Perhaps that's already what's done?  Or is there a reason

It's completely unnecessary.  Imagine that you have an application
that uses TLS to which you're adding some feature, and this feature
requires three round-trips at the beginning, and suppose further more
that there's nothing wrong, security-wise[*], with doing some or all
of those round-trips without the protection of TLS.  That's pretty
much the situation here (the number of round-trips may vary in the
actual case at hand).

The obvious thing to do then is to piggy-back the first two
round-trips of this application protocol feature, as well as the
negotiation of it. on the TLS handshake.  That's it, that's all Yoav
wants to do, and it's all I want to do.

Since we're talking about an application feature, there's no need to
define a new record type.  Defining a new record type would only slow
things down.  HOWEVER, if we had N such features to piggy-back on the
TLS handshake in parallel, then we'd need some additional framing --
such framing would still not, IMO, rise to the level of a new record
type, but it would be desirable to standardize on such framing in one
place (TLS) than in many (one per-application protocol).  (I don't
think we'll have N>1 such extensions in use concurrently, and I don't
think it'd be a tragedy if we ended up with many such framing specs.)

[*] These exchanges do get integrity protection via the Finished
messages; they just don't get confidentiality protection unless they
are done in a the handshakes of TLS renegotiations.  The reason it's
safe to not provide the same level of protection to this feature as to
the rest of the application will almost always be because either a)
this feature negotiates features that are not security-sensitive
and/or b) this feature is an authentication feature distinct from, but
bound to, TLS.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Apr 2011 08:44:29 +0200

> after the EAP (or GSS, or SASL, or whatever) exchange completes.

One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is. After the handshake completes, the TLS library gives the server application an API to get the DN presented in the certificate that the client used. We would have liked to have a similar (or the same) API for password authentication. In other words, I don't want EAP, GSS or SASL to be implemented by the application, but by the infrastructure.

Having said that, a particular library can expose the same APIs to the application even if some of the records that it generates are "application data" records rather than handshake. The question of what kind of record carries the EAP and EAP-finished is independent of the question of separation between library and application.

> implementation that provides the necessary extensions hooks, and this

I'm not sure how the state machine is not changed just because the "Finished" message precedes the EAP. You still can't get real application data out before the EAP has concluded successfully, so the state machine has to account for that.

> we have a sad terminology issue :(

Some EAP methods, especially the good ones, have some random values in them, so they're protected against cut-and-paste. The security considerations should state why it's a good idea to use such methods.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 03 Apr 2011 23:59:56 -0700

Yoav Nir wrote:
> 
> One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is.

Forgive me if this is another stupid question, but have you
looked at the Secure Remote Password (SRP) cipher suites in
RFC 5054?

Mike

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Apr 2011 09:16:57 +0200

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.

-----Original Message-----
From: Michael D'Errico [mailto:[email-masked]] 
Sent: 04 April 2011 10:00
To: Yoav Nir
Cc: Nico Williams; Simon Josefsson; [email-masked]
Subject: Re: [TLS] EAP-in-TLS and channel bindings

> One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is.

Forgive me if this is another stupid question, but have you looked at the Secure Remote Password (SRP) cipher suites in RFC 5054?

Mike

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 02:26:12 -0500

> One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is. After the handshake completes, the TLS library gives the server applicat…

I understand the urge to make this transparent to TLS applications.
Nothing stops you from achieving that in spite of the protocol being
designed to as to not modify TLS proper.

That is, you could choose to implement your original approach, the one
that resembles mine, such that your TLS library does all the work
without the application having to know (though, of course, if you have
to prompt the user you'll need to find a way, and that might mean
having the application provide callback functions/closures for that
purpose, or you might prompt out of band via a pop-up dialog).

But in terms of not upsetting the TLS apple cart, the best way to
achieve that appears to be to follow an approach that makes no changes
to TLS proper.  I'm not sure that I agree that the TLS state machine
is so precious that it must be preserved at all costs -- I'm only
pointing out that this appears to be paramount to many people you'd
need to reach consensus.  I suspect that the TLS state machine is
important because assumptions about it are burned into some TLS API
designs, concentrators, ...  This is another reason to want standard
abstract APIs: so that actual APIs are designed to a pattern that
provides extensibility instead of leaving us stuck with an extremely
constraining set of TLS handshake patterns.

> Having said that, a particular library can expose the same APIs to the application even if some of the records that it generates are "application data" records rather than handshake. The question o…

Exactly!  I'm calling these additional messages "application
messages", but in fact they are perfect candidates for abstracting in
a common library, preferably the TLS library itself.

> I'm not sure how the state machine is not changed just because the "Finished" message precedes the EAP. You still can't get real application data out before the EAP has concluded successfully, so t…

Yeah, but not the TLS state machine.  Rather, the state machine of
your protocol.

> Some EAP methods, especially the good ones, have some random values in them, so they're protected against cut-and-paste. The security considerations should state why it's a good idea to use such me…

I'm not seeing that.  Let's say we have a client C, an MITM M, a
server S, and a AAA server A.  So we have C<->M<->S and C<=M<->S=>A.
M terminates a TLS connection to C and is the client of a TLS
connection to S, and M relays all other messages (including the TLS
extensions for carrying EAP messages) between C and S until the point
where the EAP exchange is complete, and then M closes the connection
to C.  From that point on M pretends to be the user authenticated by
EAP.

To prevent that attack we have to do something such as a) change the
keying of TLS, or b) demonstrate to C and S that they have the same
TLS connection.  We can't do (a) because you might not be able to
change keying until after some point in the EAP exchanges that is past
the TLS ChangeCipherSpec and Finished  message exchanges, and you
can't delay those TLS messages because you can't change the TLS state
machine.  That leaves you with (b).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 02:35:45 -0500

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

The principle I like to hold, regarding authentication
infrastructures, is this: we should enable you to use, in Internet
protocols, whatever authentication infrastructure you have already
deployed.  Corollary: we should not force anyone to deploy any
particular authentication infrastructure, much less N different ones
(one for each Internet protocol).  Some people have Kerberos
infrastructures, some have AAA, some have PKIX (and smartcards), some
have any two or all three of those; our protocols should work in all
those cases.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 02:42:08 -0500

> machine.  That leaves you with (b).

BTW, this is properly the province of RFC5056 channel binding.  That's
because you have a secure channel (TLS) and authentication above it
(EAP), and you want the channel to speak for the authenticated
parties, which is precisely what RFC5056 channel binding is all about.

Also, you should go look at ABFAB WG.  ABFAB is working on an
EAP-based mechanism for the GSS-API (they have much running code too,
so it's not pie in the sky).  Combined with
draft-williams-tls-sasl-opt, ABFAB would give you pretty much the same
exact thing you're trying to accomplish :)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 04 Apr 2011 11:45:21 +0200

Nico Williams <[email-masked]> writes:

> designs, concentrators, ... 

I'd wish I understood the argument against modifying the state machine
better.  As an implementer, I don't see any problem making the change.
As far as I understood EKR at the meeting, his concern was not based on
implementation arguments.

Still, given Nico's proposal, which does not affect the state machine,
it seems we could implement support SASL and probably also EAP in TLS
without state machine modifications.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Apr 2011 13:30:08 +0200

> implementation arguments.

Me neither

> without state machine modifications.

I don't know. If I call OpenSSL or GnuTLS or SChannel to perform a TLS handshake with password authentication, and it does the TLS handshake followed by an EAP exchange before returning to the application, then somewhere a state machine has changed. It doesn't really matter if the EAP messages are send as handshake records or "application data" records. Either way there has to be a state machine that takes care of requests and responses.

It may be that for some implementations it separates nicely into a TLS state machine, and then an EAP state machine, with some big state machine that controls how one state machine is used before the other. But this is not the case for all implementations, and it's not necessarily the cleanest way to implement this either.

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 07:35:33 -0500

Personally, I'd just modify TLS.  It may be that today attitudes have
changed regarding such changes.  A few years ago when Stefan was
pushing TLS-GSS there was a lot of resistance on state machine change
grounds -- at least as far as I recall, and that's what I based my I-D
and some of my comments on your proposal.  (The CB-related comments,
however, are not related to TLS change machince change resistance.)

BTW, by state machine I'm referring to the number of round-trips and
expectations of when the exchange is complete.  In SASL and the
GSS-API, for example, the state machine allows for a variable number
of round-trips -- applications should not assume any particular
number.  In TLS the number of round-trips has always been 1.5 or 2,
depending on context (session resumption vs. not).  This difference
means that one could have designed TLS APIs such that the addition of
round-trips could not be made without changing the applications that
use those APIs, but then the obvious thing to do is to not negotiate
state-machine-changing extensions to TLS when using such APIs.  So
I'll admit that I'm also baffled by the unchanging state machine
restriction; it may be that I just never understood it properly.

EKR?  Can you shed some light on this?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Apr 2011 07:56:42 -0700

> implementation arguments.

No, it's based on layer separation and cleanliness of protocol analysis.
TLS is a relatively straightforward protocol with a state machine which is
easy to analyze. (and there has been a huge amount of analysis on it)
and yet even so we got it partly wrong as the renegotiation issue shows.
Interlacing the TLS state machine with the EAP state
machine as you propose complicates it and makes analysis much harder.
As there's no compelling reason to do so, we shouldn't.

> without state machine modifications.

Agreed.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 04 Apr 2011 17:21:20 +0200

> As there's no compelling reason to do so, we shouldn't.

I doubt that the existing analysis of TLS would apply to such
a modification as EAP-TLS. Moreover there are so many EAP mechanisms
that an analysis of such a modification would not be possible for all
possible cases.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Apr 2011 08:34:23 -0700

> that an analysis of such a modification would not be possible for all

I certainly agree with this but that seems to me to be an argument for keeping these mechanisms separate and composing them with channel bindings

Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 04 Apr 2011 17:39:50 +0200

> I certainly agree with this but that seems to me to be an argument for keeping these mechanisms separate and composing them with channel bindings

Totally agree.

regards,
Nikos

---

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

> machine as you propose complicates it and makes analysis much harder.

OK, this is good.  It's not about round-trips, but about security
analysis.  In that case my approach to this problem is clean, or so I
hope you'd agree.  (In my approach the only "interlacing" is in the
form of channel binding, and everything else is just an optimization.
The only odd thing is the application protocol early start part, but
surely you don't think that's a big deal, right?)

>> without state machine modifications.

Is that an endorsement of my approach in draft-williams-tls-sasl-opt?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 11:25:29 -0500

> I certainly agree with this but that seems to me to be an argument for keeping these mechanisms separate and composing them with channel bindings

+1.  But note that composition via channel binding does not imply that
one cannot extend existing TLS implementations to do all this under
the covers.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Apr 2011 03:20:18 +0200 (MEST)

Eric Rescorla wrote:
> Simon Josefsson wrote:

The problem is that it hardly scales if everyone redefines the TLS
state machine to his liking.  In the first generation, folks modify
"the original state machine".  Then you want to use two such "enhancements"
and start wondering, how they intermix (since they're both defined
for the original state machine and not for use with "enhanced" state machines.

And the next time around that TLS WG itself wants to add handshake messages,
they have to address not only the original state machines, but also
all of the "enhancements", their interference with each other and
interference of the other enhancements with the new TLS WG enhancements.
That is going to be a pretty big mess.

> and yet even so we got it partly wrong as the renegotiation issue shows.

The renegotiation issue was more of an undocumented limitation of the
protocol where the apps folks (= the TLS callers) boldly assumed a
feature that didn't exist in TLS.  Retrofitting secure renegotiation
into the SSLv3&TLS protocol seemed like the most sensible approach
to fixing the issue.

-Martin