Multiplexing of Connections between Extensible Messaging and Presence Protocol (XMPP) Servers Using Transport Layer Security (TLS)
Cisco
jhildebr@cisco.com
Cisco
psaintan@cisco.com
Applications
Transport Layer Security
TLS
Extensible Messaging and Presence Protocol
XMPP
Jabber
This document specifies requirements for multiplexing of connections between Extensible Messaging and Presence Protocol (XMPP) servers using Transport Layer Security (TLS).
The Extensible Messaging and Presence Protocol (XMPP) has been widely deployed over the Internet since publication of in 2004. One common deployment scenario is for a hosting provider or application service provider to service multiple domains on the same machine or machines. With the increasing popularity of so-called "cloud computing", some of these providers service thousands of domains. Because RFC 3920 specifies that each domain-to-domain "link" shall use two XML streams (one in each direction) and because currently XMPP has no method by which an existing stream can be re-used for additional domains, establishing connectivity between two XMPP "clouds" can quickly necessitate a large number of TCP connections. This is true even if the clouds have authenticated to each other using Transport Layer Security and the Simple Authentication and Security Layer with digital certificates issued by trusted roots. Therefore it would be desirable to define a method by which two XMPP clouds could optionally multiplex communications between themselves, so that an existing domain-to-domain stream could be re-used for additional domains. This document defines requirements for such a method. Possible solutions will be defined in separate specifications, potentially for inclusion into .
We stipulate the following requirements for server-to-server multiplexing in XMPP:
The multiplexing method must be backwards-compatible with existing server-to-server connection methods.
A party that supports multiplexing must also support bidirectional XML streams.
Each party to a server-to-server communication must be able to determine if the other party supports multiplexing.
If the addition of a new domain to an existing domain-to-domain stream fails, the existing stream must not be terminated, and the adding party may attempt to add the new domain again.
Multiplexing shall depend on presentation of a valid digital certificate for the multiplexed domain.
The certificate for a multiplexed domain should not be same (i.e., have the same subject) as a certificate that has previously been accepted for the stream; however, if it is the same then it shall replace the previous certificate with the same subject (e.g., to present a new certificate with a different expiry time).
When a multiplexed domain is accepted for the stream, each name on the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for this stream.
The protocol for accepting the initial certificate for a stream may be different from the protocol for accepting subsequent ("multiplexed") certificates for the stream.
The process of adding a subsequent domain shall not affect transmission of application data over the stream.
If the stream is resumed, all of the certificates that were accepted for the previous session apply to the resumed session.
It is a security violation to proceed with transmission of application between two domains if multiplexing for those domains failed. It is acceptable for the party that receives such applicatino data to terminate the stream.
It must be possible to remove a domain from the stream.
The requirements in this memo are intended to provide guidance regarding solutions to the problem of securely multiplexing domain-to-domain XMPP communications over a single XML stream.
Extensible Messaging and Presence Protocol (XMPP): Core
Jabber Software Foundation
stpeter@jabber.org
Applications
XMPP Working Group
RFC
Request for Comments
I-D
Internet-Draft
XMPP
Extensible Messaging and Presence Protocol
Jabber
IM
Instant Messaging
Presence
XML
Extensible Markup Language
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]
Extensible Messaging and Presence Protocol (XMPP): Core
This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.
Simple Authentication and Security Layer (SASL)
<p>The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</p><p> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</p><p> This document obsoletes RFC 2222. [STANDARDS TRACK]</p>
Regarding this entire document or any portion of it, the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.