Alternative proxy-creds API for constrained-delegation

[Simo Sorce]

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.

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.

Regular gssapi client:
8. Client uses ccache1 (now with target ticket) to connect to target as
usual.


So this is all doable with custom code if you want, or you can let gss-
proxy do it for you, you definitely have choice.
The difference is that if you build a custom tool you will have to
explicitly use it before running your original client code, if you use
gss-proxy instead you can use unmodified clients and just set up some
configuration,
Of course we also need a modification to gss-proxy code to implement
the new scheme which is analogous to the steps above (only that it is
done transparently because of the gss-proxy mechglue plugin).


HTH,
Simo.


-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc