Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports #173

Open
Neustradamus opened this issue May 22, 2024 · 1 comment
Open

SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports #173

Neustradamus opened this issue May 22, 2024 · 1 comment

Comments

@Neustradamus
Copy link

Dear @mjl- from Mox team,

After:

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

Can you add supports of :

  • 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]".

https://xmpp.org/extensions/inbox/hash-recommendations.html

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

2FA:

IANA:

Linked to:

@mjl-
Copy link
Owner

mjl- commented Jun 27, 2024

Hi @Neustradamus, thanks for tracking progress on scram support in software. It isn't yet as widely deployed in email as it should. Too many applications use at most cram-md5, or plain. TLS channel binding is rare.

It would be good to understand why scram isn't more commonly supported in servers/clients.

  • Perhaps it's not easy enough to find/write/integrate SCRAM (and/or SASL) code? For example, I found a problem with a scram implementation in other software that used a common sasl library, and I think the library API didn't make it easy to do things right.
  • Perhaps there are compatibility issues? For example, I've seen client libraries pick the non-PLUS scram variant, while actually doing PLUS during the actual scram exchange, that caused problems.
  • Perhaps server applications find it hard to derive new scram secrets for their existing accounts? With email with SMTP and IMAP we have the problem that the server announces which auth methods it implements, but there is no standardized way (e.g. error codes) that indicate derived secrets for some of the mechanisms aren't available for a user (that is trying to login), and which derived secrets actually are available.

As for scram-sha-512 and scram-sha3-512. It's easy to add support. But those are internet drafts. It's not a priority to implement them. I considered already adding code to derive secrets for those mechanisms. It is a very simple change. But there is a risk of implementing drafts that may never make it into an RFC, or will change before being final (e.g. recommended iteration count), and I don't want to create needless legacy code. Once the mechanisms are final and published, I'll implement them.

I've been meaning to do some more real-world testing with email clients and their scram support. FYI, I wrote a simple app to track client/server protocol support some time ago, here is a selection for scram: https://implementations.modernemail.org/#feats=scram. I'm going to test a few clients now and update that matrix. For testing, I'm connecting email clients to https://imapcollect.modernemail.org. It's a proof of concept I created a while ago. It allows anyone to connect, and captures protocol traces (IMAP only for now) and tracks some statistics about connections, including which authentication mechanism was used, but also which extensions were enabled. It would be an option to automatically track protocol support over time for clients (and later servers too) through this mechanism. For now, it makes it clear which auth mechanism a client picks, and clients often identify their version with the IMAP ID command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants