This document specifies a recommended order for negotiation of XMPP stream features.
WARNING: This Informational document is Experimental. Publication as an XMPP Extension Protocol 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.4
Last Updated: 2006-08-02
Publishing Organization: Jabber Software Foundation
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0077, XEP-0079, XEP-0138
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Recommended Order of Stream Feature Negotiation (XEP-0170)>
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
This XMPP Extension Protocol 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.xmpp.org/extensions/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 document 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 following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
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 XMPP 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.
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:
Stream Compression [8] 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:
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 document requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].
This document requires no interaction with the XMPP 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 XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the Jabber Software Foundation. For further information, see <http://www.xmpp.org/registrar/>.
4. XEP-0138: Stream Compression <http://www.xmpp.org/extensions/xep-0138.html>.
5. XEP-0077: In-Band Registration <http://www.xmpp.org/extensions/xep-0077.html>.
6. XEP-0078: Non-SASL Authentication <http://www.xmpp.org/extensions/xep-0078.html>.
7. XEP-0079: Advanced Message Processing <http://www.xmpp.org/extensions/xep-0079.html>.
8. XEP-0138: Stream Compression <http://www.xmpp.org/extensions/xep-0138.html>.
9. 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