Michael Paquier <michael.paqu...@gmail.com> writes: > On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robbie Harwood <rharw...@redhat.com> writes: >>> Tom Lane <t...@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
signature.asc
Description: PGP signature
