Gss context refresh failure due to clock skew
ghudson at mit.edu
Wed Oct 7 11:08:38 EDT 2015
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.
More information about the krbdev