[20103] in Kerberos_V5_Development
Re: Alternative proxy-creds API for constrained-delegation
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Tue Jun 2 19:16:35 2020
MIME-Version: 1.0
In-Reply-To: <20200602220330.GS7856@localhost>
From: Isaac Boukris <iboukris@gmail.com>
Date: Wed, 3 Jun 2020 01:16:15 +0200
Message-ID: <CAC-fF8S5x0CxxhHvLY1rYwfqxB3_fOS=p3xthdg8Wn5co6EjKQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Simo Sorce <simo@redhat.com>, "krbdev@mit.edu Dev List" <krbdev@mit.edu>,
heimdal-discuss@heimdal.software
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wed, Jun 3, 2020 at 12:03 AM Nico Williams <nico@cryptonector.com> wrote:
>
> On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > 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?
>
> If you get a deleg_cred_handle, you should be able to use it in the same
> process without further ado -- no changes needed to code calling
> gss_init_sec_context(), and no gss-proxy should be needed either.
I agree no changes needed to code calling gss_init_sec_context()
should be made, but if we only have a tgt-less cache someone would
have to do the work, thus a proxy is needed. I was trying to imagine
how the proxy code would look like, and how would it return the
requested ticket to be saved in the client cache for next usages.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
