Gss context refresh failure due to clock skew

[Olga Kornievskaia]

On Wed, Oct 7, 2015 at 9:48 PM, Simo Sorce <simo at redhat.com> wrote:
> 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.
>

Client should not be acquiring a new service ticket when it has a
non-expired service ticket according to its clock. It is the case that
the server thinks the ticket has expired because it has no slack for
clocks being skewed and that's incorrect.

It's not clear that this issue is agreed upon. Whether or not a new
service ticket is acquired later by the client is not in question.

If the server implements a reasonable clock skew policy, it will allow
for the client side code to detect that the service ticket has expired
and renew it. That functionality is properly working on the client
side.

Alternatively, client side code can be changed to take care of
receiving and properly handling CREDENTIALS_EXPIRED error on the
client side by acquiring a service ticket then which the code doesn't
currently do.

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