Kerberos authentication and Time Skew: does not always work
JC Ferguson
jc at acopia.com
Thu Sep 6 00:18:00 EDT 2007
OK - I believe I have figured out the problem. In an ASN.1 encoding
function I wrote, I was incorrectly encoding the integer value when
processing the sign bit. This caused the susec value to exceed 999999,
sometimes by a wide margin, but not in all cases (I erroneously added an
extra 00 byte, resulting in << 8 to the real value, but not in all
cases).
I suspect what happened, in the case when the MS-Client re-tried with a
new authenticator when the value was not encoded correctly, the "time
math" caused the time in the new authenticator to exceed the 5 minute
clock skew tolerance. This explains why it worked some of the time
(when the value was encoded correctly), but not all of the time.
So, to get the MS-Client with a skewed clock to work against a server
and KDC with a sync'd clock, it is imperitive to correctly encode the
stime and susec values in the KRB-ERROR message.
I am going to test it overnight with a few 100,000 authentications to be
sure.
Thank you all for helping me have the epiphany to check the KRB_ERROR
message! It was not obvious at first until I looked real hard at the
value, the RFC, then put 2+2 together.
/jc
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu]
> On Behalf Of JC Ferguson
> Sent: Wednesday, September 05, 2007 21:29
> To: Henry B. Hotz
> Cc: krbdev at mit.edu
> Subject: RE: Kerberos authentication and Time Skew: does not
> always work
>
>
> 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, ¤ttime)))
> > > 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.
>
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
--------------------------------------------------------------------------------
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