From 4b020e18f1d579d37566417556f7db0464cb7b1d Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Tue, 4 Aug 2020 12:49:04 +0200 Subject: [PATCH] XEP-0440: Version 0.2.0 of "XEP-0440: SASL Channel-Binding Type Capability" --- xep-0440.xml | 65 ++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/xep-0440.xml b/xep-0440.xml index bbdbfadf..b54764c3 100644 --- a/xep-0440.xml +++ b/xep-0440.xml @@ -23,6 +23,15 @@ sasl-cb-types &flow; + + 0.2.0 + 2020-08-04 + fs + + Discuss interaction with SASL mechanism and add security considerations. + Recommend implementation of tls-server-end-point. + + 0.1.0 2020-06-14 @@ -88,11 +97,56 @@ + + +

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).

+ +

Clients using the information provided + via <sasl-channel-binding/> 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.

+ + + -

The author belives that this document itself does not yield any - new security considerations.Hopefully somebody will correct him, in - case he is wrong.

+

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 + <sasl-channel-binding;> 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 <sasl-channel-binding;>

+ +

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.

+ +

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.

 @@ -117,7 +171,10 @@

Thanks to Sam Whited for the discussion about the underlying - issue and incentivizing me to come up with this extension.

+ 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.