Concurrent access to replay cache

[Henry B. Hotz]

On Apr 16, 2004, at 9:00 AM, krbdev-request at mit.edu wrote:

> Date: Thu, 15 Apr 2004 12:33:03 -0400
> From: Sam Hartman <hartmans at MIT.EDU>
> To: Daniel Kouril <kouril at ics.muni.cz>
> Cc: krbdev at mit.edu
> Subject: Re: Concurrent access to replay cache
> Message-ID: <tslekqpnqv4.fsf at konishi-polis.mit.edu>
> In-Reply-To: <20040415144644.GA26460 at odorn.ics.muni.cz> (Daniel 
> Kouril's
>  message of "Thu, 15 Apr 2004 16:46:44 +0200")
> References: <20040415082124.GA1844 at odorn.ics.muni.cz>
> 	<8765c1tldk.fsf at luminous.mit.edu>
> 	<20040415144644.GA26460 at odorn.ics.muni.cz>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 1
>
>>>>>> "Daniel" == Daniel Kouril <kouril at ics.muni.cz> writes:
>
>     Daniel> Would it be possible to add a configuration option to
>     Daniel> krb5.conf specifying whether or not to use the replay
>     Daniel> cache checking? I have also problems with Microsoft IE
>     Daniel> browser using the Negotiate authentication method (which
>     Daniel> sends gss-api tokens in the HTTP headers) because of
>     Daniel> incompatibilities in processing information for replay
>     Daniel> detection. So some reasonable way of disabling the replay
>     Daniel> cache use would be worthful.
>
> We do not plan to make another release of Kerberos 1.3 at this time.
> This is not a reasonable option for krb5.conf even if we were planning
> to make another release because it is application specific, not
> global.  Your application should not require me to modify my
> krb5.conf.

Shouldn't this be an option for the kdc, not the client anyway?  It's 
already a build-time option IIRC.