Gss context refresh failure due to clock skew

[Simo Sorce]

On 07/10/15 11:46, Olga Kornievskaia wrote:
> 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?

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 :)

Simo.

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


-- 
Simo Sorce * Red Hat, Inc * New York