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

[Nico Williams <[e-mail]>]

On Mon, Apr 11, 2011 at 1:00 PM, Yoav Nir <[e-mail]> wrote:
> On Apr 11, 2011, at 7:56 PM, Nico Williams wrote:
>>> 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.
>>
>> 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?
>
> 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.

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