Re: Plans for 8.4

On Jul 31, 2008, at 7:58 AM, Magnus Hagander wrote:

> Stephen Frost wrote:
>> * Henry B. Hotz (hbhotz(at)oxy(dot)edu) wrote:
>>> I'm making no promises, but what would people think of a hostgss hba
>>> option?
>>
>> As described, sounds like a win to me. It'd be very nice to be
>> able to
>> just use GSSAPI encryption on the link. That, combined w/ Magnus'
>> work
>> on username/princ mappings, would really bring PostgreSQL up to
>> date wrt
>> GSSAPI support.
>
> Yeah, +1 on this feature, it would be quite useful.
>
>
>> It'd really be great to have this support in the ODBC and JDBC
>> drivers
>> too.. I think in JDBC it might 'just work', I'm less sure about
>> ODBC.
>
> ODBC will need hackery I think. They use libpq for authentication
> only,
> but have their own SSL code and such. I do think ODBC would be a
> fairly
> major point to it being a success, though, so it'd be good if a plan
> could be secured for it. But it's not a showstopper, of course.

I don't know enough about ODBC. If ODBC does SSL independently of PG
then it requires thought by someone who understands ODBC.

>
>> As a practical question- would you really need a seperate explicit
>> pg_hba option for it? It'd be nice to be able to require it, if
>> desired, but that strikes me as more sensible as an option to the
>> 'gss'
>> auth mechanism?
>
> Yeah, if we can get rid of that, that'd be good. The stuff I'm working
> on will allow us to have multiple parameters for each row in name/
> value
> pairs, so if we could use that, it'd be better. (I've been considering
> changing how host/hostssl work that way as well - by having a
> parameter
> similar to what we have on the client side with sslmode=...)
>
> A thought that I came across - is it even possible to use GSSAPI
> encryption *without* using GSSAPI authentication? If not, it really
> seems like it should belong more in the parameter part of the field.
> Since in that case it is also not possible to enable encryption
> *before*
> authentication, or is it?

You're on the right track. My problem isn't the hba file parsing at
all.

My problem is the interaction between the buffering logic and the
encrypted I/O routines. The technical issue is that to make a GSSAPI
security layer independent of SSL you need to invent a whole new
buffering layer. That's a lot of work, and it only buys you the
ability to do both SSL and GSSAPI at the same time. That doesn't seem
worth it.

The code being affected is what's currently configured in column 1 of
hba. The ability to use the new capability requires that SSL *NOT* be
configured in column 1 for the relevant client addresses. In short,
no, it doesn't make sense to make it an option to the gss
authentication method, even though it requires it. If we make it an
option to the gss authentication method it would still need to act
like it was specified in column 1, which would be confusing.

GSSAPI security layers are negotiated after the authentication (or at
least after the start of authentication). There are GSSAPI status
flags that indicate if the security layer is available yet. The
GSSAPI security layer code would check those flags and gss_wrap() or
not accordingly. (-: There's a flush() or two from my original patch
that will need to be added back in, otherwise we'll encrypt a message
that tells the other end how to decrypt messages. Not a big deal. ;-)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu