Re: Poll: pure SCRAM versa SCRAM-as-GS2

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Thu Feb 19 16:02:18 2009, ned+ietf-sasl@xxxxxxxxxxx wrote:
> The real risk is that an overly complex mechanism will not deploy,  
> or if it
> does deploy, will fail to interoperate. We're coming to the party  
> very, very
> late with this, and even if we end up with as simple a mechanism as  
> we possibly
> can there's still a significant risk this whole thing is going to  
> go exactly
> nowhere.

I'd go so far as to say that actual complexity isn't as important for  
the purposes of deployment as perceived complexity. This ceased to be  
a technical issue some time ago (although there are minor technical  
issues). This is really just a marketing issue, and one that's  
important to address if we want deployment.

Unfortunately, I suspect most of this boils down to the name.

> > If I understand Nico's proposal on 2/17 correctly, it could  
> > simplify the
> > difference between auth-scram-09 and auth-scram-gs2 to just a blob  
> > at the
> > beginning of the first client message.  If it's possible to do  
> > that, then I
> > would support doing so.
>
> Frankly, this is what I was expecting to see in the current set of  
> drafts - the
> idea of reducing GS2 to an opaque blob has been mentioned many  
> times in the
> past. What I found instead was a significantly more complex  
> alternative.

I'd question whether the average developer is going to go as far as  
finding and reading the specification if the mechanism name is itself  
encrypted. This might sound flippant, and frankly it's hard not to  
make it sound that way, but it's a serious point - deployment isn't  
only about technical merit.

In any case, the key attraction for many operators isn't going to be  
that GSS-API and SASL share the mechanism, but that PLAIN and SCRAM  
can share a secure authentication database. If there's another  
mechanism, GSS-API based, that also shares this backend database,  
that'll no doubt please people who're offering GSS-API services  
alongside SASL services, but I honestly can't see that having wire  
compatibility is all that important by comparison.

Sure, it's a "nice if you can get it", but it ranks far, far below  
the shared authentication backend, which itself means that  
SCRAM-capable services can be deployed right now.

Right now, operators have to choose between storing plaintext  
passwords or require transmitting them, and when forced to choose,  
they appear to go for the latter. With SCRAM, they can deploy a  
SCRAM-style authentication database right now - it's probably very  
close to what they're already using in /etc/shadow or their  
hashed-passwords DSA - they can use it for PLAIN for existing  
clients, and offer SCRAM, and client developers will see SCRAM  
advertised, and implement it because it's simple enough.

So, my conclusion from this is actually very positive - we can have a  
native SASL SCRAM-HMAC-* family, a backend-compatible GSS-API SCRAM  
family, a document describing how to make PLAIN (and XEP-0078, IMAP  
LOGIN, X.509 Simple Authentication, POP3 USER/PASS, FTP, /bin/login  
etc) authenticate against the same backend, and actually have real  
deployment in services now.

On the other hand, if we choose a solution that appears more complex,  
I'm concerned that the result will be that we never get the momentum.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade