clock skew and preauth
Greg Hudson
ghudson at MIT.EDU
Tue Mar 20 22:23:01 EDT 2012
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.
More information about the Kerberos
mailing list