xeps/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>Experimental</status>
  <type>Informational</type>
  <jig>Standards JIG</jig>
  <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>0.4</version>
    <date>2006-08-02</date>
    <initials>psa</initials>
    <remark>Modified recommended order of for server-to-server negotiations if service provisioning requires dialback after TLS negotiation.</remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2006-01-24</date>
    <initials>psa</initials>
    <remark>Split into client-to-server and server-to-server sections; specified recommended order of server-to-server negotiations.</remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2006-01-16</date>
    <initials>psa</initials>
    <remark>Changed order of SASL and stream compression to reflect list discussion.</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2006-01-11</date>
    <initials>psa</initials>
    <remark>Initial version.</remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2006-01-10</date>
    <initials>psa</initials>
    <remark>First draft.</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>
      <li>IM session establishment</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 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>
      <li>Resource binding</li>
      <li>IM session establishment</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>
      <li>IM session establishment</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>
      <li>IM session establishment</li>
    </ol>
  </section2>
  <section2 topic='Non-SASL Authentication' anchor='c2s-iqauth'>
    <p>The legacy &xep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>jabber:iq:auth</li>
    </ol>
    <p>If the "jabber:iq:auth" feature is negotiated, then SASL, resource binding, and IM session establishment MUST NOT be negotiated. TLS SHOULD be negotiated, but some older software will instead connect to an SSL-enabled port rather than upgrading port 5222 using TLS.</p>
    <p>If both stream compression and non-SASL authentication are negotiated, the following order is RECOMMENDED:</p>
    <ol>
      <li>TLS</li>
      <li>jabber:iq:auth</li>
      <li>Stream compression</li>
    </ol>
  </section2>
  <section2 topic='Advanced Message Processing' anchor='c2s-amp'>
    <p>Support for the &xep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.</p>
  </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 TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo 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>