Re: Alternative proxy-creds API for constrained-delegation

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
call:

 - 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
      configuration:

       - name attributes
       - cred options
       - cred store key/value set (for gss_add/acquire_cred_from(),
         gss_store_cred_into())

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

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

+1

> * 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
are nice-to-haves.

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

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

I believe we ended with roughly agreeing on all these various points
(though maybe not on the principles I laid out above).

Nico
-- 
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev