As with SASL mechanisms, today various different channel-binding types with varying strength can be used. SCRAM and the upcoming OPAQUE mechanism can use channel-binding to make sure the TLS channel is MITM-free (the "-PLUS" variants of SCRAM and OPAQUE).
You'll need channel-binding to make sure an attacker that is able to break into the TLS channel can not downgrade the used SASL mechanism to something weak enough for him to break. All of this is nice, but the current XMPP protocol flow - as implemented in servers/clients today - lacks a way to negotiate which channel-binding should be used by the client or server. If both do support multiple but only partially overlapping mechanisms, the client has to guess which one is also supported by the server. That can lead to authentication failures if the client uses a binding, the server does not know. XMPP lacks a way to indicate that the failed authentication was due to wrong channel-binding type used nor should we add such an indication for various security reasons. Sequentially probing all channel-binding methods a client supports would significantly extend the time needed to log in, too, which could exhaust the limited background time available on mobile platforms as well as degrade UX. Luckily all of this was already solved by Florian Schmaus in XEP-0440: SASL Channel-Binding Type Capability. We therefore made XEP-0440 mandatory to implement, if channel-binding is implemented by the server/client at all. Without implementing channel-binding, XEP-0440 is not needed, of course. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
