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

[Neustradamus]

CRAM-MD5 to Historic:

• https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 November 2008
• https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00 // June 29, 2017

RFC6331: Moving DIGEST-MD5 to Historic:

• https://tools.ietf.org/html/rfc6331 since July 2011

RFC 8600: "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):

• RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802
• RFC6120: Extensible Messaging and Presence Protocol (XMPP): Core: https://tools.ietf.org/html/rfc6120

SCRAM-SHA-256(-PLUS):

• RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677 - since 2015-11-02
• RFC8600: Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange: 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

-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

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
• 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
• https://github.com/marlam/msmtp-mirror/issues/36

[marlam]

I have no plans to implement any of this, for the following reason:

Nowadays every POP3 session must be protected with TLS. When TLS is active, there is no reason to use any SCRAM* method. (RFC 5802 says "there are some significant security concerns" with transmitting passwords over TLS-secured connections, but does not list any of them, and I have not seen a compelling argument for that statement yet.)

I therefore consider all methods except PLAIN, OAUTHBEARER, EXTERNAL (for TLS client certificates), LOGIN (strictly only for compatibility with Microsoft crap), and maybe GSSAPI (only in special situations) to be useless today.

Some of the deprecated methods like CRAM-MD5 etc are only left for backward compatibility and will probably be removed in the next larger update (1.10 or 2.0), so their presence is no reason to add SCRAM* methods.

So unless someone can convince me that any SCRAM method over TLS offers a real* (and not just theoretical) advantage over the simpler methods listed above, I will not add support for them.

[Neustradamus]

@marlam: We can thank @jas4711 who has worked on the support of the new security RFC in GNU SASL:

• RFC9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-exporter for TLS = 1.3

If you can test before merging and add support in mpop?

• https://lists.gnu.org/archive/html/help-gsasl/2022-07/msg00003.html
• https://lists.gnu.org/archive/html/help-gsasl/2022-07/msg00004.html

Thanks in advance.