RE: Use of the "Stale" flag in the WWW-Authenticate header

Why does it matter whether the nonce was valid? The 401 response contains a new nonce to use when retrying the request.

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of lionel.morand@orange-ftgroup.com
Sent: Thursday, December 11, 2008 7:57 AM
To: ietf-http-wg@w3.org
Subject: RE: Use of the "Stale" flag in the WWW-Authenticate header


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 Friday, 12 December 2008 21:07:21 UTC