[158] in Kerberos
Thoughts on the protection of the ma
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:35:39 1987
From jis@BITSY.MIT.EDU Fri Jan 30 18:06:51 1987
Date: Fri, 30 Jan 87 18:05:54 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@athena.mit.edu
Subject: Thoughts on the protection of the master key AND database.
The more I think about this issue, the more I think that the
number of systems playing with the kerberos database should be kept to
a minimum. Probably only kerberos itself.
The kerberos database master key (and associated password)
have an interesting property. That is, it has residual value even if
it is changed. Consider the following form of attack:
Grab a copy of the database somehow (poach a backup tape, or
intercept the database being FTP'd in the clear, or have read-only or
write access to the SMS database, whatever...) Now this copy is
useless because all of the secret information is enciphered with the
master key. However bide your time.... At some point the master key is
changed, once changed people are likely to not have any inhibition
from giving out the OLD key (after all it has been changed...). Now
you have a copy of the OLD database AND the old master key. You can
now decrypt your data and obtain the secret key for any principal
which has not changed their key since the time you grabbed the
database. You will probably get a significant number of both user
private keys AND service keys.
This of course is based on the psychology of password
maintenance. Specifically taking advantage that most people consider
an OLD password as no longer confidential.
This leads me to believe that instead of hairing up the master
key encipherment process on private keys, that instead efforts be made
to protect the database from disclosure regardless of the fact that
secret information is enciphered in the master key.
This leads to two changes in direction.
1) SMS should not have a copy of key data from kerberos. This isn't
really necessary anyhow, as all data in SMS can be linked to the
appropriate record in kerberos by the principal (name,instance) fields
which SMS would still have a copy of.
2) Slave kerberos database propagation, which currently sends the
database in the clear, be changed to use a kerberos authenticated
connection to send the data AND use the session key provided by
kerberos to either encipher ALL the data going across the connection,
or at the very least the private key fields.
Because SMS will not have a copy of ALL the information stored
on kerberos, kerberos will need to be a backed up service (ie. the
database should be periodically backed up [which it is today...once a
day to tape]) and the backup media should be protected (ie. stored in
a locked room).
-Jeff
