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 05:36:40PM +0000, Steve Syfuhs (AP) wrote:
> You should implement forest trusts. We automated key rotation in 2000. :)

What RFC is that?  :)

Do we need an LDAP client in order to implement that?

Seriously, if you have key history, then you can rotate x-realm krbtgt
keys w/o trouble.  For non-x-realm krbtgt principals it's useful to have
the "new service key delay" feature so that the new keys can replicate
before they get used.

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

If you're janedoe@A asking for a ticket for some service@B and you
already have a krbtgt/B@A ticket cached, you're going to use that
ticket, and then you might get an error from the KDC if either the
ticket is encrypted in the new key but the B KDC you hit doesn't have it
yet, or if the ticket is encrypted in the old key but the B KDC you hit
no longer has or accepts that key.  I believe MIT and Heimdal stop there
(though I'd have to check).

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

Ok, I'll have to look into whether we have to special case certain
errors in TGS-REQ exchanges and retry in those cases.  This could be
complicated since we might have to purge ccache entries and then retry
from the top rather than retry the current TGS-REQ.

Complicating client-side logic is a problem, and complicated clients is
one of the problems with Kerberos.  For example, I've seen interop
issues with proprietary mobile apps not implementing kerberos referrals
chasing correctly, and getting those issues fixed can be nigh
impossible, and workarounds can be equally impossible.

In this case better key rotation functionality on the KDC can save the
client implementors a great deal of complexity.  Complexity is a big
source of bugs, too.

Nico
--