Re: [PATCH v18] GSSAPI encryption support

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...

>  - 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!

Thanks,
--Robbie