Re: Security considerations from RE-AUTHENTICATION-REQUESTED

There is another problem with the re-write ... I'll comment below ...

On Mon, 16 Feb 1998, Jim Gettys wrote:

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

Beginning with "Circumstances", the wording of this sentence doesn't fit
semantically in the HTTP specification as it is justification for
the further extensions and not worded as a security concern. Perhaps
try:
           Circumstances under which credential caching can interfere
           with the application's security model 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
> 
>