[20491] in Kerberos_V5_Development
Re: A Local KDC
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 25 18:19:06 2024
Message-ID: <1eaa7f06-6eec-4ece-8060-ef1b0987ebfe@mit.edu>
Date: Tue, 25 Jun 2024 18:18:51 -0400
MIME-Version: 1.0
To: Andreas Schneider <asn@samba.org>, krbdev@mit.edu
Cc: ab@samba.org
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <2236939.hkbZ0PkbqX@magrathea>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
On 6/25/24 02:39, Andreas Schneider via krbdev wrote:
> MIT Kerberos allows KDC and kadmind daemons to run bound to a particular set
> of network addresses. This allows isolating a configuration to a localhost,
> for example (127.0.0.0/24) but still makes the KDC running all the time. For
> local KDC configurations an amount of principals stored in the KDC database
> and number of requests to be handled would probably be very low. It would be
> great to allow KDC daemons to operate over UNIX domain sockets and handle its
> startup on demand with tools like systemd socket activation or similar
> methods.
I would like to see Unix domain socket support, and may do the work
myself at some point (but can't commit to a specific schedule).
I would be happy to have socket activation support in the KDC and
kadmind, but will probably not do the work myself.
> If there could be a way to overlay individual callbacks on top of
> an existing KDB driver, we could at least have something that would keep user
> and service principals in lmdb and handle PAC issuance using SIDs and account
> details from Samba databases.
I am open to changes which would allow this, though I am probably not
the best person to do the work. I can see two basic categories of
designs: make the KDB interface stackable, or add a new interface
specifically for PAC issuance. It is probably easier to do the second;
the kdcpolicy interface provides an example.
> IAKerb is only available over GSSAPI and one cannot use GSSAPI to
> handle initial authentication for anything but password and keytab based
> credentials.
The hard way to solve this problem is to define a GSS initial creds
acquisition that can handle prompting via key/value sequences, and
rearchitect the preauth system (including the clpreauth pluggable
interface) to work with it--meaning, no more synchronous responder and
prompter callbacks. Such a design would be proxiable,
mechanism-neutral, implementation-neutral, and friendly to language
bindings, but it would take a lot of work to get there.
The easy way is to create a hybrid libkrb5/GSS extension API
(gss_krb5_import_cred() is an example of an API in this category). A
design I had in mind is to convert a krb5_init_creds_context into a GSS
credential handle which could then be used with an IAKERB
gss_init_sec_context(). This design would have none of the benefits I
listed above for the hard way, but would be a comparatively trivial
amount of work.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
