<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY rfc5056 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5056'>RFC 5056</link></span> <note>RFC 5056: On the Use of Channel Bindings to Secure Channels <<link url='http://tools.ietf.org/html/rfc5056'>http://tools.ietf.org/html/rfc5056</link>>.</note>" > <!ENTITY iana-cb-types "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>IANA Channel-Binding Types Registry</link></span> <note>IANA Channel-Binding Types Registry <<link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml</link>>.</note>" > <!ENTITY % ents SYSTEM 'xep.ent'> %ents; ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <xep> <header> <title>SASL Channel-Binding Type Capability</title> <abstract>This specification allows servers to annouce their supported SASL channel-binding types to clients.</abstract> &LEGALNOTICE; <number>xxxx</number> <status>ProtoXEP</status> <type>Standards Track</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> </dependencies> <supersedes/> <supersededby/> <shortname>sasl-cb-types</shortname> &flow; <revision> <version>0.0.1</version> <date>2020-05-20</date> <initials>fs</initials> <remark><p>First draft.</p></remark> </revision> </header> <section1 topic='Introduction' anchor='intro'> <p>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.</p> <p>The extension defined herein fills the gap left by &rfc6120;, by allowing the server the announce its supported channel-binding types.</p> </section1> <section1 topic='Announcing the SASL Channel-Binding Type Capability' anchor='sasl-cb-type'> <p>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;.</p> <p>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;.</p> <example caption='Example <mechanisms/> stream feature with SASL Channel-Binding Type Capability.'><![CDATA[ <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>EXTERNAL</mechanism> <mechanism>SCRAM-SHA-1-PLUS</mechanism> <mechanism>PLAIN</mechanism> <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> </stream:features>]]></example> </section1> <section1 topic='Security Considerations' anchor='security'> <p>The author belives that this document itself does not yield any new security considerations.<note>Hopefully somebody will correct him, in case he is wrong.</note></p> </section1> <section1 topic='IANA Considerations' anchor='iana'> <p>This document requires no interaction with &IANA;.</p> </section1> <section1 topic='XMPP Registrar Considerations' anchor='registrar'> <p>This document requires no interaction with the XMPP registrar.</p> </section1> <section1 topic='XML Schema' anchor='schema'> <p>TODO: Add if the XEP is scheduled for the state after 'experimental'.</p> </section1> <section1 topic='Acknowledgements' anchor='acknowledgements'> <p>Thanks to Sam Whited for the discussion about the underlying issue and incentivizing me to come up with this extension.</p> </section1> </xep>