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