This XEP specifies an instant stream resumption mechanism based on Stream Management (XEP-0198) [1], allowing XMPP entities to instantaneously resume an XMPP stream. This can be seen as the complementary part to XMPP Quickstart (XEP-0305) [2] 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 (besides the round trips required by the TLS handshake). This is achieved by using just a secure key to resume the stream.
If an entity supports ISR, then the <enabled/> Nonza [4], 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 Nonza MAY 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.
<enabled xmlns='urn:xmpp:sm:3' xmlns:isr='urn:xmpp:isr:0' isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
<enabled xmlns='urn:xmpp:sm:3' xmlns:isr='urn:xmpp:isr:0' isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' isr:location='isr.example.org:5222'/>
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
Next, the initiating entity sends an XMPP <stream> open element followed by a <instant-resume/> Nonza qualified by the 'urn:xmpp:isr:0' namespace which MUST contain the previous stream identifier, the XEP-0198 "SM-ID", in the 'previd' attribute, the sequence number of the last by Stream Management handled stanza in the 'h' attribute and the initiator-hmac as value of at least one <hash/> element as specified by Use of Cryptographic Hash Functions in XMPP (XEP-0300) [7], which are put as child elements under the <hmac/> element.
The initiator-hmac is defined as follows:
initiator-hamc = Base64(HMAC(key, "Initiator" || tls-server-end-point))
The function defined in RFC 2104 [8] is used to compute the HMAC using the hash algorithm specified in the 'algo' attribute of the <hash/> element as the cryptographic hash function H. The ISR Key is used as key of the HMAC. And the bytewise concatnation of the ASCII String "Initiator" and the bytes from tls-server-end-point, which a TLS Channel Binding defined in RFC 5929 [9] § 4, is used a the HMAC text. The resulting bytes of the HMAC function are encoded using Base64 as defined in RFC 4648 [10] § 4 and resulting string is used as text value of the <hash/> element.
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 nevertheless announce that they support ISR by including an <isr/> element qualified by the 'urn:xmpp:isr:0' namespace in their stream features.
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<inst-resume
xmlns='urn:xmpp:isr:0'
previd='some-long-sm-id'
h='42'>
<hmac>
<hash xmlns='urn:xmpp:hashes:1' algo='sha256'>
initator-hmac
</hash>
</hmac>
</inst-resume>ISR MUST only be performed over TLS secured sessions. What follows is that the ISR feature MUST only be announced after STARTTLS has been successfully performed or on streams where TLS was established from the beginning.
On success the server replies with <inst-resumed/> Nonza which MUST contain a new ISR Key found in the 'key' attribute, the sequence number of the last by Stream Mangement handled stanza in the 'h' attribute and the 'responder-hmac' as value of the <hash/> element being a child of the <hamc/> element.
The responder-hmac is defined as follows:
responder-hmac = Base64(HMAC(key, "Responder" || tls-server-end-point))
That is, it is the same as the initiator-hamc, but instead of using the ASCII string "Initiator", the ASCII string "Responder" is used.
The initiating entity is required to verify the responder-hmac achieve mutual authentication.
<stream:stream
from='im.example.com'
id='t7AMCin9zjMNwQKDnplntZPIDEI='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<isr xmlns='urn:xmpp:isr:0'/>
</stream:features>
<inst-resumed
xmlns='urn:xmpp:isr:0'
key='006b1a29-c549-41c7-a12c-2a931822f8c0'
h='21'>
<hmac>
<hash xmlns='urn:xmpp:hashes:1' algo='sha-256'>
responder-hmac
</hash>
</hmac>
</inst-resumed>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 Stream Compression (XEP-0138) [11]. 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.
If the server is unable to resume the stream instantly it MUST reply with a <failed/> Nonza qualified by the 'urn:xmpp:isr:0' namespace.
<failed xmlns='urn:xmpp:isr:0'/>
The server MAY also include a 'h' attribute in the <failed/> element indicating the number of stanzas it has handled so far.
<failed xmlns='urn:xmpp:isr:0' h='22'/>
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.
It is of vital importance that the Instant Stream Resumption Key is generated by a cryptographically secure random generator. See RFC 4086 [12] for more information about Randomness Requirements for Security
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [13].
The XMPP Registrar [14] includes 'urn:xmpp:isr:0' in its registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).
TODO: Add after the XEP leaves the 'experimental' state.
Thanks to Jonas Wielicki and Thijs Alkemade for their feedback.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright (c) 1999 - 2016 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0198: Stream Management <https://xmpp.org/extensions/xep-0198.html>.
2. XEP-0305: XMPP Quickstart <https://xmpp.org/extensions/xep-0305.html>.
3. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <http://tools.ietf.org/html/rfc5246>.
4. XEP-0360: Nonzas (are not Stanzas) <https://xmpp.org/extensions/xep-0360.html>.
5. XEP-0368: SRV records for XMPP over TLS <https://xmpp.org/extensions/xep-0368.html>.
6. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
7. XEP-0300: Use of Cryptographic Hash Functions in XMPP <https://xmpp.org/extensions/xep-0300.html>.
8. RFC 2104: HMAC: Keyed-Hashing for Message Authentication <http://tools.ietf.org/html/rfc2104>.
9. RFC 5929: Channel Bindings for TLS <http://tools.ietf.org/html/rfc5929>.
10. RFC 4648: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc4648>.
11. XEP-0138: Stream Compression <https://xmpp.org/extensions/xep-0138.html>.
12. RFC 4086: Randomness Requirements for Security <http://tools.ietf.org/html/rfc4086>.
13. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
14. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
Second draft.
First draft.
@report{schmaus2016isr,
title = {Instant Stream Resumption},
author = {Schmaus, Florian},
type = {XEP},
number = {xxxx},
version = {0.0.2},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-xxxx.html},
date = {2016-02-12/2016-03-11},
}END