Re: Poll: use of TLS channel bindings in SCRAM

[Jeffrey Hutzelman <jhutz@xxxxxxx>]

--On Thursday, May 28, 2009 06:35:16 PM -0500 Nicolas Williams 
<Nicolas.Williams@xxxxxxx> wrote:

> On Thu, May 28, 2009 at 10:49:03PM +0100, Alexey Melnikov wrote:
> > 1). SCRAM should just use a single allowed TLS channel binding and don't
> > have any negotiation of other TLS channel bindings (*) (**)
> > a). the default is tls-unique
> > b). the default is tls-server-end-point
> > 2). SCRAM should just use tls-server-end-point, fallback to tls-unique,
> > no negotiation of other TLS channel bindings (*)
> > 3). SCRAM should always use channel binding negotiation (*)
> > 4). SCRAM should have a default TLS channel binding with optional
> > negotiation of TLS channel bindings (*)
> > a). the default is tls-unique
> > b). the default is
> > 5). I have another opinion [this is for the case when there is some
> > valid choice which you think should be considered by the WG]
>
> (1a) future-proofed would be my preferred approach.  I.e., (1a) with the
> '**' details filled out.

Mine as well.  Particularly, I think we're trying to achieve the following:

- Maximum interoperability without compromising security
- Not too painful to implement, for clients or servers
- Not define negotiaton now, but...
- Leave the door open to define negotiation later or...
- Let SASL application protocols define negotation or...
- Let users/administrators select channels and CB types

To that end, I think the things we have to do now are define a way for 
GS2/SCRAM to carry information about what CB type is in use, and specify a 
default behavior in the absence of guidance from the user, application 
protocol specification, or an as-yet-undefined negotiation mechanism.

I can imagine a number of ways to define negotiation in the future, 
including both some that negotiate mechanism and CB type separately and 
some that link them.  Nico and I have worked through one possible 
negotiation strategy in each of those categories and convinced ourselves 
that each approach can be defined in the future without impacting 
GS2/SCRAM, provided we add the header field Nico describes below (we also 
designed an extension to TCP, but you don't care about that).

If we're going to have a single default, that should be tls-unique.


I'm also OK with (2), future-proofed in the same way as (1a), but Nico 
makes an argument that tls-server-end-point may be dangerous given the 
possibility of GSS-API mechanisms which depend on unique channel bindings. 
I'll accept that argument for now, but I think that such dependencies 
should be discouraged at the GSS-API layer, since the GSS-API imposes no 
requirement that callers use unique channel bindings or in fact any at all. 
But that's probably a discussion for kitten.

I'd be OK with (4a), but like Nico, I don't feel it's worthwhile to specify 
a negotiation mechanism now.  In practice, it's going to be some time 
before there are SASL application protocols which care about channel types 
other than TLS, and if we're deciding that TLS endpoint bindings are unsafe 
and/or not worthwhile, then we're unlikely to need a binding type for TLS 
other than tls-unique any time soon.  For similar reasons, (3) seems not 
worth doing.


Like Nico, I believe that (1b) is unacceptable since tls-server-end-point 
may not always work.



> I believe we can do this by adding a field to the GS2 header that would
> be present *only* when the channel binding type used is not the default
> one.  Since this would not materially change SCRAM/GS2, I believe this
> would be the ideal solution.

I'm fine with this approach, or with adding a field which is always present 
when channel bindings are in use.

I believe Nico is writing up a concrete proposal which builds on what he's 
already said and on the goals I mention above.

-- Jeff