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