SASL channel-binding is a technique to increase the security of connections (&rfc5056;). Unfortunately, the SASL profile specified in &rfc6120; 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 &rfc6120;, by allowing the server the announce its supported channel-binding types.

This protocol consists of a single optional extension element 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-cb-types;.

A server declares that it supports particular channel-binding types by listing the supported types via the 'sasl-channel-binding' element defined herein. The 'sasl-channel-binding' element could appear as child element to the SASL <mechanisms/> stream-feature element, qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in &rfc6120;. Another potential appearance of <sasl-channel-binding> is as child element of the <mechanisms/> stream-feature element as specified in the &xep0388;.

The author belives that this document itself does not yield any new security considerations.Hopefully somebody will correct him, in case he is wrong.

This document requires no interaction with &IANA;.

This document requires no interaction with the XMPP registrar.

TODO: Add if the XEP is scheduled for the state after 'experimental'.

Thanks to Sam Whited for the discussion about the underlying issue and incentivizing me to come up with this extension.