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

[Nico Williams <[e-mail]>]

On Mon, Apr 4, 2011 at 2:26 AM, Nico Williams <[e-mail]> wrote:
> On Mon, Apr 4, 2011 at 1:44 AM, Yoav Nir <[e-mail]> wrote:
>>> 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 :(
>>
>> 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.
>
> 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).

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