Network Working Group Keith Moore, ed.
Internet-Draft University of Tennessee
18 November 1998
Expires: 18 May 1999
Applicability Statement for HTTP State Management
draft-iesg-http-cookies-00.txt
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).
Abstract
The mechanisms described in "HTTP State Management Mechanism" [RFC-
XXXX] and its predecessor [RFC-2109], can be used for many different
purposes. Even though this protocol has been approved for the Internet
standards track, some current and potential uses of the protocol are not
within the scope of the standard approved by IESG. This memo identifies
specific uses of HTTP State Management protocol which are either (a)
nonstandard and thus not recommended by IETF, or (b) nonstandard,
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 widely misused to accomplish things for which it was
not designed and is not well-suited. Some of these misuses have
received a great deal of public attention because they threaten to
Moore Expires 18 May 1999 [Page 1]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
violate the privacy of web users, specifically by leaking information to
third parties about which web pages the user has visited. However,
there are other uses of HTTP State Management which are inappropriate
beyond those that threaten users privacy.
This memo therefore identifies uses of the HTTP State Management
protocol which are either outside of the scope of the standard and thus
not recommended by IETF, or which are believed to be harmful and are
therefore discouraged. Uses in the latter category should be considered
violations of the standard, even though the actual protocol
implementations may conform to the standard. This memo, along with RFC-
XXXX, is considered part of the HTTP State Management protocol
specification.
The following keywords, when spelled in upper case letters, have
specific meanings in the context of the HTTP State Management
Specification:
- The word "MUST" means that the definition is an absolute require-
ment of the specification.
- The word "MUST NOT" means that the definition is an absolute prohi-
bition of the specification.
- The word "SHOULD" means that the definition is generally a require-
ment of the specification, but there may exist valid reasons in
particular circumstances to ignore the requirement. The full
implications must be understood and carefully weighted in light of
the intent of both the protocol specification and this document,
before choosing to ignore the requirement..
- The word "SHOULD NOT" means that the definition is generally pro-
hibited by the specification, but there may exist valid reasons in
particular circumstances where the particular behavior is accept-
able or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
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.
Moore Expires 18 May 1999 [Page 2]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
It's important to realize that similar capabilities may 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.
The HTTP State Management facility thus provides only a marginal
(but still useful) increase in functionality over ordinary HTTP and
HTML. In practice, this additional functionality includes:
- 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.'')
- 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.
- The ability to implement sessions with minimal server configuration
and minimal protocol overhead, as compared to other techniques of
maintaining session state.
- 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''.
- 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:
- the user is aware that session state is being maintained and con-
sents to it,
Moore Expires 18 May 1999 [Page 3]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
- the user has the ability to terminate the session at any time,
- 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
- the session information itself does not contain information which
is sensitive to the user, and cannot be used to obtain information
which is sensitive to the user, that is not otherwise available to
an eavesdropper.
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 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. Inappropriate Uses
The following uses of HTTP State Management are deemed inappropri-
ate and a violation of the standard:
2.2.1. Leakage of Information to Third Parties
HTTP State Management MUST NOT be used to is 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.
Such usage is not within the intended purpose of the HTTP State
Management protocol. Because such practices encourage users to defeat
HTTP State Management mechanisms, they tend to reduce the effectiveness
Moore Expires 18 May 1999 [Page 4]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
of HTTP State Management, and are therefore considered detrimental to
the operation of the web.
2.2.1. Use as an Authentication Mechanism
It is generally inappropriate to use the HTTP State Management
protocol as an authentication mechanism. HTTP State 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.
This 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 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.
Moore Expires 18 May 1999 [Page 5]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
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:
- Clients MUST NOT respond to HTTP State Management requests unless
explicitly enabled by the user.
- 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.
- 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.
- Clients SHOULD provide an effective interface which allows a user
to disable future transmission of any state information to a ser-
vice, 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.
Moore Expires 18 May 1999 [Page 6]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
- Clients SHOULD provide an effective interface which allows a user
to terminate a previous user request to ignore a particular ser-
vice's requests for the client to maintain state management infor-
mation.
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.
4. Security Considerations
This entire memo is about security considerations.
5. Editor's Address
Keith Moore
104 Ayres Hall
Knoxville TN 37996
moore@cs.utk.edu
6. References
[RFC-XXXX]
David M. Kristol, Lou Montulli. 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 pub-
lished)
[RFC-2109]
David M. Kristol, Lou Montulli. HTTP State Management Mechanism.
RFC 2109, February 1997.
Moore Expires 18 May 1999 [Page 7]
HTTP Cookies A/S INTERNET-DRAFT 18 November 1998
Moore Expires 18 May 1999 [Page 8]
