Gss context refresh failure due to clock skew

[Adamson, Andy]

> On Oct 7, 2015, at 10:45 AM, Greg Hudson <ghudson at MIT.EDU> wrote:
> 
> On 10/07/2015 09:22 AM, Adamson, Andy wrote:
>> Actually, setting the service ticket lifetime to be equal to (or greater than if this is possible) the TGT lifetime will not help. Just as in the example I sent, the application will get permission denied during the time difference between the client and server clock.
> 
> That is expected.  What is not expected, in this variant, is that
> gss_init_sec_context() will succeed by itself once the client believes
> the TGT and service ticket to have expired.  Apologies for any
> miscommunication on this point.
> 
> There may be something in the calling code which refreshes the TGT in
> this situation.  If so, then to fully understand the scenario, we need
> to know how the calling code decides when to refresh the TGT.
> 
> I opened a ticket about this issue here:
> 
>    http://krbdev.mit.edu/rt/Ticket/Display.html?id=8268

—— 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.

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.


Here is how I would describe it:

Change this:

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.


to this

This unnecessarily strict check causes a particularly bad experience
when the server's clock is slightly ahead of the clients clock.
In that circumstance, the client will use the almost expired service 
ticket in constructing the gss_init_sec_context call and not acquire 
a new service ticket using the TGT. The application will experience 
an authentication failure as the server calling gss_accept_sec_context
sees the credential as expired.