Concurrent access to replay cache

[Daniel Kouril]

On Thu, Apr 15, 2004 at 09:35:03AM -0400, Sam Hartman wrote:
> However it doesn't actually work.  This is a known problem.

Any estimation when it will be solved?

> For Kerberos 1.3.x I'd recommend creating some sort of application
> level lock if possible around calls to gss_accept_sec_context and
> krb5_verify_init_creds.

I'd prefer to avoid using such a solution since that could be quite
difficult and ineffective in the apache enviroment, I'm affraid.

Would it be possible to add a configuration option to krb5.conf specifying
whether or not to use the replay cache checking? I have also problems with
Microsoft IE browser using the Negotiate authentication method (which sends
gss-api tokens in the HTTP headers) because of incompatibilities in
processing information for replay detection. So some reasonable way of
disabling the replay cache use would be worthful. The Negotiate http
authentication must be sent over SSL (in order to ensure integrity
protection) so I believe that replay cache is useless in this scenario. I
also think that checking for replays during password verification isn't
needed. Comments?

cheers,

--
Daniel