strophe/strophejs

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

Closed this issue · 23 comments

Neustradamus commented

After:

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):

SCRAM-SHA-256(-PLUS):

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

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

-PLUS variants:

IMAP:

LDAP:

  • RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

JMAP:

2FA:

IANA:

Linked to:

Neustradamus commented

@jcbrand: I have seen the removal of old unsecured DIGEST-MD5, thanks!

But I do not see:

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

Of course the order is SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1.

Thanks in advance.

Neustradamus commented

Good news, in more:

  • SCRAM-SHA-1(-PLUS)
  • SCRAM-SHA-256(-PLUS)

There are now:

  • SCRAM-SHA-512(-PLUS)
  • SCRAM-SHA3-512(-PLUS)

Main text updated.

Neustradamus commented

@jcbrand: Have you progressed on it?

Neustradamus commented

Dear @strophe team,

I wish you a Happy New Year 2022!

Have you looked for the standard SCRAM-SHA-256 which will be soon in Prosody IM 0.12 stable?

It is already supported with other SCRAM by DJabberd, ejabberd, Mongoose IM, M-Link, etc.

Thanks in advance.

Neustradamus commented

2022-03-14: Prosody 0.12 has been released with SCRAM-SHA-256 (in more SCRAM-SHA-1):

based-a-tron commented

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.

Neustradamus commented

@based-a-tron: Whaouuuuuuuuuuuu, excellent, magic, you are a hero of a lot of people with your PR!

If you can see for SCRAM-SHA3-512 in more SCRAM-SHA-256 and SCRAM-SHA-512, it will be nice too :)

About TLS Binding (-PLUS variants), it is in a second part, you have done a very good and important part! :)

You can see here too: https://datatracker.ietf.org/doc/html/draft-melnikov-scram-bis

cc: @pasis, @sjaeckel, devs who have worked on libstrophe!
@aamelnikov: Look the PR, a good job from @based-a-tron!
Can you reply to the previous comment?

based-a-tron commented

@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.

Neustradamus commented

@based-a-tron: For 224/384, maybe you can add a feature to enable but not by default?

About SHA3-512, temporary it is possible to have a sha3.js before the SHA-3 support in Web Crypto API?

sjaeckel commented

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 commented

@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.

Neustradamus commented

@based-a-tron: Thanks for your changes!
Have you looked for SHA-3?
I have sent you links previously here.

Hope that @jcbrand will review a new time.

sjaeckel commented

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.

Neustradamus commented

It is official, it is here: RFC 9266: Channel Bindings for TLS 1.3:

Neustradamus commented

@jcbrand: Thanks for the merging of @based-a-tron work and your commit too.

I need to create a new ticket for SHA-3 part?

jcbrand commented

@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.

Neustradamus commented

@jcbrand: Ok!
Have you planned to release a new version?

jcbrand commented

Not yet.

Neustradamus commented

@jcbrand: I have not seen before, thanks for 1.6.0 release!

Neustradamus commented

@jcbrand: Can you reopen the ticket?
-PLUS variants have not been added.

Neustradamus commented

@jcbrand: I have edited the ticket title and created a new one for SHA-3 and -PLUS variants: