idnits 2.17.00 (12 Aug 2021) /tmp/idnits62998/draft-willis-sip-cookies-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 48 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sip D. Willis 3 Internet Draft dynamicSoft 4 Document: draft-willis-sip-cookies-00.txt B. Rosen 5 Category: Standards Track Marconi 6 July, 2001 8 SIP Cookies 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This document describes an extension to SIP (RFC 2543) to provide a 33 mechanism for storing state and other information in SIP comparable 34 to the HTTP state mechanisms defined in RFC 2109. This extension 35 includes a new SIP header ("Cookie:"), an option tag for feature 36 negotiation ("cookie") and IANA registration considerations for 37 registering the "cookie" extension, semantics of the value of the 38 Cookie: header, and behavioral rules for processing these headers by 39 SIP nodes supporting the "cookie" extension. This document also 40 briefly discusses possible uses of cookies, and security 41 considerations for their use. 43 2. Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 47 this document are to be interpreted as described in RFC-2119 [2]. 49 3. Introduction 50 This is a standards-track document defining an extension to SIP (RFC 51 2543) for transmission of session state information. 53 SIP was initially derived from HTTP (RFC 2616) and shares much of 54 its design rational. RFC 2109 defines a mechanism (HTTP cookies) for 55 transmitting session state information over HTTP and storing in 56 endpoints for later use by servers. This document defines a similar 57 mechanism for SIP, with similar rationale. 59 The cookie mechanism is appropriate for uses where a non-terminal 60 SIP node, (such as a proxy) needs to insert application-specific 61 information (called "state") into a session, which is transiting 62 that node. This information may be retrieved (and potentially acted 63 on) by any other node processing that message or further messages 64 within the same SIP call, provided that the processing node is 65 capable of comprehending the state information contained in the 66 cookie. Cookies may be signed and/or encrypted as appropriate for 67 applications on an application-specific basis. 69 RFC 2543 section 10 defines SIP headers. Headers are essentially 70 name-attribute string pairs that have three interesting properties 71 for consideration in representing state information. RFC 2543 72 distinguishes between "general header", which have defined broadly 73 semantic properties in requests or responses, and "entity headers", 74 which do not. It further defines a local extension policy, whereby a 75 set of nodes may treat an entity header as a "general header" 76 provided that they have agreement on its semantics. 78 Property 1, Extensibility: RFC 2543 defines a set of standard header 79 names and an IANA process for defining new option tags and 80 associated headers. Implementors are free to add private or 81 experimental headers conforming to the syntax referenced in RFC 82 2543. 84 Property 2, Repeatability: There is no uniqueness requirement for a 85 given header type within a single SIP message. That is, there may be 86 several headers of the same type in a given message. 88 Property 3, Transparency: A SIP node that does not understand a 89 particular header type is required to treat it as an "entity 90 header". In general, proxies are required to transparently copy 91 entity headers during proxy operations, and endpoints simply ignore 92 them if they do not understand that header. 94 Applications may in some cases insert transient state simply by 95 encoding it into an extension header (an entity header with a 96 locally unique name), such that an application node inserts the 97 header into a SIP message as it passes through that node. Cookies 98 differ from simple SIP extension headers in that they are more 99 persistent. Unless renewed by a terminal node, extension headers 100 exist only in the specific message into which they were inserted by 101 an application, and no current mechanism exists for providing the 102 information encoded into the header in further messages unless the 103 terminal node has application awareness for that specific header. 104 This is appropriate for many, but not all applications. Cookies 105 provide for the preservation of state across the duration of a call 106 and derivatives of that call. Rather than being copied into new 107 messages relating to a call only when there is application awareness 108 of the specific cookie (as with an extension header), cookies are 109 copied into new messages within a call or derived from a call UNLESS 110 there is specific application awareness that dictates that they not 111 be. 113 When a terminal node (SIP User Agent) receives a Cookie: header, it 114 stores the value of the cookie in an association with the call with 115 which the message containing the cookie was associated. The terminal 116 node then copies that cookie into every message it originates for 117 the duration of that call or new call derived from that call (as in 118 a redirect or transfer). 120 4. The "Cookie:" Header Syntax 122 The syntax for the Cookie: header is derived from the Set-Cookie 123 syntax in RFC 2109 125 av-pairs = av-pair *(";" av-pair) 126 av-pair = attr ["=" value] ; optional value 127 attr = token 128 value = word 129 word = token | quoted-string 130 cookie = "Cookie:" cookies 131 cookies = 1#cookie 132 cookie = NAME "=" VALUE *(";" cookie-av) 133 NAME = attr 134 VALUE = value 135 cookie-av = "Comment" "=" value 136 | "Domain" "=" value 137 | "Version" "=" 1*DIGIT 139 Informally, the Cookie header comprises the token Cookie:, followed 140 by a comma-separated list of one or more cookies. Each cookie begins 141 with a NAME=VALUE pair, followed by zero or more semi-colon- 142 separated attribute-value pairs. The specific attributes and the 143 semantics of their values are defined below. The NAME=VALUE 144 attribute-value pair must come first in each cookie. The others, if 145 present, can occur in any order. If an attribute appears more than 146 once in a cookie, the behavior is undefined. 148 NAME=VALUE 150 Required. The name of the state information ("cookie") is NAME, and 151 its value is VALUE. NAMEs that begin with $ are reserved for other 152 uses and must not be used by applications. 154 The VALUE may be opaque to the receiving node and may be anything 155 the origin server chooses to send, possibly in a server-selected 156 printable ASCII encoding. "Opaque" implies that the content is of 157 interest and relevance only to the origin server or other nodes 158 participating in the application. The content may, in fact, be 159 readable by anyone that examines the Cookie header, but may have no 160 specific meaning to them. 162 Comment=comment 164 Optional. Because cookies can contain private information about a 165 user, the Cookie attribute allows an origin server to document its 166 intended use of a cookie. The user can inspect the information to 167 decide whether to initiate or continue a session with this cookie. 169 Domain=domain 171 Optional. The Domain attribute specifies the domain for which the 172 cookie is valid (the originating domain). An explicitly specified 173 domain must always start with a dot. 175 Version=version 177 Required. The Version attribute, a decimal integer, identifies to 178 which version of the state management specification the cookie 179 conforms. For this specification, Version=1 applies. 181 5. Behavior of SIP nodes receiving a Cookie 183 In general, a SIP node processing a message containing a cookie may 184 modify or delete the cookie only if the node is participant in the 185 application using the cookie and has adequate knowledge of the 186 semantics of that specific cookie. We define such nodes as 187 "participatory", and nodes without this involvement as "non- 188 participatory". The processing of a cookie by a participatory node 189 is subject to the requirements of the application using the cookie, 190 and is therefore implementation dependent. Behavior for non- 191 participatory SIP nodes is defined separately for proxies, user 192 agents, and redirect servers. 194 Cookies are discarded when the call instantiating the cookie and all 195 calls derived from that call have terminated.. 197 5.1. Behavior of a non-participatory SIP Proxy Server receiving a 198 Cookie 200 A SIP Proxy Server receiving a message containing a cookie 201 pertaining to an application that is not relevant to this proxy 202 treats the cookie as an unknown entity header according to the rules 203 of RFC 2543. In general, this means that the cookie is copied into 204 any proxied message resulting from the incoming message. 206 5.2. Behavior of a non-participatory SIP redirect server receiving a 207 Cookie 209 A SIP redirect server receiving a message containing a cookie not 210 relevant to this redirect server must copy the cookie into any 211 response, including redirection messages (300-class SIP messages) 212 emitted as a result of the incoming message. 214 5.3 Behavior of a non-participatory User Agent receiving a Cookie 216 A SIP User Agent Server or User Agent Client receiving a message 217 containing a cookie not relevant to this UA must store the cookie 218 and include it any future messages emitted by the UA in the course 219 of this call or derived calls. Derived calls here means any calls 220 resulting from a redirection, re-invitation, referral (transfer) or 221 any similar mechanism of the call with which the cookie was 222 associated. If the received cookie differs in only the "Value" 223 parameter from a cookie previously stored for this call, the UA 224 replaces the stored cookie with the new cookie. 226 An example with UAs A and B and C and proxy P. 227 A invites B through P. 228 P attaches cookie K to the invitation and proxies it to B. 229 B stores the cookie and responds OK, including K in the response. 230 P proxies the OK to A, including K 231 A stores K. 232 A sends ACK to B, including K. 233 B sends BYE to A including K. 234 A sends OK to B including K. 236 Cookies are discarded when the call instantiating the cookie and all 237 calls derived from that call have terminated.. 239 5.4 Implementation Limits 241 Practical User Agent implementations have limits on the number and 242 size of cookies that they can store. In general, User Agents' 243 cookie support should have no fixed limits. They should strive to 244 store as many cookies as possible. Furthermore, general-use User 245 Agents should provide each of the following minimum capabilities 246 individually, although not necessarily simultaneously: 248 * at least 10 cookies 250 * at least 4096 bytes per cookie (as measured by the size of 251 the characters that comprise the cookie non-terminal in the syntax 252 description of the Cookie header) 254 * at least 2 cookies per unique host or domain name 256 User agents created for specific purposes or for limited-capacity 257 devices should provide at least 10 cookies of 4096 bytes. 259 The information in a Cookie must be retained in its entirety. If 260 for some reason there is inadequate space to store the cookie, it 261 must be discarded, not truncated. 263 Applications should use as few and as small cookies as possible, and 264 they should cope gracefully with the loss of a cookie. 266 5.4.1 Denial of Service Attacks 268 User Agents may choose to set an upper bound on the number of 269 cookies to be stored from a given host or domain name or on the size 270 of the cookie information. Otherwise a malicious node could attempt 271 to flood a User Agent with many cookies, or large cookies, on 272 successive responses, which would force out cookies the User Agent 273 had received from other servers. However, the minima specified 274 above should still be supported. 276 6. Possible Usages of Cookie: 278 Cookies can be used for many applications requiring persistence of 279 state preservation over a duration up to the lifetime of a call and 280 its derived calls. Some applications will require participation only 281 from the node originating the cookie, and others. Such uses might 282 include: 284 * State preservation in a call as proposed by the DCS "State" draft. 285 * Associating a Billing-ID with a call as proposed by DCS Billing-ID 286 Draft. 287 * Tracking the changes in the target of a call (redirections and 288 proxy operations) as proposed in "cc-redirect" draft. 289 * Network-authenticated calling or called party identification as 290 proposed by DCS Privacy draft. 291 * Media authorization tokens as proposed by DCS "Call Auth" draft. 293 7. Option Tag for Cookie and IANA Considerations 295 RFC 2543 establishes the IANA considerations for definition of a new 296 SIP option tag. This option tag is used in server features 297 negotiation (the Requires and Supports headers). 299 7.1. Name and Description of Option: 301 Option tag = "cookie" 303 Description: This SIP option indicates the cookie extension 304 mechanism as described in this document. 306 7.2. New SIP Headers: 308 This extension adds the SIP header "Cookie:". The syntax of the 309 Cookie: header is defined elsewhere in this document. 311 7.3. Change Control 313 The SIP Working Group of the IETF retains change control over the 314 cookie extension to SIP. 316 7.4. Further Description of Extension 318 This document provides the detailed description and definition of 319 the SIP cookie extension. 321 8. Security Considerations 323 The body of a SIP message may be read by any node participating in 324 the session, and in the absence of transport-layer protection, by 325 any intermediary on the IP network. Consequently, special attention 326 must be applied to preserve the integrity or confidentiality of 327 cookie names and values as appropriate to the information therein. 328 It is suggested that implementations apply encryption using public 329 or shared secret key techniques to sensitive information. 330 Furthermore, nodes cannot be trusted not to alter the value of a 331 cookie or insert falsely attributed cookies, and it may therefore be 332 necessary to include a signing mechanism such as SSA or SHA/5 to the 333 cookie. There may be further considerations for protection of 334 messages at the SIP security level. 336 Cookies in SIP, unlike cookies in HTTP, are discarded at the 337 conclusion of a session. Therefore, many of the privacy concerns of 338 HTTP cookies do not apply to SIP cookies. However, SIP cookies 339 could be used to track user activity throughout a session, which 340 some users may consider to be a privacy concern. Some of the 341 controls listed in RFC2109 may therefore be appropriate. 343 9. Open Questions 345 9.1. Can a participatory node expecting a cookie reject a message 346 which does not have the cookie or has a cookie with an inappropriate 347 value? If so, how is this indicated? 349 10. References 351 1 Handley, et. al., ôSession Initiation Protocolö, RFC 2543, 352 March 1999. 354 2 Fielding, et. al., "Hypertext Transfer Protocol -- HTTP/1.1", 355 RFC 2616, June 1999. 357 3 Kristol, D., Montulli, L., "HTTP State Management Mechanism", 358 RFC 2109, February 1997 359 11. Acknowledgments 361 12. Author's Addresses 363 Dean Willis 364 dynamicSoft 365 366 Phone: 367 Email: dwillis@dynamicsoft.com 369 Brian Rosen 370 Marconi 371 1000 Marconi Drive 372 Warrendale, PA 15096 373 USA 374 Phone: +1 724 742 6826 375 Email: brian.rosen@marconi.com 376 Full Copyright Statement 378 "Copyright (C) The Internet Society (date). All Rights Reserved. 379 This document and translations of it may be copied and furnished to 380 others, and derivative works that comment on or otherwise explain it 381 or assist in its implmentation may be prepared, copied, published 382 and distributed, in whole or in part, without restriction of any 383 kind, provided that the above copyright notice and this paragraph 384 are included on all such copies and derivative works. However, this 385 document itself may not be modified in any way, such as by removing 386 the copyright notice or references to the Internet Society or other 387 Internet organizations, except as needed for the purpose of 388 developing Internet standards in which case the procedures for 389 copyrights defined in the Internet Standards process must be 390 followed, or as required to translate it into