Kerberos authentication and Time Skew: does not always work

Henry B. Hotz hotz at
Wed Sep 5 21:27:56 EDT 2007

My apologies.  I didn't pay enough attention to the thread.  I was  
just wondering if the error that the MIT client receives might have  
been something related to a bug I hit in the Sun client.

If you and Jeffrey can decode what Microsoft does and duplicate the  
functionality that would be nice.

On Sep 5, 2007, at 5:38 PM, JC Ferguson wrote:

>>>>> Ok - but why does a clock skewed client work fine when the
>>>> service host is windows?  Also, i have noticed a similar,
>> succcessful
>>>> behavior for Netapp NAS devices.
>>>>> Thank you,
>>>>> /jc
>>>> It shouldn't matter what the service host is as long as
>> the service
>>>> host clock is synchronized with the KDC.  If the service
>> host clock
>>>> is not synchronized with the KDC, Kerberos will not work.
>>> I agree.  But, for me, it is not working.  The service host I am
>>> developing uses the MIT KRB5 1.3.6 library and it is not able to
>>> authenticate a skewed client with any sort of reliability
>> (50% success
>>> rate), even when its clock is in sycn with the KDC.  Given
>> MS Windows,
>>> in the capacity of a service host, can authenticate a skewed client
>>> with 100% success, I am wondering what I am doing wrong in my
>>> application of the MIT krb library.  Or, if there is
>>> yet-to-be-implemented code in the library to deal with time skewed
>>> clients.
>>> /jc
>> What's the actual error message it fails with?  Is it a clock
>> skew message, or something else?
> 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.
> 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?
> /jc

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list