Re: Alternative proxy-creds API for constrained-delegation

On Thu, Jun 04, 2020 at 12:20:53AM +0200, Isaac Boukris wrote:
> Thanks, I think I get it better now.

:)

> > Now I'm thinking it'd be nice to have separate sshd_config params for
> > acceptor acquisition from cred_store and storing of
> > deleg_cred_handles...
> 
> So if we go with gss_acquire_cred_from(), we can add a new store
> option "delegation-policy: client-tgt,client-ticket" which will
> override the corresponding krb5.conf option, which will default to
> "client-tgt,proxy-creds". Then one could add GssCredStoreKeyValue
> delegation-policy ...

We could certainly add this on the acceptor credential acquisition side.
We could also add this on the credential storing side.

Since I already have application support for this on the credential
storing side, that's my preference: I won't have to change my sshd at
all.

Yes, that means sshd will get a transient S4U2Proxy deleg_cred_handle
when no cred was delegated that sshd will fail to store if
delegation-policy = client-tgt, but my sshd ignores (logs, but otherwise
ignores) failures to store deleg_cred_handles, so that's not a problem
at all.

That said, I'll probably end up adding code to call
gss_acquire_cred_from(desired_name=GSS_C_NO_NAME, cred_store=...) in
sshd, so this could be an option on both sides.

Note that we could decompose this into an option for each case:

 - a gss_acquire_cred_from() option to say whether to use S4U2Proxy when
   a cred is not delegated (or even always!)

 - a gss_store_cred_into*() option to say whether and how to store an
   S4U2Proxy cred if there were multiple options for that

Note that with gss_acquire_cred_impersonate_name() you can get an
S4U2Self (+ S4U2Proxy) cred without having to have called
gss_accept_sec_context() that could then be stored with
gss_store_cred*().

Nico
-- 
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev