XEP-0440: Version 0.2.0 of "XEP-0440: SASL Channel-Binding Type Capability"

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>