[2849] in Kerberos
Re: Compromise of Master Key
daemon@ATHENA.MIT.EDU (jon@security.ov.com)
Fri Oct 8 18:28:54 1993
From: jon@security.ov.com
To: cdavies@remen.bell-atl.com
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Fri, 08 Oct 1993 16:49:27 EDT."
Date: Fri, 08 Oct 1993 17:46:32 -0400
I realize that if the master key is compromised and the database is
obtained that the security of the whole system is compromised.
That's right.
I was wondering, however, exactly WHAT is compromised (i.e., user's
actual passwords obtained?, etc.) and exactly HOW it is compromised.
Actual passwords are not at risk. They are not stored. The keys
derived from those passwords (and all random service keys) are at
risk. If you have a user (or service's) key then you in essence are
that user as far as Kerberos is concerned.
For V4 if you get somebody's key in realm A and they use the same
password in Realm B as in Realm A, their key stored in Realm B will
the same as that stored in Realm A. So a comprise of a key in Realm A
for a principal may also be a comprise of its identity in another
realm, if the same password was used in both. Note, you don't know
what the password was, but it doesn't matter. You can still
masquerade as the principal in question.
However, if you run the Transarc V4 implementation or V5 that doesn't
happen. Both of those salt string to key routine with the realm name
(and for V5 the principal name), so even if you use the same password
in multiple realms your key will be different.
Perhaps we can answer these questions under two different assumptions:
1) That the hacker HAS root
2) That he DOES NOT have root (perhaps poor permissions have
given away the master key).
Root on what machine? The KDC? I don't think it matters. If you get
the KDC database and the master key you can take the data away and use
the keys to get tickets as you wish (or just spy on sessions since you
can get any session key by watching the ticket exchanges and looking
inside).
-- Jon
From: jon@security.ov.com
To: cdavies@remen.bell-atl.com
cc: kerberos@MIT.EDU
Subject: Re: Compromise of Master Key
In-reply-to: Your message of "Fri, 08 Oct 1993 16:49:27 EDT."
<m0olOki-0001KbC@if000353.bell-atl.com>
--------
I realize that if the master key is compromised and the database is
obtained that the security of the whole system is compromised.
That's right.
I was wondering, however, exactly WHAT is compromised (i.e., user's
actual passwords obtained?, etc.) and exactly HOW it is compromised.
Actual passwords are not at risk. They are not stored. The keys
derived from those passwords (and all random service keys) are at
risk. If you have a user (or service's) key then you in essence are
that user as far as Kerberos is concerned. The keys are compromised
because they are stored in the KDC database encrypted in the master
key. If you have the database and the master key then you can decrypt
any principal's key.
For V4 if you get somebody's key in realm A and they use the same
password in Realm B as in Realm A, their key stored in Realm B will
the same as that stored in Realm A. So a comprise of a key in Realm A
for a principal may also be a comprise of its identity in another
realm, if the same password was used in both. Note, you don't know
what the password was, but it doesn't matter. You can still
masquerade as the principal in question.
However, if you run the Transarc V4 implementation or V5 that doesn't
happen. Both of those salt string to key routine with the realm name
(and for V5 the principal name), so even if you use the same password
in multiple realms your key will be different.
Perhaps we can answer these questions under two different assumptions:
1) That the hacker HAS root
2) That he DOES NOT have root (perhaps poor permissions have
given away the master key).
Root on what machine? The KDC? I don't think it matters. If you get
the KDC database and the master key you can take the data away and use
the keys to get tickets as you wish (or just spy on sessions since you
can get any session key by watching the ticket exchanges and looking
inside).
-- Jon
