[Standards] TOTP and enforced password changes in SASL2
dave at cridland.net
Thu Aug 24 15:56:37 UTC 2017
On 24 August 2017 at 15:58, Jonas Wielicki <jonas at wielicki.name> wrote:
> On Donnerstag, 24. August 2017 12:59:56 CEST Dave Cridland wrote:
>> Now that an update to XEP-0388 has been published, I thought I'd
>> share what I've been trying to do with it.
> All of this sounds in general sensible. I was first a bit confused as to why
> you didn’t use the term "mechanism", but upon reading the updated XEP and your
> earlier emails on that subject, it makes sense.
> However, it seems to me as if much of this could be solved with a normal
> stream feature without reworking how SASL authentication works in general in
> By offering only e.g. <post-sasl-tasks xmlns="…"><task>PASSWORD-RESET</task></
> post-sasl-tasks> in the <stream:features/> after the authenticating RFC 6120
> SASL exchange, you’d achieve the same thing, afaict (except for the extra
> round-trip for the stream reset). Or am I overlooking something?
Well, no, you're not.
You *could* implement TOTP purely within the existing specifications,
as a stream feature after SASL.
I've avoided that (so far - I can be persuaded) for two reasons:
* Conceptually, these things are part of authenticating the user.
Until TOTP is done, the client is not authenticated (in the sense of
the stream being in the authenticated state as well as the more common
meaning). I'd be worried over the handling of a conceptually distinct
phase in authentication.
* SASL2 is specifically designed to handle these things efficiently.
Using a distinct stream feature to force TOTP, we'd have to include a
stream restart to move on - two more round-trips than with SASL2.
Moreover, SASL2 is designed to handle a lot more than just TOTP etc -
we can merge in resource binding without any additional round-trips,
for example, if I can ever persuade Kev to see things my way. So it's
more efficient, and more incentive to get people to add SASL2 support.
More information about the Standards