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

["Steve Syfuhs (AP)" <[e-mail]>]

You should implement forest trusts. We automated key rotation in 2000. :)

That said, I'm a bit surprised you've seen any issues with key rotation. We generally return ap-err-modified in such bad key cases which should just trigger a client renew/reauth of the ticket. What do non-Windows clients do in that case? Do they just drop the request? 

RC4-wise we don't have much in the way of documentation because it originated in an MSRC security incident. Client-side telemetry tells us only about 1% of all *observed* encryptions use RC4 (the percentage of devices that have touched RC4 any given day is quite a bit higher). Telemetry is absolutely lying to us because it's only on newer versions of client and server. I wouldn't be surprised if both numbers are actually 2x-5x higher. Part of the problem is that the code to add/remove cipher suites is rather lacking so it's been an...effort...to get to a place where we can outright turn it off. Our strategy is otherwise simple: block RC4 session keys (incidentally, also break XP and friends along the way... oops?), and then once the code is in a place where we can outright disable the RC4 enctype, signal to customers they have 12 months before it goes away. The code is in our vnext branch; now it's just a matter of getting into in-market branches. Herculean effort, and not the fun kind.

I'll have to dig through the client/server logic for how gMSAs are handled. I don't quite remember the exact behavior, but caveat a few bugs we introduced ourselves I can't recall any major reports of timing issues, which I would attribute back to the badkey-retry-getkey behavior our clients have. Also said, I'm not aware of any non-Windows servers that implement gMSA support, especially given Andrew's comment about SAMBA only now investigating adding them. That sorta makes any third party behavior a bit moot.

-----Original Message-----
From: Nico Williams <[e-mail]> 
Sent: Tuesday, February 21, 2023 8:14 PM
To: Steve Syfuhs (AP) <[e-mail]>
Cc: Luke Howard Bentata <[e-mail]>; [e-mail]
Subject: Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

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
--