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