[kitten] The Hashed-Token SASL Mechanism (SASL-HT)

[Florian Schmaus <[e-mail]>]

I would like to note the existence of draft-schmaus-kitten-sasl-ht-01:

https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01

Fast, ideally instant, session reattachment becomes increasingly
important, partly because of the rising share of mobile sessions. A
while ago I started thinking about a new approach for quick XMPP session
reattachment. Currently in XMPP a session obtains a (non-sensitive)
token which, after authentication via SASL, it can use to resume an
existing session (XEP-0198). However, this does lead to a number of
round-trips during session setup, many of which we can elide by
combining the authentication and resumption steps.

Thus we initially authenticate an XMPP session using a strong mechanism
like SCRAM, but at resumption-time we want a single round trip
mechanism. The basic idea of such a mechanism is that the client
requests a short-lived, exclusively ephemeral token after being
authenticated, which can be used to authenticate the resumption in an
efficient manner.

Members of the XSF community pointed out that that it eventually makes
sense to split the work into a number of distinct portions so that other
application protocols can re-use and benefit from it:

  1) An extensible SASL profile, replacing the existing SASL profile
     specified in RFC 6120, being developed within the XSF as XEP-0388
     [1] (although we might well move this to IETF once it fits our
     needs).
  2) An extension to this profile to support the framework of XEP-0198
     session resumption (XEP-ISR-SALS2, [2]).
  3) A new SASL mechanism suitable for the purpose (HT-*, as specified
     in draft-schmaus-kitten-sasl-ht-01).

The SASL HT-* mechanism outlined is attempting to provide a reasonably
secure authentication based around a token obtained over the application
protocol, in a single round-trip. This single-round-trip is a key
requirement. The proposal uses a single-use token as a shared secret,
provides channel binding and mutual authentication.

Because neither the XSF nor the authors of the Internet Draft do claim
to have the expertise required to adequately review and otherwise
develop a SASL mechanism it has been submitted as an Internet Draft by
an individual.

The XSF does AFAIK not operate a formal liaison process with the IETF in
general; instead we will simply encourage interested individuals to
participate here instead. In particular, the XSF will neither
participate, nor attempt to control, as an organisation. Many of the
participants within the XSF are also IETF participants, so we'll play
nicely.

Your feedback is highly appreciated.

Thanks
 Florian

1: https://xmpp.org/extensions/xep-0388.html
2: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html