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.1
Last Updated: 2006-01-11
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 - 2005 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. Recommendations
2.1. Standard XMPP Features
2.2. Non-SASL Authentication
2.3. In-Band Registration
2.4. Stream Compression
2.5. Advanced Message Processing
3. Security Considerations
4. IANA Considerations
5. 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. 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 Non-SASL Authentication

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

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

2.4 Stream Compression

Stream compression is negotiated when it is not possible to set TLS compression for whatever reason. It seems sensible to negotiate stream compression after TLS (to safely complete the negotiation) and before SASL (to compress as much traffic as possible). Therefore the following order is RECOMMENDED:

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

If both stream compression and in-band registration are negotiated, stream compression SHOULD be negotiated first. Therefore the following order is RECOMMENDED:

  1. TLS
  2. Stream compression
  3. jabber:iq:register
  4. SASL
  5. Resource binding
  6. IM session establishment

2.5 Advanced Message Processing

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

3. Security Considerations

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

4. IANA Considerations

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

5. 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-0078: Non-SASL Authentication <http://www.jabber.org/jeps/jep-0078.html>.

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

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

7. 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.1 (2006-01-11)

Initial JEP version. (psa)

Version 0.0.1 (2006-01-10)

First draft. (psa)


END