On Fri, Apr 14, 2017 at 8:28 PM, Craig Ringer
wrote:
> There's no point advertising scram-512 if only -256 can work for 'bob'
> because that's what we have in pg_authid.
The possibility to have multiple verifiers has other benefits than
that, password rolling being one. We may want to revisit tha
On 14 Apr. 2017 10:44, "Michael Paquier" wrote:
On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote:
> On 04/13/2017 05:53 AM, Michael Paquier wrote:
>> +* Parse the list of SASL authentication mechanisms in the
>> +* AuthenticationSASL message, and select the best mechanism that w
On Fri, Apr 14, 2017 at 1:37 AM, Heikki Linnakangas wrote:
> On 04/13/2017 05:53 AM, Michael Paquier wrote:
>> +* Parse the list of SASL authentication mechanisms in the
>> +* AuthenticationSASL message, and select the best mechanism that we
>> +* support. (Only SCRAM-SHA-256 is suppo
On 04/13/2017 05:53 AM, Michael Paquier wrote:
Thanks for the updated patches! I had a close look at them.
Let's begin with 0001...
/*
* Negotiation generated data to be sent to the client.
*/
- elog(DEBUG4, "sending SASL response token of length
My only desire would be to have a final spec and implement the full parser
now, not have to change it in the future. We already know today all the
requirements, so please pick one and I will follow it :)
On Apr 13, 2017 13:47, "Heikki Linnakangas" wrote:
> On 04/13/2017 02:35 PM, Álvaro Hernán
On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
On 13/04/17 13:24, Heikki Linnakangas wrote:
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,
th
On 13/04/17 04:54, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
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
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
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 ch
On 04/13/2017 05:54 AM, Michael Paquier wrote:
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
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 t
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa
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 mess
On Thu, Apr 13, 2017 at 2:34 AM, Heikki Linnakangas wrote:
> On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
>>
>> So I still see your proposal more awkward and less clear, mixing
>> things that are separate. But again, your choice :)
>
>
> So, here's my more full-fledged proposal.
>
On 12/04/17 19:34, Heikki Linnakangas wrote:
On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
So I still see your proposal more awkward and less clear, mixing
things that are separate. But again, your choice :)
So, here's my more full-fledged proposal.
The first patch refactors
On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
So I still see your proposal more awkward and less clear, mixing
things that are separate. But again, your choice :)
So, here's my more full-fledged proposal.
The first patch refactors libpq code, by moving the responsibility of
re
On 11/04/17 13:21, Heikki Linnakangas wrote:
On 04/11/2017 01:39 PM, Álvaro Hernández Tortosa wrote:
The fact that you null terminate them (fine with me) doesn't change
my reasoning. How do you separate multiple channel binding methods? And
do you realize that you will be repeating the channel
On 04/11/2017 01:39 PM, Álvaro Hernández Tortosa wrote:
The fact that you null terminate them (fine with me) doesn't change
my reasoning. How do you separate multiple channel binding methods? And
do you realize that you will be repeating the channel binding methods
without reason? A contrived but
On 11/04/17 12:23, Heikki Linnakangas wrote:
On 04/11/2017 11:55 AM, Álvaro Hernández Tortosa wrote:
On 11/04/17 08:50, Heikki Linnakangas wrote:
Oh, I see. According to the SCRAM RFC, "tls-unique" is used by
default. I don't see us implementing anything else any time soon.
PostgreSQL doesn't
On 04/11/2017 11:55 AM, Álvaro Hernández Tortosa wrote:
On 11/04/17 08:50, Heikki Linnakangas wrote:
Oh, I see. According to the SCRAM RFC, "tls-unique" is used by
default. I don't see us implementing anything else any time soon.
PostgreSQL doesn't support any other "channel type" than TLS, and
On 11/04/17 08:50, Heikki Linnakangas wrote:
On 04/10/2017 11:03 PM, Álvaro Hernández Tortosa wrote:
Channel binding needs to specify actually three things:
- The mechanism, which is indeed suffixed "-PLUS".
- The channel binding name, which is described here:
https://tools.ietf.org/html/
On 04/10/2017 11:03 PM, Álvaro Hernández Tortosa wrote:
Channel binding needs to specify actually three things:
- The mechanism, which is indeed suffixed "-PLUS".
- The channel binding name, which is described here:
https://tools.ietf.org/html/rfc5056. Types are also IANA-registered (see
htt
On Tue, Apr 11, 2017 at 4:41 AM, Heikki Linnakangas 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
On 10/04/17 21:41, Heikki Linnakangas wrote:
On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
Thanks for posting the patched HTML. In my opinion, all looks good
except that:
- I will add an extra String (a CSV) to AuthenticationSASL message for
channel binding names, so that messa
On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
Thanks for posting the patched HTML. In my opinion, all looks good
except that:
- I will add an extra String (a CSV) to AuthenticationSASL message for
channel binding names, so that message format can remain without changes
when channe
On 10/04/17 14:57, Heikki Linnakangas wrote:
On 04/07/2017 01:13 AM, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
wrote:
I don't see it. The message AuthenticationSASL.String could
contain a
CSV of the SCRAM protocols supported. This is specially import
On 04/07/2017 01:13 AM, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
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 a
On 04/07/2017 11:57 AM, Craig Ringer wrote:
On 7 April 2017 at 16:33, Heikki Linnakangas wrote:
That list of supported authentication methods would need to be included in
the startup message. Unfortunately, there is no way to add options to the
startup message, without breaking compatibility w
On 7 April 2017 at 16:33, Heikki Linnakangas wrote:
> That list of supported authentication methods would need to be included in
> the startup message. Unfortunately, there is no way to add options to the
> startup message, without breaking compatibility with old servers. If there
> is an option
On 04/06/2017 11:05 PM, Tom Lane wrote:
Perhaps we could turn this around: have the client send (in the connection
request packet) a list of auth protocols it thinks it is able to handle.
(I'm envisioning this as being more or less fixed for any one version of
any one client, since it would basic
On 04/06/2017 11:16 PM, Simon Riggs wrote:
or it
can just ignore the list and send what it wants anyway, probably leading
to client disconnect.
It would need to follow one of the requested protocols, but mark the
request as doomed. Otherwise we'd be revealing information. That's
what SCRAM does
On Fri, Apr 7, 2017 at 7:29 AM, Simon Riggs wrote:
> On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
>
>> Per the SCRAM RFC, it is the server who advertises and the client who
>> picks.
>
> Yes, but what does the RFC say about how to handle servers with an
> pg_hba.conf?
>
> How a
On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote:
> Per the SCRAM RFC, it is the server who advertises and the client who
> picks.
Yes, but what does the RFC say about how to handle servers with an pg_hba.conf?
How and what will we advertise?
--
Simon Riggshttp://
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
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
On 6 April 2017 at 16:05, Tom Lane wrote:
> Perhaps we could turn this around: have the client send (in the connection
> request packet) a list of auth protocols it thinks it is able to handle.
> (I'm envisioning this as being more or less fixed for any one version of
> any one client, since it w
On 06/04/17 22:05, Tom Lane wrote:
Simon Riggs writes:
How would we provide the list of protocols? Surely the protocol is
defined by pg_hba.conf, which makes it dependent upon username,
database and ip range. If the list were accurate, it would allow an
attacker to discover how best to attack
Simon Riggs writes:
> How would we provide the list of protocols? Surely the protocol is
> defined by pg_hba.conf, which makes it dependent upon username,
> database and ip range. If the list were accurate, it would allow an
> attacker to discover how best to attack. If the list were inaccurate
>
On 4 April 2017 at 02:02, Michael Paquier wrote:
> Hi all,
>
> There is still one open item pending for SCRAM that has not been
> treated which is mentioned here:
> https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi
>
> When doing an authentication with SASL, the ser
Hi all,
There is still one open item pending for SCRAM that has not been
treated which is mentioned here:
https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi
When doing an authentication with SASL, the server decides what is the
mechanism that the client has to use.
36 matches
Mail list logo
