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

[Greg Hudson <[e-mail]>]

On 2/22/23 12:36, Steve Syfuhs (AP) wrote:
> 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?

We drop the request.  By "renew/reauth" I am guessing you mean flush the 
cache and start with a new local TGT, obtained either by 
reauthenticating with a stored password equivalent or by renewing with 
the existing local TGT.

The open source implementations do not have any concept of a stored 
password equivalent for reauth, for several reasons: retaining a 
non-expiring credential defeats the purpose of expiration times on 
tickets, we aren't deeply integrated into the operating system and 
therefore don't have the concept of an LSA to mitigate the risk of 
storing such a credential, and not every preauth mechanism has a 
non-expiring password equivalent.

Renewing is an option if the local TGT is renewable, but it doesn't help 
if it's non-renewable, or if it's the local TGT which rotated keys.

I'll also echo Nico's concerns about adding to the complexity of the 
client TGS code path.  There is a lot of inherent complexity there 
already: it must be stepwise for IAKERB, there's a lot of fiddly 
processing for RBCD and cross-realm S4U2Self, the open-source 
implementations need to support caller-specified service realms as well 
as referrals, and there are some backwards compatibility hacks.