Minor fixes and clarifications
Accepted by council vote from 2017-12-13.
Minor changes
Based ISR on SASL2.
Second draft.
First draft.
This XEP specifies an instant stream resumption mechanism based on &xep0198;, allowing XMPP entities to instantaneously resume an XMPP stream. This can be seen as the complementary part to &xep0305; allowing for fast XMPP session (re-)establishment.
Compared to the existing stream resumption mechanism of XEP-0198 § 5, the approach defined herein reduces the round trips required to resume a stream to exactly one. This is achieved by using just a secure short-lived token to resume the stream.
XMPP entities providing Instant Stream Resumption MUST announce that functionality as stream feature, but only if an instant stream resumption is possible at this stage. The ISR stream future consists of an <isr/> element qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace. And since ISR requires TLS, this means that the <isr/> stream feature only appears on TLS secured connections.
The ISR stream feature element MUST contain a <mechanisms/> element as defined in &rfc6120;. This element contains the SASL mechanism which are available to be used for instant stream resumption.
Every ISR enabled entity SHOULD support the HT-SHA-256-ENDP mechanism, support for HT-SHA-256-UNIQ is RECOMMENDED. The family of HT SASL mechanisms is specified in &sasl-ht;.
In order to obtain an ISR token, the requesting entity must add an
'isr-enable' element qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace to the
<enable/> element as defined in &xep0198; when attempting to
enable Stream Management. This <isr-enable/> element MUST contain a
'mechanism' attribute containing the name of the SASL mechanism the
requesting entity will use when performing ISR with the returned
token. The entities involved in ISR MUST only use or allow this
mechanism when performing ISR with the according token. This
effectively pins the SASL mechanism
Next, the <enabled/> Nonza (see &xep0360;) which is sent as positive reply upon a request to enable Stream Management, MUST contain an 'isr-enabled' element qualified by the 'https://xmpp.org/extensions/isr/0' namespace containing a ISR token as value of its 'token' attribute. The token MUST be newly generated by a cryptographically secure random number generator and MUST contain at least 128 bit of entropy. The <isr-enabled/> element can optionally also contain a 'location' attribute which specifies the preferred IP address or hostname, and a TCP port number of the host which should be used for instant stream resumption.
The <enabled/> Nonza containing an ISR token MUST only be sent over TLS secured connections.
In order to instantaneously resume an XMPP stream the initiating entity, which is either an XMPP client or server, must posses a valid ISR token. After it has obtained the ISR token, using the process described in the previous section, it first determines the host for resumption, and after that, tries to perform the instant stream resumption.
The lookup mechanism order to determine host candidates for ISR resumption is as follows:
The host candidates retrieved by those mechanisms SHOULD be tried by the initiating entity in this order.
Note that the hosts announced by the 'location' attribute qualified by the 'https://xmpp.org/extensions/isr/0' namespace MUST be connected to using TLS from the beginning, i.e. <starttls/> MUST NOT be used, instead the TLS handshake is performed right after establishing the connection.
This order prefers hosts which allow connections where TLS is enabled from the beginning. This is desirable to reduce the required round trips by skipping the <starttls/> step.
After the remote host on which the instant stream resumption should be performed was determined, the initiating entity connects to the host, and establishes TLS by either
Now the initiating entity sends an XMPP <stream> open element followed by a <authenticate/> Nonza as specified in the &xep0388;. The initiating entity must also provide a <inst-resume/> element qualified by the 'https://xmpp.org/extensions/isr/0' namespace, which must contain a <resume/> element as defined in &xep0198;.
The only defined attributed of the <inst-resume/> element is the 'with-isr-token' attribute, whose value, if omitted, defaults to 'true'. If is set to 'false', then the SASL mechanism is performed as when traditionally authenticating the XMPP session. If the value of the attribute is 'true' then the "password" given to the SASL mechanism is the ISR token. Note that this implies that only SASL mechanisms which take a password/token can be used this way.
Note that the initiating entity SHOULD pipeline the instant stream resumption request together with then initial <stream> open element. The initiating entity is able to do so since it already knows that the service supports ISR because it announced an ISR token.
Servers MUST destroy the ISR token of a stream after an instant stream resumption was attempted for that stream with an invalid ISR token. Server implementations MUST implement the ISR token comparision in linear runtime.
On success the server replies with a <success/> nonza as specified in the &xep0388;, which must include a <inst-resumed/> element qualified by the 'https://xmpp.org/extensions/isr/0' namespace. This element MUST contain a new ISR Token found in the 'token' attribute. It also MUST include a <resumed/> as specified in &xep0198; containing the sequence number of the last by Stream Management handled stanza in the 'h' attribute and the 'previd' attribute.
In case of an successful Instant Stream Resumption authenticated by an ISR token, the server MUST immediately destroy the ISR token after authentication, i.e., it MUST no longer be possible to perform an ISR using that ISR token and Stream Management ID (SM-ID, see &xep0198;) tuple.
After the <inst-resumed/> was received and has been verified both entities MUST consider the resumed stream to be re-established. This includes all previously negotiated stream features like &xep0138;. It does however not include the specific state of the features: For example in case of Stream Compression, the dictionary used by the compression mechanism of the resumed stream MUST NOT be considered to be restored after instant stream resumption.
Note that this behavior is different from &xep0198; stream resumption, where "outer stream" features like compression are not restored. Since such a behavior would be counterproductive towards the goal of this XEP, it specifies that the negotiation state of such "outer stream" features is also restored (besides the features which where already negotiated at ISR-time, i.e. TLS).
If the server was able to authenticate the initiating entity but is unable to resume the stream instantly it MUST reply with a <success/> Nonza as defined in the &xep0388; containing a <inst-resume-failed/> element qualified by the 'https://xmpp.org/extensions/isr/0' namespace. This <inst-resume-failed/> MUST contain a <failed/> element as defined in &xep0198;.
Instant stream resumption errors SHOULD be considered recoverable, the initiating entity MAY continue with normal session establishment; however, misuse of stream management MAY result in termination of the stream. Since the initiating entity is authenticated, it could continue with resource binding by using &rfc6120; § 7. or &xep0386;.
As specified in the &xep0388; § 2.6.3, sole SASL authentication may not be sufficient for authentication. In this case, the remote entity sends a <continue/> element as defined in &xep0388; to request the local entity to perform another task.
If the server is unable to authenticate the initiating entity
it replies with a <failure/> Nonza as defined in
&xep0388;. The server MUST delete any state of the stream which
was attempted to resume in case the SM-ID was correct but the
authentication failed.
After the ISR authentication has failed, the initiating entity could continue with normal authentication (&xep0388;, …).
Any ISR data SHALL NOT be part of TLS 1.3 0-RTT early data. (TODO: Shall we weaken this requirement to allow early data?. It would be technically possible if the sender does not add additional data, for example Stanzas, after the ISR/XEP-0388 data at the end of the early data. And if the receiver does ensure that the existence of such additional data is causing an ISR failure.)
It is of vital importance that the Instant Stream Resumption Token is generated by a cryptographically secure random generator. See &rfc4086; for more information about Randomness Requirements for Security.
This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'https://xmpp.org/extensions/isr/0' in its registry of protocol namespaces (see &NAMESPACES;).
TODO: Add after the XEP leaves the 'experimental' state.
Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland, Maxime Buquet, Alexander Würstlein, Sam Whited and Ivan Vučica for their feedback.