Negative caching of unknown principals

[Simo Sorce]

On 24/10/15 07:52, David Woodhouse wrote:
> 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.

I am not proposing a general approach in that bug, but one specific to 
HTTP/SPNEGO in Firefox, the reason there is simple, NTLMSSP has no 
ccache, hence no place where to store negative caching. I think it 
appropriate in that case that Firefox keep the caching, mostly because 
that allows yet another optimization that the krb5 mechanism cannot 
provide, and that is providing right away the first leg of a SPNEGO 
token without the initial roundtrip that returns the 401-Negotiate error.

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

I am fine with a negative cache for krb5 ccaches, but it is a separate 
concern from Browser specific information caching (which is partly 
positive and partly negative as explained above) IMO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York