Network Working Group Keith Moore
Internet Draft University of Tennessee
Ned Freed
Innosoft
<draft-iesg-http-cookies-01.txt>
Use of HTTP State Management
December 1999
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights
Reserved.
Internet Draft Use of State Management December 1999
Abstract
The mechanisms described in "HTTP State Management Mechanism"
[RFC-XXXX] and its predecessor [RFC-2109] can be used for many
different purposes. However, some current and potential uses
of the protocol are controversial because they have
significant user privacy and security implications. This memo
identifies specific uses of HTTP State Management protocol
which are either (a) not recommended by the IETF, or (b)
believed to be harmful, and discouraged. This memo also
details additional privacy considerations which are not
covered by the HTTP State Management protocol specification.
1. Introduction
The HTTP State Management mechanism is both useful and
controversial. It is useful because numerous applications of
HTTP benefit from the ability to save state between HTTP
transactions, without encoding such state in URLs. It is
controversial because the mechanism has been used to
accomplish things for which it was not designed and is not
well-suited. Some of these uses have attracted a great deal
of public criticism because they threaten to violate the
privacy of web users, specifically by leaking potentially
sensitive information to third parties such as the Web sites a
user has visited. There are also other uses of HTTP State
Management which are inappropriate even though they do not
threaten user privacy.
This memo therefore identifies uses of the HTTP State
Management protocol specified in RFC-XXXX which are not
recommended by the IETF, or which are believed to be harmful
and are therefore discouraged.
This document occasionally uses terms that appear in capital
letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to
indicate particular requirements of this specification. A
discussion of the meanings of the terms "MUST", "SHOULD", and
"MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD
NOT" are logical extensions of this usage.
Expires June 2000 [Page 2]
Internet Draft Use of State Management December 1999
2. Uses of HTTP State Management
The purpose of HTTP State Management is to allow an HTTP-based
service to create stateful ``sessions'' which persist across
multiple HTTP transactions. A single session may involve
transactions with multiple server hosts. Multiple client hosts
may also be involved in a single session when the session data
for a particular user is shared between client hosts (e.g.,
via a networked file system). In other words, the ``session''
retains state between a ``user'' and a ``service'', not
between particular hosts.
It's important to realize that similar capabilities may also
be achieved using the ``bare'' HTTP protocol, and/or
dynamically-generated HTML, without the State Management
extensions. For example, state information can be transmitted
from the service to the user by embedding a session identifier
in one or more URLs which appear in HTTP redirects, a
Content-Location response header field, or dynamically
generated HTML; and the state information may be returned from
the user to the service when such URLs appear in a GET or POST
request. HTML forms can also be used to pass state information
from the service to the user and back, without the user being
aware of this happening.
However, the HTTP State Management facility does provide an
increase in functionality over ordinary HTTP and HTML. In
practice, this additional functionality includes:
(1) The ability to exchange URLs between users, of
resources accessed during stateful sessions, without
leaking the state information associated with those
sessions. (e.g. ``Here's the URL for the FooCorp web
catalog entry for those sandals that you wanted.'')
(2) The ability to maintain session state without ``cache-
busting''. That is, separating the session state from
the URL allows a web cache to maintain only a single
copy of the named resource. If the state is maintained
in session-specific URLs, the cache would likely have
to maintain several identical copies of the resource.
Expires June 2000 [Page 3]
Internet Draft Use of State Management December 1999
(3) The ability to implement sessions with minimal server
configuration and minimal protocol overhead, as
compared to other techniques of maintaining session
state.
(4) The ability to associate the user with session state
whenever a user accesses the service, regardless of
whether the user enters through a particular ``home
page'' or ``portal''.
(5) The ability to save session information in stable
storage, so that a ``session'' can be maintained across
client invocations, system reboots, and client or
system crashes.
2.1. Recommended Uses
Use of HTTP State Management is appropriate whenever it is
desirable to maintain state between a user and a service
across multiple HTTP transactions, provided that:
(1) the user is aware that session state is being
maintained and consents to it,
(2) the user has the ability to delete the state associated
with such a session at any time,
(3) the information obtained through the ability to track
the user's usage of the service is not disclosed to
other parties without the user's explicit consent, and
(4) session information itself cannot contain sensitive
information and cannot be used to obtain sensitive
information that is not otherwise available to an
eavesdropper.
This last point is important because cookies are usually sent
in the clear and hence are readily available to eavesdroppers.
An example of such a recommended use would be a ``shopping
cart'', where the existence of the shopping cart is explicitly
made known to the user, the user can explicitly ``empty'' his
or her shopping cart (either by requesting that it be emptied
or by purchasing those items) and thus cause the shared state
Expires June 2000 [Page 4]
Internet Draft Use of State Management December 1999
to be discarded, and the service asserts that it will not
disclose the user's shopping or browsing habits to third
parties without the user's consent.
Note that the HTTP State Management protocol effectively
allows a service provider to refuse to provide a service, or
provide a reduced level of service, if the user or a user's
client fails to honor a request to maintain session state.
Absent legal prohibition to the contrary, such the server MAY
refuse to provide the service, or provide a reduced level of
service, under these conditions. As a purely practical
consideration, services designed to utilize HTTP State
Management may be unable to function properly if the client
does not provide it. Such servers SHOULD gracefully handle
such conditions and explain to the user why the full level of
service is not available.
2.2. Problematic Uses
The following uses of HTTP State Management are deemed
inappropriate and contrary to this specification:
2.2.1. Leakage of Information to Third Parties
HTTP State Management MUST NOT be used to leak information
about the user or the user's browsing habits to other parties
besides the user or service, without the user's explicit
consent. Such usage is prohibited even if the user's name or
other externally-assigned identifier are not exposed to other
parties, because the state management mechanism itself
provides an identifier which can be used to compile
information about the user.
Because such practices encourage users to defeat HTTP State
Management mechanisms, they tend to reduce the effectiveness
of HTTP State Management, and are therefore considered
detrimental to the operation of the web.
2.2.2. Use as an Authentication Mechanism
It is generally inappropriate to use the HTTP State Management
protocol as an authentication mechanism. HTTP State
Expires June 2000 [Page 5]
Internet Draft Use of State Management December 1999
Management is not designed with such use in mind, and
safeguards for protection of authentication credentials are
lacking in both the protocol specification and in widely
deployed HTTP clients and servers. Most HTTP sessions are not
encrypted and ``cookies'' may therefore be exposed to passive
eavesdroppers. Furthermore, HTTP clients and servers
typically store ``cookies'' in cleartext with little or no
protection against exposure. HTTP State Management therefore
SHOULD NOT be used as an authentication mechanism to protect
information from being exposed to unauthorized parties, even
if the HTTP sessions are encrypted.
The prohibition against using HTTP State Management for
authentication includes both its use to protect information
which is provided by the service, and its use to protect
potentially sensitive information about the user which is
entrusted to the service's care. For example, it would be
inappropriate to expose a user's name, address, telephone
number, or billing information to a client which merely
presented a cookie which had been previously associated with
the user.
Similarly, HTTP State Management SHOULD NOT be used to
authenticate user requests if unauthorized requests might have
undesirable side-effects for the user, unless the user is
aware of the potential for such side-effects and explicitly
consents to such use. For example, a service which allowed a
user to order merchandise with a single ``click'', based
entirely on the user's stored ``cookies'', could inconvenience
the user by requiring her to dispute charges to her credit
card, and/or return the unwanted merchandise, in the event
that the cookies were exposed to third parties.
Some uses of HTTP State Management to identify users may be
relatively harmless, for example, if the only information
which can be thus exposed belongs to the service, and the
service will suffer little harm from the exposure of such
information.
3. User Interface Considerations for HTTP State Management
HTTP State Management has been very controversial because of
its potential to expose information about a user's browsing
habits to third parties, without the knowledge or consent of
Expires June 2000 [Page 6]
Internet Draft Use of State Management December 1999
the user. While such exposure is possible, this is not a flaw
in the protocol itself so much as the failure of HTTP client
implementations (and of some providers of HTTP-based services)
to protect users' interests.
As implied above, there are other ways to maintain session
state than using HTTP State Management, and therefore other
ways in which users' browsing habits can be tracked. Indeed,
it is difficult to imagine how the HTTP protocol or an HTTP
client could actually prevent a service from disclosing a
user's ``click trail'' to other parties if the service chose
to do so. Protection of such information from inappropriate
exposure must therefore be the responsibility of the service.
HTTP client implementations inherently cannot provide such
protection, though they can implement countermeasures which
make it more difficult for HTTP State Management to be used as
the mechanism by which such information is exposed.
It is arguable that HTTP clients should provide more
protection in general against inappropriate exposure of
tracking information, regardless of whether the exposure were
facilitated by use of HTTP State Management or by some other
means. However, issues related to other mechanisms are beyond
the scope of this memo.
3.1. Capabilities Required of an HTTP Client
A user's willingness to consent to use of HTTP State
Management is likely to vary from one service to another,
according to whether the user trusts the service to use the
information appropriately and to limit its exposure to other
parties. The user therefore SHOULD be able to control whether
his client supports a service's request to use HTTP State
Management, on a per-service basis. In particular:
(1) Clients MUST NOT respond to HTTP State Management
requests unless explicitly enabled by the user.
(2) Clients SHOULD provide an effective interface which
allows users to review, and approve or refuse, any
particular requests from a server to maintain state
information, before the client provides any state
information to the server.
Expires June 2000 [Page 7]
Internet Draft Use of State Management December 1999
(3) Clients SHOULD provide an effective interface which
allows users to instruct their clients to ignore all
requests from a particular service to maintain state
information, on a per-service basis, immediately in
response to any particular request from a server,
before the client provides any state information to the
server.
(4) Clients SHOULD provide an effective interface which
allows a user to disable future transmission of any
state information to a service, and/or discard any
saved state information for that service, even though
the user has previously approved a service's request to
maintain state information.
(5) Clients SHOULD provide an effective interface which
allows a user to terminate a previous user request to
ignore a particular service's requests for the client
to maintain state management information.
3.2. Limitations of the domain-match algorithm
The domain-match algorithm in RFC-XXXX section 2 is intended
as a heuristic to allow a client to ``guess'' whether or not
two domains are part of the same service. There are few rules
about how domain names can be used, and the structure of
domain names and how they are delegated varies from one top-
level domain to another (i.e. the client cannot tell which
part of the domain was assigned to the service). Therefore NO
string comparison algorithm (including the domain-match
algorithm) can be relied on to distinguish a domain that
belongs to a particular service, from a domain that belongs to
another party.
As stated above, each service is ultimately responsible for
ensuring that user information is not inappropriately leaked
to third parties. Leaking information to third parties via
State Management by careful selection of domain names, or by
assigning domain names to hosts maintained by third parties,
is at least as inappropriate as leaking the same information
by other means.
Expires June 2000 [Page 8]
Internet Draft Use of State Management December 1999
4. Security Considerations
This entire memo is about security considerations.
5. Authors' Addresses
Keith Moore
104 Ayres Hall
Knoxville, TN 37996
moore@cs.utk.edu
Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 81790
moore@cs.utk.edu
6. References
[RFC-1123]
Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October, 1989.
[RFC-XXXX]
Kristol, D., Montulli, L., "HTTP State Management
Mechanism", Internet-Draft <draft-ietf-http-state-man-
mec-10.txt>, work in progress. (To be replaced by the
RFC name when this memo is published.)
[RFC-2109]
Kristol, D., Montulli, L., "HTTP State Management
Mechanism", RFC 2109, February 1997.
7. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
Expires June 2000 [Page 9]
Internet Draft Use of State Management December 1999
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Expires June 2000 [Page 10]
