Peter Saint-Andre wrote:
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.
Btw, could you remove the other usage of 'multiplex' from RFC 3921bis?
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
The 'd' word.
"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.
unidirectional or bidirectional s2s for this? For bidi we need a
reverse-stream:features feature anyway.
* If the addition of a new domain to an existing domain-to-domain
stream fails, the existing stream must not be terminated.
if the addition of a new domain to an existing stream fails, is it
allowed to retry after x minutes?
* 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.
This could be nasty with wildcard certificates. Explicit negotiation or
no wildcards?
* 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.
You're mixing up 'certificate' and 'domain'.
* The protocol used [to] exchange(?) the certificate for the initial
domain on(?) a stream may be different from the protocol to exchange
the certificates for subsequent ("multiplexed") domains on 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).
I think it is ok to kill the stream.
Is that list accurate and complete?
looks good.
philipp
