Re: REAUTHENTICATION REQUIRED

On Wed, 19 Nov 1997, Paul Leach wrote:

> Browsers should time out, and after a while, stop sending Authorization
> and/or Proxy-Authorization header. (This isn't really simply optional UI
> behavior -- it's required for security).  However, existing browsers don't.
> And, different applications have different requirements in this regard.
> Hence, it is necessary for servers to be able to say that their maximum idle
> time has passed, and that the browser should require the user to enter their
> credentials again.

Hello all,

Authorization credentials should be given a timeout at authentication
time, the same way cookies are, and UA's MUST not use stale
authentication.  Since there is currently no way to specify this behavior
in protocol at challenge-time, the proposal as I understand it is to allow
the server to arbitrarily nix authorization that it considers stale and
force the browser to challenge the user for credentials again.

While it might be useful in some applications to allow a server to behave
this way, it is also desirable for the timeout to be a property of the
auth process and for the either the UA to be instructed to "forget" or for
the server to reject credentials (or both) after they become stale.  The
user might be alerted that this will happen.  Not all servers are going to
want to maintain a list of authorization ttls, but UA's could perform a
simple timeout check with no significant performance impact. 

Timeouts could be specified in the initial challenge as follows:

WWW-Authenticate: BASIC realm=foo  timeout=30m

But this wouldn't allow for timeouts to be determined by credential as it
would be the first statement by the server in the challenge dialogue,
before the credentials were sent in reply. 

Either way, in lieu of changing the credentials, the server is at the
mercy of the UA when it assumes that the credentials have really been
retyped and not taken from cache.  

> Add:
> A user agent MUST NOT reuse the same credentials if a substantial amount of
> time has passed without any user activity -- for example, the current user
> may have left their browser, and an unauthorized one started using it. It is
> RECOMMENDED that this time not exceed one hour, and that it be configurable.

This is good, but there are perfectly reasonable situations where you
would want to do exactly the opposite.  Assume that an institution has
kiosk UA's that operate under a license to freely access otherwise
protected content.  The UA keeps its keyring on disk or in memory with
credentials and instead of prompting a user, reads the keyring and
formulates its response to a challenge.  There is never a case where these
long-lived credentials would cause a security risk, yet it would not be
fully compliant under the above language.  

In the case of a personal workstation, a locking screen saver can perform
this function much more reliably than any protocol.  But in the case of
shared stations, especially public kiosk applications where users can walk
up and enter their own credentials, there needs to be support in the
protocol and perhaps the authentication scheme for authorization timeouts. 
I just want to see the work distributable between the parties in a manner
appropriate to the application instead of being always foisted onto the
server and with mandatory timeouts.

-marc

Received on Thursday, 20 November 1997 12:20:01 UTC