[38058] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Pre-auth encrypted timestamp clock skew

daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Aug 23 11:37:08 2017

To: Benjamin N Hall <bnh1@columbia.edu>, kerberos@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <32f6f6ad-da14-010f-9fd7-5aaf6ab66efe@mit.edu>
Date: Wed, 23 Aug 2017 11:36:50 -0400
MIME-Version: 1.0
In-Reply-To: <CAB8gXpL3C7dnd422sUZMboJH=Dc-zYJb8oRquFPSzkxwu2oVdg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On 08/23/2017 05:23 AM, Benjamin N Hall wrote:
> We recently started testing pre-authentication for certain principals, and
> I'm seeing an odd issue whereby kinit fails with "Clock skew too great
> while getting initial credentials", despite all three KDCs and the client
> systems' time being within one second of each other.
[...]
> The part that seems interesting to me is that the pre-auth encrypted
> timestamp appears to be off by way more than 5 minutes from the other
> timestamps.

The encrypted timestamp is unexpectedly for 1234 seconds in the future.
The only explanation I can think of is that you had a pre-existing
ccache with a recorded time offset of roughly 20 minutes.  For various
reasons I'm not sure that's the right explanation.  If you can
investigate with a debugger, I would be very interested in knowing the
actual cause.

The client code in 1.12 and later will use the timestamp sent by the KDC
in its PREAUTH_REQUIRED error (assuming kdc_timesync is set to true,
which it is by default), which would likely suppress this problem.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post