Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!spool.mu.edu!uunet!shelby!ATHENA.MIT.EDU!tytso
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.protocols.kerberos
Subject: Re: Storing tickets safely
Message-ID: <9103041733.AA04766@tsx-11.MIT.EDU>
Date: 4 Mar 91 17:33:40 GMT
References: <9103040022.AA13931@snll-arpagw.llnl.gov>
Sender: news@shelby.stanford.edu (USENET News System)
Reply-To: tytso@ATHENA.MIT.EDU
Organization: Internet-USENET Gateway at Stanford University
Lines: 35


   Date: Sun, 3 Mar 91 16:22:28 -0800
   From: hilary@snll-arpagw.llnl.gov (Hilary Jones)

   I was hoping that the next release of Kerberos would in fact have some
   form of ticket caching that didn't depend on the file system.  Perhaps
   some sort of shepherd process so that Kernel mods wouldn't have to be made.
   Without this, I still think the ticket is just a glorified password. 
   I will admit I am being the gadfly here, but this is the one part of
   Kerberos that I haven't completely bought off on.

Well... no.  It's not like your password in that 1) you can't use a
ticket to change your password, 2) you can't use a ticket file on
another workstation without at least some amount of work, and 3) as
shipped, Kerberos V4's maximum ticket lifetime is 21 hours.  

Kerberos V5 will have longer-lived tickets, but it also has provisions
for renewable tickets.  In Kerberos V4, you still can have batch jobs
that may take many days to run --- you just need to modify the programs
to Kerberos authenticate with whatever services they need to at the
beginning of the batch run.  As long as you can maintain some sort of
association (i.e., TCP connection) with the server, and you're not
afraid that someone will be able to hijack the association, you'll be
fine.  So there are some ways to make life more convenient, but in the
long-run you always have a trade-off between security and convenience.

Also note that if a ticket thief has broken root on your workstation,
there really isn't that much difference between grabbing the file out of
/tmp and grabbing it out of /dev/mem.  One's only just a little bit more
difficult that the other.  Also, as you have yourself pointed out, a
ticket thief who has broken root will probably just replace /bin/login
with one that logs passwords and then forwards everything else along to
the real login program.

						- Ted