Re: Poll: use of TLS channel bindings in SCRAM

[Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx>]

My current view is that channel binding type (tls-unique v. tls-server- 
end-point v. other types (whether other TLS types or non-TLS types)  
for SCRAM be accomplished through SASL mechanism negotiation.   
Specifically, I prefer the I-D to define a set of mechanism variants,  
possibly open ended to allow for future channel binding types, that  
allow, in addition to hash function, the channel binding type to be  
advertise by the server (in supporting application protocols) and  
selected by the client.  Specifically, I recommend names such as:
	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE
	SCRAM-SHA-1-TLS-SERVER-END-POINT

I do not support advertisement of pseudo mechanism names as this  
presumes the security applicability of all present and future channel  
binding types when used in all present and future SASL mechanisms with  
all present and future application problems is the same.  I argue that  
the security characteristics of each channel binding types,  
mechanisms, and protocol differ significantly enough that it  
reasonable that application protocol server implementor or deployer  
might reasonable want to place restrictions on which channel binding  
types are available on a per mechanism basis.

I do not support in SCRAM exchange negotiation as this tends to lead  
to interoperability problems (client asks to SCRAM, server offers a  
channel binding types the client is not willing to use, must abort the  
exchange, possibly having to reconnect, to try some other mechanisms).

That is, while I favor 3 but only if a negotiation is via names of the  
variants of the SCRAM mechanism.  So I guess I rather call this 5 as I  
rather my comments be take as supporting the other forms of negotiation.

The only other option I think I could support is defining only:
	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE

Under this option (basically 1a), I would not use the PLUS name for  
SCRAM-SHA-1-TLS-UNIQUE (or SCRAM-SHA-1-TLS-SERVER-END-POINT or other  
name restricted to a specific channel binding type) to encourage  
"meaningful" names of additional variants that could be subsequently  
introduced.  That is, I think the PLUS name in more suitable for the  
two options above that I do not support.

-- Kurt, as a WG participant


On May 28, 2009, at 2:49 PM, Alexey Melnikov wrote:

> I've discussed channel bindings with Nico in jabber and we agreed  
> that we need to get WG consensus on how TLS channel bindings should  
> be used with SCRAM.
> Please provide an orded list of alternatives you find acceptable  
> from the choices listed below. (Please restrict discussions of  
> variants of these choices at the moment. I will do another poll on  
> such choices later, depending on the outcome of this poll. Also,  
> please read notes for the choices before answering). Please answer  
> the poll by the end of June 7th.
>
> 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]
>
> Notes:
> (*) - whether such negotiation happens inside or outside of SCRAM
> (**) - channel binding negotiation can be added later on