Re: Gss context refresh failure due to clock skew

[Greg Hudson <ghudson@mit.edu>]

On 10/07/2015 11:00 AM, Adamson, Andy wrote:
> —— from the ticket: —— 
> 
> 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. 
> 
> —— —— 
> I think both a) and b) are incorrect.
> 
> for a) you got it backwards. this occurs when the server clock is ahead of the client clock.

Yes, I did write the wrong thing there; I will follow up on that.

> for b) the relationship between the TGT lifetime and the service ticket lifetime is irrelevant. Only the service ticket lifetime has any effect as the client will use a valid service ticket to construct an RPCSEC_GSS_INIT request irregardless of the TGT lifetime value.

I will try one more time to communicate what I mean:

* If the service ticket end time is less than the TGT end time, then
gss_init_sec_context() fails during the clock skew window, and starts
succeeding again afterwards.

* If the service ticket and TGT have both expired (according to the
server), then gss_init_sec_context() fails, and keeps failing
afterwards, unless there is some out-of-band agent refreshing expired TGTs.

Put another way: we expect authentications to start failing around the
time the TGT expires.  We do not expect authentications to start failing
around the time a service ticket expires, if the TGT is still valid.
That is what I refer to as a "particularly" bad experience.

If that isn't clear, perhaps we should ignore this as a moot point; it
doesn't really affect how we plan to change the krb5 code.