draft-ietf-kitten-sasl-ht-01 uploaded
[cc to standards@xmpp.org since it is of interest to the xmpp ecosystem] I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are - the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1]) SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from HT-SHA-512-ENDP to HT2-SHA-512-ENDP Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated. And, of course, feedback in general is welcomed. - Florian 1: https://xmpp.org/extensions/xep-0474.html
Hi Florian, On 12/05/2026 12:28, Florian Schmaus wrote:
[cc to standards@xmpp.org since it is of interest to the xmpp ecosystem]
I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are
- the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1])
SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from
HT-SHA-512-ENDP
to
HT2-SHA-512-ENDP
Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated.
I think the name is fine!
And, of course, feedback in general is welcomed.
- Florian
Best Regards, Alexey
On 12/05/2026 13.28, Florian Schmaus wrote:
I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are
- the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1])
SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from
HT-SHA-512-ENDP
to
HT2-SHA-512-ENDP
Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated.
And, of course, feedback in general is welcomed. I am going to ask the Kitten WG chair to initiate the next step for SASL-HT this week. Therefore, *now* would be a good time for feedback.
FAST (XEP-0484) is currently using draft-schmaus-kitten-sasl-ht-09. The diff between this version and the lastest can be viewed via https://author-tools.ietf.org/iddiff?url1=draft-schmaus-kitten-sasl-ht-09&ur... The latest version of sasl-ht uses the HT2-* prefix for its SASl mechanism name, instead of the HT-* prefix used by version -09. This name adjustment was necessary because the wire protocol changed slightly. It is perfectly fine for XEP FAST to continue using -09. Support for HT2-*, and its advantages, like support for SASL downgrade protection, can be deployed alongside it a later time (and shouldn't require any changes to XEP FAST). - Flow
I note that FAST introduces an external (to HT-*) counter as a replay protection. This feels like a layer violation, in as much as replay protection feels like it's a concern of the SASL mechanism. Previous attempts to get a mechanism with a coordinated counter through this working group were tricky, Chris Newman observed that for many distributed systems this was complex. Examples given were email clients simultaneously connecting to IMAP and Submission, and read-only LDAP "mirror" servers. (See https://datatracker.ietf.org/doc/html/draft-cridland-kitten-clientkey-00 for the design I abandoned in favour of HT-* for mostly this reason). So, question: Do we want to put a replay counter into HT2-*? (I'll send a follow-up to standards@xmpp.org concerning the 0-RTT replay case specifically) Dave. On Mon, 22 Jun 2026 at 09:09, Florian Schmaus <flo@geekplace.eu> wrote:
On 12/05/2026 13.28, Florian Schmaus wrote:
I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are
- the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1])
SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from
HT-SHA-512-ENDP
to
HT2-SHA-512-ENDP
Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated.
And, of course, feedback in general is welcomed. I am going to ask the Kitten WG chair to initiate the next step for SASL-HT this week. Therefore, *now* would be a good time for feedback.
FAST (XEP-0484) is currently using draft-schmaus-kitten-sasl-ht-09. The diff between this version and the lastest can be viewed via
https://author-tools.ietf.org/iddiff?url1=draft-schmaus-kitten-sasl-ht-09&ur...
The latest version of sasl-ht uses the HT2-* prefix for its SASl mechanism name, instead of the HT-* prefix used by version -09. This name adjustment was necessary because the wire protocol changed slightly. It is perfectly fine for XEP FAST to continue using -09. Support for HT2-*, and its advantages, like support for SASL downgrade protection, can be deployed alongside it a later time (and shouldn't require any changes to XEP FAST).
- Flow _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Greetings. I would advise to substitute the word "kitten" with a descriptive word; or, otherwise, remove it. I think that these words do not contribute to further the engagement with XMPP and related technologies; especially amongst academics and adults from Africa, Asia, Australia, and South America. Kind regards, Schimon On Tue, 12 May 2026 13:28:55 +0200 Florian Schmaus <flo@geekplace.eu> wrote:
[cc to standards@xmpp.org since it is of interest to the xmpp ecosystem]
I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are
- the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1])
SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from
HT-SHA-512-ENDP
to
HT2-SHA-512-ENDP
Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated.
And, of course, feedback in general is welcomed.
- Florian
I'm not sure I see the benefit of the key-value thing, does any other SASL mechanism have this? I'm not against it of course, just trying to understand. There had been previous discussion of including a timestamp or similar to prevent replay attacks with SASL-HT is that still being considered? Would be very nice.
participants (5)
-
Alexey Melnikov -
Dave Cridland -
Florian Schmaus -
Schimon -
Stephen Paul Weber