-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joe Hildebrand and I have started working on an Internet-Draft that
describes at least the requirements and possibly proposed solutions to
the challenge of securely multiplexing multiple domains over the same
XML stream.
The deployment scenario we have in mind 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 (e.g.,
Google Apps). 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 TLS
and SASL with digital certificates issued by trusted roots. Therefore we
think 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.
We see the following requirements:
* The multiplexing method must be backwards-compatible with existing
server-to-server connection methods.
* 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.
* Multiplexing shall depend on presentation of a valid digital
certificate for the multiplexed domain.
* The certificate for a multiplexed domain should not be the 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
the stream.
* The protocol used accept the initial certificate for a stream may
be different from the protocol used to accept subsequent ("multiplexed")
domains 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 data between two domains if multiplexing for those domains
failed (however, this does not affect domains that have already been
accepted for the stream).
Is that list accurate and complete?
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn4b/MACgkQNL8k5A2w/vyJFACgy8MRHFPwHKYIyt46qfPyS7mO
FxIAn37bp7hHvWzImbVAHoIxtv+G8iPD
=5hZ/
-----END PGP SIGNATURE-----
