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: 
 <CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@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>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Wed, 15 Jun 2016 19:16:56 -0400
Message-ID: <jlgk2hq3uvr.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 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?

Thanks,
--Robbie

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

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

iQIcBAEBAgAGBQJXYeHpAAoJECUy+RdqlaRCDSoP/AjdgyhEBN6xhpEcLj/PzK3R
OX36duig9mwQDcxpAl9LmWC45IJJdMqdwKQk0STlWZs42Kl3vBkEBkjeCFXC0pNF
8qV1xzOlJ9Rhao15cfFhUmfWgF7ZB2eTgoOpQdRgMQBy1WmFNNomffNkIZJNKpQy
+B6XkjAnWB2Pr+b2ErYbMWilUd4rPQDct1g4xgdT/IcjeYRjonYgtYBr8WXCe858
zHZ0MmfqEF8uFGYDiANjyhnhvTiq2p4N9gHL3JI3AkfVdr8fze6umYJCK9DIzW2T
lQiTAE9VTQ8WqfjMD6EDcvGT3K6k3GYAIVw8WW+ML8BtJMzw7r4izS0nKivT+CFG
KsyCtA0rrK7/ywCIjQgp0USnA8pBUSm3spKLt80W9wSAmGTRJuBM+pRe3KbAXnkO
xXMYd7F9SQiNzV0gAHnkYSisl6E5+pjg6eUxhjzt0olpIX7EyztGmxoBi9Du6piW
OQM1ZgOjocoQHhbcwFQlmM9wJYucFpDzg5eo42bgf2BBj/JMixZXL5nogGAcSzRu
eYqQF806TnoocEnVVb0EVIjxds5ul+7Nfmyz7C3pIJezU32MAzniRc0BJw8vrOyC
ANVhUKmqTyH4cAyfbZ0U1t0uaL0BTi4PTIkGjajVHyMnITatSBwcFPIPvV83QWat
u228LEcdL/QXYwR7B/qU
=g9sC
-----END PGP SIGNATURE-----
--=-=-=--