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

[Simon Josefsson <[e-mail]>]

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

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