From: Robbie Harwood <rharwood@redhat.com>
To: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v12] GSSAPI encryption support
Date: Mon, 25 Jul 2016 16:58:47 -0400
Message-ID: <jlg7fc91lko.fsf@thriss.redhat.com> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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?
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rharwood@redhat.com, michael.paquier@gmail.com, tgl@sss.pgh.pa.us, sfrost@snowman.net
Subject: Re: [PATCH v12] GSSAPI encryption support
In-Reply-To: <jlg7fc91lko.fsf@thriss.redhat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox