Re: [http-state] Origin cookies

Other than a typo near the end:

"... the non-origin cookies are returned in the Origin-Cookie header field."

I don't understand why a separate Origin-Cookie request header is needed.  It seems the Origin attribute of a cookie simply says the cookie can only be sent back to the URL it came from, while the Path/Domain/Secure attributes allow the cookie to be sent to any URL that satisfies the combo. So why add extra complexity of a new header? How does the server validate the legitimacy of the Origin-Cookie versus what it already validates for the Cookie header?

-----Original Message-----
From: Adam Barth <ietf@adambarth.com>
Sender: http-state-bounces@ietf.org
Date: Sat, 5 Mar 2011 17:46:54 
To: http-state<http-state@ietf.org>
Subject: [http-state] Origin cookies

Hi http-state,

Now that we're done with phase 1, I've updated my phase 2 proposal:

http://www.ietf.org/id/draft-abarth-cake-01.txt

There's a bunch of boilerplate (and missing sections) in that
document.  The main idea is to provide a new cookie attribute that
lets server harmonize the security policy of their cookies with the
same-origin policy.  Harmonizing the two policies has a number of
general security benefits because security vulnerabilities often arise
when there's an impedance mismatch between security policies.
Specifically, origin cookies mitigate an important security hole in
cookies by preventing active network attackers from setting cookies
that overwrite the session identifies used by HTTPS web sites, e.g. as
described in Section 8.6 of draft-ietf-httpstate-cookie.

Let me know if you have any feedback.

Thanks!
Adam

----8<----

Abstract

   This document defines the Origin attribute for cookies, which lets
   servers harmonize the security policy of their cookies with the
   widely used same-origin policy.  Origin cookies provide both
   confidentiality and integrity, unlike the Secure attribute, which
   provides only confidentiality.

3.  Overview

   Using the Origin attribute, a server can set a cookie for its origin.
   Unlike the Path, Domain, and Secure attributes, the Origin attribute
   harmonizes the security properties of the cookie with the same-origin
   policy [cite: Principles of Origin].  In particular, the Origin
   attribute provides both confidentiality and integrity from other
   origins.

   The Origin attribute superceeds the Path, Domain, and Secure
   attributes.  The server can set these attributes as well to control
   the scope of cookies in legacy user agents.  User agents that support
   origin cookies will ignore these attributes when the Origin attribute
   is present.

   Origin cookies are returned from the user agent to the server in the
   Origin-Cookie header field and not the Cookie header field because
   the Cookie header field does not provide any information about the
   source of the cookie.  When the server receives a cookie in the
   Origin-Cookie header field, the server can reason that the cookie was
   set by its own origin, and not injected by another origin.

3.1.  Examples

   The server can set an origin cookie, which is returned in the Origin-
   Cookie header field.  Origin cookies support all the same attributes
   as other kinds of cookies, except Path, Domain, and Secure, which are
   ignored.

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Origin

   == User Agent -> Server ==

   Origin-Cookie: SID=31d4d96e407aad42

   Non-origin cookies are returned in the Cookie header as usual.  If
   the user agent sends the server both origin and non-origin cookies,
   the origin cookies are returned in the Origin-Cookie header field and
   the non-origin cookies are returned in the Origin-Cookie header
   field.

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Origin
   Set-Cookie: lang=en-US; Path=/; Domain=example.com

   == User Agent -> Server ==

   Cookie: lang=en-US
   Origin-Cookie: SID=31d4d96e407aad42

---->8----
_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state