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 key 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 'urn:xmpp: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 MUST support the X-HT-SHA-256-ENDP + mechanism, support for X-HT-SHA-256-UNIQ is RECOMMENDED. The family + of SASL X-HT-* mechanisms is defined below in Section 6.
+ +In order to obtain an ISR key, the requesting entity must add a
+ 'mechanism' attribute qualified by the 'urn:xmpp:isr:0' namespace to
+ the <enable/> element as defined in &xep0198; when attempting
+ to enable Stream Management. The value of the 'mechanism' attribute
+ is the name of the SASL mechanism the requesting entity will use
+ when performing ISR with the returned key. The entities involved in
+ ISR MUST only use or allow this mechanism when performing ISR with
+ the according key. This effectively pins the SASL
+ mechanism
Next, the <enabled/> Nonza (see &xep0360;) which is send as + positive reply upon a request to enable Stream Management, MUST + contain an 'key' attribute qualified by the 'urn:xmpp:isr:0' + namespace containing a ISR key. The key MUST be newly generated by a + cryptographically secure random number generator and MUST contain at + lest 128 bit of entropy. The Nonza can optionally also contain a + 'location' attribute qualified by the 'urn:xmpp:isr:0' namespace + 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 key 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 key. After it has obtained the ISR key, 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 'urn:xmpp: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 'urn:xmpp:isr:0' + namespace, which must contain a <resume/> element as defined + in &xep0198;.
+ +If the 'without-isr-token' attribute is set to true, then the + SASL mechanisms are performed as when traditionally authenticating + the XMPP session. If the value of the attribute is 'false', which is + the default value for this attribute, then the "password" given to + the SASL mechanism is the ISR key. Note that this implies that only + SASL mechanisms which take a password/token can be used this + way.
+ +All ISR implementations MUST support the + X-HT-SHA-256-ENDP mechanism.
+ +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 key.
+ +Servers MUST destroy the ISR key of a stream after an instant + stream resumption was attempted for that stream with an invalid ISR + key. Server implementations MUST implement the ISR key 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 'urn:xmpp:isr:0' + namespace. This element MUST contain a new ISR Key found in + the 'key' 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 key, the server MUST immediately destroy the ISR key after + authentication, i.e., it MUST no longer be possible to perform an + ISR using that ISR key 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 + 'urn:xmpp: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.4, a single SASL + mechanism 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 + SASL mechanism. Performing instant stream resumption using + multiple SASL mechanisms MUST only be done if the + 'without-isr-token' attribute is set to 'true'.
+ +If the server is unable to authenticate the initiating entity it + MUST reply with a <failure/> Nonza as defined in + &xep0388;.
+ +After the ISR authentication has failed, the initiating entity + could continue with normal authentication (&xep0388;, + …).
+ +This section specifies the Hashed Token (X-HT-*) SASL + mechanism. This mechanism was designed to be used with short-lived + tokens (shared secrets) for authentication. It provides hash + agility, mutual authentication and is secured by channel + binding. Since the token is not salted, and only one iteration is + used, the X-HT mechanism is not suitable to protect long-lived + shared secrets (e.g. "passwords"). You may want to look at &rfc5802; + for that.
+ +Each mechanism in this family differs by the choice of the hash + algorithm and the choice of the channel binding type. Each + mechanism has a name of the form X-HT-[HA]-[CBT] where [HA] is the + "Hash Name String" of the &iana-hash-alg; registry in capital + letters, and [CBT] is one of 'ENDP' or 'UNIQ'. In case of 'ENDP', + the tls-server-end-point channel binding type is used. In case of + 'UNIQ', the tls-unique channel binding type is used. For more + information about channel binding, see &rfc5929; and the + &iana-cbt; registry.
+ +| CBT | Channel Binding Type |
|---|---|
| ENDP | tls-server-end-point |
| UNIQ | tls-unique |
The following table lists a few examples of X-HT-* SASL + mechanism names.
+ +| Mechanism Name | Hash Algorithm | Channel-binding unique prefix |
|---|---|---|
| X-HT-SHA-512-ENDP | SHA-512 (FIPS 180-4) | tls-server-end-point |
| X-HT-SHA3-256-ENDP | SHA3-512 (FIPS 202) | tls-server-end-point |
| X-HT-SHA-512-UNIQ | SHA-512 (FIPS 180-4) | tls-unique |
| X-HT-SHA-256-UNIQ | SHA-256 (&rfc6920;) | tls-unique |
The mechanism consists of a simple exchange of exactly two + messages between the initiator and responder. It starts with the + message from the initiator to the responder. This + 'initiator-message' is defined as follows:
+ ++ initiator-message = HMAC(token, "Initiator" || cb-data) +
+ +HMAC() is the function defined in &rfc2104; with H being the + chosen hash algorithm, 'cb-data' represents channel binding type + data, and 'token' are the UTF-8 (see &rfc3629;) encoded bytes of + the token String which acts as shared secret between initiator and + responder. The initiator-message MUST NOT be included in TLS 1.3 + 0-RTT early data (&tls13;).
+ +This message is followed by a message from the responder to the + initiator. This 'responder-message' is defined as follows:
+ ++ responder-message = HMAC(token, "Responder" || cb-data) +
+ +The initiating entity MUST verify the responder-message to + achieve mutual authentication.
+ +To be secure, X-HT MUST be used over a TLS channel that has had + the session hash extension &rfc7627; negotiated, or session + resumption MUST NOT have been used.
+ +Putting ISR data in TLS 1.3 0-RTT early data is + forbidden. (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 Key + 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 'urn:xmpp: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 and Alexander Würstlein for their feedback.
+ +