idnits 2.17.1 draft-pietrak-cookie-scope-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '...ned by a cookie, it MUST be assumed to...' RFC 2119 keyword, line 174: '...ed, applications MUST assume it's valu...' RFC 2119 keyword, line 195: '... User agent MAY let users further ti...' RFC 2119 keyword, line 196: '...adius attribute, but it MUST NOT allow...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2021) is 1175 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Pietrak 3 Internet-Draft February 4, 2021 4 Intended status: Standards Track 5 Expires: August 8, 2021 7 Cookie Extention Limitting Its Availability to User Agent Components 8 draft-pietrak-cookie-scope-00 10 Abstract 12 This memo addresses cookies security by introduction of an additional 13 constraints, web application designer may impose on cookie 14 availability for localhost applications components. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 8, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. CookieRadius attribute . . . . . . . . . . . . . . . . . . . 4 65 4. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 As of current standard, HTTP state management mechanism RFC 6265 72 [refs.RFC6265], provide tools (in the form of cookie attributes) to 73 limit the dissemination of any particular cookie. Those constraints 74 are: 76 o Cookie domain 78 o Cookie expiration time 80 o HttpOnly attribute 82 o SecureOnly attribute 84 But, current standard doesn't provide means to control the scope 85 cookies are available to localhost components, like user agent 86 software. These days search engines provide host of evidence that 87 programmers continuesly look for such means. Usually, the question 88 is: "How do I limit my session cookie to just a single tab?". 90 The questions comes from evident need to move away out off user 91 session-ID (acquired after login/pass veryfication) visible in plain 92 sight as part of URL referring to the access limitted pages. Usually 93 such modyfications are evaluated under strict requirement, that 94 current functionality remains unaltered. Here the required 95 functionality usually boils down to having such session-ID not shared 96 among interface components which waren't involved in credencials 97 veryfication. Meaning, that only the tab that provided credencials 98 (login/pass) will be authorised to access those particular resources. 99 In other words: since currently every window and every tab may have a 100 diffrent URL retrieved, it should also be possible for it to have 101 different (from other tabs) session login credencials. 103 This is considered a desired (even required) feature. 105 As of now, storing such login session credencials within a Cookie 106 (which is also whidely used to hold session credencials) alters this 107 functionality, and so is not acceptable for those migrations. The 108 functionality is lost, because a cookie set in one tab of web browser 109 will be immediately available to all other tabs. 111 On the other hand, current functionality of sharing all cookies 112 between all application components is desired by other web 113 application programmers. This memo introduces cookie attribute, 114 which will maintain current cookie behavior, while allowing for 115 currently missing cookie scope limitations to be defined by web 116 application programmer. 118 2. Terminology 120 The following terms will be used in this memo: 122 user: Within a computer system the term "user" means any set of 123 components holding the same security credencials. These 124 credencials may originate (or be derived) from a physical person 125 giving them out to a login application, or they may originate from 126 kernel mainteined vault of credencials designated for system 127 components when system (unattended) application actions are due. 128 System services like ntp service, or MTA (mail transport agent) 129 are examples of the later case. 131 application: Any programatic component of a computer system. 133 window: Any input/output channel, that an application may have an 134 access to independently from other such channels. An example of 135 such channel is GUI window, which gets data (like graphics) from 136 an application, while all other windows of that same application 137 does not get disturbed by that data stream. Every HTTP 138 datastream, from open to close is considered a separate window, 139 with the exeption below, where "tabs" are defined. 141 window-tab: Any part of a window, that holds and presents (or 142 processes) one HTML document, including all objects that may be 143 retrieved separately (separate HTTP connections), but are a part 144 (functional or aestetical) of the main document. It's valid to 145 say, that a tab is whatever is necesary to present (or processe) 146 whatever server returns in response for a single user click, 147 including all the subcomponents, that HTML defines to be retrieved 148 as a result of that click. 150 tab: synonim to window-tab 152 viewport: A single window-tab currently selected (activated/focused/ 153 visible) to/by the user. 155 3. CookieRadius attribute 157 CookieRadius attribute can have only one of the following four 158 values, and system behavior for each of them is the following: 160 World: Cookie will be available to all user applications. Every web 161 browsers launched by a particular user will see that cookie. 163 Windows: Cookie will be available to all the windows of an 164 application that received that cookie. 166 Tabs: Cookie will be available to all the tabs of the same window. 167 A window, a tab that received that cookie, belongs to. 169 Viewport: Cookie will not be available to any other system 170 component, but the tab, that received it. 172 When CookieRadius is not defined by a cookie, it MUST be assumed to 173 have a value of "Windows". When CookieRadius is defined, but it's 174 value is unrecognized, applications MUST assume it's value is 175 "Viewport". 177 HttpOnly cookie attribute is completely independent and 178 implementations WILL NOT correlate values of HttpOnly attribute with 179 any value of CookieRadius attribute. 181 Cookie "domain" interferes with CookieRadius only when its value is 182 "Viewport". In that case (either explicitly set or assumed as 183 default), "domain" is set to domain of URL retrieved irrespectively 184 of setting within the cookie. Consequently availability of such 185 cookie is not only limitted to a single viewport, but also to a 186 "domain" the tab content originated from. In other words, "Viewport" 187 cookies never traverse domains. 189 One notable consequence of the above "domain" restriction is the 190 fact, that no other component (like an embeded picture from a 191 different "domain") will ever get any information of user getting 192 logged-in to any particular "main-tab-domain". This is a security 193 feature. 195 User agent MAY let users further tighten the scope of a cookie below 196 the radius declared in CookieRadius attribute, but it MUST NOT allow 197 user to expand the radius. That is particularly important for 198 "HttpOnly=false" cookies. 200 4. Security 202 The actual impact of the proposed cookie attribute can only be 203 truelly evaluated after its wide implementation and use in other then 204 here presented scenarios. The potencial to limit the leackage of 205 security data (login credencials) between application components may 206 help improve internet security. 208 5. References 210 [refs.RFC6265] 211 Barth, A., "HTTP State Management Mechanism", RFC 6265, 212 April 2011. 214 Author's Address 216 Rafal Pietrak 218 Email: cookie.rp@ztk-rp.eu