According to http://tools.ietf.org/html/rfc2617#section-4.9, having the server chose a nonce but not having the client chose a nonce opens up Digest Access authentication to chosen plaintext attacks. My question is two fold...
Is this a problem with SHA1? Digest access authentication uses MD5 so maybe the client nonce is intended specifically for that?
Also, how does being able to control the server chosen nonce help? The link in the RFC is dead.
The goal of the attacker is to guess the password. By observing the authentication message, the attacker already learns enough to "try" passwords at home (i.e. an "offline dictionary attack"), but that's not what RFC 2617 is talking about at that point. Rather, it concentrates on the idea of an attacker who impersonates the server, and thus feeds "server" nonces of its choosing to the client. The client responds to such a nonce by hashing the server nonce, the client nonce and the password together (I voluntarily skip the details here). The attacker may then try to exploit some internal weakness of the hash function to recompute the password from what the client sent. What the RFC 2617 tries to say is that omitting the client nonce can only makes things easier for the attacker (at least provably not harder, and heuristically easier) -- as a corollary, using a client nonce may help in protecting the client in case the hash function is flaky; a client nonce will certainly do no additional harm.
Now no exploitable weakness of MD5 is currently known, when used in Digest Access authentication as described by RFC 2617. Even though MD5 has shown considerable flakiness with regards to resistance to collision, which is another, distinct security property that a good hash function should have (and that MD5 has not). So the protection offered here by the client nonce is only hypothetical. But, as I said, it does not harm either.
That section of the RFC is making some dubious claims, and isn't written all that well. Here's what I think it should have said.
If you allow the attacker to control part of the input to a hash function, then you have to think about whether this enables chosen-plaintext attacks on the hash function. If the client didn't provide any nonce, then one might worry that a malicious server could choose its server nonce maliciously in an attempt to mount some kind of chosen-plaintext attack on the hash function.
Fortunately, current hash functions are designed to be secure against chosen-plaintext attacks, so this worry is not really a risk in practice.
On the other hand, if you want to be really cautious, I guess you could try to reduce the number of opportunities for these kinds of attacks by including a random number chosen by the client. This way, even if the server is malicious, there's still guaranteed to be part of the input to the hash function that is random, not controllable by the attacker, and not predictable by the attacker. It is not clear whether this actually provides any benefit (it is probably unnecessary), but it can't hurt.
See @Thomas's answer for more elaboration.
It is generally good engineering practice to have both endpoints contribute their own random nonce. For instance, in some situations this helps prevent certain kinds of replay attacks where one endpoint is malicious.
I don't know whether leaving out the client nonce would actually enable some sort of clever replay attack on RFC2617, but why take the risk? If there is a simple modification I can make that rules out an entire class of possible attacks, that modification looks attractive. Anything that saves me from having to think hard about subtle attacks (and possibly overlooking one, which is catastrophic) feels like a good thing.
In the case of RFC2617, including a client nonce prevents precomputation attacks (e.g., time/space tradeoff attacks, "rainbox tables", and the like) when the server is malicious. See @ixe013's answer and my comment for more details on this.
Yes, it is still a problem with SHA1. It is irrelevant of the actual hashing algorithm, apart that the attacker will need more space to store lookup tables, and maybe a little more time computing them.
The digest is a hash of the username, the password, the given nonce value, the HTTP method, and the requested URI (RFC2617). The attacker knows all of them (but the password) and thus can prepare a lookup table in advance. Such a table cannot be precomputed of the client adds it's own nonce (cnonce), unknown to the attacker beforehand.
