[krbdev.mit.edu #5556] Incorrect consistency check of initial ticket.
"Henry B. Hotz" via RT
rt-comment at krbdev.mit.edu
Thu May 10 12:26:36 EDT 2007
Like the subject says. Here are the particulars, starting with an
extract from wireshark.
> ----AS-REQ @ 11:55:06.137094 per client
>
>> from: 2007-04-04 18:55:06 (Z)
>> till: 2037-12-30 23:00:00 (Z)
>> rtime: 2007-04-11 18:55:06 (Z)
>>
>
> ----AS-REP @ 11:55:06.141120 per client
>
>> Authtime: 2007-04-04 18:55:10 (Z)
>> End time: 2007-04-05 18:55:10 (Z)
>> Renew-till: 2007-04-11 18:55:10 (Z)
>>
>
> The corresponding entry in the Heimdal KDC log is (sorry about line
> wrap):
>
>
>> 2007-04-04T11:55:10 AS-REQ rgutier at JPL.NASA.GOV from
>> IPv4:128.149.197.100 for krbtgt/JPL.NASA.GOV at JPL.NASA.GOV
>> 2007-04-04T11:55:10 Using aes128-cts-hmac-sha1-96/aes128-cts-hmac-
>> sha1-96
>> 2007-04-04T11:55:10 Requested flags: renewable_ok, renewable,
>> forwardable
>> 2007-04-04T11:55:10 AS-REQ authtime: 2007-04-04T11:55:10
>> starttime: unset endtype: 2007-04-05T11:55:10 renew till:
>> 2007-04-11T11:55:10
>> 2007-04-04T11:55:10 sending 661 bytes to IPv4:128.149.197.100
The client is 6 seconds slow and kinit (actually Solaris pam_krb5)
returns a KRB5_KDCREP_MODIFIED error. The relevant logic appears to
be common to MIT and Sun, and unchanged for a very long time.
I don't seem to have the specific snoop file for the above data. If
you want a similar one showing the same error, I can provide it.
Jeffrey Hutzelman's analysis follows.
Begin forwarded message:
> From: Jeffrey Hutzelman <jhutz at cmu.edu>
> Date: May 3, 2007 7:46:59 PM PDT
> To: "Henry B. Hotz" <hotz at jpl.nasa.gov>, Shawn M Emery
> <Shawn.Emery at Sun.COM>
> Cc: ML <security-discuss at opensolaris.org>, Jeffrey Hutzelman
> <jhutz at 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 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
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krb5-bugs
mailing list