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

From: Robbie Harwood <[email-masked]>
Date: Wed, 03 Nov 2021 13:43:34 -0400

Simon Josefsson <[email-masked]> writes:

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

Hi Simon, do you have any further thoughts on this in light of Ruslan's
and Alexey's comments in reply?

Be well,
--Robbie

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 3 Nov 2021 20:31:30 +0000

> and Alexey's comments in reply?

No.  I agree with what the replies, and haven’t changed my opinion.  I’d rather see work on addressing the problems that were brought up, or stronger mechanisms, instead. But things aren’t a zero-sum game, so if enough people wants these drafts published, that’s what will happen.

/Simon

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 04 Nov 2021 08:06:11 -0400

Having reconsidered this in light of some of these comments, I think I
agree in terms of SCRAM-SHA-512 and SCRAM-SHA3. While I'm certainly not
*against* publishing these mechanisms (as I mentioned, I have
implemented them and used them already in some places) I do think SCRAM-SHA-
256, for example, is likely strong enough for now. It doesn't show any
signs of weakness, so we might want to focus on a mechanism that has its
own hash/CB negotiation instead and is extensible enough to add 2FA
later (or whatever other requirements this group comes up with: better
hash agility comes to mind). I suppose I've changed to being neutral on
publishing the new SCRAM mechanisms.

As for the 2FA document I think that represents something that's missing
from *current* mechanisms and should likely move forward. If we were to
focus on new mechanisms that could implement 2FA I think we'd be doing a
disservice to existing SASL/SCRAM users who may not be able to evaluate
and update to a new mechanism, but may be able to add 2FA to their
existing setup more quickly.

—Sam

On Wed, Nov 3, 2021, at 16:31, Simon Josefsson wrote:
>>> 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
>> Hi Simon, do you have any further thoughts on this in light of
>> Ruslan's and Alexey's comments in reply?
>
> No.  I agree with what the replies, and haven’t changed my opinion.
> I’d rather see work on addressing the problems that were brought
> up, or stronger mechanisms, instead. But things aren’t a zero-sum
> game, so if enough people wants these drafts published, that’s what
> will happen.
>
> /Simon
> _______________________________________________
> Kitten mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

-- 
Sam Whited

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 5 Nov 2021 11:08:42 +0000

On 04/11/2021 12:06, Sam Whited wrote:
> 256, for example, is likely strong enough for now.
I am happy to defer decision on bringing them into the WG till a later date.
> It doesn't show any

I feel the same.

So my update proposal is to work on the following in the WG:

1) SCRAM 2FA extension

2) Something like draft-cridland-kitten-clientkey for SASL 
re-authentication that can be used with SCRAM or similar mechanisms

3) A possible informational document about best SASL implementation 
practices, in particular how to deal with some SASL mechanisms only 
being available for some users.

Best Regards,

Alexey

---

From: Dave Cridland <[email-masked]>
Date: Fri, 5 Nov 2021 15:41:53 +0000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 5 Nov 2021 15:49:57 +0000

Dave,

On 05/11/2021 15:41, Dave Cridland wrote:
> 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.

> It could be side-stepped by providing a

Best Regards,

Alexey

---

From: Dave Cridland <[email-masked]>
Date: Fri, 5 Nov 2021 17:08:01 +0000

Hi Alexey,

> simpler/quicker ways to deploy 2FA with SCRAM that can be done in a

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 8 Nov 2021 14:17:19 +0000

Hi Dave,

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

> 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

---

From: Robbie Harwood <[email-masked]>
Date: Thu, 11 Nov 2021 11:09:01 -0500

> being available for some users.

Does anyone have thoughts on this modified proposal?  (I'm trying to
judge consensus, so please speak up.)

Be well,
--Robbie

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Thu, 11 Nov 2021 21:39:03 +0100

> judge consensus, so please speak up.)
Up for MFA, no comments re SHA2+.

Or rather I do have comments re SHA2+ - but they have nothing to do
with security. Just standard blah-blah re future proof and stuff. But
I'd rather prefer seeing cost-based algorithm (like scrypt or Argon2)
for future-proofness than sha1024 (eg. I already hate seeing sha512
base64 in xmpp dumps).

Regards,
Ruslan