Alternative proxy-creds API for constrained-delegation

[Isaac Boukris]

On Wed, Jun 3, 2020 at 4:44 PM Simo Sorce <simo at redhat.com> wrote:
>
> On Wed, 2020-06-03 at 16:11 +0200, Isaac Boukris wrote:
> > On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <ghudson at mit.edu> wrote:
> > > The second half of the problem is a facility for using a "just the
> > > service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> > > host TGT, this has to be done via a privileged service running on the
> > > host.  I think there is general agreement that this should be done via
> > > the existing gss-proxy facility unless we run into a roadblock.
> >
> > To me, gss-proxy sounds like a big requirement, I was hoping for a
> > simpler plugable client helper mechanism, that simply talks to a
> > daemon when needed and puts the ticket in cache for the client to use.
> > In other words, I'd prefer that we define how gss-proxy and other
> > daemon would be able to achieve this with gssapi, rather than the
> > other way around.
>
> What is gss-proxy?
> A pluggable helper client mechanism with that simply talks to a daemon
> when need and puts a ticket in the client ccache.
>
> So I am confused at your claim that gss-proxy is "a big requirement"
> while at the same time describing a mechanism that is equivalent.

The gss-proxy isn't just that, it can also interpose the acceptor and
could have solved this problem in many other ways by its own (as you
said yesterday), that by itself qualifies it as big tool for this
problem.

> Sure, if you build something that is precisely targeted at resolving
> this specific use case, you could build a somewhat smaller "plugin"
> infrastructure, with a smaller plugin and a somewhat smaller daemon,
> but you'd have to do this from scratch and it would be likely
> incompatible with gss-proxy.
>
> Besides, if you look at gss-proxy code you'll see it is not really
> "big". The protocol the proxy describes is also well defined so you are
> not even forced to use the same implementation if, for some reason, you
> want to build something different.
>
> Finally you do not even have to use gss-proxy or a plugin at all.
> Assuming we get a way to just store the client provided ticket from the
> acceptor you can build your own privileged daemon and a client utility
> to achieve the desired goal this way:
>
> Prerequisite:
> 1. service uses new configuration to store service ticket in ccache1
>
> Additional steps compared to normal gssapi client:
> 2. custom client tool uses ccache1 to establish a context over a local
> socket to a privileged daemon.
> 3. privileged daemon use access to service keytab to redo a context
> establishment but uses usage=BOTH in acceptor to crate a s4u2proxy
> enabled delegated credential
> 4. once the context is established client send the target service they
> want a ticket for in the channel
> 5. privileged daemon performs an init_sec_context with the provided
> name to cause gssapi to get a ticket for that target from the kdc
> (alternatively privileged daemon can also use krb5 apis directly).
> 6. privileged daemon sends back a ccache where only the target ticket
> is stored.
> 7. client receives the ccache with the target ticket and stores it in
> ccache1.

Yeah that's roughly the picture I have, although 5-7 steps aren't well
defined, but I'm fine with this basis.