-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/29/09 10:41 AM, Philipp Hancke wrote:
> 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?
Yes, I'll add that to my issues list for 3920bis.
>> 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.
What's wrong with 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.
Correct.
>> * 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?
Why not?
>> * 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?
Wildcards are quite useful (e.g., to handle things like MUC). I don't
know that we want to get rid of wildcard certs.
>> * 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'.
You're right.
> * 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.
Agreed.
>> Is that list accurate and complete?
>
> looks good.
Super. Now to figure out some solutions...
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
iEYEARECAAYFAkn/TXAACgkQNL8k5A2w/vxFggCfcrj+jO9htFUE4b1z7mu8TzC+
wf4AnjzqXQ4ZylkH+V64o06wRjyC1QLo
=JYla
-----END PGP SIGNATURE-----
