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

[Florian Schmaus <[e-mail]>]

On 16.10.2017 04:51, Benjamin Kaduk wrote:
> 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.

Much appreciated, thank you. :)

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

Good point. I'll write down some recommendations.

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

Yes, I think TLS is a requirement to achieve what HT-* tries to achieve
in a secure fashion.

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

I don't remember explicit putting it there, so it is likely a leftover
from the I-D template [1] I've used. Err, I mean it put it there to test
if someone actually reads it. You have passed. :) I've removed the
reference in 02-SNAPSHOT [2].


One important point regarding SASL HT-* I'd like to discuss and hope to
get some insights from such a discussion is, if (and how) we should
combine it with TLS 1.3 early data.

It would be theoretically possible to exploit TLS 1.3 early data for 1
round trip session resumption. The current version of the I-D stays
defensive and forbids the usage of TLS 1.3 early data. However if the
early data *only* contains the HT-* initiator-msg and potential SASL
profile framing of the application protocol, and nothing else, then it
should be safe as far as I can tell. If that is the case, then I really
feel tempted to make use of it.

I'm happy to hear everyone's thoughts on this.

- Florian

1:
https://github.com/miekg/mmark/blob/master/rfc/rfc7511.md#conventions-and-terminology
2:
http://geekplace.eu/xeps/draft-schmaus-kitten-sasl-ht/draft-schmaus-kitten-sasl-ht-02.html