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

[Nadja von Reitzenstein Cerpnjak <[e-mail]>]

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

Ah okay that does make more sense. Your draft does currently read "The 
early data should only contain the SASL-HT payload, i.e., the 
initiator-msg, and not an application protocol specific payload.", which 
is why I assumed you planned to send the `<authenticate>` tag in the 
0-RTT data.


> 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).
This is also an issue if `tls-exporter` is used. It can only rely on 
data the client produces (since the server hasn't responded yet), so 
there is no way for the exporter to contain any connection-specific 
randomness (i.e. the server nonce).
> 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.

There are valid attacks here. The most grievous being that 0-RTT data 
can not include an ephemeral KEX step so if the servers PSK store is 
leaked an otherwise passive attacker can *change* 0-RTT data in a 
replay, e.g. take your authentication and replace your benign action 
with creating a new admin user, all without having to know your 
authentication secret. And even if replay protection and single-use 
authentication like HT is used a passive attacker can still race you to 
the server.

The only real solution to that problem I'm aware of are multi-step SASL 
mechanisms, or of course not using 0-RTT data to begin with.

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

If the goal is fast resumption of sessions by making use of 0-RTT data 
my personal preference would to just use SASL EXTERNAL. The resumed 
session is already cryptographically bound to the one in which the 
resumption PSK was generated, so we might as well bind authentication 
state to that. This is also really nice for e.g. the happy-eyeballs 
approach because a server can issue multiple session tickets, and a 
client can then use a different one for each parallel connection, 
keeping security high.

And in that situation including the authentication in 0-RTT data is 
somewhat more safe, i.e. the following exchange happens:

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

An attacker can then of course replay the whole first line, but if the 
server correctly aborts if 0-RTT contains anything after the closing > 
of </authenticate> this is not a major issue. And a later leak of the 
resumption secret (i.e. the server-side PSK store) will not give it any 
additional information, with HT-* on the other hand it would get at 
least the HT token.

So to me it feels like the HT-* mechanisms are most useful in the non 
PSK, non 0-RTT case. A completely fresh TLS handshake doesn't let a 
server divine any relation to a previous connection at all, and the HT 
token would provide exactly that.

~Nadja