Thanks very much for the detailed analysis. I'll submit a bug report to MIT based on it.
In the mean time, I expect I still need to patch Heimdal KDC to avoid the situation. It'll be a while before any MIT fix makes it into the deployed client base. On May 3, 2007, at 7:46 PM, Jeffrey Hutzelman wrote: > On Saturday, April 21, 2007 07:39:54 PM -0700 "Henry B. Hotz" > <hotz at jpl.nasa.gov> wrote: > >> So, bottom line, you think it's more an error on the Heimdal side >> than >> the MIT/Sun side. >> >> On Apr 20, 2007, at 10:10 PM, Shawn M Emery wrote: >> >>>> 2) Is this an error that ought to be fixed on the Heimdal or the >>>> Sun/MIT side? I'm kind of thinking that start times should only >>>> be adjusted forwards, and end times >>> >>> Yes, start times can differ w/o problems, unless the REP differs >>> from the client's system time by more than clockskew. endtimes can >>> also differ as long as the REP is not greater than the REQ. But >>> the problem in this case is that the REP renew till time is greater >>> than the REQ renew till time. 4120 states that the REP renew till >>> time MAY be the minimum of: >>> >>> REQ renew life time >>> -or- >>> start time + principal's max renew life time >>> -or- >>> start time + policy's max renew life time >> >> Interestingly, there is some code in Heimdal that does (most of) of >> this, but it's commented out. >> >>> So in this case Heimdal is not using this algorithm, though it's >>> not a MUST. You should submit a bug to them to see if they will >>> fix their KDC to honor this if one hasn't already been submitted. >> >> The issue is that Heimdal is correcting the times by the 6-second >> offset >> in the client's clock (because NTP had failed on the client). >> I'm not >> disagreeing with you, but there are plausible, if possibly >> insufficient, >> reasons for the behavior. > > I think you're reading too much into this. > > The authtime of an initial ticket is set to the time the ticket was > issued, according to the KDC's clock. This is always the case; the > client does not get to request a particular value for this field, > so there is no "adjustment" going on. > > The starttime is not only not being adjusted; it is not set at > all. This is acceptable when the value that would be used is the > same as the authtime, which it is in this case. It is clear from > the spec that when the requested starttime is in the past, the > actual starttime is the current time as indicated by the AS's clock. > > The expiration time is also not being adjusted for clock skew. The > client requests an endtime in the far future, while the KDC's > policy for this principal apparently permits a maximum lifetime of > one day. So, the endtime is the starttime plus one day. No problem. > > The interesting case is renew-till. Again, the KDC is not > adjusting for the client's clock skew, though it looks like it is. > The key to what's going on here is the renewable_ok flag in the AS- > REQ. This flag indicates that if the requested endtime is larger > than the maximum the KDC is willing to use, a renewable ticket may > be issued to cover some or all of the balance. > > In this case, the requested renew-till is 2007-04-11 18:55:06, and > policy permits a renew-till no later than the actual starttime plus > one week, which is 2007-04-11 18:55:10. So ordinarily, the KDC > would use the value requested by the client, because it is smaller. > > However, the RENEWABLE_OK flag indicates that when the requested > endtime is later than permitted by policy, the KDC may issue a > renewable ticket whose renew-time is the original requested end- > time or the maximum permitted by policy, whichever is smaller. > Since the requested endtime is in the far future, the maximum > permitted renew-till of 2007-04-11 18:55:10 is smaller, so the KDC > will use that value. > > Now, there are two possible values for the renew-till field in the > issued ticket - it can be the value computed from the client's > requested renew-till (2007-04-11 18:55:06), or it can be the value > computed by the renewable_ok logic (2007-04-11 18:55:10). Heimdal > chooses the latter because it is larger. > > The effect is that it looks as though the KDC is correcting for the > client's clock skew, even though that is not actually the case (and > in fact, the KDC does not even know what the client's clock is -- > only the time at which the client wishes the ticket to start). > > > Answering a couple of your earlier questions: > > >> I'm kind of thinking that start times should only be adjusted >> forwards > > If a postdated ticket has not been requested, then the only > starttime the AS will ever use is its local time. The only > alternative is to fail the requset with KDC_ERR_CANNOT_POSTDATE, > which is what happens if the client requests a starttime too far in > the future (where "too far" is determined by the policy setting for > acceptable clock skew). If a postdated ticket is requested, then > the KDC will use the requested starttime, if the ticket is issued > at all -- policy on what starttimes are permitted for postdated > tickets can be fairly arbitrary. > >> and end times should only be adjusted backwards > > Correct; the server will not issue a ticket with an endtime later > than requested. The same generally applies to the renew-till; > however, there is an exception related to the RENEWABLE_OK > processing described above. See the text in RFC4120 section 3.1.3 > about what happens when the requested lifetime is too large, and > the text in section 5.1.4 describing the RENEWABLE_OK flag, which > clarifies that when this processing is triggered, the requested > endtime is used in determining the issued renew-till. > > > > IMHO, the Heimdal KDC is behaving correctly in this case, and the > check on the client is buggy - if renewable_ok is set, the actal > renew-till may be as large as the requested endtime or rtime, > whichever is larger. > > -- Jeff
