Re: Poll: use of TLS channel bindings in SCRAM

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> 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.

Right.  This isn't explicit in the GS2 document now, but I'm not sure it
has to be.

>> 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 :)

Well, some guidance what should happen is needed.  Server's certainly
shouldn't accept the authentication attempt.

>> 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.

Yes.

>> 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.

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>

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?

> 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,...

However I didn't want to make unrelated changes at this point.

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

I'm not sure.

Thoughts?

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

Done.

/Simon