For instance, for the tls-server-end-point channel binding, it is the server's TLS certificate.
AFAIK it does require the TLS certifificates, but it does not require TLS certificate *validation*. You can use channel binding with just self-signed certs.
tls-server-end-point channel binding type relies on certificates. But SCRAM uses "tls-unique" by default, and it does not use certificates. It's a bit weird that the wikipedia article uses tls-server-end-point as the example, I don't know why anyone would use tls-server-end-point with SCRAM.
Interesting. But we don't support TLS without certificates, do we? We support it without client certificates, but we need a server certificate. So the TLS connection itself still relies on the certificates, justn ot the channel binding.
That said, I stand by my comment that I don't think it's the enterprises that need or want the channel binding. If they care about it, they have already put certificate validation in place, and it won't buy them anything.
Because channel binding also only secures the authentication (SCRAM), not the actual contents and commands that are then sent across the channel, AFAIK?
TLS protects the contents and the commands. The point of channel binding is to defeat a MITM attack, where the client connects to a malicious server, using TLS, which then connects to the real server, using another TLS connection. Channel binding will detect that the client and the real server are not communicating over the same TLS connection, but two different TLS connections, and make the authentication fail.
SSL certificates, with validation, achieves the same, but channel binding achieves it without the hassle of certificates.
Right. It also achieves some more things, but definitely with more hassle.
