Alternative proxy-creds API for constrained-delegation

[Isaac Boukris]

On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <ghudson at mit.edu> 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?