Re: Poll: use of TLS channel bindings in SCRAM

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Jeffrey Hutzelman <jhutz@xxxxxxx> writes:

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

Indeed.  I'll not discuss cb nego more, since my hope is that we won't
have to solve that particular problem (thanks to the recent compromise
proposal!), and that this part of the discussion will have only been a
large rat hole.  But one comment.

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

I think there is something critically missing from this elaboration:
Even though there can be theoretically up to 36 names, or possibly
hundreds, or thousands, I believe that does not matter in practice.

In practice, for any particular server, only a few set of combinations
will be useful.  The set of practically useful combinations are much
more limited than the N*M figure suggests.

There is a one step in getting a combination of a SASL mechanism and a
channel binding type approved: the IANA allocation of the SCRAM-CB-FOO
name.  The naming scheme could be implemented to happen automatically
(like the hashed GS2 names), but I believe there is some point in having
a manual process to register each and every SCRAM-IPSEC-FOO,
SCRAM-TLS-BAR combination: it makes us have to think about the security
properties of each particular combination of mechanism with channel
binding.

We have already seen that YAP have different properties than SCRAM when
used with tls-server-end-point.  That can be true generally.  It seems
like a mistake to not think about each particular combination.

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

A much better strategy is the manual registration step I mentioned
above.  So let's say there is SCRAM and some new channel binding called
ipsec-verylongword-anotherlongword-certificate-foobar.  The combination
of those two can be registered as SCRAM-FOOBAR in the IANA registry,
after having considered whether that combination of SASL mechanism and
channel binding is a reasonable one.

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

Hear, hear.

/Simon