- From: <lionel.morand@orange-ftgroup.com>
- Date: Wed, 3 Dec 2008 16:56:47 +0100
- To: <ietf-http-wg@w3.org>
Hi, 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. 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? 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? 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? Sorry for the long question and sorry if the answer is obvious. BR, Lionel
Received on Wednesday, 3 December 2008 15:57:32 UTC