Re: Security considerations from RE-AUTHENTICATION-REQUESTED

Jim Gettys:
>
>I've pulled Paul's proposal from Rev-02 for RE-AUTHENTICATION-REQUESTED
>per the discussion in Washington and the mailing list.  The lack
>of this facility does need discussion in the Security Considerations
>section, however.  So I had an editorial task to generate such a section.
>
>Here's my crack at drafting such a section.  Comments welcome (for a short
>while, anyway...).
>				- Jim
>
>15.6 15.6 Authentication Credentials and Idle Clients
>
>Existing HTTP clients typically retain authentication information 
>indefinately. HTTP/1.1 lacks a facility to force reauthentication of clients, 
>which may have been idle for extended periods, by an origin server or 
>a proxy. This is considered a significant defect that requires further 
>additions to HTTP, and is under separate study. There are a number of 
>work-arounds to parts of this problem, and we encourage the use of password 
>protected screen savers on idle clients to mitigate some of the resulting 
>security problems.

Hmm, I think you are using `clients' to mean `user agents' here.  A
suggested rewrite:

15.6 Authentication Credentials and Idle Users

Existing HTTP user agents typically retain user-supplied
authentication information indefinately. HTTP/1.1 lacks a facility to
force reauthentication of users, which may have been idle for extended
periods, by an origin server or a proxy. This is considered a
significant defect that requires further additions to HTTP, and is
under separate study. There are a number of work-arounds to parts of
this problem, including terminating the user agent in order to clear
all accumulated authentication credentials.  We encourage the use of
password protected screen savers on systems which run such user
agents to mitigate some of the resulting security problems.


This still does not spell out the actual problem scenario involved,
which is that a user walks away after which a malicious other user
takes control of his user agent, so I guess it can be improved still
further.

Koen.

Received on Friday, 13 February 1998 08:28:41 UTC