NegoEx broke GSSAPI in BIND 9

[Ondřej Surý]

Thanks. I came to similar conclusion meanwhile that the code I sent was most likely a red herring.

The error is generated from the code path where the credentials is “NULL“ in a call to gss_accept_sec_context(). This still means we could be doing something wrong on the initiator side, but there’s empty set of credentials too in gss_init_sec_context().

The error could still be somewhere how we are using the API, but it still smells like a regression to me. Though I am happy to fix our code and I’ll continue into digging tomorrow, it’s just not easy for somebody new to the API and the whole concept.

I’ll start with the pointers you gave me.

Ondřej
--
Ondřej Surý — ISC

>> On 20 May 2020, at 18:14, Greg Hudson <ghudson at mit.edu> wrote:
>> 
>> On 5/20/20 5:34 AM, Ondřej Surý wrote:
>> Unfortunately, this stopped working since 1.18.1, but perhaps we were doing something
>> wrong from the beginning. Honestly, looking at the GSSAPI is like reading tea leaves :-),
>> so I would appreciate if I can get some pointers where to start with the debugging.
> 
> I don't immediately see what's going wrong.  What Simo pointed out seems
> unlikely to be related to the regression.
> 
> Given the error message, my best guess is that this is related to commit
> c088f56a62702a2cc99c26185681efee1555b7fa ("Restrict SPNEGO acceptor
> mechs by cred acquisition").  It should be possible to individually
> revert that commit to confirm.  I still wouldn't really know why it
> caused a regression, though.
> 
> The error message corresponds to ERR_SPNEGO_NO_MECHS_AVAILABLE, which
> can be returned from get_available_mechs() or get_negotiable_mechs() in
> src/lib/gssapi/spnego/spnego_mech.c.  If I had a reproduction recipe for
> this, I would start by setting a breakpoint in get_negotiable_mechs() on
> the acceptor side, and figure out the execution path differences between
> 1.17 and 1.18.