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
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
From jis@BITSY.MIT.EDU Sun Feb 1 20:18:44 1987
Date: Sun, 1 Feb 87 20:17:56 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@athena.mit.edu
In-Reply-To: Jerome H. Saltzer's message of Sun, 1 Feb 87 19:40:12 EST
<8702020040.AA18909@HERACLES>
Subject: On the backup of kerberos.
The current scheme uses three backup tapes that are rotated through.
A tape gets written each night with three snapshots of the kerberos
database, one from each of the previous three nights.
This scheme has the advantage that only three tapes ever have confidential
data on them to worry about. The disadvantage is that we only save information
for the previous five days (the oldest data being from the oldest file
on the oldest tape). This also makes it unnecessary to deguass any
tapes just because the kerberos master key was changed.
As it turns out we have already had one tape fail, and that tape is
now waiting for me to take it to W91 for deguassing.
-Jeff
From miller%erlang.DEC@decwrl.DEC.COM Thu Feb 12 08:28:43 1987
Date: 11-Feb-1987 1752
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: Protecting Kerberos
From: RHEA::DECWRL::MAILER-DAEMON "Mail Delivery Subsystem" 9-FEB-1987 07:47
To: <erlang::miller (Steve Miller)>
Subj: Returned mail: Cannot send message for 3 days
----- NOTICE -----
Due to a hardware failure, DECWRL has been disconnected from
the Internet for several days. We hope to be reconnected some-
time Monday, Feb 9, 1987. Please give us a chance to recover
and then retry your message.
----- Transcript of session follows -----
I agree with the recent notes by Jeff and Jerry re protecting the
OLD master key and backup copies of the database. Kerberos must be
protected!
The only other solution to losing an old master key would be to
invalidate all the principal keys every time the master key changed.
Then a new key could be established by a protocol that passed the old
password STRING to the password server, before its one-way encryption into
the key form. If that was ok, a new key could be created. Meanwhile,
the old key, compromised by the disclosure of the old Master key, would
not be valid for routine authentication. Since the Kerberos database
already contains a master key version field for each entry, enough hooks
currently exist to do this. This may be too drastic a step for the
Athena environment, but the alternative is to potentially compromise
all the keys.
I would also suggest that the slave copies of the database dont even
use the master key at all. Instead of encrypting the database (or at least
key fields) with a session key in order to transmit it between the master
and the slave, the master can just convert it to be encrypted under
the session key, or some other temporary key. Thus the slave database
has its key fields encrypted by some key OTHER than the master key, and
it changes every time a new slave database version is loaded. This
provides much more protection for the master key, since it now
exists on the master database only.
In other words, where E(foo)bar means Encrypt 'foo' with key 'bar'
Let PrinKey == my principal key
master: EncPrinKey = E(PrinKey)Kmaster /* master encrypts my prin key*/
master: store(EncPrinKey) /* master stores encrypted key*/
master: SlaveKey = E(D(EncPrinKey)Kmaster)Kslave /* master decrypts and
re-encrypts my prin key
using Kslave */
master: ProtSlaveKey = E(SlaveKey)Ksession /* master encrypts SlaveKey for
secure transmission */
master --> slave: ProtSlaveKey /* master transmits sealed key*/
slave: SlaveKey= D(ProtSlaveKey)Ksession /* slave decrypts received key*/
slave: store(SlaveKey) /* slave stores SlaveKey */
slave: PrinKey = D(SlaveKey)Kslave /* slave decrypts to yield PrinKey
upon Kerberos requests */
Ksession is used to protect the transfer, using the private_msg() or
equivalent.
Kslave is another 'session' key used as the temporary 'master' for the
slave.
Despite the best reasonable efforts, sooner or later major Kerberos
security problems, such as disclosing an old master key, will occur. I would
strongly suggest that Jerry, Jeff and others walk through some likely
scenarios and recovery procedures.
Steve.
From Saltzer@ATHENA.MIT.EDU Thu Feb 12 10:21:57 1987
Date: Thu, 12 Feb 87 10:19:17 EST
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Subject: re: Protecting Kerberos
Cc: kerberos@athena.mit.edu (Distribution list @KERB)
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM
(Steve Miller)'s message of 11-Feb-1987 1752
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Steve,
I like the idea that the slaves have their database enciphered with a
temporary Slave Key rather than the real master, to reduce the number
of exposure points for the master. But I don't think your specific
proposal is as effective as it sounds. The problem is that your
scenario sends the new Slave Key enciphered with KSession. Where did
Ksession come from? Presumably it is a result of an authenticated
handshake between the slave and the master. And how did that
handshake get authenticated? Presumably by virtue of a private key
known only to the slave and to some Kerberos, probably the master.
So now the slave's private key becomes an effective "master key",
albeit two steps removed, with the usual problems of future
disclosure. The one advantage your scenario provides is make it
necessary that an attacker who has discovered that private key be
present at the right time so as to watch the initial handshake (so as
to discover Ksession) and also to snatch a copy of
E(SlaveKey)Ksession as it goes by. Assuming everyone is careful to
destroy Ksession as soon as SlaveKey is safely acquired by the slave,
the attack work factor is certainly somewhat higher than if the slave
database is simply enciphered with the Master key.
There is also an availability problem: following a power failure, for
example, the slave Kerberos can't begin work again until it has been
reloaded from the Master Kerberos, unless it took the precaution of
preserving both its old data base and the SlaveKey that is
enciphering it. But preserving the SlaveKey in the persistent
storage of the slave machine is exactly the action that (I assume)
you are trying to avoid, so as to minimize its risk of disclosure.
I agree that we need to work out the best approach to handling the
case where a first-class compromise of the master key occurs.
Jerry
From miller%erlang.DEC@decwrl.DEC.COM Tue Feb 17 20:18:36 1987
Date: 17-Feb-1987 0939
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: More re Protecting kerberos
(The gateway from the DEC engineering net to the Arpanet , 'decwrl',
has been flaky lately, so mail is being delayed and bounced around. spm)
----------------
Jerry,
You are right, my last suggestion only shifts the attack from the
master key to the interchange key between the slave database and
the master Kerberos database. Though it does make it a little harder.
The only way it might work, and still address the availability problem
is if you could afford, operationally, to create new interchange keys
between the slave db and master db every time an update was made,
manually distribute them out of band (Jeff on roller skates!), feed
them to the slaves, then immediately destroy them as soon as the
update protocol had fired up. On powerfail, Jeff on Skates would have
to redo the procedure, but unless all slaves power-failed at once,
Kerberos would still be available. But it would still leave a slave
key resident at the slave, subject to attack, even though no one
had ever directly seen it.
I conclude that it is not worth the effort for Athena for a minor
improvement in security. The only solution is real physical security
of the master keys, backup tapes, maybe even real crypto boxes, key guns, etc.
Perhaps some time before we all retire, Public key can be made fast
enough to allow a 3-way public-key based handshake without the
direct intervention of a 3rd party (Kerberos server) with critical
secrets. Note that Kerberos not only authenticates, but enforces an
expiration date on principals, which would not be possible in a
2-party Public Key exchange. (Assume that the public half is published.)
Introducing the 3rd party introduces that critical secret -- in one case
a Kerberos DES master key, in another an RSA (or similar) public half of
the key-pair.
From jis@BITSY.MIT.EDU Wed Feb 18 15:58:19 1987
Date: Wed, 18 Feb 87 15:56:30 EST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: kerberos@athena.mit.edu
Subject: On the security of kerberos (need for physical security)
All this talk of how to deliver the keys isn't really addressing the
likeliest form of attack, namely:
1) Obtain physical access to a kerberos slave machine.
2) Deposit a trap door program that allows a remote root login at
a later time.
3) Arrange it to look like the system crashed in some "normal" maner.
4) Wait for the system to be restarted.
5) Now while the machine is running, utilize trap door, make a copy of the
database and use the "gcore" program to grab a core image of the
running kerberos server and extract the master key (or the equivalent
of the master key for the database copy you must made).
6) Done. And let Athena beware!
Providing physical security is the key here (no pun intended). Encryption
hardware would help (if the hardware allows the key to be written, but
not read out, and it clears the key memory on bus reset).
-Jeff