This XEP completes SASL2, but I figured that it was better to publish it as an extra XEP:
RFC 6120 [1] and Extensible SASL Profile (XEP-0388) [2] define a way to negotiate SASL mechanisms. When used together with SCRAM mechanisms (RFC 5802 [3]) and channel-binding (SASL Channel-Binding Type Capability (XEP-0440) [4]) the mechanism selection is protected against downgrade attacks by an active MITM tampering with the TLS channel and advertised SASL mechanisms, while the negotiation of the channel-binding types is still not protected against such downgrade attacks.
SASL Channel-Binding Type Capability (XEP-0440) [4] tries to mitigate this by making the "tls-server-end-point" (RFC 5929 [5]) channel-binding mandatory to implement for servers. But that leaves clients not able to implement this type, or any channel-binding at all, vulnerable to downgrades of channel-binding types and SASL mechanisms. Furthermore "tls-server-end-point" provides weaker security guarantees than other channel-bindings like for example "tls-exporter" (defined in RFC 5705 [6] and RFC 9266 [7]).
This specification aims to solve this issue by spcifying a downgrade protection for both SASL mechanisms and channel-binding types using an optional SCRAM attribute (RFC 5802 [3]).
This XEP completes SASL2, but I figured that it was better to publish it as an extra XEP:
RFC 6120 [1] and Extensible SASL Profile (XEP-0388) [2] define a way to negotiate SASL mechanisms. When used together with SCRAM mechanisms (RFC 5802 [3]) and channel-binding (SASL Channel-Binding Type Capability (XEP-0440) [4]) the mechanism selection is protected against downgrade attacks by an active MITM tampering with the TLS channel and advertised SASL mechanisms, while the negotiation of the channel-binding types is still not protected against such downgrade attacks.
SASL Channel-Binding Type Capability (XEP-0440) [4] tries to mitigate this by making the "tls-server-end-point" (RFC 5929 [5]) channel-binding mandatory to implement for servers. But that leaves clients not able to implement this type, or any channel-binding at all, vulnerable to downgrades of channel-binding types and SASL mechanisms. Furthermore "tls-server-end-point" provides weaker security guarantees than other channel-bindings like for example "tls-exporter" (defined in RFC 5705 [6] and RFC 9266 [7]).
This specification aims to solve this issue by spcifying a downgrade protection for both SASL mechanisms and channel-binding types using an optional SCRAM attribute (RFC 5802 [3]).