330702 - Authorization: header missing quotes on qop="auth"

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Matthew van Eerde]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I configured an IIS 5 server to require Digest Authentication for a particular area.

IE can connect to all of these pages fine.

Firefox connects to the FIRST page fine.  Connecting to any other page results in a server error.

Reproducible: Always

Steps to Reproduce:
1. Configure an IIS 5 server to require Digest Authentication (and ONLY digest authentication) for a particular location.

2. Connect to that location in Internet Explorer. IE will prompt for credentials.
3. Enter appropriate credentials.
4. Notice that the page loads.
5. Hit Refresh.
6. Notice that the page loads successfully.

7. Connect to that location in Firefox.  Firefox will prompt for credentials.
8. Enter appropriate credentials.
9. Notice that the page loads.
10. Hit Refresh.
11. Notice the server error: "The network request is not supported."
Actual Results:  
Server error: "the network request is not supported"

Expected Results:  
200 OK and the page loading successfully

Internet Explorer 7 is going to display a warning message whenever Basic authentication is used on a non-SSL connection.  See:
http://blogs.msdn.com/ie/archive/2006/03/15/552246.aspx

This will cause a huge push for site owners to change authentication from Basic to other means, such as Digest.

Therefore I feel severity = major.

Trace of headers available:
http://www.geocities.com/mvaneerde/digest-test.txt

I will attach as soon as the bug is created

Comment 1

[Matthew van Eerde]

Attachment: trace of headers in IE and Firefox to IIS 5 digest

This shows the digest conversation for both IE <-> IIS and Firefox <-> IIS.  Note the Firefox conversation ends in a "Server Error" but IE just has a string of "OK"s.

Comment 2

[Matthew van Eerde]

Just tested in the latest nightly - problem still occurs.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060316 Firefox/1.6a1

Comment 3

[Matthew van Eerde]

I've noticed an RFC violation in the Firefox request.... it contains
qop=auth

But RFC2617 says:
If present, [qop's value] is a *quoted string* of one or more tokens...

That is to say, qop="auth" is correct, but qop=auth is not.

Comment 4

[Matthew van Eerde]

Changing summary to update bug problem

Comment 5

[Matthew van Eerde]

Attachment: always put quotes on qop="auth"

Patch applies to /mozilla/netwerk/protocol/http/src/nsHttpDigestAuth.cpp

The current code checks to see whether the server is IIS -- if so, it adds the quotes

But according to the RFC the quotes are always mandatory

Comment 6

[Matthew van Eerde]

OK, so that's how to fix it... now here's my guess as to why it behaves the way it does.

On the first request to a page, there's a Response available in the HTTP channel:

C: GET
S: WWW-Authenticate
C: Authorization

So the Response->Server variable is queriable and the quotes are added.

On subsequent requests (for associated content, refreshes, etc.) there is no readily available Response->Server variable.  Default behavior takes place, no quotes are added, and IIS CORRECTLY rejects the request.

Comment 7

[Matthew van Eerde]

See also bug 141605 and bug 150602

Comment 8

[Matthew van Eerde]

Oops!

It helps to read the entire RFC.  The qop rules are different for server-to-client "WWW-Authenticate" headers than they are for client-to-server Authorization headers.

For server-to-client WWW-Authenticate: headers, the rules are:
      qop-options       = "qop" "=" <"> 1#qop-value <">
      qop-value         = "auth" | "auth-int" | token
That is to say, quotes are MANDATORY.

On the other hand, for client-to-server Authorization: headers, the rules are:
      message-qop      = "qop" "=" qop-value
That is to say, quotes are FORBIDDEN.

There are thus three bugs.
* one in IE, for generating the incorrect Authorization: header
* one in IIS, for accepting the incorrect Authorization: header
* another one in IIS, for refusing the correct Authorization: header.

Comment 9

[Matthew van Eerde]

According to David Wang of Microsoft, the IIS bugs were fixed in IIS 6.0.

Comment 10

[Matthew van Eerde]

I have a support request in to Microsoft for a fix for IIS 5.
Support Request Number - SRZ060321001678