500323 - please add config for reusable negotiated creds

Status: UNCONFIRMED

(Core :: Networking: HTTP, enhancement, P5)

Description

[Zac Hansen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: 

Not including making this a config option, this is a one-token change:

I would like 

*flags = CONNECTION_BASED | IDENTITY_IGNORED; 

to be able to be config'd to be

*flags = CONNECTION_BASED | IDENTITY_IGNORED | REUSABLE_CREDENTIALS; 

in mozilla/extensions/auth/nsHttpNegotiateAuth.cpp

Right now, the browser gets a new key for EVERY request and requires two round 
trips for each request.  By setting it to be reusable, the browser will do 2 round trips for the first request, but then send the credentials in subsequent requests.  When the credentials do expire, the browser will try with the old ones, be rejected by the server, and then it will get new credentials and try again.  This behavior is a HUGE win especially in situations with high latency.  We've checked this against apache + mod_auth_kerb and IIS.  We have an internal Tomcat/Jetty filter that this also works with.

Reproducible: Always

Steps to Reproduce:
1. Go to a kerberized site
2. Go to the same site and you'll get another 2 round trip
3. DO it again.. 2 more round trips
Actual Results:  
every request requires 2 round trips.  The first without creds, the second with.

Expected Results:  
go to a site and get two round trips.  Go again "soon" and only get one round trip.  Eventually it will have an expired cred and it will fail and be re-retrieved.

all the behavior is there except for adding a single flag.  You add the one flag and *poof* it magically works just like it should.

Comment 1

[Jason Duell]

Do we have anyone who knows Kerberos well enough to judge if this is a safe
optimization?   I'm also unclear on what our testing strategy would be here.  
I'll ask biesi to see if he knows more about this.

If this change works as advertised, is there any reason not to have it on all
the time (i.e. hard-code the flag, instead of making it a config option)?

Comment 2

[Zac Hansen]

it is possible to write something that assumes an expired ticket is a FAILURE and will not present the www-authenticate: negotiate option after receiving a failed request.  

Java servers require you to write your own auth handlers (there is no standard kerb auth setup for tomcat/jetty/whatever) that I could find and the one we wrote in-house would need to be updated to make this work.

Perhaps it could be default to the current behavior at first and then if people like it turn it on as the default?

This stuff is so implementation specific that it's tough to tell if it would do the right thing all the time, but saving half (amortized) the round trips is HUGE.

I know it's not a "strategy", but I can give any info or test any changes (though the change is exceedingly simple) about our setup.

Comment 3

[Zac Hansen]

I know it's simple, but can I submit a patch for this?  Would it help the process along?

Comment 4

[Christopher Nebergall]

>>Actual Results:  
>>every request requires 2 round trips.  The first without creds, the second
>>with.

The rfc put out my MS (http://tools.ietf.org/html/rfc4559) suggests Negotiate should be per connection not per request, maybe mod_auth_kerb doesn't implement that? That would also speed things up.

kerberos gssapi adds a nonce based on the time each time it generates a token to send with the NEGOTIATE Header 

mod_auth_kerb accepted a patch at some point which disables MIT kerberos's replay cache. Probably because IE with its MS Kerb implementation appears to the MIT code to be sending lots of replay's.  The token will still probably be evaluated as being invalid at the max clock skew time between the client and the server which is often 5 minutes.
 
I also don't know what it will do to NTLM which MS can send instead of kerberos with Negotiate when running firefox on windows (since NTLM requires several round trips to succeed it will often appear as a failure with extra 401's in the middle).

It's up to the mozilla folks what they accept (nothing, a config item which changes the flags controllable by the user, a patch which somehow detects whether the server has a replay cache, etc) but accepting a simple patch to just change the flags to reusable doesn't sound like the right thing to do.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258