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

[Yoav Nir <[e-mail]>]

On Apr 4, 2011, at 7:36 AM, 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.

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.

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

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.

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

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.

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