From d3fb72ea6de58d285e278459bca9d7cdf7f6a38b Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 4 Jan 2018 15:18:39 -0500 Subject: Implement channel binding tls-server-end-point for SCRAM This adds a second standard channel binding type for SCRAM. It is mainly intended for third-party clients that cannot implement tls-unique, for example JDBC. Author: Michael Paquier --- doc/src/sgml/protocol.sgml | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 8174e3defa7..4c5ed1e6d66 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1575,9 +1575,13 @@ the password is in. Channel binding is supported in PostgreSQL builds with -SSL support. The SASL mechanism name for SCRAM with channel binding -is SCRAM-SHA-256-PLUS. The only channel binding type -supported at the moment is tls-unique, defined in RFC 5929. +SSL support. The SASL mechanism name for SCRAM with channel binding is +SCRAM-SHA-256-PLUS. Two channel binding types are +supported: tls-unique and +tls-server-end-point, both defined in RFC 5929. Clients +should use tls-unique if they can support it. +tls-server-end-point is intended for third-party clients +that cannot support tls-unique for some reason. @@ -1597,9 +1601,10 @@ supported at the moment is tls-unique, defined in RFC 5929. indicates the chosen mechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS. (A client is free to choose either mechanism, but for better security it should choose the channel-binding - variant if it can support it.) In the Initial Client response field, - the message contains the SCRAM - client-first-message. + variant if it can support it.) In the Initial Client response field, the + message contains the SCRAM client-first-message. + The client-first-message also contains the channel + binding type chosen by the client. -- cgit v1.2.3