LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens)
This message constitutes notice of a Last Call for comments on XEP-0484. Title: Fast Authentication Streamlining Tokens Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. URL: https://xmpp.org/extensions/xep-0484.html This Last Call begins today and shall end at the close of business on 2025-01-27. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
On Mon, Jan 13, 2025 at 12:50 PM Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0484.
Title: Fast Authentication Streamlining Tokens Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip.
URL: https://xmpp.org/extensions/xep-0484.html
This Last Call begins today and shall end at the close of business on 2025-01-27.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes. Making login/resumption faster is important and FAST is the last building block in the new SASL2/Bind 2 stack that isn’t stable yet.
2. Does the specification solve the problem stated in the introduction and requirements?
yes
3. Do you plan to implement this specification in your code? If not, why not?
Yes it’s implemented in Conversations
4. Do you have any security concerns related to this specification?
Yes. I think the section 3.2 as well as the security considerations are missing text that instruct developers not to downgrade their channel binding method compared to their normal login method. Meaning when logged in with SCRAM-SHA1-PLUS/exporter only tokens that use an equivalent or better channel binding mechanism should be requested and/or excepted. The channel bindings for normal login are protected via XEP-0474: SASL SCRAM Downgrade Protection while the fast mechanisms are not covered by this. That’s fine if and only if we add language to 484 saying that clients should not request anything weaker than used during login.
5. Is the specification accurate and clearly written?
Yes
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
Yes.
4. Do you have any security concerns related to this specification?
I don't love that the suggested SASL mechanisms have no protection against tokens being stolen and re-used via MITM, but this could be solved by using SCRAM in implementations which is not forbidden.
5. Is the specification accurate and clearly written?
I do not particularly like at all having the SASL mechanisms for FAST specified completely seperately. I do sort of understand the reason it was does, but it's not generic at all. For example if I want do (and I do want to) support "app passwords" I need to solve the same problems (select which credential is being used, specify which SASL mechanisms can be used for which credential) but I wouldn't be able to re-use the solution FAST uses and would need yet another third solution.
On Tue, Feb 4, 2025 at 4:02 PM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
4. Do you have any security concerns related to this specification?
I don't love that the suggested SASL mechanisms have no protection against tokens being stolen and re-used via MITM, but this could be solved by using SCRAM in implementations which is not forbidden.
5. Is the specification accurate and clearly written?
I do not particularly like at all having the SASL mechanisms for FAST specified completely seperately. I do sort of understand the reason it was does, but it's not generic at all. For example if I want do (and I do want to) support "app passwords" I need to solve the same problems (select which credential is being used, specify which SASL mechanisms can be used for which credential) but I wouldn't be able to re-use the solution FAST uses and would need yet another third solution.
I guess that depends a lot on what exactly your vision for "app passwords" is but if they don’t renew themselves and aren’t necessarily requested via XMPP you can just use SASL2 with PLAIN for example and already get the 0rtt parts. (I actually have a deployment where we use PLAIN anyway and thus never felt the need to use FAST after we got SASL2+Bind2) I mean FAST is really just a thin wrapper around a family of SASL mechanisms so I don’t get the point that it is too narrowly defined around those mechanisms. But I guess if you feel strongly spec out what you need for "app passwords" and we can look at the concrete overlap. cheers Daniel
I guess that depends a lot on what exactly your vision for "app passwords" is but if they don’t renew themselves and aren’t necessarily requested via XMPP you can just use SASL2 with PLAIN for example and already get the 0rtt parts.
Yes, with PLAIN is what I do now, but no way to use SCRAM for example which is the whole issue.
(I actually have a deployment where we use PLAIN anyway and thus never felt the need to use FAST after we got SASL2+Bind2)
Generally for me the purpose of FAST is to stop storing passwords on client devices, but I understand everyone has their own use case.
I mean FAST is really just a thin wrapper around a family of SASL mechanisms so I don’t get the point that it is too narrowly defined around those mechanisms.
I don't think FAST is tied to any particular SASL mechanisms? That's why we duplicate mechanism discovery as part of FAST, which is the main thing I'm talking about here.
I don't think FAST is tied to any particular SASL mechanisms? That's why we duplicate mechanism discovery as part of FAST, which is the main thing I'm talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I think would work for FAST and also for other things such as app passwords: When requesting a FAST token, return the token and also a SASL authcid value to go along with it. Then when doing authentication in the future, this authcid will select which credential to check against (the FAST token) instead of using a custom mechanism (the <fast/> tag). This solves one of the two warts in a way that works with SASL instead of reinventing it. Now, as for the duplicate mechanisms thing, I don't personally see why this is needed at all at this point. A token is a password and thus should work with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc). However, in case we want to still allow servers to not implement FAST for every relevant SASL mechanism they support, I would suggest this change. Instead of: <request-token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP'/> We do (insersection of server and client supported mechanisms): <request-token xmlns='urn:xmpp:fast:0'> <mechanism>SCRAM-SHA-1</mechanism> <mechanism>HT-SHA-256-ENDP</mechanism> </request-token> And the server will select a supported one to bind to the token: <token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP' expiry='2020-03-12T14:36:15Z' token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' />
On Wed, 5 Feb 2025 at 15:35, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I don't think FAST is tied to any particular SASL mechanisms? That's why we duplicate mechanism discovery as part of FAST, which is the main thing I'm talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value to go along with it. Then when doing authentication in the future, this authcid will select which credential to check against (the FAST token) instead of using a custom mechanism (the <fast/> tag).
The authcid is how we convey the authenticating username.
This solves one of the two warts in a way that works with SASL instead of reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this is needed at all at this point. A token is a password and thus should work with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc). However, in case we want to still allow servers to not implement FAST for every relevant SASL mechanism they support, I would suggest this change. Instead of:
The problem is that for some mechanisms and authentication backends, the server needs to know what kind of credentials are being used up-front. In an ideal world, I think we would have SASL able to encode this information. Specifically, there are two things the server needs to know: 1) The type of credential being used (password, FAST token, bearer token, etc.) 2) In some cases, some identifier of the credential being used (when the same user has multiple credentials of the same type, common with tokens) In many cases (1) can be hackily inferred from the mechanism - e.g. just assume that SCRAM is always a password, and that HT is always a FAST token. However I don't think this is a future-proof design, and there are cases where a mechanism may be useful for multiple credential types. For (2) we currently use the SASL2 client id (a single user may have multiple FAST tokens, because they have multiple devices). Again, it would be great if SASL had this concept built-in, but it does not right now. The FAST protocol was designed the way it was in order to work around these constraints. I agree that the protocol could be more elegant if we were to change the SASL layer to accommodate some of its requirements. But I also think that what we have is fine and future-proof. Regards, Matthew
I don't think FAST is tied to any particular SASL mechanisms? That's why we duplicate mechanism discovery as part of FAST, which is the main thing I'm talking about here.
Ok, so, a concrete proposal for an alternative to the current design which I think would work for FAST and also for other things such as app passwords:
When requesting a FAST token, return the token and also a SASL authcid value to go along with it. Then when doing authentication in the future, this authcid will select which credential to check against (the FAST token) instead of using a custom mechanism (the <fast/> tag).
The authcid is how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that for FAST we put a token id there, which will of course convey the account in question to the server as well (since a token is only valid for a single account).
This solves one of the two warts in a way that works with SASL instead of reinventing it.
Now, as for the duplicate mechanisms thing, I don't personally see why this is needed at all at this point. A token is a password and thus should work with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc). However, in case we want to still allow servers to not implement FAST for every relevant SASL mechanism they support, I would suggest this change. Instead of:
The problem is that for some mechanisms and authentication backends, the server needs to know what kind of credentials are being used up-front. In an ideal world, I think we would have SASL able to encode this information.
Specifically, there are two things the server needs to know:
1) The type of credential being used (password, FAST token, bearer token, etc.) 2) In some cases, some identifier of the credential being used (when the same user has multiple credentials of the same type, common with tokens)
I think these are basically the same thing. We need to know what credential is being used. If we have an identifier then we will also know the type of that credential based on the id.
On Mon, 10 Feb 2025 at 17:39, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
The authcid is how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that for FAST we put a token id there, which will of course convey the account in question to the server as well (since a token is only valid for a single account).
The server would need to know that FAST is being used in order to know it's not a username, but my understanding is that a reason for proposing this is to remove the explicit indication to the server that this is a FAST authentication. Right?
1) The type of credential being used (password, FAST token, bearer token, etc.) 2) In some cases, some identifier of the credential being used (when the same user has multiple credentials of the same type, common with tokens)
I think these are basically the same thing. We need to know what credential is being used. If we have an identifier then we will also know the type of that credential based on the id.
Well, passwords don't have such identifiers, only the username. It feels somewhat hacky to override the meaning of authcid in this way. I'd perhaps be okay with defining the authcid as a credential id, except that it currently is not, and I definitely don't like the idea of it sometimes containing a username and sometimes something else. That's just asking for mix-ups, with potentially bad consequences. Regards, Matthew
Somebody claiming to be Matthew Wild wrote:
On Mon, 10 Feb 2025 at 17:39, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
The authcid is how we convey the authenticating username.
Yes I understand that's what currently is placed there. I'm proposing that for FAST we put a token id there, which will of course convey the account in question to the server as well (since a token is only valid for a single account).
The server would need to know that FAST is being used in order to know it's not a username, but my understanding is that a reason for proposing this is to remove the explicit indication to the server that this is a FAST authentication. Right?
Your concern is namepace collision between username and a fast token id if the ids are also valid usernames? I think since the IDs are fully under the control of the server this isn't a problem is practise is it? The server would not assign any credential (including FAST tokens) an id that is an existing username, and would not allow creation of an account with username that matches any existing credential id. Username is the credential ID for the "primary account password" as used today.
On Mon, 13 Jan 2025 at 11:52, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0484.
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in the introduction and requirements?
Yes
3. Do you plan to implement this specification in your code? If not, why not?
N/A (currently, at least).
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes BUT... I think we may have a problem with the replay protection included in this layer. Many many apologies for not having reviewed this until now. Or, you know, if I knew about this before, I'd forgotten it, which I'm also sorry for if this is the case. When I designed CLIENTKEY - draft-cridland-kitten-clientkey-00 - Client Key SASL mechanism <https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/> - it was designed such that it, too, had replay protection built-in to the SASL mechanism. When discussing this with various people at the IETF, it was suggested that having a write for each authentication would be extremely expensive in some environments, preventing the usage (LDAP was given as an example here). Similarly, for clustered implementations this required a coordinated write (and possibly a lock); otherwise it might be possible to replay a session almost-concurrently and quickly enough to hit another cluster node successfully. Anyway, a lot of push-back, which is why I decided not to actively progress CLIENTKEY. There's an additional concern at the back of my mind, which is that this all represents a bit of a layer violation, which might be important or might not be. So... One option here is to (as I did with CLIENTKEY) move the replay concern into the SASL mechanism. I don't think this is a bad option; clients should be expected to know the security properties of the SASL mechanisms they use, and to know whether it's safe to use within TLS early data. But it does mean servers cannot enforce (or at least, servers cannot easily enforce) that an unsuitable mechanism hasn't been used in early data and thus at risk of replay. Another is to require it anyway at the FAST layer rather than the SASL mechanism layer. This has advantages, but does mean that if the IETF ever did take up CLIENTKEY or similar mechanisms with built-in replay protection - I mean, other than DIGEST-MD5 - we're doing everything twice. And it also means that the IETF might end up standardizing the other model. Anyway, this is all very late - but I think we need consensus on an approach prior to moving this along the track. Dave.
On 13/01/2025 12.50, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0484.
Title: Fast Authentication Streamlining Tokens Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip.
URL: https://xmpp.org/extensions/xep-0484.html
This Last Call begins today and shall end at the close of business on 2025-01-27.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yep.
2. Does the specification solve the problem stated in the introduction and requirements?
Si!
3. Do you plan to implement this specification in your code? If not, why not?
Unfortunately, the time I can dedicate to voluntary XMPP development has become scarce. I hope the situation will change again.
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. 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? 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? - Flow 1: See also the relevant paragraph about 0-RTT in https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#name-i...
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
On 10/02/2025 18.07, Matthew Wild wrote:
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).
But in the scenario I depicted, the authentication would succeed.
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
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.
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 Thu, 13 Feb 2025 at 10:42, Florian Schmaus <flo@geekplace.eu> wrote:
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.
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.
Sorry, I think I understand now. The missing part is the assumption that the attacker will block the original handshake and that client will retry on failure. So the repeated transmission is actually coming from the client itself generating a new packet, not from the attacker duplicating things. If the client does not increase the count unless the server responds with <success/>, doesn't that fix this issue? But my confidence is certainly decreasing at this point. I generally dislike the use of timestamps for things like this. Either something is safe, or it's not. Reducing the unsafe part to a small time window is almost certainly going to remain unacceptably unsafe in some circumstances.
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.
FWIW I do care about round trips, but I'm not trying to be fanatical about it :) I don't think anyone implements 0-RTT at this point, and I don't know how much anyone actually cares right now, considering the other savings we've already achieved. Regards, Matthew
On 13/02/2025 12.00, Matthew Wild wrote:
On Thu, 13 Feb 2025 at 10:42, Florian Schmaus <flo@geekplace.eu> wrote:
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.
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.
Sorry, I think I understand now. The missing part is the assumption that the attacker will block the original handshake and that client will retry on failure. So the repeated transmission is actually coming from the client itself generating a new packet, not from the attacker duplicating things.
Not only that. The attacker could "hold" the original packet and the client will run into a timeout, potentially assuming that the packet did not reach the server and that the "commands" in the packet where not executed. Afterwards, the attacker could replay the packet, causing the packet's "commands" to be executed. This could leave the client in a state where its assumption about what happened to be different from what actually happened. For example, the client may appear online to others, while it considers itself being offline. This can just be fixed by only including the data required for authentication in the 0-RTT packet and performing everything else, in particular resource binding, in a subsequent step.
If the client does not increase the count unless the server responds with <success/>, doesn't that fix this issue? But my confidence is certainly decreasing at this point.
The only fix is for the 0-RTT data to exclusively contain material used for authentication. Then an attack replaying the packet could "just" authenticate the connection, but this connection would be unusable for the attacker as they don't actually possess the TLS key material.
I generally dislike the use of timestamps for things like this. Either something is safe, or it's not. Reducing the unsafe part to a small time window is almost certainly going to remain unacceptably unsafe in some circumstances.
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.
FWIW I do care about round trips, but I'm not trying to be fanatical about it :) I don't think anyone implements 0-RTT at this point, and I don't know how much anyone actually cares right now, considering the other savings we've already achieved.
Right, but there is no need to close the door on 0-RTT yet. We need some more implementation experience before we decide that. But as of now, we certainly should not force 0-RTT implementers to shove more than the data required for authentication into the 0-RTT packet. - Flow
I know the last call is already over, but we should not advance that spec to stable until the underlying I-D for HT tokens is stable. For example, the latest version of the HT draft adds a 0x00/0x01 prefix to the responder message to indicate success or failure. I suggest to do a namespace bump of FAST once the HT I-D becomes an RFC and then reference that RFC in FAST. -tmolitor Am Montag, 24. Februar 2025, 12:41:48 CET schrieb Florian Schmaus:
On 13/02/2025 12.00, Matthew Wild wrote:
On Thu, 13 Feb 2025 at 10:42, Florian Schmaus <flo@geekplace.eu> wrote:
1: See also the relevant paragraph about 0-RTT in https://datatracker.ietf.org/doc/html/draft-schmaus-kitten-sasl-ht-10#n ame-initiator-first-message
I think this text is overly restrictive, as explained above.
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.
Sorry, I think I understand now. The missing part is the assumption that the attacker will block the original handshake and that client will retry on failure. So the repeated transmission is actually coming from the client itself generating a new packet, not from the attacker duplicating things.
Not only that.
The attacker could "hold" the original packet and the client will run into a timeout, potentially assuming that the packet did not reach the server and that the "commands" in the packet where not executed. Afterwards, the attacker could replay the packet, causing the packet's "commands" to be executed. This could leave the client in a state where its assumption about what happened to be different from what actually happened.
For example, the client may appear online to others, while it considers itself being offline.
This can just be fixed by only including the data required for authentication in the 0-RTT packet and performing everything else, in particular resource binding, in a subsequent step.
If the client does not increase the count unless the server responds with <success/>, doesn't that fix this issue? But my confidence is certainly decreasing at this point.
The only fix is for the 0-RTT data to exclusively contain material used for authentication. Then an attack replaying the packet could "just" authenticate the connection, but this connection would be unusable for the attacker as they don't actually possess the TLS key material.
I generally dislike the use of timestamps for things like this. Either something is safe, or it's not. Reducing the unsafe part to a small time window is almost certainly going to remain unacceptably unsafe in some circumstances.
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.
FWIW I do care about round trips, but I'm not trying to be fanatical about it :) I don't think anyone implements 0-RTT at this point, and I don't know how much anyone actually cares right now, considering the other savings we've already achieved.
Right, but there is no need to close the door on 0-RTT yet. We need some more implementation experience before we decide that. But as of now, we certainly should not force 0-RTT implementers to shove more than the data required for authentication into the 0-RTT packet.
- Flow
I know the last call is already over, but we should not advance that spec to stable until the underlying I-D for HT tokens is stable.
This is a good thought, but fast doesn't rely on or mandate HT so I dint think it affects the xep per se? I'm aware that in prrctise implementations are using HT before it is stable which is a problem for these implementations.
Hi, On Fri, Dec 12, 2025 at 4:03 AM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I know the last call is already over, but we should not advance that spec to stable until the underlying I-D for HT tokens is stable.
This is a good thought, but fast doesn't rely on or mandate HT so I dint think it affects the xep per se?
I'm aware that in prrctise implementations are using HT before it is stable which is a problem for these implementations.
couple of things: I think FAST is adding some real benefit to the ecosystem. I believe three servers have support for it and a forth one is currently working on the implementation. I think we should do our best to try to advance this XEP one way or another. As a community we should try to avoid having slightly imperfect things that are widely deployed and clearly useful but are stagnated due their imperfectness. (I think for a while Carbons was a good example for what I think we should try to avoid) As Stephen pointed out the XEP is _technically_ independent of Hashed Tokens (but also not really in practice). Implementing HT before it becomes stable is something one can probably just deal with. I don’t think it posses major challenges (at least not with the changes that have been made so far) However the IETF isn’t a magical place where we send HT to and just wait for them to do their job. Kitten is not a super active WG and we (the XMPP community) are a major stake holder in SASL (one of the few stake holders that there are). So if we want this to go through the IETF it is us (our community) that needs to actively push it through the WG and the process. So if we have community consensus that we want an HT RFC before we stabilize FAST we need to get active here. I will be at IETF125 in Shenzhen in March. Maybe we can convince the Kitten WG to have a meeting there (They didn’t have a meeting at the last two IETFs) but I would also appreciate additional support from people who have more experience with the IETF on how we can get HT trough. I guess the second open question for this XEP is whether or not the 0rtt is appropriate for which my personal answer is I just don’t know. I can write an implementation because Java lacks the API so I guess we have to wait for people like Thilo to provide their input on that. cheers Daniel
Given that the "counter" for FAST does nothing to prevent replay attacks (see flows mails in this thread) and nobody currently implements 0rtt (afaik), I'd say we remove the whole 0rtt from the spec. We can always create a dedicated 0rtt spec later on if we feel this is needed (and the security part of it has been sorted out appropriately). This means we can remove the <fast> element inside the <authenticate> element altogether since this was only there to communicate the counter and the SASL mechanism name already conveys we are using FAST. I can draft a PR to do this :) Regarding the HT token reference: yes, we should try harder to advance that at the IETF. Daniel, your presence at IETF125 could help there. I won't be able to attend, but I'm willing to help remotely :) -tmolitor Am Freitag, 12. Dezember 2025, 15:43:26 CET schrieb Daniel Gultsch:
Hi,
On Fri, Dec 12, 2025 at 4:03 AM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I know the last call is already over, but we should not advance that spec to stable until the underlying I-D for HT tokens is stable.
This is a good thought, but fast doesn't rely on or mandate HT so I dint think it affects the xep per se?
I'm aware that in prrctise implementations are using HT before it is stable
which is a problem for these implementations.
couple of things: I think FAST is adding some real benefit to the ecosystem. I believe three servers have support for it and a forth one is currently working on the implementation. I think we should do our best to try to advance this XEP one way or another. As a community we should try to avoid having slightly imperfect things that are widely deployed and clearly useful but are stagnated due their imperfectness. (I think for a while Carbons was a good example for what I think we should try to avoid)
As Stephen pointed out the XEP is _technically_ independent of Hashed Tokens (but also not really in practice). Implementing HT before it becomes stable is something one can probably just deal with. I don’t think it posses major challenges (at least not with the changes that have been made so far)
However the IETF isn’t a magical place where we send HT to and just wait for them to do their job. Kitten is not a super active WG and we (the XMPP community) are a major stake holder in SASL (one of the few stake holders that there are). So if we want this to go through the IETF it is us (our community) that needs to actively push it through the WG and the process.
So if we have community consensus that we want an HT RFC before we stabilize FAST we need to get active here. I will be at IETF125 in Shenzhen in March. Maybe we can convince the Kitten WG to have a meeting there (They didn’t have a meeting at the last two IETFs) but I would also appreciate additional support from people who have more experience with the IETF on how we can get HT trough.
I guess the second open question for this XEP is whether or not the 0rtt is appropriate for which my personal answer is I just don’t know. I can write an implementation because Java lacks the API so I guess we have to wait for people like Thilo to provide their input on that.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
SASL mechanism name already conveys we are using FAST.
Unfortunately it does not. Fast can use any sasl mechanism and HT can be lsed for things odher than fast. This is the whole reason fast has a second layer os sasl mechanism negotiations. Though I'd love to see this replaced with authcid or similar
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Matthew Wild -
Stephen Paul Weber -
Thilo Molitor