XEP-0440: SASL Channel-Binding Type Capability

1. Introduction¶

SASL channel-binding is a technique to increase the security of connections (RFC 5056 [1]). Unfortunately, the SASL profile specified in RFC 6120 [2] lacks a method for the server to announce its supported channel-binding types. This hinders the adoption of channel-binding, especially since the error protocol to execute after a client requested a channel-binding type unsupported by the server is basically unspecified.

The extension defined herein fills the gap left by RFC 6120 [2], by allowing the server to announce its supported channel-binding types.

2. Announcing the SASL Channel-Binding Type Capability¶

This protocol consists of a stream feature named <sasl-channel-binding/> qualified by the 'urn:xmpp:sasl-cb:0' namespace. The <sasl-channel-binding/> element MUST contain one or more <channel-binding/> elements, of which each MUST have an attribute with the name 'type'. The value of the 'type' attribute SHOULD be the "Channel-binding unique prefix" of a channel-binding type which was registered with the IANA Channel-Binding Types Registry [3].

A server declares that it supports particular channel-binding types by listing the supported types via the <sasl-channel-binding/> stream feature defined herein. The <sasl-channel-binding/> element could appear next to the SASL <mechanisms/> stream-feature element, qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in RFC 6120 [2]. Another potential appearance of <sasl-channel-binding/> is next to the <authentication/> stream-feature element as specified in the Extensible SASL Profile (XEP-0388) [4].

<stream:features>
  <sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
    <channel-binding type='tls-server-end-point'/>
    <channel-binding type='tls-exporter'/>
  </sasl-channel-binding>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>EXTERNAL</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
</stream:features>

<stream:features>
  <sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
    <channel-binding type='tls-server-end-point'/>
    <channel-binding type='tls-exporter'/>
  </sasl-channel-binding>
  <authentication xmlns='urn:xmpp:sasl:2'>
    <mechanism>SCRAM-SHA-1</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <inline>
      <sm xmlns='urn:xmpp:sm:3'/>
      <bind xmlns='urn:xmpp:bind:0'/>
    </inline>
  </authentication>
</stream:features>

3. Business Rules¶

Client developers MUST follow the following rules to ensure that implementing this specification in conjunction with SCRAM (RFC 5802 [5]) or any other equivalent SASL mechanism supporting channel-binding does not introduce a MITM attack vector. The rules are specifically taylored to SCRAM. For other SASL mechanisms supporting channel-binding, client developers MUST use the equivalent to "y" and "n" defined by those mechanisms.

1. Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no stronger channel-binding method is mutually supported.
2. If the client doesn't support channel-binding, it MUST send "n" in the GSS-header (see RFC 5802 [5]).
3. If the client supports channel-binding, but the server announced neither SASL mechanisms supporting channel-binding nor channel-binding types (via this specification), it MUST send "y" in accordance to RFC 5802 [5].
4. If the client is using SASL2 (Extensible SASL Profile (XEP-0388) [4]) to authenticate and received announcements for SASL mechanisms supporting channel-binding from the server, but no channel-binding types, it MUST abort the authentication (this is either an implementation error or ongoing MITM attack where channel-binding types are stripped). This condition is undefined with SASL1 (RFC 6120 [2]), but the client MAY also abort authentication in this case (or it MAY try authentication using tls-server-end-point or any other channel-binding mechanism).
5. If the client is using SASL2 to authenticate and it receives channel-binding announcements, from the server, but no SASL mechanisms supporting channel-binding are announced, it MUST abort authentication (this is an implementation error or ongoing MITM attack where SASL mechanisms are stripped). It SHOULD do the same when using SASL1.
6. If the client is using either SASL1 or SASL2 to authenticate and receives announcements for SASL mechanisms supporting channel-binding and channel-binding types, but none of these announced channel-binding types are supported by it, it MUST abort authentication, if tls-server-end-point is also not advertised by the server (this is an ongoing MITM attack, as per our first rule above).
7. The client SHOULD use a channel-binding stronger than tls-server-end-point, if advertised by the server and implemented by it (that is: set the p=<channel-binding-name> GSS-header to that channel-binding type according to RFC 5802 [5]).

When implementing SASL SCRAM Downgrade Protection (XEP-0474) [6] the above rules might be relaxed a bit, see that specification for details.

A more sophisticated attacker managing to steal the certificate and private key of the server won't be detected by the tls-server-end-point channel-binding. Clients and servers SHOULD implement stronger channel-binding types like tls-exporter, to detect and prevent such attacks

4. Security Considerations¶

The following considerations refer to SCRAM, as it is the only widely depolyed mechanism with channel binding at the time of writing this document. As already stated in the Business Rules, other mechanisms supporting channel-binding will have some sort of equivalent for "y" and "n".

In SCRAM (RFC 5802 [5]) the client-first-message contains three possible values in the GSS-header part:

1. y - The client would have used channel-binding, but the server did not offer any.
2. n - The client does not support channel-binding (even if the server offered any).
3. p=<cb-name> - The name of the channel-binding, the client wants to use.

The RFC explains, that sending "y" when the server advertised channel-binding support is to be used as a MITM-detection. An attacker stripping out all *-PLUS variants can be detected this way: the server knows it advertised them and the client reports via "y", that it would have used them if it saw them advertised, so the server can abort the authentication in this case.

This works reasonably well, if there is only one single channel-binding possible. But that's the exact assumption this specification now changes: it is now possible to advertise a list of different channel-bindings for the client to choose.

But this creates a problem: what to do if the server advertised a list of channel-binding algorithms, but the client doesn't support any of these? Assuming there is no MITM attacker present, the client can't send "y" in the GSS-header, because the server would then abort the authentication because it advertised channel-bindings. Sending "n" and continuing without channel-binding is fine in this case, but it won't be if a MITM attacker were present. [7]

Any MITM attacker could just manipulate the list of channel-bindings advertised using this specification to just list some dummy mechanisms the client doesn't support. If the client acted like in the non-attacker case depicted in the last paragraph and sent "n", the attacker would have successfully downgraded the client to non-channel-binding. The client won't be able to distinguish the attacker case from the non-attacker one.

The rules in the Business Rules section fix that loophole. Tls-server-end-point was picked, because it is the lowest denominator that can be implemented by virtually everyone and even though it isn't as strong as tls-exporter or tls-unique, it still catches many attacks. This only works reliably, if every server supports and announces tls-server-end-point.

A client following the rules above and seeing a server-advertised list without tls-sever-end-point, immediately knows, that some attacker tampered with the list of channel-binding types and can abort the authentication. It never needs to send "n" even though it supports channel-binding and can still safely send "y" if it doesn't see any '*-PLUS' variants and channel-bindings announced.

5. IANA Considerations¶

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].

6. XMPP Registrar Considerations¶

Add the 'urn:xmpp:sasl-cb:0' namespace to the registry:

<var>
  <name>urn:xmpp:sasl-cb:0</name>
  <desc>Expose supported channel-binding types to clients</desc>
  <doc>XEP-0440</doc>
</var>

7. XML Schema¶

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    xmlns='urn:xmpp:sasl-cb:0'
    targetNamespace='urn:xmpp:sasl-cb:0'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0440: https://xmpp.org/extensions/xep-0440.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='sasl-channel-binding'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='channel-binding' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='channel-binding'>
    <xs:complexType>
      <xs:attribute name='type' type='xs:string'/>
    </xs:complexType>
  </xs:element>

</xs:schema>

8. Acknowledgements¶

Thanks to Sam Whited for the discussion about the underlying issue and incentivizing me to come up with this extension. Further thanks goes to Ruslan N. Marchenko for pointing out the possible MITM attack vector. Last but not least, Dave Cridland, Thilo Molitor, and Simon Josefsson provided valuable feedback.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0440

Publisher

XMPP Standards Foundation

Status

Proposed

Type

Standards Track

Version

0.5

Last Updated

2025-10-25

Approving Body

XMPP Council

Dependencies

XMPP Core

Supersedes

None

Superseded By

None

Short Name

sasl-cb-types

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Florian Schmaus

Email

flo@geekplace.eu

JabberID

flo@geekplace.eu

Thilo Molitor

Email

thilo+xmpp@eightysoft.de

JabberID

thilo.molitor@juforum.de

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.5 (2025-10-25)¶
   • Address a possible MITM attack vector by making the tls-server-end-point channel-binding mandatory to implement
   • Remove the whole 'Interaction with SASL mechanisms' section and replace it with 'Business Rules'
   • Rework whole 'Security Considerations' section
   • Some minor editorial changes
   • Add Thilo Molitor as author
   tm
2. Version 0.4.2 (2024-07-02)¶
   • Add an XML schema.
   • Mention that this specification does add a new namespace that should go to the registrar.
   • Fix indentation, typos, misuse of '' vs. </> for elements, etc.
   egp
3. Version 0.4.1 (2024-01-30)¶
   Recommend the usage of tls-exporter over tls-server-end-point
   fs
4. Version 0.4.0 (2022-09-21)¶
   Make sasl-channel-binding element a top level stream feature
   dg
5. Version 0.3.0 (2022-08-29)¶
   Make implementation of tls-server-end-point a MUST for servers.
   tm
6. Version 0.2.0 (2020-08-04)¶
   Discuss interaction with SASL mechanism and add security considerations. Recommend implementation of tls-server-end-point.
   fs
7. Version 0.1.0 (2020-06-14)¶
   Accepted by vote of Council on 2020-05-27.
   XEP Editor (jsc)
8. Version 0.0.1 (2020-05-20)¶

   First draft.

   fs

Appendix I: Bib(La)TeX Entry

@report{schmaus2020sasl-cb-types,
  title = {SASL Channel-Binding Type Capability},
  author = {Schmaus, Florian and Molitor, Thilo},
  type = {XEP},
  number = {0440},
  version = {0.5},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0440.html},
  date = {2020-05-20/2025-10-25},
}

END