Multiplexing of Connections between Extensible Messaging and Presence Protocol (XMPP) Servers Using Transport Layer Security (TLS)
draft-hildebrand-xmpp-tls-multiplexing-00

Status of this Memo

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 Notice

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.

Abstract

This document specifies requirements for multiplexing of connections between Extensible Messaging and Presence Protocol (XMPP) servers using Transport Layer Security (TLS).

Table of Contents

1.  Problem Statement
2.  Requirements
3.  Security Considerations
4.  References
    4.1.  Normative References
    4.2.  Informative References
Appendix A.  Copying Conditions
§  Authors' Addresses

1.  Problem Statement

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.).

2.  Requirements

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.

3.  Security Considerations

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.

4.  References

4.1. Normative References

4.2. Informative References

Appendix A.  Copying Conditions

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.

Authors' Addresses