krbtgt compromise

Nicolas Williams Nicolas.Williams at sun.com
Tue Aug 26 15:40:54 EDT 2003


On Tue, Aug 26, 2003 at 01:23:34AM -0700, Frank Cusack wrote:
> http://www.faqs.org/faqs/kerberos-faq/general/section-46.html
> 
> "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!"

This is true, the TGS key is the worst _single_ key to have compromised,
but worse still would be to have ALL (or any significant subset thereof)
the keys in the KDC compromised.

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

Yes, if you have a single KDC per-realm.  If you have more than one KDC
per-realm then you'd have to replicate this indexed log, in real-time,
to all the KDCs for each realm.

And consider this: if anyone compromises the KDC they'll generally get
not just the TGS key, but also the service keys, and the
password-derived keys.  The way to deal with TGS key compromises is to
re-key the TGS.  The way to deal with service principal key compromises
is to re-key the compromised principals.  The way to deal with user
principal key compromises is to require them to set new passwords.

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

Sure, but if the attacker got the service keys too then he/she can start
minting tickets to those services for any user principals, _without_ the
help of the TGS, even if you're using PKINIT (because PKINIT applies
only to AS requests, not to TGS requests).

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

Yup.

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

You got it, except that generally, if the TGS key is compromised so will
the other principals' keys in that realm be compromised.  (Of course, if
the TGS key is broken [through cryptanalysis], rather than stolen,
that's another story - there you lose just the TGS key - and frequent
TGS re-keying should help prevent that).

Cheers,

Nico
-- 


More information about the krbdev mailing list