Concurrent access to replay cache
hartmans at MIT.EDU
Thu Apr 15 12:33:03 EDT 2004
>>>>> "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
Daniel> The Negotiate http
Daniel> authentication must be sent over SSL (in order to ensure
Daniel> integrity protection) so I believe that replay cache is
Daniel> useless in this scenario.
That doesn't follow. I think that replay detection may be useless for
negotiate, but mostly because it is sufficiently insecure that all the
attacks possible without replay cache are present even with the replay
cache. But you can certainly take an authenticator you pick up
through some other exchange and replay it over an SSL session. So
just because your protocol requires SSL does not mean that you can
avoid a replay cache.
Daniel> I also think that checking for
Daniel> replays during password verification isn't
This is true; feel free to open a bug on it. It's probably something
we can get to for 1.4.
I'm not opposed to a solution that allows you to avoid
replay cache checking for negotiate. I am opposed to krb5.conf
variables for this purpose. I don't have time to design a solution I
consider acceptable, I don't have time to implement such a solution
and I'm not sure I have time to review a design for such a solution.
If you or someone else does have time to design such a solution I will
try to review it.
But regardless of whether you come up with a solution that we
integrate, we're faced with the deployed base of Kerberos
installations. It will be a year or so from the release of Kerberos
1.4 before it starts making its way into operating systems. So it
will be a while before you can depend on any solution we adopt being
We do understand the need for the negotiate mechanism and are
interested in working with you to make it feisable to use. But we
believe supporting the current deployed base of Kerberos users is
More information about the krbdev