Re: New GS2 design -- much simplified, and simplified SCRAM

[ned+ietf-sasl@xxxxxxxxxxx]

> On Mon, Feb 23, 2009 at 10:40:05AM +0000, Dave Cridland wrote:
> > On Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> > >extended GSS-API mechanism inquiry becomes widely implemented.
> > >Pretty
> > >SASL mechnames would just be icing on the cake though -- the other
> > >issues are far more important.
> >
> > Then you misunderstand the reality of the situation - I'm afraid that
> > whatever you might wish for, the reality is that the name is
> > crucially important. I'm finding myself struggling to see where the
> > incomprehension stems from.

> I don't see why the particular bits that appear on the wire as
> "mechanism name" are all that important -- that's what I was talking
> about.

> The *actual* mechanism name -- the name by which we know it in
> conversations, e-mails, documentation, ... -- that matters greatly.

> Does that resolve the conflict?  Or did you really mean that the bits
> that appear on the wire as "mechanism name" are greatly important?

'm afraid Dave really does mean that. And while I'm not quite as adamant about
the urgency of being able to advertise comprehensible mechanism on the wire as
Dave is, I do agree that having incomprehensible ones is a barrier to
deployment. And given how unlikely this is to deploy at this late date so
matter what we do, such barriers need to be removed if at all possible.

> > I strongly suspect that if a bespoke implementor finds GS2 before
> > they find SCRAM they'll give up at that point irregardless of how
> > simple the mechanism is. I'm not even convinced that most developers,

> Which is why we want a SCRAM-as-GS2-but0described-as-pure-SASL document.

> > faced with a mechanism name consisting of random characters, will
> > even look up a specification. To get these developers to read and
> > implement the specification, the mechanism needs to be not only
> > simple, but seen to be simple.

> But I don't think they'll be faced with "a mechanism name consisting of
> random characters" (besides the fact that they are only random-looking
> :)

They will in the case of someone examining the output of what mechanisms a
particular server offers.

> The fact is that when customers request support for SCRAM they won't
> say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
> sort.

Of course not. But this is entirely beside the point.

> > Even if they get as far as reading the spec, most client authors will
> > probably decide to do what I did, which is to interrogate the hash
> > library as to what hashes I have available and look for mechanism
> > names. This approach to hash agility is handy, in as much as with
> > GS2, it won't require me to perform a preimage attack on the
> > mechanism name, however it has the disadvantage that with GS2's
> > cryptographically secure names [I'm told I shouldn't call them
> > encrypted] I have to implement a DER encoder (at least for OIDs).

> Not really.  I've seen DER-encoded OIDs hardcoded in C source plenty.

> > And, perhaps more tellingly, I cannot be bothered to do this -

> You don't have to be.  The name is effectively constant and so can just
> be hardcoded, just as you'd hardcode the name if it weren't
> random-looking.

> > Which means hash agility is actually harmed, and yes, it really is

> This is NOT about hash agility.

> > On a more positive note, I'm firmly convinced that wire
> > interoperability between GSS-API and "native" SASL mechanisms is so
> > unimportant as to be a waste of time to persue. I never did
> > understand the argument that we should somehow retire SASL to
> > increase wire compatibility between protocols which are
> > wire-incompatible.

> Do you support or have you deployed GSS-API and SASL based applications?
> I do/have.

I've supported and deployed multiple SASL-based applications. I have attempted
to do GSS-API stuff on a couple of occasions but have never been successful.

> I find the inability to use the same authentication
> infrastructures in a variety of application protocols to be a serious
> issue.  This is not about retiring SASL!  This is about getting
> commonality of mechanisms.

That's your goal. My goal is different: I want a mechanism that's capable of
actually deploying into the application clients and servers I'm interested in,
including but not limited to assorted email protocols, XMPP, and calendar. All
the commonality of mechanism in the universe doesn't mean squat to me if nobody
bothers to add support for either one, which is the likely outcome unless we
hammer every last bit of unnecessary obscurity and complexity out of this.

> > I can tell this issue of wire-compatibility is important to you, but

> Actually, it's not at all.  There is no wire compatibility in this case.
> That was never the point.  The point is re-use.

Not to be catty or anything, but use has to preceed re-use.

				Ned