Alternative proxy-creds API for constrained-delegation

Isaac Boukris iboukris at
Tue Jun 2 14:35:14 EDT 2020

On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <ghudson at> wrote:
> Summary of IRC and voice conversations on this topic:
> 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.
> 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:
> * 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.
> * 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.

I'd still love to see an application signal for the service ticket
using a cred option or name attribute, more likely to help in samba.

> * 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."
> 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.
> 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.

What does the daemon do once it get a proxy-creds upon accepting with
GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
extract it and return it to the caller, maybe krb5 api? How does the
caller gets it injected to its cache, would that be possible?

More information about the krbdev mailing list