Bug 165432 - 'Request is a replay' error at SVN operations
Summary: 'Request is a replay' error at SVN operations
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mod_auth_kerb   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-09 09:55 UTC by Enrico Scholz
Modified: 2008-02-28 10:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-28 10:00:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Quick'n dirty hack with sleep and retry-as-long-we-get-errors loop (871 bytes, patch)
2005-08-10 12:14 UTC, Enrico Scholz
no flags Details | Diff

Description Enrico Scholz 2005-08-09 09:55:54 UTC
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>

Comment 1 Joe Orton 2005-08-09 10:03:45 UTC
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.

Comment 2 Enrico Scholz 2005-08-09 10:14:58 UTC
(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.

Comment 3 Joe Orton 2005-08-09 10:27:30 UTC
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.

Comment 4 Enrico Scholz 2005-08-10 12:14:07 UTC
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.

Comment 5 Christian Iseli 2007-01-22 11:09:42 UTC
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.

Comment 6 petrosyan 2008-02-28 10:00:37 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.