Merge branch 'premerge' into 'main'

Premerge See merge request xsf/xeps!13
2024-11-24 10:12:19 -05:00 · 2020-08-04 16:02:44 +00:00 · 2020-08-04 16:02:44 +00:00 · 5f0bc97f4d
commit 5f0bc97f4d
parent 18cf059d08 1d993a092e
5 changed files with 84 additions and 9 deletions
--- a/xep-0048.xml
+++ b/xep-0048.xml
@ -10,7 +10,7 @@
  <abstract>This specification defines an XML data format for use by XMPP clients in storing bookmarks to mult-user chatrooms and web pages. The chatroom bookmarking function includes the ability to auto-join rooms on login.</abstract>
  &LEGALNOTICE;
  <number>0048</number>
-  <status>Draft</status>
+  <status>Deprecated</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
@ -19,7 +19,9 @@
    <spec>XEP-0223</spec>
  </dependencies>
  <supersedes/>
-  <supersededby/>
+  <supersededby>
+    <spec>XEP-0402</spec>
+  </supersededby>
  <shortname>bookmarks</shortname>
  <schemaloc>
    <url>http://www.xmpp.org/schemas/bookmarks.xsd</url>
@ -32,6 +34,12 @@
  </author>
  &pgmillard;
  &stpeter;
+  <revision>
+    <version>1.2</version>
+    <date>2020-08-04</date>
+    <initials>XEP Editor (jsc)</initials>
+    <remark>Deprecate in favour of XEP-0402</remark>
+  </revision>
  <revision>
    <version>1.1</version>
    <date>2007-11-07</date>
--- a/xep-0313.xml
+++ b/xep-0313.xml
@ -28,6 +28,14 @@
  </schemaloc>
  &mwild;
  &ksmith;
+  <revision>
+    <version>0.7.1</version>
+    <date>2020-08-04</date>
+    <initials>rufferson</initials>
+    <remark>
+      <p>Fix missing part of sentence to make more sense</p>
+    </remark>
+  </revision>
  <revision>
    <version>0.7.0</version>
    <date>2020-03-20</date>
@ -430,7 +438,7 @@
 </iq>
    ]]></example>

-      <p>If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields, the server MUST return an item-not-found error in response to the query.</p>
+      <p>If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields is not present in the archive, the server MUST return an item-not-found error in response to the query.</p>

    </section3>
    <section3 topic='Retrieving form fields' anchor='query-form'>
--- a/xep-0352.xml
+++ b/xep-0352.xml
@ -10,7 +10,8 @@
  <abstract>This document defines a way for the client to indicate its active/inactive state.</abstract>
  &LEGALNOTICE;
  <number>0352</number>
-  <status>Deferred</status>
+  <status>Proposed</status>
+  <lastcall>2020-08-18</lastcall>
  <lastcall>2017-12-21</lastcall>
  <lastcall>2017-11-15</lastcall>
  <lastcall>2017-03-28</lastcall>
--- a/xep-0411.xml
+++ b/xep-0411.xml
@ -10,7 +10,8 @@
  <abstract>This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML.</abstract>
  &LEGALNOTICE;
  <number>0411</number>
-  <status>Deferred</status>
+  <status>Proposed</status>
+  <lastcall>2020-08-18</lastcall>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
--- a/xep-0440.xml
+++ b/xep-0440.xml
@ -23,6 +23,15 @@
  <supersededby/>
  <shortname>sasl-cb-types</shortname>
  &flow;
+  <revision>
+    <version>0.2.0</version>
+    <date>2020-08-04</date>
+    <initials>fs</initials>
+    <remark>
+	  Discuss interaction with SASL mechanism and add security considerations.
+	  Recommend implementation of tls-server-end-point.
+	</remark>
+  </revision>
  <revision>
    <version>0.1.0</version>
    <date>2020-06-14</date>
@ -88,11 +97,56 @@

 </section1>

+<section1 topic='Interaction with SASL mechanisms' anchor='sasl-mech-interaction'>
+
+  <p>Some channel-binding enabled SASL mechanisms reflect the server's
+  presumed channel-binding abilities back to the server. This prevents
+  SASL-mechanism stripping attacks, where a Man in the Middle (MITM)
+  removes certain SASL mechanisms in an attempt to downgrade the
+  mechanism choosen for authentication to a non-channel-binding enabled
+  one. An example of a SASL mechanism family with this feature is
+  &rfc5802;. This standard specifies the gs2-cbind-flag. The flag has a
+  tristate value of "I don't support channel-binding" (n), "I think you
+  do not support channel-binding, but I do" (y), or, "Let us use
+  channel-binding type X" (p).</p>
+
+  <p>Clients using the information provided
+  via &lt;sasl-channel-binding/&gt; MAY want to indicate to the server
+  that they do not support channel-binding (even if they do) if no
+  mutual supported channel-binding type was found. The only alternative
+  is, that the client signals the server that he believes that the server
+  does not support channel binding. But this may cause the server to
+  terminate the connection, because it indicates a potential ongoing
+  SASL-mechanism stripping attack.</p>
+
+</section1>
+
 <section1 topic='Security Considerations' anchor='security'>

-  <p>The author belives that this document itself does not yield any
-  new security considerations.<note>Hopefully somebody will correct him, in
-  case he is wrong.</note></p>
+  <p>If a client signals to the server that he does not support
+  channel binding, because it found no mutual supported
+  channel-binding types, another MITM attack
+  vector is introduced. An active attacker could replace the
+  &lt;sasl-channel-binding;&gt; list with channel bindings unlikely
+  (or impossible) to be supported by the client. If the client is
+  configured to use non-channel-binding SASL mechanisms as a fallback,
+  this could be used to downgrade the connection security. Note that
+  this attack is a different one than the SASL-mechanism stripping one:
+  Here the attacker tempers with the announced channel-binding types,
+  i.e., the values within &lt;sasl-channel-binding;&gt;</p>
+
+  <p>Depending on the application's security policy, clients may
+  refrain from falling back to non-channel-binding SASL mechanisms
+  if no mutual supported channel-binding type is available.
+  Alternatively, they may try channel-binding with a supported type
+  nevertheless. To mitigate the attack describe above, clients
+  could "pin" the announced channel bindings types by a service. In that
+  case, implementations may want to allow the set of pinned channel-binding
+  types to be extended to stronger ones.</p>
+
+  <p>As further mitigation, it is RECOMMENDED to implement the
+  channel-binding type tls-server-end-point (&rfc5929;) to increase the
+  probability of a mutual supported channel-binding type.</p>

 </section1>

@ -117,7 +171,10 @@
 <section1 topic='Acknowledgements' anchor='acknowledgements'>

  <p>Thanks to Sam Whited for the discussion about the underlying
-  issue and incentivizing me to come up with this extension.</p>
+  issue and incentivizing me to come up with this extension. Further
+  thanks goes to Ruslan N. Marchenko for pointing out the possible
+  MITM attack vector. Last but not least, Dave Cridland provided
+  valuable feedback.</p>

 </section1>