Kerberos authentication and Time Skew: does not always work

[Jeffrey Altman]

JC Ferguson wrote:
> When the MS-Client (clock skewed) is negotiating an SMB session with a
> MS-Server (clock is sync'ed with KDC), the first time the MS-client
> authenticates with a fresh ticket from the KDC, the MS-server returns
> TIME_SKEW.  The MS-client rapidly retries, this time with a different
> authenticator, same ticket, and the MS-server accepts the request.  
> 
> Now, when the same MS-Client (clock skewed) is negotiating an SMB
> session with the SMB server we're developing (its clock is sync'd with
> the KDC), the same exchange ensues, however, the the MIT KRB5 library
> returns TIME_SKEW in -both- cases.
> 
> I need to take a much closer look at the KRB-ERROR message I am
> constructing to return to the MS-Client to ensure it has all the parts
> the MS-Server returns.

As Danilo pointed out yesterday, take a look at the stime and susec
fields of the KRB_ERROR message.

> Mr. Altman suggested I build the krb library debug and determine where
> the TIME_SKEW error is being returned.  I have done that and the skew
> error is returned from krb5_rd_req_decoded_opt() in rd_req_dec.c:
> 
>     if (!in_clock_skew((*auth_context)->authentp->ctime)) {
>        retval = KRB5KRB_AP_ERR_SKEW;
>        goto cleanup;
>     }
> 
> the in_clock_skew() is a macro:
> 
> #define in_clock_skew(date) (labs((date)-currenttime) <
> context->clockskew)
> 
> "currenttime" is populated with the current time right before doing the
> skew check:
> 
>     if ((retval = krb5_timeofday(context, &currenttime)))
>         goto cleanup;
> 
> this is all in rd_req_dec.c
> 
> So - the $64,000 question, to me at least, is where does the MS-Client
> pluck a new ctime value from that it sends in the -second- request?
> Must be the KRB-ERROR message, no?

Danilo's recollection is that the client re-computes the ctime value by
comparing the stime value to its own current time and adjusting the
ctime by the resulting offset.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070905/f9bb627e/attachment.bin