Alternative proxy-creds API for constrained-delegation

[Nico Williams]

On Wed, Jun 03, 2020 at 01:16:15AM +0200, Isaac Boukris wrote:
> On Wed, Jun 3, 2020 at 12:03 AM Nico Williams <nico at cryptonector.com> wrote:
> > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > What does the daemon do once it get a proxy-creds upon accepting with
> > > GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
> > > extract it and return it to the caller, maybe krb5 api? How does the
> > > caller gets it injected to its cache, would that be possible?
> >
> > If you get a deleg_cred_handle, you should be able to use it in the same
> > process without further ado -- no changes needed to code calling
> > gss_init_sec_context(), and no gss-proxy should be needed either.
> 
> I agree no changes needed to code calling gss_init_sec_context()
> should be made, but if we only have a tgt-less cache someone would
> have to do the work, thus a proxy is needed. I was trying to imagine
> how the proxy code would look like, and how would it return the
> requested ticket to be saved in the client cache for next usages.

That still involves no API changes.  The proxy _could_ share a cache
with the user process calling it if that's a useful optimization, but
it's an optimization, and probably not essential.  For the optimized
case, the proxy client would have to be invoked by the non-proxy krb5
mech if it doesn't find the desired service ticket in the cache.