SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports

[Neustradamus]

Dear @mjl- from Mox team,

After:

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS

Can you add supports of :

• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512
• SCRAM-SHA3-512-PLUS

You can add too:

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

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
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/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

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://datatracker.ietf.org/doc/html/draft-ietf-kitten-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

[mjl-]

Hi @Neustradamus, thanks for tracking progress on scram support in software. It isn't yet as widely deployed in email as it should. Too many applications use at most cram-md5, or plain. TLS channel binding is rare.

It would be good to understand why scram isn't more commonly supported in servers/clients.

• Perhaps it's not easy enough to find/write/integrate SCRAM (and/or SASL) code? For example, I found a problem with a scram implementation in other software that used a common sasl library, and I think the library API didn't make it easy to do things right.
• Perhaps there are compatibility issues? For example, I've seen client libraries pick the non-PLUS scram variant, while actually doing PLUS during the actual scram exchange, that caused problems.
• Perhaps server applications find it hard to derive new scram secrets for their existing accounts? With email with SMTP and IMAP we have the problem that the server announces which auth methods it implements, but there is no standardized way (e.g. error codes) that indicate derived secrets for some of the mechanisms aren't available for a user (that is trying to login), and which derived secrets actually are available.

As for scram-sha-512 and scram-sha3-512. It's easy to add support. But those are internet drafts. It's not a priority to implement them. I considered already adding code to derive secrets for those mechanisms. It is a very simple change. But there is a risk of implementing drafts that may never make it into an RFC, or will change before being final (e.g. recommended iteration count), and I don't want to create needless legacy code. Once the mechanisms are final and published, I'll implement them.

I've been meaning to do some more real-world testing with email clients and their scram support. FYI, I wrote a simple app to track client/server protocol support some time ago, here is a selection for scram: https://implementations.modernemail.org/#feats=scram. I'm going to test a few clients now and update that matrix. For testing, I'm connecting email clients to https://imapcollect.modernemail.org. It's a proof of concept I created a while ago. It allows anyone to connect, and captures protocol traces (IMAP only for now) and tracks some statistics about connections, including which authentication mechanism was used, but also which extensions were enabled. It would be an option to automatically track protocol support over time for clients (and later servers too) through this mechanism. For now, it makes it clear which auth mechanism a client picks, and clients often identify their version with the IMAP ID command.