One practical problem with Kerberos is that the tickets eventually expire. A
practical balance has to be made between the desire to reduce the usefulness
of stolen tickets (short lifetime) versus the ease-of-use for the user (long
lifetime).

This problem becomes a much larger issue when dealing with long-running user
processes. Jobs run on some supercomputer systems can run for days or weeks,
but having tickets that last that long can be a security nightmare.

The compromise for this problem that was introduced in Kerberos 5 is the
support for renewable tickets. Renewable tickets have expiration times, like
normal tickets. However, they also have a maximum renewable lifetime.

A renewable ticket can be renewed by asking the KDC for a new ticket with an
extended lifetime. However, the ticket itself has to be valid (in other
words, you cannot renew a ticket that has expired; you have to renew it
before it expires). A renewable ticket can be renewed up until the maximum
renewable ticket lifetime.

This scheme has two important advantages over long-lived tickets:

  1. It reduces the window of usefulness for stolen tickets. If an attacker
     gets access to a renewable ticket after it has expired, then it is
     useless.
  2. After a user is finished with a renewable ticket, he can notify the KDC
     that he no longer needs the ticket, and the KDC will refuse to renew
     this ticket any more (note that although this is in the protocol, I
     don't think any version of Kerberos actually implements this part).