Re: [PATCH v12] GSSAPI encryption support

Robbie Harwood <rharwood(at)redhat(dot)com> writes:

> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>
>> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robbie Harwood <rharwood(at)redhat(dot)com> writes:
>>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?