idnits 2.17.1 draft-ietf-sipping-consent-framework-04.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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1018. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 25, 2006) is 6632 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) ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '3') == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-01) exists of draft-camarillo-sipping-consent-format-00 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-08 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-reqs (ref. '17') == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 29, 2006 G. Camarillo, Ed. 5 Ericsson 6 D. Willis 7 Cisco Systems 8 February 25, 2006 10 A Framework for Consent-Based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sipping-consent-framework-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 29, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Session Initiation Protocol (SIP) supports communications across 46 many media types, including real-time audio, video, text, instant 47 messaging, and presence. In its current form, it allows session 48 invitations, instant messages, and other requests to be delivered 49 from one party to another without requiring explicit consent of the 50 recipient. Without such consent, it is possible for SIP to be used 51 for malicious purposes, including amplification and DoS (Denial of 52 Service) attacks. This document identifies a framework for consent- 53 based communications in SIP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Relays and Translations . . . . . . . . . . . . . . . . . . . 3 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 6 62 4.2. Consenting Manipulations on a Relay's Transaction Logic . 6 63 4.3. Permission Servers . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 8 65 5. Overview of Operations . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 10 67 5.2. Subscription to the Permission Status . . . . . . . . . . 11 68 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 11 69 5.4. Permission Document Structure . . . . . . . . . . . . . . 11 70 5.5. Permission Requested Notification . . . . . . . . . . . . 12 71 5.6. Permission Upload . . . . . . . . . . . . . . . . . . . . 12 72 5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 13 73 5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 13 74 5.6.3. Return Routability . . . . . . . . . . . . . . . . . . 13 75 5.7. Permission Granted Notification . . . . . . . . . . . . . 14 76 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 14 77 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 15 78 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 17 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . . . 24 87 1. Introduction 89 The Session Initiation Protocol (SIP) [1] supports communications 90 across many media types, including real-time audio, video, text, 91 instant messaging and presence. This communication is established by 92 the transmission of various SIP requests (such as INVITE and MESSAGE 93 [4]) from an initiator to the recipient, with whom communication is 94 desired. Although a recipient of such a SIP request can reject the 95 request, and therefore decline the session, a SIP network will 96 deliver a SIP request to the recipient without their explicit 97 consent. 99 Receipt of these requests without explicit consent can cause a number 100 of problems in SIP networks. These include amplification and DoS 101 (Denial of Service) attacks. These problems are described in more 102 detail in a companion requirements document [17]. 104 This specification defines a basic framework for adding consent-based 105 communication to SIP. 107 2. Definitions 109 Recipient URI: The request-URI of an outgoing request sent by an 110 entity (e.g., a user agent or a proxy). The sending of such 111 request may have been the result of a translation operation. 113 Target URI: The request-URI of an incoming request that arrives to an 114 entity (e.g., a proxy) that will perform a translation operation. 116 Translation operation: Operation by which an entity (e.g., a proxy) 117 translates the request URI of an incoming request (i.e., the 118 target URI) into one or more URIs (i.e., recipient URIs) which are 119 used as the request URIs of one or more outgoing requests. 121 3. Relays and Translations 123 Relays play a key role in this framework. A relay is defined as any 124 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 125 hybrid, which receives a request and translates the request URI into 126 one or more next hop URIs to which it then delivers a request. The 127 request URI of the incoming request is referred to as 'target URI' 128 and the destination URI of the outgoing requests is referred to as 129 'recipient URIs', as shown in Figure 1. 131 +---------------+ 132 | | recipient URI 133 | |----------------> 134 target URI | Translation | 135 -------------->| Operation | recipient URI 136 | |----------------> 137 | | 138 +---------------+ 140 Figure 1: Translation operation 142 Thus, an essential aspect of a relay is that of translation. When a 143 relay receives a request, it translates, following its translation 144 logic, the request URI into one or more additional URIs. Or, more 145 generally, it can create outgoing requests to one or more additional 146 URIs. The translation operation is what creates the consent problem. 148 Additionally, since the translation operation can result in more than 149 one URI, it is also the source of amplification. Servers that do not 150 perform translations, such as outbound proxy servers, do not cause 151 amplification. 153 Since the translation operation is based on local policy or local 154 data (such as registrations), it is the vehicle by which a request is 155 delivered directly to an endpoint, when it would not otherwise be 156 possible to. In other words, if a spammer has the address of a user, 157 'user@example.com', it cannot deliver a MESSAGE request to the UA 158 (User Agent) of that user without having access to the registration 159 data that maps 'user@example.com' to the user agent on which that 160 user is present. Thus, it is the usage of this registration data, 161 and more generally, the translation logic, which must be authorized 162 in order to prevent undesired communications. (Of course, if the 163 spammer knows the address of the user agent, it will be able to 164 deliver requests directly to it.) 166 Figure 2 shows a relay that performs translations. The user agent 167 client (UAC) in the figure sends a SIP request to a URI representing 168 a resource in the domain 'example.com' (resource@example.com). This 169 request may pass through a local outbound proxy (not shown), but 170 eventually arrives at a server authoritative for the domain 171 'example.com'. This server, which acts as a relay, performs a 172 translation operation, translating the target URI into one or more 173 recipient URIs, which may or may not belong to the domain 174 'example.com'. This relay may be, for instance, a proxy server or a 175 URI-list service [18]. 177 +-------+ 178 | | 179 >| UAS | 180 / | | 181 / +-------+ 182 / 183 / 184 +-----------------------+ / 185 | | / 186 +-----+ | Relay | / +-------+ 187 | | | |/ | | 188 | UAC |------>| |-------->| Proxy | 189 | | |+---------------------+|\ | | 190 +-----+ || Translation || \ +-------+ 191 || Logic || \ 192 |+---------------------+| \ [...] 193 +-----------------------+ \ 194 \ 195 \ +-------+ 196 \ | | 197 >| B2BUA | 198 | | 199 +-------+ 201 Figure 2: Relay performing a translation 203 This framework allows potential recipients of a translation to agree 204 to be actual recipients by giving permission to the relay performing 205 the translation to send them traffic. 207 4. Architecture 209 Figure 3 shows the architectural elements of this framework. 210 Section 4.1 describes the role of permissions at a relay. 211 Section 4.2 discusses the actions taken by a relay when its 212 translation logic is manipulated by a client. Section 4.3 introduces 213 permission servers and their functionality. Section 4.4 describes 214 how potential recipients can grant permissions to a relay to add them 215 to the relay's translation logic. 217 +-----------------------+ Permission +------------+ 218 | | Request | | 219 +--------+ | Relay |----------->| Permission | 220 | | | | | Server | 221 | Client | | | | | 222 | | |+-------+ +-----------+| +------------+ 223 +--------+ ||Transl.| |Permissions|| | 224 | ||Logic | | || Permission | 225 | |+-------+ +-----------+| Request | 226 | +-----------------------+ V 227 | ^ ^ +------------+ 228 | Manipulation | | Permission Grant | | 229 +---------------+ +-------------------| Recipient | 230 | | 231 +------------+ 233 Figure 3: Reference Architecture 235 4.1. Permissions at a Relay 237 Relays implementing this framework need to obtain and store 238 permissions associated to their translation logics. These 239 permissions indicate if a particular recipient has agreed to receive 240 traffic or not at any given time. Recipients that have not given 241 permission to the relay to send them traffic are simply ignored by 242 the relay when performing a translation. 244 Permissions are valid as long as the context where they were granted 245 is valid. For example, the permissions obtained by a URI-list SIP 246 service that distributes MESSAGE requests to a set of recipients will 247 be valid as long as the URI-list SIP service exists. 249 4.2. Consenting Manipulations on a Relay's Transaction Logic 251 This framework aims to ensure that any particular Relay only performs 252 translations towards destinations that have given permission to the 253 Relay to perform such a translation. Consequently, when the 254 translation logic of a relay is manipulated (e.g., a new recipient 255 URI is added), the relay needs to obtain permission from the new 256 recipient in order to install the new translation logic. Relays ask 257 recipients for permission using CONSENT [10] requests. 259 For example, the relay hosting the URI-list service at 260 'friends@example.com' performs a translation from that URI to a set 261 of recipient URIs. When a client (e.g., the administrator of that 262 URI-list service) adds 'bob@example.org' as a new recipient URI, the 263 relay sends a CONSENT request to 'bob@example.org' asking whether or 264 not it is OK to perform the translation from 'friends@example.com' to 265 'bob@example.org' (CONSENT requests carry in their message bodies a 266 permission document that describes the translation for which 267 permissions are being requested). If the answer is positive, the new 268 translation logic is installed at the relay. That is, the new 269 recipient URI is added. 271 Note that the mechanism to be used to manipulate the translation 272 logic of a particular relay depends on the relay. One possible 273 mechanism to manipulate translation logic is XCAP [15]. Section 5.9 274 and Section 5.10 describe how to add recipients to a translation 275 using request-contained URI lists and REGISTER requests respectively. 277 In any case, manipulation mechanisms implementing this framework need 278 to have a means to indicate that a particular recipient URI is in the 279 'Permission Pending' state and to provide the URI where the REFER 280 request needs to be sent to. 282 4.3. Permission Servers 284 When a CONSENT request sent by a relay arrives to the recipient URI 285 to which it was sent, the receiving user can grant or deny the 286 permission needed to perform the translation. Nevertheless, users 287 are not on-line all the time and, so, sometimes are not able to 288 receive CONSENT requests. 290 This issue is also found in presence, where a user's status is 291 reported by a presence server instead of by the user's user agents, 292 which can go on and off-line. Similarly, we define permission 293 servers, which are a key element of this framework. Permission 294 servers are network elements that act as SIP user agents and handle 295 CONSENT requests for a user. 297 Permission servers inform users about new CONSENT requests using the 298 'grant-permission' event package [12]. Figure 4 illustrates this 299 point. 301 The user associated with the recipient URI for which the relay will 302 ask for permission subscribes [2] (1) to the 'grant-permission' event 303 package at the permission server. This event package models the 304 state of all pending CONSENT requests for a particular resource. 305 When a new CONSENT request (3) arrives to the permission server, a 306 NOTIFY (5) is sent to the user. This informs them that permission is 307 needed for a particular sender. The NOTIFY contains the permission 308 document received in the CONSENT request. This permission document 309 is a description of the translation for which permissions are being 310 requested. 312 There is a strong similarity between the 'winfo' event template- 313 package [19] and the 'grant-permission' event package. Indeed, 314 the grant-permission package is effectively a superset of 315 watcherinfo. Once in place, presentities could use the grant- 316 permission event package for presence in addition to all other 317 services for which opt-in is being provided. 319 Relay B's Permission B 320 Server 321 | |(1) SUBSCRIBE | 322 | |Event: grant-permission 323 | |<------------------| 324 | |(2) 200 OK | 325 | |------------------>| 326 | |(3) NOTIFY | 327 | |------------------>| 328 | |(4) 200 OK | 329 | |<------------------| 330 |(5) CONSENT B@example | 331 |------------------>| | 332 |(6) 202 Accepted | | 333 |<------------------| | 334 | |(7) NOTIFY | 335 | |------------------>| 336 | |(8) 200 OK | 337 | |<------------------| 339 Figure 4: Permission server operation 341 4.4. Recipients Grant Permissions 343 Recipients provide relays with permissions using SIP PUBLISH 344 requests. These requests contain a permission document that 345 describes the translation for which permissions are being granted. 347 5. Overview of Operations 349 This section provides an overview of this framework using an example 350 of the prototypical call flow. The elements described in Section 4 351 (i.e., relays, translations, and permission servers) play an 352 essential role in this call flow. 354 Figure Figure 5 shows the complete process to add a recipient URI 355 ('B@example.com') to the translation logic of a relay. The call flow 356 starts with user B subscribing to the permission server using the 357 'grant-permission' event package [12]. User B will be informed about 358 the arrival of CONSENT [10] requests addressed to 'B@example.com'. 360 User A attempts to add 'B@example.com' as a new recipient URI to the 361 translation logic of the relay (5). User A uses XCAP [15] and the 362 XML (Extensible Markup Language) format for representing resource 363 lists [16] as extended by [14] to perform this addition. Since the 364 relay does not have permission from 'B@example.com' to perform 365 translations towards that URI, the relay places 'B@example.com' in 366 the 'Pending' state [14] and informs user A (6). 368 A@example.com Relay B's Permission B@example.com 369 Server 370 | | |(1) SUBSCRIBE | 371 | | |Event: grant-permission 372 | | |<---------------| 373 | | |(2) 200 OK | 374 | | |--------------->| 375 | | |(3) NOTIFY | 376 | | |--------------->| 377 | | |(4) 200 OK | 378 | | |<---------------| 379 |(5) Add Recipient B@example.com | | 380 |--------------->| | | 381 |(6) Permission Pending | | 382 |<---------------| | | 383 |(7) REFER | | | 384 |Refer-To: B@example.com?method=CONSENT | 385 |--------------->| | | 386 |(8) 200 OK | | | 387 |<---------------| | | 388 |(9) SUBSCRIBE | | | 389 |Event: list-state | | 390 |--------------->| | | 391 |(10) 200 OK | | | 392 |<---------------| | | 393 |(11) NOTIFY | | | 394 |<---------------| | | 395 |(12) 200 OK | | | 396 |--------------->| | | 397 | |(13) CONSENT B@example | 398 | |Permission-Upload: uri-up | 399 | |Permission Document | 400 | |--------------->| | 401 | |(14) 202 Accepted | 402 | |<---------------| | 403 | | |(15) NOTIFY | 404 | | |uri-up | 405 | | |Permission Document 406 | | |--------------->| 407 | | |(16) 200 OK | 408 | | |<---------------| 409 | |(17) PUBLISH uri-up | 410 | |Permission Document | 411 | |<--------------------------------| 412 | |(18) 200 OK | | 413 | |-------------------------------->| 414 |(19) NOTIFY | | | 415 |<---------------| | | 416 |(20) 200 OK | | | 417 |--------------->| | | 419 Figure 5: Prototypical call flow 421 5.1. Amplification Avoidance 423 Once 'B@example.com' is in the 'Permission Pending' state, the relay 424 needs to ask user B for permission by sending a CONSENT request to 425 'B@example.com'. However, the relay needs to ensure that it is not 426 used as an amplifier to launch amplification attacks. 428 In such an attack, the attacker would add a large number of recipient 429 URIs to the translation logic of a relay. The relay would then send 430 a CONSENT request to each of those URIs. The bandwidth generated by 431 the relay would be much higher than the bandwidth used by the 432 attacker to add those URIs to the translation logic of the relay. 434 This framework uses a credit-based authorization mechanism to avoid 435 the attack just described. It requires users adding new recipient 436 URIs to a translation to generate an amount of bandwidth that is 437 comparable to the bandwidth the relay will generate when sending 438 CONSENT requests towards those recipient URIs. This requirement is 439 met by having users generate REFER requests [5] towards the relay. 440 Each REFER request triggers the sending of a CONSENT request by the 441 relay. 443 So, the relay sends user A the URI (6) where user A needs to send a 444 REFER request. User A generates such a REFER request (7) and sends 445 it to the relay. User A uses the 'norefersub' extension [7], which 446 supresses the implicit subscription that is associated with REFER 447 transactions. This is because user A is not interested in the result 448 of the CONSENT transaction, but in whether or not user B will 449 authorize the translation by providing the requested permission. 451 The relay provides a URI (6) where user A can subscribe to obtain 452 information on whether or not user B provides the requested 453 permission. User A subscribes to that URI using the 'list-state' 454 [14] event package (9). 456 5.2. Subscription to the Permission Status 458 After sending the REFER (7) user A subscribes to the 'list-state' 459 event package at the relay. This subscription keeps user A informed 460 about the status of the permissions (e.g., granted or denied) the 461 relay will request on receiving the REFER request (7). 463 5.3. Request for Permission 465 On receiving the REFER request (7), the relay generates a CONSENT 466 request (13) towards 'B@example.com'. This CONSENT request carries a 467 permission document, which describes the translation that needs to be 468 authorized, and a URI where to upload the permission for that 469 translation. User B will authorize the translation by uploading the 470 permission document received in the CONSENT request into this URI, as 471 described in Section 5.6. 473 When the permission document is uploaded to the URI provided by the 474 relay (17), the relay needs to make sure that the permission document 475 received was generated by user B and not by an attacker. The relay 476 can use three methods to authenticate the permission document: SIP 477 identity, P-Asserted-Identity [3], or a return routability test. 478 These methods are described in Section 5.6. Relays using a return 479 routability test to perform this authentication need to send the 480 CONSENT request to a SIPS URI. 482 5.4. Permission Document Structure 484 A permission document is the XML representation of a permission. A 485 permission document contains several pieces of data: 487 Identity of the Sender: A URI representing the identity of the sender 488 for whom permissions are granted. 490 Identity of the Original Recipient: A URI representing the identity 491 of the original recipient, which is used as the input for the 492 translation operation. This is also called the target URI. 494 Identity of the Final Recipient: A URI representing the result of the 495 translation. The permission grants ability for the sender to send 496 requests to the target URI, and for a relay receiving those 497 requests to forward them to this URI. This is also called the 498 recipient URI. 500 Signature: A digital signature over the rest of the permission, 501 signed by an entity that can identify itself as the recipient URI. 502 The signature is not always present. 504 Permission documents may contain wildcards. For example, a 505 permission document may authorize any relay to forward requests 506 coming from a particular sender to a particular recipient. Such a 507 permission document would apply to any target URI. That is, the 508 field containing the identity of the original recipient would match 509 any URI. 511 The format for permission documents is defined in [11]. 513 The permission document in the CONSENT request (13) sent by the relay 514 contains the following values: 516 Identity of the Sender: Any. 518 Identity of the Original Recipient: friends@example.com 520 Identity of the Final Recipient: B@example.com 522 It is expected that the Sender field often contains a wildcard. 523 However, scenarios involving request-contained URI lists, such as the 524 one described in Section 5.9, may require permission documents that 525 apply to a specific sender. Of course, in cases where the identity 526 of the sender matters, it is essential that relays authenticate 527 senders. 529 5.5. Permission Requested Notification 531 On receiving the CONSENT request (13), B's permission server sends a 532 NOTIFY request (15) to user B, who had previously subscribed to the 533 grant-permission event package (1). This NOTIFY request contains, 534 the permission document, which describes the translation that needs 535 to be authorized, and a URI where to upload the permission for that 536 translation. Both the permission document and the URI to upload the 537 permission are copied from the CONSENT request (13) into the NOTIFY 538 request (15). 540 5.6. Permission Upload 542 On receiving the NOTIFY request (15), user B authorizes the 543 translation described in the permission document received by 544 uploading this permission document to the relay. User B uses a 545 PUBLISH request (17) to upload the permission document to the URI 546 received in the NOTIFY request. 548 When the permission document is uploaded to the URI provided by the 549 relay (17), the relay needs to make sure that the permission document 550 received was generated by user B and not by an attacker. The relay 551 can use three methods to authenticate the permission document: SIP 552 identity, P-Asserted-Identity [3], or a return routability test. 554 5.6.1. SIP Identity 556 The SIP identity [8] mechanism can be used to authenticate the sender 557 of the PUBLISH request uploading the permission document. The relay 558 checks that the originator of the PUBLISH request is the owner of the 559 recipient URI in the permission document. Otherwise, the permission 560 document is discarded. 562 5.6.2. P-Asserted-Identity 564 The P-Asserted-Identity [3] mechanism can be used to authenticate the 565 sender of the PUBLISH request uploading the permission document. 566 However, as discussed in RFC 3325 [3], this mechanism should only be 567 used within networks of trusted SIP servers. That is, the use of 568 this mechanism is only applicable inside an administrative domain 569 with previously agreed-upon policies. 571 The relay checks that the originator of the PUBLISH request is the 572 owner of the recipient URI in the permission document. Otherwise, 573 the permission document is discarded. 575 5.6.3. Return Routability 577 SIP identity provides a good authentication mechanism for this type 578 of scenario. Nevertheless, SIP identity is not widely available on 579 the public Internet yet. That is why an authentication mechanism 580 that can already be used at this point is needed. 582 Return routability tests do not provide the same level of security as 583 SIP identity, but they provide a good-enough security level in 584 architectures where the SIP identity mechanism is not available 585 (e.g., the current Internet). The relay generates an unguessable URI 586 (e.g., with a long and random-looking user part) and places it in the 587 CONSENT request (13). The recipient needs to upload the permission 588 document to that URI. 590 Relays using a return routability test to perform this authentication 591 need to send the CONSENT request to a SIPS URI. This ensures that 592 attackers do not get access to the (unguessable) URI. Thus, the only 593 user able to upload the permission document to the (unguessable) URI 594 is the receiver of the CONSENT request. 596 Relays can transition from return routability tests to SIP identity 597 by simply requiring the use of SIP identity for incoming PUBLISH 598 requests. That is, such a relay would reject PUBLISH requests that 599 did not use SIP identity. 601 5.7. Permission Granted Notification 603 On receiving the PUBLISH request (17), the relay sends a NOTIFY 604 request (19) to inform user A that the permission for the translation 605 has been received that the translation logic at the relay has been 606 updated. That is, 'B@example.com' has been added as a recipient URI. 608 5.8. Permission Revocation 610 At any time, if a client wants to revoke any permission, it uses the 611 same URI as before to upload, using a PUBLISH request, a new 612 permission document that does not authorize the translation at the 613 relay any longer. If a client loses this URI for some reason, it 614 needs to wait until it receives a new request product of the 615 translation. Such a request will contain a Trigger-Consent header 616 field with a URI. That URI will have an escaped Refer-To header 617 field identifying the client (i.e., the recipient of the 618 translation). The client needs to send a REFER request to the URI in 619 the Trigger-Consent header field in order to receive a CONSENT 620 request from the relay. Such a CONSENT request will contain the 621 permission document that was uploaded to the relay at some point and 622 the URI where the user can upload a new permission document that does 623 not authorize the translation at the relay any longer. 625 Figure 6 shows an example of a user revoking permissions at a relay. 626 The user rejects an incoming INVITE (5) request, which contains a 627 Trigger-Consent header field. Using the URI in the that header 628 field, the user sends a REFER request (8) to the relay. On receiving 629 the REFER request (8), the relay generates a CONSENT request (8) 630 towards the user. Finally, the user revokes the permissions by 631 sending a PUBLISH request (14) to the relay. 633 Relay B's Permission B@example.com 634 Server 635 | |(1) SUBSCRIBE | 636 | |Event: grant-permission 637 | |<---------------| 638 | |(2) 200 OK | 639 | |--------------->| 640 | |(3) NOTIFY | 641 | |--------------->| 642 | |(4) 200 OK | 643 | |<---------------| 644 |(5) INVITE | | 645 |Trigger-Consent: <123@relay.example.com> 646 | ?Refer-To= 647 |-------------------------------->| 648 |(6) 603 Decline | | 649 |<--------------------------------| 650 |(7) ACK | | 651 |-------------------------------->| 652 |(8) REFER 123@relay.example.com | 653 |Refer-To: B@example.com | 654 |<--------------------------------| 655 |(9) 200 OK | | 656 |-------------------------------->| 657 |(10) CONSENT B@example | 658 |Permission-Upload: uri-up | 659 |Permission Document | 660 |--------------->| | 661 |(11) 202 Accepted | 662 |<---------------| | 663 | |(12) NOTIFY | 664 | |uri-up | 665 | |Permission Document 666 | |--------------->| 667 | |(13) 200 OK | 668 | |<---------------| 669 |(14) PUBLISH uri-up | 670 |Permission Document Revoking Permissions 671 |<--------------------------------| 672 |(15) 200 OK | | 673 |-------------------------------->| 675 Figure 6: Permission Revocation 677 5.9. Request-contained URI Lists 679 In the scenarios described so far, a user adds recipient URIs to the 680 translation logic of a relay. However, the relay does not perform 681 translations towards those URIs until permissions are obtained. 683 URI-list services using request-contained URI lists are a special 684 case because the selection of recipient URIs is performed at the same 685 time as the communication attempt. A user places a set of recipient 686 URIs in a request and sends it to a relay so that the relay sends a 687 similar request to all those recipient URIs. 689 This type of URI-list services maintain a list of recipient URIs from 690 which permission have been received. This list is manipulated in the 691 same way as described in Section 5 and represents the set of URIs 692 that will be accepted if a request containing a URI-list arrives to 693 the relay. Additionally, Figure 7 shows another way to add entries 694 to that list. 696 If the relay receives a request (1) that contains URIs for which the 697 relay does not have permission, the relay rejects the request with a 698 470 (Consent Needed) response (2). Such a response contains a 699 Trigger-Consent header field with a URI for each recipient for which 700 there is no permission, as shown in Figure 7. Each URI entry in the 701 Trigger-Consent header field contains an escaped Refer-To header 702 field with the URI of the recipient. The user needs to send REFER 703 requests to the URIs in the Trigger-Consent header field. 704 Additionally, the response also contains a Call-Info header field 705 with a URI where the user can subscribe in order to be informed on 706 whether or not the relay receives permission from user B. The value 707 of the purpose parameter for this entry is 'list-state'. 709 OPEN ISSUE: do we need to provide that URI in a Call-Info header 710 field (or in a new header field) or can we assume that the sender has 711 a relationship with the relay and will know that URI already? 713 The rest of the process is similar to the one described in Section 5. 714 Note, however, that for simplicity, Figure 7 does not show the split 715 between user B's permission server and user agent. 717 A@example.com Relay B@example.com 718 |(1) INVITE | | 719 |B@example.com | | 720 |C@example.com | | 721 |------------------>| | 722 |(2) 470 Consent Needed | 723 |Trigger-Consent: <123@relay.example.com> 724 | ?Refer-To= 725 |Call-Info: 456@Relay;purpose=list-state 726 |<------------------| | 727 |(3) ACK | | 728 |------------------>| | 729 |(4) SUBSCRIBE 456@Relay | 730 |Event: list-state | 731 |------------------>| | 732 |(5) 200 OK | | 733 |<------------------| | 734 |(6) NOTIFY | | 735 |<------------------| | 736 |(7) 200 OK | | 737 |------------------>| | 738 |(8) REFER 123@Relay| | 739 |Refer-To: B@example.com | 740 |------------------>| | 741 |(9) 200 OK | | 742 |<------------------| | 743 | |(10) CONSENT B@example 744 | |Permission-Upload: uri-up-relay 745 | |Permission Document| 746 | |------------------>| 747 | |(11) 202 Accepted | 748 | |<------------------| 749 | |(12) PUBLISH uri-up-relay 750 | |Permission Document| 751 | |<------------------| 752 | |(13) 200 OK | 753 | |------------------>| 754 |(14) NOTIFY | | 755 |<------------------| | 756 |(15) 200 OK | | 757 |------------------>| | 759 Figure 7: INVITE with a URI list in its body 761 5.10. Registrations 763 Registrations are a special type of translations. The user 764 registering has a trust relationship with the registrar in its home 765 domain. This is not the case when a user gives any type of 766 permissions to a relay in a different domain. 768 Traditionally, REGISTER transactions have performed two operations at 769 the same time: setting up a translation and authorizing the use of 770 that translation. For example, a user registering its current 771 contact URI is giving permission to the registrar to forward traffic 772 sent to the user's AoR (Address of Records) to the registered contact 773 URI. This works fine when the entity registering is the same as the 774 one that will be receiving traffic at a later point (e.g., the entity 775 receives traffic over the same connection used for the registration 776 as described in [9]). However, this schema creates some potential 777 attacks which relate to third-party registrations. 779 An attacker binds, via a registration, his or her AoR with the 780 contact URI of a victim. Now, the victim will receive unsolicited 781 traffic that was originally addressed to the attacker. 783 The process of authorizing a registration is shown in Figure 8. User 784 A performs a third-party registration (1) and receives a 200 (OK) 785 response (2) with a Trigger-Consent header field. This header field 786 contains the URI for which there is no permission in an escaped 787 Refer-To header field. That is, the URI the user is attempting to 788 register. A REFER request sent to the URI in the Trigger-Consent 789 header field will trigger the registrar to send a CONSENT request to 790 the URI being registered. 792 The user sends a REFER request (7) to the URI received in the 793 Trigger-Consent header field. In order to know whether or not the 794 registrar receives the permission needed, the user subscribes (3) to 795 the 'reg-event' event package [6], which can report consent-related 796 information using the extension defined in [13]. The rest of the 797 process is similar to the one described in Section 5. 799 A@example.com Registrar a@ws123.example.com 800 |(1) REGISTER | | 801 |Contact: a@ws123.example.com | 802 |Supported: consent-reg | 803 |------------------>| | 804 |(2) 200 OK | | 805 |Required: consent-reg | 806 |Trigger-Consent: <123@relay.example.com> 807 | ?Refer-To= 808 |<------------------| | 809 |(3) SUBSCRIBE | | 810 |Event: reg-event | | 811 |------------------>| | 812 |(4) 200 OK | | 813 |<------------------| | 814 |(5) NOTIFY | | 815 |<------------------| | 816 |(6) 200 OK | | 817 |------------------>| | 818 |(7) REFER 123@Registrar | 819 |Refer-To: a@ws123.example.com | 820 |------------------>| | 821 |(8) 200 OK | | 822 |<------------------| | 823 | |(9) CONSENT a@ws123.example 824 | |Permission-Upload: uri-up 825 | |Permission Document| 826 | |------------------>| 827 | |(10) 202 Accepted | 828 | |<------------------| 829 | |(11) PUBLISH uri-up| 830 | |Permission Document| 831 | |<------------------| 832 | |(12) 200 OK | 833 | |------------------>| 834 |(13) NOTIFY | | 835 |<------------------| | 836 |(14) 200 OK | | 837 |------------------>| | 839 Figure 8: Registration 841 Permission documents used to authorize registrations are very 842 general. For example, one such document may authorize the registrar 843 to forward any request from any sender to a particular recipient URI. 844 This is the type of granularity that this framework intends to 845 provide for registrations. Users who want to define how incoming 846 requests are treated with a finer granularity (e.g., requests from 847 user A should only be accepted between 9:00 and 11:00) should use 848 other mechanisms such as CPL [20]. 850 Note that, as indicated previously, user agents using the same 851 connection to register and to receive traffic from the registrar, as 852 described in [9] do not need to use the mechanism described in this 853 section. 855 A user agent being registered by a third party may not be able to use 856 the SIP Identity or P-Asserted-Identity mechanisms to prove to the 857 registrar that the user agent is the owner of the URI being 858 registered (e.g., sip:user@192.0.2.1), which is the recipient URI of 859 the translation. In this case, return routability needs to be used. 861 6. IANA Considerations 863 This document does not require the IANA to take any actions. 865 7. Security Considerations 867 TBD. 869 Editor's note: we have to avoid that attackers provide permissions 870 for translations that apply to other users (e.g., allow everyone to 871 send traffic to a victim) and that attackers provide permissions for 872 a translation that apply to them but routes to a victim (e.g., 3rd 873 party registration that binds attacker@relay to victim@somewhere). 874 For the former we need authentication (e.g., SIP identity) and for 875 the latter we relay on the routing infrastructure to route CONSENTs 876 to the same place the traffic will be sent to once permissions are 877 obtained (i.e., a return routability test). 879 8. References 881 8.1. Normative References 883 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 884 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 885 Session Initiation Protocol", RFC 3261, June 2002. 887 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 888 Notification", RFC 3265, June 2002. 890 [3] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 891 to the Session Initiation Protocol (SIP) for Asserted Identity 892 within Trusted Networks", RFC 3325, November 2002. 894 [4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 895 D. Gurle, "Session Initiation Protocol (SIP) Extension for 896 Instant Messaging", RFC 3428, December 2002. 898 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 899 Method", RFC 3515, April 2003. 901 [6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 902 Package for Registrations", RFC 3680, March 2004. 904 [7] Levin, O., "Suppression of Session Initiation Protocol REFER 905 Method Implicit Subscription", 906 draft-ietf-sip-refer-with-norefersub-04 (work in progress), 907 January 2006. 909 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 910 Identity Management in the Session Initiation Protocol (SIP)", 911 draft-ietf-sip-identity-06 (work in progress), October 2005. 913 [9] Jennings, C. and R. Mahy, "Managing Client Initiated 914 Connections in the Session Initiation Protocol (SIP)", 915 draft-ietf-sip-outbound-01 (work in progress), October 2005. 917 [10] Camarillo, G., "A Document Format for Expressing Consent", 918 draft-camarillo-sip-consent-method-00 (work in progress), 919 February 2006. 921 [11] Camarillo, G., "A Document Format for Expressing Consent", 922 draft-camarillo-sipping-consent-format-00 (work in progress), 923 February 2006. 925 [12] Camarillo, G., "A Document Format for Expressing Consent", 926 draft-camarillo-sipping-grant-permission-00 (work in progress), 927 February 2006. 929 [13] Camarillo, G., "Session Initiation Protocol (SIP) Registration 930 Event Package Extension for Consent-Based Communications", 931 draft-camarillo-sipping-consent-reg-event-00 (work in 932 progress), February 2006. 934 [14] Camarillo, G., "The Session Initiation Protocol (SIP) List 935 State Event Package", draft-camarillo-sipping-list-state-00 936 (work in progress), February 2006. 938 [15] Rosenberg, J., "The Extensible Markup Language (XML) 939 Configuration Access Protocol (XCAP)", 940 draft-ietf-simple-xcap-08 (work in progress), October 2005. 942 [16] Rosenberg, J., "Extensible Markup Language (XML) Formats for 943 Representing Resource Lists", 944 draft-ietf-simple-xcap-list-usage-05 (work in progress), 945 February 2005. 947 [17] Rosenberg, J., "Requirements for Consent-Based Communications 948 in the Session Initiation Protocol (SIP)", 949 draft-ietf-sipping-consent-reqs-04 (work in progress), 950 January 2006. 952 [18] Camarillo, G. and A. Roach, "Framework and Security 953 Considerations for Session Initiation Protocol (SIP) Uniform 954 Resource Identifier (URI)-List Services", 955 draft-ietf-sipping-uri-services-05 (work in progress), 956 January 2006. 958 8.2. Informative References 960 [19] Rosenberg, J., "A Watcher Information Event Template-Package 961 for the Session Initiation Protocol (SIP)", RFC 3857, 962 August 2004. 964 [20] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 965 Language (CPL): A Language for User Control of Internet 966 Telephony Services", RFC 3880, October 2004. 968 Authors' Addresses 970 Jonathan Rosenberg 971 Cisco Systems 972 600 Lanidex Plaza 973 Parsippany, NJ 07054 974 US 976 Phone: +1 973 952-5000 977 Email: jdrosen@cisco.com 978 URI: http://www.jdrosen.net 980 Gonzalo Camarillo (editor) 981 Ericsson 982 Hirsalantie 11 983 Jorvas 02420 984 Finland 986 Email: Gonzalo.Camarillo@ericsson.com 988 Dean Willis 989 Cisco Systems 990 2200 E. Pres. George Bush Turnpike 991 Richardson, TX 75082 992 USA 994 Email: dean.willis@softarmor.com 996 Intellectual Property Statement 998 The IETF takes no position regarding the validity or scope of any 999 Intellectual Property Rights or other rights that might be claimed to 1000 pertain to the implementation or use of the technology described in 1001 this document or the extent to which any license under such rights 1002 might or might not be available; nor does it represent that it has 1003 made any independent effort to identify any such rights. Information 1004 on the procedures with respect to rights in RFC documents can be 1005 found in BCP 78 and BCP 79. 1007 Copies of IPR disclosures made to the IETF Secretariat and any 1008 assurances of licenses to be made available, or the result of an 1009 attempt made to obtain a general license or permission for the use of 1010 such proprietary rights by implementers or users of this 1011 specification can be obtained from the IETF on-line IPR repository at 1012 http://www.ietf.org/ipr. 1014 The IETF invites any interested party to bring to its attention any 1015 copyrights, patents or patent applications, or other proprietary 1016 rights that may cover technology that may be required to implement 1017 this standard. Please address the information to the IETF at 1018 ietf-ipr@ietf.org. 1020 Disclaimer of Validity 1022 This document and the information contained herein are provided on an 1023 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1024 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1025 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1026 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1027 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1028 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1030 Copyright Statement 1032 Copyright (C) The Internet Society (2006). This document is subject 1033 to the rights, licenses and restrictions contained in BCP 78, and 1034 except as set forth therein, the authors retain all their rights. 1036 Acknowledgment 1038 Funding for the RFC Editor function is currently provided by the 1039 Internet Society.