Re: Negotiating the SCRAM channel binding type

On 07/08/18 22:34, Bruce Momjian wrote:
> On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
>> On 12/07/18 07:14, Michael Paquier wrote:
>>> On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
>>>> I started digging into this more closely, and ran into a little problem. If
>>>> channel binding is not used, the client sends a flag to the server to
>>>> indicate if it's because the client doesn't support channel binding, or
>>>> because it thought that the server doesn't support it. This is the
>>>> gs2-cbind-flag. How should the flag be set, if the server supports channel
>>>> binding type A, while client supports only type B? The purpose of the flag
>>>> is to detect downgrade attacks, where a man-in-the-middle removes the PLUS
>>>> variants from the list of supported mechanisms. If we treat incompatible
>>>> channel binding types as "client doesn't support channel binding", then the
>>>> downgrade attack becomes possible (the attacker can replace the legit PLUS
>>>> variants with bogus channel binding types that the client surely doesn't
>>>> support). If we treat it as "server doesn't support channel binding", then
>>>> we won't downgrade to the non-channel-binding variant, in the legitimate
>>>> case that the client and server both support channel binding, but with
>>>> incompatible types.
>>>>
>>>> What we'd really want, is to include the full list of server's supported
>>>> mechanisms as part of the exchange, not just a boolean "y/n" flag. But
>>>> that's not what the spec says :-(.
>>>
>>> Let's not break the spec :)  I understand from it that the client is in
>>> charge of the choice, so we are rather free to choose the reaction the
>>> client should have.  In the second phase of the exchange, the client
>>> communicates back to the server the channel binding it has decided to
>>> choose, it is not up to the server to pick up one if the client thinks
>>> that it can use multiple ones.
>>
>> The case where the client and the server both support the same channel
>> binding type, we're OK. The problematic case is when e.g. the server only
>> supports tls-unique and the client only supports tls-server-end-point. What
>> we would (usually) like to happen, is to fall back to not using channel
>> binding. But it's not clear how to make that work, and still protect from
>> downgrade attacks. If the client responds "y", meaning "the client supports
>> channel binding, but it looks like the server doesn't", then the server will
>> reject the authentication, because it did actually support channel binding.
>> Just not the same one that the client did. If the client could reply "y",
>> and also echo back the server's list of supported channel bindings in the
>> same message, that would solve the problem. But the spec doesn't do that.
>                  ----------------------------
> 
> I know this is an academic question now, but I am not sure this is true.
> A man-in-the-middle attacker could say they don't support channel
> binding to the real client and real server and pretend to be the real
> server.  What would work is to hash the secret in with the supported
> channel binding list.  This is how TLS works --- all previous messages
> are combined with the secret into a transmitted hash to prevent a MITM
> from changing it.

Yeah, that is what I meant. Currently, when client chooses to not use 
channel binding, it the sends a single flag, y/n, to indicate whether it 
thinks the server supports channel binding or not. That flag is included 
in the hashes used in the authentication, so if a MITM tries to change 
it, the authentication will fail. If instead of a single flag, it 
included a list of channel binding types supported by the server, that 
would solve the problem with supporting multiple channel binding types.

- Heikki