Path: utzoo!utgpu!watserv1!watmath!att!emory!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!shelby!ATHENA.MIT.EDU!tytso
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.protocols.kerberos
Subject: Re: srvtab on client machines
Message-ID: <9103012216.AA06363@tsx-11.MIT.EDU>
Date: 1 Mar 91 22:16:21 GMT
References: <9103012146.AA27404@soup.MIT.EDU>
Sender: news@shelby.stanford.edu (USENET News System)
Reply-To: tytso@ATHENA.MIT.EDU
Organization: Internet-USENET Gateway at Stanford University
Lines: 27


   From: qjb@ATHENA.MIT.EDU
   Date: Fri, 1 Mar 91 16:46:39 -0500

   Actually, we often don't bother sending the srvtab over
   encrypted at all.  We often simply copy the srvtab into a
   protect filesystem and copy it to the machine all in the clear.
   Then, once it's there, we run 

   krsvutil change

   to change the keys via the admin protocol.  This is analogous to
   giving a user an initial password and telling him/her to change
   it immediately.

People should note that, under this method, it is theoretically possible
for someone with a Network sniffer to grab the srvtab as it passes by
via FTP or NFS traffic, and then be able to use the knowledge of that
key to figure out what the service key was changed to by spying on the
ksrvutil's protocol exchange with the admin server.  So this method
doesn't really add that much security against a really determined (and
knowledgable) attacker.

People may want to decide that this amount of security is "good enough";
but they should be consciously aware of this decision.

						- Ted