From: Robbie Harwood <rharwood@redhat.com>
To: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Cc: Michael Paquier <michael.paquier@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
        Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v12] GSSAPI encryption support
In-Reply-To: <jlgk2hq3uvr.fsf@thriss.redhat.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>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Mon, 25 Jul 2016 16:58:47 -0400
Message-ID: <jlg7fc91lko.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

Robbie Harwood <rharwood@redhat.com> writes:

> Michael Paquier <michael.paquier@gmail.com> writes:
>
>> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robbie Harwood <rharwood@redhat.com> writes:
>>>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>>>
>>>>> Wait a second.  So the initial connection-request packet is
>>>>> necessarily unencrypted under this scheme?
>>>
>>>> Yes, by necessity.  The username must be sent in the clear, even if
>>>> only as part of the GSSAPI handshake (i.e., the GSSAPI username will
>>>> appear in plantext in the GSSAPI blobs which are otherwise
>>>> encrypted).  GSSAPI performs authentication before it can start
>>>> encryption.
>>>
>>> Ugh.  I had thought we were putting work into this because it
>>> represented something we could recommend as best practice, but now
>>> you're telling me that it's always going to be inferior to what we
>>> have already.
>>
>> It does not seem necessary to have an equivalent of
>> pqsecure_open_client, just some extra handling in fe-connect.c to set
>> up the initial context with a proper message handling... Not that
>> direct anyway. So should the patch be marked as returned with feedback
>> at this stage?
>
> I think in order to satisfy Tom's (valid) concern, there does need to be
> a separate handshake - i.e., GSSAPI support in pqsecure_open_client().
>
> 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).
>
> The way I'm seeing this, when a connection comes in, we take the 'G'
> character for GSSAPI much as for SSL.  At that time, we need to perform
> an *authentication* handshake (because GSSAPI will not do encryption
> before authenticating).  I expect to use a consistent format for all
> GSSAPI packets - four bytes for length, and a payload.  (I would prefer
> tagging them, but previously preference for not doing this has been
> expressed.)
>
> Once GSSAPI authentication is complete, the normal handshake process can
> be tunneled through a GSSAPI encryption layer, as is done with TLS.  The
> server will need to retain some of the earlier authentication data
> (e.g., to check that the presented user-name matches GSSAPI
> credentials), but there will be no authentication packets exchanged
> (more specifically, it will resemble the anonymous case).  Authorization
> will be checked as normal, and we then proceed in the usual fashion, all
> over the GSSAPI tunnel.
>
> 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.  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.
>
> Before I implement this design, does anyone have any additional concerns
> or feedback on it?

Does this look reasonable to folks?

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

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

iQIcBAEBAgAGBQJXln2IAAoJECUy+RdqlaRCwyAP/3c6TnKDBDQrzA99YRo9KpKc
CoqaW83pMkRxnlMJ8IRmI8Y93O8M4CscDdgnHWd+s2jXo0rKfperHI9hZkUt76Jy
S2Jwy8otjy/8O0rbZix8HI81aGleqhaOdTFP0kd1tt69ebXdRAb7NhGzr7WpwkID
aT9R02T2QDO5CF30FXoUgpHzBrILqZA5r5X93m73DB7+J4oXgxq/JQfxCMqGxpG1
dzARWEuvDmncr3GoG9RnN3++tpC+3RdyUiPCbDArzEFoeMuC1KW3qQxfSAxwbVaJ
/xnQINHYZNGEpRuhohM19x78VMGuSDrMSseonB48qDi7R01enhAAI6rhYXR28J3p
PubSbABBWSekqm95IXdSO6nNIznLUOs2GDKsC1era0MTyms/PqsZkSgMiUq7mMvH
aSlP48pDaPjM/Pdvx/nAPUIVfyg4xMUJHKHf3Lcg4WtT76YCcSgPRkxv6Pm9NNsE
64gYsH35KzQaJDa/TFmP4Xi+dA/k9gMQHCaYvAFSHhobbZBzQzfy20cMe5eI0Swk
SHfdSitLGvcSiDme3u7ech+JGPp9sc2GIZqr1IXLP+WGv607tmnGhEf3UVMbfjU0
xANgPcOfUP845pi1popS4GwmbfvIrzCqQJU4bUuCyFNsNvSsyGzz2P52MA05pymX
jkT/Ox4KjUqr1k1+uEGQ
=ROIY
-----END PGP SIGNATURE-----
--=-=-=--