Skip Menu |
 

History Show all quoted text — Show full headers
# Mon Oct 26 19:07:23 2015 Olga Kornievskaia <aglo@umich.edu> - Ticket created
Date: Mon, 26 Oct 2015 18:39:43 -0400
Subject: clock skew ignored in latest kerberos?
From: Olga Kornievskaia <aglo@umich.edu>
To: krb5-bugs@mit.edu
Download (untitled) / with headers
text/plain 382B
Hi,

When client and KDC's clock are out of sync, the latest kinit (1.13.2)
doesn't fail with "clock skew" error. Is this intentional?

Steps to reproduce:
1. set client's clock either way ahead or way behind (hours)
2. do kinit and watch it succeed.

While I don't know exactly when the problem started, but in
krb-1.10.3, kinit worked correctly and produced an error.

Thank you.
# Mon Oct 26 19:13:13 2015 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'resolved'
# Mon Oct 26 19:13:13 2015 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 897B
[aglo@umich.edu - Mon Oct 26 19:07:23 2015]:
Show quoted text
> Steps to reproduce:
> 1. set client's clock either way ahead or way behind (hours)
> 2. do kinit and watch it succeed.
>
> While I don't know exactly when the problem started, but in
> krb-1.10.3, kinit worked correctly and produced an error.

If the "kdc_timesync" krb5.conf variable is true (as is the default),
the client will note the difference between its own clock and the
KDC's clock during authentication, and will apply that adjustment to
its clock whenever the tickets are used.

Prior to 1.12, the kdc_timesync functionality did not work when pre-
authentication was required. This was changed by issue #7657[1].
You can, of course, set "kdc_timesync = false" in the [libdefaults]
section of krb5.conf to suppress this behavior, whether or not pre-
authentication is used.

[1] http://krbdev.mit.edu/rt/Ticket/Display.html?id=7657
# Mon Oct 26 19:13:21 2015 ghudson@mit.edu (Greg Hudson) - Tags nochange added
# Mon Oct 26 19:15:33 2015 ghudson@mit.edu (Greg Hudson) - Ticket 8272 RefersTo ticket 7657.
# Tue Oct 27 09:09:30 2015 Olga Kornievskaia <aglo@umich.edu> - Correspondence added
Date: Tue, 27 Oct 2015 09:09:29 -0400
Subject: Re: [krbdev.mit.edu #8272] clock skew ignored in latest kerberos?
From: Olga Kornievskaia <aglo@umich.edu>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
On Mon, Oct 26, 2015 at 7:13 PM, Greg Hudson via RT
<rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> [aglo@umich.edu - Mon Oct 26 19:07:23 2015]:
>> Steps to reproduce:
>> 1. set client's clock either way ahead or way behind (hours)
>> 2. do kinit and watch it succeed.
>>
>> While I don't know exactly when the problem started, but in
>> krb-1.10.3, kinit worked correctly and produced an error.
>
> If the "kdc_timesync" krb5.conf variable is true (as is the default),
> the client will note the difference between its own clock and the
> KDC's clock during authentication, and will apply that adjustment to
> its clock whenever the tickets are used.
>
> Prior to 1.12, the kdc_timesync functionality did not work when pre-
> authentication was required. This was changed by issue #7657[1].
> You can, of course, set "kdc_timesync = false" in the [libdefaults]
> section of krb5.conf to suppress this behavior, whether or not pre-
> authentication is used.
>
> [1] http://krbdev.mit.edu/rt/Ticket/Display.html?id=7657

Thank you for the explanation. One more question: does that allow for
acquiring a ticket for indeterminate future and allow user access even
though say that user's access should be revoked.
# Tue Oct 27 09:09:30 2015 Olga Kornievskaia <aglo@umich.edu> - Comments added
Date: Tue, 27 Oct 2015 09:09:29 -0400
Subject: Re: [krbdev.mit.edu #8272] clock skew ignored in latest kerberos?
From: Olga Kornievskaia <aglo@umich.edu>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
On Mon, Oct 26, 2015 at 7:13 PM, Greg Hudson via RT
<rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> [aglo@umich.edu - Mon Oct 26 19:07:23 2015]:
>> Steps to reproduce:
>> 1. set client's clock either way ahead or way behind (hours)
>> 2. do kinit and watch it succeed.
>>
>> While I don't know exactly when the problem started, but in
>> krb-1.10.3, kinit worked correctly and produced an error.
>
> If the "kdc_timesync" krb5.conf variable is true (as is the default),
> the client will note the difference between its own clock and the
> KDC's clock during authentication, and will apply that adjustment to
> its clock whenever the tickets are used.
>
> Prior to 1.12, the kdc_timesync functionality did not work when pre-
> authentication was required. This was changed by issue #7657[1].
> You can, of course, set "kdc_timesync = false" in the [libdefaults]
> section of krb5.conf to suppress this behavior, whether or not pre-
> authentication is used.
>
> [1] http://krbdev.mit.edu/rt/Ticket/Display.html?id=7657

Thank you for the explanation. One more question: does that allow for
acquiring a ticket for indeterminate future and allow user access even
though say that user's access should be revoked.
# Tue Oct 27 10:32:36 2015 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 1KiB
[aglo@umich.edu - Tue Oct 27 09:09:30 2015]:
Show quoted text
> Thank you for the explanation. One more question: does that allow
for
Show quoted text
> acquiring a ticket for indeterminate future and allow user access
even
Show quoted text
> though say that user's access should be revoked.

No. The KDC always issues tickets for its current time, and the KDC
and servers always enforce ticket endtimes based on their current
times. If you set the client's clock far in the future and kinit,
you're not getting a ticket which is valid far in the future; you are
getting a ticket which is valid right now, using clock correction.

The clock correction feature is not 100% risk-free, at least
analytically. In the absence of FAST or MS-KKDCP, the timestamp sent
from the KDC to the client is not protected against tampering.
Therefore, the client could be fooled into generating an encrypted
timestamp for the future, which an attacker could replay later in
order to get the KDC to issue a ticket. This attack has low value;
the attacker cannot decrypt the ticket without the client's long-term
key.