[164] in Kerberos
re: Protecting Kerberos
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:36:31 1987
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
