RE: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

[Paolo Argentieri <[e-mail]>]

Hi Mark,
Thanks. I understand that adding new features to cookies is a complex process and I welcome an alternative solutions to the use case below.
AFAIK, for all practical purposes, Secure HttpOnly cookies are the only client side secure persistent store available to web apps today.
The "__Host-" Prefix does not seem to provide what's needed.

Consider this use case:
- (A) : REST Web Service hosted in Acme.com
- (B) : Web App hosted in Globex.com, issues fetch requests to (A)
- (C) : Web App hosted in Contoso.com, issues fetch requests to (A)
- One user agent accessing both Web Apps (B) and (C)

Step 1: User navigates to (B), (B) connects to (A) and receives a Secure, HttpOnly cookie (B-A-AccessToken).
Step 2: User navigates to (C), (C) connects to (A) and receives a Secure, HttpOnly cookie (C-A-AccessToken).

In this use case, we want the user to explicitly grant (C) access to (A), and not hijack the existing (B-A-AccessToken) cookie.
The solution, that can be implemented today, is for the server (A) to keep track to what "origin", (B) or (C), the AccessToken cookie was first issued to.

The issue here is that when (C) issues fetch calls to (A) both (B-A-AccessToken) and (C-A-AccessToken) cookies are sent. E.g.

//JavaScript hosted in (C)
fetch(uriOf(A)/resource123,
            {
                credentials: "include",  //NOTE: Both (B-A-AccessToken) and (C-A-AccessToken) cookies are included but only (C-A-AccessToken), the one matching the request header Origin: (C), is considered by the server. 
                mode: "cors"
            }) .then(...

Ideally, the user agent would know to only send the (C-A-AccessToken) cookie in the first place.
My original proposal is an attempt to define a backwards compatible "Origin locked" cookie: conformant user agent would not set or send "Origin locked" cookies that don't "match" the Origin request header.

Regards,
Paolo

-----Original Message-----
From: Mark Nottingham <[e-mail]> 
Sent: Monday, September 7, 2020 12:50 AM
To: Paolo Argentieri <[e-mail]>
Cc: [e-mail]
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06



Hi Paolo,

Are you familiar with the __Host prefix?[1]

Describing what you want to do in relation to it might be more helpful.

Also, from a procedural standpoint, we have a pretty high bar for adding new features to cookies in the current work; the proposals that are current in-scope needed to gain consensus for inclusion before we started the work. So, we'd need to see some pretty strong support for a new feature, given the state of the work.

Cheers,

1. https://urldefense.com/v3/__https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olqMau0eg$ [httpwg[.]org]



> On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <[e-mail]> wrote:
> 
> Hi all, first post here.
> 
> I'd like to propose a new "__Origin-" cookie prefix with "origin locked" semantic.
> While it is possible to implement these cookies today, standardized user agent support would add a layer of optimization and security.
> 
> The cookie name begins with prefix "__Origin-" followed by the domain that served the parent page (the origin) and, optionally, a name postfix. Example:
> 
> Set-Cookie: __Origin-apps.contoso.com-accessToken=12345; Secure; HttpOnly; SameSite=None
> 
> A conformant user agent would ensure that the cookie will have been set with a "Secure" attribute and the domain following "__Origin-" matches the request Origin.
> In addition, a conformant user agent would not send an "__Origin-" cookie if the domain in the cookie name does not match the Origin, excluding port.
> 
> A server should ignore "__Origin-"  cookies whose name doesn't match the Origin request header. This combination yields cookies that are pinned to a specific origin thus well suited to roundtrip session ids or JWTs (immune to XSS session hijacking attack).
> 
> Regards,
> Paolo Argentieri
> 
> 

--
Mark Nottingham   https://urldefense.com/v3/__https://www.mnot.net/__;!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ [mnot[.]net]