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

master
Florian Schmaus 2020-08-04 12:49:04 +02:00
parent 18cf059d08
commit 4b020e18f1
1 changed files with 61 additions and 4 deletions

View File

@ -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>