[7808] in Kerberos
Re: Mundane kerberos question: srvtab management
daemon@ATHENA.MIT.EDU (Joe Kovara)
Sun Aug 18 04:30:40 1996
To: kerberos@MIT.EDU
Date: Sat, 17 Aug 1996 03:33:06 GMT
From: joek@CyberSafe.com (Joe Kovara)
kenh@cmf.nrl.navy.mil (Ken Hornstein) in comp.protocols.kerberos wrote:
>Now that we are increasing the number of hosts that are in our Kerberos
>realm, one thought comes to mind: the current method for managing srvtabs
>really bites.
>Specifically, the thought of doing "ark host/foo", "xst foo host", etc etc,
>a billion times is giving me screaming nightmares.
Some folks at Morgan Stanley presented a paper at the last Usenix ("Kerberos on
Wall Street") which describes their approach and some of the tradeoffs they
faced, not only for this problem, but many others. Recommended reading.
>I am wondering what larger sites do w.r.t. srvtab management. Are there
>any custom scripts that people use? Do people actually change the keys
>in the srvtabs, or do they leave them at the initial value?
Many sites do change their keys on a regular basis, using existing kerberized
utilities. Changing the keys frequently does have a security benefit. Changing
the keys frequently is an administrative nightmare (as you point out) unless it
is automated. Automating it is not a significant problem. However, automating
it such that you actually get some security benefit out of more frequent key
changes requires a bit more work (but not much).
E.g., Kerberized rsh and a simple script. Install the scripts on the target
systems (when you do the initial install). Use an admin principal from your
"administrative system" (*not* the KDC) to rsh to the target and run the script
and change the keys. Obviously, this assumes that the existing key (both the
host and admin) are good. If the keys don't exist, or the host key has been
compromised, then you have to start at square 1 with an secure (out-of-band) or
not-so-secure (network) distribution.
As to "a bit more work"... This assumes that you can "hide" key change
operations from an attacker, to minimize the probabilty that an attacker can
record the key change operation. If I'm an attacker I'll simply beat on the old
key until I crack it, then (quickly) run through all the key changes I've
recorded until I have your current key. In other words, if you change your keys
remotely using an existing srvtab key, *don't* do it at known and regular
intervals, as this significantly reduces the problem of recording the key change
for an attacker, and reduces the security benefits of more frequent and remote
key changes.
>And as a site note, how many people _really_ use a floppy/tape drive/whatever
>to send the srvtab to various machines, and how many people just ftp it
>over in the clear? I know that the stuff in the srvtabs should never go
>in the clear, but since you only do it once ...
Initial installation of the software is many times accompanied by the generation
of the srvtab--both of which are done locally (securely). I say "many times",
because it is very dependent on the customer. Some sites will take the risk of
moving it over the net with minimal protection, because they have little or no
alternative. I can't blame them. If you need to improve your security, and you
have 50,000+ machines world-wide, you probably have two choices:
1) Slow and secure (or fast and very expensive). Good luck. "Yes, we have a
solution, but it will take 5 years and a dedicated staff of 20 to disitribute
the keys" won't fly.
2) Fast and semi-secure. Is it bullet proof? No, but that's not relevant;
*nothing* is bullet proof. Is it an improvement over existing security? The
answer is almost always "yes", and that's what's relevant.
Regards,
Joe Kovara / CyberSafe Corp. / joek@cybersafe.com
