Re: Poll: use of TLS channel bindings in SCRAM

[Jeffrey Hutzelman <jhutz@xxxxxxx>]

--On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga 
<Kurt.Zeilenga@xxxxxxxxx> wrote:

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

Yup, I think we all understand that; we just don't all agree with it, or 
think it's compelling enough to override the M*N concern.  However, the 
beauty of the current proposal is that it doesn't require us to select a 
negotiation strategy now; instead it gives us, or application protocol 
designers, or users, the flexiblity to select from among a variety of 
strategies.

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

Yeah, the problem is that you believe that N and M are small numbers today, 
and assume that therefore they always will be.  Let's look at that 
assumption...

Assume N is the number of mechanisms, and M is the number of CB types.

With a strategy like Nico's, every mechanism needs 2 names (and maybe a 
third, depending on when we add negotiation and how we signal support for 
it).  Every CB type needs one name.  So you end up with 2N+M names.

With a strategy like mine, every mechanism needs 2 names (possibly only 
one, but adding negotiation later requires that two exist), every CB type 
needs one name, and you need one for the negotiation pseudo-mechanism.  So, 
you end up with 2N+M+1 names.

With a strategy like yours, every mechanism needs M+1 names (including one 
for "no channel bindings"), so you end up with N*(M+1) or N*M+N names.

Now, let's look at what N and M are.

Today, we're talking about SCRAM, and maybe GS2-KRB5, and maybe YAP.
So for the moment we have N=3.

Today, we're talking about tls-unique and tls-server-end-point.  We'll 
ignore tls-unique-for-telnet, which has limited applicability, and the 
mythical tls-client-end-point and tls-dual-end-point bindings, which I 
think we all agree are not that interesting to SASL.  So suppose M=2.

Fine.  Then we have these numbers:
Nico: 2N+M   = 6+2   = 8
Jeff: 2N+M+1 = 6+2+1 = 9
Kurt: N*M+N  = 6+3   = 9

So it's not so bad, when N and M are both small.  However, as you know, as 
those parameters grow, the _order_ of complexity is much more important 
than the constant factors.  Let's see what happens in a couple of years...

- Instead of considering just SCRAM, GS2-KRB5, and YAP, let's also consider
 GS2-SPKM3, GS2-PKU2U, and GS2-IAKERB, all of which are likely to see
 deployment in the next few years.  Now N=6.

- Instead of considering just tls-unique and tls-server-end-point, let's
 consider some other channel types that are not terribly unlikely, such
 as ipsec-dual-end-point (certs from both sides, or whatever), ssh-unique
 (based on the exchange hash), and ssh-server-end-point (using the server
 host key).  Now M=5.

Nico: 2N+M   = 12+5   = 17
Jeff: 2N+M+1 = 12+5+1 = 18
Kurt: N*M+N  = 30+6   = 36

Worse, the first user who wants to use SCRAM with ssh-unique is going to 
have to figure out enough about our process to register it.

Even worse, these are _very_ conservative estimates for N.  With GS2, we 
can use virtually any GSS-API mechanism.  Many of those are proprietary and 
will never be seen outside the enterprise(s) in which they are used.  Ask 
Martin Rex someday about the number of GSS-API mechanisms he's seen; he has 
plenty of experience helping customers build GSS-API mechanisms so they can 
use their enterprise authentication infrastructure with his product.

With M=5, every new mechanism adds 6 new mechanism names.


> Also, I don't this as creating an N*M registration issue.  N and M values
> can be registered separately.

Right up until the point where you realize that SASL allows N names to be 
up to 20 characters long, and RFC5056 places _no_ limit on names (but the 
existing registrations are 10, 20, and 21 characters long), and yet SASL 
application protocols may only allow for mechanism names up to 20 
characters long, because SASL says they won't be any longer.

I suppose you could hash both the SASL mech name and channel binding name, 
and come up with a combined string that's not longer than 20 characters, 
but then you will get pushback from the same people who complained about 
hash-based names in GS2.  Weren't you one of those?


> Though I dislike multiple levels of negotiation, I rather have multiple
> levels of negotiation which was not per mechanism.

I'm afraid I can't parse this.  Can you try again?




In any case, I strongly prefer that GS2 and SCRAM not lock us into a 
particular negotiation model, and instead allow the flexibility to choose 
from among a variety of models later, if/when we determine thet negotiation 
is actually needed, and in the meantime allow users and SASL application 
protocol designers the flexibility to choose the meechanisms and channel 
binding types they need.

-- Jeff