Clock skew too great status code

[Arpit Srivastava]

Hi,

What is the difference between these two minor status codes ?

-1765328373 KRB5KDC_ERR_NEVER_VALID Requested effective lifetime is
negative or too short
and
-1765328347 KRB5KRB_AP_ERR_SKEW Clock skew too great

Because both of them seem to be getting generated when time on the
client-side is incorrect.

I also obseved that, in case of clock skew is great - I am getting
credentials expired error code instead of clock skew too great error code.
Is there any explaination for this behaviour.

Please help !

Arpit

[Greg Hudson]

On 02/05/2014 03:36 AM, Arpit Srivastava wrote:
> -1765328373 KRB5KDC_ERR_NEVER_VALID Requested effective lifetime is
> negative or too short

This means the KDC responded with protocol error 11
(KDC_ERR_NEVER_VALID), which means that based on the requested end time,
the ticket would be immediately invalid.

This error would result when (a) the client's clock is so far in the
past that its requested end time is before the current time, and (b) the
KDC implementation is Heimdal or (I think) Active Directory. The MIT
krb5 KDC doesn't generate this code, I believe.

> and
> -1765328347 KRB5KRB_AP_ERR_SKEW Clock skew too great

This code is generated when a timestamp which is supposed to be close to
the current time is more than five minutes off. This could be the
timestamp in an authenticator (for a TGS-REQ or an AP-REQ), the
timestamp in encrypted timestamp preauth, or a similar situation.
Generally it means your clock is off by more than five minutes.

> I also obseved that, in case of clock skew is great - I am getting
> credentials expired error code instead of clock skew too great error code.
> Is there any explaination for this behaviour.

Let's say you want ten-hour tickets but your client's clock is nine
hours in the past. The client computes an end time which is one hour
after the KDC's current time, so the KDC issues a one-hour ticket. The
client may have a mechanism which adjusts the effective time for TGS and
AP-REQs, but one hour later, the ticket expires.

If the client's clock is super far in the past, like a full day, then it
would asks for a ticket with an end time in the past. An AD or Heimdal
KDC would respond with KDC_ERR_NEVER_VALID, but the MIT KDC simply
issues a ticket with a zero lifetime. Five minutes later, the ticket
expires.

This could all work better if krb5 had used a ticket lifetime instead of
an end time (like krb4 did, but without the crazy 8-bit representation
of the lifetime). But the protocol was designed under the assumption
that clients, servers, and KDCs would all have mostly synchronized
clocks, so it went with the simplification of always using absolute
timestamps and never relative intervals.

[Nico Williams]

On Wed, Feb 5, 2014 at 11:05 AM, Greg Hudson <ghu...@mit.edu> wrote:
> This could all work better if krb5 had used a ticket lifetime instead of
> an end time (like krb4 did, but without the crazy 8-bit representation
> of the lifetime). But the protocol was designed under the assumption
> that clients, servers, and KDCs would all have mostly synchronized
> clocks, so it went with the simplification of always using absolute
> timestamps and never relative intervals.

And yet implementation-wise relative times are still needed... I
agree, 'twould have been better to have relative lifetime.

[Arpit Srivastava]

Thanks Greg and Niko

I am using MIT Kerberos at client side and AD as KDC.

I am using 8 hrs lifetime for TGT.
Now,
When I increase the time at client side, say 2015, I get following error
codes.
gss_inquire_cred
maj_stat = 720896, min_stat = 100001
gss_init_sec_context
maj_stat = 851968, min_stat = 100005

When I decrease the time at client side, say 2013, I get following error
codes.
gss_inquire_cred
maj_stat = 0, min_stat = 0
gss_init_sec_context
maj_stat = 851968, min_stat = 100005

How to handle such situations ? because I am not getting clock skew error
even once (I get it only at the time of kinit).
Pls advice how to handle clock-related problems at client-side.

Arpit

[Greg Hudson]

On 02/06/2014 09:24 AM, Arpit Srivastava wrote:
> When I increase the time at client side, say 2015, I get following error
> codes.

Minor codes can't be deciphered after the fact, because they are just
points in a mapping table; you need to pass them to gss_display_status
to make them meaningful in an email message or log file.

> How to handle such situations ? because I am not getting clock skew
> error even once (I get it only at the time of kinit).
> Pls advice how to handle clock-related problems at client-side.

If you (1) require preauth on user principals, (2) use MIT krb5 1.12 or
later on the client, and (3) have kdc_timesync turned on (as it is by
default), then I think the client should adjust for even large clock
skew values when it gets initial tickets. The client's initial request
may be nonsensical, but it will resync using the time in the
PREAUTH_REQUIRED error from the KDC. The only concern is whether the
KDC will return PREAUTH_REQUIRED for the initial request or whether it
could return NEVER_VALID instead, which would abort the initial ticket
exchange.

Any clock drift *after* the initial tickets are obtained could still
cause problems, but hopefully the clock doesn't drift by five minutes
over eight hours.

[Arpit Srivastava]

I have one more observation that I want some clarification on.

When credentials expires, and I immediately call gss_init_sec_context, I
get minor -1765328373 (Requested effective lifetime is negative or too
short)
but after 2-3 minutes, I call gss_init_sec_context again, I get expected
minor code of credentials expired.

What is the reasoning behind this behaviour. I have MIT Krb5 client and
Windows AD KDC.

Arpit

[Greg Hudson]

On 02/11/2014 04:28 AM, Arpit Srivastava wrote:
> When credentials expires, and I immediately call gss_init_sec_context, I
> get minor -1765328373 (Requested effective lifetime is negative or too
> short)
> but after 2-3 minutes, I call gss_init_sec_context again, I get expected
> minor code of credentials expired.

In the first case, the KDC accepted your TGT for the TGS request
(because of clock skew allowance) but calculated that the service ticket
would never be valid. In the second case, the KDC rejected your TGT as
expired.

(At least, I think that's what is going on. The GSSAPI client code can
locally generate a KRB5KRB_AP_ERR_TKT_EXPIRED error, but only if it
successfully obtains a service ticket from the ccache or the KDC and
then determines that it has expired.)