On Mon, 26 Jul 1999, Pete Gonzalez wrote:

[snip]

> > > BTW what exactly is the justification for the expirations?  It seems to
> > > decrease security (by requiring daemons which store the passwords in
> > > cleartext) rather than increase it.
> > 
> > One reason I can come up with is that expiration is needed in case a user
> > logs out, and there isn't a mechanism by which venus can tell the user is
> > no longer logged in, and that tokens should be destroyed. If this were not
> 
> Hmm...  It can't simply check for termination of all processes owned by
> that user?

Probably, I was intending to use this case as a example of the problems
one can have. 

> 
> > the case, a machine which has been compromised could allow an attacker
> > filesystem access to any accounts which have logged into the machine since
> > it was last rebooted. (Granted, haveing the passwords in cleartext allows
> > the same thing, but not *every* client will have cleartext passwords on
> > it)
> 
> Yes, but couldn't the remote server simply clear all the old tokens when
> the rebooted machine connects up again?
> 
> Also, would it be possible to allow a process to opt for no expiration
> when it acquires the token (e.g. with a command line parameter for clog)?
> This would introduce no new security concerns because the process would
> need to be storing the password in cleartext anyway to automatically
> reauthenticate.
> 
> > Kerberos expires tickets for the above reasons, and *also* so that an
> > attacker with a packet sniffer only has a limited amount of time to play
> > use the sniffed information. (Kerberos 5 has mechanisms to keep even this
> > from happening)
> 
> How does Kerberos handle daemons which need to be indefinitely
> authenticated?  Does it use the cleartext/cronjob kludge also?
> 

Let's say you have an mail server (sendmail with procmail for example)  
running that needs authenticated write access to user home directories on
a kerberos-authenticated filesystem (i.e. Kerberos or AFS).

On the machine delivering mail, one can use a 'mail' kerberos principal
and unix user which will have write access to the user's mail directories
via ACL's. The 'key' for this client will get stored on the local machine
in an /etc/srvtab file which contains any kerberos keys for servers
running on the local machine. One then needs to get Kerberos tickets and
Coda tokens by running 'kinit' with an argument to use the key from the
srvtab file and then kclog to generate coda tokens. (This would probably
happen from a cron job.)

I'm not sure I've done a decent job explaining this. If not, I would
definitely suggest spending a couple hours looking up some kerberos
documentation and information on the web.

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy_at_microux.com     |    hozer_at_drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------