Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 01/06/17 18:11, Bruce Momjian wrote:
> On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote:
>> On Tue, May 30, 2017 at 11:49 PM, Stephen Frost <sfrost@snowman.net> wrote:
>>> ... and I don't believe that we should be asking the
>>> implementors of channel binding to also implement support for multiple
>>> TLS libraries in PostgreSQL in order to test that their RFC-following
>>> (at least, as far as they can tell) implementation actually works.
>> You're of course free to believe what you wish, but that sounds
>> short-sighted to me.  If we implement channel binding and it turns out
>> not to be interoperable with other SSL implementations, then what?  We
>> can't change it later without breaking compatibility with our own
>> prior implementation.  Note that Álvaro Hernández Tortosa said about
>> two hours before you sent this email that it doesn't seem possible to
>> implement something comparable in Java's standard SSL stack.  If
>> that's the case, adopting this implementation is dooming everyone who
>> connects to the database server using JDBC to be unable to use channel
>> binding.  And that's a large percentage of our user base.
> Just to step back, exactly how does channel binding work?  Is each side
> of the SSL connection hashing the password hash with the shared SSL
> session secret in some way that each side knows the other end knows
> the password hash, but not disclosing the secret or password hash?  Is
> there some other way JDBC can get that information?
>

     In short, channel binding augments SCRAM (could be also other
authentication methods, I guess) by adding to the mix of data to be
exchanged, data that comes off-band. Normal SCRAM exchange involves
user, a unique token, a salt and some other information. If you add into
the mix off-band information, that is uniquely known by only client and
server, you can avoid MITM attacks. It's not as simple as "hashing" the
password, though. SCRAM involves 4 steps (2 messages each way) with
somehow complex hashing of data in the last 2 steps.

     There are basically 2 channel binding options, that is, 2 possible
data pieces that could be taken off-band of the SCRAM authentication and
throw them into this mix:

- tls-unique. It's like a unique identifier for each client-server SSL
connection. It should be get from the SSL channel and there doesn't seem
to be a super consistent way of getting it from the channel (in OpenSSL
is an undocumented API, it's not available in normal Java stack, etc).
- tls-server-end-point. Channel binding data is just a hash of a SSL
certificate, as is. As such, seems to be easier to be supported across
multiple OSs/SSL stacks.

     However, SCRAM RFC states that if channel binding is implemented,
at least tls-unique must be implemented, with others being optional
(there is as of today a third one, but only applies to telnet). So in my
opinion, I'd implement both of the above, for maximum flexibility, and
add a field to the required scram authentication febe message with a
list (aka CSV) of the channel binding mechanisms supported by this
server. In this way, I believe covers support for several channel
binding mechanisms and could be extended in the future should other
mechanisms appear.


     Álvaro

--

Álvaro Hernández Tortosa


-----------
<8K>data