Re: Letting the client choose the protocol to use during a SASL exchange

On 04/13/2017 05:54 AM, Michael Paquier wrote:
> On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
> <aht(at)8kdata(dot)com> wrote:
>> By looking at the them, and unless I'm missing something, I don't see
>> how the extra information for the future implementation of channel binding
>> would be added (without changing the protocol). Relevant part is:
>>
>> The message body is a list of SASL authentication mechanisms, in the
>> server's order of preference. A zero byte is required as terminator after
>> the last authentication mechanism name. For each mechanism, there is the
>> following:
>> <variablelist>
>> <varlistentry>
>> <term>
>> String
>> </term>
>> <listitem>
>> <para>
>> Name of a SASL authentication mechanism.
>> </para>
>> </listitem>
>> </varlistentry>
>> </variablelist>
>> How do you plan to implement it, in future versions, without modifying
>> the AuthenticationSASL message? Or is it OK to add new fields to a message
>> in future PostgreSQL versions, without considering that a protocol change?
>
> I don't quite understand the complain here, it is perfectly fine to
> add as many null-terminated names as you want with this model. The
> patches would make the server just send one mechanism name now, but
> nothing prevents the addition of more.

Right, when we get channel binding, the server will list "SCRAM-SHA-256"
and "SCRAM-SHA-256-PLUS" as the list of mechanisms. And if we get
channel binding using something else than tls-unique, then those will be
added as extra mechanisms, too, e.g. "SCRAM-SHA-256-PLUS tls-awesome".

I don't think that needs to be discussed in the docs yet, because a
client will simply ignore any mechanisms it doesn't understand. Although
perhaps it would be good to mention explicitly that even though SASL
defines that mechanism names have a particular format - all ASCII
upper-case, max 20 chars - the client should accept and ignore arbitrary
strings, not limited to that format.

- Heikki