This series of mails concluded that channel-binding together with SCRAM (or OPAQUE) provides for the highest additional security beyond TLS.
But channel-binding can only be used, if a MITM isn't able to deactivate it before it can detect the MITM. The security considerations of XEP-0440 ( https://xmpp.org/extensions/ xep-0440.html#security ) show a scenario where a MITM is able to change the server-announced list of supported channel-binding types to only include a dummy type the client certainly does not support or to contain no channel- bindings at all. A client in this situation has two possible actions at hand: 1. Signal in it's SCRAM handshake, that it does support channel-binding, but not the one the server advertised (use "y" for the channel-binding flag as described in RFC 5802). The server will fail authentication if it supports channel-binding. That's bad UX if the problem only arose because no mutual channel-binding type could be found rather than because a MITM occurred. 2. Signal in its SCRAM handshake that it does not support channel-binding at all (use "n" for the channel-binding flag as described in RFC 5802). That won't fail the authentication but leaves a possible MITM undetected. XEP 0440 tries to mitigate this by suggesting to use pinning for the channel- binding types. But that introduces other problems: A server operator deciding to offload TLS termination to an extra box would not be able to offer "tls- exporter" on his server anymore (only the weaker "tls-server-end-point"). Pinning will not allow this downgrade in security and fail the connection/ authentication. I've written my ProtoXEP ("SASL SCRAM Downgrade Protection") to overcome exactly this problem. (Side note: Naming it "SASL SCRAM Downgrade Detection" would have been a better choice.) As long as PLAIN is not supported by the client (and not the only mechanism announced by the server), this protocol can be used to detect downgrades on the channel-binding types, even if channel-binding is not used, and fail the authentication if a downgrade was detected. Some clients can not support channel-binding (for example web-clients). To allow some level of downgrade detection even for those type of clients, I've added the list of announced SASL mechanisms as perceived by the client alongside the list of channel-binding types as perceived by the client. A downgrade from SCRAM-SHA-256 to, say, SCRAM-SHA-1 could be detected even without channel-binding in place and may some day be valuable, if SCRAM-SHA-1 get broken. Yes, that downgrade detection of SASL mechanisms is of limited use in case of SCRAM, because the downgrade can only be detected after the client-final- message was sent, which already contains the client proof based upon the password. But that's a limitation of SCRAM itself, my downgrade detection could be defined for OPAQUE as well and OPAQUE does not have this weakness that SCRAM has. But the downgrade detection of SCRAM mechanisms could still be used to inform the user that a password change could be helpful. (For the record: that same limitation holds for channel-binding using SCRAM as well: the mismatch in channel-binding data will only be detected by the server after the client-final-message was sent.) To make it clear: The main goal of my ProtoXEP is to protect the list of channel-binding types, not the list of SASL mechanisms. But while I was at it, I thought it was trivial to add at least some level of protection for the SASL mechanisms as well. An implementation of this ProtoXEP for Prosody and Monal already exists and works well. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
