[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll: use of TLS channel bindings in SCRAM



On May 29, 2009, at 8:42 AM, Nicolas Williams wrote:



On Fri, May 29, 2009 at 09:21:27AM +0200, Simon Josefsson wrote:

Nicolas Williams <Nicolas.Williams@xxxxxxx> 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)
	SCRAM-SHA-1-TLS-UNIQUE
	SCRAM-SHA-1-TLS-SERVER-END-POINT
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?
What I don't find acceptable is any assumption that applicability of any particular channel binding type is the same for all mechanisms used within a particular application layer protocol. Hence, I want negotiation which allows the server to say which channel binding types it willing to support on a per mechanism basis.
As for as the N*M problem, I think N and M are relatively small numbers and hence N*M doesn't concern me significantly.
Also, I don't this as creating an N*M registration issue. N and M values can be registered separately. All a mechanism spec needs to do is register SCRAM-SHA-1-* and state that * is to replaced by a value from the channel binding table, mapped to upper case, etc. (see below).
(of course the names have to be changed to fit within the 20 character 
limits)


That's an exceedingly obnoxious aspect of this problem.
Yes, I had once suggested to grow the limit but was in the rough. TLS- SERVER-END-POINT by itself is 20 characters. One might use instead TSEP (we could register "short names" in the IANA table) or use a hash (which nobody is terribly fond of). The etc. above needs to deal with this.
Though I dislike multiple levels of negotiation, I rather have multiple levels of negotiation which was not per mechanism.
So, I guess my second preference might be some in-the-mechanism exchange negotiation mechanism. 

-- Kurt