Negative caching of unknown principals

[David Woodhouse]

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.

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.

-- 
dwmw2


-------------- 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/20151025/3587bd8e/attachment.bin