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

[Neustradamus]

To have compatibility with XMPP Servers and after:

• SCRAM-SHA-1
• SCRAM-SHA-256
• SCRAM-SHA-512

Can you add supports of :

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

• 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
• RFC 9266: Channel Bindings for TLS 1.3 support #13
• SCRAM-SHA-1-PLUS + SCRAM-SHA-256-PLUS + SCRAM-SHA-512-PLUS + SCRAM-SHA3-512(-PLUS) supports moxxmpp#2
• RFC 9266: Channel Bindings for TLS 1.3 support moxxmpp#3

[PapaTutuWawa]

Currently, I have SCRAM-SHA-1, SCRAM-SHA256 and SCRAM-SHA-512 implemented. The 224 and 384 variants could be implemented rather easily. SHA3-512 would require another library that I am not sure I would like to pull in just for SCRAM. The PLUS variants cannot be implemented since the TLS implementation of Dart doesn't give me access to features like channel binding.

[mwild1]

I would ignore -PLUS for now. The channel binding method is not well specified with TLS 1.3. Just so you know the original reporter of this issue reports this against every XMPP project, but in reality it's totally unnecessary to support all these variants which are not used in the real world :)

---

Not very related, but... it's nice to see a fresh XMPP client! In case you find them useful, here are a few resources:

• The chats and mailing lists hosted by the XSF, especially the jdev chat is a good place to reach fellow XMPP developers (both new and experienced).
• docs.modernxmpp.org - a documentation project covering all things "modern XMPP", especially things that are not covered by XEPs (e.g. user interface guidelines). It also has an overview of what XEPs are currently recommended for modern XMPP clients and how they fit together. It's by no means complete, but hopefully a useful resource and if you have any learnings to contribute to it, that's welcome too! (see also the chat room linked on the front page)

[PapaTutuWawa]

@mwild1 I know, I have seen these issues around. I am aware that SHA-1 is still sufficiently secure but I thought that it didn't hurt since you get SCRAM-SHA-{256,512} basically for free if you implement it using SHA-1. I have to admit that I was influenced by the XMPP wiki page about SCRAM. Removing it now probably makes no sense since it is already there but not being able to test it against an actual implementation makes me a bit uncomfortable. The fact about the deployment of other SCRAM variants is also the reason why I am reluctant about pulling in another crypto library just for SCRAM-SHA3-512 and so on (until I have to be compliant with XEP-0414).

But thank you for the additional information, though I do already know of them. I've had the idea of a new XMPP client not just since yesterday 😄

[Neustradamus]

Note that a lot of people have TLS 1.2, add -PLUS variants have been integrated in libs/softwares/products.

Example: PostegreSQL supports with and without -PLUS.

Note that GnuTLS supports already TLS Binding with TLS 1.3.

You can see libs/softwares which use different SCRAM protocols, here: scram-sasl/info#1

Note that some XMPP projects do not want to add other SCRAM that SCRAM-SHA-1.

In few weeks, Prosody 0.12.x will have SCRAM-SHA-256.
Other XMPP server already support and other SCRAM too:

• DJabberd
• ejabberd
• Metronome IM
• Mongoose IM
• M-Link
• Tigase XMPP Server

Edit: SCRAM BIS: https://tools.ietf.org/html/draft-melnikov-scram-bis speaks about SCRAM-SHA-(1-256-512)(-PLUS) and SCRAM-SHA3-(512)(-PLUS) and TLS 1.2 and TLS 1.3.

[Neustradamus]

@PapaTutuWawa: Please note that to have only SCRAM-SHA-1 support does not permit to all users to connect on XMPP Servers ;)

[PapaTutuWawa]

@Neustradamus I understand that, but at the moment I view just having SCRAM-SHA-{1,256,512} as enough, judging by the stats of the XMPP observatory. This doesn't mean I refuse to implement the "missing" ones, but at the moment my code has issues with much higher priority. If anyone tries to use my client on a server that does not offer one of the already mentioned SCRAM methods, then I will gladly implement them, as long as it's not *-MD5 or any of the *-PLUS variants.

[Neustradamus]

@PapaTutuWawa: Thanks for your reply, you can test here:

• https://lightwitch.org/

[Neustradamus]

@PapaTutuWawa: It is official for TLS 1.3 Binding!

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

Details:

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

Linked to:

• RFC 9266: Channel Bindings for TLS 1.3 support #13

[PapaTutuWawa]

@Neustradamus I have now implemented (and fixed) the SHA-256 and SHA-512 variants. Channel binding is not implemented since I still cannot access the TLS data required to do so.

[Neustradamus]

Thanks for your improvements!

Hard to add SHA3-512?

Yes, you need to wait for -PLUS variants...

[PapaTutuWawa]

Hard to add SHA3-512?

No, but I don't want to pull in another library (my current crypto library does not implement SHA3) just for SCRAM-SHA3.