Kerberos authentication and Time Skew: does not always work

[JC Ferguson]

> >>> 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 information contained in this e-mail is confidential and is intended solely 
for the review of the named addressee, and in conjunction with specific Acopia 
Networks business. Any review, retransmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited. If you are unable to 
treat this information accordingly, or are not the intended recipient, please 
notify us immediately by returning the e-mail to the originator.