xep-0170.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Recommended Order of Stream Feature Negotiation</title>
  <abstract>This document specifies a recommended order for negotiation of XMPP stream features.</abstract>
  &LEGALNOTICE;
  <number>0170</number>
  <status>Active</status>
  <type>Informational</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0077</spec>
    <spec>XEP-0079</spec>
    <spec>XEP-0138</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>N/A</shortname>
  &stpeter;
  <revision>
    <version>1.0</version>
    <date>2007-01-04</date>
    <initials>psa</initials>
    <remark><p>Per a vote of the XMPP Council, advanced status to Active.</p></remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2006-12-06</date>
    <initials>psa</initials>
    <remark><p>Per Council feedback, removed section on deprecated jabber:iq:auth protocol.</p></remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2006-08-02</date>
    <initials>psa</initials>
    <remark><p>Modified recommended order of for server-to-server negotiations if service provisioning requires dialback after TLS negotiation.</p></remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2006-01-24</date>
    <initials>psa</initials>
    <remark><p>Split into client-to-server and server-to-server sections; specified recommended order of server-to-server negotiations.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2006-01-16</date>
    <initials>psa</initials>
    <remark><p>Changed order of SASL and stream compression to reflect list discussion.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2006-01-11</date>
    <initials>psa</initials>
    <remark><p>Initial version.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2006-01-10</date>
    <initials>psa</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>During its formalization of the core Jabber protocols, the IETF's XMPP WG introduced the concept of XML stream features. While the order in which features shall be negotiated is clearly defined for the features specified in &rfc3920; and &rfc3921;, the number of possible features is open-ended (which is why the &REGISTRAR; maintains a registry of stream features). This document specifies the recommended order for negotiation of various stream features.</p>
</section1>
<section1 topic='Client-to-Server Recommendations' anchor='c2s'>
  <section2 topic='Standard XMPP Features' anchor='c2s-xmpp'>
    <p>The XMPP RFCs define an ordering for the features defined therein, namely:</p>
    <ol>
      <li>TLS</li>
      <li>SASL</li>
      <li>Resource binding</li>
    </ol>
    <p>That order MUST be followed if no other stream features are negotiated.</p>
  </section2>
  <section2 topic='Stream Compression' anchor='c2s-compress'>
    <p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks caused by consumption of server resources for compression before the connecting entity is authenticated). Therefore the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>SASL</li>
      <li>Stream compression</li>
      <li>Resource binding</li>
    </ol>
  </section2>
  <section2 topic='In-Band Registration' anchor='c2s-register'>
    <p>The &xep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>In-band registration</li>
      <li>SASL</li>
      <li>Resource binding</li>
    </ol>
    <p>If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>In-band registration</li>
      <li>SASL</li>
      <li>Stream compression</li>
      <li>Resource binding</li>
    </ol>
  </section2>
</section1>
<section1 topic='Server-to-Server Recommendations' anchor='s2s'>
  <section2 topic='Standard XMPP Features' anchor='s2s-xmpp'>
    <p>The XMPP RFCs define an ordering for the features defined therein, namely:</p>
    <ol>
      <li>TLS</li>
      <li>SASL</li>
    </ol>
    <p>That order MUST be followed if no other stream features are negotiated.</p>
  </section2>
  <section2 topic='Dialback' anchor='s2s-dialback'>
    <p>RFC 3920 requires SASL negotiation after TLS negotiation. When the certificate presented by the initiating entity makes reference to a trusted root certification authority, SASL negotiation provides meaningful authentication. In that case, the order shown above is recommended.</p>
    <p>However, it is possible that the initiating entity will present a self-signed certificate or a certificate whose associated root certification authority is not trusted by the receiving entity. In this situation, service provisioning policies at the receiving entity may dictate the use of server dialback in order to provide a stronger level of trust for the server-to-server stream (where such trust is essentially trust in the underlying Domain Name System), even though server dialback explicitly does not provide authentication. In this case, the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>Dialback</li>
    </ol>
  </section2>
  <section2 topic='Stream Compression' anchor='s2s-compress'>
    <p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>SASL</li>
      <li>Stream compression</li>
    </ol>
    <p>If stream compression is negotiated in addition to TLS and dialback, it is RECOMMENDED to negotiate it after both TLS and dialback:</p>
    <ol>
      <li>TLS</li>
      <li>Dialback</li>
      <li>Stream compression</li>
    </ol>
  </section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.</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>
</xep>