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

[Dave Cridland <[e-mail]>]

On Tue, 26 Oct 2021 at 11:43, Alexey Melnikov <[e-mail]> 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.
>

Three years ago I was working on a 2FA (and more specifically, TOTP)
approach for XMPP. The route described here was my first approach - a
way of passing both factors in a single exchange seemed like the
optimal path.

But on early implementation, it became obvious that UX factors render
the saved round-trips insignificant, and also the client-driven
approach this design mandates becomes undesirable. Finally, it
necessitates that every mechanism you want to have TOTP used with
needs TOTP added, and while Alexey's approach does side-step the
creation of an actual new mechanism,

The rough outline seems to be:

* Some users will have enrolled in 2FA (and therefore created a TOTP
secret), whereas others will not have.
* Sometimes, administrators will want to enforce TOTP for all users,
other times, they will wish to make it optional.
* If a TOTP secret exists on the server, its use should ordinarily be
mandatory by a client using a password, and this must be enforced by
the server.
* But, if a client is performing some form of subsequent
reauthentication, you don't want to use it or enforce it.
* Except when you do - it can be useful to re-request a TOTP code
every month, or the reverse, and choose not to re-request TOTP even
when a password mechanism is re-requested.
* Where a TOTP is required, the client will always perform some kind
of user interaction; so asking for the TOTP code as an additional RTT
is fine.

Negotiating second factors as an additional negotiation therefore
became the design, since this provided most flexibility in deployment.

Hence XEP-0388 - https://xmpp.org/extensions/xep-0388.html -
colloquially known as SASL2 which replaces the existing XMPP SASL
profile with a newer profile which is not only more extensible (useful
for other reasons in XMPP), but also has a concept of secondary
authentication "tasks".

Originally these were going to be chained mechanisms - so TOTP would
be modelled as a SASL mechanism, and usable in any order. This felt
very clever, but it turns out that "tasks" are different from
"mechanisms" is various ways - mostly in as much as they do not change
the authorization identifier, and so do not need it as an input or
output.

So what XEP-388 provides ends up being a SASL profile that has a
mechanism selection phase for authentication, then the mechanism
exchanges, but then instead of only resulting in success or failure,
also results in a continue, which presents some more tasks, one of
which must be selected and run through.

In practical terms, this gives an opportunity after the initial SCRAM,
PLAIN, etc to use TOTP, or a mandatory password change, or TOTP
initialization.

We defined the TOTP tasks in XEP-0400, and also defined a generalized
"subsequent reauthentication" system which ended up being clientkey
(draft-cridland-kitten-clientkey, and also XEP-0399). Defining
subsequent reauthentication around a SASL mechanism and associated
application-layer support gives useful flexibility, and felt more
generically useful than building it into the mechanisms, but in
retrospect it'd be nice to avoid the necessity for the application
protocol support (even if it's a nice-to-have). An option here would
be to introduce optional tasks in XEP-0388, which the existing design
doesn't have, which could then be used to token initialization.

Finally, to complete the work we were actually trying to do, we also
wrote a "pseudo-mechanism" for clients to request password resets, and
a SASL2 task for mandatory password changes.

The obvious downside of the approach we took is that it requires
changes to the SASL profiles of the application protocols - this is
certainly undesirable. It could be side-stepped by providing a
meta-mechanism, which in turn handled the enhanced exchange
internally, but this is very much a compatibility layer and (I
suspect) less efficient. In any case, XEP-0388 provides a better
profile for XMPP for various unrelated reasons.

The upside of the approach is that - I feel - it matches the
requirements of practical TOTP deployment considerably better, and
provides a flexible framework for 2FA which conforms to the design of
SASL itself.

> 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 two look good, and we should most certainly get them published
on the standards track.

Dave.