On Wed, 5 Feb 2025 at 16:24, Florian Schmaus <flo@geekplace.eu> wrote:
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?
Per the XEP, the server rejects subsequent packets with a 'count' less than or equal to what it has already seen.
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...
I think this text is overly restrictive, as explained above. Regards, Matthew