On Tue, Jun 12, 2018 at 12:36:01PM -0400, Robbie Harwood wrote: > Nico Williams <n...@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 --
