In 1996 (before the 1.0 release), an explicit check was added to the 
krb5 gss_accept_sec_context() implementation to reject the incoming 
token if the ticket endtime expires before the current time.  This 
check may have been motivated by the need to compute a non-negative 
time_rec result.  If the check triggers, gss_accept_sec_context() 
returns GSS_S_CREDENTIALS_EXPIRED, which is incorrect (it suggests 
that the acceptor's verifier_cred_handle has expired) and is not 
consistent with the behavior when krb5_rd_req_decoded() fails due to 
expired tickets.

This unnecessarily strict check causes a particularly bad experience 
when (a) the client's clock is slightly ahead of the server's clock, 
and (b) the maximum service ticket lifetime is lower than the maximum 
TGT lifetime.  In that circumstance, the client will acquire a new 
service ticket using the TGT if the client sees the credential as 
expired, but the application will experience an authentication 
failure if only the server sees the credential as expired.

A better way of dealing with the time_rec computation would be to 
unconditionally add the allowed clock skew to time_rec, and to 
lifetime_rec in krb5_gss_inquire_context.

There is a corresponding piece of code in the krb5 
gss_init_sec_context() to "Enforce a stricter limit" on client 
credentials, but it may not be operative; krb5_get_credentials() will 
already ignore cached service tickets whose endtime is less than the 
current time.

See also:

http://mailman.mit.edu/pipermail/krbdev/2015-October/012457.html