W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: I-D ACTION:draft-ietf-http-state-mgmt-03.txt, .ps

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 23 Jul 1996 18:40:05 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960724014005Z-4558@abash1.microsoft.com>
To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'lentz@annie.astro.nwu.edu'" <lentz@annie.astro.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1161
It would seem to me that you're just up the creek with no paddle. From
first principles, if the OS you are using is "single user", there's no
way that multiple users can use it securely (even serially), and nothing
any *protocol* can do to fix it.

I'd say that you need a browser that will encrypt all of a user's
cookies under a key known only to that user, never stores them in the
clear, never leaves them in main memory in the clear for more than the
time required to send them to the server, and exits or demands the user
type a password if idle for more than a few minutes.

This approach basically uses cryptographic techniques to turn a "single
user" workstation into a serially resuable secure multiple user one (at
least as far as cookies go).  I don't think anything less will do.

All of which has nothing to do with the cookie protocol.

>From: 	Robert A. Lentz[SMTP:lentz@annie.astro.nwu.edu]
>Sent: 	Tuesday, July 23, 1996 5:44 PM
>To: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Re: I-D ACTION:draft-ietf-http-state-mgmt-03.txt, .ps
>The current cookie proposal appears insufficient to assure a secure
>environment for providing state management in an authenticated system
>where multiple users have access to the same single-user machine.
>To be specific, and provide an example, I will use the environment,
>and application, I am trying to use:
>There will be a cookie as an identifier for an authenticated session during
>which the student will conduct online course work, possibly from a public
>computer lab. What I want to guard against is the possibility of subsequent
>users of the same machine from being able to "work" as the previous student.
>Relying upon the default Max-Age behavior of not saving the cookie is
>not an option. I use Max-Age to limit the validity of a session to guard
>against a student just walking away from their computer, leaving it
>unattended (much like auto-locking screen savers or idle timeouts on
>various shells, or kerberos tickets).
>Yet I would also like for the cookie to disappear after one person's
>"use" of the client, whether this be signified by an actual quitting of
>the client program, closing the browsing window, switching user environment,
>What I would propose is another standard attribute "Single-user".
>This attribute would indicate not only that the cookie is not to be kept
>across client invocations, but also that the cookie should be discarded
>after any indication that the user has closed the session, such as closing
>the window, switching user environments, etc. (And perhaps the cookie should
>not be shared by multiple windows of the user agent unless the other windows
>are opened from the originating session?)
>thank you,
>      "The intellectual level of the schools can be no higher than the
>       intellectual level of the culture in which they float."
>                                                     -Richard Gibboney
Received on Tuesday, 23 July 1996 19:03:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC