Use of kdc_send_hook with gss_init_sec_context

Stefan Metzmacher metze at
Sat Feb 5 02:56:20 EST 2022

Am 04.02.22 um 19:34 schrieb Greg Hudson:
> On 2/4/22 11:57 AM, Isaac Boukris wrote:
>>>> Is there a way to use 'kdc_send_hook' with 'gss_init_sec_context'?
>>>> If there isn't, can we add something like 'gsskrb5_set_krb5_context'?
> I've floated this idea before, as a way to bridge libkrb5 functionality
> (such as krb5_init_context_profile()) and GSS.
> Nico dislikes the idea because he doesn't like anything that encourages
> mechanism-specific code in GSS applications.  He tends to favor name
> attributes as the extension point when possible.
> Sam has raised a more specific objection: if the context set by
> gsskrb5_set_krb5_context() is per-thread (which is the easiest way to
> get around contexts not being thread-safe), then it could be a source of
> subtle bugs if someone creates a GSS object in one thread and gets
> different behavior when they use it in another thread.
> I don't totally understand your use case.  If I read correctly, the
> platform (wasm) requires the use of websockets rather than TCP or UDP.
> So what code would register the send hook and GSS context?  Does every
> application have to be modified in order to work with the platform?
> That doesn't seem like a good long-term design compared to solving the
> problem within libkrb5.

I'd like to propose something similar to the send_to_realm
plugins available in heimdal, see

This is what I'm trying to use in Samba soon,
because it's too much work have everything working with just the _step() apis.

In order to get something working with existing MIT krb5 installations
I had the crazy idea of having a locator plugin, which is registered globally.
That plugin would return a single but unreachable (loopback) address
and also registers a kdc_send_hook to the passed krb5_context (so it also
able to inject it into the krb5_context hidden in the gssapi layer.
The kdc_send_hook() acts like a send_to_realm hook by returning a hook_reply.


More information about the krbdev mailing list