Robbie Harwood <rharw...@redhat.com> writes: > 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?
Does this look reasonable to folks?
signature.asc
Description: PGP signature
