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
