First draft.
The ability to multiplex multiple virtual hosts over a single XMPP session
(historically known as "piggybacking") was originally defined in RFC 3920
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 Mediated Information eXchange (MIX) (XEP-0369)
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 Server Dialback (XEP-0220)
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.
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.
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 Best Practices for Use of SASL EXTERNAL (XEP-0178)
If a bidirectional s2s connection has been negotiated for this session using
Bidirectional Server-to-Server Connections (XEP-0288)
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 RFC 6120
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:
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 Dialback Key Generation and Validation (XEP-0185)
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
This specification defines the following XML namespace:
Upon advancement of this specification from a status of Experimental to a
status of Draft, the XMPP Registrar
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 XMPP Registrar
urn:xmpp:mux:0
Editor to add document reference if accepted
provisional
]]>
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
Thanks to Jeremie Miller, Peter Saint-Andre, and Philipp Hancke for writing
Server Dialback (XEP-0220)