idnits 2.17.1 draft-ietf-sipping-consent-framework-01.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 784. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 797. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 20, 2005) is 7002 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) == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-03 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-03 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-consent-reqs-00 == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-01 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-01 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: August 21, 2005 G. Camarillo 4 Ericsson 5 D. Willis 6 Cisco Systems 7 February 20, 2005 9 A Framework for Consent-Based Communications in the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sipping-consent-framework-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 21, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The Session Initiation Protocol (SIP) supports communications across 47 many media types, including real-time audio, video, text, instant 48 messaging, and presence. In its current form, it allows session 49 invitations, instant messages, and other requests to be delivered 50 from one party to another without requiring explicit consent of the 51 recipient. Without such consent, it is possible for SIP to be used 52 for malicious purposes, including spam and denial-of-service attacks. 53 This document identifies a framework for consent-based communications 54 in SIP. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4 62 5. Structure of a Permission . . . . . . . . . . . . . . . . . . 5 63 6. Single-Relay Scenario . . . . . . . . . . . . . . . . . . . . 6 64 6.1 Attempting Communication . . . . . . . . . . . . . . . . . 6 65 6.2 Requesting a Permission . . . . . . . . . . . . . . . . . 8 66 6.3 Waiting for Permissions . . . . . . . . . . . . . . . . . 9 67 6.4 Granting a Permission . . . . . . . . . . . . . . . . . . 9 68 6.5 Retrying the Original Request . . . . . . . . . . . . . . 10 69 6.6 Permission Revocation . . . . . . . . . . . . . . . . . . 10 70 7. Permission Servers . . . . . . . . . . . . . . . . . . . . . . 11 71 8. Multiple-Relay Scenario . . . . . . . . . . . . . . . . . . . 12 72 8.1 Initial Steps . . . . . . . . . . . . . . . . . . . . . . 12 73 8.2 Waiting for Permissions . . . . . . . . . . . . . . . . . 15 74 8.3 Intermediate Relays . . . . . . . . . . . . . . . . . . . 15 75 9. Installing Permissions in Advance . . . . . . . . . . . . . . 16 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 77 11. Security Considerations . . . . . . . . . . . . . . . . . . 16 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 80 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . 18 84 1. Introduction 86 The Session Initiation Protocol (SIP) [1] supports communications 87 across many media types, including real-time audio, video, text, 88 instant messaging and presence. This communication is established by 89 the transmission of various SIP requests (such as INVITE and MESSAGE 90 [2]) from an initiator to the recipient, with whom communication is 91 desired. Although a recipient of such a SIP request can reject the 92 request, and therefore decline the session, a SIP network will 93 deliver a SIP request to the recipient without their explicit 94 consent. 96 Receipt of these requests without explicit consent can cause a number 97 of problems in SIP networks. These include spam and DoS (Denial of 98 Service) attacks. These problems are described in more detail in a 99 companion requirements document [5]. 101 This specification defines a basic framework for adding consent-based 102 communication to SIP. 104 2. Definitions 106 Recipient URI: The request-URI of an outgoing request sent by an 107 entity (e.g., a proxy) that has performed a translation operation. 109 Target URI: The request-URI of an incoming request that arrives to an 110 entity (e.g., a proxy) that will perform a translation operation. 112 Translation operation: Operation by which an entity (e.g., a proxy) 113 translates the request URI of an incoming request (i.e., the 114 target URI) into one or more URIs (i.e., recipient URIs) which are 115 used as the request URIs of one or more outgoing requests. 117 3. Relays 119 A central concept in this framework is that of a relay. A relay is 120 defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User 121 Agent), or some hybrid, which receives a request and translates the 122 request URI into one or more next hop URIs to which it then delivers 123 a request. The request URI of the incoming request is referred to as 124 'target URI' and the destination URI of the outgoing requests is 125 referred to as 'recipient URIs', as shown in Figure 1. 127 +---------------+ 128 | | recipient URI 129 | |----------------> 130 target URI | Translation | 131 -------------->| Operation | recipient URI 132 | |----------------> 133 | | 134 +---------------+ 136 Figure 1: Translation operation 138 Thus, an essential aspect of a relay is that of translation. When a 139 relay receives a request, it translates the request URI into one or 140 more additional URIs. Or, more generally, it can create outgoing 141 requests to one or more additional URIs. The translation operation 142 is what creates the consent problem. 144 Additionally, since the translation operation can result in more than 145 one URI, it is also the source of amplification. Servers that do not 146 perform translations, such as outbound proxy servers, do not cause 147 amplification. 149 Since the translation operation is based on local policy or local 150 data (such as registrations), it is the vehicle by which a request is 151 delivered directly to an endpoint, when it would not otherwise be 152 possible to. In other words, if a spammer has the address of a user, 153 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA 154 (User Agent) of that user without having access to the registration 155 data that maps 'sip:user@example.com' to the UA on which that user is 156 present. Thus, it is the usage of this registration data, and more 157 generally, the translation logic, which must be authorized in order 158 to prevent undesired communications. 160 4. Reference Architecture 162 The reference architecture is shown in Figure 2. In this 163 architecture, a UAC wishes to send a message to a request URI 164 representing a resource in domain A (sip:resource@A). This request 165 may pass through a local outbound proxy (not shown), but eventually 166 arrives at a server authoritative for domain A. This server, which 167 acts as a relay, performs a translation operation, translating the 168 target URI into one or more recipient URIs, which may or may not 169 belong to domain A. This relay may be, for instance, a proxy server 170 or a URI-list service [7]. 172 +-------+ 173 | | 174 >| UAS | 175 +-------+ / | | 176 | Rules | / +-------+ 177 | DB | / 178 +-------+ / 179 | / 180 V / 181 +-----+ +-------+ / +-------+ 182 | | | |/ | | 183 | UAC |------>| Relay |-------->| Proxy | 184 | | | |\ | | 185 +-----+ +-------+ \ +-------+ 186 \ 187 \ [...] 188 \ 189 \ 190 \ +-------+ 191 \ | | 192 >| B2BUA | 193 | | 194 +-------+ 196 Figure 2: Relay performing a translation 198 5. Structure of a Permission 200 This framework centers on the idea that a relay will only perform a 201 translation if a permission is in place authorizing that translation. 202 As such, the notion of a permission is another key part of this 203 framework. A permission is an object, represented in XML, that 204 contains several pieces of data: 206 Identity of the Sender: A URI representing the identity of the sender 207 for whom permissions are granted. 209 Identity of the Original Recipient: A URI representing the identity 210 of the original recipient, which is used as the input for the 211 translation operation. This is also called the target URI. 213 Identity of the Final Recipient: A URI representing the result of the 214 translation. The permission grants ability for the sender to send 215 requests to the target URI, and for a relay receiving those 216 requests to forward them to this URI. This is also called the 217 recipient URI. 219 Operations Permitted: A set of specific methods or qualifiers for 220 which the permission applies. For example, the permission may 221 only grant relaying for INVITE or MESSAGE, or for MESSAGE with 222 specific MIME types. 224 Signature: A digital signature over the rest of the permission, 225 signed by an entity that can identify itself as the recipient URI. 226 The signature is not always present. 228 Permissions are installed on a resource by resource basis. That is, 229 for each target URI to which a request is sent, there is a set of 230 permissions installed for that URI. Each permission has the content 231 described above. 233 A natural format for representing permissions appears to be the 234 common policy format [3]. This format is also used for presence 235 permissions. 237 6. Single-Relay Scenario 239 This section describes the fundamental operations of this framework 240 in a single-relay scenario. The descriptions are illustrated with an 241 example (see Figure 3). 243 6.1 Attempting Communication 245 When a UA sends a request to a target resource (message 1 in Figure 246 3), the request eventually arrives at a server that is authoritative 247 for the domain in the request URI. The server may require, as part 248 of its processing logic, the relaying of the request to one or more 249 next hops. If such relaying is required, the server first 250 authenticates the sender of the request. Such authentication can be 251 done using the SIP identity mechanism [4]. Once the sender is 252 authenticated, the server checks its permission database for that 253 target resource. It looks for permissions containing senders whose 254 URI matches the identity of the sender of the request. Of those that 255 are found, the server checks to see if the permitted translated URI 256 matches the URIs to which the server wishes to relay the request. 258 If at least one of the next hops to which the server wishes to relay 259 have not been permitted, the server includes a Permission-Needed 260 header field in the response to the request (message 2 in Figure 3). 261 This Permission-Needed header field contains a list of URIs, each of 262 which identify a translation for which permissions are needed. 264 Note that each of the URIs identify a translation at the server 265 (i.e., at the relay). That is, the domain part of the URI will 266 identify the server and the user part will be meaningful only to 267 the server. 269 A Relay B 270 |(1) REQUEST school-friends@relay | 271 |-------------------------->| | 272 |(2) 470 Consent Needed | | 273 |Call-Info: 123@relay; | | 274 |purpose=wait-permission | | 275 |Permission-Needed: xyz@relay | 276 |<--------------------------| | 277 |(3) CONSENT school-friends@relay | 278 |Permission-From: xyz@relay | | 279 |-------------------------->| | 280 | |(4) CONSENT B | 281 | |Permission-Requested: uri-req 282 | |-------------------------->| 283 | |(5) 202 Accepted | 284 | |<--------------------------| 285 |(6) 202 Accepted | | 286 |<--------------------------| | 287 |(7) SUBSCRIBE 123@relay | | 288 |-------------------------->| | 289 |(8) 200 OK | | 290 |<--------------------------| | 291 |(9) NOTIFY (no permission) | | 292 |<--------------------------| | 293 |(10) 200 OK | | 294 |-------------------------->| | 295 | |(11) HTTP uri-req | 296 | |Get Requested Permission | 297 | |<--------------------------| 298 | |(12) 200 OK | 299 | |Permission Document | 300 | |URI to Upload: uri-up | 301 | |-------------------------->| 302 | |(13) PUBLISH uri-up | 303 | |Permission Document | 304 | |<--------------------------| 305 | |(14) 200 OK | 306 | |-------------------------->| 307 |(15) NOTIFY (permission) | | 308 |<--------------------------| | 309 |(16) 200 OK | | 310 |-------------------------->| | 311 |(17) REQUEST school-friends@relay | 312 |-------------------------->| | 313 | |(18) REQUEST B | 314 | |Permission-Used: uri-perm | 315 | |-------------------------->| 317 Figure 3: Basic call flow 319 The status code the server uses in its response depends on the 320 service the translation is part of. For example, a URI-list service 321 which receives a request with a list of recipient URIs may already 322 have permissions for some of them. The URI-list service may choose 323 to perform the translations which it has permissions for and return a 324 200 (OK) response with a list of URIs in a Permission-Needed header 325 field for the translations for which permissions have not yet been 326 obtained. Alternatively, the URI-list service may choose not to 327 perform any translation and to return a 470 (Consent Needed) response 328 with a list of URIs in a Permission-Needed header field for the 329 translations for which permissions have not yet been obtained. 331 The response from the server may carry a URI in a Call-Info header 332 field (wait-permission purpose) where the client can SUBSCRIBE to 333 using the wait-permission event package. This event package models 334 the state of the permission granted to the client for communicating 335 with the target URIs. When a permission is granted, the state 336 changes, and the client receives a NOTIFY. This NOTIFY contains the 337 permission(s) that have been granted for the sender. 339 OPEN ISSUE: in which response does the server include the 340 call-info header? Proposal: it can include it in any response 341 (i.e., responses to the original request and responses to the 342 CONSENTs, but it should include always the same URI. 344 Usage of an event package has the benefit that the client can come 345 back at any time and do a query SUBSCRIBE to see if permissions were 346 granted, or it can wait for them to be granted, and find out when. 347 There is no requirement that the client use this event package to 348 wait. For some requests, it may not be important for the sender to 349 find out when permission is granted (e.g., a presence subscription). 351 6.2 Requesting a Permission 353 If a server returns a response with a Permission-Needed header field, 354 the client knows that it needs to obtain some number of permissions. 355 The response will include a list of URIs in a Permission-Needed 356 header field for which permission must be obtained. To obtain 357 permission, the client generates as many CONSENT request as entries 358 the Permission-Needed header field contained. 360 Each CONSENT request (message 3 in Figure 3) is sent to the same URI 361 as the original request and carries, in a Permission-From header 362 field, one of the URIs received in the Permission-Needed header 363 field. The server will forward these CONSENT requests on to the 364 destinations whose permissions have not been obtained yet. 366 OPEN ISSUE: it was proposed having clients send CONSENTs to the 367 URIs received in the Permission-Needed header field (i.e., using 368 them in the Request-URI instead of in a Request-From header 369 field). This would require the server to store more state 370 information and come up with a number of URIs in multiple-relay 371 scenarios. 373 When the CONSENT request arrives at the server, the relay adds a 374 Permission-Requested header field which contains a URI (e.g., an HTTP 375 URI) that the receiver can use to download a description of the 376 permission being requested (e.g., an XML-based permission document). 377 Then, the server forwards the request towards its destination 378 (message 4 in Figure 3). 380 If there are several relays between the sender and the final 381 destination, those CONSENT requests may also fail if permissions have 382 not yet been obtained, in which case the process recurses, as 383 described in Section Section 8. Eventually, the client will have 384 sent a request to all of the relays at the leaves of the translation 385 tree between the sender and the final destinations. 387 6.3 Waiting for Permissions 389 A CONSENT request is responded with a 202 (Accepted) response 390 (message 5 in Figure 3). As stated earlier, if the client is 391 interested in the status of the permissions, it can SUBSCRIBE 392 (message 7 in Figure 3) to the the wait-permission event package 393 using the URI received in the Call-Info header field (wait-permission 394 purpose) of the response to the original request (responses to 395 CONSENT requests may also carry a Call-Info header field with such a 396 URI). 398 6.4 Granting a Permission 400 On reception of a CONSENT request, the user fetches the permission 401 being requested from the URI in the Permission-Requested header field 402 (message 11 in Figure 3). This permission document includes the URI 403 that the user needs to use to upload the permissions that the user 404 chooses to grant. So, if the user wishes to grant a permission, it 405 may use a SIP PUBLISH request (message 13 in Figure 3) to upload a 406 permission document into that URI. This PUBLISH request is 407 authenticated using the SIP identity mechanism. 409 OPEN ISSUE: XCAP could be useful for endpoints that support it. 410 Do we want to allow XCAP to be used? If XCAP was allowed, how do 411 we permorm authentication? Do endpoings using XCAP need to sign 412 their permissions? Relaying on the routing architecture and SIPS 413 to deliver a randomly-looking http URI to the proper endpoint does 414 not seem to be secure enough. 415 OPEN ISSUE: Using XCAP to grant permissions would require the 416 definition of a new application usage. We note that this usage 417 appears to be a generalization of the presence rules usage 418 currently defined [6]. 420 The owner of the target resource may choose to grant the permissions 421 requested or a superset of them. For example, a CONSENT request may 422 request permission to perform a given translation on MESSAGE 423 requests, and the target resource owner may grant permission to 424 perform the translation on any request (not only on MESSAGE 425 requests). 427 6.5 Retrying the Original Request 429 The sender learns about permissions through the wait-permission event 430 package. Once it has obtained permissions for all of the resources 431 that were identified in the Permission-Needed header field, the 432 client can retry the original request (message 17 in Figure 3). 434 When the server performs the translation, it adds a Permission-Used 435 header field with a URI (e.g., an HTTP URI) where the permission 436 document that authorizes the translation can be downloaded from. 438 6.6 Permission Revocation 440 At any time, if a client wants to revoke any permission, it uses the 441 same URI as before to upload a new permission document. If a client 442 loses this URI for some reason, it needs to wait until it receives a 443 new request, which will contain a Permission-Used header field. 445 The permission documents that can be downloaded from the URIs in the 446 Permission-Used header field contain a URI where the client can 447 upload a new permission document (e.g., a permission document that 448 does not allow a particular translation any longer). 450 OPEN ISSUE: is it OK to force clients to download the permission 451 document in order to obtain the SIP URI to send their PUBLISH 452 requests to or we want to already include such a URI in the 453 Permission-Used header field. 455 7. Permission Servers 457 We described in Section 6.4 how a user agent that receives a CONSENT 458 request can use a PUBLISH request to grant certain permissions. 459 Nevertheless, users are not on-line all the time and, so, sometimes 460 are not able to receive CONSENT requests. 462 This issue is also found in presence, where a user's status is 463 reported by a presence server instead of by the user's user agents, 464 which can go on and off-line. Similarly, we define permission 465 servers. Permission servers are network elements that act as SIP UAs 466 and handle CONSENT requests for a user. 468 Permission servers inform users about new CONSENT requests using the 469 "grant-permission" event package. The user associated with the 470 target URI SUBSCRIBEs (message 1 in Figure 4) to the 471 "grant-permission" event package at the permission server. This 472 event package models the state of all pending CONSENT requests for a 473 particular resource, for which permissions do not yet exist. When a 474 new CONSENT request (message 3 in Figure 4) arrives for which 475 permissions have not been granted, a NOTIFY (message 5 in Figure 4) 476 is sent to the user. This informs them that permission is needed for 477 a particular sender. The NOTIFY contains information on the 478 operation which was requested. 480 There is a strong similarity between the watcherinfo event package 481 and the grant-permission event package. Indeed, the 482 grant-permission package is effectively a superset of watcherinfo. 483 Once in place, presentities could use the grant-permission event 484 package for presence in addition to all other services for which 485 opt-in is being provided. 487 When a user is notified of a new pending CONSENT request, the user 488 follows regular procedures to upload the permissions that were 489 requested (messages 9 to 11 in Figure 4). 491 Relay B's Permission B 492 Server 493 | |(1) SUBSCRIBE | 494 | |grant-permission | 495 | |<------------------| 496 | |(2) 200 OK | 497 | |------------------>| 498 |(3) CONSENT B | | 499 |Permission-Requested: uri-req | 500 |------------------>| | 501 |(4) 202 Accepted | | 502 |<------------------| | 503 | |(5) NOTIFY | 504 | |Permission Requested: uri-req 505 | |------------------>| 506 | |(6) 200 OK | 507 | |<------------------| 508 |(7) HTTP uri-req | | 509 |Get Requested Permission | 510 |<--------------------------------------| 511 |(8) 200 OK | | 512 |Permission Document| | 513 |URI to Upload: uri-up | 514 |------------------>| | 515 |(9) PUBLISH uri-up | | 516 |Permission Document| | 517 |<--------------------------------------| 518 |(10) 200 OK | | 519 |-------------------------------------->| 521 Figure 4: Permission server operation 523 8. Multiple-Relay Scenario 525 One of the results of a translation (i.e., a recipient URI) at a 526 relay can route to another relay. In this case, there will be 527 multiple relays between the UA generating a request and the 528 destination UA or UAs. 530 8.1 Initial Steps 532 The way UAs are informed that they need to request permissions for a 533 translation and the way they request those permissions (i.e., using 534 CONSENT requests) are identical to the single-relay case. 536 In the example of Figure 5, Relay 1 handles the URI 'friends@relay1', 537 which translates to a set of URIs. Relay 1 already has permissions 538 to perform all the translations but one. Relay 1 needs to obtain 539 permission to perform the translation to 'school-friends@relay2'. 541 Relay 1 returns a 470 (Consent Needed) response (message 2 in Figure 542 5) with a Permission-Needed header field. The UA generates a CONSENT 543 request (message 2 in Figure 5) placing the URI received in that 544 header field in a Request-From header field. 546 The CONSENT request is forwarded by Relay 1 to Relay 2 (message 4 in 547 Figure 5). The URI 'school-friends@relay2' translates to a set of 548 URIs. Relay 1 already has permissions to perform all the 549 translations but one. Relay 1 needs to obtain permission to perform 550 the translation to B. 552 Relay 2 returns a 470 (Consent Needed) response (message 5 in Figure 553 5) with a Permission-Needed header field. On reception of this 554 response, Relay 1 adds the URI identifying the first translation to 555 this header field (message 6 in Figure 5). 557 The UA inserts the two URIs received in the Permission-Needed header 558 field into the Permission-From header field of a new CONSENT request 559 (message 7 in Figure 5). Relay 1 consumes the URI it added when it 560 relays the CONSENT request to Relay 2 (message 8 in Figure 5). Relay 561 2 consumes the URI it added when it relays the CONSENT request to B 562 (message 9 in Figure 5). 564 A Relay1 Relay2 B 565 |(1) REQUEST friends@relay1 | | 566 |---------------->| | | 567 |(2) 470 Consent Needed | | 568 |Call-Info: 123@relay1; | | 569 |purpose=wait-permission | | 570 |Permission-Needed: xyz@relay1 | | 571 |<----------------| | | 572 |(3) CONSENT friends@relay1 | | 573 |Permission-From: xyz@relay1 | | 574 |---------------->| | | 575 | |(4) CONSENT school-friends@relay2 | 576 | |Permission-Requested: uri-req1 | 577 | |---------------->| | 578 | |(5) 470 Consent Needed | 579 | |Call-Info:456@relay2; | 580 | |purpose=wait-permission | 581 | |Permission-Needed: abc@relay2 | 582 | |<----------------| | 583 |(6) 470 Consent Needed | | 584 |Permission-Needed: xyz@relay1;abc@relay2 | 585 |<----------------| | | 586 |(7) CONSENT friends@relay1 | | 587 |Permission-From: xyz@relay1;abc@relay2 | 588 |---------------->| | | 589 | |(8) CONSENT school-friends@relay2 | 590 | |Permission-Requested:uri-req1 | 591 | |Permission-From: abc@relay2 | 592 | |---------------->| | 593 | | |(9) CONSENT B | 594 | | |Permission-Requested: uri-req2 595 | | |---------------->| 596 | | |(10) 202 Accepted| 597 | | |<----------------| 598 | |(11) 202 Accepted| | 599 | |<----------------| | 600 |(12) 202 Accepted| | | 601 |<----------------| | | 602 |(13) SUBSCRIBE 123@relay1 | | 603 |---------------->| | | 604 |(14) 200 OK | | | 605 |<----------------| | | 606 |(15) NOTIFY (no permission) | | 607 |<----------------| | | 608 |(16) 200 OK | | | 609 |---------------->| | | 610 | | |(17) HTTP uri-req| 611 | | |Get Requested Permission 612 | | |<----------------| 613 | | |(18) 200 OK | 614 | | |Permission Document 615 | | |URI to Upload: uri-up2 616 | | |---------------->| 617 | | |(19) PUBLISH uri-up2 618 | | |Permission Document 619 | | |<----------------| 620 | | |(20) 200 OK | 621 | | |---------------->| 622 | |(21) HTTP uri-req1 | 623 | |Get Requested Permission | 624 | |<----------------| | 625 | |(22) 200 OK | | 626 | |Permission Document | 627 | |URI to Upload: uri-up1 | 628 | |---------------->| | 629 | |(23) PUBLISH uri-up1 | 630 | |Permission Document | 631 | |<----------------| | 632 | |(24) 200 OK | | 633 | |---------------->| | 634 |(25) NOTIFY (permission) | | 635 |<----------------| | | 636 |(26) 200 OK | | | 637 |---------------->| | | 638 |(27) REQUEST friends@relay1 | | 639 |---------------->| | | 640 | |(28) REQUEST school-friends@relay2 | 641 | |Permission-Used: uri-perm1 | 642 | |---------------->| | 643 | | |(29) REQUEST B | 644 | | |Permission-Used: uri-perm1 645 | | |Permission-Used: uri-perm2 646 | | |---------------->| 648 Figure 5: Multiple-relay scenario 650 8.2 Waiting for Permissions 652 In order to be informed of the status of the permissions, A 653 subscribes (message 13 in Figure 5) to the URI it received from Relay 654 1 in a Call-Info header field (message 2 in Figure 5). 656 Although Figure 5 does not show it, Relay 1 could subscribe to the 657 status of the permissions at Relay 2 using the URI it received in a 658 Call-Info header field (message 5 in Figure 5). 660 8.3 Intermediate Relays 662 At this point, A needs to upload permissions to Relay 2 and Relay 2 663 needs to upload permissions to Relay 1. Therefore, Relay 2 acts as 664 an intermediate relay between B and Relay 1. 666 The policy followed by Relay 2 in Figure 5 is not to give permissions 667 to Relay 1 to perform the translation from friends@relay1 to 668 school-friends@relay2 until B gives Relay 2 permissions to perform 669 the translation school-friends@relay2 to B. However, this is not the 670 only possible policy. Relay 2 may choose to give permissions to 671 Relay 1 before B gave Relay 2 permissions. This would probably be 672 the case if Relay 2 was a forking proxy trying to locate a user 673 registered at several UAs, one of which had not given permissions to 674 the forking proxy yet. 676 Therefore, how a relay decides when to give certain permissions to 677 other relays is based on the local policy of the relay, which will 678 generally depend on the type of service provided by the relay. 680 9. Installing Permissions in Advance 682 The previous sections described how a relay can request a target 683 resource owner to authorize a communication attempt. However, target 684 resource owners may want to authorize a particular translation in 685 advance. That is, before any communication attempt is performed. 687 To do so, the target resource owner sends a CONSENT request to the 688 target URI of the translation. This CONSENT request will trigger the 689 mechanisms described in the previous sections. The result is that 690 the target resource owner(s) will obtain a URI to upload a permission 691 document. 693 10. IANA Considerations 695 TBD. 697 11. Security Considerations 699 TBD. 701 Editor's note: we have to avoid that attackers provide permissions 702 for translations that apply to other users (e.g., allow everyone to 703 send traffic to a victim) and that attackers provide permissions for 704 a translation that apply to them but routes to a victim (e.g., 3rd 705 party registration that binds attacker@relay to victim@somewhere). 706 For the former we need authentication (e.g., SIP identity) and for 707 the latter we relay on the routing infrastructure to route CONSENTs 708 to the same place the traffic will be sent to once permissions are 709 obtained (i.e., a return routability test). 711 12. References 713 12.1 Normative References 715 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 716 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 717 Session Initiation Protocol", RFC 3261, June 2002. 719 [2] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 720 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 721 Messaging", RFC 3428, December 2002. 723 12.2 Informative References 725 [3] Schulzrinne, H., "A Document Format for Expressing Privacy 726 Preferences", draft-ietf-geopriv-common-policy-03 (work in 727 progress), October 2004. 729 [4] Peterson, J., "Enhancements for Authenticated Identity 730 Management in the Session Initiation Protocol (SIP)", 731 draft-ietf-sip-identity-03 (work in progress), September 2004. 733 [5] Rosenberg, J., "Requirements for Consent-Based Communications in 734 the Session Initiation Protocol (SIP)", 735 draft-ietf-sipping-consent-reqs-00 (work in progress), October 736 2004. 738 [6] Rosenberg, J., "Presence Authorization Rules", 739 draft-ietf-simple-presence-rules-01 (work in progress), October 740 2004. 742 [7] Camarillo, G., "Requirements and Framework for Session 743 Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List 744 Services", draft-ietf-sipping-uri-services-01 (work in 745 progress), October 2004. 747 Authors' Addresses 749 Jonathan Rosenberg 750 Cisco Systems 751 600 Lanidex Plaza 752 Parsippany, NJ 07054 753 US 755 Phone: +1 973 952-5000 756 EMail: jdrosen@cisco.com 757 URI: http://www.jdrosen.net 759 Gonzalo Camarillo 760 Ericsson 761 Hirsalantie 11 762 Jorvas 02420 763 Finland 765 EMail: Gonzalo.Camarillo@ericsson.com 767 Dean Willis 768 Cisco Systems 769 2200 E. Pres. George Bush Turnpike 770 Richardson, TX 75082 771 USA 773 EMail: dean.willis@softarmor.com 775 Intellectual Property Statement 777 The IETF takes no position regarding the validity or scope of any 778 Intellectual Property Rights or other rights that might be claimed to 779 pertain to the implementation or use of the technology described in 780 this document or the extent to which any license under such rights 781 might or might not be available; nor does it represent that it has 782 made any independent effort to identify any such rights. Information 783 on the procedures with respect to rights in RFC documents can be 784 found in BCP 78 and BCP 79. 786 Copies of IPR disclosures made to the IETF Secretariat and any 787 assurances of licenses to be made available, or the result of an 788 attempt made to obtain a general license or permission for the use of 789 such proprietary rights by implementers or users of this 790 specification can be obtained from the IETF on-line IPR repository at 791 http://www.ietf.org/ipr. 793 The IETF invites any interested party to bring to its attention any 794 copyrights, patents or patent applications, or other proprietary 795 rights that may cover technology that may be required to implement 796 this standard. Please address the information to the IETF at 797 ietf-ipr@ietf.org. 799 Disclaimer of Validity 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 804 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 805 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 806 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Copyright Statement 811 Copyright (C) The Internet Society (2005). This document is subject 812 to the rights, licenses and restrictions contained in BCP 78, and 813 except as set forth therein, the authors retain all their rights. 815 Acknowledgment 817 Funding for the RFC Editor function is currently provided by the 818 Internet Society.