%ents; ]>
Recommended Order of Stream Feature Negotiation This document specifies a recommended order for negotiation of XMPP stream features. &LEGALNOTICE; 0170 Experimental Informational Standards JIG Council XMPP Core XEP-0077 XEP-0079 XEP-0138 N/A &stpeter; 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
  4. IM session establishment

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

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

  1. TLS
  2. SASL
  3. Stream compression
  4. Resource binding
  5. IM session establishment

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
  5. IM session establishment

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
  6. IM session establishment

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:

  1. TLS
  2. jabber:iq:auth

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.

If both stream compression and non-SASL authentication are negotiated, the following order is RECOMMENDED:

  1. TLS
  2. jabber:iq:auth
  3. Stream compression

Support for the &xep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.

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

  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.