Subject: [kitten] Requesting WG adoption of several SCRAM related documents

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 Oct 2021 11:43:25 +0100

Dear Kitten WG participants,

I would like to request WG adoption of several SCRAM related documents:

1) Extensions to Salted Challenge Response (SCRAM) for 2 factor 
authentication
<https://datatracker.ietf.org/doc/draft-melnikov-scram-2fa/>

There were some earlier discussions of this document and it seems to be 
in scope for the current charter.

2) SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and 
Security Layer (SASL) Mechanisms
<https://datatracker.ietf.org/doc/draft-melnikov-scram-sha-512/>

This is already implemented in Cyrus SASL, so it would be good to have 
stable documentation.

3) SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and 
Security Layer (SASL) Mechanisms
<https://datatracker.ietf.org/doc/draft-melnikov-scram-sha3-512/>

Best Regards,

Alexey

P.S. As I am editing various documents mentioned in this email, my 
co-chair Robbie will judge consensus on adoption of each document.

---

From: "Sam Whited" <[email-masked]>
Date: Tue, 26 Oct 2021 10:12:57 -0400

I have existing implementations of some of these I-D's and support their
adoption. Thanks!

—Sam

On Tue, Oct 26, 2021, at 06:43, Alexey Melnikov wrote:
> There were some earlier discussions of this document and it seems to
> be in scope for the current charter.
>
> P.S. As I am editing various documents mentioned in this email, my co-
>      chair Robbie will judge consensus on adoption of each document.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Oct 2021 22:52:54 +0200

Hi.  I'm not strongly opposed to these work items, but I do feel
publishing these documents without adressing high-level concerns have a
risk of causing problems during deployment.  I think the WG should
understand and consider the implication before adopting the documents -
maybe there is alternative work that needs to happen before/instead.

1) For SCRAM-2FA how is user interaction supposed to work for
applications that open many connections?  This is the problem that
turned out to kill deployment of SAML20 and OPENID20 for typical
environments.  I think this is a serious problem for any SASL mechanisms
that works with non-long-term secrets, and I think we should ponder if
there is some generic mechanism (like SASL re-authentication or
authentication resumption) that needs to be standardized.  Otherwise I
think SCRAM-2FA will end up in the same way, and cause people to do a
lot of work to try to implement it and run into the same problems.

2) Add new hashes for SCRAM causes complexity in applications to specify
and support multiple database entries for different
password-equivalents.  There is no real guidance on how clients and
servers should treat multiple hash variants and negotiation between
them.  SASL does not handle sub-mechanism negotiation well, so it has a
security complexity cost.  I wrote about some of this in
https://blog.josefsson.org/2021/06/08/whats-wrong-with-scram/ and at
least one problem is worth repeating:

  How to negotiate which variant to use is not well-defined. Consider if
  the server only has access to a SCRAM-SHA-1 hashed password for user X
  and a SCRAM-SHA-256 hashed password for user Y. What mechanisms should
  it offer to an unknown client? Offering both is likely to cause
  authentication failures, and the fall-back behaviour of SASL is poor.

/Simon

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Wed, 27 Oct 2021 08:53:36 +0200

Hi Simon,
>   authentication failures, and the fall-back behaviour of SASL is
I think the problem statement goes beyond the scope of the protocol.
The SASL is pluggable protocol by design and offering many methods is a
differentiating feature of the protocol. Handling credentials database
or applicaiton protocol negotiation is responsibility of the
applicaiton and SASL as authenticaiton protocol cannot mandate that you
should store your passwords this or that way. Rather opposite,
depending on the way the passwords are stored you get an access to
either this or that method. However the protocol negotiates applicaiton
capabilities (which methods authentication backend supports, which of
them are allowed to be used) not application data (which elements are
stored and how). 

Hence adding a [more secure?] method to a protocol which is designed to
use many is an improvement. What needs to be discussed I believe is
whther the new method really adds any value (is more secure). I.e. does
it make sense artificially increasing complexity (bits & iterations of
the pbkdf2) of the hash function which is designed to be fast and
simple? Or instead focus on using high-complexity hashing and
derivation methods like argon2. My knowledge and experience are not
sufficient to answer this question however I _feel_ the added methods
are a workaround, not solution.

And then the problem stated is a good reason and a subject to develop a
new protocol, adaptive to various storage backends and storage methods,
resistant to negotiation mangling and downgrade (SASL already has this
problem with tls binding type negotiation).

Thanks & regards,
Ruslan

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Oct 2021 12:13:35 +0100

Hi Simon,

> lot of work to try to implement it and run into the same problems.
Very good point. I think Dave Cridland had a proposal for a generic SASL 
resumption mechanism 
<https://www.ietf.org/archive/id/draft-cridland-kitten-clientkey-00.txt> 
and I support adopting it to address this problem.
> password-equivalents.
This is not really a new thing, although multiple SCRAM mechanisms 
certainly made it worse. Some backends can store multiple values and 
some can't.
> There is no real guidance on how clients and

I think this is a generic SASL problem when there are different sets of 
users that use different SASL mechanism/credentials. (E.g. the same 
problem exists if some users have SCRAM-SHA-1 credential and some can 
only use EXTERNAL).

This is also a quality of implementation issue. Many implementations can 
iterate through several SASL mechanisms until one of them succeeds.

Anyway, I am happy to work on better advice for SASL implementors or 
some other way to help improve this.

Best Regards,

Alexey