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

[Alexey Melnikov <[e-mail]>]

Hi Dave,

On 05/11/2021 17:08, Dave Cridland wrote:
> 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

I was thinking about implementation and testing costs of something like 
this. I am not saying this is not the right long term (or medium term) 
solution, but this is definitely more work than adding 2FA directly to 
SCRAM...

I suppose I need to play with this (once I see an ID) and see how much 
work this is going to be.

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

The answer to this is pretty much always "yes" :-). So yes, please write 
it as an ID.

Best Regards,

Alexey

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