[krbdev.mit.edu #2027] Premature error 32 (tickets expired) in K4

[Jeffrey Altman]

This is my understanding of the issue, Sam will correct me if I am
wrong:

Kerberos 4 is not supposed to support the renewal of TGTs beyond the
lifetime of the original ticket.  If you change the behavior to allow the
ticket to be valid beyond its initial ticket time it will tickle a protocol
bug which would allow the client to indefinitely extend the lifetime of
the TGT by renewing it for five minutes one second after it expires.
The only way to prevent the bug is to enforce the restriction at the
client within the library. 

Separate and apart from the bug.  The use of extremely short ticket
lifetimes with renewable tickets has usability problems for a variety
of systems.  KFW for example attempts to provide for auto-renewal
of Kerberos 5 tickets.  The renewal process starts at 20 minutes and
issues warnings at 15, 10, 5, and 0 minutes.  Renewal does not work
if the lifetime of the ticket is less than 21 minutes.  This is because
the renewed ticket is always in need of renewal and the KDC treats
the request as a replay.  I strongly advise you to advise the library
to find another solution which does not require tickets of lifetime
less than 30 minutes.  30 minutes is the minimum that KFW will
allow the user to request via the default User Interface configuration.

Jeffrey Altman



Ron DiNapoli via RT wrote:

>Sam--
>
>   When you get a chance, can you email me an explanation of what the 
>security issue is?    You started to explain it a few months ago, but 
>when I raised a question regarding the difference between renewing a 
>ticket with 5 minutes left and one with 4 hours and 5 minutes left, you 
>stated you needed to think about it and would get back to me.    The 
>email I just received is the first communication I've seen on the 
>subject since then, so I'd just like some clarification.   I believe 
>I've kept up on watching the krbdev traffic, but, again, I haven't seen 
>this issues discussed any further.
>
>Thanks,
>--Ron D.
>