Ticket History #5556: Incorrect consistency check of initial ticket.

> ----AS-REQ @ 11:55:06.137094 per client
>
>
> ----AS-REP @ 11:55:06.141120 per client
>
>
> The corresponding entry in the Heimdal KDC log is (sorry about line
> wrap):
>
>

> From: Jeffrey Hutzelman <jhutz@cmu.edu>
> Date: May 3, 2007 7:46:59 PM PDT
> To: "Henry B. Hotz" <hotz@jpl.nasa.gov>, Shawn M Emery
> <Shawn.Emery@Sun.COM>
> Cc: ML <security-discuss@opensolaris.org>, Jeffrey Hutzelman
> <jhutz@cmu.edu>
> Subject: Re: [Fwd: Re: [security-discuss] Heimdal 7 vs Solaris 10,
> Any Volunteers?]
>
>
>
> On Saturday, April 21, 2007 07:39:54 PM -0700 "Henry B. Hotz"
> <hotz@jpl.nasa.gov> wrote:
>
>
> 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:
>
>
>
> 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.
>
>
> 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