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

["Ruslan N. Marchenko" <[e-mail]>]

Hi Simon,
Am Dienstag, dem 26.10.2021 um 22:52 +0200 schrieb Simon Josefsson:
> 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.
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