Fwd: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth
jaltman at secure-endpoints.com
Tue May 27 21:49:51 EDT 2008
Thanks for this. The analysis is slightly wrong but the end result
is correct. The 'authtime' value has one second accuracy. As a result
when it is used as input to krb5_set_real_time() which has microsecond
accuracy the current microseconds value from the system clock is rounded
off. The end result is an increased likelihood that there will be
krb5_set_real_time() is only called from within verify_as_reply() as is
therefore only used with input values with one second accuracy. I believe
the correct fix is to modify krb5_set_real_time() to ignore the
Henry B. Hotz wrote:
> Hope this is of some use.
> Begin forwarded message:
>> From: Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de>
>> Date: April 7, 2007 11:24:55 AM EDT
>> To: modauthkerb-help at lists.sourceforge.net
>> Subject: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth
>> I had a longstanding problem that mod_auth_kerb failed with
>> | Request is a replay
>> when doing Basic Auth and making lot of requests (e.g. SVN, webpages
>> with much images).
>> The problem was the setting of
>> | [defaults]
>> | kdc_timesync = 1
>> in /etc/krb5.conf. Turning it off seems to make things work fine.
>> Explanation: The option above is used to correct timestamps of tickets.
>> Unfortunately, MIT KRB5 (1.4 - 1.6) uses a precision of one second for
>> this calibration while the system time (which is e.g. used for
>> tickets) uses a precision of microseconds.
>> Now, the following happens:
>> 1. Client verifies KDC
>> 2. Client receives an authtime reply from the KDC
>> Time in reply might be 1175958621 seconds
>> Time at client might be 1175958621 seconds and 900000 microseconds
>> 3. Client will now use corrected times by subtracting 900000
>> from the system time
>> 4. 100 microseconds later, the client requests the ticket
>> Time at client is now 1175958621 seconds and 900100 microseconds
>> Corrected time in ticket is 1175958621 seconds and 100 microseconds
>> 5. The same steps happens in e.g. 10 other threads. Since time between
>> 2. and 4. will be nearly constant (same code will be executed), it is
>> very likely that two tickets with the same timestamp will be
>> This results into the 'Request is a replay' error.
>> Turning off the time calibration ensures that ticket time is different
>> for all threads (scheduling needs more than 1 us for task switching
>> and krb5 tries to handle this too).
>>  See lib/krb5/krb/get_in_tkt.c which makes
>> | krb5_set_real_time(context,
>> | as_reply->enc_part2->times.authtime, 0);
>> ~~~~~~~~~~~~ seconds ~~~~~~~~~~~~~~ ~us~
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> modauthkerb-help mailing list
>> modauthkerb-help at lists.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080527/a68aa0de/attachment.bin
More information about the krbdev