Re: Alternative proxy-creds API for constrained-delegation
Isaac Boukris <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <CAC-fF8T0ty8tUuMr3tSMy-onbW_e4sijEfTZZUgKL4BypQAjqw@mail.gmail.com> |
On Thu, Jun 4, 2020 at 1:26 AM Nico Williams <[email protected]> wrote: > > > > 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!) Right, like the above delegation-policy. > - a gss_store_cred_into*() option to say whether and how to store an > S4U2Proxy cred if there were multiple options for that Do we really need that this part? > 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*(). Or I can acquire impersonator creds with gss_acquire_cred_from("delegation-policy: client-ticket"). The krb5.conf though should only apply to gss_accept() though. _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev