Clock skew too great status code

[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.