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

[Neustradamus]

Dear SquirrelMail team, @pdontthink, @jangliss, @jervfors, @kink, @alex-brainstorm, @avel, @bouchon, @braverock, @perlstalker, @tassium,

In first, I wish you a Happy New Year!

Can you add supports of:
- SCRAM-SHA-1
- SCRAM-SHA-1-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-256-PLUS
- 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

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

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

[Neustradamus]

Dear SquirrelMail team, @pdontthink, @jangliss, @jervfors, @kink, @alex-brainstorm, @avel, @bouchon, @braverock, @perlstalker, @tassium,

I have forgotten the last RFC in the description: RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2:
- https://tools.ietf.org/html/rfc9051

I wish you a good reading.

[Paul Lesniewski]

Thanks for this request. I'm not sure it needs high priority -- can you explain what you think the benefit is of adding these protocols to a server-side system? Most webmail installations will be authenticating on localhost and won't even be using TLS, not to mention anything more than plain/normal password auth. Even with slightly more advanced architectures, what is the value-add of using these protocols that are more client-oriented? What is the weakness of the mechanisms already offered in this context?