Negative caching of unknown principals

[Greg Hudson]

On 07/31/2014 04:52 PM, David Woodhouse wrote:
> There are certain sites on our Intranet where unless you run 'kdestroy'
> before pointing firefox at them, you end up waiting literally *minutes*
> for pages to load.

I agree that we ought to do something about this.  (We also ought to do
something about the related HTTP case where krb5 authentication is
successful, but credential delegation is enabled and we fetch a separate
TGT for every connection.)  I also agree that an in-memory negative
cache is probably the right answer.  A few notes:

OS X through 10.6 had negative cache entries represented in the ccache.
 This could be disruptive at times; you could fail to authenticate to a
principal after it was created, and not be able to do much about it
besides re-running kinit to through out your ccache.

OS X 10.7+ has an in-memory cache implemented in the krb5
gss_init_sec_context.  I don't see any evidence that the cache entries
expire, but it does use an OS X specific (or maybe Mach-specific)
notification mechanism to invalidate the negative cache whenever any
ccache changes within the kcm daemon or when the system clock changes.
That isn't portable, but expiring negative cache entries after five
seconds or so might be sufficient.

A negative cache could interfere with an administrative operation which
checks for the existence of a principal, creates it if it doesn't exist,
and then uses it.  An in-memory negative cache wouldn't affect such a
procedure if it is implemented by script, but would if the existence
test and the use of the principal are all within the same process.  I
think the real-life HTTP cases are more important than this
hypothetical, but we would want some programmatic way of disabling the
negative cache.

If we implement a negative cache in libkrb5, I would prefer to hang it
on the krb5_context than to use mutex-locked global state.  But that
wouldn't help the HTTP use case unless we also implement per-thread krb5
contexts for GSSAPI--something I've wanted to do for a while.

If we implement a negative cache in the krb5 GSS mech, then it pretty
much needs to live in global state; there isn't anything else to hang it
off of.