RFC 5056 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.