Gss context refresh failure due to clock skew

Simo Sorce simo at
Wed Oct 7 21:48:52 EDT 2015

On 07/10/15 11:46, Olga Kornievskaia wrote:
> On Wed, Oct 7, 2015 at 11:08 AM, Greg Hudson <ghudson at> wrote:
>> 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.
> Why not?

Because technically the client can acquire a new ticket at any time if 
the TGT is valid, but in this case instead it fails to acquire a new 
ticket and fails the authentication.

> This is not what should happen according to the theory of
> Kerberos protocol. Let's use slightly generic terms, TGT is a
> credential that proves client's identity to the KDC. TGT or it's
> lifetime has no relevance in the context of authentication between the
> client and a kerberized service, in this case an NFS server. Then a
> service ticket is a credential that is used to prove client's identity
> to the NFS server. The lifetime of the NFS service ticket should be
> allowed to be valid within some configurable clock skew.

Yes, but this is not what Greg was referring to :)


>> 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.
>> _______________________________________________
>> krbdev mailing list             krbdev at
> _______________________________________________
> krbdev mailing list             krbdev at

Simo Sorce * Red Hat, Inc * New York

More information about the krbdev mailing list