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

[Dave Cridland <[e-mail]>]

Hi Alexey,

On Fri, 5 Nov 2021 at 15:50, Alexey Melnikov <[e-mail]> wrote:
>
> Dave,
>
> On 05/11/2021 15:41, Dave Cridland wrote:
> > 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.
>
> I like your approach of stacking mechanisms, but I fear this is going to
> be a multi-year approach to implement and deploy.
>
> So yes, happy to work on this as well, but I am not happy to not work on
> simpler/quicker ways to deploy 2FA with SCRAM that can be done in a
> couple of months time.
>

OK, and I understand your motive for something rapidly deployable -
but what about encapsulating the XEP-0388 SASL flow within another
mechanism?

This would mean a mechanism where the messages were:

Client Send First: username, optional wrapped-mechname, optional
client-send-first for wrapped-mechanism
Server: wrapped-mechname, wrapped-exchange OR mechanisms-list
Client: ...
Server: ...
Client: ...
Server: success, optional success-data OR failure OR continue,
optional success-data, task list

[etc]

That would mean you could wrap SCRAM within it and where TOTP was
required by the server, it could force that and the UX flow would be
as expected - thus functionally equivalent to your design but also
more or less as easy to deploy (in as much as it could be written as a
Cyrus SASL mechanism plugin I think - one that itself would then make
mechanism calls).

But it would also be equivalent in terms of SASL itself to XEP-0388,
thus allowing TOTP to be used with PLAIN, and HOTP or even SMS codes
to be used in lieu of TOTP (in principle).

The only real change from yours is that there's an additional RTT
involved for TOTP, but that's irrelevant when the user is having to
fumble about for their phone anyway.

If you're interested in exploring further I'm happy to describe this
approach more formally (ie, put together an I-D).

> > 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.
>
> Best Regards,
>
> Alexey
>