Re: [PATCH v12] GSSAPI encryption support - Mailing list pgsql-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?