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.
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)>
Email: stpeter@jabber.org
JID: stpeter@jabber.org
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/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
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.
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.
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.
The XMPP RFCs define an ordering for the features defined therein, namely:
That order MUST be followed if no other stream features are negotiated.
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:
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:
If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:
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:
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:
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.
The XMPP RFCs define an ordering for the features defined therein, namely:
That order MUST be followed if no other stream features are negotiated.
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:
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:
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:
The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].
This JEP requires no interaction with the Jabber Registrar.
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/>.
END