[20099] in Kerberos_V5_Development
Re: Alternative proxy-creds API for constrained-delegation
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Tue Jun 2 14:35:50 2020
MIME-Version: 1.0
In-Reply-To: <910e4628-757b-9090-56b9-a992c6532a21@mit.edu>
From: Isaac Boukris <iboukris@gmail.com>
Date: Tue, 2 Jun 2020 20:35:14 +0200
Message-ID: <CAC-fF8QCq6vTP6jMHS7MfnDUSieB7kDfgx+0HPY1eYWnKjWwFg@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: Simo Sorce <simo@redhat.com>, "krbdev@mit.edu Dev List" <krbdev@mit.edu>,
heimdal-discuss@heimdal.software,
Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <ghudson@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?
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
