Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

marc@pele.ckm.ucsf.edu (Marc Salomon):
  > dmk@allegra.att.com:
  > |In several places we made a point to prevent a cookie from being
  > |shared across multiple domains.  For example, a client rejects a cookie
  > |if the request-host (the server just contacted) does not domain-match
  > |the Domain attribute.  (Section 4.3.2.  Also see section 8.2)  The
  > |issue was privacy, and the intent was to avoid leaking cookies away
  > |from the intended domain.
  > 
  > Default policy is for the client not to send a cookie unless there was an 
  > exact match between the cookie's and the request's domain/path pairs, so 
  > leaking is an error in any case.  If multiple domains were permitted, a 
  > client would only send a cookie if there were an exact match between the 
  > URI at hand the one of the set of domain and path pairs associated with 
  > the cookie.  Sharing would be possible only when there were multiple domains 
  > in the Set-Cookie header.  Sharing with permission is OK, but leaking is bad.

The rejection criteria that I cite apply when the client *receives* a
cookie.  It's a way to guard against man-in-the-middle attacks.  If you
allow the origin server (or an adversary) to specify that a cookie can
be sent to an arbitrary host, you open the possibility of cookie
leakage.
  > 
  > As for an application, say that we are providing a single point of access
  > for a collection of electronic journals from multiple publishers or 
  > aggregators where we have a site license with each organization.  We could 
  > issue a cookie (after authenticating locally) valid for our local domain 
  > and for cooperating domains serving up content under license.  Those sites 
  > would decode our cookie and use it in access control and logging.
  [example deleted]

You provide a reasonable example.  However, it's late in the game to
change the spec to allow for multiple domains.  The current I-D more or
less ratifies what exists in Netscape (and "compatible" :-) browsers.
What you ask for would necessarily require client changes and therefore
probably deserves a new cookie Version number.

Dave Kristol

Received on Friday, 14 June 1996 12:07:24 UTC