24 Oct
2025
24 Oct
'25
10:24 a.m.
Thank you Thilo.
On Fri, Oct 24, 2025 at 4:00 AM Thilo Molitor <thilo(a)eightysoft.de> wrote:
Yes I guess with this ruleset in place defining a common, mandatory to
implement channel binding mechanism makes sense.
But this set of rules is definitely not obvious and I wasn’t really
aware of that even though I consider myself as having some experience
with the whole channel binding/SASL2 stack.
So yeah. IDK. scrap the entire Security Considerations and replace it
with that. ^
To put what
you wrote into actionable terms for the client developer:
"If a client sees that that the server has 0440 support it MUST set
the 'y' flag regardless of the concrete binding mechanisms announced
by the server"
Is this a correct summary of what you wrote?
No, no. Lets try to explain it from
the client developer perspective.
As a client developer, do the following:
0) Servers MUST implement tls-server-end-point and enable/advertise it.
Clients SHOULD implement tls-server-end-point and use it if no other
(stronger) channel-binding method is supported by both sides.
1) If you don't support channel-binding, you MUST send "n" in the
GSS-header
(RFC 5802).
2) If you support channel-binding, but you neither got SCRAM-*-PLUS nor
XEP-0440 channel-bindings announced by the server, you MUST send "y" (RFC
5802).
3) If you're using SASL2 to authenticate and got SCRAM-*-PLUS, but no XEP-0440
announced, you MUST abort the authentication (this is either an implementation
error or MITM). This is undefined with SASL1, but you MAY abort authentication
in this case (or just randomly pick a channel-binding and hope for the best).
4) If you're using SASL2 and see XEP-0440 channel-bindings announced, but no
SCRAM-*-PLUS methods, you MUST abort authentication (implementation error or
MITM). You SHOULD do the same when using SASL1.
5) If you're using SASL1 or SASL2 and see SCRAM-*-PLUS methods and XEP-0440
channel-bindings announced, but *none* of these channel-binding types are
supported by you and tls-server-end-point isn't advertised by the server, you
MUST abort authentication (this is a MITM, as per rule 0). You SHOULD of
course use a channel-binding stronger than tls-server-end-point, if advertised
by the server and implemented by you (set the p=<channel-binding-name> GSS-
header).
6) All of this applies equally to other mechanisms that, like SCRAM, support
channel binding.
I hope this makes it more clear. I'm happy to draft a PR to add this list to
the XEP, if you want me to.
Rule 0 is essentially what we were discussing in this thread.
Yeah. But until now we have been discussing it without the context.
We should move
that out of the "Security Considerations" section and replace the entire
"Interaction with SASL mechanisms" section with the above list (see below).
My explanation why this is needed (from my last mail) could then go into the
Security Considerations section.
Yeah I don’t have strong feelings of where in the XEP to put exactly
what. But this should probably all go somewhere.
In any case all that are only arguments for having one required
binding mechanism. This still leaves the question if enough time has
passed that we can make exporter that mechanism.
cheers
Daniel