Kerberos authentication and Time Skew: does not always work

[Henry B. Hotz]

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 jpl.nasa.gov, or hbhotz at oxy.edu