[20097] in Kerberos_V5_Development
Alternative proxy-creds API for constrained-delegation
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Mon Jun 1 09:23:48 2020
MIME-Version: 1.0
From: Isaac Boukris <iboukris@gmail.com>
Date: Mon, 1 Jun 2020 15:23:16 +0200
Message-ID: <CAC-fF8SajTKMWrW4D=tj2TDHz_QGMfME+4sGy87XS=esu+23Uw@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>, Nico Williams <nico@cryptonector.com>,
Simo Sorce <simo@redhat.com>, Alexander Bokovoy <abokovoy@redhat.com>,
Stefan Metzmacher <metze@samba.org>,
"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
Hi,
Currently we have an API in MIT to acquire delegated proxy-creds via
gss_accept(), if the credentials include initiator creds (GSS_C_BOTH).
I find this API is really nice as a drop in replacement for
tgt-forwarding, and can be relatively easily adopted by applications,
but on the other hand maybe not suitable for all usage as it:
a. exposes the TGT of the impersonator in the proxy-creds.
b. it may trigger TGT acquisition (with default client kt) in the
gss_accept() call.
I wonder if we can have an alternative API, like
gss_set_{cred/context}_option, to tell gss_accept() to simply delegate
the service ticket in the delegated credentials without any tgt (i
think we used to produce such creds when no forwardable flag was
found). This by itself would provide a simple way to re-authenticate
the client locally.
Then we can implement client plugins, that are invoked in case the
cache hasn't got the requested service ticket, and doesn't have any
TGT. When invoked, they'ed authenticate to a local host daemon, such
as winbind or gss-proxy or anyone with access to the long term keys,
using the ticket from the tgt-less cache, and get back credentials
(service ticket) for a next service via S4U2Proxy (encrypted using the
established gss context).
If we use cred options, we could use the same flag for
gss_impersonate() as well, otherwise one could call gss_accept() on
the creds acquired via gss_impersonate().
Thoughts?
Thanks!
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
