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