xeps/inbox/cb-pseudomechanisms.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ianacb "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types'>IANA Channel-Binding Types Registry</link></span> <note>IANA registry of channel binding types &lt;<link url='https://www.iana.org/assignments/channel-binding-types'>https://www.iana.org/assignments/channel-binding-types</link>&gt;.</note>" >
<!ENTITY rfc7677 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7677'>RFC 7677</link></span> <note>RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms &lt;<link url='http://tools.ietf.org/html/rfc7677'>http://tools.ietf.org/html/rfc7677</link>&gt;.</note>" >
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Channel Binding Pseudomechanisms</title>
  <abstract>
    A method for advertising and negotiating types of channel binding supported
    by SCRAM based SASL mechanisms.
  </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>pseudomechanisms</shortname>
  &sam;
  <revision>
    <version>0.0.1</version>
    <date>2020-05-01</date>
    <initials>ssw</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>
    The SCRAM (&rfc5802;) family of SASL (&rfc4422;) mechanisms is widely used
    in XMPP.
    SCRAM supports channel binding to the underlying security layer to prevent
    replay attacks, but does not provide a means of negotiating the type of
    channel binding performed.
    Normally this means that XMPP defaults to the tls-unique channel binding
    method defined in &rfc5929;.
  </p>
  <p>
    This specification provides servers with a way to advertise what forms of
    channel binding they support, and for clients to choose a channel binding
    mechanism to use.
  </p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
  <ul>
    <li>
      Servers must be able to advertise multiple channel binding mechanisms.
    </li>
    <li>
      Clients must be able to pick a single supported SCRAM and channel binding
      mechanism.
    </li>
    <li>
      No extra round trips should be added to facilitate channel binding
      negotiation.
    </li>
  </ul>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
  <p>
    As a server operator I want to support different channel bindings depending
    on what version of TLS was negotiated.
  </p>
  <p>
    As a client I want to know if the server supports tls-server-end-point
    channel binding to verify that the server's certificate has not changed
    between negotiation attempts.
  </p>
</section1>
<section1 topic='Pseudomechanisms' anchor='mechanism'>
  <p>
    The SCRAM based mechanisms advertise their channel binding support by
    listing themselves with an added suffix, "-PLUS".
    This advertises that channel binding is possible, but not the actual channel
    binding types supported by the server.
    The "SCRAM-SHA-1-PLUS" mechanism is the same as the "SCRAM-SHA-1" mechanism,
    the "-PLUS" suffix does not fundamentally change the mechanisms behavior.
    This concept of a "pseudomechanism", a mechanism that is implemented in
    terms of another mechanism with minor changes to the name and behavior, can
    be extended to allow for the advertising of specific channel binding types
    in addition to whether channel binding is supported or not.
  </p>
  <p>
    To create such a pseudomechanism the server MUST concatenate the name of any
    "-PLUS" suffixed mechanism that it supports from the IANA SASL SCRAM Family
    Mechanisms Subregistry of the &ianasasl; with a colon (":") followed by the
    name of any channel binding data that it supports with the currently
    negotiated security layer from the &ianacb;.
    For example, if a TLS connection has been established and the server wants
    to advertise that it supports the SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS
    mechanisms with the tls-unique and tls-server-end-point channel binding
    types, it would list the following mechanisms:
  </p>
  <p>
    While the channel binding variants of SCRAM are registered in the
    &ianasasl;, the pseudomechanisms described in this document depend on values
    in the registry themselves and so are explicitly not meant to be listed.
    A mechanism with a conflicting name cannot be registered because these
    pseudomechanisms are deliberately in violation of the naming convention of
    the SCRAM family of mechanisms as defined in &rfc7677; to prevent such
    conflicts.
    Because they are not meant to represent full mechanisms for use outside of
    XMPP, they do not require registration or the issuance of a GSS-API
    mechanism OID.
  </p>
  <example caption='Host Advertises Mechanisms'><![CDATA[
<stream:features>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>SCRAM-SHA-256-PLUS</mechanism>
    <mechanism>SCRAM-SHA-256-PLUS:tls-unique</mechanism>
    <mechanism>SCRAM-SHA-256-PLUS:tls-server-end-point</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS:tls-unique</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS:tls-server-end-point</mechanism>
    <mechanism>SCRAM-SHA-256</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
  </mechanisms>
</stream:features>]]></example>
  <p>
    The original "-PLUS" suffixed mechanisms SHOULD continue to be listed and
    function as they did before (likely by defaulting to tls-unique) for the
    purpose of backwards compatibility.
  </p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>
    The Security Considerations sections from &rfc4422;, &rfc5802;, and
    &rfc7677; apply to this document.
  </p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document has no actions for IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>This document has no actions for the &REGISTRAR;.</p>
</section1>
</xep>