Kerberos authentication and Time Skew: does not always work

JC Ferguson jc at
Wed Sep 5 20:34:14 EDT 2007


> >> 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
> The client has to be synchronized as well OR the client has 
> to have support for computing clock skew and applying the difference.
> Otherwise the times will be off and the authentication will fail.

Agreed.  But, my observations indicate the MS-client *does* do this as
evidenced by my testing when the clock skewed client connects
-successfully- to the MS-server, who's time is in sync with the KDC).
> Build your service with a debug version of the Kerberos 
> libraries and trace through where the time skew error is 
> being returned.

email about this is coming right up.  Standby... part of a reply to
another note on this thread.

> You can modify the acceptable clock skew period with the "clockskew"
> option in krb5.conf.

Yes, well aware. But I want to live within the default 5 minutes skew
AND have skewed clients work as defined in rfc 4120.


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.

More information about the krbdev mailing list