[Standards] secure s2s multiplexing

Peter Saint-Andre stpeter at stpeter.im
Mon May 4 20:17:52 UTC 2009


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



More information about the Standards mailing list