Alternative proxy-creds API for constrained-delegation

[Isaac Boukris]

Hi,

Currently we have an API in MIT to acquire delegated proxy-creds via
gss_accept(), if the credentials include initiator creds (GSS_C_BOTH).

I find this API is really nice as a drop in replacement for
tgt-forwarding, and can be relatively easily adopted by applications,
but on the other hand maybe not suitable for all usage as it:
a. exposes the TGT of the impersonator in the proxy-creds.
b. it may trigger TGT acquisition (with default client kt) in the
gss_accept() call.

I wonder if we can have an alternative API, like
gss_set_{cred/context}_option, to tell gss_accept() to simply delegate
the service ticket in the delegated credentials without any tgt (i
think we used to produce such creds when no forwardable flag was
found). This by itself would provide a simple way to re-authenticate
the client locally.

Then we can implement client plugins, that are invoked in case the
cache hasn't got the requested service ticket, and doesn't have any
TGT.  When invoked, they'ed authenticate to a local host daemon, such
as winbind or gss-proxy or anyone with access to the long term keys,
using the ticket from the tgt-less cache, and get back credentials
(service ticket) for a next service via S4U2Proxy (encrypted using the
established gss context).

If we use cred options, we could use the same flag for
gss_impersonate() as well, otherwise one could call gss_accept() on
the creds acquired via gss_impersonate().

Thoughts?

Thanks!