First draft.
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.
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.
+ +