pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nico Williams <nico@cryptonector.com>
To: Robbie Harwood <rharwood@redhat.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v18] GSSAPI encryption support
Date: Tue, 12 Jun 2018 11:39:24 -0500
Message-ID: <20180612163923.GE23356@localhost> (raw)
In-Reply-To: <jlgr2lcgdxq.fsf@redhat.com>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
	<jlg1se287n3.fsf@redhat.com>
	<jlg602phyn5.fsf@redhat.com>
	<20180611230026.GC23356@localhost>
	<jlgr2lcgdxq.fsf@redhat.com>

On Tue, Jun 12, 2018 at 12:36:01PM -0400, Robbie Harwood wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > On Mon, Jun 11, 2018 at 04:11:10PM -0400, Robbie Harwood wrote:
> >> Nico was kind enough to provide me with some code review.  This should
> >> those concerns (clarify short-read behavior and fixing error checking on
> >> GSS functions).
> >
> > Besides the bug you fixed and which I told you about off-list (on IRC,
> > specifically), I only have some commentary that does not need any
> > action:
> >
> >  - support for non-Kerberos/default GSS mechanisms
> >
> >    This might require new values for gssmode: prefer-<mechanism-name>
> >    and require-<mechanism-name>.  One could always use SPNEGO if there
> >    are multiple mechanisms to choose from.  And indeed, you could just
> >    use SPNEGO if the user has credentials for multiple mechanism.
> >
> >    (Because GSS has no standard mechanism _names_, this means making
> >    some up.  This is one obnoxious shortcoming of the GSS-API...)
> 
> As long as it's better than passing raw OIDs on the CLI...

Rite?

I think this can be a follow-on patch, though trying SPNEGO if the user
has credentials for multiple mechanisms (and SPNEGO is indicated) seems
simple enough to do now (no interface changes).

> >  - when the SCRAM channel binding work is done, it might be good to add
> >    an option for TLS + GSS w/ channel binding to TLS and no gss wrap
> >    tokens
> 
> I think both of these are neat ideas if they'll be used.  Getting GSSAPI
> encryption in shouldn't preclude either in its present form (should make
> it easier, I hope), but I'm glad to hear of possible future work as
> well!

This one can (must) wait.  It has some security benefits.  You get to
use GSS/Kerberos for authentication, but you get an forward security
you'd get from TLS (if the GSS mechanism doesn't provide it, which
Kerberos today does not).

Nico
-- 




view thread (220+ messages)  latest in thread

Message-ID: <20180612163923.GE23356@localhost>
Permalink:  ../20180612163923.GE23356@localhost/
Also on:    postgresql.org/message-id/20180612163923.GE23356@localhost

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: nico@cryptonector.com, rharwood@redhat.com
  Subject: Re: [PATCH v18] GSSAPI encryption support
  In-Reply-To: <20180612163923.GE23356@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox