Negative caching of unknown principals

[Isaac Boukris]

Hi,

On Sun, Oct 25, 2015 at 6:53 AM, David Woodhouse <dwmw2 at infradead.org> 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?
>
> 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.
>
>> > 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.

Side note - I think the above assumption isn't correct as Negotiate
(SPNEGO) will actually behave as connection-based when the elected
underlying mechanism was NTLMSSP.
As a matter of fact, even when KRB5 is negotiated it may still be
connection-based according to server side settings (lookup
'Persistent-Auth' header).

Have a look at MS specification of the Negotiate protocol:
https://msdn.microsoft.com/en-us/library/ee393311.aspx

Regards,
Isaac B.