--On Friday, May 29, 2009 10:42:09 AM -0500 Nicolas Williams <Nicolas.Williams@xxxxxxx> 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.
That is, it _locks_ us into the N*M registration issue, forcing a particular negotiation strategy, instead of letting us decide later or allowing a user to decide on a whim that he wants to bind to an ssh channel.
A better answer is to just put the channel binding type in the GS2 header, then the server can just inspect that.
Which allows us to defer indefinitely the question of exactly how negotiation should be done, if at all.
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-POINTI 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?
Nor will I.A negotiation scheme involving separately registering every combination of choices from multiple levels is not acceptable to me. It breaks modularity and restricts users to using supposedly orthogonal pieces only in combinations which someone else has decided are acceptable, and that is not OK. As an operator, I believe that the right to set policy, including what mechanisms and what channel bindings are used, belongs entirely to me, and not to some implementor or protocol designer or IANA. SASL is designed to make it possible for application implementers to give me that flexibility with respect to mechanisms; why would I want it to tie my hands with respect to choice of channel bindings?
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.
What it doesn't give the client is information about what combinations of mechanisms and channel bindings can be used. But that's OK, because these components are not used "in combination" they are orghogonal. The interface between them is about as simple as it gets -- channel bindings are opaque data, and the mechanism carries and integrity-protects that data without making any assumptions about what is inside it. Any mechanism can carry any opaque blob of binary data; the security of the mechanism is not affected by what that data is, and the security of the channel binding is affected only by the mechanism's ability to provide integrity protection on that blob of data. Neither is affected by any interactions between the mechanism and channel binding type, because neither of those makes any assuptions about the other.
That said, I'm really not interested in debating the merits of various possible negotiation schemes. The entire point of the small change we're proposing to GS2/SCRAM is to avoid having to hold up those mechanisms for that debate, when in reality the debate is mostly moot because we're unlikely to see enough widespread use of binding types other than TLS-UNIQUE to make defining a negotiation mechanism worthwhile, especially given that users and administrators are already used to configuring everything manually if they want any behavior other than PLAIN over TLS without server certificate validation.
-- Jeff