On 13/04/17 13:24, Heikki Linnakangas wrote:
> On 04/13/2017 05:54 AM, Michael Paquier wrote:
>> On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
>> <aht@8kdata.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".
And how about supporting different SCRAM mechanisms with different
possible channel bindings? Separate by space too? So given a field, is
the first item the SCRAM mechanism, and all the remaning the channel
binding methods? I.e.:
SCRAM-SHA-256-PLUS tls-awesome tls-awesome2 tls-awesome3\0...
Please note that if this is the solution chosen:
- A lot of parsing and convention is required (first arg is the SCRAM
mechanism, succesive are channel binding; tls-unique is always
"implied", etc)
- Channel binding names will be repeated for every SCRAM mechanism with
"-PLUS". This is not needed, SCRAM mechanisms and channel binding are
separate things.
- Channel binding names will not be present on others, making the parser
even more complex.
All this vs, again, stating SCRAM mechanisms on one list and
channel binding on another list, which is to my much more KISS. But...
anyway, if this is the decision made, at least I think this should be
documented now, because client parsers need to be designed one way or
another.
Thanks,
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
