Concurrent access to replay cache

[Sam Hartman]

>>>>> "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.



    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
available.

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
important.

--Sam