>
> On Jul 31, 2008, at 7:58 AM, Magnus Hagander wrote:
>
>> Stephen Frost wrote:
>>> * Henry B. Hotz (hbhotz@oxy.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.
I just meant please consider coordinating with the ODBC folks to make
sure it gets in there as well - and in time for the same release.
>>> 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.
Yeah, there seems to be no general point in that.
However, implementing a layer there might have other benefits. Such as
being able to use other SSL implementations (right now we only do
OpenSSL. There has been talk about GnuTLS, and it would be good to be
able to do schannel)
> 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.
Does this hold even if we move the "hostssl" stuff into a parameter "at
the end"? I was thinking maybe something like:
host all all 0.0.0.0/0 md5 ssl=require
host all all 0.0.0.0/0 gss ssl=forbid gssencrypt=require
(you get the idea)
> 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. ;-)
Ok, makes sense.
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment