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

[Benjamin Kaduk <[e-mail]>]

On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote:
> 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

Thanks, I just got a chance to look it over.

[...]

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

There does seem to be some value in having a fast "session resumption"
SASL mechanism to avoid repeated reauthentication (though presumably there
should be some guidance to periodically require a full authentication;
various flows elsewhere do this on a month timescale, roughly).
It's a little unfortunate that this ends up requiring TLS for confidentiality
(as there is some desire to have standalone mechanisms), but that seems
to be an acceptable tradeoff for this sort of application.

Putting my kitten WG chair hat on for a moment, it does seem like this work
would be in scope with our current charter
(https://datatracker.ietf.org/doc/charter-ietf-kitten/), which gives us
a pretty wide berth for giving "guidance for any new SASL-related
submissions".  That said, it is not really appropriate for us to accept
new work without a critical mass of people willing to participate/review
that work.  This document seems simple and straightforward enough that
it would not take too much work to get it ready, but we would need
to find a couple more people who are willing to review it before we
could adopt it as a WG document.  (Noting the standards@xmpp cc, I'll
explictly state that since participation in IETF working groups is
entirely open, so there is no requirement of having previously been
a WG participant for this purpose.)

Without my chair hat, the document is a little rough in some places,
but it should be pretty straightforward to clean up.  I do appreciate
the reference to RFC 6919 in particular, but it should really only be
cited by other "April 1st" RFCs.

-Ben