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

[Nico Williams <[e-mail]>]

On Sat, Apr 2, 2011 at 1:00 PM, Yoav Nir <[e-mail]> wrote:
> Thanks for this. One of our earlier versions of our proposal looked like this:
>
> [...]
>
> 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.

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

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