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

On Wed, Dec 3, 2008 at 4:56 PM,  <lionel.morand@orange-ftgroup.com> wrote:
>
> 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.

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

> 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?

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)?

> 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?

That would be "c" (by my understanding)

> 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?

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

Received on Thursday, 11 December 2008 17:59:36 UTC