Internet DRAFT - draft-hildebrand-xmpp-tls-multiplexing
draft-hildebrand-xmpp-tls-multiplexing
Network Working Group J. Hildebrand
Internet-Draft P. Saint-Andre
Intended status: Standards Track Cisco
Expires: November 9, 2009 May 8, 2009
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
Hildebrand & Saint-Andre Expires November 9, 2009 [Page 1]
Internet-Draft XMPP Multiplexing Using TLS May 2009
using Transport Layer Security (TLS).
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Normative References . . . . . . . . . . . . . . . . . . . 4
4.2. Informative References . . . . . . . . . . . . . . . . . . 4
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Hildebrand & Saint-Andre Expires November 9, 2009 [Page 2]
Internet-Draft XMPP Multiplexing Using TLS May 2009
1. Problem Statement
The Extensible Messaging and Presence Protocol (XMPP) has been widely
deployed over the Internet since publication of [RFC3920] 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] and the Simple
Authentication and Security Layer [SASL] 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].
2. Requirements
We stipulate the following requirements for server-to-server
multiplexing in XMPP:
o The multiplexing method must be backwards-compatible with existing
server-to-server connection methods.
o A party that supports multiplexing must also support bidirectional
XML streams.
o Each party to a server-to-server communication must be able to
determine if the other party supports multiplexing.
o 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.
o Multiplexing shall depend on presentation of a valid digital
certificate for the multiplexed domain.
o 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).
Hildebrand & Saint-Andre Expires November 9, 2009 [Page 3]
Internet-Draft XMPP Multiplexing Using TLS May 2009
o 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.
o The protocol for accepting the initial certificate for a stream
may be different from the protocol for accepting subsequent
("multiplexed") certificates for the stream.
o The process of adding a subsequent domain shall not affect
transmission of application data over the stream.
o If the stream is resumed, all of the certificates that were
accepted for the previous session apply to the resumed session.
o 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.
o 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
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
4.2. Informative References
[rfc3920bis]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-saintandre-rfc3920bis-09
(work in progress), March 2009.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
Appendix A. Copying Conditions
Regarding this entire document or any portion of it, the authors make
Hildebrand & Saint-Andre Expires November 9, 2009 [Page 4]
Internet-Draft XMPP Multiplexing Using TLS May 2009
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
Joe Hildebrand
Cisco
Email: jhildebr@cisco.com
Peter Saint-Andre
Cisco
Email: psaintan@cisco.com
Hildebrand & Saint-Andre Expires November 9, 2009 [Page 5]
