13 Feb
2025
13 Feb
'25
3:41 a.m.
On 10/02/2025 18.07, Matthew Wild wrote:
+1
I am sorry, but I don't think it was explained above. But I now
understand that your mental model regarding 0-RTT data differs from mine.
I am surprised that the FAST XEP mentions the issue with side effects
causing data in the 0-RTT payload, explaining that the counter would fix
that completely. That is not the case if the attacker removes the
original 0-RTT packet from the wire. It seems to be consensus by the TLS
designers that 0-RTT payload should only cause an idempotent operation.
But if we need replay protection, then the operation we protect is not
idempotent, as otherwise, we wouldn't need replay protection.
I believe you want to reduce XMPPs initial connection and authentication
delay as much as I do. But the 0-RTT data should only contain what is
necessary for (fast re-)authentication. Everything else should be done
in a subsequent [1], i.e., in the 1.5 round trip, which is a small price
to pay for the security you gain. As bonus, replay protection becomes a
non-issue for FAST.
If you really want to go down that route, then at least consider adding
a timestamp. This would reduce the time window for an attacker to replay
the packet. The timestamp could replace the counter, be in addition to
it, or even be optional.
Hopefully this does not come over as overly negative. I really
appreciate your work on FAST. I only disagree on technical grounds on
how 0-RTT is used in FAST.
- Flow
1: This probably needs support from Bind 2
On Wed, 5 Feb 2025 at 16:24, Florian Schmaus
<flo(a)geekplace.eu> wrote:
Per the XEP, the server rejects subsequent packets with a 'count' less
than or equal to what it has already seen.
But in the scenario I depicted, the authentication would succeed.
4. Do you
have any security concerns related to this specification?
The XEP states that the 'count' attribute protects against replay
attacks if TLS' 0-RTT data is used. I am not sure if this is true. An
attacker could take the original 0-RTT package from the wire and replay
it against the server. How does 'count' help here?
What is essential is that 0-RTT data only
contains the authentication
data, but nothing more [1]. If it would contain, for example, also a
correctly pipelined <message/>, then an attacker could potentially
replay the 0-RTT data and cause the server to send the message.
I don't think this matters, if the server correctly rejects the
authentication. Servers already need to ensure they don't process
pipelined data on failed authentications (with or without 0-RTT).
Further
remarks:
Shouldn't token invalidation be possible without having to go through a
SASL authentication? I am at a kiosk browser and hit the 'logout'
button. Now the browser first has to disconnect and reconnect to
invalidate the token?
Yes, I agree this is a bit awkward. We should spec a way to do this
after authentication, e.g. with a simple iq.
1: See also
the relevant paragraph about 0-RTT in
https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-…
I think this text is overly restrictive, as explained above.