Re: Alternative proxy-creds API for constrained-delegation
Nico Williams <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <20200603194211.GA7856@localhost> |
On Wed, Jun 03, 2020 at 07:15:23PM +0200, Isaac Boukris wrote: > On Wed, Jun 3, 2020 at 6:01 PM Nico Williams <[email protected]> wrote: > > That's still a proxy. We talked about this on the call. Love had > > wanted all of these proxies back in 2012, and I agree with that: > > > > - krb5_get_credentials() proxy > > > > - krb5_mk/rd_req*() proxy > > > > - gss proxy > > > > All of these can be in the same or different programs -- it doesn't > > matter much. > > Proxy is fine, as long as we define its requirements for *this* feature. All we need is to define the IPC protocol(s), discovery, and the "RPC" calls. gss-proxy already has a framework for all of that, so all we have to do is add a call for krb5_get_credentials() and we won't need any of the others. kcm also has such a framework. - the user would see a ccache without a start TGT, - with a cc config entry that contains the S4U2Proxy credential (evidence ticket), - and every time the user needs a service ticket the app ultimately reaches krb5_get_credentials(), - krb5_get_credentials() notices the S4U2Proxy credential and that it has no access to the _service_ credential, - so krb5_get_credentials() calls its counterpart in the proxy service, - which then does have access to the same ccache _and_ the service credential, so it can satisfy the request. We'd need loop protection so in the case where the proxy can't find the service credential it doesn't then accidentally call itself when it reaches krb5_get_credentials(), naturally. Nico -- _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev