Alternative proxy-creds API for constrained-delegation
iboukris at gmail.com
Wed Jun 3 12:54:01 EDT 2020
On Wed, Jun 3, 2020 at 5:58 PM Nico Williams <nico at cryptonector.com> wrote:
> On Wed, Jun 03, 2020 at 02:15:58PM +0200, Isaac Boukris wrote:
> > On Wed, Jun 3, 2020 at 6:53 AM Nico Williams <nico at cryptonector.com> wrote:
> > > Here's the idea:
> > >
> > > - you always get a deleg_cred_handle if one was delegated or S4U2Proxy
> > > is available,
> > >
> > > - you tell gss_store_cred_into() about what you're willing to store and
> > > with what options,
> > >
> > > - if you say "only real creds" then gss_store_cred_into() will not
> > > store S4U2Proxy creds.
> > This sounds a lot of application logic, and we also don't want to
> > implicitly delegate a ticket at this point.
> On the contrary, this makes the app simpler because configuration now is
> something of a hole: the app doesn't need to know anything about it, it
> just passes through settings from a config file.
> We do this in our sshd already, so it won't need _any_ changes in order
> to use this new configuration parameter.
Not sure I follow, so your sshd won't need any changes, how does that
make it simple for others? And again, we don't want to implicitly
delegate a ticket at this point.
> > btw, we don't have to call it s4u2proxy creds, it's just a tgt-less
> > cache with a service ticket, maybe we could use it in different
> > manners as well (for local auth, or maybe invent a way to authenticate
> > to the kdc with it?).
> I'm going to call them S4U2Proxy creds. To me that's what they are. It
> tells me what I need to know: that initiator credentials for the service
> are needed.
That's what they are now, but I think we can make other uses of it as
More information about the krbdev