- From: <lionel.morand@orange-ftgroup.com>
- Date: Thu, 11 Dec 2008 16:56:31 +0100
- To: <ietf-http-wg@w3.org>
Hi again, Is there no one able to answer this question or at least point to a document or any what else that could help me on this topic? I would like to know at least if the question is stupid and the answer obvious... BR, Lionel > -----Message d'origine----- > De : ietf-http-wg-request@w3.org > [mailto:ietf-http-wg-request@w3.org] De la part de > lionel.morand@orange-ftgroup.com > Envoyé : mercredi 3 décembre 2008 16:57 > À : ietf-http-wg@w3.org > Objet : Use of the "Stale" flag in the WWW-Authenticate header > > > > 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 Thursday, 11 December 2008 15:57:07 UTC