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

On Tue, Apr 11, 2017 at 4:41 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
>> - If the username used is the one sent in the startup message, rather
>> than leaving it empty in the client-first-message, I would force it to
>> be the same as the used in the startuo message.
>
> The problem with that is that the SCRAM spec dictates that the username must
> be encoded in UTF-8, but PostgreSQL supports non-UTF-8 usernames.
>
> Or did you mean that, if the username is sent, it must match the one in the
> startup packet, but an empty string would always be allowed? That would be
> reasonable.

That sounds sensible from here.

>> Otherwise we may confuse
>> some client implementations which would probably consider that as an
>> error; for one, my implementation would currently throw an error if
>> username is empty, and I think that's correct.
>
> I'm not sure I follow. The username is sent from client to server, and
> currently, the server will ignore it. If you're writing a client library, it
> can send whatever it wants. (Although again I would recommend an empty
> string, to avoid confusion. Sending the same username as in the startup
> packet, as long as it's in UTF-8, seems reasonable too.)
>
> Thanks for reviewing this! I'll start hacking on code changes to go with
> these docs.

Sounds good to me, thanks! I looked at the doc patch for now, and here
are some nits.

+ <para>
+ SCRAM-SHA-256 is the only implemented SASL mechanism, at the moment. It is
+ described in detail in [RFC7677] and [RFC5741]. (called just
SCRAM from now on)
+ </para>
Perhaps those should be links to the RFCs.

+<para>
+ Client sends a SASLResponse messsage, with SCRAM
+ <literal>client-final-message</literal> as the content.
+</para>
Typo. Message needs two 's'.

+ <literal>server-final-message</> in the "additional data" field.
+</para>
+
+</sect2>
+
I think that you are missing a </sect1> markup here.

+<listitem>
+<para>
+ Authentication method specific "additional data". If this
+ message contains no additional data, this field is omitted.
+</para>
+</listitem>
So that's for the first message generated by the client in the
exchange. Better than my previous idea. Shouldn't double quotes be
replaced by proper markups?
--
Michael