Re: Negotiating the SCRAM channel binding type

On 11/07/18 14:37, Michael Paquier wrote:
> On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
>> 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
> 
> Can we say for sure that there won't be other options associated to a
> given SASL mechanism?  It seems to me that something like the following
> is better long-term, with channel binding available as a comma-separated
> list of items:
> 
> SCRAM-SHA-256-PLUS channel_bindings=tls-unique,tls-server-end-point
> SCRAM-SHA-256

That would be more complicated to parse. Yeah, we might need further 
options for some SASL mechanisms in the future, but we can cross that 
bridge when we get there. I don't see any need to complicate this case 
for that.

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 :-(.

I guess we should err on the side of caution, and fail the 
authentication in that case. That's unfortunate, but it's better than 
not negotiating at all. At least with the negotiation, the 
authentication will work if there is any mutually supported channel 
binding type.

- Heikki