[OpenAFS] token lifetime

Jayen Ashar jayen@science.unsw.edu.au
Sat, 7 Jul 2012 12:43:20 +1000

We have looked into the other tools, and:

- with renewable tickets, is any security gained?  a cracked/stolen
ticket can be renewed until the renewable lifetime, which seems not much
different to me than simply changing the expiration time.

- with keytabs, what if the keytab is unknowingly cracked or stolen?

we have some long-running processes, which we would like to be able to
read/write to afs beyond 30 days.  some of these jobs may run on clients
we don't control, so we prefer to make changes server-side.  we are
looking at options that offer convenience over security.  we don't want
a user to come after us after six months saying he/she has to redo an
experiment because his token expired.

why 30 days?  does it take 30 days to crack DES?  is there much
difference between 30 days and 300 days?

we're less concerned about the ticket/token being cracked and more
concerned about it being stolen.  while i agree the lifetime limits the
use of a stolen ticket, if a ticket can be unknowingly stolen once, it
can probably be stolen repeatedly.


On 07/07/12 05:56, Brian Sebby wrote:
> The lifetime of a Kerberos ticket is a security measure to prevent someone
> from being able to use your credentials if they can crack your ticket/token.
> AFS still uses DES for its tokens, which is incredibly easy to crack these
> days.  The limited lifetime is part of what prevents this from being an
> incredibly large security issue.  If you have lifetimes that long, with DES,
> you might as well just run your servers with -noauth to turn off all
> authentication.  (Please please please do not actually do this.)
> If you want long-lived tickets, look into using kinit -r, k5start, or any
> of the other tools for extending the lifetime of a ticket/token.
> Brian
> On Fri, Jul 06, 2012 at 06:44:46PM +1000, Jayen Ashar wrote:
>> On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman
>> <jaltman@secure-endpoints.com> wrote:
>>> The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and
>>> tkt_CheckTimes() in src/rxkad/ticket.c.    If the 'end' value is not
>>> exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than
>>> 30 days, the token will be rejected.
>> Can I do anything (without changing code) to make the end 0xFFFFFFFF?
>> As far as I can set, the end is only 0x7FFFFFFF.  If not, is it
>> reasonable to change the 'end' - 'start' to 180 days?
>> Thanks,
>> Jayen