Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

[Nico Williams <[e-mail]>]

On Tue, Feb 21, 2023 at 05:44:05PM +0000, Steve Syfuhs (AP) wrote:
> Here's a useful overview: https://syfuhs.net/how-managed-service-accounts-in-active-directory-work

That helps with running a service on multiple hosts, with each one
retrieving the services keys (well, password anyways).  That's the
intent, correct?

Does AD have key (password) history so that key rotation can be smooth?
I.e., can you change a key (password) and have AD retain the previous
one for some time so as to be able to decrypt extant tickets?

Key history is essential for rekeying trust accounts w/o outages.  It is
_not_ essential (in the KDC anyways) to rekeying other services than
trust accounts, but it _is_ very helpful for clustered services so that
if you add a member to the cluster it can fetch the keys it needs from
the KDC (directory) rather than having to build a thing for sharing keys
from one cluster member to another.

Heimdal's equivalent to your managed service accounts lets clients fetch
keytabs with:

 - all the keys (not passwords, but hey) needed to decrypt potentially
   extant (not yet expired) tickets

    - this potentially includes previous keys (kvnos)

 - all the keys not yet in service that will soon be needed to decrypt
   tickets

This is important because otherwise a new cluster member might not have
all the keys it needs to be able to decrypt tickets in AP-REQs presented
to it, causing something of an outate.  One can say "tough, you can go
get the keys from the other cluster members", but that's how people
conclude that Kerberos sucks.  Having a way to get the keys from the KDC
is much simpler than having to build and integrate a proprietary key
sharing mechanism.

In Heimdal we added a "new service key delay" feature that allows new
keys to be set that won't be used by KDCs yet for a specified amount of
time so as to give cluster members a chance to fetch / sync the new
keys.

We also have a feature where service principals whose names fall in
configured namespaces have their keys derived on the fly from the
namespace's base keys, the principals' names, and the current time
epoch.  And in this case too clients can fetch keytabs with all the keys
needed to decrypt potentially extant tickets + upcoming keys (as if
there was a new service key delay set on future keys).  When using this
feature keys rotate automatically based on the current time and
configured key rotation period for the namespace.

In principle Heimdal can store passwords in the HDB in addition to keys,
and we could have a feature where we return service passwords instead of
keys if desired by sites that prefer your focus on passwords rather than
keys.  We'd still want to return possibly more than one password though,
along with kvno and time metadata, and for that the keytab format is
pretty good -- we'd just need an "enctype" reserved for "password", or
enctypes for "password for deriving keys for enctype XYZ".

> Obviously the AD/Windows-specific stuff wouldn't be appropriate to
> apply to a public spec, but the gist of it might be useful.

Sure.  In this case the thing that's desirable is a protocol for
extracting the keys (passwords).  In your case it's just an LDAP query,
and authorization is handled by the directory (AD).  An HTTP API would
be much better because it would impose much less bloat on the client
stack.

I've concluded that HTTP APIs are a sine qua non for all of this stuff.
Want an online CA?  HTTP.  A kinit-as-a-service?  HTTP.  Negotiate as a
service?  HTTP.  Keytab fetching?  HTTP.  Canned admin tasks?  HTTP.
This has made integration of these new Heimdal features into site-local
orchestration systems much easier on the integrators.

Another thing I've concluded is that metastasizing directory schemas
into lots of codebases in time always becomes a huge headache and no
fun.  Besides, different solutions will have different schemas, and now
you more headaches.  The solution to this is to implement proxies that
provide "stored procedures" that implement simple interfaces to common
tasks.  From a protocol perspective I'd want to standardize such
interfaces.

Yes, LDAP is still needed in your case, though I suppose one could have
an HTTP JSON API that transliterates LDAP to/from JSON as an API to
LDAP.  But it's nice to have simpler HTTP APIs for common tasks.

Nico
--