Re: SCRAM authentication, take three

On 07/04/17 11:05, Magnus Hagander wrote:
> On Fri, Apr 7, 2017 at 9:59 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi
> <mailto:hlinnaka(at)iki(dot)fi>> wrote:
>
> On 04/07/2017 10:38 AM, Magnus Hagander wrote:
>
> So here's a wild idea. What if we just call it "sha256"? Does
> the user
> actually care about it being scram, or is scram just an
> implementation
> detail for them? That way when the next one shows up, it'll be
> sha512 or
> whatever. It happens to use scram under the hood, but does the
> user have to
> or does the user want to care about that?
>
> (One could argue the same way that the user shouldn't have to
> or want to
> care about the hashing algorithm -- but if that's the case
> then we should
> only have one entry, it would be "scram", and the system would
> decide from
> there. And I think this discussion already indicates we don't
> think this is
> enough)
>
>
> I think the "SCRAM" part is more important than "SHA-256", so -1
> on that.
>
>
> If that is the important part, then I agree :) I am not entirely sure
> that the scram part *is* more important though.

I agree it is much more important. Needed, I'd say. "SHA-256" could
refer to other mechanisms that just simply hash the value (maybe with a
salt, or not) with that hash algorithm. SCRAM is a different beast, with
much more functionality than that. So yes, it matters a lot :)

>
> I think most users will be a lot more comfortable with "sha256" than
> "scram" though. But I guess that says using scram-sha-256 is the
> correct way.

I don't like UPPERCASE, but the RFC links to the IANA registry
where SCRAM methods are all uppercase and with dashes: SCRAM-SHA-256 and
SCRAM-SHA-256-PLUS. I'd use those names, they are standardized.

>
> The main against using just "scram" is that it's misleading,
> because we implement SCRAM-SHA-256, rather than SCRAM-SHA-1, which
> was the first SCRAM mechanism, commonly called just SCRAM. As long
> as that's the only SCRAM variant we have, that's not too bad, but
> it becomes more confusing if we ever implement SCRAM-SHA-512 or
> SCRAM-something-else in the future. That's the point Noah made,
> and it's a fair point, but the question is whether we consider
> that to be more important than having a short name for what we
> have now.
>
>
> Yeah, I agree we should be prepared for the future. And having "scram"
> and "scram-sha-512" would definitely fall under confusing.
>
> The channel binding aspect is actually more important to think
> about right
> now, as that we will hopefully implement in the next release
> or two.
>
> In [1], Michael wrote:
>
> There is also the channel binding to think about... So we
> could have a
> list of keywords perhaps associated with SASL? Imagine for
> example:
> sasl $algo,$channel_binding
> Giving potentially:
> sasl scram_sha256
> sasl scram_sha256,channel
> sasl scram_sha512
> sasl scram_sha512,channel
> In the case of the patch of this thread just the first
> entry would
> make sense, once channel binding support is added a second
> keyword/option could be added. And there are of course
> other methods
> that could replace SCRAM..
>
>
> It should also be possible to somehow specify "use channel
> binding, if the
> client supports it".
>
>
> Is that really a type of authentication? We already hvae the idea of
> authentication method options, used for most other things except
> md5 which
> doesn't have any. So it could be "sha256 channelbind=on", "sha256
> channelbind=off" or "sha256 channelbind=negotiate" or something
> like that?
>
>
> > Technically, the channel-binding variant is a separate SASL
> mechanism, i.e. it has a separate name, SCRAM-SHA-256-PLUS. I'm not
> sure if > users/admins think of it that way.
>
>
> I bet they don't.

Probably. But let's not underestimate channel binding: it is the
"greatest" feature of SCRAM, and where security really shines. I'd
encourage the use of channel binding and would definitely make it explicit.

As for the options, there's no way to negotiate, the client picks.
It could still be three-valued: on, off, only-channel-binding (or
however you want to call them). That will only change what mechanisms
the server will be advertising to clients.

Álvaro

--

Álvaro Hernández Tortosa

-----------
<8K>data