- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Thu, 11 Dec 2008 18:58:50 +0100
- To: ietf-http-wg@w3.org
On Wed, Dec 3, 2008 at 4:56 PM, <lionel.morand@orange-ftgroup.com> wrote: > > I have a basic question on the use of the "Stale" in the > WWW-Authenticate header (or in the Proxy-Authenticate header). > This question was raised after cross-reading of the RFC2617 and it was > difficult to point to a specific part of the specification to answer > this question. > > The problem comes from the definition of the Stale directive: > > stale > A flag, indicating that the previous request from the client was > rejected because the nonce value was stale. If stale is TRUE > (case-insensitive), the client may wish to simply retry the request > with a new encrypted response, without reprompting the user for a > new username and password. The server should only set stale to TRUE > if it receives a request for which the nonce is invalid but with a > valid digest for that nonce (indicating that the client knows the > correct username/password). If stale is FALSE, or anything other > than TRUE, or the stale directive is not present, the username > and/or password are invalid, and new values must be obtained. > > The last sentence seems to state that a WWW-Authenticate header without > a Stale primitive indicates that there is a problem with either the > username or the password. That's my understanding, otherwise the server would have answered with Stale=TRUE (the digest is valid by the nonce used to compute it isn't). > Let's consider the following example: > > Assuming a client has received after a first successful authentication a > Authentication-Info header with the nextnonce/cnonce/nonce-count > directive to use for a future authentication response; > > Assuming the client includes preemptively the (Proxy-)Authorization > header in every request after the first authentication (the client > receiving a nextnonce/cnonce/nonce-count after each successful > authentication); > > Assuming the server has lost (e.g. after crash/restart) all information > related to pre-existing authentication sessions (last nonces, cnonce, > noce-count opaque, etc.); > > Assuming the client sends a new request after the server restart > including an (Proxy-)Auhorization header generated with authentication > information previously stored; > > What must/should/may be the behaviour of the server to authenticate the > user? What would be the behaviour of the server (without the crash/restart step above: your server's uptime is several days/months/years) if I created an Authorization "from scratch" (minting my own nonce)? > a/ not process the content of the (ProAuthorization header and send back > 401/407, with a WWW-/Proxy-Authenticate header including a new nonce but > without the Stale directive? > > b/ not process the content of the Authorization header and send back > 401/407, with a WWW-/Proxy-Authenticate header including a new nonce > with the Stale directive set to TRUE? > > c/ process the content of the Authorization header and send back > 401/407, with a WWW-/Proxy-Authenticate header including a new nonce > with the Stale directive set to TRUE or FALSE only if the authentication > failed? That would be "c" (by my understanding) > In another word: Does a 401/407 without the Stale directive in the > WWW-/Proxy-Authenticate received in response to request containing an > Authorization header ALWAYS (even if the server as no ongoing > authenication session with the client) indicate that the nonce was valid > but the username or the password was incorrect? Yes (though the nonce might have been invalid too! what matters is the username/password pair) Stale=TRUE means "username/password OK, but invalid nonce, retry with this one" (it might be a replay attack with a very old nonce, or one that you forgot after a crash:restart) Stale=FALSE means "username or password are incorrect" And if both username/password *and* the nonce are OK, then there's no reason to send a challenge ;-) -- Thomas Broyer
Received on Thursday, 11 December 2008 17:59:36 UTC