[20113] in Kerberos_V5_Development
Re: Alternative proxy-creds API for constrained-delegation
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Jun 3 12:02:03 2020
Date: Wed, 3 Jun 2020 11:01:00 -0500
From: Nico Williams <nico@cryptonector.com>
To: Isaac Boukris <iboukris@gmail.com>
Message-ID: <20200603160058.GY7856@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAC-fF8QgfvonVmCjAKHGbDgyL6Kt4H2GsxY9Vnea3=HQ9ZaCVw@mail.gmail.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 03, 2020 at 04:11:08PM +0200, Isaac Boukris wrote:
> To me, gss-proxy sounds like a big requirement, I was hoping for a
> simpler plugable client helper mechanism, that simply talks to a
> daemon when needed and puts the ticket in cache for the client to use.
That's still a proxy. We talked about this on the call. Love had
wanted all of these proxies back in 2012, and I agree with that:
- krb5_get_credentials() proxy
- krb5_mk/rd_req*() proxy
- gss proxy
All of these can be in the same or different programs -- it doesn't
matter much.
In Heimdal, kcm could be this proxy.
> In other words, I'd prefer that we define how gss-proxy and other
> daemon would be able to achieve this with gssapi, rather than the
> other way around.
The use of a proxy is an internal detail that MUST NOT leak into the
API. (It's OK if there's a configuration knob in the API for some of
this, but it must not be required that the app know how to use it.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
