Gss context refresh failure due to clock skew

[Olga Kornievskaia]

On Wed, Oct 7, 2015 at 11:08 AM, Greg Hudson <ghudson at mit.edu> 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? 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.

> 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev