Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Fri, May 29, 2009 at 10:59:17PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
> > Both, 1 and 2 refer to that new GS2 header field that I mentioned.  And
> > both 1 and 2 are there to:
> 
> Right.  This isn't explicit in the GS2 document now, but I'm not sure it
> has to be.

Right -- I just wanted to clarify for the WG.

> I've changed the first paragraph to:
> 
> 	      <t>A default channel binding type agreement process for
> 		all SASL application protocols that do not provide
> 		their own channel binding type agreement is provided
> 		as follows.</t>

Perfect.

> However this seems somewhat restrictive, since it may be read to suggest
> that negotiation cannot happen at other levels.  But I can't come up
> with better text.  Suggestions?

No, I think the above is fine.

> > 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.
> 
> I'm glad you like it.  I'm not entirely happy with it: you can't parse
> it using a var[=value] parser, you need to inspect the string character
> by character in the beginning.  One alternative would be (compare with
> the examples in the document):
> 
> Example #1: n,a=someuser,...
> Example #2: n,...
> Example #3: F,n,...
> Example #4: p=tls-unique,a=someuser,...
> Example #5: p=tls-unique,...
> Example #6: p=tls-server-end-point,...
> Example #7: y=tls-unique:tls-server-end-point,a=someuser,...

That's fine too.

> Also, that SCRAM uses var[=value] doesn't mean GS2 needs to.

True, but GS2 already does (a=<authzid>).

Nico
--