[16826] in Kerberos_V5_Development
RE: AP-REP KRB5_MUTUAL_FAILED (-1765328226L) and Leap Seconds
daemon@ATHENA.MIT.EDU (Dave Daugherty)
Wed May 25 19:56:29 2011
From: Dave Daugherty <dave.daugherty@centrify.com>
To: Tom Yu <tlyu@mit.edu>
Date: Wed, 25 May 2011 16:56:20 -0700
Message-ID: <6E90015C52F4FA478E0E30CD3BC6479837CF3C959F@exch-07.centrify.com>
In-Reply-To: <ldvboyqcuqa.fsf@cathode-dark-space.mit.edu>
Content-Language: en-US
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
> From: Tom Yu [mailto:tlyu@MIT.EDU]
> Sent: Wednesday, May 25, 2011 2:54 PM
> Subject: Re: AP-REP KRB5_MUTUAL_FAILED (-1765328226L) and Leap Seconds
>
> This is not the first time I've heard of this problem (thanks to Love
> Hörnquist Åstrand for pointing it out before, along with a possible
> solution), but I'd like to have more information about how common it
> is.
Sorry for the redundancy.
This is the first time we have seen this problem in 7 years of customers.
I suspect we will see it more and more.
>
> > Questions:
> > Why not just save the time string and then compare it against the
> return time string to avoid this problem?
>
> Overall, this does not appear to be an easy problem to solve.
>
> The interfaces used in the mk_req/rd_rep code path deal in time_t
> values, not struct tm values or ASN.1 GeneralizedTime strings, so it
> would not be easy to save the time string. Attempting to solve this
> by using the platform's native time conversion functions runs into
> problems because there is no standard inverse to gmtime() (some
> platforms might have timegm(), a GNU extension), and changing global
> timezone state in a library isn't very friendly or thread-safe.
>
> We might try Love's approach, which involves a replacement gmtime()
> that ignores leap seconds. On a system with a "right" timezone, that
> approach won't encode the correct value of UTC time into the protocol
> messages, as the time_t values will count leap seconds while the
> replacement gmtime() will ignore them. This may not matter right now,
> as the offset is currently only 24 seconds, but it might cause
> auditing issues or confusion when interpreting log files. In the
> future, it might exceed the permissible clockskew.
>
I may have to take a crack at solving this soon. If so I will post my fix.
Sounds like you would prefer the roll-your-own gmtime. Seems reasonable to me.
Dave Daugherty
Centrify Corp
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
