This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document specifies requirements for multiplexing of connections between Extensible Messaging and Presence Protocol (XMPP) servers using Transport Layer Security (TLS).
3. Security Considerations
4.1. Normative References
4.2. Informative References
Appendix A. Copying Conditions
§ Authors' Addresses
The Extensible Messaging and Presence Protocol (XMPP) has been widely deployed over the Internet since publication of [RFC3920] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) 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 [TLS] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) and the Simple Authentication and Security Layer [SASL] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) 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 [rfc3920bis] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” March 2009.).
We stipulate the following requirements for server-to-server multiplexing in XMPP:
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.
|[RFC3920]||Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004 (TXT, HTML, XML).|
|[TLS]||Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).|
|[rfc3920bis]||Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” draft-saintandre-rfc3920bis-09 (work in progress), March 2009 (TXT).|
|[SASL]||Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” RFC 4422, June 2006 (TXT).|
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.