idnits 2.17.1 draft-ietf-sip-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, updated by RFC 4748 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1380. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 31, 2008) is 5929 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) == Missing Reference: 'RFCxxxx' is mentioned on line 1172, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-06 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-consent-format-03 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-pending-additions-02 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-08 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 Intended status: Standards Track G. Camarillo, Ed. 5 Expires: August 3, 2008 Ericsson 6 D. Willis 7 Unaffiliated 8 January 31, 2008 10 A Framework for Consent-based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sip-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 3, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 The Session Initiation Protocol (SIP) supports communications for 46 several services, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4 59 3. Relays and Translations . . . . . . . . . . . . . . . . . . . 5 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 7 62 4.2. Consenting Manipulations on a Relay's Transaction Logic . 8 63 4.3. Store-and-forward Servers . . . . . . . . . . . . . . . . 9 64 4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 10 65 4.5. Entities Implementing this Framework . . . . . . . . . . . 10 66 5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 11 67 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 12 68 5.1.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13 69 5.2. Subscription to the Permission Status . . . . . . . . . . 13 70 5.2.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 14 71 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 14 72 5.3.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 14 73 5.4. Permission Document Structure . . . . . . . . . . . . . . 16 74 5.5. Permission Requested Notification . . . . . . . . . . . . 17 75 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 18 76 5.6.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 18 77 5.7. Permission Granted Notification . . . . . . . . . . . . . 20 78 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 20 79 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 21 80 5.9.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 22 81 5.9.2. Definition of the 470 Response Code . . . . . . . . . 22 82 5.9.3. Definition of the Permission-Missing Header Field . . 23 83 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 23 84 5.11. Relays Generating Traffic towards Recipients . . . . . . . 26 85 5.11.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 26 86 5.11.2. Definition of the Trigger-Consent Header Field . . . . 26 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 6.1. Registration of the 470 Response Code . . . . . . . . . . 27 89 6.2. Registration of the Trigger-Consent Header Field . . . . . 27 90 6.3. Registration of the Permission-Missing Header Field . . . 27 91 6.4. Registration of the target-uri Header Field Parameter . . 28 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 98 Intellectual Property and Copyright Statements . . . . . . . . . . 32 100 1. Introduction 102 The Session Initiation Protocol (SIP) [RFC3261] supports 103 communications for several services, including, real-time audio, 104 video, text, instant messaging, and presence. This communication is 105 established by the transmission of various SIP requests (such as 106 INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with 107 whom communication is desired. Although a recipient of such a SIP 108 request can reject the request, and therefore decline the session, a 109 network of SIP proxy servers will deliver a SIP request to its 110 recipients without their explicit consent. 112 Receipt of these requests without explicit consent can cause a number 113 of problems. These include amplification and DoS (Denial of Service) 114 attacks. These problems are described in more detail in a companion 115 requirements document [RFC4453]. 117 This specification defines a basic framework for adding consent-based 118 communication to SIP. 120 2. Definitions and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 Recipient URI: The Request-URI of an outgoing request sent by an 127 entity (e.g., a user agent or a proxy). The sending of such 128 request can have been the result of a translation operation. 130 Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User 131 Agent), or some hybrid, that receives a request, translates its 132 Request-URI into one or more next-hop URIs (i.e., recipient URIs), 133 and delivers the request to those URIs. 135 Target URI: The Request-URI of an incoming request that arrives to a 136 relay that will perform a translation operation. 138 Translation logic: The logic that defines a translation operation at 139 a relay. This logic includes the translation's target and 140 recipient URIs. 142 Translation operation: Operation by which a relay translates the 143 Request-URI of an incoming request (i.e., the target URI) into one 144 or more URIs (i.e., recipient URIs) which are used as the Request- 145 URIs of one or more outgoing requests. 147 3. Relays and Translations 149 Relays play a key role in this framework. A relay is defined as any 150 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 151 hybrid, which receives a request, translates its Request-URI into one 152 or more next hop URIs, and delivers the request to those URIs. The 153 Request-URI of the incoming request is referred to as 'target URI' 154 and the destination URIs of the outgoing requests are referred to as 155 'recipient URIs', as shown in Figure 1. 157 +---------------+ recipient URI 158 | |----------------> 159 | | 160 target URI | Translation | [...] 161 -------------->| Operation | 162 | | recipient URI 163 | |----------------> 164 +---------------+ 166 Figure 1: Translation operation 168 Thus, an essential aspect of a relay is that of translation. When a 169 relay receives a request, it translates the Request-URI (target URI) 170 into one or more additional URIs (recipient URIs). Through this 171 translation operation, the relay can create outgoing requests to one 172 or more additional recipient URIs, thus creating the consent problem. 174 The consent problem is created by two types of translations: 175 translations based on local data and translations that involve 176 amplifications. 178 Translation operations based on local policy or local data (such as 179 registrations) are the vehicle by which a request is delivered 180 directly to an endpoint, when it would not otherwise be possible to. 181 In other words, if a spammer has the address of a user, 182 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA 183 (User Agent) of that user without having access to the registration 184 data that maps 'sip:user@example.com' to the user agent on which that 185 user is present. Thus, it is the usage of this registration data, 186 and more generally, the translation logic, which is expected to be 187 authorized in order to prevent undesired communications. Of course, 188 if the spammer knows the address of the user agent, it will be able 189 to deliver requests directly to it. 191 Translation operations that result in more than one recipient URI are 192 a source of amplification. Servers that do not perform translations, 193 such as outbound proxy servers, do not cause amplification. On the 194 other hand, servers that perform translations (e.g., inbound proxies 195 authoritatively responsible for a SIP domain) may cause amplification 196 if the user can be reached at multiple endpoints (thereby resulting 197 in multiple recipient URIs.) 199 Figure 2 shows a relay that performs translations. The user agent 200 client in the figure sends a SIP request to a URI representing a 201 resource in the domain 'example.com' (sip:resource@example.com). 202 This request can pass through a local outbound proxy (not shown), but 203 eventually arrives at a server authoritative for the domain 204 'example.com'. This server, which acts as a relay, performs a 205 translation operation, translating the target URI into one or more 206 recipient URIs, which can but need not belong to the domain 207 'example.com'. This relay can be, for instance, a proxy server or a 208 URI-list service [I-D.ietf-sipping-uri-services]. 210 +-------+ 211 | | 212 >| UA | 213 / | | 214 / +-------+ 215 / 216 / 217 +-----------------------+ / 218 | | / 219 +-----+ | Relay | / +-------+ 220 | | | |/ | | 221 | UA |------>| |-------->| Proxy | 222 | | |+---------------------+|\ | | 223 +-----+ || Translation || \ +-------+ 224 || Logic || \ 225 |+---------------------+| \ [...] 226 +-----------------------+ \ 227 \ 228 \ +-------+ 229 \ | | 230 >| B2BUA | 231 | | 232 +-------+ 234 Figure 2: Relay performing a translation 236 This framework allows potential recipients of a translation to agree 237 to be actual recipients by giving the relay performing the 238 translation permission to send them traffic. 240 4. Architecture 242 Figure 3 shows the architectural elements of this framework. The 243 manipulation of a relay's translation logic typically causes the 244 relay to send a permission request, which in turn causes the 245 recipient to grant or deny the relay permissions for the translation. 246 Section 4.1 describes the role of permissions at a relay. 247 Section 4.2 discusses the actions taken by a relay when its 248 translation logic is manipulated by a client. Section 4.3 discusses 249 store-and-forward servers and their functionality. Section 4.4 250 describes how potential recipients can grant a relay permissions to 251 add them to the relay's translation logic. Section 4.5 discusses 252 which entities need to implement this framework. 254 +-----------------------+ Permission +-------------+ 255 | | Request | | 256 +--------+ | Relay |----------->| Store & Fwd | 257 | | | | | Server | 258 | Client | | | | | 259 | | |+-------+ +-----------+| +-------------+ 260 +--------+ ||Transl.| |Permissions|| | 261 | ||Logic | | || Permission | 262 | |+-------+ +-----------+| Request | 263 | +-----------------------+ V 264 | ^ ^ +-------------+ 265 | Manipulation | | Permission Grant | | 266 +---------------+ +-------------------| Recipient | 267 | | 268 +-------------+ 270 Figure 3: Reference Architecture 272 4.1. Permissions at a Relay 274 Relays implementing this framework obtain and store permissions 275 associated to their translation logic. These permissions indicate if 276 a particular recipient has agreed to receive traffic or not at any 277 given time. Recipients that have not given the relay permission to 278 send them traffic are simply ignored by the relay when performing a 279 translation. 281 In principle, permissions are valid as long as the context where they 282 were granted is valid or until they are revoked. For example, the 283 permissions obtained by a URI-list SIP service that distributes 284 MESSAGE requests to a set of recipients will be valid as long as the 285 URI-list SIP service exists or until the permissions are revoked. 287 Additionally, if a recipient is removed from a relay's translation 288 logic, the relay SHOULD delete the permissions related to that 289 recipient. For example, if the registration of a contact URI expires 290 or is otherwise terminated, the registrar deletes the permissions 291 related to that contact address. 293 It is also RECOMMENDED that relays request recipients to refresh 294 their permissions periodically. If a recipient fails to refresh its 295 permissions for a given period of time, the relay SHOULD delete the 296 permissions related to that recipient. 298 This framework does not provide any guidance for the values of the 299 refreshment intervals because different applications can have 300 different requirements to set those values. For example, a relay 301 dealing with recipients that do not implement this framework may 302 choose to use longer intervals between refreshes. The refresh 303 process in such recipients has to be performed manually by their 304 users (since the recipients do not implement this framework) and 305 having too short refresh intervals may become too heavy a burden 306 for those users. 308 4.2. Consenting Manipulations on a Relay's Transaction Logic 310 This framework aims to ensure that any particular relay only performs 311 translations towards destinations that have given the relay 312 permission to perform such a translation. Consequently, when the 313 translation logic of a relay is manipulated (e.g., a new recipient 314 URI is added), the relay obtains permission from the new recipient in 315 order to install the new translation logic. Relays ask recipients 316 for permission using MESSAGE [RFC3428] requests. 318 For example, the relay hosting the URI-list service at 319 'sip:friends@example.com' performs a translation from that target URI 320 to a set of recipient URIs. When a client (e.g., the administrator 321 of that URI-list service) adds 'bob@example.org' as a new recipient 322 URI, the relay sends a MESSAGE request to 'sip:bob@example.org' 323 asking whether or not it is OK to perform the translation from 324 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE 325 request carries in its message body a permission document that 326 describes the translation for which permissions are being requested 327 and a human readable part that also describes the translation. If 328 the answer is positive, the new translation logic is installed at the 329 relay. That is, the new recipient URI is added. 331 The human-readable part is included so that user agents that do 332 not understand permission documents can still process the request 333 and display it in a sensible way to the user. 335 The mechanism to be used to manipulate the translation logic of a 336 particular relay depends on the relay. Two existing mechanisms to 337 manipulate translation logic are XCAP [RFC4825] and REGISTER 338 transactions. 340 Section 5 uses a URI-list service whose translation logic is 341 manipulated with XCAP as an example of a translation in order to 342 specify this framework. Section 5.10 discusses how to apply this 343 framework to registrations, which are a different type of 344 translation. 346 In any case, relays implementing this framework SHOULD have a means 347 to indicate that a particular recipient URI is in the states 348 specified in [I-D.ietf-sipping-pending-additions] (i.e., pending, 349 waiting, error, denied, or granted). 351 4.3. Store-and-forward Servers 353 When a MESSAGE request with a permission document arrives to the 354 recipient URI to which it was sent by the relay, the receiving user 355 can grant or deny the permission needed to perform the translation. 356 However, the receiving user may not be available when the MESSAGE 357 request arrives, or it may have expressed preferences to block all 358 incoming requests for a certain time period. In such cases, a store- 359 and-forward server can act as a substitute for the user and buffer 360 the incoming MESSAGE requests, which are subsequently delivered to 361 the user when he or she is available again. 363 There are several mechanisms to implement store-and-forward message 364 services (e.g., with an instant message to email gateway). Any of 365 these mechanisms can be used between a user agent and its store-and- 366 forward server as long as they agree on which mechanism to use. 367 Therefore, this framework does not make any provision for the 368 interface between user agents and their store-and-forward servers. 370 Note that the same store-and-forward message service can handle 371 all incoming MESSAGE requests for a user while this is off line, 372 not only those MESSAGE requests with a permission document in 373 their bodies. 375 Even though store-and-forward servers perform a useful function and 376 they are expected to be deployed in most domains, some domains will 377 not deploy them from the outset. However, user agents and relays in 378 domains without store-and-forward servers can still use this consent 379 framework. 381 When a relay requests permissions from an off-line user agent that 382 does not have an associated store-and-forward server, the relay will 383 obtain an error response indicating that its MESSAGE request could 384 not be delivered. The client that attempted to add the off-line user 385 to the relay's translation logic will be notified about the error 386 (e.g., using the Pending Additions event package 387 [I-D.ietf-sipping-pending-additions]). This client MAY attempt to 388 add the same user at a later point, hopefully when the user is on- 389 line. Clients can discover whether or not a user is on-line by using 390 a presence service, for instance. 392 4.4. Recipients Grant Permissions 394 Permission documents generated by a relay include URIs that can be 395 used by the recipient of the document to grant or deny the relay the 396 permission described in the document. Relays always include SIP URIs 397 and can include HTTP [RFC2616] URIs for this purpose. Consequently, 398 recipients provide relays with permissions using SIP PUBLISH requests 399 or HTTP GET requests. 401 4.5. Entities Implementing this Framework 403 The goal of this framework is to keep relays from executing 404 translations towards unwilling recipients. Therefore, all relays 405 MUST implement this framework in order to avoid being used to perform 406 attacks (e.g., amplification attacks). 408 This framework has been designed with backwards compatibility in mind 409 so that legacy user agents (i.e., user agents that do not implement 410 this framework) can act both as clients and recipients with an 411 acceptable level of functionality. However, it is RECOMMENDED that 412 user agents implement this framework, which includes supporting the 413 Pending Additions event package specified in 414 [I-D.ietf-sipping-pending-additions], the format for permission 415 documents specified in [I-D.ietf-sipping-consent-format], and the 416 header fields and response code specified in this document, in order 417 to achieve full functionality. 419 The only requirement that this framework places on store-and-forward 420 servers is that they need to be able to deliver encrypted and 421 integrity-protected messages to their user agents, as discussed in 422 Section 7. However, this is not a requirement specific to this 423 framework but a general requirement for store-and-forward servers. 425 5. Framework Operations 427 This section specifies this consent framework using an example of the 428 prototypical call flow. The elements described in Section 4 (i.e., 429 relays, translations, and store-and-forward servers) play an 430 essential role in this call flow. 432 Figure 4 shows the complete process to add a recipient URI 433 ('sip:B@example.com') to the translation logic of a relay. User A 434 attempts to add 'sip:B@example.com' as a new recipient URI to the 435 translation logic of the relay (1). User A uses XCAP [RFC4825] and 436 the XML (Extensible Markup Language) format for representing resource 437 lists [RFC4826] to perform this addition. Since the relay does not 438 have permission from 'sip:B@example.com' to perform translations 439 towards that URI, the relay places 'sip:B@example.com' in the pending 440 state, as specified in [I-D.ietf-sipping-pending-additions]. 442 A@example.com Relay B's Store & Fwd B@example.com 443 Server 445 |(1) Add Recipient | | 446 | sip:B@example.com | | 447 |--------------->| | | 448 |(2) HTTP 202 (Accepted) | | 449 |<---------------| | | 450 | |(3) MESSAGE sip:B@example | 451 | | Permission Document | 452 | |--------------->| | 453 | |(4) 202 Accepted| | 454 | |<---------------| | 455 |(5) SUBSCRIBE | | | 456 | Event: pending-additions | | 457 |--------------->| | | 458 |(6) 200 OK | | | 459 |<---------------| | | 460 |(7) NOTIFY | | | 461 |<---------------| | | 462 |(8) 200 OK | | | 463 |--------------->| | | 464 | | | |User B goes 465 | | | | on line 466 | | |(9) Request for | 467 | | | stored messages 468 | | |<---------------| 469 | | |(10) Delivery of| 470 | | | stored messages 471 | | |--------------->| 472 | |(11) PUBLISH uri-up | 473 | |<--------------------------------| 474 | |(12) 200 OK | | 475 | |-------------------------------->| 476 |(13) NOTIFY | | | 477 |<---------------| | | 478 |(14) 200 OK | | | 479 |--------------->| | | 481 Figure 4: Prototypical call flow 483 5.1. Amplification Avoidance 485 Once 'sip:B@example.com' is in the pending state, the relay needs to 486 ask user B for permission by sending a MESSAGE request to 487 'sip:B@example.com'. However, the relay needs to ensure that it is 488 not used as an amplifier to launch amplification attacks. 490 In such an attack, the attacker would add a large number of recipient 491 URIs to the translation logic of a relay. The relay would then send 492 a MESSAGE request to each of those recipient URIs. The bandwidth 493 generated by the relay would be much higher than the bandwidth used 494 by the attacker to add those recipient URIs to the translation logic 495 of the relay. 497 This framework uses a credit-based authorization mechanism to avoid 498 the attack just described. It requires users adding new recipient 499 URIs to a translation to generate an amount of bandwidth that is 500 comparable to the bandwidth the relay will generate when sending 501 MESSAGE requests towards those recipient URIs. When XCAP is used, 502 this requirement is met by not allowing clients to add more than one 503 URI per HTTP transaction. When a REGISTER transaction is used, this 504 requirement is met by not allowing clients to register more than one 505 contact per REGISTER transaction. 507 5.1.1. Relay's Behavior 509 Relays implementing this framework MUST NOT allow clients to add more 510 than one recipient URI per transaction. If a client using XCAP 511 attempts to add more than one recipient URI in a single HTTP 512 transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) 513 response. The XCAP server SHOULD describe the reason for the refusal 514 in an XML body using the element, as described 515 in [RFC4825]. If a client attempts to register more than one contact 516 in a single REGISTER transaction, the registrar SHOULD return a SIP 517 403 response and explain the reason for the refusal in its reason 518 phrase (e.g., Maximum one contact per registration). 520 5.2. Subscription to the Permission Status 522 Clients need a way to be informed about the status of the operations 523 they requested. Otherwise, users can be waiting for an operation to 524 succeed when it has actually already failed. In particular, if the 525 target of the request for consent was not reachable and did not have 526 an associated store-and-forward server, the client needs to know to 527 retry the request later. The Pending Additions SIP event package 528 [I-D.ietf-sipping-pending-additions] is a way to provide clients with 529 that information. 531 Clients can use the Pending Additions SIP event package to be 532 informed about the status of the operations they requested. That is, 533 the client will be informed when an operation (e.g., the addition of 534 a recipient URI to a relay's translation logic) is authorized (and 535 thus executed) or rejected. Clients use the target URI of the SIP 536 translation being manipulated to subscribe to the 'pending-additions' 537 event package. 539 In our example, after receiving the response from the relay (2), user 540 A subscribes to the Pending Additions event package at the relay (5). 541 This subscription keeps user A informed about the status of the 542 permissions (e.g., granted or denied) the relay will obtain. 544 5.2.1. Relay's Behavior 546 Relays SHOULD support the Pending Additions SIP event package 547 specified in [I-D.ietf-sipping-pending-additions]. 549 5.3. Request for Permission 551 A relay requests permissions from potential recipients to add them to 552 its translation logic using MESSAGE requests. In our example, on 553 receiving the request to add User B to the translation logic of the 554 relay (1), the relay generates a MESSAGE request (3) towards 555 'sip:B@example.com'. This MESSAGE request carries a permission 556 document, which describes the translation that needs to be authorized 557 and carries a set of URIs to be used by the recipient to grant or to 558 deny the relay permission to perform that translation. Since User B 559 is off line, the MESSAGE request will be buffered by User B's store- 560 and-forward server. User B will later go on line and authorize the 561 translation by using one of those URIs, as described in Section 5.6. 562 The MESSAGE request also carries a body part that contains the same 563 information as the permission document but in a human-readable 564 format. 566 When User B uses one of the URIs in the permission document to grant 567 or deny permissions, the relay needs to make sure that it was 568 actually User B the one using that URI, and not an attacker. The 569 relay can use any of the methods described in Section 5.6 to 570 authenticate the permission document. 572 5.3.1. Relay's Behavior 574 Relays that implement this framework MUST obtain permissions from 575 potential recipients before adding them to their translation logic. 576 Relays request permissions from potential recipients using MESSAGE 577 requests. 579 Section 5.6 describes the methods a relay can use to authenticate 580 recipients giving the relay permission to perform a particular 581 translation. These methods are SIP identity [RFC4474], P-Asserted- 582 Identity [RFC3325], a return routability test, or SIP digest. Relays 583 that use the method consisting of a return routability test have to 584 send their MESSAGE requests to a SIPS URI, as specified in 585 Section 5.6. 587 MESSAGE requests sent to request permissions MUST include a 588 permission document and SHOULD include a human-readable part in their 589 bodies. The human-readable part contains the same information as the 590 permission document (but in a human-readable format), including the 591 URIs to grant and deny permissions. User agents that do not 592 understand permission documents can still process the request and 593 display it in a sensible way to the user, as they would display any 594 other instant message. This way, even if the user agent does not 595 implement this framework, the (human) user will be able to manually 596 click on the correct URI in order to grant or deny permissions. The 597 following is an example of a MESSAGE request that carries a human- 598 readable part and a permission document, which follows the format 599 specified in [I-D.ietf-sipping-consent-format], in its body. Not all 600 header fields are shown for simplicity reasons. 602 MESSAGE sip:bob@example.org SIP/2.0 603 From: ;tag=12345678 604 To: 605 Content-Type: multipart/mixed;boundary="boundary1" 607 --boundary1 608 Content-Type: text/plain 610 If you consent to receive traffic sent to 611 , please use one of the following 612 URIs: or 613 . Otherwise, use one of 614 the following URIs: or 615 . 616 --boundary1 617 Content-Type: application/auth-policy+xml 619 620 624 625 626 627 628 629 630 631 632 633 635 636 637 638 640 grant 641 643 grant 644 646 deny 647 649 deny 650 651 652 653 654 --boundary1-- 656 5.4. Permission Document Structure 658 A permission document is the representation (e.g., encoded in XML) of 659 a permission. A permission document contains several pieces of data: 661 Identity of the Sender: A URI representing the identity of the 662 sender for whom permissions are granted. 664 Identity of the Original Recipient: A URI representing the identity 665 of the original recipient, which is used as the input for the 666 translation operation. This is also called the target URI. 668 Identity of the Final Recipient: A URI representing the result of 669 the translation. The permission grants ability for the sender to 670 send requests to the target URI, and for a relay receiving those 671 requests to forward them to this URI. This is also called the 672 recipient URI. 674 URIs to Grant Permission: URIs that recipients can use to grant the 675 relay permission to perform the translation described in the 676 document. Relays MUST support the use of SIP and SIPS URIs in 677 permission documents and MAY support the use of HTTP and HTTPS 678 URIs. 680 URIs to Deny Permission: URIs that recipients can use to deny the 681 relay permission to perform the translation described in the 682 document. Relays MUST support the use of SIP and SIPS URIs in 683 permission documents and MAY support the use of HTTP and HTTPS 684 URIs. 686 Permission documents can contain wildcards. For example, a 687 permission document can request permission for any relay to forward 688 requests coming from a particular sender to a particular recipient. 689 Such a permission document would apply to any target URI. That is, 690 the field containing the identity of the original recipient would 691 match any URI. However, the recipient URI MUST NOT be wildcarded. 693 Entities implementing this framework MUST support the format for 694 permission documents defined in [I-D.ietf-sipping-consent-format] and 695 MAY support other formats. 697 In our example, the permission document in the MESSAGE request (3) 698 sent by the relay contains the following values: 700 Identity of the Sender: Any sender 702 Identity of the Original Recipient: sip:friends@example.com 704 Identity of the Final Recipient: sip:B@example.com 706 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 708 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 710 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 712 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 714 It is expected that the Sender field often contains a wildcard. 715 However, scenarios involving request-contained URI lists, such as the 716 one described in Section 5.9, can require permission documents that 717 apply to a specific sender. In cases where the identity of the 718 sender matters, relays MUST authenticate senders. 720 5.5. Permission Requested Notification 722 On receiving the MESSAGE request (3), User B's store-and-forward 723 server stores it because User B is off line at that point. When User 724 B goes on line, User B fetches all the requests its store-and-forward 725 server has stored (9). 727 5.6. Permission Grant 729 A recipient gives a relay permission to execute the translation 730 described in a permission document by sending a SIP PUBLISH or an 731 HTTP GET request to one of the URIs to grant permissions contained in 732 the document. Similarly, a recipient denies a relay permission to 733 execute the translation described in a permission document by sending 734 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 735 permissions contained in the document. Requests to grant or deny 736 permissions contain an empty body. 738 In our example, User B obtains the permission document (10) that was 739 received earlier by its store-and-forward server in the MESSAGE 740 request (3). User B authorizes the translation described in the 741 permission document received by sending a PUBLISH request (11) to the 742 SIP URI to grant permissions contained in the permission document. 744 5.6.1. Relay's Behavior 746 Relays MUST ensure that the SIP PUBLISH or the HTTP GET request 747 received was generated by the recipient of the translation and not by 748 an attacker. Relays can use four methods to authenticate those 749 requests. SIP identity, P-Asserted-Identity [RFC3325], a return 750 routability test, or SIP digest. While return routability tests can 751 be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP 752 identity, P-Asserted-Identity, and SIP digest can only be used to 753 authenticate SIP PUBLISH requests. SIP digest can only be used to 754 authenticate recipients that share a secret with the relay (e.g., 755 recipients that are in the same domain as the relay). 757 5.6.1.1. SIP Identity 759 The SIP identity [RFC4474] mechanism can be used to authenticate the 760 sender of a PUBLISH request. The relay MUST check that the 761 originator of the PUBLISH request is the owner of the recipient URI 762 in the permission document. Otherwise, the PUBLISH request SHOULD be 763 responded with a 401 (Unauthorized) response and MUST NOT be 764 processed further. 766 5.6.1.2. P-Asserted-Identity 768 The P-Asserted-Identity [RFC3325] mechanism can also be used to 769 authenticate the sender of a PUBLISH request. However, as discussed 770 in [RFC3325], this mechanism is intended to be used only within 771 networks of trusted SIP servers. That is, the use of this mechanism 772 is only applicable inside an administrative domain with previously 773 agreed-upon policies. 775 The relay MUST check that the originator of the PUBLISH request is 776 the owner of the recipient URI in the permission document. 777 Otherwise, the PUBLISH request SHOULD be responded with a 401 778 (Unauthorized) response and MUST NOT be processed further. 780 5.6.1.3. Return Routability 782 SIP identity provides a good authentication mechanism for incoming 783 PUBLISH requests. Nevertheless, SIP identity is not widely available 784 on the public Internet yet. That is why an authentication mechanism 785 that can already be used at this point is needed. 787 Return routability tests do not provide the same level of security as 788 SIP identity, but they provide a better-than-nothing security level 789 in architectures where the SIP identity mechanism is not available 790 (e.g., the current Internet). The relay generates an unguessable URI 791 (i.e., with a cryptographically random user part) and places it in 792 the permission document in the MESSAGE request (3). The recipient 793 needs to send a SIP PUBLISH request or an HTTP GET request to that 794 URI. Any incoming request sent to that URI SHOULD be considered 795 authenticated by the relay. 797 Note that the return routability method is the only one that 798 allows the use of HTTP URIs in permission documents. The other 799 methods require the use of SIP URIs. 801 Relays using a return routability test to perform this authentication 802 MUST send the MESSAGE request with the permission document to a SIPS 803 URI. This ensures that attackers do not get access to the 804 (unguessable) URI. Thus, the only user able to use the (unguessable) 805 URI is the receiver of the MESSAGE request. Similarly, permission 806 documents sent by relays using a return routability test MUST only 807 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 808 permissions. A part of these URIs (e.g., the user part of a SIPS 809 URI) MUST be cryptographically random with at least 32 bits of 810 randomness. 812 Relays can transition from return routability tests to SIP identity 813 by simply requiring the use of SIP identity for incoming PUBLISH 814 requests. That is, such a relay would reject PUBLISH requests that 815 did not use SIP identity. 817 5.6.1.4. SIP Digest 819 The SIP digest mechanism can be used to authenticate the sender of a 820 PUBLISH request as long as that sender shares a secret with the 821 relay. The relay MUST check that the originator of the PUBLISH 822 request is the owner of the recipient URI in the permission document. 824 Otherwise, the PUBLISH request SHOULD be responded with a 401 825 (Unauthorized) response and MUST NOT be processed further. 827 5.7. Permission Granted Notification 829 On receiving the PUBLISH request (11), the relay sends a NOTIFY 830 request (13) to inform user A that the permission for the translation 831 has been received and that the translation logic at the relay has 832 been updated. That is, 'sip:B@example.com' has been added as a 833 recipient URI. 835 5.8. Permission Revocation 837 At any time, if a recipient wants to revoke any permission, it uses 838 the URI it received in the permission document to deny the 839 permissions it previously granted. If a recipient loses this URI for 840 some reason, it needs to wait until it receives a new request 841 produced by the translation. Such a request will contain a Trigger- 842 Consent header field with a URI. That Trigger-Consent header field 843 will have a target-uri header field parameter identifying the target 844 URI of the translation. The recipient needs to send a PUBLISH 845 request with an empty body to the URI in the Trigger-Consent header 846 field in order to receive a MESSAGE request from the relay. Such a 847 MESSAGE request will contain a permission document with a URI to 848 revoke the permission that was previously granted. 850 Figure 5 shows an example of how a user that lost the URI to revoke 851 permissions at a relay can obtain a new URI using the Trigger-Consent 852 header field of an incoming request. The user rejects an incoming 853 INVITE (1) request, which contains a Trigger-Consent header field. 854 Using the URI in the that header field, the user sends a PUBLISH 855 request (4) to the relay. On receiving the PUBLISH request (4), the 856 relay generates a MESSAGE request (6) towards the user. Finally, the 857 user revokes the permissions by sending a PUBLISH request (8) to the 858 relay. 860 Relay B@example.com 861 |(1) INVITE | 862 | Trigger-Consent: sip:123@relay.example.com 863 | ;target-uri="sip:friends@relay.example.com" 864 |---------------------------->| 865 |(2) 603 Decline | 866 |<----------------------------| 867 |(3) ACK | 868 |---------------------------->| 869 |(4) PUBLISH sip:123@relay.example.com 870 |<----------------------------| 871 |(5) 200 OK | 872 |---------------------------->| 873 |(6) MESSAGE sip:B@example | 874 | Permission Document | 875 |---------------------------->| 876 |(7) 200 OK | 877 |<----------------------------| 878 |(8) PUBLISH uri-deny | 879 |<----------------------------| 880 |(9) 200 OK | 881 |---------------------------->| 883 Figure 5: Permission Revocation 885 5.9. Request-contained URI Lists 887 In the scenarios described so far, a user adds recipient URIs to the 888 translation logic of a relay. However, the relay does not perform 889 translations towards those recipient URIs until permissions are 890 obtained. 892 URI-list services using request-contained URI lists are a special 893 case because the selection of recipient URIs is performed at the same 894 time as the communication attempt. A user places a set of recipient 895 URIs in a request and sends it to a relay so that the relay sends a 896 similar request to all those recipient URIs. 898 Relays implementing this consent framework and providing request- 899 contained URI-list services behave in a slightly different way than 900 the relays described so far. This type of relay also maintains a 901 list of recipient URIs for which permissions have been received. 902 Clients also manipulate this list using a manipulation mechanism 903 (e.g., XCAP). Nevertheless, this list does not represent the 904 recipient URIs of every translation performed by the relay. This 905 list just represents all the recipient URIs for which permissions 906 have been received. That is, the set of URIs that will be accepted 907 if a request containing a URI-list arrives to the relay. This set of 908 URIs is a super set of the recipient URIs of any particular 909 translation the relay performs. 911 5.9.1. Relay's Behavior 913 On receiving a request-contained URI-list, the relay checks whether 914 or not it has permissions for all the URIs contained in the incoming 915 URI-list. If it does, the relay performs the translation. If it 916 lacks permissions for one of more URIs, the relay MUST NOT perform 917 the translation and SHOULD return an error response. 919 A relay that receives a request-contained URI-list with a URI for 920 which the relay has no permissions SHOULD return a 470 (Consent 921 Needed) response. The relay SHOULD add a Permission-Missing header 922 field with the URIs for which the relay has no permissions. 924 Figure 6 shows a relay that receives a request (1) that contains URIs 925 for which the relay does not have permission (the INVITE carries the 926 recipient URIs in its message body). The relay rejects the request 927 with a 470 (Consent Needed) response (2). That response contains a 928 Permission-Missing header field with the URIs for which there was no 929 permission. 931 A@example.com Relay 933 |(1) INVITE | 934 | sip:B@example.com | 935 | sip:C@example.com | 936 |---------------------->| 937 |(2) 470 Consent Needed | 938 | Permission-Missing: sip:C@example.com 939 |<----------------------| 940 |(3) ACK | 941 |---------------------->| 943 Figure 6: INVITE with a URI list in its body 945 5.9.2. Definition of the 470 Response Code 947 A 470 (Consent Needed) response indicates that the request that 948 triggered the response contained a URI-list with at least a URI for 949 which the relay had no permissions. A user agent server generating a 950 470 (Consent Needed) response SHOULD include a Permission-Missing 951 header field in it. This header field carries the URI or URIs for 952 which the relay had no permissions. 954 A user agent client receiving a 470 (Consent Needed) response without 955 a Permission-Missing header field needs to use an alternative 956 mechanism (e.g., XCAP) to discover for which URI or URIs there were 957 no permissions. 959 A client receiving a 470 (Consent Needed) response uses a 960 manipulation mechanism (e.g., XCAP) to add those URIs to the relay's 961 list of URIs. The relay will obtain permissions for those URIs as 962 usual. 964 5.9.3. Definition of the Permission-Missing Header Field 966 Permission-Missing header fields carry URIs for which a relay did not 967 have permissions. The following is the augmented Backus-Naur Form 968 (BNF) [RFC4234] syntax of the Permission-Missing header field. Some 969 of its elements are defined in [RFC3261]. 971 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 972 *( COMMA per-miss-spec ) 973 per-miss-spec = ( name-addr / addr-spec ) 974 *( SEMI generic-param ) 976 The following is an example of a Permission-Missing header field: 978 Permission-Missing: sip:C@example.com 980 5.10. Registrations 982 Even though the example used to specify this framework has been a 983 URI-list service, this framework applies to any type of translation 984 (i.e., not only to URI-list services). Registrations are a different 985 type of translations that deserve discussion. 987 Registrations are a special type of translations. The user 988 registering has a trust relationship with the registrar in its home 989 domain. This is not the case when a user gives any type of 990 permissions to a relay in a different domain. 992 Traditionally, REGISTER transactions have performed two operations at 993 the same time: setting up a translation and authorizing the use of 994 that translation. For example, a user registering its current 995 contact URI is giving permission to the registrar to forward traffic 996 sent to the user's AoR (Address of Records) to the registered contact 997 URI. This works fine when the entity registering is the same as the 998 one that will be receiving traffic at a later point (e.g., the entity 999 receives traffic over the same connection used for the registration 1000 as described in [I-D.ietf-sip-outbound]). However, this schema 1001 creates some potential attacks which relate to third-party 1002 registrations. 1004 An attacker binds, via a registration, his or her AoR with the 1005 contact URI of a victim. Now, the victim will receive unsolicited 1006 traffic that was originally addressed to the attacker. 1008 The process of authorizing a registration is shown in Figure 7. User 1009 A performs a third-party registration (1) and receives a 202 1010 (Accepted) response (2). 1012 Since the relay does not have permission from 1013 'sip:a@ws123.example.com' to perform translations towards that 1014 recipient URI, the relay places 'sip:a@ws123.example.com' in the 1015 'pending' state. Once 'sip:a@ws123.example.com' is in the 1016 'Permission Pending' state, the registrar needs to ask 1017 'sip:a@ws123.example.com' for permission by sending a MESSAGE request 1018 (3). 1020 After receiving the response from the relay (2), user A subscribes to 1021 the Pending Additions event package at the registrar (5). This 1022 subscription keeps the user informed about the status of the 1023 permissions (e.g., granted or denied) the registrar will obtain. The 1024 rest of the process is similar to the one described in Section 5. 1026 A@example.com Registrar a@ws123.example.com 1028 |(1) REGISTER | | 1029 | Contact: sip:a@ws123.example.com | 1030 |------------------>| | 1031 |(2) 202 Accepted OK| | 1032 |<------------------| | 1033 | |(3) MESSAGE sip:a@ws123.example 1034 | | Permission Document 1035 | |------------------>| 1036 | |(4) 200 OK | 1037 | |<------------------| 1038 |(5) SUBSCRIBE | | 1039 | Event: pending-additions | 1040 |------------------>| | 1041 |(6) 200 OK | | 1042 |<------------------| | 1043 |(7) NOTIFY | | 1044 |<------------------| | 1045 |(8) 200 OK | | 1046 |------------------>| | 1047 | |(9) PUBLISH uri-up | 1048 | |<------------------| 1049 | |(10) 200 OK | 1050 | |------------------>| 1051 |(11) NOTIFY | | 1052 |<------------------| | 1053 |(12) 200 OK | | 1054 |------------------>| | 1056 Figure 7: Registration 1058 Permission documents generated by registrars are typically very 1059 general. For example, in one such document a registrar can ask a 1060 recipient for permission to forward any request from any sender to 1061 the recipient's URI. This is the type of granularity that this 1062 framework intends to provide for registrations. Users who want to 1063 define how incoming requests are treated with a finer granularity 1064 (e.g., requests from user A are only accepted between 9:00 and 11:00) 1065 will have to use other mechanisms such as CPL [RFC3880]. 1067 Note that, as indicated previously, user agents using the same 1068 connection to register and to receive traffic from the registrar, 1069 as described in [I-D.ietf-sip-outbound] do not need to use the 1070 mechanism described in this section. 1072 A user agent being registered by a third party can be unable to use 1073 the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to 1074 prove to the registrar that the user agent is the owner of the URI 1075 being registered (e.g., sip:user@192.0.2.1), which is the recipient 1076 URI of the translation. In this case, return routability MUST be 1077 used. 1079 5.11. Relays Generating Traffic towards Recipients 1081 Relays generating traffic towards recipient need to make sure that 1082 those recipients can revoke the permissions they gave at any time. 1083 The Trigger-Consent helps achieve this. 1085 5.11.1. Relay's Behavior 1087 A relay executing a translation that involves sending a request to a 1088 URI from which permissions were obtained previously SHOULD add a 1089 Trigger-Consent header field to the request. The URI in the Trigger- 1090 Consent header field MUST have a target-uri header field parameter 1091 identifying the target URI of the translation. 1093 On receiving a PUBLISH request addressed to the URI a relay placed in 1094 a Trigger-Consent header field, the relay SHOULD send a MESSAGE 1095 request to corresponding recipient URI with a permission document. 1096 Therefore, the relay needs to be able to correlate the URI it places 1097 in the Trigger-Consent header field with the recipient URI of the 1098 translation. 1100 5.11.2. Definition of the Trigger-Consent Header Field 1102 The following is the augmented Backus-Naur Form (BNF) [RFC4234] 1103 syntax of the Trigger-Consent header field. Some of its elements are 1104 defined in [RFC3261]. 1106 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 1107 *( COMMA trigger-cons-spec ) 1108 trigger-cons-spec = ( SIP-URI / SIPS-URI ) 1109 *( SEMI trigger-param ) 1110 trigger-param = target-uri / generic-param 1111 target-uri = "target-uri" EQUAL 1112 LDQUOT *( qdtext / quoted-pair ) RDQUOT 1114 The target-uri header field parameter MUST contain a URI. 1116 The following is an example of a Trigger-Consent header field: 1118 Trigger-Consent: sip:123@relay.example.com 1119 ;target-uri="sip:friends@relay.example.com" 1121 6. IANA Considerations 1123 The following sections request the IANA to register a SIP response 1124 code, two SIP header fields, and a SIP header field parameter. 1126 6.1. Registration of the 470 Response Code 1128 The IANA is requested to add the following new response code to the 1129 Methods and Response Codes subregistry under the SIP Parameters 1130 registry. 1132 Response Code Number: 470 1133 Default Reason Phrase: Consent Needed 1134 Reference: [RFCxxxx] 1136 Note to the RFC editor: substitute xxxx with the RFC number of this 1137 document. 1139 6.2. Registration of the Trigger-Consent Header Field 1141 The IANA is requested to add the following new SIP header field to 1142 the Header Fields subregistry under the SIP Parameters registry. 1144 Header Name: Trigger-Consent 1145 Compact Form: (none) 1146 Reference: [RFCxxxx] 1148 Note to the RFC editor: substitute xxxx with the RFC number of this 1149 document. 1151 6.3. Registration of the Permission-Missing Header Field 1153 The IANA is requested to add the following new SIP header field to 1154 the Header Fields subregistry under the SIP Parameters registry. 1156 Header Name: Permission-Missing 1157 Compact Form: (none) 1158 Reference: [RFCxxxx] 1160 Note to the RFC editor: substitute xxxx with the RFC number of this 1161 document. 1163 6.4. Registration of the target-uri Header Field Parameter 1165 The IANA is requested to register the 'target-uri' Trigger-Consent 1166 header field parameter under the Header Field Parameters and 1167 Parameter Values subregistry within the SIP Parameters registry: 1169 Predefined 1170 Header Field Parameter Name Values Reference 1171 ---------------------------- --------------- --------- --------- 1172 Trigger-Consent target-uri No [RFCxxxx] 1174 Note to the RFC editor: substitute xxxx with the RFC number of this 1175 document. 1177 7. Security Considerations 1179 Security has been discussed throughout the whole document. However, 1180 there are some issues that deserve special attention. 1182 Relays generally implement several security mechanisms that relate to 1183 client authentication and authorization. Clients are typically 1184 authenticated before they can manipulate a relay's translation logic. 1185 Additionally, clients are typically also authenticated and sometimes 1186 need to perform SPAM prevention tasks [RFC5039] when they send 1187 traffic to a relay. It is important that relays implement these 1188 types of security mechanisms. However, they fall out of the scope of 1189 this framework. Even with these mechanisms in place, there is still 1190 a need for relays to implement this framework because the use of 1191 these mechanisms do not prevent authorized clients to add recipients 1192 to a translation without their consent. Consequently, relays 1193 performing translations MUST implement this framework. 1195 Note that, as indicated previously, user agents using the same 1196 connection to register and to receive traffic from the registrar, 1197 as described in [I-D.ietf-sip-outbound] do not need to use this 1198 framework. Therefore, a registrars that did not accept third- 1199 party registrations would not need to implement this framework. 1201 As pointed out in Section 5.6.1.3, when return routability tests are 1202 used to authenticate recipients granting or denying permissions, the 1203 URIs used to grant or deny permissions need to be protected from 1204 attackers. SIPS URIs provide a good tool to meet this requirement, 1205 as described in [I-D.ietf-sipping-consent-format]. When store-and- 1206 forward servers are used, the interface between a user agent and its 1207 store-and-forward server is frequently not based on SIP. In such 1208 case, SIPS cannot be used to secure those URIs. Implementations of 1209 store-and-forward servers MUST provide a mechanism for delivering 1210 encrypted and integrity-protected messages to their user agents. 1212 The information provided by the Pending Additions event package can 1213 be sensitive. For this reason, as described in 1214 [I-D.ietf-sipping-pending-additions], relays need to use strong means 1215 for authentication and information confidentiality. SIPS URIs are a 1216 good mechanism to meet this requirement. 1218 Permission documents can reveal sensitive information. Attackers may 1219 attempt to modify them in order to have clients grant or deny 1220 permissions different to the ones they think are granting or denying. 1221 For this reason, it is RECOMMENDED that relays use strong means for 1222 information integrity protection and confidentiality when sending 1223 permission documents to clients. 1225 The mechanism used for conveying information to clients SHOULD ensure 1226 the integrity and confidentially of the information. In order to 1227 achieve these, an end-to-end SIP encryption mechanism, such as 1228 S/MIME, as described in [RFC3261], SHOULD be used. 1230 If strong end-to-end security means (such as above) is not available, 1231 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS 1232 URIs, as described in [RFC3261], is used. 1234 8. Acknowledgments 1236 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 1237 useful ideas on this document. Ben Campbell, AC Mahendran, Keith 1238 Drage, and Mary Barnes performed a thorough review of this document. 1240 9. References 1242 9.1. Normative References 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, March 1997. 1247 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1248 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1249 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1251 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1252 A., Peterson, J., Sparks, R., Handley, M., and E. 1253 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1254 June 2002. 1256 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1257 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1258 for Instant Messaging", RFC 3428, December 2002. 1260 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1261 Specifications: ABNF", RFC 4234, October 2005. 1263 [I-D.ietf-sipping-uri-services] 1264 Camarillo, G. and A. Roach, "Framework and Security 1265 Considerations for Session Initiation Protocol (SIP) 1266 Uniform Resource Identifier (URI)-List Services", 1267 draft-ietf-sipping-uri-services-06 (work in progress), 1268 September 2006. 1270 [I-D.ietf-sipping-consent-format] 1271 Camarillo, G., "A Document Format for Requesting Consent", 1272 draft-ietf-sipping-consent-format-03 (work in progress), 1273 April 2007. 1275 [I-D.ietf-sipping-pending-additions] 1276 Camarillo, G., "The Session Initiation Protocol (SIP) 1277 Pending Additions Event Package", 1278 draft-ietf-sipping-pending-additions-02 (work in 1279 progress), April 2007. 1281 9.2. Informative References 1283 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1284 Extensions to the Session Initiation Protocol (SIP) for 1285 Asserted Identity within Trusted Networks", RFC 3325, 1286 November 2002. 1288 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1289 Language (CPL): A Language for User Control of Internet 1290 Telephony Services", RFC 3880, October 2004. 1292 [RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements 1293 for Consent-Based Communications in the Session Initiation 1294 Protocol (SIP)", RFC 4453, April 2006. 1296 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1297 Authenticated Identity Management in the Session 1298 Initiation Protocol (SIP)", RFC 4474, August 2006. 1300 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1301 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1303 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 1304 for Representing Resource Lists", RFC 4826, May 2007. 1306 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1307 Protocol (SIP) and Spam", RFC 5039, January 2008. 1309 [I-D.ietf-sip-outbound] 1310 Jennings, C. and R. Mahy, "Managing Client Initiated 1311 Connections in the Session Initiation Protocol (SIP)", 1312 draft-ietf-sip-outbound-08 (work in progress), March 2007. 1314 Authors' Addresses 1316 Jonathan Rosenberg 1317 Cisco Systems 1318 600 Lanidex Plaza 1319 Parsippany, NJ 07054 1320 US 1322 Phone: +1 973 952-5000 1323 Email: jdrosen@cisco.com 1324 URI: http://www.jdrosen.net 1326 Gonzalo Camarillo (editor) 1327 Ericsson 1328 Hirsalantie 11 1329 Jorvas 02420 1330 Finland 1332 Email: Gonzalo.Camarillo@ericsson.com 1334 Dean Willis 1335 Unaffiliated 1336 3100 Independence Pkwy #311-164 1337 Plano, TX 75075 1338 USA 1340 Email: dean.willis@softarmor.com 1342 Full Copyright Statement 1344 Copyright (C) The IETF Trust (2008). 1346 This document is subject to the rights, licenses and restrictions 1347 contained in BCP 78, and except as set forth therein, the authors 1348 retain all their rights. 1350 This document and the information contained herein are provided on an 1351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1353 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1354 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1355 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1358 Intellectual Property 1360 The IETF takes no position regarding the validity or scope of any 1361 Intellectual Property Rights or other rights that might be claimed to 1362 pertain to the implementation or use of the technology described in 1363 this document or the extent to which any license under such rights 1364 might or might not be available; nor does it represent that it has 1365 made any independent effort to identify any such rights. Information 1366 on the procedures with respect to rights in RFC documents can be 1367 found in BCP 78 and BCP 79. 1369 Copies of IPR disclosures made to the IETF Secretariat and any 1370 assurances of licenses to be made available, or the result of an 1371 attempt made to obtain a general license or permission for the use of 1372 such proprietary rights by implementers or users of this 1373 specification can be obtained from the IETF on-line IPR repository at 1374 http://www.ietf.org/ipr. 1376 The IETF invites any interested party to bring to its attention any 1377 copyrights, patents or patent applications, or other proprietary 1378 rights that may cover technology that may be required to implement 1379 this standard. Please address the information to the IETF at 1380 ietf-ipr@ietf.org. 1382 Acknowledgment 1384 Funding for the RFC Editor function is provided by the IETF 1385 Administrative Support Activity (IASA).