Negative caching of unknown principals

[Simo Sorce]

On 25/10/15 00:53, David Woodhouse wrote:
> On Sat, 2015-10-24 at 19:12 -0400, Simo Sorce wrote:
>> 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.
>
> Firefox is basically dead code. It's not receiving maintenance — even
> the trivial patch to make it look for /usr/bin/ntlm_auth for automatic
> NTLM authentication instead of looking only in the current directory
> has been languishing in bugzilla for years.
>
> That aside, I'm not sure we *care* about negative caching for NTLMSSP.
> It isn't NTLMSSP that is causing the problems — it's repeated attempts
> to obtain a krb5 ticket, over and over and over and over again.
>
> As for eliminating the initial roundtrip... I'm not even sure that's a
> valid optimisation, is it? You're basically suggesting that we cache
> the WWW-Authenticate: headers that the server gave us for one request,
> and *assume* that it'll give us the same options for a subsequent
> request?

It's a pretty good assumption for the same URL, and it is harmless.

> Even if that is an optimisation we want to make in Firefox, and even if
> we can somehow get traction and make such changes in dead code, it
> seems to be an orthogonal issue. We could do that *without* having to
> keep track of specific mechanisms used *within* Negotiate/SPNEGO
> authentication.

If you combine that with a libkrb5 negative cache perhaps.

>>> 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.
>
> OK. There are perhaps other things we could explore on the browser side
> too — for example, if a server offers 'WWW-Authenticate: NTLM' as well
> as Negotiate then *disable* GSS-NTLMSSP in SPNEGO because if we *do*
> fall back to using NTLM then we are better off with connection-based
> authentication rather than per-request.

I am not sure ehy you would disable GSS-NTLMSSP in this case, but this 
is probably not the right place to discuss NTLM specific stuff.

> But seriously, I don't hold out much hope of doing *anything* sane in
> Firefox, and the auth code in Chrome is utterly painful to change too
> (it *still* doesn't do SSO for WWW-Authenticate: NTLM, and there's been
> patches for *that* for years too).
>
> Doing the negative cache for Kerberos service tickets seems like the
> only thing that's actually tractable in a reasonable amount of time.

Understood.

Simo.


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