Minor changes
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' + 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.
@@ -175,66 +136,64 @@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.
+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 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
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 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 + contain an 'isr-enabled' element qualified by the 'htpps://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 key MUST only be +
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 key. After it has obtained the ISR key, using the process + 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.
@@ -255,7 +214,7 @@Note that the hosts announced by the 'location' attribute - qualified by the 'urn:xmpp:isr:0' namespace MUST be connected to + qualified by the 'htpps://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.
@@ -294,21 +253,18 @@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' + <inst-resume/> element qualified by the 'htpps://xmpp.org/extensions/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 +
If the with-isr-token' attribute 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', 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 + 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.
-All ISR implementations MUST support the - X-HT-SHA-256-ENDP mechanism.
-Servers MUST destroy the ISR key of a stream after an instant +
Servers MUST destroy the ISR token 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 + 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 '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 + <inst-resumed/> element qualified by the 'htpps://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 key, the server MUST immediately destroy the ISR key after + 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 key and Stream Management ID (SM-ID, see + ISR using that ISR token and Stream Management ID (SM-ID, see &xep0198;) tuple.
After the <inst-resumed/> was received and has been @@ -391,13 +347,13 @@ 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 + 'htpps://xmpp.org/extensions/isr/0' namespace. This <inst-resume-failed/> MUST contain a <failed/> element as defined in &xep0198;.
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'.
+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 - MUST reply with a <failure/> Nonza as defined in - &xep0388;.
+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.
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 +
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 Key - is generated by a cryptographically secure random generator. See - &rfc4086; for more information about Randomness Requirements for - Security
+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.
The ®ISTRAR; includes 'urn:xmpp:isr:0' in its registry of protocol namespaces (see &NAMESPACES;).
+The ®ISTRAR; includes 'htpps://xmpp.org/extensions/isr/0' in its registry of protocol namespaces (see &NAMESPACES;).
Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland, - Maxime Buquet and Alexander Würstlein for their feedback.
+Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland, Maxime + Buquet, Alexander Würstlein and Sam Whited for their feedback.