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

Hi Peter,

I acknowledge that it is a minor issue and that the problem will occur in rare cases.
First, I agree that in any case, the nonce received in the 401 must be used by the client to create the Authorization header of the request.

My point was just to say that a 401 without the stale flag received in response to a request containing an Authorization header created with a stale nonce can also indicate that the previous authentication session was broken and the server wants to force a completly new authentication session.

After some off-line discussions, my understanding is that:

*What matters in the 401 is the nonce.

*the stale flag is an optional parameter providing further information to the client about the reason of the reception of a new 401

*About the stale flag only:
stale=true says: user/password = valid AND nonce = stale
no stale flag (or stale=false) says:  user = invalid OR password = invalid OR nonce = invalid (For instance, in crash/restart scenario, all three parameters can be totally unknown for the server)

Based on this understanding, it is why I was saying that the following sentence in the definition of the stale parameter was not totally true:

"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."

To cover all the possible cases, we should read/understand that the absence of the flag (or stale=false) indicates that at least one of (user,pass,nonce) is rejected by the server and it wants to force a re-authentication. No information is given or could be deduced, which part of the received Authorization header was invalid.

In other words, only the stale=true gives a clear indication to the client that re-prompting the user is no required in that case.

Thank you for the different answers/feedback that I received on this "minor" topic ;)

BR,

Lionel


> -----Message d'origine-----
> De : Paul Leach [mailto:paulle@windows.microsoft.com] 
> Envoyé : vendredi 12 décembre 2008 22:06
> À : MORAND Lionel RD-CORE-ISS; ietf-http-wg@w3.org
> Objet : 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 Saturday, 13 December 2008 10:13:24 UTC