Skip Menu |
 

Subject: Prompter delay can cause spurious clock skew
When we make an AS request, by default we record the difference between
the system time and the reply's authtime in the context (in the
time_offset field of os_context). This offset is recorded when a ccache
is created and restored when a ccache is loaded.

If gak_fct takes a long time (because the user took a long time to enter
the password), we incorrectly compute a large negative time offset. To
fix this, we need to snapshot the system time when the reply is received,
before calling gak_fct, and use that snapshotted time after decrypting the
reply.

We can either do this by introducing a more sophisticated (perhaps
internal) API than krb5_set_real_time(), or we can just fudge the authtime
by the amount of time elapsed across the gak_fct call.
From: ghudson@mit.edu
Subject: SVN Commit

Fix spurious clock skew caused by gak_fct delay

In get_in_tkt.c, a time offset is computed between the KDC's auth_time
and the current system time after the reply is decrypted. Time may
have elapsed between these events because of a gak_fct invocation
which blocks on user input. The resulting spurious time offset can
cause subsequent TGS-REQs to fail and can also cause the end time of
the next AS request to be in the past (issue #889) in cases where the
old ccache is opened to find the default principal.

Use the system time, without offset, for the request time of an AS
request, for more predictable kinit behavior. Use this request time,
rather than the current time, when computing the clock skew after the
reply is decrypted.

https://github.com/krb5/krb5/commit/37b0e55e21926c7875b7176e24e13005920915a6
Commit By: ghudson
Revision: 25644
Changed Files:
U trunk/src/lib/krb5/krb/get_in_tkt.c
This is a very old bug, so the fix could reasonably be pulled up to any
previous release we support. Releases prior to 1.8 will have a different
code structure in get_in_tkt.c, so would require more effort to backport
the patch.