krbtgt compromise

Frank Cusack fcusack at
Tue Aug 26 04:23:34 EDT 2003

"However, the worst key to get compromised is the krbtgt key, as an attacker
could use this to generate a valid TGT for any principal in your realm!"

What if the KDC kept a log of all TGTs issued?  Then the TGS checks
against that log to make sure a TGT was issued when it says it was
issued.  Unlike the replay cache, you'd have to remember ALL unexpired
TGTs issued.  But let's assume you go to disk for this data, so even in
a large environment, space isn't an issue.

Would this work?

Assuming that's a valid idea, let's now consider PK-INIT.  If the KDC
is no longer subject to compromise of the users' keys, then the krbtgt
key is the only thing a root-gone-bad person walks away with.  So then
it seems more worthwhile to protect the krbtgt key.

And if that's true, why not just change that key (say) every day?  Just
like a service key, you keep multiple kvno's on hand.  There'd just have
to be some RPC comms between multiple KDCs in a realm to coordinate key
changes.  (As I see it.)

Forgive me for any misunderstandings about krb5.  I'm certainly no expert.


More information about the krbdev mailing list