Re: [PATCH v12] GSSAPI encryption support

On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood <rharwood@redhat.com> wrote:
> Robbie Harwood <rharwood@redhat.com> writes:

Sorry for my late reply.

>> 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().

Having the communication layer in fe-secure.c definitely makes sense.
The startup process though should not use CONNECTION_SSL_STARTUP.

>> 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).

Per the discussion upthread I got the opposite impression, the startup
packet should be sent after the connection has been established. SSL
does so: the SSL negotiation goes first, and then the startup packet
is sent. That's the flow with the status changing from
CONNECTION_SSL_START -> CONNECTION_MADE.

>> 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.)

OK.

>> 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.

OK, that sounds good.

>> 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.

As well as hostnogss, but I guess that's part of the plan.

>> 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.

I am not sure I get what you mean here.
-- 
Michael