Bug 58530

Moving to kio-http; not sure the problem is exactly there, but I imagine Zogje  
would be the right person to comment on this anyway. 

> When required digest authentication the window prompting for username and 
> password pops up several times, approx. once for each HTTP object.  
 
Hmm... this is supposed to have already been addressed, i.e. the issue of multiple 
password dialogs. I will see if I can duplicate. 
 
> This was discovered tracking an apparent bug in Squid Web Proxy digest 
> authentication. It turned that the problem was in the browser side (wrong nonce 
> count).  
 
This is a known issue in the current implementation of kio_http's (KDE's http handler) 
authentication handler code. Here is what the code that deals with nonce-count does:  
 
  // HACK: Should be fixed according to RFC 2617 section 3.2.2. 
  _data._nc = "00000001"; 
 
When we implemented support for digest authentication very few servers supported 
that particular authentication scheme and some of the more complex features were 
simply left un-implemented.   
 
I however would be a bit surprised if Squid's implementation by default supports the 
'qop' directive.  RFC 2617 section 3.2.2 explicitly states that support for 'qop' is 
provided for backwards compatibility with RFC 2069... 
 
From the server's perspective what kio_http does should look like a replay since it 
sends back the same constant nc value of 1 all the time.  We do not also properly 
support support qop = auth-int since it requires the calculation of the digest value for 
the entity-body to be trasmitted. 
 
Anyways, I will put this on my to do list but it will probably have a lower priority since 
for the reasons I stated above, namely it being a deprecated feature... 
 
Regards, 
Dawit A. 

Dawit:

You are misreading the Digest specifications.

According to RFC2617 qop SHOULD be used, but to provide compability with RFC2069
implementations it MAY optionally not be used.

Squid uses qop=auth, and this requires nc to be at least increasing for each
request. In the optimal world nc SHOULD increase by exacly one for each new
request using the same server nonce, but it MUST at least be increasing on each
new request. A client MUST NOT send two requests with the same nonce-count value
(nc=)

If a client implementation does not support qop (i.e. a minimal Digest
implementation by RFC2069) then it should not respond to the qop invitation by
the server. Such requests will however be rejected by RFC2617 servers requiring
qop such as Squid as the Digest security level when not using qop is quite poor.

Henrik: 
 
You are right!  I indeed misread the specification.  I stand corrected. Anyways, I have 
now fixed this and will test it with my squid installation. 
 
Regards, 
Dawit A. 

Dawit:
On a related note, it seems that Konqueror is first trying Basic auth, even when
Digest is present, and first on the proxy's list:

HTTP/1.0 407 Proxy Authentication Required
Server: squid/2.5.STABLE2-20030519
Mime-Version: 1.0
Date: Mon, 19 May 2003 16:11:36 GMT
Content-Type: text/html
Content-Length: 1343
Expires: Mon, 19 May 2003 16:11:36 GMT
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Digest realm="squid", nonce="OALJPkCjQwnCK7It", qop="auth",
stale=false
Proxy-Authenticate: Basic realm="squid"
X-Cache: MISS from raimundo.mecon.ar
Proxy-Connection: close

I think strongest method should be prefered (not sure what the RFC says).
Mozilla handles this Ok.

Thanks!

Hi Fernando,

That should not happen as we automatically ook for the strongest authentication
scheme. If basic authentication is being used as the result of the response you
posted, then there must be another issue. I will have a look at that too.  I
know for sure that this problem does not exist in the version I have on my local
HD which is at the moment very different than what is in the cvs.

Regards,
Dawit A.

RFC2617 4.6 Weakness Created by Multiple Authentication Schemes

   An HTTP/1.1 server may return multiple challenges with a 401
   (Authenticate) response, and each challenge may use a different
   auth-scheme. A user agent MUST choose to use the strongest auth-
   scheme it understands and request credentials from the user based
   upon that challenge.

*** Bug 57862 has been marked as a duplicate of this bug. ***

*** Bug 53997 has been marked as a duplicate of this bug. ***

All the problems mentioned in this report are now fixed in a new branch called 
kio_http_experimental.  You can check out that branch for the following two 
modules => kdelibs/kioslave/http and kdelibs/interface/kio if you are using CVS 
version. 
 
Regards, 
Dawit A.   

See also http://bugzilla.mozilla.org/show_bug.cgi?id=114451
I think there is a problem ensuring correctly increasing nonce-count if we share the same nonce across multiple io-slaves (paralel connections). The best way to ensure correct nonce-count seems to me if the nonce's where not cached in the password deamon and each slave would keep track of its own nonce and nonce-count.

Would that work, or would we, with two slaves operating in parallel, keep triggering invalid nonces in such case?

The nonce-count check is tricky to get correct. About the only way to ensure correcness is to never have more than one concurrent request per nonce.

For now Squid does not enforce increasing nonce-count due to the high risk browsers gets it incorrect or messages gets reordered in the network (i.e. hierarchy of proxies). Eventually we hope to enable this again as it's use strengthens digest auth from replay attacks.

We definitely need to store the nonce-count in the password server so that all the http io-slaves can correctly obtain the current count. Otherwise, two http io-slaves operating in parallel would indeed end up sending invalid nonce values. Which reminds me that I still need to fix the experimetal branch such that the nonce values are correctly incremented when we pre-emptively send authentication to the server.

Not FreeBSD specific, it seems. Dawit, has this been fixed for 3.2?

Subject: Re:  flaws in digest authentication implementation

On Saturday 17 January 2004 09:16, Adriaan De Groot wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=58530
> adridg@cs.kun.nl changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- OS/Version|FreeBSD                     |All
>
>
>
> ------- Additional Comments From adridg@cs.kun.nl  2004-01-17 15:16 -------
> Not FreeBSD specific, it seems. Dawit, has this been fixed for 3.2?

See comment #10. For the most part it is fixed in the experimental branch, but 
I am not sure if and when the experimental branch is going to be merged back 
in.  At this point it is only safe to say that it will not be before the 3.2 
release...

There is another flaw within the digest authentication code.
Within the response (Proxy-)Authorization, the values of the
parameters algorithm and qop are quoted. This is against the
spec. The response value of algorithm and qop are single tokens,
cf. rfc2617, "3.2.2 The Authorization Request Header"
a) the augmented BNF
b) 
====
 qop
     Indicates what "quality of protection" the client has applied to
     the message. If present, its value MUST be one of the alternatives
     the server indicated it supports in the WWW-Authenticate header.
     These values affect the computation of the request-digest. Note
     that this is a single token, not a quoted list of alternatives as
     in WWW- Authenticate.
===

The value of algorithm is a single token in any case, i.e. without quotes
(both within request and response, see rfc2617 "3.2.1 The WWW-Authenticate Response Header")
NOTE that the quotes within the
augmented BNF do NOT belong to the token nor indicate that the token
must be enclosed by quotes (see rfc2616, "2.1 Augmented BNF":
===
   "literal"
      Quotation marks surround literal text. Unless stated otherwise,
      the text is case-insensitive.
===

This flaw is present up to 3.2.5

...sorry: I meant present up to 3.5.4, i.e. the recent stable version as of today. See attached a patch for kdelibs-3.5.4/kioslave/http/http.cc
=====
--- http.cc.orig        2006-08-04 14:33:16.070320080 +0200
+++ http.cc     2006-08-04 14:33:59.170767816 +0200
@@ -5939,15 +5939,14 @@
   auth += "\", uri=\"";
   auth += m_request.url.encodedPathAndQuery(0, true);

-  auth += "\", algorithm=\"";
+  auth += "\", algorithm=";
   auth += info.algorithm;
-  auth +="\"";

   if ( !info.qop.isEmpty() )
   {
-    auth += ", qop=\"";
+    auth += ", qop=";
     auth += info.qop;
-    auth += "\", cnonce=\"";
+    auth += ", cnonce=\"";
     auth += info.cnonce;
     auth += "\", nc=";
     auth += info.nc;

the quoting flaw still is present in 3.5.7.
*sigh*

the flaw is present up to 3.93.0.

Unfixed. Still present in kdelibs-3.96.0. Please fix it.

Unfixed. Still present in kdelibs-3.97.0. Please fix it.

I implemented a digest authentication service that works fine with Opera and Firefox, but always get replay attacked by Konqueror since the nc never increase. Konqueror can still authenticate, but each request has to be repeated, i.e. 1st request denied due to replay attack -> server sends a new nonce with stale=true -> 2nd request OK. 

By the way, Ingo, I think you have misread the spec. Both algorithm and qop MUST[1] be quoted:

algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
qop-options       = "qop" "=" <"> 1#qop-value <">

[1] http://www.ietf.org/rfc/rfc2119.txt :P

@Sok Ann Yap. Nope. You misread it. Sorry, dude.

cf.
a) http://www.ietf.org/rfc/rfc2617.txt (1.1 Reliance on the HTTP/1.1 Spec)
---
This specification is a companion to the HTTP/1.1 specification [2].
It uses the augmented BNF section 2.1 of that document, and relies on
both the non-terminals defined in that document and other aspects of
the HTTP/1.1 specification.
---

b) http://www.ietf.org/rfc/rfc2616.txt (2.1 Augmented BNF)
---
  "literal"
  Quotation marks surround literal text. Unless stated otherwise,
  the text is case-insensitive.
---
The quotes are NOT part of the literal text.

As for "qop" this is clear from the spec, too (see above)
http://www.ietf.org/rfc/rfc2617.txt (3.2.2)
---
message-qop      = "qop" "=" qop-value
[...]
Note that this is a single token, not a quoted list of alternatives as
in WWW- Authenticate.
---

Ingo is right here. Quoted strings in the BNF syntax is string literals with the value being the string between the quotes. The quotes is not part of the protocol.

Quotes when present in the protocol is represented as <"> in the BNF syntax, as can be seen in the definitions of domain (RFC2617) or quoted-string (RFC2616)

qop is a little confusing as it uses different syntax for requests and responses. In requests it's a single vaule and not quoted (qop). In challenges (responses) it's a quoted list of possible values (qop-message)...

a little tired... meant qop-options, not qop-message. 

You guys are correct. I misread the spec indeed. Guess that makes me a perfect candidate for the IE team :)

Ingo, you may want to try creating a separate bug report for the syntax issue. The title for this bug report is too general, and that could be one of the reason why nothing get done after 5 years.

I don't have developer versions, so parts may already be fixed, but a quick look in the trunk suggests that the bugs are still there.

1) It seems that the entity-body can't be accessed. So "auth-int" should not be used at all.

2) info.qop seems to hold the value(s) specified in the challenge from the server, which can be something like "auth-int, auth". This exact string is then used in the response calculation, the request and in internal comparison. Instead, one of the qop-values must be picked:
Only one qop-value is allowed in the request (message-qop) and 'if ( info.qop == "auth-int" )' fails, if info.qop is "auth-int, auth".

3) The entity-body is appended to authString where its hash should be used:
authStr += ':'; authStr += info.entityBody;
vs. RFC 2617 - 3.2.2.3 (notice the H):
A2       = Method ":" digest-uri-value ":" H(entity-body)

(In reply to comment #27)
> I don't have developer versions, so parts may already be fixed, but a quick
> look in the trunk suggests that the bugs are still there.
> 
> 1) It seems that the entity-body can't be accessed. So "auth-int" should not be
> used at all.
> 
> 2) info.qop seems to hold the value(s) specified in the challenge from the
> server, which can be something like "auth-int, auth". This exact string is then
> used in the response calculation, the request and in internal comparison.
> Instead, one of the qop-values must be picked:
> Only one qop-value is allowed in the request (message-qop) and 'if ( info.qop
> == "auth-int" )' fails, if info.qop is "auth-int, auth".
> 
> 3) The entity-body is appended to authString where its hash should be used:
> authStr += ':'; authStr += info.entityBody;
> vs. RFC 2617 - 3.2.2.3 (notice the H):
> A2       = Method ":" digest-uri-value ":" H(entity-body)

http://websvn.kde.org/?view=revision&revision=1203598

Is this still an issue?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!