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

[Michael D'Errico <[e-mail]>]

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



Nico Williams wrote:
> 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