--On Thursday, May 28, 2009 07:08:42 PM -0700 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> wrote:
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
Ugh. This creates exactly the kind of geometric registration problem that Nico, I, and others find completely unacceptable. I can understand your desire to link negotiation of mechanisms and channel types, but this is not the way to do it. The SASL architecture is modular in nature; given a modular implementation a user can take an arbitrary SASL application protocol (possibly a private one you've never heard of) and an arbitrary mechanism (also possibly a private one you've never heard of) and use them together. Channel bindings should have the same property; it should be possible to construct an implementation where users can take any such combination, add an arbitrary channel binding type (including a private one you've never heard of), and use them together. And they shouldn't first have to register a SASL mechanism name in an IESG-controlled mechanism family (or any mechanism name) to do so.
Since I want users, administrators, or writers of SASL application protocol specifications to be able to specify use of an arbitrary channel binding type with SCRAM, I do not support use of a mechanism name which encodes a particular channel binding type. I do support a means of allowing the client to inform the server, within and secured by the mechanism, of which channel binding type is in use. I believe this provides sufficient flexibility not only to allow users, admins, and application protocols to do what they need, but also to allow later introduction of a negotiation mechanism with whatever properties we deem necessary.
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).
Yes, multi-level negotiation is to be avoided. A client must not be forced to choose SCRAM before it knows what channel binding types it will be able to use. For that reason I also do not support in-mechanism negotiation. However, I do support inclusion in the mechanism of a means of informing the server as to which channel binding type the client has selected, which opens the door for arbitrary means of selecting a channel binding type.
-- Jeff