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

Hi Again,

I need someone to review/answer this question.
I'm not even sure that the question makes sense or not.
So please, any feedback is very welcome!

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, 5 December 2008 09:36:02 UTC