SCRAM-SHA-256 + SCRAM-SHA-512 supports

[Neustradamus]

After:

• SCRAM-SHA-1
• SCRAM-SHA-256 (done by @based-a-tron)
• SCRAM-SHA-384 (done by @based-a-tron)
• SCRAM-SHA-512 (done by @based-a-tron)

Can you add supports of:

• SCRAM-SHA3-512

Can you add the -PLUS variants (with TLS Channel Binding):

• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512-PLUS

You can add too:

• SCRAM-SHA-224
• SCRAM-SHA-224-PLUS
• SCRAM-SHA-384-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

SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms:

• https://tools.ietf.org/html/draft-melnikov-scram-bis

-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 TLS 1.3: https://datatracker.ietf.org/doc/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

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

JMAP:

• RFC8621: The JSON Meta Application Protocol (JMAP) for Mail: https://tools.ietf.org/html/rfc8621

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

Linked to:

• State of Play scram-sasl/info#1

[based-a-tron]

It is my understanding that the SCRAM-.*-PLUS mechanisms are not possible to implement in the browser, at least at the moment. I believe they would require access to the currently used certificate, which the browser does not expose.
Regardless, I have implemented #465 which should provide interfaces for SCRAM-SHA256 and the like.
If I am wrong about the channel binding abilities of modern web browsers, please let me know and I would be happy to implement the PLUS variants as well.

[based-a-tron]

@Neustradamus It would be very easy to add support for SHA-384 as well. I would just need to know what priority to put it in. I don't know what the current opinion on it is. Currently SHA-512 > SHA256 > SHA1 > PLAIN. My instinct would tell me SHA256 should be preferred to SHA384, but I don't know if this is the best way to do it.
For SHA3-512, the answer is a bit more complicated. We have two options, implement it as a standalone sasl mechanism (as in, distribute some kind of sha3.js file that contains a SHA3 implementation in javascript), or wait for the usptream Web Crypto API to write SHA3 into the standard. I encourage you to open an issue at https://github.com/w3c/webcrypto (or maybe more accurately, https://github.com/WICG/proposals) to request SHA3 support.

[sjaeckel]

My instinct would tell me SHA256 should be preferred to SHA384, but I don't know if this is the best way to do it.

It might seem unintuitive, but SHA384 should be preferred over SHA256. AFAIK the order should be:

SHA3 (512 -> 384 -> 256 -> 224)
SHA (512 -> 384 -> 512-256 -> 512-224 -> 256 -> 224 -> 1)

Speed doesn't really matter for SCRAM as the amount of data to hash is minimal (SHA256/224 would be faster on 32bit CPUs)

For SHA3

IMO requesting the feature in the WICG and adding a sha3.js (until it's included in webcrypto) sounds sensible.

[based-a-tron]

@Neustradamus, would you happen to have test vectors for sha3-512 (or sha3-256)? They are excluded from https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha3-512, likely by accident.
The SHA-512 RFC also did not include test vectors, but the code change from sha-256 to sha-512 was so trivial that they weren't needed. Since we must use a different approach for sha3, I would like something to test against. Thank you.

[sjaeckel]

Have you looked for SHA-3?

@Neustradamus: as already mentioned in another thread: please stop pushing for non-standardized Algorithms!

SCRAM-SHA3 is not standardized and maintaining X different versions because the final standard differs from the draft -- which has already happened in other cases -- is no fun. Handling this is a burden and you (@Neustradamus) won't be the maintainer of this mess then, but instead you will be complaining reminding that only some draft version is supported.

[jcbrand]

@Neustradamus: Yes, but if SCRAM-SHA-3 is not yet standardized, then I don't see much use in asking for support for it now.

[jcbrand]

Not yet.