xeps/xep-0440.xml

<?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>0440</number>
  <status>Experimental</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.4.0</version>
    <date>2022-09-21</date>
    <initials>dg</initials>
    <remark>
      Make sasl-channel-binding element a top level stream feature
    </remark>
  </revision>
  <revision>
    <version>0.3.0</version>
    <date>2022-08-29</date>
    <initials>tm</initials>
    <remark>
      Make implementation of tls-server-end-point a MUST for servers.
    </remark>
  </revision>
  <revision>
    <version>0.2.0</version>
    <date>2020-08-04</date>
    <initials>fs</initials>
    <remark>
	  Discuss interaction with SASL mechanism and add security considerations.
	  Recommend implementation of tls-server-end-point.
	</remark>
  </revision>
  <revision>
    <version>0.1.0</version>
    <date>2020-06-14</date>
    <initials>XEP Editor (jsc)</initials>
    <remark>Accepted by vote of Council on 2020-05-27.</remark>
  </revision>
  <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 stream feature 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'
  stream feature defined herein. The 'sasl-channel-binding' element could
  appear next 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 next to the
  &lt;authentication/&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>
  <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 xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>EXTERNAL</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
</stream:features>]]></example>

</section1>

<section1 topic='Interaction with SASL mechanisms' anchor='sasl-mech-interaction'>

  <p>Some channel-binding enabled SASL mechanisms reflect the server's
  presumed channel-binding abilities back to the server. This prevents
  SASL-mechanism stripping attacks, where a Man in the Middle (MITM)
  removes certain SASL mechanisms in an attempt to downgrade the
  mechanism choosen for authentication to a non-channel-binding enabled
  one. An example of a SASL mechanism family with this feature is
  &rfc5802;. This standard specifies the gs2-cbind-flag. The flag has a
  tristate value of "I don't support channel-binding" (n), "I think you
  do not support channel-binding, but I do" (y), or, "Let us use
  channel-binding type X" (p).</p>

  <p>Clients using the information provided
  via &lt;sasl-channel-binding/&gt; MAY want to indicate to the server
  that they do not support channel-binding (even if they do) if no
  mutual supported channel-binding type was found. The only alternative
  is, that the client signals the server that he believes that the server
  does not support channel binding. But this may cause the server to
  terminate the connection, because it indicates a potential ongoing
  SASL-mechanism stripping attack.</p>

</section1>

<section1 topic='Security Considerations' anchor='security'>

  <p>If a client signals to the server that he does not support
  channel binding, because it found no mutual supported
  channel-binding types, another MITM attack
  vector is introduced. An active attacker could replace the
  &lt;sasl-channel-binding;&gt; list with channel bindings unlikely
  (or impossible) to be supported by the client. If the client is
  configured to use non-channel-binding SASL mechanisms as a fallback,
  this could be used to downgrade the connection security. Note that
  this attack is a different one than the SASL-mechanism stripping one:
  Here the attacker tempers with the announced channel-binding types,
  i.e., the values within &lt;sasl-channel-binding;&gt;</p>

  <p>Depending on the application's security policy, clients may
  refrain from falling back to non-channel-binding SASL mechanisms
  if no mutual supported channel-binding type is available.
  Alternatively, they may try channel-binding with a supported type
  nevertheless. To mitigate the attack describe above, clients
  could "pin" the announced channel bindings types by a service. In that
  case, implementations may want to allow the set of pinned channel-binding
  types to be extended to stronger ones.</p>

  <p>As further mitigation, servers MUST and clients are RECOMMENDED to
  at least implement the channel-binding type tls-server-end-point (&rfc5929;)
  to increase the probability of a mutual supported channel-binding type.</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. Further
  thanks goes to Ruslan N. Marchenko for pointing out the possible
  MITM attack vector. Last but not least, Dave Cridland and Thilo Molitor
  provided valuable feedback.</p>

</section1>

</xep>