idnits 2.17.1 draft-rosenberg-sipping-consent-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 534. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 550), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (July 8, 2004) is 7231 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) -- Looks like a reference, but probably isn't: 'PRES-RULES' on line 299 == Unused Reference: '3' is defined on line 473, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-02 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 6, 2005 G. Camarillo 4 Ericsson 5 D. Willis 6 dynamicsoft 7 July 8, 2004 9 A Framework for Consent-Based Communications in the Session 10 Initiation Protocol (SIP) 11 draft-rosenberg-sipping-consent-framework-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 6, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 The Session Initiation Protocol (SIP) supports communications across 44 many media types, including real-time audio, video, text, instant 45 messaging, and presence. In its current form, it allows session 46 invitations, instant messages, and other requests to be delivered 47 from one party to another without requiring explicit consent of the 48 recipient. Without such consent, it is possible for SIP to be used 49 for malicious purposes, including spam and denial-of-service attacks. 50 This document identifies a framework for consent-based communications 51 in SIP. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 4 58 4. Structure of a Permission . . . . . . . . . . . . . . . . . 4 59 5. Attempting Communication . . . . . . . . . . . . . . . . . . 5 60 6. Requesting a Permission . . . . . . . . . . . . . . . . . . 6 61 7. Waiting for Permissions . . . . . . . . . . . . . . . . . . 6 62 8. Granting a Permission . . . . . . . . . . . . . . . . . . . 7 63 8.1 Permission Servers . . . . . . . . . . . . . . . . . . . . 7 64 9. Retrying the Original Request . . . . . . . . . . . . . . . 8 65 10. Permission Revocation . . . . . . . . . . . . . . . . . . . 8 66 11. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 11.1 Basic Flow with No Permission Server . . . . . . . . . . 8 68 11.2 Basic Flow with a Permission Server . . . . . . . . . . 9 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 12.1 Normative References . . . . . . . . . . . . . . . . . . . 11 71 12.2 Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 73 Intellectual Property and Copyright Statements . . . . . . . 13 75 1. Introduction 77 The Session Initiation Protocol (SIP) [1] supports communications 78 across many media types, including real-time audio, video, text, 79 instant messaging and presence. This communication is established by 80 the transmission of various SIP requests (such as INVITE and MESSAGE 81 [2]) from an initiator to the recipient, with whom communication is 82 desired. Although a recipient of such a SIP request can reject the 83 request, and therefore decline the session, a SIP network will 84 deliver a SIP request to the recipient without their explicit 85 consent. 87 Receipt of these requests without explicit consent can cause a number 88 of problems in SIP networks. These include spam and DoS (Denial of 89 Service) attacks. These problems are described in more detail in a 90 companion requirements document 91 [draft-rosenberg-sipping-consent-reqs-00.txt]. 93 This specification defines a basic framework for adding consent-based 94 communication to SIP. 96 2. Relays 98 A central concept in this framework is that of a relay. A relay is 99 defined as any SIP server, be it a proxy, back-to-back user agent or 100 some hybrid, which receives a request and translates the request URI 101 into one or more next hop URIs to which it then delivers a request. 102 So, an essential aspect of a relay is that of translation. 104 When a relay receives a request, it translates the request URI into 105 one or more additional URIs. Or, more generally, it can create 106 outgoing requests to one or more additional URIs. The translation 107 operation is what creates the consent problem. Since the translation 108 operation can result in more than one URI, it is the source of 109 amplification. Servers that do not perform translations, such as 110 outbound proxy servers, do not cause amplification. 112 Since the translation operation is based on local policy or local 113 data (such as registrations), it is the vehicle by which a request is 114 delivered directly to an endpoint, when it would not otherwise be 115 possible to. In other words, if a spammer has the address of a user, 116 sip:user@example.com, it cannot deliver a MESSAGE request to the user 117 agent of that user without having access to the registration data 118 that maps sip:user@example.com to the UA on which that user is 119 present. Thus, it is the usage of this registration data, and more 120 generally, the translation logic, which must be authorized, in order 121 to prevent undesired communications. 123 3. Reference Architecture 125 The reference architecture is shown in Figure 1. In this 126 architecture, a UAC wishes to send a message to a request URI 127 representing a resource in domain A (sip:resource@A). This request 128 may pass through a local outbound proxy (not shown), but eventually 129 arrives at a server authoritative for domain A. This server, which 130 acts as a relay, performs a translation operation, translating the 131 request URI into one or more next hop URIs, which may or may not 132 belong to domain A. This relay may be a proxy server of a URI-list 133 service, for instance. 135 +-------+ 136 | | 137 >| UAS 1 | 138 +-------+ / | | 139 | Rules | / +-------+ 140 | DB | / 141 +-------+ / 142 | / 143 V / 144 +-----+ +-------+ / +-------+ 145 | | | |/ | | 146 | UAC |------>| Relay |-------->| UAS 2 | 147 | | | |\ | | 148 +-----+ +-------+ \ +-------+ 149 \ 150 \ [...] 151 \ 152 \ 153 \ +-------+ 154 \ | | 155 >| UAS n | 156 | | 157 +-------+ 159 Figure 1 161 4. Structure of a Permission 163 This framework centers on the idea that a relay will only perform a 164 translation if a permission is in place authorizing that translation. 165 As such, the notion of a permission is another key part of this 166 framework. A permission is an object, represented in XML, that 167 contains several pieces of data: 169 Identity of the Sender: A URI representing the identity of the sender 170 for whom permissions are granted. 172 Identity of the Recipient: A URI representing the target of the 173 translation. The permission grants ability for the sender to send 174 requests, and for a relay receiving those requests to forward them 175 to this URI. This is also called the recipient URI. 177 Operations Permitted: A set of specific methods or qualifiers for 178 which the permission applies. For example, the permission may only 179 grant relaying for INVITE or MESSAGE, or for MESSAGE with specific 180 MIME types. 182 Signature: A digital signature over the rest of the permission, 183 signed by an entity that can identify itself as the recipient URI. 184 The signature is not always present. 186 Permissions are installed on a resource by resource basis. That is, 187 for each target URI to which a request is sent, there is a set of 188 permissions installed for that URI. Each permission has the content 189 described above. 191 It is important to note that the permission itself does not depend 192 on, or contain, the identity of a target URI (i.e., the input). As 193 such, if a request is sent to sip:resource1@A and to sip:resource2@A, 194 and for both targets, the same permission was installed, allowing 195 requests from the sender to be relayed to sip:resource@B, that same 196 permission would allow the translation to take place for both 197 targets. 199 A natural format for representing permissions appears to be the 200 common policy format [4]. This format is also used for presence 201 permissions. 203 5. Attempting Communication 205 When a UA sends a request to a target resource, the request 206 eventually arrives at a server that is authoritative for the domain 207 in the request URI. The server may require, as part of its processing 208 logic, the relaying of the request to one or more next hops. If such 209 relaying is required, the server first authenticates the sender of 210 the request. Such authentication can be done using the SIP identity 211 mechansim [5]. Once the sender is authenticated, the server checks 212 its permission database for that target resource. It looks for 213 permissions containing senders whose URI matches the identity of the 214 sender of the request. Of those that are found, the server checks to 215 see if the permitted translated URI matches the URIs to which the 216 server wishes to relay the request. 218 If at least one of the next hops to which the server wishes to relay 219 have not been permitted, the server rejects the request with a 470 220 (Consent Needed) response. The 470 response code indicates that the 221 request couldn't be relayed because at least one permission was not 222 present. The error response can contain a body, which contains a list 223 of URIs for the translations for which permissions have not yet been 224 obtained. This is effectively an instruction for the sender to go 225 off, and obtain permissions from those URIs. 227 6. Requesting a Permission 229 If the attempt to communicate was rejected with a 470 (Consent 230 Needed) response, the client knows that it must obtain some number of 231 permissions in order for the communications to take place. The error 232 response will include a list of URIs for which permission must be 233 obtained. To obtain permission, the client sends a CONSENT request to 234 each of the URIs it learned from the body of the error response. 235 These URIs typically route to the relay, which will forward them on 236 to the destinations whose permissions have not been obtained yet. The 237 CONSENT request carries a Consent-Methods header field which 238 indicates for which methods consent is being requested. 240 When the CONSENT request arrives at the relay, the relay adds a 241 Permission header field which contains a URI that the receiver can 242 use to upload a permission (e.g., the receiver can use XCAP to upload 243 an XML-based permission document). Then, the relay forwards the 244 request towards its destination. 246 If there are several relays between the sender and the final 247 destination, those CONSENT requests may also fail if permissions have 248 not yet been obtained, in which case the process recurses. 249 Eventually, the client will have sent a request to all of the relays 250 at the leaves of the translation tree between the sender and the 251 final destinations. 253 7. Waiting for Permissions 255 A CONSENT request is responded with a 202 (Accepted) response, which 256 carries a URI in a Call-Info header field (wait-permission purpose) 257 where the client can SUBSCRIBE to using the wait-permission event 258 package. This event package models the state of the permission 259 granted to the client for communicating with the target URI. When a 260 permission is granted, the state changes, and the client receives a 261 NOTIFY. This NOTIFY contains the permission(s) that have been granted 262 for the sender. 264 Usage of an event package has the benefit that the client can come 265 back at any time and do a query SUBSCRIBE to see if permissions were 266 granted, or it can wait for them to be granted, and find out when. 267 There is no requirement that the client use this event package to 268 wait. For some requests, it may not be important for the sender to 269 find out when permission is granted (e.g., a presence subscription). 271 8. Granting a Permission 273 On reception of a CONSENT request, if the user wishes to grant a 274 permission, XCAP is used, just as it is today in presence. The owner 275 of the target resource would use contact the URI in the Permission 276 header field of the CONSENT request and use XCAP to place the 277 permission into a document containing the list of permissions for 278 that target resource. 280 The XCAP server needs to make sure that the entity uploading the 281 permission document is the same as the destination of the CONSENT 282 request. This is done by inserting a URI in the Permission header 283 field of the CONSENT request which is long and random enough so that 284 it cannot be guessed. In addition, the CONSENT request is delivered 285 to the user using a SIPS URI. Then, the server inserting such a URI 286 relies on the SIP routing infrastructure to deliver the CONSENT 287 request to its proper destination. 289 If the SIP routing infrastructure is compromised, it could route 290 the CONSENT request to an attacker so that the attacker could 291 authorize requests addressed to a victim. Nevertheless, if the SIP 292 routing infrastructure gets compromised, many types of attacks 293 much worse than this are possible. So, relaying on the SIP routing 294 infrastructure seems like a sensible choice. 296 Using XCAP to grant permissions will require the definition of a new 297 application usage. We note that this usage appears to be a 298 generalization of the presence rules usage currently defined 299 [PRES-RULES]. 301 8.1 Permission Servers 303 We have just described how a user agent that receives a CONSENT 304 request can use XCAP to grant certain permissions. Nevertheless, 305 users are not on-line all the time and, so, sometimes are not able to 306 receive CONSENT requests. 308 This issue is also found in presence, where a user's status is 309 reported by a presence server instead of by the user's user agents, 310 which can go on and off-line. Similarly, we define permission 311 servers. Permission servers are network elements that act as SIP UAs 312 and handle CONSENT requests for a user. 314 Permission servers inform users about new CONSENT requests using the 315 "grant-permission" event package. The user associated with the target 316 URI SUBSCRIBEs to the "grant-permission" event package at the 317 permission server. This event package models the state of all pending 318 CONSENT requests for a particular resource, for which permissions do 319 not yet exist. When a new CONSENT request arrives for which 320 permissions have not been granted, a NOTIFY is sent to the user. This 321 informs them that permission is needed for a particular sender. The 322 NOTIFY contains information on the operation which was requested. 324 There is a strong similarity between the watcherinfo event package 325 and the grant-permission event package. Indeed, the 326 grant-permission package is effectively a superset of watcherinfo. 327 Once in place, presentities could use the grant-permission event 328 package for presence in addition to all other services for which 329 opt-in is being provided. 331 9. Retrying the Original Request 333 The sender learns about permissions through the wait-permission event 334 package. Once it has obtained permissions for all of the resources 335 that were identified in the 470 (Consent Needed) response, the client 336 can retry the original request. 338 10. Permission Revocation 340 At any time, if a client wants to revoke any permission, it uses the 341 XCAP URI that received in the CONSENT message or through the 342 grant-permission event package. If a client lost this URI for some 343 reason, it would need to wait until it received a new request and 344 respond with a 470 (Consent Needed) response. The client would get 345 the URI in a new CONSENT request. 347 OPEN ISSUE: if we defined the Permission header field so that it can 348 be present in any request, and not only in CONSENT requests, the 349 relay could add this header field to every request directed to the 350 user which used SIPS. 352 11. Use Cases 354 The following use cases exhibit how the framework works. 356 11.1 Basic Flow with No Permission Server 358 A Relay B 359 | MESSAGE list@relay | | 360 |-------------------------->| | 361 | 470 | | 362 | xyz@relay | | 363 |<--------------------------| | 364 | | | 365 | CONSENT xyz@relay | CONSENT B | 366 | Consent-methods: MESSAGE | Consent-methods: MESSAGE | 367 |-------------------------->| Permission: xcap-uri | 368 | |-------------------------->| 369 | 202 Accepted | | 370 | Call-Info: 123@relay; | 202 Accepted | 371 | purpose: wait-permission |<--------------------------| 372 |<--------------------------| | 373 | | | 374 | SUBSCRIBE 123@relay | | 375 |-------------------------->| | 376 | 200 OK | | 377 |<--------------------------| | 378 | | | 379 | NOTIFY (no permission) | | 380 |<--------------------------| | 381 | 200 OK | | 382 |-------------------------->| | 383 | | | 384 | | XCAP xcap-uri | 385 | | Permission Grant | 386 | |<--------------------------| 387 | | 200 OK | 388 | NOTIFY (permission) |-------------------------->| 389 |<--------------------------| | 390 | 200 OK | | 391 |-------------------------->| | 392 | | | 393 | MESSAGE list@relay | | 394 |-------------------------->| MESSAGE B | 395 | |-------------------------->| 396 | | | 398 Figure 2 400 Alternatively, the Call-Info header field could have been inserted by 401 B directly. In this case, A would SUBSCRIBE to B, instead of 402 subscribing to the Relay. 404 11.2 Basic Flow with a Permission Server 405 A Relay B's Permission B 406 Server 408 | MESSAGE list@relay | | | 409 |-------------------------->| | | 410 | 470 | | | 411 | xyz@relay | | | 412 |<--------------------------| | | 413 | | | | 414 | CONSENT xyz@relay | CONSENT B | | 415 | Consent-methods: MESSAGE | Consent-methods: MESSAGE | 416 |-------------------------->| Permission: xcap-uri | 417 | |----------------->| | 418 | 202 Accepted | | | 419 | Call-Info: 123@relay; | 202 Accepted | | 420 | purpose: wait-permission |<-----------------| | 421 |<--------------------------| | | 422 | | | | 423 | SUBSCRIBE 123@relay | | | 424 |-------------------------->| | | 425 | 200 OK | | | 426 |<--------------------------| | | 427 | | | | 428 | NOTIFY (no permission) | | [B goes on-line] | 429 |<--------------------------| | | 430 | 200 OK | | | 431 |-------------------------->| | SUBSCRIBE | 432 | | | grant-permission | 433 | | |<------------------| 434 | | | 200 OK | 435 | | |------------------>| 436 | | | | 437 | | | NOTIFY | 438 | | | xcap-uri | 439 | | |------------------>| 440 | | | 200 OK | 441 | | |<------------------| 442 | | XCAP xcap-uri | | 443 | | Permission Grant| | 444 | |<-------------------------------------| 445 | | 200 OK | | 446 | NOTIFY (permission) |--------------------------------------| 447 |<--------------------------| | | 448 | 200 OK | | | 449 |-------------------------->| | | 450 | | | | 451 | MESSAGE list@relay | | | 452 |-------------------------->| | | 453 | | MESSAGE B | | 454 | |------------------------------------->| 455 | | | | 457 Figure 3 459 12. References 461 12.1 Normative References 463 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 464 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 465 Session Initiation Protocol", RFC 3261, June 2002. 467 [2] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 468 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 469 Messaging", RFC 3428, December 2002. 471 12.2 Informative References 473 [3] Rosenberg, J., "A Presence Event Package for the Session 474 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 475 in progress), January 2003. 477 [4] Schulzrinne, H., "Common Policy", 478 draft-ietf-geopriv-common-policy-00 (work in progress), February 479 2004. 481 [5] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 482 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 484 Authors' Addresses 486 Jonathan Rosenberg 487 dynamicsoft 488 600 Lanidex Plaza 489 Parsippany, NJ 07054 490 US 492 Phone: +1 973 952-5000 493 EMail: jdrosen@dynamicsoft.com 494 URI: http://www.jdrosen.net 495 Gonzalo Camarillo 496 Ericsson 497 Hirsalantie 11 498 Jorvas 02420 499 Finland 501 EMail: Gonzalo.Camarillo@ericsson.com 503 Dean Willis 504 dynamicsoft 505 5100 Tennyson Parkway 506 Suite 1200 507 Plano, TX 75028 508 USA 510 EMail: dean.willis@softarmor.com 512 Intellectual Property Statement 514 The IETF takes no position regarding the validity or scope of any 515 Intellectual Property Rights or other rights that might be claimed to 516 pertain to the implementation or use of the technology described in 517 this document or the extent to which any license under such rights 518 might or might not be available; nor does it represent that it has 519 made any independent effort to identify any such rights. Information 520 on the IETF's procedures with respect to rights in IETF Documents can 521 be found in BCP 78 and BCP 79. 523 Copies of IPR disclosures made to the IETF Secretariat and any 524 assurances of licenses to be made available, or the result of an 525 attempt made to obtain a general license or permission for the use of 526 such proprietary rights by implementers or users of this 527 specification can be obtained from the IETF on-line IPR repository at 528 http://www.ietf.org/ipr. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights that may cover technology that may be required to implement 533 this standard. Please address the information to the IETF at 534 ietf-ipr@ietf.org. 536 Disclaimer of Validity 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 541 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 542 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 543 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Copyright Statement 548 Copyright (C) The Internet Society (2004). This document is subject 549 to the rights, licenses and restrictions contained in BCP 78, and 550 except as set forth therein, the authors retain all their rights. 552 Acknowledgment 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.