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

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Letting the client choose the protocol to use during a SASL exchange
Date: 2017-04-06 22:13:16
Message-ID: CAB7nPqSd9U24g2666COBhkwMdESbknP8dL6e3QpDqM181TbAKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:
> I don't see it. The message AuthenticationSASL.String could contain a
> CSV of the SCRAM protocols supported. This is specially important to support
> channel binding (which is just another protocol name for this matter), which
> is the really enhanced security mechanism of SCRAM. Since this message is
> sent regardless, and the client replies with PasswordMessage, no extra round
> trip is required. However, PasswordMessage needs to also include a field
> with the name of the selected protocol (it is the client who picks). Or a
> different message would need to be created, but no extra round-trips more
> than those required by SCRAM itself (4 messages for SCRAM + 1 extra for the
> server to tell the client it needs to use SCRAM).

Yes, it seems to me that the list of protocols to send should be done
by sendAuthRequest(). Then the client parses the received string, and
sends an extra 'p' message with its choice before sending the first
SCRAM message. So there is no need for any extra round trips.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-04-06 22:29:42 Re: Letting the client choose the protocol to use during a SASL exchange
Previous Message Peter Geoghegan 2017-04-06 21:57:56 Re: tuplesort_gettuple_common() and *should_free argument