Ejabberd: [SCRAM] SCRAM-SHA-1-PLUS + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) supports

Created on 30 Dec 2018 · 21Comments · Source: processone/ejabberd

To have compatibility with XMPP Servers and after:

SCRAM-SHA-1

Can you add supports of :

SCRAM-SHA-1-PLUS
SCRAM-SHA-224
SCRAM-SHA-224-PLUS
SCRAM-SHA-256
SCRAM-SHA-256-PLUS
SCRAM-SHA-384
SCRAM-SHA-384-PLUS
SCRAM-SHA-512
SCRAM-SHA-512-PLUS
SCRAM-SHA3-512
SCRAM-SHA3-512-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

SCRAM-SHA-1(-PLUS):
-- https://tools.ietf.org/html/rfc5802
-- https://tools.ietf.org/html/rfc6120
SCRAM-SHA-256(-PLUS):
-- https://tools.ietf.org/html/rfc7677 since 2015-11-02
-- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA
SCRAM-SHA-512(-PLUS):
-- https://tools.ietf.org/html/draft-melnikov-scram-sha-512
SCRAM-SHA3-512(-PLUS):
-- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
Channel Bindings for SCRAM over TLS 1.3: https://tools.ietf.org/html/draft-whited-tls-channel-bindings-for-tls13 -> https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13

LDAP:

RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://tools.ietf.org/html/draft-melnikov-scram-2fa

IANA:

Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Note, after SCRAM-SHA-1(-PLUS):

GNU SASL (gsasl) supports SCRAM-SHA-256(-PLUS) since 1.9.1: http://git.savannah.gnu.org/gitweb/?p=gsasl.git;a=blob;f=NEWS;hb=HEAD
I have informed about missing informations in website/manual/docs.
Dovecot supports SCRAM-SHA-256(-PLUS) since 2.3.10: https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/
Cyrus SASL/IMAP supports SCRAM-SHA-256(-PLUS) and more since 2.1.27: https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html
...

Linked to:

https://github.com/scram-xmpp/info/issues/1

Source

Neustradamus

All 21 comments

On and on this goes. They invent new SCRAM every year (without clear migration path) and we should implement this every time? Why?

zinid on 4 Jan 2019

@stpeter who works on it: https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid.

IANA: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

State of Play: https://github.com/scram-xmpp/info/issues/1

EDIT: @stpeter has done a good job, RFC8600 is official: https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA.

Neustradamus on 4 Jan 2019

So, let's say I created a password with SCRAM-SHA-512, but my another client only supports SCRAM-SHA-1, then what to do?

zinid on 4 Jan 2019

XMPP client devs must to update the software... ^^
The user will do the best choice :)

Neustradamus on 4 Jan 2019

Yeah, sure.

zinid on 4 Jan 2019

Can you reopen the ticket?
There are a lot of informations now ^^

Neustradamus on 6 Jan 2019

What information?
You still don't answer my main question about migration path.

zinid on 6 Jan 2019

For information: https://crypto.stackexchange.com/questions/66195/what-is-the-use-of-scram-sha-256-over-scram-sha-1

Neustradamus on 18 Jan 2019

😕1

More details for Tigase 8.0.0+:

For a new install in 8.0.0, and by default, a password is saved to SCRAM-SHA-1 and SCRAM-SHA-256.
There is an option if we want to use PLAIN -> PLAIN/SHA-1/SHA-256.
For a migration to 8.0.0, there is an option to keep PLAIN, if enabled, there will be PLAIN/SHA-1/SHA-256.

In more for Tigase 8.0.1+:

With 8.0.1 and 8.1.0, there will be in more PLAIN (if enabled), SCRAM-SHA-1 and SCRAM-SHA-256, an option to enable SCRAM-SHA-512.

Of course, -PLUS variant work without any problems for all.

If the password was in SCRAM-SHA-1 before a migration and if we want to have SCRAM-SHA-256 (and other), a reset all passwords is needed.
Of course, it is possible to disable SCRAM-SHA-1 and/or SCRAM-SHA-256 too.

Neustradamus on 21 Mar 2019

@Neustradamus how is information about Tigase relevant in this bug tracker?

zinid on 21 Mar 2019

It is the solution for launch improvements of the missing part in ejabberd :)

Neustradamus on 21 Mar 2019

Any news on it?

The new RFC has been published by @stpeter: https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA.

Neustradamus on 21 Aug 2019

Goog news, there is a best article to convert old unsecured MD5 passwords to SCRAM-SHA-256 with PostgreSQL:

https://info.crunchydata.com/blog/how-to-upgrade-postgresql-passwords-to-scram

Neustradamus on 6 Nov 2019

@Neustradamus I think the problem upstream has with this is that it requires a reset of all user passwords to make use of it, as the Tigase and PostgreSQL articles also mention (the instructions for neither of them would port over to ejabberd, given that it basically comes down to "reset all passwords").

Also, what happens if a user password is stored in SCRAM-SHA256 format, but their client only supports SCRAM-SHA1? The server is unable to verify the user.
The Tigase solution seems to be to store both a SHA1 and SHA256 based version of the password, and they say they can automatically port if you have the PLAIN auth enabled. (Which, if you use it, sorta defeats the entire purpose of SCRAM I'd say?)
I think that if ejabberd wants to support SCRAM-SHA256, they should/would probably also support multiple stored passwords, to retain compatibility with clients that don't have SCRAM-SHA256, but I'm not knowledgeable of the code to a sufficient enough degree to know what that'd entail.

Basically, it's a new password storage mechanism without migration path from SCRAM-SHA1 that makes implementing this hard.