Negative caching of unknown principals

[David Woodhouse]

On Sat, 2014-08-02 at 08:01 -0400, Simo Sorce wrote:
> On Fri, 2014-08-01 at 16:46 -0500, Nico Williams wrote:
> > IMO a negative cache belongs in the ccache, with some TTL, and with
> > kvno(1) always (or optionally) ignoring NAKs.
> 
> I agree you want [...] all involved processes in a script to see
> negative caches.
> And perhaps add a kdestroy switch that just remove negative entries ?
> This would make it possible for admins to deal with bad negative
> entries
> during administrative tasks without having to throw away the ccache
> entirely.

Hm, I thought we had consensus that doing the negative caching in krb5
(either in memory or in the ccache, probably the latter) was the best
approach.

In https://bugzilla.redhat.com/show_bug.cgi?id=981477#c15 you now seem
to be suggesting a wildly different approach, where each application
doing SPNEGO must keep track of which underlying mechanism actually
*worked* for a given service, and then restrict future SPNEGO attempts
to use only that mechanism.

So, for example, in the example which led to that bug being filed,
Firefox would *notice* that SPNEGO ended up falling back to GSS-NTLMSSP
and would thus restrict the mechanisms used by SPNEGO for future
authentication (for how long?) to the same host.

Please correct me if I'm misunderstanding.

Can we continue that discussion here? I'm not sure I like this new
approach, but if there's a clear agreement from the krb5 side that this
is how it should be done by all applications, and a comprehensive
description of *how* applications should behave, we can potentially set
about fixing them all to do it as you envisage...

TBH I much prefer having a negative cache on the krb5 side, as
demonstrated by my hackish proof of concept. But I'll defer to the
collective expertise of this list...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20151024/d68e74a4/attachment.bin