Henry B. Hotz wrote: > Looking a little more closely, and allowing for the inequality > compares in verify_as_reply(), I think the following piece of the test: > >> || ((request->kdc_options & KDC_OPT_RENEWABLE) && >> (request->rtime != 0) && >> (as_reply->enc_part2->times.renew_till > request->rtime)) > > will fail on the following data from the snoop: > > ----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 > > Clearly there's a time offset between the two machines, and Heimdal's > doing some compensation. > > So, I got two questions: 1) am I way off base? I don't know the > MIT/Sun code that well.
They are fairly in-sync in this area. MIT's mech does not return KRB5_KDCREP_MODIFIED during your test? > 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 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. Shawn. -- > should only be adjusted backwards in the server, but I haven't thought > it all the way through. > > Offer of a snoop file showing the problem (and with a bogus user > password for easy decryption) stands. > > On Apr 10, 2007, at 11:47 AM, Henry B. Hotz wrote: > >> I have a snoop file for a case where pam_krb5 fails with a >> KRB5_KDCREP_MODIFIED error. Anyone willing to take a look at it to >> see if the problem is on the Sun or the Heimdal side? >> >> Looking at where that error gets generated in the MIT code (not >> OpenSolaris, yeah, I know) the routine verify_as_reply() looks >> likely, but it's clearly not the whole story. >> >> The only field that looks mismatched (that verify_as_reply() checks) >> is the end time: the request is to 2037, and the reply is 24h >> ahead. I don't see any other mismatched fields between the request >> and reply. I could be blind though. ;-) >> >> Oh, yes, a last nit: ticket_lifetime isn't documented in the >> krb5.conf man page. That's an MIT problem as well, and I submitted >> it to them. > > ------------------------------------------------------------------------ > 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 > > > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org >
