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

[Neustradamus]

Dear @nevans,

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
• 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://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:

• State of Play scram-sasl/info#1

[nevans]

Thank you so much for simply documenting this so thoroughly and cleanly, @Neustradamus.

I will very gratefully review and accept a PR that adds support for the SCRAM-SHA-* mechanisms!

This is a new gem, which is not (yet) used by anyone as far as I know. But it has been extracted from code which has been part of ruby's stdlib since 2000! Unfortunately, that code was hidden away inside ruby's IMAP library and not available as a library in its own right, the way SASL was meant to be used. I do have other improvements planned for this gem over the next couple of months (e.g. OAUTHBEARER), and I will most likely start using it in some of my own projects very soon.

My ultimate goals for this gem are:

1. Create PRs for net-imap, net-smtp, and net-pop which are all bundled gems.
2. This would cause net-sasl to also be a bundled gem.
3. Transfer ownership of this gem over to ruby core and the ruby security team. If this becomes a core piece of ruby security instrastructure, I'm simply not responsive enough to be the primary maintainer.
4. Create PRs for other popular ruby gems which have (or should have) SASL support: net-ldap, blather (XMPP), memcached, dalli (another memcached client). And probably some others.

Unfortunately, the SASL-SHA-* mechanisms are still unsupported by most servers that I work with. I understand that client support waiting for server support and vice versa creates a chicken-and-egg dilemma. Unfortunately, I simply don't have time to add this myself right now.

[nevans]

If you don't have time to create a PR for this gem, that's okay too. The gem is still young and will probably undergo a few API changes before it's released as 1.0, so if you create a PR against the current main branch, I might need to update it in the very near term anyway.

The second best option would be if you simply found or provided a generic ruby implementation with a compatible open source license and a good test suite. I can do the remaining work to import it. It might take me a few months to get around to it, but I will get around to it. These mechanisms should be in this library.

Third best option: point me at a well tested open source implementation in another language. It will take me longer to get around to porting that into ruby. And I could probably find one on my own by simply googling. And even still, I probably won't have time to add this myself. But a suggested reference implementation will improve the odds. :)

[nevans]

See also:

• Should we create a shared net-sasl gem? ruby/net-imap#23

I did create a branch of net-imap which uses this gem, but it was just a draft and will need to be rebased to the latest release.

I remarked there that I was going to create PRs for the other bundled gems (net-pop and net-smtp), but my schedule changed and I never got back to that. If this is going to be included in the bundled gems for ruby 3.2, I'd like to start that conversation very early in the release cycle.

[Neustradamus]

Thanks @singpolyma for #5!

@nevans: Have you planned to merge it?

[nevans]

@Neustradamus Please see my comments on #3, #4, and #5. I'm working on it, but only sporadically. I have a pure ruby SASLprep that I'm mostly happy with, and that was probably my biggest blocker for #5. But I'll probably push them all as PRs to net-imap before I port them over here.

[Neustradamus]

@nevans: Have you progressed on it?

[nevans]

Sorry, in the limited time I'm had to spend on non-work related, I've been pushing a couple of other things forward, but haven't gotten back to this yet. Thanks for the ping. I'll take a look at where I left off in my earlier branch.