10 Feb
2025
10 Feb
'25
10:07 a.m.
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.
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.
Same for token rotation: what if a client has a
long-lasting connection.
Wouldn't it be good to be able to rotate the token without having to
re-connect? Why not have the server simply push a new token to the
client if the current one approaches its expiry date?
Similarly, I think this could be added.
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.
Regards,
Matthew