Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Fri, May 29, 2009 at 08:29:42PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
> 
> > After much discussion with Jeff H. and, separately, Sam H., I think the
> > following proposal is likely to be simple enough to garner consensus and
> > yet flexible enough to let us adapt to future conditions.  The proposal:
> 
> Nico convinced me about this proposal in jabber, and we fleshed out the
> changes that will be needed in GS2 to implement this.  This has to be
> reflected in SCRAM as well.  The changes can be summarized into:
> 
> 1) Add text to say that with 'p' one cb type name is included (normally
> tls-unique)
> 
> 2) Add text to say that with 'y' a list of cb type names supported by
> the client is included

Both, 1 and 2 refer to that new GS2 header field that I mentioned.  And
both 1 and 2 are there to:

a) facilitate the future addition of channel binding type negotiation
   using any one of the three sketches so far (Jeff's pseudo-mech,
   Simon/Kurt's N*M mech names, or my N+M mech names),

and

b) provide for downgrade detection should we ever add channel binding
   type negotiation.

> 3) Add text to say that if a server doesn't understand the cb type,
> authentication fails.

That's not strictly needed: whatever the server does at that point
authentication necessarily must fail :)

> 4) The text from Nico's e-mail (clients and servers MUST support
> tls-unique, clients SHOULD choose tls-unique, ...)

Yup, as modified by Jeff's reply to my post.

> I have converted the above into text changes for GS2, and you can review
> the result in:
> 
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html
> 
> The diff against -13 is in:
> 
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--13.diff.html

The main comment I have is that section 5.1 needs to claim the default
channel binding type agreement as being the default for _SASL application
protocols_, and explicitly allow SASL app protocols to specify a
different agreement.

Also, I like your ABNF.  I had in mind using something like t=<type> and
t=<type>[:<type>[:...]], but your approach strikes me as better.

Finally, you need to add references to the channel binding type
registrations.

> Check the examples, they are updated and hopefully give you a quick idea
> of how the protocol will look like.
> 
> Thoughts?

Awesome.  Thanks!

Alexey, can you adapt Simon's changes to GS2 to SCRAM?

Nico
--