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

Hi all,

The following is my position on adoption:

On Tue, 26 Oct 2021 at 11:43, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

> 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.
>
>
I think this document should be adopted and worked on.

As I've said, I think there's better options long-term, but baking TOTP
into SCRAM seems like an effective method for - as lean afficionados would
say - getting signal. We can use it to explore the limitations of the
design, and if it proves useful in deployment, that's great.

Longer term, I'd like to look at something based around XEP-0388 and/or the
encapsulation of that into another SASL mechanism, but that will take more
time and effort to implement and can be influenced by the above.

> 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/>
>
>
These are straightforward adoptions for me. Yes, migration is indeed
frustrating, but unless we have adaptations to the SASL profiles to allow
for per-user mechanisms lists, or else bring back transition-needed and all
that that entails, we're stuck with that problem.

For reauthentication (as noted by Simon, as well as Alexey and I as a
significant problem) I'd note the existence of two SASL mechanisms which
may be useful to adopt and work on:

The Hashed Token SASL Mechanism (ietf.org)
<https://tools.ietf.org/id/draft-schmaus-kitten-sasl-ht-07.html> - The
Hashed Token SASL mechanism family uses a shared secret to provide
mutual authentication with channel binding, with the shared secret
provisioned by an application level exchange.

Client Key SASL mechanism (ietf.org)
<https://tools.ietf.org/id/draft-cridland-kitten-clientkey-00.html> -
CLIENTKEY, which was designed alongside my TOTP work, and contains both a
one-time token system (with mutual authentication, channel-binding, and
without password equivalents on the server - but with the need for a
coordinated counter).

Or, of course, we can design something new.

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.
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>