clock skew and preauth

[Chris Hecker]

> Yes, that should work. It may not be universally deployed, but you 
> probably don't need to care. I'm surprised it didn't.

I'm trying to debug it, and it's a 1.9.2 kdc right now, which has the ec
type as an so, and I'm wondering if I'm screwing something up.  It does
load the so according to gdb.

Also, the encrypted_challenge_main.c file does check this:

if (labs(now-ts->patimestamp) < context->clockskew) {

and gives the KRB5KRB_AP_ERR_SKEW error, which is the same check the
timestamp preauth does, so I don't see how it could work.  But, I'm
having trouble getting gdb to break there, so I'm not sure it's getting
called.

Chris



On 2012/03/20 15:26, Nico Williams wrote:
> On Tue, Mar 20, 2012 at 5:06 PM, Chris Hecker <checker at d6.com> wrote:
>> Ugh.  Okay, I guess I'll try this if it's the best thing.  I don't
>> understand why the challenge preauth type didn't work, though, since the
>> draft-ietf-krb-wg-preauth-framework seems to imply it will:
>>
>>   The
>>   word challenge is used instead of timestamp because while the
>>   timestamp is used as an initial challenge, if the KDC and client do
>>   not have synchronized time, then the KDC can provide updated time to
>>   the client to use as a challenge.
> 
> Yes, that should work.  It may not be universally deployed, but you
> probably don't need to care.  I'm surprised it didn't.
> 
>>
>> You mention using krb5_init_creds_get_error().  How do I get the
>> krb5_init_creds_context to pass to this?  I'm using
>> krb5_get_init_creds_keytab, which wraps all that stuff deeper down.  Do I
>> have to duplicate all the code in there?
> 
> krb5_init_creds_init()
> 
> Nico
> --
>