Merge pull request #552 from Flowdalic/xep-isr-sasl2

Update inbox/isr-sasl2.xml to 0.0.5

inbox/isr-sasl2.xml

@@ -1,9 +1,8 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
   <!ENTITY % ents SYSTEM 'xep.ent'>
-  <!ENTITY tls13 "<span class='ref'><link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-19'>draft-ietf-tls-tls13-19</link></span> <note>The Transport Layer Security (TLS) Protocol Version 1.3 &lt;<link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-19'>https://tools.ietf.org/html/draft-ietf-tls-tls13-19</link>&gt;.</note>" >
+  <!ENTITY tls13 "<span class='ref'><link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-21'>draft-ietf-tls-tls13-21</link></span> <note>The Transport Layer Security (TLS) Protocol Version 1.3 &lt;<link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-21'>https://tools.ietf.org/html/draft-ietf-tls-tls13-21</link>&gt;.</note>" >
-  <!ENTITY iana-hash-alg "<span class='ref'><link url='https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg'>IANA Named Information Hash Algorithm Registry</link></span><note>IANA Named Information Hash Algorithm Registry &lt;<link url='https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg'>https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg</link>&gt;.</note>" >
+  <!ENTITY sasl-ht "<span class='ref'><link url='https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-03'>draft-schmaus-sasl-ht-03</link></span><note>draft-schmaus-sasl-ht-03: The Hashed Token SASL Mechanism &lt;<link url='https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-03'>https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-03</link>&gt;.</note>" >
-  <!ENTITY iana-cbt "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>IANA Channel-Binding Types</link></span><note>IANA Channel-Binding Types&lt;<link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml</link>&gt;.</note>" >
 %ents;
 ]>
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@@ -14,62 +13,7 @@
   <abstract>This specification introduces a mechanism for instant
   stream resumption, based on Stream Management (XEP-0198), allowing
   XMPP entities to instantaneously resume an XMPP stream.</abstract>
-
+  &LEGALNOTICE;
-  <legal>
-    <copyright>This XMPP Extension Protocol is copyright (c) 1999 -
-    2016 by the XMPP Standards Foundation (XSF).</copyright>
-
-  <permissions>Permission is hereby granted, free of charge, to any
-    person obtaining a copy of this specification (the
-    &quot;Specification&quot;), 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.</permissions>
-
-  <warranty>## NOTE WELL: This Specification is provided on an
-    &quot;AS IS&quot; 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. ##</warranty>
-
-  <liability>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.</liability>
-
-  <conformance>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 &lt;<link
-      url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt;
-    or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201
-    USA).</conformance>
-  </legal>
-
   <number>xxxx</number>
   <status>ProtoXEP</status>
   <type>Standards Track</type>
@@ -89,6 +33,23 @@
     <email>flo@geekplace.eu</email>
     <jid>flo@geekplace.eu</jid>
   </author>
+  <revision>
+    <version>0.0.5</version>
+    <date>2017-11-30</date>
+    <initials>fs</initials>
+    <remark><p>Minor changes</p></remark>
+  </revision>
+  <revision>
+    <version>0.0.4</version>
+    <date>2017-10-15</date>
+    <initials>fs</initials>
+    <remark>
+      <ul>
+        <li>Bump SASL2 namespace to urn:xmpp:sasl:1, and as result:</li>
+        <li>Rename 'key' to 'token'</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.0.3</version>
     <date>2017-03-17</date>
@@ -120,7 +81,7 @@
   url='http://xmpp.org/extensions/xep-0198.html#resumption'><cite>XEP-0198</cite>
   § 5</link>, the approach defined herein reduces the round trips
   required to resume a stream to exactly <em>one</em>. This is
-  achieved by using just a secure short-lived key to resume the
+  achieved by using just a secure short-lived token to resume the
   stream.</p>
 
 </section1>
@@ -133,7 +94,7 @@
     <dd>Instant Stream Resumption.</dd>
   </di>
   <di>
-    <dt>Instant Stream Resumption Key (ISR Key)</dt>
+    <dt>Instant Stream Resumption Token (ISR Token)</dt>
     <dd>A shared secret that is exclusively ephemeral and represented as string.</dd>
   </di>
   <di>
@@ -155,7 +116,7 @@
   <p>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 &lt;isr/&gt; element qualified by the 'urn:xmpp:isr:0'
+  of an &lt;isr/&gt; element qualified by the 'htpps://xmpp.org/extensions/isr/0'
   namespace. And since ISR requires TLS, this means that the
   &lt;isr/&gt; stream feature only appears on TLS secured
   connections.</p>
@@ -175,66 +136,64 @@
 <stream:features>
   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
   <sm xmlns='urn:xmpp:sm:3'/>
-  <isr xmlns='urn:xmpp:isr:0'>
+  <isr xmlns='https://xmpp.org/extensions/isr/0'>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
-      <mechanism>X-HT-SHA-256-ENDP</mechanism>
+      <mechanism>HT-SHA-256-ENDP</mechanism>
     </mechaisms>
   </isr>
 </stream:features>
 ]]></example>
 
-  <p>Every ISR enabled entity MUST support the X-HT-SHA-256-ENDP
+  <p>Every ISR enabled entity SHOULD support the HT-SHA-256-ENDP
-  mechanism, support for X-HT-SHA-256-UNIQ is RECOMMENDED. The family
+  mechanism, support for HT-SHA-256-UNIQ is RECOMMENDED. The family
-  of SASL <cite>X-HT-*</cite> mechanisms is defined below in <link
+  of <cite>HT SASL</cite> mechanisms is specified in &sasl-ht;.</p>
-  url='#ht-sasl'>Section 6</link>.</p>
 
 </section1>
 
-<section1 topic='Obtaining a Instant Stream Resumption Key' anchor='obtain'>
+<section1 topic='Obtaining a Instant Stream Resumption Token' anchor='obtain'>
 
-  <p>In order to obtain an ISR key, the requesting entity must add a
+  <p>In order to obtain an ISR token, the requesting entity must add an
-  'mechanism' attribute qualified by the 'urn:xmpp:isr:0' namespace to
+  'isr-enable' element qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace to the
-  the &lt;enable/&gt; element as defined in &xep0198; when attempting
+  &lt;enable/&gt; element as defined in &xep0198; when attempting to
-  to enable Stream Management. The value of the 'mechanism' attribute
+  enable Stream Management. This &lt;isr-enable/&gt; element MUST contain a
-  is the name of the SASL mechanism the requesting entity will use
+  'mechanism' attribute containing the name of the SASL mechanism the
-  when performing ISR with the returned key. The entities involved in
+  requesting entity will use when performing ISR with the returned
-  ISR MUST only use or allow this mechanism when performing ISR with
+  token. The entities involved in ISR MUST only use or allow this
-  the according key. This effectively pins the SASL
+  mechanism when performing ISR with the according token. This
-  mechanism <note>Pinning the SASL mechanism is believed to
+  effectively pins the SASL mechanism <note>Pinning the SASL mechanism
-  increase the security</note>.</p>
+  is believed to increase the security</note>.</p>
 
-  <example caption='An &lt;enable/gt; Nonza with the ISR &apos;mechanism&apos; attribute'><![CDATA[
+  <example caption='An &lt;enable/&gt; Nonza with the ISR &apos;mechanism&apos; element'><![CDATA[
-<enable
+<enable xmlns='urn:xmpp:sm:3'>
-  xmlns='urn:xmpp:sm:3'
+  <isr-enable xmlns='https://xmpp.org/extensions/isr/0' mechanism='HT-SHA-256-ENDP'/>
-  xmlns:isr='urn:xmpp:isr:0'
+</enable>
-  isr:mechanism='X-HT-SHA-256-ENDP'/>
 ]]></example>
 
   <p>Next, the &lt;enabled/&gt; 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'
+  contain an 'isr-enabled' element qualified by the 'htpps://xmpp.org/extensions/isr/0'
-  namespace containing a ISR key. The key MUST be newly generated by a
+  namespace containing a ISR token as value of its 'token' attribute. The
-  cryptographically secure random number generator and MUST contain at
+  token MUST be newly generated by a cryptographically secure random
-  lest 128 bit of entropy. The Nonza can optionally also contain a
+  number generator and MUST contain at least 128 bit of entropy. The
-  'location' attribute qualified by the 'urn:xmpp:isr:0' namespace
+  &lt;isr-enabled/&gt; 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.</p>
 
-  <example caption='An &lt;enabled/&gt; Nonza with a ISR key'><![CDATA[
+  <example caption='An &lt;enabled/&gt; Nonza with a ISR token'><![CDATA[
-<enabled
+<enabled xmlns='urn:xmpp:sm:3'>
-  xmlns='urn:xmpp:sm:3'
+  <isr-enabled xmlns='https://xmpp.org/extensions/isr/0' token='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
-  xmlns:isr='urn:xmpp:isr:0'
+</enabled>]]></example>
-  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>]]></example>
 
-  <example caption='An &lt;enabled/&gt; Nonza with a ISR key and location'><![CDATA[
+  <example caption='An &lt;enabled/&gt; Nonza with a ISR token and location'><![CDATA[
-<enabled
+<enabled xmlns='urn:xmpp:sm:3'>
-  xmlns='urn:xmpp:sm:3'
+  <isr-enabled xmlns='https://xmpp.org/extensions/isr/0'
-  xmlns:isr='urn:xmpp:isr:0'
+               token='a0b9162d-0981-4c7d-9174-1f55aedd1f52'
-  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'
+               location='isr.example.org:5222'/>
-  isr:location='isr.example.org:5222'/>]]></example>
+</enabled>]]></example>
 
-  <p>The &lt;enabled/&gt; Nonza containing an ISR key MUST only be
+  <p>The &lt;enabled/&gt; Nonza containing an ISR token MUST only be
   sent over TLS secured connections.</p>
 
 </section1>
@@ -243,7 +202,7 @@
 
   <p>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.</p>
@@ -255,7 +214,7 @@
 
   <ol>
     <li>The host provided in the optional 'location' attribute
-    qualified by the 'urn:xmpp:isr:0' namespace found in the
+    qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace found in the
     &lt;enabled/&gt; element of <cite>XEP-0198</cite> (the
     "isr:location").
     </li>
@@ -269,7 +228,7 @@
   tried by the initiating entity in this order.</p>
 
   <p>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. &lt;starttls/&gt; MUST NOT be
   used, instead the TLS handshake is performed right after
   establishing the connection.</p>
@@ -294,21 +253,18 @@
   <p>Now the initiating entity sends an XMPP &lt;stream&gt; open
   element followed by a &lt;authenticate/&gt; Nonza as specified in
   the &xep0388;. The initiating entity must also provide a
-  &lt;inst-resume/&gt; element qualified by the 'urn:xmpp:isr:0'
+  &lt;inst-resume/&gt; element qualified by the 'htpps://xmpp.org/extensions/isr/0'
   namespace, which must contain a &lt;resume/&gt; element as defined
   in &xep0198;.</p>
 
-  <p>If the 'without-isr-token' attribute is set to true, then the
+  <p>If the with-isr-token' attribute is set to 'false', then the
-  SASL mechanisms are performed as when traditionally authenticating
+  SASL mechanism is performed as when traditionally authenticating
-  the XMPP session. If the value of the attribute is 'false', which is
+  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.</p>
 
-  <p>All ISR implementations MUST support the
-  X-HT-SHA-256-ENDP mechanism.</p>
-
   <example caption='Initiating entity requests instant stream resumption via the Extensible SASL Profile (XEP-0388)'><![CDATA[
 <?xml version='1.0'?>
 <stream:stream
@@ -319,9 +275,9 @@
     xmlns='jabber:client'
     xmlns:stream='http://etherx.jabber.org/streams'>
 
-<authenticate xmlns='urn:xmpp:sasl:0' mechanism='X-HT-SHA-256-ENDP'>
+<authenticate xmlns='urn:xmpp:sasl:1' mechanism='HT-SHA-256-ENDP'>
-  <initial-response></initial-response>
+  <initial-response>[base64 encoded SASL data]</initial-response>
-  <inst-resume xmlns='urn:xmpp:isr:0' without-isr-token='false'/>
+  <inst-resume xmlns='https://xmpp.org/extensions/isr/0' with-isr-token='true'/>
     <resume xmlns='urn:xmpp:sm:3'
             h='some-sequence-number'
             previd='some-long-sm-id'/>
@@ -333,20 +289,20 @@
   stream resumption request together with then initial
   &lt;stream&gt; 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.</p>
+  announced an ISR token.</p>
 
-  <p>Servers MUST destroy the ISR key of a stream after an instant
+  <p>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.</p>
 
   <section3 topic='Successful Stream Resumption' anchor='isr-success'>
 
   <example caption='Successful Instant Stream Resumption'><![CDATA[
-<success xmlns='urn:xmpp:sasl:0'>z
+<success xmlns='urn:xmpp:sasl:1'>z
-  <success-data></success-data>
+  <additional-data></additional-data>
-  <inst-resumed xmlns='urn:xmpp:isr:o'
+  <inst-resumed xmlns='https://xmpp.org/extensions/isr/0'
-                key='006b1a29-c549-41c7-a12c-2a931822f8c0'>
+                token='006b1a29-c549-41c7-a12c-2a931822f8c0'>
     <resumed xmlns='urn:xmpp:sm:3' h='354' previd='123'/>
   </inst-resumed>
 </success>
@@ -354,17 +310,17 @@
 
   <p>On success the server replies with a &lt;success/&gt; nonza as
   specified in the &xep0388;, which must include a
-  &lt;inst-resumed/&gt; element qualified by the 'urn:xmpp:isr:0'
+  &lt;inst-resumed/&gt; element qualified by the 'htpps://xmpp.org/extensions/isr/0'
-  namespace. This element MUST contain a <em>new</em> ISR Key found in
+  namespace. This element MUST contain a <em>new</em> ISR Token found in
-  the 'key' attribute. It also MUST include a &lt;resumed/&gt; as
+  the 'token' attribute. It also MUST include a &lt;resumed/&gt; as
   specified in &xep0198; containing the sequence number of the last by
   Stream Management handled stanza in the 'h' attribute and the
   'previd' attribute.</p>
 
   <p>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.</p>
 
   <p>After the &lt;inst-resumed/&gt; was received and has been
@@ -391,13 +347,13 @@
     but is unable to resume the stream instantly it MUST reply with a
     &lt;success/&gt; Nonza as defined in the &xep0388; containing
     a &lt;inst-resume-failed/&gt; element qualified by the
-    'urn:xmpp:isr:0' namespace. This
+    'htpps://xmpp.org/extensions/isr/0' namespace. This
     &lt;inst-resume-failed/&gt; MUST contain a &lt;failed/&gt;
     element as defined in &xep0198;.</p>
 
     <example caption='Server indicates instant stream resumption failure'><![CDATA[
-<success xmlns='urn:xmpp:sasl:0'>
+<success xmlns='urn:xmpp:sasl:1'>
-  <inst-resume-failed xmlns='urn:xmpp:isr:0'>
+  <inst-resume-failed xmlns='https://xmpp.org/extensions/isr/0'>
     <failed xmlns='urn:xmpp:sm:3'
             h='another-sequence-number'>
       <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -415,25 +371,23 @@
 
   </section3>
 
-  <section3 topic='Multi SASL Mechanism ISR' anchor='multi-sasl-mech-isr'>
+  <section3 topic='Multi step authentication ISR' anchor='multi-step-auth-isr'>
 
-    <p>As specified in the &xep0388; § 2.6.4, a single SASL
+    <p>As specified in the &xep0388; § 2.6.3, sole SASL authentication
-    mechanism may not be sufficient for authentication. In this case,
+    may not be sufficient for authentication. In this case, the remote
-    the remote entity sends a &lt;continue/&gt; element as defined in
+    entity sends a &lt;continue/&gt; element as defined in &xep0388;
-    &xep0388; to request the local entity to perform another
+    to request the local entity to perform another
-    SASL mechanism. Performing instant stream resumption using
+    task.</p>
-    multiple SASL mechanisms MUST only be done if the
-    'without-isr-token' attribute is set to 'true'.</p>
 
     <example caption='Server requires Multi SASL Mechanism ISR'><![CDATA[
-<continue xmlns='urn:xmpp:sasl:0'>
+<continue xmlns='urn:xmpp:sasl:1'>
   <additional-data>
    T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh
   </additional-data>
-  <mechanisms>
+  <tasks>
-    <mechanism>HOTP-EXAMPLE</mechanism>
+    <task>HOTP-EXAMPLE</task>
-    <mechanism>TOTP-EXAMPLE</mechanism>
+    <task>TOTP-EXAMPLE</task>
-  <mechanisms>
+  <tasks>
 </continue>
 ]]></example>
 
@@ -441,12 +395,15 @@
 
     <section3 topic='Failed ISR Authentication' anchor='isr-auth-failed'>
 
-    <p>If the server is unable to authenticate the initiating entity it
+    <p>If the server is unable to authenticate the initiating entity
-    MUST reply with a &lt;failure/&gt; Nonza as defined in
+    it replies with a &lt;failure/&gt; Nonza as defined in
-    &xep0388;.</p>
+    &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.<note>This is to prevent brute force
+    attacks.</note></p>
 
     <example caption='Server indicates instant stream resumption failure'><![CDATA[
-<failure xmlns='urn:xmpp:sasl:0'>
+<failure xmlns='urn:xmpp:sasl:1'>
     <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
 </failure>
 ]]></example>
@@ -461,100 +418,19 @@
 
 </section1>
 
-<section1 topic='The X-HT-* SASL Mechanism' anchor='ht-sasl'>
-
-  <p>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.</p>
-
-  <section2 topic='The X-HT-* Family of Mechanisms' anchor='ht-sasl-mechanism-family'>
-
-    <p>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.</p>
-
-    <table caption='Mapping of CBT to Channel Bindings'>
-      <tr><th>CBT</th><th>Channel Binding Type</th></tr>
-      <tr><td>ENDP</td><td>tls-server-end-point</td></tr>
-      <tr><td>UNIQ</td><td>tls-unique</td></tr>
-    </table>
-
-    <p>The following table lists a few examples of X-HT-* SASL
-    mechanism names.</p>
-
-    <table caption='Example X-HT-* SASL mechanisms'>
-      <tr><th>Mechanism Name</th><th>Hash Algorithm</th><th>Channel-binding unique prefix</th></tr>
-      <tr><td>X-HT-SHA-512-ENDP</td><td>SHA-512 (FIPS 180-4)</td><td>tls-server-end-point</td></tr>
-      <tr><td>X-HT-SHA3-256-ENDP</td><td>SHA3-512 (FIPS 202)</td><td>tls-server-end-point</td></tr>
-      <tr><td>X-HT-SHA-512-UNIQ</td><td>SHA-512 (FIPS 180-4)</td><td>tls-unique</td></tr>
-      <tr><td>X-HT-SHA-256-UNIQ</td><td>SHA-256 (&rfc6920;)</td><td>tls-unique</td></tr>
-    </table>
-  </section2>
-
-  <section2 topic='The X-HT Mechanism' anchor='ht-sasl-mechanism'>
-
-    <p>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:</p>
-
-    <p class='box'>
-      initiator-message = HMAC(token, "Initiator" || cb-data)
-    </p>
-
-    <p>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;).</p>
-
-    <p>This message is followed by a message from the responder to the
-    initiator. This 'responder-message' is defined as follows:</p>
-
-    <p class='box'>
-      responder-message = HMAC(token, "Responder" || cb-data)
-    </p>
-
-    <p>The initiating entity MUST verify the responder-message to
-    achieve mutual authentication.</p>
-
-  </section2>
-
-  <section2 topic='Security Considerations for the X-HT SASL Mechanism' anchor='ht-sasl-security-considerations'>
-
-    <p>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.</p>
-
-  </section2>
-
-</section1>
-
 <section1 topic='Security Considerations' anchor='security'>
 
-  <p>Putting ISR data in <cite>TLS 1.3</cite> 0-RTT early data is
+  <p>Any ISR data SHALL NOT be part of <cite>TLS 1.3</cite> 0-RTT
-  forbidden. (TODO: Shall we weaken this requirement to allow early
+  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.)</p>
 
-  <p>It is of vital importance that the Instant Stream Resumption Key
+  <p>It is of vital importance that the Instant Stream Resumption
-  is generated by a cryptographically secure random generator. See
+  Token is generated by a cryptographically secure random
-  &rfc4086; for more information about Randomness Requirements for
+  generator. See &rfc4086; for more information about Randomness
-  Security</p>
+  Requirements for Security.</p>
 
 </section1>
 
@@ -566,7 +442,7 @@
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
 
-  <p>The &REGISTRAR; includes 'urn:xmpp:isr:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
+  <p>The &REGISTRAR; includes 'htpps://xmpp.org/extensions/isr/0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
 
 </section1>
 
@@ -578,9 +454,14 @@
 
 <section1 topic='Acknowledgements' anchor='acknowledgements'>
 
-  <p>Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland,
+  <p>Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland, Maxime
-  Maxime Buquet and Alexander Würstlein for their feedback.</p>
+  Buquet, Alexander Würstlein and Sam Whited for their feedback.</p>
 
 </section1>
 
 </xep>
+
+<!-- Local Variables: -->
+<!-- fill-column: 100 -->
+<!-- indent-tabs-mode: nil -->
+<!-- End: -->