Sorry, in my previous e-mail, I have forgotten to specify the draft-melnikov-sasl2 IETF Internet-Drafts too: - https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2 You can see the Channel Binding here: - https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2#name-channel-bin… I have done several remarks to Alexey Melnikov (the author) about SCRAM, Channel Binding and SASL2. And I have done several remarks before publication of the "RFC 9266: Channel Bindings for TLS 1.3" too which specify the "tls-exporter". Regards, BOCQUET Ludovic ________________________________________ From: Ludovic BOCQUET <lbxmpp(a)live.com> Sent: Wednesday, November 5, 2025 3:52 PM To: XMPP Standards Subject: [Standards] Re: XEP-0440 No supported channel bindings Hello Dave, I am happy to read you here :) Recall, several months ago, I have asked you if your Openfire SASL2 PR will fix missing Channel Binding support in Openfire: - https://github.com/igniterealtime/Openfire/pull/2795 The Openfire JIRA tickets are: - https://igniterealtime.atlassian.net/browse/OF-2879 - https://igniterealtime.atlassian.net/browse/OF-2878 - https://igniterealtime.atlassian.net/browse/OF-2762 - https://igniterealtime.atlassian.net/browse/OF-2694 The Channel Binding support is requested by a lot of people since several years for security. A lot of companies or projects use it, for example : Microsoft, PostgreSQL, ... For the XMPP World, it is in RFC 6120 since March 2011 (15 years in few months): - https://datatracker.ietf.org/doc/html/rfc6120 It is supported by other XMPP Servers: DJabberd, ejabberd (ProcessOne), Jackal IM, M-Link (Isode), Metronome IM, MongooseIM (Erlang Solutions), Prosody IM, Snikket, Tigase XMPP Server. I do not specify the number of XMPP Clients and XMPP Libraries which support it too. Regards, BOCQUET Ludovic ________________________________________ From: Dave Cridland <dave(a)cridland.net> Sent: Wednesday, November 5, 2025 10:57 AM To: XMPP Standards Subject: [Standards] XEP-0440 No supported channel bindings Thilo, sorry! I had somehow missed that SASL2 mandates XEP-0440. It makes a lot of sense. But... Openfire currently doesn't support any channel bindings. It is sometimes used in cases where there is no TLS at all. This is quite deliberate and sensible in this case, please don't argue with this! This means there will always be cases where there are no channel bindings available (because there's no channel to bind to!). The schema doesn't include a minOccurs, and that means minOccurs='1' by default. This means at least one channel binding MUST be included. Is this intentional? I appreciate this is an oddball case (and I can support tls-server-endpoint for most normal cases), but is this the intent here or was the expectation that the minOccurs should be '0'? (I know tls-server-endpoint MUST be implemented, but MTI is not MTD etc). Dave. _______________________________________________ Standards mailing list -- standards(a)xmpp.org To unsubscribe send an email to standards-leave(a)xmpp.org