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
                Name of a SASL authentication mechanism.
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.




Álvaro Hernández Tortosa


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to