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