clock skew and preauth

[Greg Hudson]

On 03/20/2012 04:59 PM, Chris Hecker wrote:
> Hmm, it looks like there's a timestamp and a challenge preauth type, but
> I'm having trouble figuring out how to get it used...

Sorry, I could have saved you some effort with a quicker response.

Encrypted challenge is similar to encrypted timestamp, but is a FAST
factor instead of a regular preauth plugin.  To use FAST, you need to
have an existing ccache (ideally derived from a strong key, like the
host keytab's key) and call krb5_get_init_creds_set_fast_ccache(), or
use the kinit -T option.

However, it won't solve your problem.  In either case, what you want is
for the KDC to use the timestamp from the initial preauth-required error
to set time offsets for the preauthenticated request, and the code
simply doesn't do that.  It's been that way for a long time, though I
couldn't tell you exactly why.  There are some minor security
implications to allowing an attacker to possibly trick the client into
sending a preauth request for a future timestamp, but it's not clear
that they are significant.

As Nico suggested, it may be possible to use the
krb5_init_creds_init/step interface to work around this using
krb5_init_creds_get_error and krb5_set_real_time(), but given what I
know about your deployment, it's probably easier to modify get_in_tkt.c
to set the offsets when a preauth-required error is received.