%ents; ]>
Recommended Order of Stream Feature Negotiation This document specifies a recommended order for negotiation of XMPP stream features. &LEGALNOTICE; 0170 Active Informational Standards Council XMPP Core XEP-0077 XEP-0079 XEP-0138 N/A &stpeter; 1.0 2007-01-04 psa

Per a vote of the XMPP Council, advanced status to Active.

 0.5 2006-12-06 psa

Per Council feedback, removed section on deprecated jabber:iq:auth protocol.

 0.4 2006-08-02 psa

Modified recommended order of for server-to-server negotiations if service provisioning requires dialback after TLS negotiation.

 0.3 2006-01-24 psa

Split into client-to-server and server-to-server sections; specified recommended order of server-to-server negotiations.

 0.2 2006-01-16 psa

Changed order of SASL and stream compression to reflect list discussion.

 0.1 2006-01-11 psa

Initial version.

 0.0.1 2006-01-10 psa

First draft.

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 ®ISTRAR; maintains a registry of stream features). This document specifies the recommended order for negotiation of various stream features.

The XMPP RFCs define an ordering for the features defined therein, namely:

  1. TLS
  2. SASL
  3. Resource binding

That order MUST be followed if no other stream features are negotiated.

&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:

  1. TLS
  2. SASL
  3. Stream compression
  4. Resource binding

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:

  1. TLS
  2. In-band registration
  3. SASL
  4. Resource binding

If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:

  1. TLS
  2. In-band registration
  3. SASL
  4. Stream compression
  5. Resource binding

The XMPP RFCs define an ordering for the features defined therein, namely:

  1. TLS
  2. SASL

That order MUST be followed if no other stream features are negotiated.

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.

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:

  1. TLS
  2. Dialback

&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:

  1. TLS
  2. SASL
  3. Stream compression

If stream compression is negotiated in addition to TLS and dialback, it is RECOMMENDED to negotiate it after both TLS and dialback:

  1. TLS
  2. Dialback
  3. Stream compression

The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.

This document requires no interaction with &IANA;.

This document requires no interaction with the XMPP Registrar.