Re: [PATCH v12] GSSAPI encryption support

On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>
>> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>>> Robbie Harwood <rharwood(at)redhat(dot)com> writes:
>>
>> Sorry for my late reply.
>
> Thanks for the feedback!
>
>>>> If I were to continue as I have been - using the plaintext connection
>>>> and auth negotiation path - then at the time of startup the client has
>>>> no way of knowing whether to send connection parameters or not.
>>>> Personally, I would be in favor of not frontloading these connection
>>>> parameters over insecure connections, but it is my impression that the
>>>> project does not want to go this way (which is fine).
>>
>> Per the discussion upthread I got the opposite impression, the startup
>> packet should be sent after the connection has been established. SSL
>> does so: the SSL negotiation goes first, and then the startup packet
>> is sent. That's the flow with the status changing from
>> CONNECTION_SSL_START -> CONNECTION_MADE.
>
> We are in agreement, I think. I have structured the referenced
> paragraph badly: for this design, I'm suggesting separate GSS startup
> path (like SSL) and once a tunnel is established we send the startup
> packet. I probably should have just left this paragraph out.

OK we're good then.

>>>> On the server, I'll need to implement `hostgss` (by analogy to
>>>> `hostssl`), and we'll want to lock authentication on those connections
>>>> to GSSAPI-only.
>>
>> As well as hostnogss, but I guess that's part of the plan.
>
> Sure, `hostnogss` should be fine. This isn't quadratic, right? We don't
> need hostnogssnossl (or thereabouts)?

We don't need to do that far, users could still do the same with two
different lines in pg_hba.conf.

> So there's a connection setting `sslmode` that we'll want something
> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> (which presumably would be the default).

Seeing the debate regarding sslmode these days, I would not say that
"prefer" would be the default, but that's an implementation detail.

> Lets suppose we're working with "prefer". GSSAPI will itself check two
> places for credentials: client keytab and ccache. But if we don't find
> credentials there, we as the client have two options on how to proceed.
>
> - First, we could prompt for a password (and then call
> gss_acquire_cred_with_password() to get credentials), presumably with
> an empty password meaning to skip GSSAPI. My memory is that the
> current behavior for GSSAPI auth-only is to prompt for password if we
> don't find credentials (and if it isn't, there's no reason not to
> unless we're opposed to handling the password).
>
> - Second, we could skip GSSAPI and proceed with the next connection
> method. This might be confusing if the user is then prompted for a
> password and expects it to be for GSSAPI, but we could probably make
> it sensible. I think I prefer the first option.

Ah, right. I completely forgot that GSSAPI had its own handling of
passwords for users registered to it...

Isn't this distinction a good point for not implementing "prefer",
"allow" or any equivalents? By that I mean that we should not have any
GSS connection mode that fallbacks to something else if the first one
fails. So we would live with the two following modes:
- "disable", to only try a non-GSS connection
- "enable", or "require", to only try a GSS connection.
That seems quite acceptable to me as a first implementation to just have that.
--
Michael