Re: [kitten] TLS 0-RTT question regarding draft-schmaus-kitten-sasl-ht

[Dave Cridland <[e-mail]>]

On Wed, 19 Oct 2022 at 10:22, Nadja von Reitzenstein Cerpnjak <
[e-mail]> wrote:

> After you recently linked it I was reading through your draft and I
> would like a clarification regarding the intended interaction with
> TLSv1.3 0-RTT data.
>

As a bit of background, HT-* was developed primarily with a view to
providing a "fast reauthentication" in XMPP, and technically, would be
initiated in the second client-sent data, normally as part of the new
"SASL2" profile (XEP-0388). The currently proposed update to SASL2 has a
"MUST NOT" for TLSv1.3 0-RTT data; I've argued that this ought to be a
SHOULD NOT (and the proposal already lists sensible mitigations as far as I
follow the detail).

So if 0-RTT data were used, it'd be used in the initial stream open, and
then the client would read off stream features including the supported
authentication mechanisms (and SASL/SASL2 support), and only then send the
HT-* client-send-first data, by which time channel binding information has
been obtained:

C->S (0-RTT) <stream:stream from='...' to='...' ... version=1.0>
C<-S <stream:stream ...><stream:features>...</stream:features>
C->S <authenticate mechanism='HT-*'
...><initial-data>...</initial-data/></authenticate>

The alternative would be to optimistically pipeline the client-send-first
data (which would work on other SASL-using protocols, too), in which case
it would be possible to do so in the 0-RTT data. My understanding of 0-RTT
data is fairly weak, but I understand that it may be subject to replay by
an attacker. Assuming this is so, its current form, HT-* would then allow
for a replay attack if the binding was not dependent on the session itself
(ie, if there were no channel bindings or tls-server-end-point were used).

Whether the attack is actually useful is something of another matter - I
think an attacker would struggle to identify and use a useful pipelined
sequence, but perhaps that's not the point.

In any case, I entirely appreciate the irony in having a fast
reauthentication mechanism that essentially mandates an additional
round-trip, and if you've any suggestions I would really welcome them. One
of the handy features of HT-* in its current form is that a server could
provide a token which is the encrypted username/password for the user, for
services that are forced into using PLAIN in the backend.

Dave.