idnits 2.17.1 draft-ietf-sip-consent-framework-03.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 1328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1352. 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 (November 13, 2007) is 6002 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 1154, 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: May 16, 2008 Ericsson 6 D. Willis 7 Unaffiliated 8 November 13, 2007 10 A Framework for Consent-based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sip-consent-framework-03.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 May 16, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Session Initiation Protocol (SIP) supports communications across 46 many media types, including real-time audio, video, text, instant 47 messaging, and presence. In its current form, it allows session 48 invitations, instant messages, and other requests to be delivered 49 from one party to another without requiring explicit consent of the 50 recipient. Without such consent, it is possible for SIP to be used 51 for malicious purposes, including amplification, and DoS (Denial of 52 Service) attacks. This document identifies a framework for consent- 53 based communications in SIP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4 59 3. Relays and Translations . . . . . . . . . . . . . . . . . . . 5 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 12 68 5.1.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 12 69 5.2. Subscription to the Permission Status . . . . . . . . . . 12 70 5.2.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13 71 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 13 72 5.3.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 13 73 5.4. Permission Document Structure . . . . . . . . . . . . . . 15 74 5.5. Permission Requested Notification . . . . . . . . . . . . 17 75 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 17 76 5.6.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 17 77 5.7. Permission Granted Notification . . . . . . . . . . . . . 19 78 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 19 79 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 20 80 5.9.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 21 81 5.9.2. Definition of the 470 Response Code . . . . . . . . . 21 82 5.9.3. Definition of the Permission-Missing Header Field . . 21 83 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 22 84 5.11. Relays Generating Traffic towards Recipients . . . . . . . 24 85 5.11.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 24 86 5.11.2. Definition of the Trigger-Consent Header Field . . . . 24 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 6.1. Registration of the 470 Response Code . . . . . . . . . . 25 89 6.2. Registration of the Trigger-Consent Header Field . . . . . 25 90 6.3. Registration of the Permission-Missing Header Field . . . 26 91 6.4. Registration of the target-uri Header Field Parameter . . 26 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 98 Intellectual Property and Copyright Statements . . . . . . . . . . 31 100 1. Introduction 102 The Session Initiation Protocol (SIP) [RFC3261] supports 103 communications across many media types, 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 +---------------+ 158 | | recipient URI 159 | |----------------> 160 target URI | Translation | 161 -------------->| Operation | recipient URI 162 | |----------------> 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. 195 Figure 2 shows a relay that performs translations. The user agent 196 client in the figure sends a SIP request to a URI representing a 197 resource in the domain 'example.com' (sip:resource@example.com). 198 This request can pass through a local outbound proxy (not shown), but 199 eventually arrives at a server authoritative for the domain 200 'example.com'. This server, which acts as a relay, performs a 201 translation operation, translating the target URI into one or more 202 recipient URIs, which can but need not belong to the domain 203 'example.com'. This relay can be, for instance, a proxy server or a 204 URI-list service [I-D.ietf-sipping-uri-services]. 206 +-------+ 207 | | 208 >| UA | 209 / | | 210 / +-------+ 211 / 212 / 213 +-----------------------+ / 214 | | / 215 +-----+ | Relay | / +-------+ 216 | | | |/ | | 217 | UA |------>| |-------->| Proxy | 218 | | |+---------------------+|\ | | 219 +-----+ || Translation || \ +-------+ 220 || Logic || \ 221 |+---------------------+| \ [...] 222 +-----------------------+ \ 223 \ 224 \ +-------+ 225 \ | | 226 >| B2BUA | 227 | | 228 +-------+ 230 Figure 2: Relay performing a translation 232 This framework allows potential recipients of a translation to agree 233 to be actual recipients by giving the relay performing the 234 translation permission to send them traffic. 236 4. Architecture 238 Figure 3 shows the architectural elements of this framework. The 239 manipulation of a relay's translation logic typically causes the 240 relay to send a permission request, which in turn causes the 241 recipient to grant or deny the relay permissions for the translation. 242 Section 4.1 describes the role of permissions at a relay. 243 Section 4.2 discusses the actions taken by a relay when its 244 translation logic is manipulated by a client. Section 4.3 discusses 245 store-and-forward servers and their functionality. Section 4.4 246 describes how potential recipients can grant a relay permissions to 247 add them to the relay's translation logic. Section 4.5 discusses 248 which entities need to implement this framework. 250 +-----------------------+ Permission +-------------+ 251 | | Request | | 252 +--------+ | Relay |----------->| Store & Fwd | 253 | | | | | Server | 254 | Client | | | | | 255 | | |+-------+ +-----------+| +-------------+ 256 +--------+ ||Transl.| |Permissions|| | 257 | ||Logic | | || Permission | 258 | |+-------+ +-----------+| Request | 259 | +-----------------------+ V 260 | ^ ^ +-------------+ 261 | Manipulation | | Permission Grant | | 262 +---------------+ +-------------------| Recipient | 263 | | 264 +-------------+ 266 Figure 3: Reference Architecture 268 4.1. Permissions at a Relay 270 Relays implementing this framework obtain and store permissions 271 associated to their translation logic. These permissions indicate if 272 a particular recipient has agreed to receive traffic or not at any 273 given time. Recipients that have not given the relay permission to 274 send them traffic are simply ignored by the relay when performing a 275 translation. 277 In principle, permissions are valid as long as the context where they 278 were granted is valid or until they are revoked. For example, the 279 permissions obtained by a URI-list SIP service that distributes 280 MESSAGE requests to a set of recipients will be valid as long as the 281 URI-list SIP service exists or until the permissions are revoked. 283 Additionally, if a recipient is removed from a relay's translation 284 logic, the relay SHOULD delete the permissions related to that 285 recipient. For example, if the registration of a contact URI expires 286 or is otherwise terminated, the registrar deletes the permissions 287 related to that contact address. 289 It is also RECOMMENDED that relays request recipients to refresh 290 their permissions periodically. If a recipient fails to refresh its 291 permissions for a given period of time, the relay SHOULD delete the 292 permissions related to that recipient. 294 This framework does not provide any guidance for the values of the 295 refreshment intervals because different applications can have 296 different requirements to set those values. 298 4.2. Consenting Manipulations on a Relay's Transaction Logic 300 This framework aims to ensure that any particular relay only performs 301 translations towards destinations that have given the relay 302 permission to perform such a translation. Consequently, when the 303 translation logic of a relay is manipulated (e.g., a new recipient 304 URI is added), the relay obtains permission from the new recipient in 305 order to install the new translation logic. Relays ask recipients 306 for permission using MESSAGE [RFC3428] requests. 308 For example, the relay hosting the URI-list service at 309 'sip:friends@example.com' performs a translation from that target URI 310 to a set of recipient URIs. When a client (e.g., the administrator 311 of that URI-list service) adds 'bob@example.org' as a new recipient 312 URI, the relay sends a MESSAGE request to 'sip:bob@example.org' 313 asking whether or not it is OK to perform the translation from 314 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE 315 request carries in its message body a permission document that 316 describes the translation for which permissions are being requested 317 and a human readable part that also describes the translation. If 318 the answer is positive, the new translation logic is installed at the 319 relay. That is, the new recipient URI is added. 321 The human-readable part is included so that user agents that do 322 not understand permission documents can still process the request 323 and display it in a sensible way to the user. 325 The mechanism to be used to manipulate the translation logic of a 326 particular relay depends on the relay. Two existing mechanisms to 327 manipulate translation logic are XCAP [RFC4825] and REGISTER 328 transactions. 330 Section 5 uses a URI-list service whose translation logic is 331 manipulated with XCAP as an example of a translation in order to 332 specify this framework. Section 5.10 discusses how to apply this 333 framework to registrations, which are a different type of 334 translation. 336 In any case, relays implementing this framework SHOULD have a means 337 to indicate that a particular recipient URI is in the states 338 specified in [I-D.ietf-sipping-pending-additions] (i.e., pending, 339 waiting, error, denied, or granted). 341 4.3. Store-and-forward Servers 343 When a MESSAGE request with a permission document arrives to the 344 recipient URI to which it was sent by the relay, the receiving user 345 can grant or deny the permission needed to perform the translation. 346 However, users are not on-line all the time and, so, sometimes are 347 not able to receive MESSAGE requests. 349 This issue is also found in presence, where a user's status is 350 reported by a presence server instead of by the user's user agents, 351 which can go on and off line. Similarly, store-and-forward servers 352 are elements that act as SIP user agents and handle MESSAGE requests 353 for a user. A store-and-forward server stores incoming MESSAGE 354 requests when the user is unavailable and delivers them when the user 355 is available again. 357 There are several mechanisms to implement store-and-forward message 358 services (e.g., with an instant message to email gateway). Any of 359 these mechanisms can be used between a user agent and its store-and- 360 forward server as long as they agree on which mechanism to use. 361 Therefore, this framework does not make any provision for the 362 interface between user agents and their store-and-forward servers. 364 Note that the same store-and-forward message service can handle 365 all incoming MESSAGE requests for a user while this is off line, 366 not only those MESSAGE requests with a permission document in 367 their bodies. 369 Even though store-and-forward servers perform a useful function and 370 they are expected to be deployed in most domains, some domains will 371 not deploy them from day one. However, user agents and relays in 372 domains without store-and-forward servers can still use this consent 373 framework. 375 When a relay requests permissions from an off-line user agent that 376 does not have an associated store-and-forward server, the relay will 377 obtain an error response indicating that its MESSAGE request could 378 not be delivered. The client that attempted to add the off-line user 379 to the relay's translation logic will be notified about the error 380 (e.g., using the Pending Additions event package 381 [I-D.ietf-sipping-pending-additions]). This client MAY attempt to 382 add the same user at a later point, hopefully when the user is on- 383 line. Clients can discover whether or not a user is on-line by using 384 a presence service, for instance. 386 4.4. Recipients Grant Permissions 388 Relays include in the permission documents they generate URIs that 389 can be used by the recipient of the document to grant or deny the 390 relay the permission described in the document. Relays always 391 include SIP URIs and can include HTTP [RFC2616] URIs for this 392 purpose. Consequently, recipients provide relays with permissions 393 using SIP PUBLISH requests or HTTP GET requests. 395 4.5. Entities Implementing this Framework 397 The goal of this framework is to keep relays from executing 398 translations towards unwilling recipients. Therefore, all relays 399 MUST implement this framework in order to avoid being used to perform 400 attacks (e.g., amplification attacks). 402 This framework has been designed with backwards compatibility in mind 403 so that legacy user agents (i.e., user agents that do not implement 404 this framework) can act both as clients and recipients with an 405 acceptable level of functionality. However, it is RECOMMENDED that 406 user agents implement this framework, which includes supporting the 407 Pending Additions event package specified in 408 [I-D.ietf-sipping-pending-additions], the format for permission 409 documents specified in [I-D.ietf-sipping-consent-format], and the 410 header fields and response code specified in this document, in order 411 to achieve full functionality. 413 The only requirement that this framework places on store-and-forward 414 servers is that they need to be able to deliver encrypted and 415 integrity- protected messages to their user agents, as discussed in 416 Section 7. However, this is not a requirement specific to this 417 framework but a general requirement for store-and-forward servers. 419 5. Framework Operations 421 This section specifies this consent framework using an example of the 422 prototypical call flow. The elements described in Section 4 (i.e., 423 relays, translations, and store-and-forward servers) play an 424 essential role in this call flow. 426 Figure 4 shows the complete process to add a recipient URI 427 ('sip:B@example.com') to the translation logic of a relay. User A 428 attempts to add 'sip:B@example.com' as a new recipient URI to the 429 translation logic of the relay (1). User A uses XCAP [RFC4825] and 430 the XML (Extensible Markup Language) format for representing resource 431 lists [RFC4826] to perform this addition. Since the relay does not 432 have permission from 'sip:B@example.com' to perform translations 433 towards that URI, the relay places 'sip:B@example.com' in the pending 434 state, as specified in [I-D.ietf-sipping-pending-additions]. 436 A@example.com Relay B's Store & Fwd B@example.com 437 Server 439 |(1) Add Recipient | | 440 | sip:B@example.com | | 441 |--------------->| | | 442 |(2) HTTP 202 (Accepted) | | 443 |<---------------| | | 444 | |(3) MESSAGE sip:B@example | 445 | | Permission Document | 446 | |--------------->| | 447 | |(4) 202 Accepted| | 448 | |<---------------| | 449 |(5) SUBSCRIBE | | | 450 | Event: pending-additions | | 451 |--------------->| | | 452 |(6) 200 OK | | | 453 |<---------------| | | 454 |(7) NOTIFY | | | 455 |<---------------| | | 456 |(8) 200 OK | | | 457 |--------------->| | | 458 | | | |User B goes 459 | | | | on line 460 | | |(9) Request for | 461 | | | stored messages 462 | | |<---------------| 463 | | |(10) Delivery of| 464 | | | stored messages 465 | | |--------------->| 466 | |(11) PUBLISH uri-up | 467 | | Permission Document | 468 | |<--------------------------------| 469 | |(12) 200 OK | | 470 | |-------------------------------->| 471 |(13) NOTIFY | | | 472 |<---------------| | | 473 |(14) 200 OK | | | 474 |--------------->| | | 476 Figure 4: Prototypical call flow 478 5.1. Amplification Avoidance 480 Once 'sip:B@example.com' is in the pending state, the relay needs to 481 ask user B for permission by sending a MESSAGE request to 482 'sip:B@example.com'. However, the relay needs to ensure that it is 483 not used as an amplifier to launch amplification attacks. 485 In such an attack, the attacker would add a large number of recipient 486 URIs to the translation logic of a relay. The relay would then send 487 a MESSAGE request to each of those recipient URIs. The bandwidth 488 generated by the relay would be much higher than the bandwidth used 489 by the attacker to add those recipient URIs to the translation logic 490 of the relay. 492 This framework uses a credit-based authorization mechanism to avoid 493 the attack just described. It requires users adding new recipient 494 URIs to a translation to generate an amount of bandwidth that is 495 comparable to the bandwidth the relay will generate when sending 496 MESSAGE requests towards those recipient URIs. When XCAP is used, 497 this requirement is met by not allowing clients to add more than one 498 URI per HTTP transaction. When a REGISTER transaction is used, this 499 requirement is met by not allowing clients to register more than one 500 contact per REGISTER transaction. 502 5.1.1. Relay's Behavior 504 Relays implementing this framework MUST NOT allow clients to add more 505 than one recipient URI per transaction. If a client using XCAP 506 attempts to add more than one recipient URI in a single HTTP 507 transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) 508 response. The XCAP server SHOULD describe the reason for the refusal 509 in an XML body using the element, as described 510 in [RFC4825]. If a client attempts to register more than one contact 511 in a single REGISTER transaction, the registrar SHOULD return a SIP 512 403 response and explain the reason for the refusal in its reason 513 phrase (e.g., Maximum one contact per registration). 515 5.2. Subscription to the Permission Status 517 Clients need a way to be informed about the status of the operations 518 they requested. Otherwise, users can be waiting for an operation to 519 succeed when it has actually already failed. In particular, if the 520 target of the request for consent was not reachable and did not have 521 an associated store-and-forward server, the client needs to know to 522 retry the request later. The Pending Additions SIP event package 523 [I-D.ietf-sipping-pending-additions] is a way to provide clients with 524 that information. 526 Clients can use the Pending Additions SIP event package to be 527 informed about the status of the operations they requested. That is, 528 the client will be informed when an operation (e.g., the addition of 529 a recipient URI to a relay's translation logic) is authorized (and 530 thus executed) or rejected. Clients use the target URI of the SIP 531 translation being manipulated to subscribe to the 'pending-additions' 532 event package. 534 In our example, after receiving the response from the relay (2), user 535 A subscribes to the Pending Additions event package at the relay (5). 536 This subscription keeps user A informed about the status of the 537 permissions (e.g., granted or denied) the relay will obtain. 539 5.2.1. Relay's Behavior 541 Relays SHOULD support the Pending Additions SIP event package 542 specified in [I-D.ietf-sipping-pending-additions]. 544 5.3. Request for Permission 546 A relay requests permissions from potential recipients to add them to 547 its translation logic using MESSAGE requests. In our example, on 548 receiving the request to add User B to the translation logic of the 549 relay (1), the relay generates a MESSAGE request (3) towards 550 'sip:B@example.com'. This MESSAGE request carries a permission 551 document, which describes the translation that needs to be authorized 552 and carries a set of URIs to be used by the recipient to grant or to 553 deny the relay permission to perform that translation. User B will 554 authorize the translation by using one of those URIs, as described in 555 Section 5.6. The MESSAGE request also carries a body part that 556 contains the same information as the permission document but in a 557 human-readable format. 559 When User B uses one of the URIs in the permission document to grant 560 or deny permissions, the relay needs to make sure that it was 561 actually User B the one using that URI, and not an attacker. The 562 relay can use any of the methods described in Section 5.6 to 563 authenticate the permission document. 565 5.3.1. Relay's Behavior 567 Relays that implement this framework MUST obtain permissions from 568 potential recipients before adding them to their translation logic. 569 Relays request permissions from potential recipients using MESSAGE 570 requests. 572 Section 5.6 describes the methods a relay can use to authenticate 573 recipients giving the relay permission to perform a particular 574 translation. These methods are SIP identity [RFC4474], P-Asserted- 575 Identity [RFC3325], a return routability test, or SIP digest. Relays 576 that use the method consisting of a return routability test have to 577 send their MESSAGE requests to a SIPS URI, as specified in 578 Section 5.6. 580 MESSAGE requests sent to request permissions MUST include a 581 permission document and SHOULD include a human-readable part in their 582 bodies. The human-readable part contains the same information as the 583 permission document (but in a human-readable format), including the 584 URIs to grant and deny permissions. User agents that do not 585 understand permission documents can still process the request and 586 display it in a sensible way to the user, as they would display any 587 other instant message. This way, even if the user agent does not 588 implement this framework, the (human) user will be able to manually 589 click on the correct URI in order to grant or deny permissions. The 590 following is an example of a MESSAGE request that carries a human- 591 readable part and a permission document, which follows the format 592 specified in [I-D.ietf-sipping-consent-format], in its body. Not all 593 header fields are shown for simplicity reasons. 595 MESSAGE sip:bob@example.org SIP/2.0 596 From: ;tag=12345678 597 To: 598 Content-Type: multipart/mixed;boundary="boundary1" 600 --boundary1 601 Content-Type: text/plain 603 If you consent to receive traffic sent to 604 , please use one of the following 605 URIs: or 606 . Otherwise, use one of 607 the following URIs: or 608 . 609 --boundary1 610 Content-Type: application/auth-policy+xml 612 613 619 620 621 622 623 624 625 626 627 628 629 630 631 633 grant 634 636 grant 637 639 deny 640 642 deny 643 644 645 646 647 --boundary1-- 649 5.4. Permission Document Structure 651 A permission document is the representation (e.g., encoded in XML) of 652 a permission. A permission document contains several pieces of data: 654 Identity of the Sender: A URI representing the identity of the 655 sender for whom permissions are granted. 657 Identity of the Original Recipient: A URI representing the identity 658 of the original recipient, which is used as the input for the 659 translation operation. This is also called the target URI. 661 Identity of the Final Recipient: A URI representing the result of 662 the translation. The permission grants ability for the sender to 663 send requests to the target URI, and for a relay receiving those 664 requests to forward them to this URI. This is also called the 665 recipient URI. 667 URIs to Grant Permission: URIs that recipients can use to grant the 668 relay permission to perform the translation described in the 669 document. At least one of these URIs MUST be a SIP or SIPS URI. 670 HTTP and HTTPS URIs MAY also be used. 672 URIs to Deny Permission: URIs that recipients can use to deny the 673 relay permission to perform the translation described in the 674 document. At least one of these URIs MUST be a SIP or SIPS URI. 675 HTTP and HTTPS URIs MAY also be used. 677 Permission documents can contain wildcards. For example, a 678 permission document can request permission for any relay to forward 679 requests coming from a particular sender to a particular recipient. 680 Such a permission document would apply to any target URI. That is, 681 the field containing the identity of the original recipient would 682 match any URI. However, the recipient URI MUST NOT be wildcarded. 684 Entities implementing this framework MUST support the format for 685 permission documents defined in [I-D.ietf-sipping-consent-format] and 686 MAY support other formats. 688 In our example, the permission document in the MESSAGE request (3) 689 sent by the relay contains the following values: 691 Identity of the Sender: Any sender 693 Identity of the Original Recipient: sip:friends@example.com 695 Identity of the Final Recipient: sip:B@example.com 697 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 699 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 701 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 703 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 705 It is expected that the Sender field often contains a wildcard. 706 However, scenarios involving request-contained URI lists, such as the 707 one described in Section 5.9, can require permission documents that 708 apply to a specific sender. In cases where the identity of the 709 sender matters, relays MUST authenticate senders. 711 5.5. Permission Requested Notification 713 On receiving the MESSAGE request (3), User B's store-and-forward 714 server stores it because User B is off line at that point. When User 715 B goes on line, User B fetches all the requests its store-and-forward 716 server has stored (9). 718 5.6. Permission Grant 720 A client gives a relay permission to execute the translation 721 described in a permission document by sending a SIP PUBLISH or an 722 HTTP GET request to one of the URIs to grant permissions contained in 723 the document. Similarly, a client denies a relay permission to 724 execute the translation described in a permission document by sending 725 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 726 permissions contained in the document. Requests to grant or deny 727 permissions contain an empty body. 729 In our example, User B obtains the permission document (10) that was 730 received earlier by its store-and-forward server in the MESSAGE 731 request (3). User B authorizes the translation described in the 732 permission document received by sending a PUBLISH request (11) to the 733 SIP URI to grant permissions contained in the permission document. 735 5.6.1. Relay's Behavior 737 Relays MUST ensure that the SIP PUBLISH or the HTTP GET request 738 received was generated by the recipient of the translation and not by 739 an attacker. Relays can use four methods to authenticate those 740 requests. SIP identity, P-Asserted-Identity [RFC3325], a return 741 routability test, or SIP digest. While return routability tests can 742 be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP 743 identity, P-Asserted-Identity, and SIP digest can only be used to 744 authenticate SIP PUBLISH requests. SIP digest can only be used to 745 authenticate clients that share a secret with the relay (e.g., 746 clients that are in the same domain as the relay). 748 5.6.1.1. SIP Identity 750 The SIP identity [RFC4474] mechanism can be used to authenticate the 751 sender of a PUBLISH request. The relay MUST check that the 752 originator of the PUBLISH request is the owner of the recipient URI 753 in the permission document. Otherwise, the PUBLISH request SHOULD be 754 responded with a 401 (Unauthorized) response and MUST NOT be 755 processed further. 757 5.6.1.2. P-Asserted-Identity 759 The P-Asserted-Identity [RFC3325] mechanism can also be used to 760 authenticate the sender of a PUBLISH request. However, as discussed 761 in [RFC3325], this mechanism is intended to be used only within 762 networks of trusted SIP servers. That is, the use of this mechanism 763 is only applicable inside an administrative domain with previously 764 agreed-upon policies. 766 The relay MUST check that the originator of the PUBLISH request is 767 the owner of the recipient URI in the permission document. 768 Otherwise, the PUBLISH request SHOULD be responded with a 401 769 (Unauthorized) response and MUST NOT be processed further. 771 5.6.1.3. Return Routability 773 SIP identity provides a good authentication mechanism for incoming 774 PUBLISH requests. Nevertheless, SIP identity is not widely available 775 on the public Internet yet. That is why an authentication mechanism 776 that can already be used at this point is needed. 778 Return routability tests do not provide the same level of security as 779 SIP identity, but they provide a better-than-nothing security level 780 in architectures where the SIP identity mechanism is not available 781 (e.g., the current Internet). The relay generates an unguessable URI 782 (i.e., with a cryptographically random user part) and places it in 783 the permission document in the MESSAGE request (3). The recipient 784 needs to send a SIP PUBLISH request or an HTTP GET request to that 785 URI. Any incoming request sent to that URI SHOULD be considered 786 authenticated by the relay. 788 Note that the return routability method is the only one that 789 allows the use of HTTP URIs in permission documents. The other 790 methods require the use of SIP URIs. 792 Relays using a return routability test to perform this authentication 793 MUST send the MESSAGE request with the permission document to a SIPS 794 URI. This ensures that attackers do not get access to the 795 (unguessable) URI. Thus, the only user able to use the (unguessable) 796 URI is the receiver of the MESSAGE request. Similarly, permission 797 documents sent by relays using a return routability test MUST only 798 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 799 permissions. A part of these URIs (e.g., the user part of a SIPS 800 URI) MUST be cryptographically random with at least 32 bits of 801 randomness. 803 Relays can transition from return routability tests to SIP identity 804 by simply requiring the use of SIP identity for incoming PUBLISH 805 requests. That is, such a relay would reject PUBLISH requests that 806 did not use SIP identity. 808 5.6.1.4. SIP Digest 810 The SIP digest mechanism can be used to authenticate the sender of a 811 PUBLISH request as long as that sender shares a secret with the 812 relay. The relay MUST check that the originator of the PUBLISH 813 request is the owner of the recipient URI in the permission document. 814 Otherwise, the PUBLISH request SHOULD be responded with a 401 815 (Unauthorized) response and MUST NOT be processed further. 817 5.7. Permission Granted Notification 819 On receiving the PUBLISH request (11), the relay sends a NOTIFY 820 request (13) to inform user A that the permission for the translation 821 has been received and that the translation logic at the relay has 822 been updated. That is, 'sip:B@example.com' has been added as a 823 recipient URI. 825 5.8. Permission Revocation 827 At any time, if a recipient wants to revoke any permission, it uses 828 the URI it received in the permission document to deny the 829 permissions it previously granted. If a recipient loses this URI for 830 some reason, it needs to wait until it receives a new request 831 produced by the translation. Such a request will contain a Trigger- 832 Consent header field with a URI. That Trigger-Consent header field 833 will have a target-uri header field parameter identifying the target 834 URI of the translation. The recipient needs to send a PUBLISH 835 request with an empty body to the URI in the Trigger-Consent header 836 field in order to receive a MESSAGE request from the relay. Such a 837 MESSAGE request will contain a permission document with a URI to 838 revoke the permission that was previously granted. 840 Figure 5 shows an example of how a user that lost the URI to revoke 841 permissions at a relay can obtain a new URI using the Trigger-Consent 842 header field of an incoming request. The user rejects an incoming 843 INVITE (1) request, which contains a Trigger-Consent header field. 844 Using the URI in the that header field, the user sends a PUBLISH 845 request (4) to the relay. On receiving the PUBLISH request (4), the 846 relay generates a MESSAGE request (6) towards the user. Finally, the 847 user revokes the permissions by sending a PUBLISH request (8) to the 848 relay. 850 Relay B@example.com 851 |(1) INVITE | 852 | Trigger-Consent: sip:123@relay.example.com 853 | ;target-uri="sip:friends@relay.example.com" 854 |---------------------------->| 855 |(2) 603 Decline | 856 |<----------------------------| 857 |(3) ACK | 858 |---------------------------->| 859 |(4) PUBLISH sip:123@relay.example.com 860 |<----------------------------| 861 |(5) 200 OK | 862 |---------------------------->| 863 |(6) MESSAGE sip:B@example | 864 | Permission Document | 865 |---------------------------->| 866 |(7) 200 OK | 867 |<----------------------------| 868 |(8) PUBLISH uri-deny | 869 |<----------------------------| 870 |(9) 200 OK | 871 |---------------------------->| 873 Figure 5: Permission Revocation 875 5.9. Request-contained URI Lists 877 In the scenarios described so far, a user adds recipient URIs to the 878 translation logic of a relay. However, the relay does not perform 879 translations towards those recipient URIs until permissions are 880 obtained. 882 URI-list services using request-contained URI lists are a special 883 case because the selection of recipient URIs is performed at the same 884 time as the communication attempt. A user places a set of recipient 885 URIs in a request and sends it to a relay so that the relay sends a 886 similar request to all those recipient URIs. 888 Relays implementing this framework and providing this type of URI- 889 list services behave in a slightly different way as the relays 890 described so far. This type of relay also maintains a list of 891 recipient URIs for which permissions have been received. Clients 892 also manipulate this list using a manipulation mechanism (e.g., 893 XCAP). Nevertheless, this list does not represent the recipient URIs 894 of every translation performed by the relay. This list just 895 represents all the recipient URIs for which permissions have been 896 received. That is, the set of URIs that will be accepted if a 897 request containing a URI-list arrives to the relay. This set of URIs 898 is a super set of the recipient URIs of any particular translation 899 the relay performs. 901 5.9.1. Relay's Behavior 903 On receiving a request-contained URI-list, the relay checks whether 904 or not it has permissions for all the URIs contained in the incoming 905 URI-list. If it does, the relay performs the translation. If it 906 lacks permissions for one of more URIs, the relay MUST NOT perform 907 the translation and SHOULD return an error response. 909 A relay that receives a request-contained URI-list with a URI for 910 which the relay has no permissions SHOULD return a 470 (Consent 911 Needed) response. The relay SHOULD add a Permission-Missing header 912 field with the URIs for which the relay has no permissions. 914 5.9.2. Definition of the 470 Response Code 916 A 470 (Consent Needed) response indicates that the request that 917 triggered the response contained a URI-list with at least a URI for 918 which the relay had no permissions. The URI or URIs for which the 919 relay had not permissions are listed in a Permission-Missing header 920 field, should the response carry one. 922 A client receiving a 470 (Consent Needed) response uses a 923 manipulation mechanism (e.g., XCAP) to add those URIs to the relay's 924 list of URIs. The relay will obtain permissions for those URIs as 925 usual. 927 5.9.3. Definition of the Permission-Missing Header Field 929 Permission-Missing header fields carry URIs for which a relay did not 930 have permissions. The following is the augmented Backus-Naur Form 931 (BNF) [RFC4234] syntax of the Permission-Missing header field. Some 932 of its elements are defined in [RFC3261]. 934 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 935 *( COMMA per-miss-spec ) 936 per-miss-spec = ( name-addr / addr-spec ) 937 *( SEMI generic-param ) 939 The following is an example of a Permission-Missing header field: 941 Permission-Missing: sip:C@example.com 943 Figure 6 shows a relay that receives a request (1) that contains URIs 944 for which the relay does not have permission. The relay rejects the 945 request with a 470 (Consent Needed) response (2). That response 946 contains a Permission-Missing header field with the URIs for which 947 there was no permission. 949 A@example.com Relay 951 |(1) INVITE | 952 | sip:B@example.com | 953 | sip:C@example.com | 954 |---------------------->| 955 |(2) 470 Consent Needed | 956 | Permission-Missing: sip:C@example.com 957 |<----------------------| 958 |(3) ACK | 959 |---------------------->| 961 Figure 6: INVITE with a URI list in its body 963 5.10. Registrations 965 Even though the example used to specify this framework has been a 966 URI-list service, this framework applies to any type of translation 967 (i.e., not only to URI-list services). Registrations are a different 968 type of translations that deserve discussion. 970 Registrations are a special type of translations. The user 971 registering has a trust relationship with the registrar in its home 972 domain. This is not the case when a user gives any type of 973 permissions to a relay in a different domain. 975 Traditionally, REGISTER transactions have performed two operations at 976 the same time: setting up a translation and authorizing the use of 977 that translation. For example, a user registering its current 978 contact URI is giving permission to the registrar to forward traffic 979 sent to the user's AoR (Address of Records) to the registered contact 980 URI. This works fine when the entity registering is the same as the 981 one that will be receiving traffic at a later point (e.g., the entity 982 receives traffic over the same connection used for the registration 983 as described in [I-D.ietf-sip-outbound]). However, this schema 984 creates some potential attacks which relate to third-party 985 registrations. 987 An attacker binds, via a registration, his or her AoR with the 988 contact URI of a victim. Now, the victim will receive unsolicited 989 traffic that was originally addressed to the attacker. 991 The process of authorizing a registration is shown in Figure 7. User 992 A performs a third-party registration (1) and receives a 202 993 (Accepted) response (2). 995 Since the relay does not have permission from 996 'sip:a@ws123.example.com' to perform translations towards that 997 recipient URI, the relay places 'sip:a@ws123.example.com' in the 998 'pending' state. Once 'sip:a@ws123.example.com' is in the 999 'Permission Pending' state, the registrar needs to ask 1000 'sip:a@ws123.example.com' for permission by sending a MESSAGE request 1001 (3). 1003 After receiving the response from the relay (2), user A subscribes to 1004 the Pending Additions event package at the registrar (4). This 1005 subscription keeps the user informed about the status of the 1006 permissions (e.g., granted or denied) the registrar will obtain. The 1007 rest of the process is similar to the one described in Section 5. 1009 A@example.com Registrar a@ws123.example.com 1011 |(1) REGISTER | | 1012 | Contact: sip:a@ws123.example.com | 1013 |------------------>| | 1014 |(2) 202 Accepted OK| | 1015 |<------------------| | 1016 | |(3) MESSAGE sip:a@ws123.example 1017 | | Permission Document 1018 | |------------------>| 1019 | |(4) 200 OK | 1020 | |<------------------| 1021 |(5) SUBSCRIBE | | 1022 | Event: pending-additions | 1023 |------------------>| | 1024 |(6) 200 OK | | 1025 |<------------------| | 1026 |(7) NOTIFY | | 1027 |<------------------| | 1028 |(8) 200 OK | | 1029 |------------------>| | 1030 | |(9) PUBLISH uri-up | 1031 | |<------------------| 1032 | |(10) 200 OK | 1033 | |------------------>| 1034 |(11) NOTIFY | | 1035 |<------------------| | 1036 |(12) 200 OK | | 1037 |------------------>| | 1038 Figure 7: Registration 1040 Permission documents generated by registrars are typically very 1041 general. For example, in one such document a registrar can ask a 1042 recipient for permission to forward any request from any sender to 1043 the recipient's URI. This is the type of granularity that this 1044 framework intends to provide for registrations. Users who want to 1045 define how incoming requests are treated with a finer granularity 1046 (e.g., requests from user A are only accepted between 9:00 and 11:00) 1047 will have to use other mechanisms such as CPL [RFC3880]. 1049 Note that, as indicated previously, user agents using the same 1050 connection to register and to receive traffic from the registrar, 1051 as described in [I-D.ietf-sip-outbound] do not need to use the 1052 mechanism described in this section. 1054 A user agent being registered by a third party can be unable to use 1055 the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to 1056 prove to the registrar that the user agent is the owner of the URI 1057 being registered (e.g., sip:user@192.0.2.1), which is the recipient 1058 URI of the translation. In this case, return routability MUST be 1059 used. 1061 5.11. Relays Generating Traffic towards Recipients 1063 Relays generating traffic towards recipient need to make sure that 1064 those recipients can revoke the permissions they gave at any time. 1065 The Trigger-Consent helps achieve this. 1067 5.11.1. Relay's Behavior 1069 A relay executing a translation that involves sending a request to a 1070 URI from which permissions were obtained previously SHOULD add a 1071 Trigger-Consent header field to the request. The URI in the Trigger- 1072 Consent header field MUST have a target-uri header field parameter 1073 identifying the target URI of the translation. 1075 On receiving a PUBLISH request addressed to the URI a relay placed in 1076 a Trigger-Consent header field, the relay SHOULD send a MESSAGE 1077 request to corresponding recipient URI with a permission document. 1078 Therefore, the relay needs to be able to correlate the URI it places 1079 in the Trigger-Consent header field with the recipient URI of the 1080 translation. 1082 5.11.2. Definition of the Trigger-Consent Header Field 1084 The following is the augmented Backus-Naur Form (BNF) [RFC4234] 1085 syntax of the Trigger-Consent header field. Some of its elements are 1086 defined in [RFC3261]. 1088 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 1089 *( COMMA trigger-cons-spec ) 1090 trigger-cons-spec = ( SIP-URI / SIPS-URI ) 1091 *( SEMI trigger-param ) 1092 trigger-param = target-uri / generic-param 1093 target-uri = "target-uri" EQUAL 1094 LDQUOT *( qdtext / quoted-pair ) RDQUOT 1096 The target-uri header field parameter MUST contain a URI. 1098 The following is an example of a Trigger-Consent header field: 1100 Trigger-Consent: sip:123@relay.example.com 1101 ;target-uri="sip:friends@relay.example.com" 1103 6. IANA Considerations 1105 The following sections request the IANA to register a SIP response 1106 code, two SIP header fields, and a SIP header field parameter. 1108 6.1. Registration of the 470 Response Code 1110 The IANA is requested to add the following new response code to the 1111 Methods and Response Codes subregistry under the SIP Parameters 1112 registry. 1114 Response Code Number: 470 1115 Default Reason Phrase: Consent Needed 1116 Reference: [RFCxxxx] 1118 Note to the RFC editor: substitute xxxx with the RFC number of this 1119 document. 1121 6.2. Registration of the Trigger-Consent Header Field 1123 The IANA is requested to add the following new SIP header field to 1124 the Header Fields subregistry under the SIP Parameters registry. 1126 Header Name: Trigger-Consent 1127 Compact Form: (none) 1128 Reference: [RFCxxxx] 1130 Note to the RFC editor: substitute xxxx with the RFC number of this 1131 document. 1133 6.3. Registration of the Permission-Missing Header Field 1135 The IANA is requested to add the following new SIP header field to 1136 the Header Fields subregistry under the SIP Parameters registry. 1138 Header Name: Permission-Missing 1139 Compact Form: (none) 1140 Reference: [RFCxxxx] 1142 Note to the RFC editor: substitute xxxx with the RFC number of this 1143 document. 1145 6.4. Registration of the target-uri Header Field Parameter 1147 The IANA is requested to register the 'target-uri' Trigger-Consent 1148 header field parameter under the Header Field Parameters and 1149 Parameter Values subregistry within the SIP Parameters registry: 1151 Predefined 1152 Header Field Parameter Name Values Reference 1153 ---------------------------- --------------- --------- --------- 1154 Trigger-Consent target-uri No [RFCxxxx] 1156 Note to the RFC editor: substitute xxxx with the RFC number of this 1157 document. 1159 7. Security Considerations 1161 Security has been discussed throughout the whole document. However, 1162 there are some issues that deserve special attention. 1164 The specifications of mechanisms to manipulate translation logic at 1165 relays usually stress the importance of client authentication and 1166 authorization. Having relays authenticate and authorize clients 1167 manipulating their translation logic keeps unauthorized clients from 1168 adding recipients to a translation. However, this does not prevent 1169 authorized clients to add recipients to a translation without their 1170 consent. Additionally, some relays provide web interfaces for any 1171 client to add new recipients to the translation (e.g., many email 1172 mailing lists are operated in this way). In this situation, every 1173 client is considered authorized to manipulate the translation logic 1174 at the relay. This makes the use of this framework even more 1175 important. Therefore, relays performing translations MUST implement 1176 this framework. 1178 As pointed out in Section 5.6.1.3, when return routability tests are 1179 used to authenticate recipients granting or denying permissions, the 1180 URIs used to grant or deny permissions need to be protected from 1181 attackers. SIPS URIs provide a good tool to meet this requirement, 1182 as described in [I-D.ietf-sipping-consent-format]. When store-and- 1183 forward servers are used, the interface between a user agent and its 1184 store-and-forward server is frequently not based on SIP. In such 1185 case, SIPS cannot be used to secure those URIs. Implementations of 1186 store-and-forward servers MUST provide a mechanism for delivering 1187 encrypted and integrity-protected messages to their user agents. 1189 The information provided by the Pending Additions event package can 1190 be sensitive. For this reason, as described in 1191 [I-D.ietf-sipping-pending-additions], relays need to use strong means 1192 for authentication and information confidentiality. SIPS URIs are a 1193 good mechanism to meet this requirement. 1195 Permission documents can reveal sensitive information. Attackers may 1196 attempt to modify them in order to have clients grant or deny 1197 permissions different to the ones they think are granting or denying. 1198 For this reason, it is RECOMMENDED that relays use strong means for 1199 information integrity protection and confidentiality when sending 1200 permission documents to clients. 1202 The mechanism used for conveying information to clients SHOULD ensure 1203 the integrity and confidentially of the information. In order to 1204 achieve these, an end-to-end SIP encryption mechanism, such as 1205 S/MIME, as described in [RFC3261], SHOULD be used. 1207 If strong end-to-end security means (such as above) is not available, 1208 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS 1209 URIs, as described in [RFC3261], is used. 1211 8. Acknowledgments 1213 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 1214 useful ideas on this document. Ben Campbell, AC Mahendran, Keith 1215 Drage, and Mary Barnes performed a thorough review of this document. 1217 9. References 1218 9.1. Normative References 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, March 1997. 1223 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1224 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1225 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1227 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1228 A., Peterson, J., Sparks, R., Handley, M., and E. 1229 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1230 June 2002. 1232 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1233 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1234 for Instant Messaging", RFC 3428, December 2002. 1236 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1237 Specifications: ABNF", RFC 4234, October 2005. 1239 [I-D.ietf-sipping-uri-services] 1240 Camarillo, G. and A. Roach, "Framework and Security 1241 Considerations for Session Initiation Protocol (SIP) 1242 Uniform Resource Identifier (URI)-List Services", 1243 draft-ietf-sipping-uri-services-06 (work in progress), 1244 September 2006. 1246 [I-D.ietf-sipping-consent-format] 1247 Camarillo, G., "A Document Format for Requesting Consent", 1248 draft-ietf-sipping-consent-format-03 (work in progress), 1249 April 2007. 1251 [I-D.ietf-sipping-pending-additions] 1252 Camarillo, G., "The Session Initiation Protocol (SIP) 1253 Pending Additions Event Package", 1254 draft-ietf-sipping-pending-additions-02 (work in 1255 progress), April 2007. 1257 9.2. Informative References 1259 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1260 Extensions to the Session Initiation Protocol (SIP) for 1261 Asserted Identity within Trusted Networks", RFC 3325, 1262 November 2002. 1264 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1265 Language (CPL): A Language for User Control of Internet 1266 Telephony Services", RFC 3880, October 2004. 1268 [RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements 1269 for Consent-Based Communications in the Session Initiation 1270 Protocol (SIP)", RFC 4453, April 2006. 1272 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1273 Authenticated Identity Management in the Session 1274 Initiation Protocol (SIP)", RFC 4474, August 2006. 1276 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1277 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1279 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 1280 for Representing Resource Lists", RFC 4826, May 2007. 1282 [I-D.ietf-sip-outbound] 1283 Jennings, C. and R. Mahy, "Managing Client Initiated 1284 Connections in the Session Initiation Protocol (SIP)", 1285 draft-ietf-sip-outbound-08 (work in progress), March 2007. 1287 Authors' Addresses 1289 Jonathan Rosenberg 1290 Cisco Systems 1291 600 Lanidex Plaza 1292 Parsippany, NJ 07054 1293 US 1295 Phone: +1 973 952-5000 1296 Email: jdrosen@cisco.com 1297 URI: http://www.jdrosen.net 1299 Gonzalo Camarillo (editor) 1300 Ericsson 1301 Hirsalantie 11 1302 Jorvas 02420 1303 Finland 1305 Email: Gonzalo.Camarillo@ericsson.com 1306 Dean Willis 1307 Unaffiliated 1308 3100 Independence Pkwy #311-164 1309 Plano, TX 75075 1310 USA 1312 Email: dean.willis@softarmor.com 1314 Full Copyright Statement 1316 Copyright (C) The IETF Trust (2007). 1318 This document is subject to the rights, licenses and restrictions 1319 contained in BCP 78, and except as set forth therein, the authors 1320 retain all their rights. 1322 This document and the information contained herein are provided on an 1323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1325 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1326 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1330 Intellectual Property 1332 The IETF takes no position regarding the validity or scope of any 1333 Intellectual Property Rights or other rights that might be claimed to 1334 pertain to the implementation or use of the technology described in 1335 this document or the extent to which any license under such rights 1336 might or might not be available; nor does it represent that it has 1337 made any independent effort to identify any such rights. Information 1338 on the procedures with respect to rights in RFC documents can be 1339 found in BCP 78 and BCP 79. 1341 Copies of IPR disclosures made to the IETF Secretariat and any 1342 assurances of licenses to be made available, or the result of an 1343 attempt made to obtain a general license or permission for the use of 1344 such proprietary rights by implementers or users of this 1345 specification can be obtained from the IETF on-line IPR repository at 1346 http://www.ietf.org/ipr. 1348 The IETF invites any interested party to bring to its attention any 1349 copyrights, patents or patent applications, or other proprietary 1350 rights that may cover technology that may be required to implement 1351 this standard. Please address the information to the IETF at 1352 ietf-ipr@ietf.org. 1354 Acknowledgment 1356 Funding for the RFC Editor function is provided by the IETF 1357 Administrative Support Activity (IASA).