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
<a...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
