Use of kdc_send_hook with gss_init_sec_context

[Stefan Metzmacher]

Am 05.02.22 um 11:52 schrieb Isaac Boukris:
> On Sat, Feb 5, 2022 at 9:56 AM Stefan Metzmacher <metze at samba.org> wrote:
>>
>>
>> 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
>> https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc_plugin.h
>>
>> 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.
> 
> Looking at send_to_realm() it doesn't seem much different than MIT's
> kdc_send_hook(), so I wonder how you would make use of it for async
> operations, since you need to provide the kdc reply synchronously upon
> returning.

We'd need a helper thread or helper process to run the
gss/krb5 function in blocking mode and use socketpair to the main thread.
the send_to_realm() would be like this:

    sendto(socketpair, realm+req_buffer);
    revcfrom(socketpair, rep_buffer);

While the main thread can almost use the same async logic
to transmit the buffers to the correct kdc as it does for the _step api
case.

My plan would be to use the _step() apis as much as possible
and fallback to the more complex solution if needed.

E.g. call gss_init_sec_context() with send_to_realm() rejecting any
traffic if it happens and only in that case start to use a thread
or helper process.

>> 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.
> 
> Thanks for the hack, I might try it out as it seems simpler than the
> current alternatives I have in mind. That said, with the web being the
> single largest platform in today's ecosystem, I'd still hope for a
> more straightforward way to build and use the krb5 libs on it.

I think a real send_to_realm plugin would be better,
but it will take quite some time to land in distributions.

metze