JEP-0170: Recommended Order of Stream Feature Negotiation

This document specifies a recommended order for negotiation of XMPP stream features.


WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.


JEP Information

Status: Experimental
Type: Informational
Number: 0170
Version: 0.3
Last Updated: 2006-01-24
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0077, JEP-0079, JEP-0138
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Recommended Order of Stream Feature Negotiation (JEP-0170)>

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

1. Introduction
2. Client-to-Server Recommendations
2.1. Standard XMPP Features
2.2. Stream Compression
2.3. In-Band Registration
2.4. Non-SASL Authentication
2.5. Advanced Message Processing
3. Server-to-Server Recommendations
3.1. Standard XMPP Features
3.2. Stream Compression
3.3. Dialback
4. Security Considerations
5. IANA Considerations
6. Jabber Registrar Considerations
Notes
Revision History


1. Introduction

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 RFC 3920 [1] and RFC 3921 [2], the number of possible features is open-ended (which is why the Jabber Registrar [3] maintains a registry of stream features). This document specifies the recommended order for negotiation of various stream features.

2. Client-to-Server Recommendations

2.1 Standard XMPP 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.

2.2 Stream Compression

Stream Compression [4] 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

2.3 In-Band Registration

The In-Band Registration [5] 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. jabber:iq:register
  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. jabber:iq:register
  3. SASL
  4. Stream compression
  5. Resource binding
  6. IM session establishment

2.4 Non-SASL Authentication

The legacy Non-SASL Authentication [6] 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

2.5 Advanced Message Processing

Support for the Advanced Message Processing [7] protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.

3. Server-to-Server Recommendations

3.1 Standard XMPP Features

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

  1. TLS
  2. SASL [8]

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

3.2 Stream Compression

Stream Compression [9] 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

3.3 Dialback

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. 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. The following order is RECOMMENDED:

  1. TLS
  2. SASL
  3. Dialback

Note: Even though it may appear that SASL does not provide meaningful authentication in the case of self-signed certificates or certificates whose root certification authority is not trusted by the receiving entity, RFC 3920 requires its use, a recommendation which this document does not override.

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. SASL
  3. Dialback
  4. Stream compression

4. Security Considerations

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

5. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].

6. Jabber Registrar Considerations

This JEP requires no interaction with the Jabber Registrar.


Notes

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

3. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

4. JEP-0138: Stream Compression <http://www.jabber.org/jeps/jep-0138.html>.

5. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.

6. JEP-0078: Non-SASL Authentication <http://www.jabber.org/jeps/jep-0078.html>.

7. JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>.

8. Typically, the mechanism used in server-to-server negotiation will be SASL EXTERNAL.

9. JEP-0138: Stream Compression <http://www.jabber.org/jeps/jep-0138.html>.

10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.


Revision History

Version 0.3 (2006-01-24)

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

Version 0.2 (2006-01-16)

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

Version 0.1 (2006-01-11)

Initial JEP version. (psa)

Version 0.0.1 (2006-01-10)

First draft. (psa)


END