Re: Security considerations from RE-AUTHENTICATION-REQUESTED

> View: Browse HTML    Browse Raw Text
> From: "Scott Lawrence" <lawrence@agranat.com>
> Date: Mon, 16 Feb 1998 11:18:48 -0500
> To: jg@pa.dec.com (Jim Gettys)
> Cc: http-wg@cuckoo.hpl.hp.com
> Subject: Re: Security considerations from RE-AUTHENTICATION-REQUESTED
> 
>   I've attempted to provide a more general discussion of the issue of
>   cached credentials, appended below.
> 
> >>>>> "JG" == Jim Gettys <jg@pa.dec.com> writes:
> 
> JG> 15.6 Authentication Credentials and Idle Clients
> 
> JG> Existing HTTP clients and user agents typically retain authentication
> JG> information indefinately. HTTP/1.1. does not provide a method for an origin
> JG> server or proxy to force reauthentication. Since clients may be idle for
> JG> extended periods between use (and unauthorized users may have access to
> JG> the user agent during these idle periods), this is a significant defect
> JG> that requires further extensions to HTTP. This is currently under separate
> JG> study. For user agents, there are a number of work-arounds to parts of
> JG> this problem, and we enourage the use of password protection in screen
> JG> savers, idle time-outs, and other methods which mitigate the security
> JG> problems inherent in this problem.
> 
> 15.6 Caching Authentication Credentials
> 
>   Existing HTTP clients and user agents typically retain authentication
>   information indefinately. HTTP/1.1. does not provide a method for a
>   server to direct clients to dicard these cached credentials.  This is a
>   significant defect that requires further extensions to HTTP.
>   Circumstances under which this should be possible include but are not
>   limited to:
> 
>     - Clients which have been idle for an extended period following which
>       the server may wish to cause the client to reprompt the user for
>       credentials.
> 
>     - Applications which include a session termination indication (such as
>       a 'logout' or 'commit' button on a page) after which the server side
>       of the application 'knows' that there is no further reason for the
>       client to retain the credentials.
> 
>   This is currently under separate study.  For user agents, there are a
>   number of work-arounds to parts of this problem, and we enourage the use
>   of password protection in screen savers, idle time-outs, and other
>   methods which mitigate the security problems inherent in this problem.
>   In particular, user agents which cache credentials are encouraged to
>   provide a readily accessible mechanism for discarding cached credentials
>   under user control.
> 
>
OK, I've adopted this rewrite, with the exception of the "For user agents";
since the work arounds are often server side rather than having anything
to do with user agents.
					- Jim

Received on Monday, 16 February 1998 08:41:18 UTC