Kerberos authentication and Time Skew: does not always work

[JC Ferguson]

Not a problem.  

I may be on to something - this thread and exchange has been helpful.
Re-compiling now - I will certainly report the result later this evening
if it works.

/jc


> -----Original Message-----
> From: Henry B. Hotz [mailto:hotz at jpl.nasa.gov] 
> Sent: Wednesday, September 05, 2007 21:28
> To: JC Ferguson
> Cc: krbdev at mit.edu
> Subject: Re: Kerberos authentication and Time Skew: does not 
> always work
> 
> 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
> 
> 
> 

--------------------------------------------------------------------------------
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.