On Wed, 5 Feb 2025 at 16:24, Florian Schmaus <[email protected]> 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-initiator-first-message

I think this text is overly restrictive, as explained above.

Regards,
Matthew
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to