Bug 981477 - [RFE] Negative Caching for GSSAPI
[RFE] Negative Caching for GSSAPI
Status: NEW
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Robbie Harwood
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-04 17:37 EDT by David Woodhouse
Modified: 2017-10-09 13:37 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 21:49:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 890908 None None None Never

  None (edit)
Description David Woodhouse 2013-07-04 17:37:50 EDT
It stops even redrawing itself and I can't even switch to any other tabs or interact with it in any way even to cancel the connection, while Kerberos authentication is being attempted. Is it calling the GSSAPI functions from its main thread?

This can take a *very* long time, in a large Active Directory forest with a large number of servers.

The problem is exacerbated by the fact that it seems to try, and fail, over and over and over again to obtain a ticket for the same server when loading lots of images etc.,

So the result is that I can sniff the traffic on the VPN and see the *same* DNS SRV request for _kerberos._udp.$domain, and then the A and AAAA lookups for each of the *dozens* of servers listed in that SRV record. Over and over and over again, before firefox starts talking to me again.

This makes firefox with Kerberos fairly much unusable unless we also use the the samba-winbind-krb5-locator and a local caching nameserver to try to speed things up — and even then it's barely tolerable.
Comment 1 David Woodhouse 2013-07-08 09:07:31 EDT
We have an internal host which has broken reverse DNS, so Kerberos fails thus:

$ time kvno -S http servicedesk.intel.com
kvno: Server not found in Kerberos database while getting credentials for http/asktech.cps.intel.com@

This failure takes up to five seconds, although it's usually only about a third of a second.

I ran firefox with a breakpoint on gss_init_sec_context(), and pointed it at this web site. It loads, eventually, but only by invoking /usr/bin/ntlm_auth to authenticate with NTLM.

On the way *there*, however, it invokes gss_init_sec_context(), for the *same* SPN, 140 times in quick succession. Where the word "quick" is probably used ill-advisedly.

It even continues to call gss_init_sec_context() *after* it's already fallen back to NTLM and is talking to /usr/bin/ntlm_auth.


Perhaps if it were to only try once, it wouldn't matter so much that it's doing all this from its main thread and is failing even to redraw itself in the meantime.
Comment 2 David Woodhouse 2013-07-08 11:24:51 EDT
Some of this is definitely a firefox bug (doing blocking network stuff from main thread). However, the majority of the problem is probably best mitigated in the GSSAPI library with some kind of negative caching. Assigning to krb5 accordingly.

(I also have a live-http-headers trace here where in about 24 of 120 cases, gss_init_sec_context() returns *success* and firefox does send a large Authentication: Negotiate YIINrgYGKwYBBQUCoIINojCCDZ6gCjAIBg... header to the server. I have no idea what's going on there; what would it be sending?)
Comment 3 Nalin Dahyabhai 2013-07-08 11:33:00 EDT
(In reply to David Woodhouse from comment #2)
> (I also have a live-http-headers trace here where in about 24 of 120 cases,
> gss_init_sec_context() returns *success* and firefox does send a large
> Authentication: Negotiate YIINrgYGKwYBBQUCoIINojCCDZ6gCjAIBg... header to
> the server. I have no idea what's going on there; what would it be sending?)

The browser's apparently sending an initiator token to the server - do you have a complete one we can decode and examine?
Comment 4 Aleksandar Kostadinov 2013-09-06 02:32:35 EDT
FYI since recent FF versions it does not hang completely for me (at least FF22 was good, not sure about FF18+). kerberos auth is much slower than basic auth but that affects only particular tab. Not sure why some users report that it still hangs the whole browser. It might depend on some configuration option as well.
Comment 5 Aleksandar Kostadinov 2014-09-12 10:37:32 EDT
btw I think that slowdown might be related to generic FF auth code. When a site requires basic auth, I can't use other tabs until I enter credentials. Which is sub-optimal IMO. Maybe there's some global block that's triggered while kerberos auth is taking place.
Comment 6 Fedora Admin XMLRPC Client 2014-10-06 12:37:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora End Of Life 2015-01-09 13:40:32 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 8 Fedora End Of Life 2015-02-17 10:51:36 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 9 Fedora Admin XMLRPC Client 2015-09-01 17:35:37 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Robbie Harwood 2015-09-09 18:27:01 EDT
This really sounds to me like firefox is calling GSSAPI incorrectly.  One does not simply call gss_init_sec_context() one hundred times and change.  Unless you have a good argument why this is a krb5 bug, it sounds to me like firefox is doing their auth in a blocking fashion (which they shouldn't) and this should be reassigned there.
Comment 11 David Woodhouse 2015-09-10 05:28:27 EDT
Yes, Firefox sucks. See comment #2 for the reason this was assigned to krb5:

(In reply to David Woodhouse from comment #2)
> Some of this is definitely a firefox bug (doing blocking network stuff from
> main thread). However, the majority of the problem is probably best
> mitigated in the GSSAPI library with some kind of negative caching.
> Assigning to krb5 accordingly.

See also the discussion at
http://krbdev.mit.narkive.com/wNu53vy3/negative-caching-of-unknown-principals
Comment 12 Martin Stransky 2015-09-10 05:28:43 EDT
Please be more specific, what do you mean with incorrect GSSAPI calling? Where is the problem exactly? I'm not a kerberos expert so we need to good instructions how to fix that.
Comment 13 David Woodhouse 2015-09-10 05:59:57 EDT
The other reason is that Firefox is basically unmaintained. Note the upstream bug, untouched for over two years. Chrome's auth code is almost as bad — there have been patches outstanding to fix its lack of NTLM single-sign-on for even *more* years, with little sign of progress.

So fixing this with a negative cache in krb5 is *extremely* attractive.
Comment 14 David Woodhouse 2015-09-10 06:11:07 EDT
(In reply to Martin Stransky from comment #12)
> Please be more specific, what do you mean with incorrect GSSAPI calling?
> Where is the problem exactly? I'm not a kerberos expert so we need to good
> instructions how to fix that.

Firstly: Do not call it from your main thread. It does blocking network operations which may take *seconds*. And your UI is entirely unresponsive during that time. That one is purely a Firefox issue.

The second issue is that we could really do with some negative caching. If a given SPN doesn't exist, and GSSAPI fails and we fall back to NTLM auth, then *somebody* ought to remember that rather than just trying again and getting that same multi-second delay over and over again for every HTTP request we make (GSSAPI auth is per-request, isn't it? Not per-connection like NTLM auth IIRC). 

I actually think the negative caching lives in krb5 *not* all the applications that use it. Partly so it can be implemented just once and the cache can be shared, and also because I can't quite see *how* an application would sanely implement it in the case where it *does* want to use GSSAPI, but krb5 fails and we fall back to GSS-NTLMSSP (within SPNEGO), *not* completely abandon SPNEGO and fall back to something different like 'WWW-Authenticate: NTLM'. In that case we'd be asking the application to notice that it ended up falling back to GSS-NTLMSSP last time, and deliberately exclude krb5 from the permitted mechanisms for GSSAPI on subsequent attempts to the same host. Please no! The negative cache lives in krb5, surely!
Comment 15 Simo Sorce 2015-10-22 13:43:14 EDT
The negative caching should also be done in Firefox IMO, I do not think the library should get into that business.
Comment 16 David Woodhouse 2015-10-22 16:56:57 EDT
When Firefox does SPNEGO, and krb5 fails and GSSAPI falls back to NTLMSSP... how how would you recommend that Firefox determine that, and make it use NTLMSSP only next time?

Doing the negative caching at the krb5 level as discussed at  krbdev.mit.narkive.com/wNu53vy3/negative-caching-of-unknown-principals seems much better to me.
Comment 17 Simo Sorce 2015-10-23 18:56:29 EDT
When the context is established firefox can query it to find out what mechanism it used, and simply store that information. Next time it tries to authenticate the same URI it will set the allowed nergotiation mechanism only to NTLMSSP.

HTH.
Comment 18 Fedora End Of Life 2015-11-04 05:02:58 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2015-12-01 21:49:15 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.