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

[Alexey Melnikov <[e-mail]>]

Hi Simon,

On 26/10/2021 21:52, Simon Josefsson wrote:
> 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.
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.
> 2) Add new hashes for SCRAM causes complexity in applications to specify
> and support multiple database entries for different
> 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
> 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 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

> /Simon
>
> Alexey Melnikov <[e-mail]> writes:
>
>> 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.
>>