[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Poll: use of TLS channel bindings in SCRAM Nicolas Williams Fri May 29 09:01:43 2009

On Fri, May 29, 2009 at 09:21:27AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[EMAIL PROTECTED]> writes:
> > Note that there's no reference to tls-server-end-point in the above
> > proposal.  And notice that the server knows what channel binding type
> > the client chose.
> That would work, but I'm not sure it is required.  I don't see what
> advantage that gives over the current situation of not sending the
> channel binding type and specifying that tls-unique (or
> tls-server-end-point) should be used?

First, we do send the channel binding type _now_, just not on the
"outside" (from the GSS-API perspective), where we actually need it.

The reason we need the channel binding type on the "outside" is this:
suppose we've added channel binding type negotiation and a server
supports multiple channel binding types, then how is the server to know
which channel binding type the client chose?  One answer would be:
through the name of the mechanism that the client chose -- but this gets
us into the N*M mechanism name registration issue.  A better answer is
to just put the channel binding type in the GS2 header, then the server
can just inspect that.

> > The sum total changes to SCRAM/GS2 would be:
> >
> >  - New text to describe the default channel binding type agreement
> >    process.
> >
> >  - New text and ABNF to describe the new GS2 header field.
> >
> > Comments?
> For the negotiation, I prefer the scheme with explicit channel binding
> type negotiation in the mechanism name:
>       SCRAM-SHA-1  (no channel binding)

I will not agree to that.  I've already explained that an N*M mechanism
name registration problem is unacceptable.  I can't imagine why you'd
find it acceptable.  Perhaps you think that M will never exceed 2?

> (of course the names have to be changed to fit within the 20 character
> limits)

That's an exceedingly obnoxious aspect of this problem.

> This approach appears simpler and more robust than either yours or
> Jeff's schemes, if I understand them all correctly.

I don't agree.

> My reasons against Jeff's scheme is that an additional round-trip is
> performance costly and adds implementation complexity, and it is easily
> avoidable.  Your scheme assumes that all mechanisms wants to use the
> same channel binding negotiation approach, which I think can't be
> assumed at this point.  I also think your approach fits badly with how
> SASL mechanism negotiation are handled in some implementations, which is
> a subjective opinion.

You mischaracterize my scheme for the future addition of cbinding type
nego.  It gives the client all the information it needs to select a
suitable {mechanism, channel binding type}, without any additional
round-trips.  Given that information it is possible to pick a
{mechanism, channel binding type} in a way that takes into account a)
availability of user credentials for the mechanism, b) client/user
mechanism preference, c) mechanism dependence/ non-dependence on unique
channel bindings.

The only problem with my scheme is that applications that don't use a
SASL framework have to implement the {mechanism, channel binding type}
selection algorithm themselves -- a bit of pain, but nowadays there's a
variety of SASL framework implementations, and most apps that I'm aware
of use one.