Re: Security considerations from RE-AUTHENTICATION-REQUESTED

David W. Morris (dwm@xpasc.com)
Mon, 16 Feb 1998 12:28:53 -0800 (PST) 

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

On Mon, 16 Feb 1998, Jim Gettys wrote:

>=20
>=20
> > View: Browse=A0HTML=A0=A0=A0=A0Browse=A0Raw=A0Text
> > 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
> >=20
> > =A0 I've attempted to provide a more general discussion of the issue of
> > =A0 cached credentials, appended below.
> >=20
> > >>>>> "JG" =3D=3D Jim Gettys <jg@pa.dec.com> writes:
> >=20
> > JG> 15.6 Authentication Credentials and Idle Clients
> >=20
> > JG> Existing HTTP clients and user agents typically retain authenticati=
on
> > JG> information indefinately. HTTP/1.1. does not provide a method for a=
n origin
> > JG> server or proxy to force reauthentication. Since clients may be idl=
e for
> > JG> extended periods between use (and unauthorized users may have acces=
s to
> > JG> the user agent during these idle periods), this is a significant de=
fect
> > JG> that requires further extensions to HTTP. This is currently under s=
eparate
> > 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 scr=
een
> > JG> savers, idle time-outs, and other methods which mitigate the securi=
ty
> > JG> problems inherent in this problem.
> >=20
> > 15.6 Caching Authentication Credentials
> >=20
> > =A0 Existing HTTP clients and user agents typically retain authenticati=
on
> > =A0 information indefinately. HTTP/1.1. does not provide a method for a
> > =A0 server to direct clients to dicard these cached credentials.=A0 Thi=
s is a
> > =A0 significant defect that requires further extensions to HTTP.
> > =A0 Circumstances under which this should be possible include but are n=
ot
> > =A0 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:


> >=20
> > =A0=A0=A0 - Clients which have been idle for an extended period followi=
ng which
> > =A0=A0=A0=A0=A0 the server may wish to cause the client to reprompt the=
 user for
> > =A0=A0=A0=A0=A0 credentials.
> >=20
> > =A0=A0=A0 - Applications which include a session termination indication=
 (such as
> > =A0=A0=A0=A0=A0 a 'logout' or 'commit' button on a page) after which th=
e server side
> > =A0=A0=A0=A0=A0 of the application 'knows' that there is no further rea=
son for the
> > =A0=A0=A0=A0=A0 client to retain the credentials.
> >=20
> > =A0 This is currently under separate study.=A0 For user agents, there a=
re a
> > =A0 number of work-arounds to parts of this problem, and we enourage th=
e use
> > =A0 of password protection in screen savers, idle time-outs, and other
> > =A0 methods which mitigate the security problems inherent in this probl=
em.
> > =A0 In particular, user agents which cache credentials are encouraged t=
o
> > =A0 provide a readily accessible mechanism for discarding cached creden=
tials
> > =A0 under user control.
> >=20
> >
> 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.
> =09=09=09=09=09- Jim
>=20
>=20