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

From: <[email-masked]>
Date: Wed, 3 Dec 2008 16:56:47 +0100

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

---

From: <[email-masked]>
Date: Fri, 5 Dec 2008 10:35:23 +0100

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 : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : mercredi 3 décembre 2008 16:57
> À : [email-masked]
> Objet : Use of the "Stale" flag in the WWW-Authenticate header
> 
> 
>  
> Hi,
> 
> 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 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.
> 
> 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?
>

---

From: <[email-masked]>
Date: Thu, 11 Dec 2008 16:56:31 +0100

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

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 11 Dec 2008 18:58:50 +0100

> username or the password.

That's my understanding, otherwise the server would have answered with
Stale=TRUE (the digest is valid by the nonce used to compute it
isn't).

> What must/should/may be the behaviour of the server to authenticate the

What would be the behaviour of the server (without the crash/restart
step above: your server's uptime is several days/months/years) if I
created an Authorization "from scratch" (minting my own nonce)?

> with the Stale directive set to TRUE or FALSE only if the authentication

That would be "c" (by my understanding)

> but the username or the password was incorrect?

Yes (though the nonce might have been invalid too! what matters is the
username/password pair)

Stale=TRUE means "username/password OK, but invalid nonce, retry with
this one" (it might be a replay attack with a very old nonce, or one
that you forgot after a crash:restart)
Stale=FALSE means "username or password are incorrect"
And if both username/password *and* the nonce are OK, then there's no
reason to send a challenge ;-)

-- 
Thomas Broyer

---

From: Paul Leach <[email-masked]>
Date: Fri, 12 Dec 2008 13:06:22 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 11, 2008 7:57 AM
To: [email-masked]
Subject: RE: Use of the "Stale" flag in the WWW-Authenticate header

Hi again,

BR,

Lionel

---

From: <[email-masked]>
Date: Sat, 13 Dec 2008 11:12:40 +0100

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

> De : Paul Leach [mailto:[email-masked]] 
> Envoyé : vendredi 12 décembre 2008 22:06
> À : MORAND Lionel RD-CORE-ISS; [email-masked]
> 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.
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> 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?
> > [email-masked] Envoyé : mercredi 3 décembre 2008 
> > 16:57 À : [email-masked] Objet : Use of the "Stale" 
> flag in the 
> > WWW-Authenticate header
> >
> >
> >
> > Hi,
> >
> and it was 
> >      if it receives a request for which the nonce is 
> invalid but with 
> > a
> > 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.
> >
> authentication 
> > a Authentication-Info header with the nextnonce/cnonce/nonce-count 
> > information related to pre-existing authentication sessions (last 
> > nonces, cnonce, noce-count opaque, etc.);
> >
> > 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?
> >
> send back 
> > with the Stale directive set to TRUE or FALSE only if the 
> > authentication failed?
> >
> > authenication session with the
> > client) indicate that the nonce was valid but the username or the 
> > password was incorrect?
> >