From: Robbie Harwood <rharwood@redhat.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
        Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v12] GSSAPI encryption support
In-Reply-To: 
 <CAB7nPqSmq1tuVGoVQXVb86y9SoaM-wcMDxHD1of9dGc54QYNSQ@mail.gmail.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlgy48ssyvl.fsf@thriss.redhat.com>
 <20160406112105.GG10850@tamriel.snowman.net>
 <jlg1t6isftk.fsf@thriss.redhat.com> <1530.1459977031@sss.pgh.pa.us>
 <jlgy48qqt86.fsf@thriss.redhat.com> <5486.1459984857@sss.pgh.pa.us>
 <CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com>
 <jlgk2hq3uvr.fsf@thriss.redhat.com> <jlg7fc91lko.fsf@thriss.redhat.com>
 <CAB7nPqSmq1tuVGoVQXVb86y9SoaM-wcMDxHD1of9dGc54QYNSQ@mail.gmail.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Tue, 26 Jul 2016 11:22:24 -0400
Message-ID: <jlg7fc8fmq7.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain

Michael Paquier <michael.paquier@gmail.com> writes:

> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood <rharwood@redhat.com> wrote:
>> Robbie Harwood <rharwood@redhat.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.

>>> 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)?

>>> Clients will explicitly probe for GSSAPI support as they do for TLS
>>> support (I look forward to the bikeshed on the order of these) and
>>> should have a parameter to require said support.  One thing I'm not
>>> clear on is what our behavior should be when the user doesn't
>>> explicitly request GSSAPI and doesn't have a ccache - do we prompt?
>>> Skip probing?  I'm not sure what the best option there is.
>
> I am not sure I get what you mean here.

Okay.  Let me try again:

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).

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.

Thanks,
--Robbie

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXl4AwAAoJECUy+RdqlaRCdx8P/33sRpqxtdSUTNNzlk2xnTeC
QEugxb5uwLZh1+j+gRLTLJISI1xUSEdyG3SFbrjbTh3lEQspPEuFlZ7e53W/eytR
CGzTUCoyW1hf2oFxvE7OisTa4XeSReetacU4icXsJDO808dh0m4V0GVJgjAXAQa2
UbsAEW6lT6w59yFcE76Ek9Y3ezhRZDIi5S+BHgi0LJLgEBx5Q9tzj9DAMwtPFwBH
G1nm/+ca2M6Ypa6VFQNj9H7LCQMmiynGBA++WXWBf7vY6JRo1VQ5919Yk3SWtoXT
BfR8i0EEGRqhhgtHykHfN6W/wh7Ncz52sihwjbnM0feCJwFEdrX12VoIFRtVXjGu
IzntudPwaydav7/gvaX3m+pyuYyD0572MG83Oyci3bmz9ukSYc4CvM5n0i73vpUl
Rjkn/frsKktMlHDytWDJUXEV/USe1D+h8iEVkYag3HkS8dH8FgfAbkPVAvQFoZtQ
E0y3bvQwuDk3C/Wq59/4mmagGXRxHWLKarE9Urb1QiiwxBlMV+fBs56LwfzOr0q3
9o7t+iX0EtlYs3OUKrVNkZaiWBjlmsfFjJ8H/npuRPbzPeWqzaHM/f65vUmxcQec
fxC9pCtJ0dpg9tLvtSS5vjut3rhFHiuFCgIErIFmdK+Oz5KrW4fEHM+JGDApKaWP
DjCmm/C5mwveAPG6piuW
=uOqv
-----END PGP SIGNATURE-----
--=-=-=--