W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: <lionel.morand@orange-ftgroup.com>
Date: Wed, 3 Dec 2008 16:56:47 +0100
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060DED2C@ftrdmel2>
To: <ietf-http-wg@w3.org>

 
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 Wednesday, 3 December 2008 15:57:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT