[krbdev.mit.edu #889] vast clock skew allows negative-life tickets

[Greg Hudson via RT]

#7063 (discovered by Simo and I) may shed some light on why these huge 
negative clock skews get recorded in the first place.

It's a matter of reasonable debate whether an AS request should pay 
attention to the recorded clock skew of an existing ticket cache.  On 
the one side, perhaps every kinit should be a "blank slate"; after all, 
the only reason we even look at the existing ticket cache is to figure 
out what principal name to use.  On the other hand, if the recorded 
clock skew is legitimate, it could help get the correct end time for the 
new tickets.

Simo suggests that we could look at the resulting ticket and, if its 
lifetime varies wildly from the requested lifetime, we could try again.  
I don't know if that's worth the complexity.  Fixing #7063 should 
eliminate most practical causes of this issue, although it can still 
arise if there's a big adjustment in the system clock between one kinit 
and another.