Currently, there is no negotiation of the channel binding type between
client and server. The server advertises that it supports channel
binding, or not, and the client decides what channel binding to use. If
the server doesn't support the binding type that the client chose,
authentication will fail.
Based on recent discussions, it looks like there's going to be
differences in this area [1]. OpenSSL can support both tls-unique and
tls-server-end-point. Java only supports tls-server-end-point, while
GnuTLS only supports tls-unique. And Mac OS Secure Transports supports
neither one. Furthermore, it's not clear how TLS v1.3 affects this.
tls-unique might no longer be available in TLS v1.3, but we might get
new channel binding types to replace it. So this is about to get really
messy, if there is no way to negotiate. (Yes, it's going to be messy
even with negotiation.)
I think we must fix that before we release v11, because this affects the
protocol. There needs to be a way for the server to advertise what
channel binding types it supports.
I propose that the server list each supported channel binding type as a
separate SASL mechanism. For example, where currently the server lists:
SCRAM-SHA-256-PLUS
SCRAM-SHA-256
as the supported mechanisms, we change that into:
SCRAM-SHA-256-PLUS tls-unique
SCRAM-SHA-256-PLUS tls-server-end-point
SCRAM-SHA-256
Thoughts? Unfortunately this breaks compatibility with current v11beta
clients, but IMHO we must fix this. If we want to alleviate that, and
save a few bytes of network traffic, we could decide that plain
"SCRAM-SHA-256-PLUS" implies tls-unique, so the list would be:
SCRAM-SHA-256-PLUS
SCRAM-SHA-256-PLUS tls-server-end-point
SCRAM-SHA-256
That would be mostly compatible with current libpq clients.
[1]
https://www.postgresql.org/message-id/flat/20180122072936.GB1772%40paquier.xyz
- Heikki
