Subject: [kitten] TOTP in SASL in XMPP

From: Dave Cridland <[email-masked]>
Date: Thu, 25 Jan 2018 10:35:47 +0000

Dear Kittens,

A new ball of wool to play with:

I've been working with my colleagues over the past few months trying
to get a working TOTP pattern for XMPP. Initial publication of all the
bits has just finished, so it's a good time to nudge the list and say
how keen I am to find out what I've done wrong.

The basic requirements are roughly the following:

1) Users can be made to enter a TOTP code as part of the login flow.

2) This can be a single movable part (ie, no OAUTH/SAML).

3) Users can request to "remember this browser".

4) Threat model assumes that at some point, devices will be stolen,
server databases exfiltrated, and credentials lifted from clients.

We've tried to address this by a bunch of specifications, one Internet
Draft and the rest XEPs over at the XSF:

* XEP-0388 provides an enhanced SASL profile for XMPP which introduces
a new quasi-terminal response of "continue", which is functionally
identical to "success", except it demands further action by the client
in the form of "tasks".

* XEP-0400 provides a TOTP task, as well as some application-level
stuff in XMPP to handle provisioning.

* draft-cridland-kitten-clientkey provides a per-client, 1*RTT SASL
mechanism which we then use as the "remember this device".

* XEP-0399 then implements the application-level stuff in XMPP for
CLIENT-KEY, which handles provisioning etc.

These four build into a functioning and usable TOTP implementation.

As I say, I would welcome feedback. There is a strong coupling between
draft-cridland-kitten-clientkey and XEP-0399, but otherwise each part
is weakly coupled and can be replaced (so if we want a DH-based
mechanism instead of - or as well as - CLIENT-KEY's hash-and-counter,
that's easily done).

We (Surevine) have a working implementation of this, except that we're
currently using an older, weaker, design instead of CLIENT-KEY.

Dave.