AP-REP KRB5_MUTUAL_FAILED (-1765328226L) and Leap Seconds

[Dave Daugherty]

> From: Tom Yu [mailto:tlyu at 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