Add SASL Channel-Binding ProtoXEP to inbox/

inbox/xep-sasl-cb-types.xml

@@ -0,0 +1,118 @@
+<?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 &lt;<link url='http://tools.ietf.org/html/rfc5056'>http://tools.ietf.org/html/rfc5056</link>&gt;.</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 &lt;<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>&gt;.</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 &lt;mechanisms/&gt;
+  stream-feature element, qualified by the
+  'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in
+  &rfc6120;. Another potential appearance of
+  &lt;sasl-channel-binding&gt; is as child element of the
+  &lt;mechanisms/&gt; stream-feature element as specified in the
+  &xep0388;.</p>
+
+  <example caption='Example &lt;mechanisms/&gt; 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>