[160] in Kerberos
re: Thoughts on the protection of th
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:35:59 1987
From Saltzer@ATHENA.MIT.EDU Sun Feb 1 19:42:43 1987
Date: Sun, 1 Feb 87 19:40:12 EST
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Subject: re: Thoughts on the protection of the master key AND database.
Cc: kerberos@athena.mit.edu
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Fri, 30 Jan 87 18:05:54 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
> The kerberos database master key (and associated password)
> have an interesting property. That is, it has residual value even if
> it is changed.
Jeff's concern for attack using old, less-well protected keys is a
good one. That concern raises several further interesting points.
1. The double-edged sword. When the master key is changed, previous
backup copies become worthless. (Well, not completely; if you
remember the old master key you could reload the old backups, and
rechange the key. But the point of changing the key is to stop being
dependent on it.) So the key change procedure providing both
security and integrity probably goes like this:
- change the master key
- make a couple of new backup tapes and reload one of them to make
sure it is really valid.
- destroy all copies of the old master key and degauss all old
backup tapes.
- load (by hand, I think) the slave servers with the new master
key but tell them not to use it yet.
- send the slave servers the new data base and tell them cut over
to the new master key when they switch to the new data base.
2. Degaussing old backup tapes can help minimize the risk that Jeff
suggests, namely that people may be less protective of old master
keys than new ones.
3. Whether SMS or private backup tapes are used as the backup
mechanism, it might still be wise to encipher/seal keys in a block
containing the associated principal identifer, in order to inhibit
any kind of substitution attack. The one objection is decryption
time, which is serial with each authentication. If we had some
supported decryption hardware for use in the Kerberos servers I think
it would be worth doing this step. While awaiting arrival of such
hardware the idea probably has to be commented out.
4. I agree that SMS does not need to feed Kerberos. I claim further
that the principal identifier field is the ONLY item that needs to be
duplicated between the two data bases, and it provides an adequate
link between the information on record in the two places. There are
two more advantages of keeping SMS clear of Kerberos:
- Kerberos is then forced to be self-sufficient in management
tools, which helps insure its modular exportability.
- it is possible to have Kerberos-authenticable identities that are
not known to SMS. That could be useful in any case where the
administrative boundaries surrounding SMS and Kerberos don't
exactly coincide. (For example, one Kerberos realm might cover
Athena, Administrative Computing, and Telecommunications, while
SMS might maintain information only about Athena.)
Jerry
