[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Poll: pure SCRAM versa SCRAM-as-GS2
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
late with this, and even if we end up with as simple a mechanism as
can there's still a significant risk this whole thing is going to
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
difference between auth-scram-09 and auth-scram-gs2 to just a blob
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
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 Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade