W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Security considerations from RE-AUTHENTICATION-REQUESTED

From: David W. Morris <dwm@xpasc.com>
Date: Mon, 16 Feb 1998 12:28:53 -0800 (PST)
To: Jim Gettys <jg@pa.dec.com>
Cc: Scott Lawrence <lawrence@agranat.com>, http-wg@cuckoo.hpl.hp.com, http-wg@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980216122311.11762B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5370
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
> 
> 
Received on Monday, 16 February 1998 12:34:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC