From 4c53a5ad5705ac1e6c96b036ae183f7cc55b9a2d Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Thu, 3 Dec 2020 09:11:24 -0500 Subject: [PATCH] inbox: add new protoxep: Stanza Multiplexing --- inbox/mux.xml | 342 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 342 insertions(+) create mode 100644 inbox/mux.xml diff --git a/inbox/mux.xml b/inbox/mux.xml new file mode 100644 index 00000000..81ab77ae --- /dev/null +++ b/inbox/mux.xml @@ -0,0 +1,342 @@ + + +%ents; +]> + + +
+ Stanza Multiplexing + + This spec provides a mechanism for multiplexing multiple virtual hosts over + a single XMPP session. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + XEP-0220 + + + mux + &sam; + + 0.0.1 + 2020-12-03 + ssw +

First draft.

 + +
+ +

+ The ability to multiplex multiple virtual hosts over a single XMPP session + (historically known as "piggybacking") was originally defined in &rfc3920; + and later pulled out into &xep0220; for use with &rfc6120;. + With the advent of cheap or free TLS certificates the use of dialback + began falling off on the public XMPP network as more secure authentication + mechanisms such as SASL EXTERNAL began to become more common. + However, multiplexing is still a useful technique in constrained + environments regardless of the authentication mechanism being used. +

+

+ Multiplexing is also useful for reusing connections for additional + services associated with a domain but hosted at a subdomain. + For example, both the "montague.example" and the "capulet.example" may be + hosted by the same XMPP server which may also host &xep0369; services at + "chat.montague.example" and "rooms.capulet.example" respectively. + Without multiplexing this would require eight TCP connections for a + bidirectional exchange of stanzas between two sending domains and two + target domains. + However, with multiplexing this can be reduced to two connections, or, at + the operator's discretion, more than two for operational reasons. + If multiplexing is not used, the number of server-to-server connections + needed to exchange stanzas between virtual hosting providers or + multi-service XMPP servers can increase signficantly. + This can lead to the number of connections exceeding the maximum number of + connections allowed from a single address as explained in &xep0205;. +

+

+ This specification defines new mechanisms for advertising and negotiating + multiple hosts over a single session. + Furthermore it advances the state of the art over the multiplexing + solution defined in &xep0220; by working on both client-to-server (c2s) + and server-to-server (s2s) sessions. +

+ + +

+ If a server supports receiving multiplexed streams it SHOULD inform the + connecting entity when returning stream features during the negotiation + process. + Two mechanisms exist for authenticating domains that can be multiplexed + over a connection: domains may be authenticated using the TLS certificate + (and client certificate if applicable), and domains may be authorized + using the connection authorization mechanism described later in this + document. +

+

+ To advertise support for multiplexing all domains present in a TLS + certificate the server includes a <mux/> element qualified by the + 'urn:xmpp:mux:0' namespace in the stream features list. + This feature MUST be advertised only after TLS has been negotiated (either + by opportunistic TLS using the STARTTLS feature or by implicit TLS when + establishing the TCP socket) an before authentication using SASL EXTERNAL + has been performed. + This feature is not mandatory to negotiate. +

+ + + + EXTERNAL + +]]> +

+ The mux feature may also be advertised after authentication with SASL + EXTERNAL. + If advertised after authentication the feature MUST include a list of + supported hosts wrapped in <host/> elements. +

+ + + capulet.example + montague.example + chat.montague.example + rooms.capulet.example + + +]]> + + +

+ If the initiating entity wishes to indicate that it intends to use + multiplexing with SASL EXTERNAL it MUST respond to the empty <mux/> + element by sending another empty <mux/> element qualified by the + 'urn:xmpp:mux:0' namespace in reply. + No stream restart is necessary. +

+

+ After indicating support for multiplexing by negotiating the mux stream + feature, authentication can proceed. + When using SASL EXTERNAL this is done by validating the certificate as + detailed in &xep0178; except that every domain that is present in the + certificate is now eligible for multiplexing without further negotiation. + Further stream features (such as resource binding) still use the JID from + the original connection (or from the authorization identity). +

+

+ If a bidirectional s2s connection has been negotiated for this session using + &xep0288;, negotiation of the mux stream feature also implies that the + receiving entity SHOULD multiplex stanzas sent back to the initiating entity + for all domains in the verified client certificate. + If bidi is not negotiated then mux will need to be negotiated again when the + original receiving entity establishes a connection with the original + initiating entity. +

+ + +

+ Often it is not desirable to have one certificate containing every XMPP + address or host managed by the server, or the use of SASL EXTERNAL may be + impossible. + In these cases the initiating entity may request authorization to + send stanzas over an existing connection. +

+

+ If the initiating entity has an authenticated connection to a server and + wishes to send stanzas to another server that was listed in the original + servers post-auth <mux/> stream feature it MAY establish an XMPP + connection with the new server and verify that new server also lists the + original server in its post-auth mux stream feature. + If it does the initiating entity replies with a <mux/> element + qualified by the 'urn:xmpp:mux:0' namespace with a shared secret as the + payload and the host being selected included in the 'host' attribute. + The old server then sends an IQ over its existing connection with the + initiating entity containing the same mux element and secret, thereby + confirming its relationship to the new server. + If the client verifies that the secrets match it sends an empty IQ of type + "result" in response to indicate success, otherwise the IQ response should + be a "not-acceptable" stanza error (see &rfc6120; ยง8.3.3.9). +

+

+ For example, if the server montague.example wishes to establish a + multiplexed connection with capulet.example and rooms.capulet.example the + flow would look like this: +

+ | rooms.capulet.example + | | --------------------- + | [if necessary, | | + | perform DNS lookup, | | + | on Sender Domain, | | + | open TCP connection, | | + | and establish stream] | | + | -----------------------------------------------> | + | | | + | send mux secret | | + | -----------------------------------------------> | + | | | + | send mux secret IQ | | + | <----------------------- | | + | | | + | send IQ response | | + | -----------------------> | | + | | | + | | close connection | + | <----------------------------------------------- |]]> +

+ The XML for this exchange would look like the following: +

+ + + + rooms.capulet.example + + + + + + secret + + +<-- The server at montague.example indicates that the secret was verified. --> + +]]> + + + + + capulet.example + + + + + + secret + + + + +]]> +

+ The format of the secret is not specified however, see the Security + Considerations section of this document for some suggestions. +

+ + +

+ Some clients may send stanzas with no "from" attribute specified and rely on + the server to add the attribute before routing the stanza to its final + destination. + If multiplexing is used the lack of a from attribute indicates that the + client is acting on behalf of the origin JID for the connection, just like + normal, so clients MUST set the from attribute on any stanzas sent on behalf + of any multiplexed host. +

+

+ The format of mux secrets is undefined in this document, however, they MUST + be unpredictable. + Only the initiating entity should attribute any meaning (if indeed there is + any) to the format of mux secrets. + In particular the receiving entity MUST NOT rely on a specific format for + the secret. +

+

+ One suggestion for generating mux secrets is to generate a key that signs + information about the stream. + The format defined in &xep0185; is appropriate for this. + If the mux secret is a signature it must protect against reuse by at least + include a random secret generated with a cryptographically secure random + number source, the origin JID, the JID of the server initially receiving the + mux secret, and the stream ID for the stream the key will be authenticating + (this is not the same stream as the receiving entity's JID). + It is also RECOMMENDED that an expiration time be included in the key after + which it is no longer valid. +

+ + +

This document requires no interaction with &IANA;.

+ + + +

This specification defines the following XML namespace:

+
    +
  • urn:xmpp:mux:0
    • +
+

+ Upon advancement of this specification from a status of Experimental to a + status of Draft, the ®ISTRAR; shall add the foregoing namespace to the + registries located at &STREAMFEATURES;, as described in Section 4 of + &xep0053;. +

+ + urn:xmpp:mux:0 + mux + mux + Indicate support for connection multiplexing and transmit secret keys to a peer. + Editor to add document reference if accepted + provisional +]]> +

+ The ®ISTRAR; shall also add the foregoing namespace to the Jabber/XMPP + Protocol Namespaces Registry located at &NAMESPACES;. + Upon advancement of this specification from a status of Experimental to a + status of Draft, the ®ISTRAR; shall remove the provisional status from + this registry entry. +

+ + urn:xmpp:mux:0 + Editor to add document reference if accepted + provisional +]]> + + + &NSVER; + + + +

+ Thanks to Jeremie Miller, Peter Saint-Andre, and Philipp Hancke for writing + &xep0220; from which some of the text and techniques used in this document + were borrowed. +

+ +