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

[Nico Williams <[e-mail]>]

On Wed, Feb 22, 2023 at 03:07:48AM +0000, Steve Syfuhs (AP) wrote:
> True. In the cross-realm krbtgt case we give it an hour I think. I was
> always under the impression that we had that coded that way because of
> replication delays. Or are you thinking hypothetically if one were to
> build this from scratch, today?

People I know will be doing one of these trust account password changes
soon.  It'd be good to know if it's really one hour so we can tune down
the krbtgt/${AD_REALM} principals' ticket lifetimes.

A then-client of mine did one of these rotations in 2012, and we tuned
x-realm krbtgt ticket lifetimes way down ahead of rotating the keys on a
Saturday to avoid any downtime.  Workable, but expensive in terms of
labor.  Key rotations should be smooth w/o manual intervension.  This is
especially important given that because they've not been smooth people
don't rotate them, and now you're retiring RC4 and so they have to
rotate them.  Is there some guidance doc for this somewhere?

> GMSA-wise, a ticket will never be encrypted with an out of date key.
> It's issued to the N key with the ticket set to expire when the
> password is set to roll over. If you're looking to postdate a ticket
> (not something I'm keen on folks doing), you could encrypt to N+1
> because all versions of the key are always derivatives of a constant
> secret plus a time epoch. TOTP on a grander scale if you will.

I feel a bit uncomfortable with non-overlapping key periods.  For one
thing there's clock skew to think about.  For another the ticket
lifetimes will not be the same every time a client requests a ticket --
weird! but especially given that they decrease to zero.  The window of
time for which that could be a problem seems small, but I bet it does
cause problems.  Maybe you've seen hiccups in your telemetry?  I worry
that hiccups in apps that retry with a backoff timer might be getting
papered over and you're missing hiccups in non-Windows, customer apps.

I would prefer that key lifetimes overlap a bit.  The Heimdal virtual
principal service namespace feature too does time-based key derivation
(good to know we're not the only ones thinking of such things!), but it
does allow the service to fetch multiple kvnos (all the ones the service
could need given configured ticket lifetimes and key epochs and current
time), and does not cause ticket lifetimes to be variable.

This a friendly suggestion that AD should store at least up to two keys
per account (plus a time at which each key was set).

Nico
--