Hide Forgot
Description of problem: When doing basic-auth style authentication (using login + password instead of krb5 ticket) with mod_auth_kerb'erized SVN server, the svn operations will fail randomly because the krb5 server detects replay-attacks. E.g. apache log shows | [Tue Aug 09 11:23:15 2005] [error] [client 192.168.3.251] failed to verify krb5 credentials: Request is a replay and the kdc log | Aug 9 11:23:15 kerberos@rochester krb5kdc[17936]: TGS_REQ (3 etypes {16 1 3}) 192.168.8.84: PROCESS_TGS: authtime 0, <unknown client> for HTTP/XXXX, Request is a replay I never saw these problems with GSSAPI based auth. mod_auth_kerb seems to try to workaround the replay-cache problem and makes some assumptions regarding krb5 internals. Can RH patches on krb5 cause conflicts there? Version-Release number of selected component (if applicable): krb5-server-1.4.1-5 mod_auth_kerb-5.0-6 How reproducible: randomly Additional info: As both mod_auth_kerb and krb5 is heavily patched by RH, I do not want to make upstream bugreports. Apache was setup as | <IfModule mod_auth_kerb.c> | <Directory /> | Krb5Keytab /etc/httpd/conf/krb5.keytab | KrbAuthRealms .... | </Directory> | </IfModule> | | <Location /development> | DAV svn | SVNPath .... | | SSLRequireSSL | AuthType Kerberos | AuthGroupFile /etc/httpd/conf/default-groups | Require group .... | | <LimitExcept GET PROPFIND OPTIONS REPORT> | </LimitExcept> | </Location>
We've been able to reproduce these with unpatched mod_auth_kerb too (see bug 157328) - I think it's a fundamental problem with how the Basic auth mode works.
(the mentioned bug seems to be unrelated ;)) http://comments.gmane.org/gmane.comp.apache.mod-auth-kerb.general/614 discusses the same problem (but is a little bit out-of-context for me). They mention usage of sizeof(k5_mutex_t) which depends on used krb5-lib and compiler flags.
Sorry, bug 157238. Re: the thread you reference. I hadn't realised that hack was actually enabled, eww. But I saw the replay errors when I was testing with the RHEL4 krb5-1.3.4. My understanding was that the error is being issued by the KDC on attempts to verify the credentials several times very frequently - this seems to really be an inevitable failure.
Created attachment 117599 [details] Quick'n dirty hack with sleep and retry-as-long-we-get-errors loop Description says it; it's a dirty hack which allows non-gssapi aware SVN clients to work with my server. Right fix would be probably something like using the same ccache for the same connection/principal or even a mod_auth_kerb session. Currently it uses MEMORY: which gets destroyed at each new authentication. I am unexperienced in krb5 programming, so perhaps a better way is possible.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.