Alternative proxy-creds API for constrained-delegation

[Greg Hudson]

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.

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