Alternative proxy-creds API for constrained-delegation
nico at cryptonector.com
Tue Jun 2 17:58:31 EDT 2020
On Tue, Jun 02, 2020 at 02:11:42PM -0400, Greg Hudson wrote:
> Summary of IRC and voice conversations on this topic:
Thanks. I want to restate a few principles here that I mentioned on the
- where possible, existing APIs should just work if the semantics fit
(Here dealing with an S4U2Proxy credential as a deleg_cred_handle
will work. The detailed differences between such a cred and a
traditional delegated cred are the kind that GSS abstracts away just
fine via the cred handle type.)
- we don't need new APIs for configuration unless that configuration
needs to be dynamic, or specifiable by the application and
specifically not in krb5.conf or the like
- but we can _also_ add new APIs for configuration
- we have three existing ways in GSS today to do slot in application
- name attributes
- cred options
- cred store key/value set (for gss_add/acquire_cred_from(),
which the last is the nicest for configuration because all the
values are strings -- look ma', no OIDs!
- env vars should by and large have configuration equivalents, and
should rarely be the only mechanism for specifying behavior, but
there can be exceptions
> The problem we are trying to solve is making a login server (e.g. a host
> running sshd) use constrained delegation instead of traditional TGT
> delegation. This is harder than, say, the web server scenario, because
> a login session should not have access to a host TGT.
Right. An S4U2Proxy cred output by gss_accept_sec_context() can be used
in the same process without further ado, but storing it is more
complicated because we have a privilege separation issue that will force
us to have an IPC service.
> The first half of the problem is a way for acceptor applications to save
> and store just the service ticket (without the host TGT)--most likely
> through delegated_cred_handle. We considered several options:
I wouldn't do it any other way than as a deleg_cred_handle.
> * Simply do this all the time--so sshd would start storing a ccache with
> just the evidence ticket whenever Kerberos authentication is performed
> and no TGT is delegated. Unless the host is configured for constrained
> delegation, this ccache would not be very useful because it does not
> contain a TGT. In general applications would not behave much
> differently in the presence of this cache (they would tend to fail in
> gss_init_sec_context() just as they would if there were no creds), but I
> objected because it is likely to create rough edges for users and scripts.
I agree this need not be a default behavior, though I believe it could
> * Make the application signal for the service ticket using a cred option
> or name attribute. Nico argued that in most cases, this just would
> devolve to server application configuration, which is no different from
> krb5 mech configuration, so this would just be busy-work for the
> acceptor code.
> * Configure this via krb5.conf or an environment variable or both.
> Isaac suggested an ordered list of delegated credential types, which
> would allow flexible acceptor policy configuration such as "always
> return just the service ticket, even if the client delegates a TGT
> and/or the acceptor cred is GSS_C_BOTH."
+1. I agree with Isaac's proposal.
> There is general agreement on a krb5.conf option, with unclear agreement
> on whether there should also be an environment variable or application
> signal or all three.
I object to none, but a krb5.conf option is necessary, while the others
> 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.
> There was some discussion of whether gss-proxy needs access to
> additional specialized APIs to combine the user's credentials with the
> host's credentials. Nico noted that this could likely be accomplished
> via mech configuration rather than an API, and Simo noted that gss-proxy
> could re-authenticate with the service ticket and GSS_C_BOTH credentials
> to create a proxy cred. So I think there are existing options for the
> implementation, but we can revisit this as needed.
It's certainly easier to make changes to gss-proxy than to other GSS
apps (one vs. many), but I believe everything needed here is
The question that comes up is "how to find the keytab that has the keys
for a given service principal?", and, if you want to cache TGTs obtained
with those, "how to find that cache?". The answer to these is more
configuration -- new krb5 APIs may be needed, though they could be
I believe we ended with roughly agreeing on all these various points
(though maybe not on the principles I laid out above).
More information about the krbdev