Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange

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