idnits 2.17.1 draft-ietf-sip-consent-framework-02.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 1241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1265. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 (July 5, 2007) is 6139 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 1083, 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 (~~), 7 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 Expires: January 6, 2008 G. Camarillo, Ed. 5 Ericsson 6 D. Willis 7 Unaffiliated 8 July 5, 2007 10 A Framework for Consent-Based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sip-consent-framework-02.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 January 6, 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 . . . . . . . . . . . . . . 14 74 5.5. Permission Requested Notification . . . . . . . . . . . . 15 75 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 15 76 5.6.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 16 77 5.7. Permission Granted Notification . . . . . . . . . . . . . 17 78 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 18 79 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 19 80 5.9.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 19 81 5.9.2. Definition of the 470 Response Code . . . . . . . . . 19 82 5.9.3. Definition of the Permission-Missing Header Field . . 20 83 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 21 84 5.11. Relays Generating Traffic towards Recipients . . . . . . . 23 85 5.11.1. Relay's Behavior . . . . . . . . . . . . . . . . . . . 23 86 5.11.2. Definition of the Trigger-Consent Header Field . . . . 23 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 6.1. Registration of the 470 Response Code . . . . . . . . . . 24 89 6.2. Registration of the Trigger-Consent Header Field . . . . . 24 90 6.3. Registration of the target-uri Header Field Parameter . . 24 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 97 Intellectual Property and Copyright Statements . . . . . . . . . . 29 99 1. Introduction 101 The Session Initiation Protocol (SIP) [RFC3261] supports 102 communications across many media types, including real-time audio, 103 video, text, instant messaging, and presence. This communication is 104 established by the transmission of various SIP requests (such as 105 INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with 106 whom communication is desired. Although a recipient of such a SIP 107 request can reject the request, and therefore decline the session, a 108 network of SIP proxy servers will deliver a SIP request to its 109 recipients without their explicit consent. 111 Receipt of these requests without explicit consent can cause a number 112 of problems. These include amplification and DoS (Denial of Service) 113 attacks. These problems are described in more detail in a companion 114 requirements document [RFC4453]. 116 This specification defines a basic framework for adding consent-based 117 communication to SIP. 119 2. Definitions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 Recipient URI: The Request-URI of an outgoing request sent by an 126 entity (e.g., a user agent or a proxy). The sending of such 127 request can have been the result of a translation operation. 129 Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User 130 Agent), or some hybrid, that receives a request, translates its 131 Request-URI into one or more next-hop URIs (i.e., recipient URIs), 132 and delivers the request to those URIs. 134 Target URI: The Request-URI of an incoming request that arrives to a 135 relay that will perform a translation operation. 137 Translation logic: The logic that defines a translation operation at 138 a relay. This logic includes the translation's target and 139 recipient URIs. 141 Translation operation: Operation by which a relay translates the 142 Request-URI of an incoming request (i.e., the target URI) into one 143 or more URIs (i.e., recipient URIs) which are used as the Request- 144 URIs of one or more outgoing requests. 146 3. Relays and Translations 148 Relays play a key role in this framework. A relay is defined as any 149 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 150 hybrid, which receives a request, translates its Request-URI into one 151 or more next hop URIs, and delivers the request to those URIs. The 152 Request-URI of the incoming request is referred to as 'target URI' 153 and the destination URIs of the outgoing requests are referred to as 154 'recipient URIs', as shown in Figure 1. 156 +---------------+ 157 | | recipient URI 158 | |----------------> 159 target URI | Translation | 160 -------------->| Operation | recipient URI 161 | |----------------> 162 | | 163 +---------------+ 165 Figure 1: Translation operation 167 Thus, an essential aspect of a relay is that of translation. When a 168 relay receives a request, it translates the Request-URI (target URI) 169 into one or more additional URIs (recipient URIs). Through this 170 translation operation, the relay can create outgoing requests to one 171 or more additional recipient URIs, thus creating the consent problem. 173 The consent problem is created by two types of translations: 174 translations based on local data and translations that involve 175 amplifications. 177 Translation operations based on local policy or local data (such as 178 registrations) are the vehicle by which a request is delivered 179 directly to an endpoint, when it would not otherwise be possible to. 180 In other words, if a spammer has the address of a user, 181 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA 182 (User Agent) of that user without having access to the registration 183 data that maps 'sip:user@example.com' to the user agent on which that 184 user is present. Thus, it is the usage of this registration data, 185 and more generally, the translation logic, which is expected to be 186 authorized in order to prevent undesired communications. Of course, 187 if the spammer knows the address of the user agent, it will be able 188 to deliver requests directly to it. 190 Translation operations that result in more than one recipient URI are 191 a source of amplification. Servers that do not perform translations, 192 such as outbound proxy servers, do not cause amplification. 194 Figure 2 shows a relay that performs translations. The user agent 195 client in the figure sends a SIP request to a URI representing a 196 resource in the domain 'example.com' (sip:resource@example.com). 197 This request can pass through a local outbound proxy (not shown), but 198 eventually arrives at a server authoritative for the domain 199 'example.com'. This server, which acts as a relay, performs a 200 translation operation, translating the target URI into one or more 201 recipient URIs, which can but need not belong to the domain 202 'example.com'. This relay can be, for instance, a proxy server or a 203 URI-list service [I-D.ietf-sipping-uri-services]. 205 +-------+ 206 | | 207 >| UA | 208 / | | 209 / +-------+ 210 / 211 / 212 +-----------------------+ / 213 | | / 214 +-----+ | Relay | / +-------+ 215 | | | |/ | | 216 | UA |------>| |-------->| Proxy | 217 | | |+---------------------+|\ | | 218 +-----+ || Translation || \ +-------+ 219 || Logic || \ 220 |+---------------------+| \ [...] 221 +-----------------------+ \ 222 \ 223 \ +-------+ 224 \ | | 225 >| B2BUA | 226 | | 227 +-------+ 229 Figure 2: Relay performing a translation 231 This framework allows potential recipients of a translation to agree 232 to be actual recipients by giving the relay performing the 233 translation permission to send them traffic. 235 4. Architecture 237 Figure 3 shows the architectural elements of this framework. The 238 manipulation of a relay's translation logic typically causes the 239 relay to send a permission request, which in turn causes the 240 recipient to grant or deny the relay permissions for the translation. 241 Section 4.1 describes the role of permissions at a relay. 242 Section 4.2 discusses the actions taken by a relay when its 243 translation logic is manipulated by a client. Section 4.3 discusses 244 store-and-forward servers and their functionality. Section 4.4 245 describes how potential recipients can grant a relay permissions to 246 add them to the relay's translation logic. Section 4.5 discusses 247 which entities need to implement this framework. 249 +-----------------------+ Permission +-------------+ 250 | | Request | | 251 +--------+ | Relay |----------->| Store & Fwd | 252 | | | | | Server | 253 | Client | | | | | 254 | | |+-------+ +-----------+| +-------------+ 255 +--------+ ||Transl.| |Permissions|| | 256 | ||Logic | | || Permission | 257 | |+-------+ +-----------+| Request | 258 | +-----------------------+ V 259 | ^ ^ +-------------+ 260 | Manipulation | | Permission Grant | | 261 +---------------+ +-------------------| Recipient | 262 | | 263 +-------------+ 265 Figure 3: Reference Architecture 267 4.1. Permissions at a Relay 269 Relays implementing this framework obtain and store permissions 270 associated to their translation logic. These permissions indicate if 271 a particular recipient has agreed to receive traffic or not at any 272 given time. Recipients that have not given the relay permission to 273 send them traffic are simply ignored by the relay when performing a 274 translation. 276 In principle, permissions are valid as long as the context where they 277 were granted is valid or until they are revoked. For example, the 278 permissions obtained by a URI-list SIP service that distributes 279 MESSAGE requests to a set of recipients will be valid as long as the 280 URI-list SIP service exists or until the permissions are revoked. 282 Additionally, if a recipient is removed from a relay's translation 283 logic, the relay SHOULD delete the permissions related to that 284 recipient. For example, if the registration of a contact URI expires 285 or is otherwise terminated, the registrar deletes the permissions 286 related to that contact address. 288 It is also RECOMMENDED that relays request recipients to refresh 289 their permissions periodically. If a recipient fails to refresh its 290 permissions for a given period of time, the relay SHOULD delete the 291 permissions related to that recipient. 293 This framework does not provide any guidance for the values of the 294 refreshment intervals because different applications can have 295 different requirements to set those values. 297 4.2. Consenting Manipulations on a Relay's Transaction Logic 299 This framework aims to ensure that any particular relay only performs 300 translations towards destinations that have given the relay 301 permission to perform such a translation. Consequently, when the 302 translation logic of a relay is manipulated (e.g., a new recipient 303 URI is added), the relay obtains permission from the new recipient in 304 order to install the new translation logic. Relays ask recipients 305 for permission using MESSAGE [RFC3428] requests. 307 For example, the relay hosting the URI-list service at 308 'sip:friends@example.com' performs a translation from that target URI 309 to a set of recipient URIs. When a client (e.g., the administrator 310 of that URI-list service) adds 'bob@example.org' as a new recipient 311 URI, the relay sends a MESSAGE request to 'sip:bob@example.org' 312 asking whether or not it is OK to perform the translation from 313 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE 314 request carries in its message body a permission document that 315 describes the translation for which permissions are being requested 316 and a human readable part that also describes the translation. If 317 the answer is positive, the new translation logic is installed at the 318 relay. That is, the new recipient URI is added. 320 The human-readable part is included so that user agents that do 321 not understand permission documents can still process the request 322 and display it in a sensible way to the user. 324 The mechanism to be used to manipulate the translation logic of a 325 particular relay depends on the relay. Two existing mechanisms to 326 manipulate translation logic are XCAP [RFC4825] and REGISTER 327 transactions. 329 Section 5 uses a URI-list service whose translation logic is 330 manipulated with XCAP as an example of a translation in order to 331 specify this framework. Section 5.10 discusses how to apply this 332 framework to registrations, which are a different type of 333 translation. 335 In any case, relays implementing this framework SHOULD have a means 336 to indicate that a particular recipient URI is in the states 337 specified in [I-D.ietf-sipping-pending-additions] (i.e., pending, 338 waiting, error, denied, or granted). 340 4.3. Store-and-forward Servers 342 When a MESSAGE request with a permission document arrives to the 343 recipient URI to which it was sent by the relay, the receiving user 344 can grant or deny the permission needed to perform the translation. 345 However, users are not on-line all the time and, so, sometimes are 346 not able to receive MESSAGE requests. 348 This issue is also found in presence, where a user's status is 349 reported by a presence server instead of by the user's user agents, 350 which can go on and off line. Similarly, store-and-forward servers 351 are elements that act as SIP user agents and handle MESSAGE requests 352 for a user. A store-and-forward server stores incoming MESSAGE 353 requests when the user is unavailable and delivers them when the user 354 is available again. 356 There are several mechanisms to implement store-and-forward message 357 services (e.g., with an instant message to email gateway). Any of 358 these mechanisms can be used between a user agent and its store-and- 359 forward server as long as they agree on which mechanism to use. 360 Therefore, this framework does not make any provision for the 361 interface between user agents and their store-and-forward servers. 363 Note that the same store-and-forward message service can handle 364 all incoming MESSAGE requests for a user while this is off line, 365 not only those MESSAGE requests with a permission document in 366 their bodies. 368 Even though store-and-forward servers perform a useful function and 369 they are expected to be deployed in most domains, some domains will 370 not deploy them from day one. However, user agents and relays in 371 domains without store-and-forward servers can still use this consent 372 framework. 374 When a relay requests permissions from an off-line user agent that 375 does not have an associated store-and-forward server, the relay will 376 obtain an error response indicating that its MESSAGE request could 377 not be delivered. The client that attempted to add the off-line user 378 to the relay's translation logic will be notified about the error 379 (e.g., using the Pending Additions event package 380 [I-D.ietf-sipping-pending-additions]). This client MAY attempt to 381 add the same user at a later point, hopefully when the user is on- 382 line. Clients can discover whether or not a user is on-line by using 383 a presence service, for instance. 385 4.4. Recipients Grant Permissions 387 Relays include in the permission documents they generate URIs that 388 can be used by the recipient of the document to grant or deny the 389 relay the permission described in the document. Relays always 390 include SIP URIs and can include HTTP [RFC2616] URIs for this 391 purpose. Consequently, recipients provide relays with permissions 392 using SIP PUBLISH requests or HTTP GET requests. 394 4.5. Entities Implementing this Framework 396 The goal of this framework is to keep relays from executing 397 translations towards unwilling recipients. Therefore, it is 398 RECOMMENDED that all relays implement this framework in order to 399 avoid being used to perform attacks (e.g., amplification attacks). 401 This framework has been designed with backwards compatibility in mind 402 so that legacy user agents (i.e., user agents that do not implement 403 this framework) can act both as clients and recipients with an 404 acceptable level of functionality. However, it is RECOMMENDED that 405 user agents implement this framework, which includes supporting the 406 Pending Additions event package specified in 407 [I-D.ietf-sipping-pending-additions], the format for permission 408 documents specified in [I-D.ietf-sipping-consent-format], and the 409 header fields and response code specified in this document, in order 410 to achieve full functionality. 412 The only requirement that this framework places on store-and-forward 413 servers is that they need to be able to deliver encrypted and 414 integrity- protected messages to their user agents, as discussed in 415 Section 7. However, this is not a requirement specific to this 416 framework but a general requirement for store-and-forward servers. 418 5. Framework Operations 420 This section specifies this consent framework using an example of the 421 prototypical call flow. The elements described in Section 4 (i.e., 422 relays, translations, and store-and-forward servers) play an 423 essential role in this call flow. 425 Figure 4 shows the complete process to add a recipient URI 426 ('sip:B@example.com') to the translation logic of a relay. User A 427 attempts to add 'sip:B@example.com' as a new recipient URI to the 428 translation logic of the relay (1). User A uses XCAP [RFC4825] and 429 the XML (Extensible Markup Language) format for representing resource 430 lists [RFC4826] to perform this addition. Since the relay does not 431 have permission from 'sip:B@example.com' to perform translations 432 towards that URI, the relay places 'sip:B@example.com' in the pending 433 state, as specified in [I-D.ietf-sipping-pending-additions]. 435 A@example.com Relay B's Store & Fwd B@example.com 436 Server 438 |(1) Add Recipient | | 439 | sip:B@example.com | | 440 |--------------->| | | 441 |(2) HTTP 202 (Accepted) | | 442 |<---------------| | | 443 | |(3) MESSAGE sip:B@example | 444 | | Permission Document | 445 | |--------------->| | 446 | |(4) 202 Accepted| | 447 | |<---------------| | 448 |(5) SUBSCRIBE | | | 449 | Event: pending-additions | | 450 |--------------->| | | 451 |(6) 200 OK | | | 452 |<---------------| | | 453 |(7) NOTIFY | | | 454 |<---------------| | | 455 |(8) 200 OK | | | 456 |--------------->| | | 457 | | | |User B goes 458 | | | | on line 459 | | |(9) Request for | 460 | | | stored messages 461 | | |<---------------| 462 | | |(10) Delivery of| 463 | | | stored messages 464 | | |--------------->| 465 | |(11) PUBLISH uri-up | 466 | | Permission Document | 467 | |<--------------------------------| 468 | |(12) 200 OK | | 469 | |-------------------------------->| 470 |(13) NOTIFY | | | 471 |<---------------| | | 472 |(14) 200 OK | | | 473 |--------------->| | | 475 Figure 4: Prototypical call flow 477 5.1. Amplification Avoidance 479 Once 'sip:B@example.com' is in the pending state, the relay needs to 480 ask user B for permission by sending a MESSAGE request to 481 'sip:B@example.com'. However, the relay needs to ensure that it is 482 not used as an amplifier to launch amplification attacks. 484 In such an attack, the attacker would add a large number of recipient 485 URIs to the translation logic of a relay. The relay would then send 486 a MESSAGE request to each of those recipient URIs. The bandwidth 487 generated by the relay would be much higher than the bandwidth used 488 by the attacker to add those recipient URIs to the translation logic 489 of the relay. 491 This framework uses a credit-based authorization mechanism to avoid 492 the attack just described. It requires users adding new recipient 493 URIs to a translation to generate an amount of bandwidth that is 494 comparable to the bandwidth the relay will generate when sending 495 MESSAGE requests towards those recipient URIs. When XCAP is used, 496 this requirement is met by not allowing clients to add more than one 497 URI per HTTP transaction. When a REGISTER transaction is used, this 498 requirement is met by not allowing clients to register more than one 499 contact per REGISTER transaction. 501 5.1.1. Relay's Behavior 503 Relays implementing this framework MUST NOT allow clients to add more 504 than one recipient URI per transaction. If a client using XCAP 505 attempts to add more than one recipient URI in a single HTTP 506 transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) 507 response. The XCAP server SHOULD describe the reason for the refusal 508 in an XML body using the element, as described 509 in [RFC4825]. If a client attempts to register more than one contact 510 in a single REGISTER transaction, the registrar SHOULD return a SIP 511 403 response and explain the reason for the refusal in its reason 512 phrase (e.g., Maximum one contact per registration). 514 5.2. Subscription to the Permission Status 516 Clients need a way to be informed about the status of the operations 517 they requested. Otherwise, users can be waiting for an operation to 518 succeed when it has actually already failed. In particular, if the 519 target of the request for consent was not reachable and did not have 520 an associated store-and-forward server, the client needs to know to 521 retry the request later. The Pending Additions SIP event package 522 [I-D.ietf-sipping-pending-additions] is a way to provide clients with 523 that information. 525 Clients can use the Pending Additions SIP event package to be 526 informed about the status of the operations they requested. That is, 527 the client will be informed when an operation (e.g., the addition of 528 a recipient URI to a relay's translation logic) is authorized (and 529 thus executed) or rejected. Clients use the target URI of the SIP 530 translation being manipulated to subscribe to the 'pending-additions' 531 event package. 533 In our example, after receiving the response from the relay (2), user 534 A subscribes to the Pending Additions event package at the relay (5). 535 This subscription keeps user A informed about the status of the 536 permissions (e.g., granted or denied) the relay will obtain. 538 5.2.1. Relay's Behavior 540 Relays SHOULD support the Pending Additions SIP event package 541 specified in [I-D.ietf-sipping-pending-additions]. 543 5.3. Request for Permission 545 A relay requests permissions from potential recipients to add them to 546 its translation logic using MESSAGE requests. In our example, on 547 receiving the request to add User B to the translation logic of the 548 relay (1), the relay generates a MESSAGE request (3) towards 549 'sip:B@example.com'. This MESSAGE request carries a permission 550 document, which describes the translation that needs to be authorized 551 and carries a set of URIs to be used by the recipient to grant or to 552 deny the relay permission to perform that translation. User B will 553 authorize the translation by using one of those URIs, as described in 554 Section 5.6. The MESSAGE request also carries a body part that 555 contains the same information as the permission document but in a 556 human-readable format. 558 When User B uses one of the URIs in the permission document to grant 559 or deny permissions, the relay needs to make sure that it was 560 actually User B the one using that URI, and not an attacker. The 561 relay can use any of the methods described in Section 5.6 to 562 authenticate the permission document. 564 5.3.1. Relay's Behavior 566 Relays that implement this framework MUST obtain permissions from 567 potential recipients before adding them to their translation logic. 568 Relays request permissions from potential recipients using MESSAGE 569 requests. 571 Section 5.6 describes the methods a relay can use to authenticate 572 recipients giving the relay permission to perform a particular 573 translation. These methods are SIP identity [RFC4474], P-Asserted- 574 Identity [RFC3325], a return routability test, or SIP digest. Relays 575 that use the method consisting of a return routability test have to 576 send their MESSAGE requests to a SIPS URI, as specified in 577 Section 5.6. 579 MESSAGE requests sent to request permissions MUST include a 580 permission document and SHOULD include a human-readable part in their 581 bodies. The human-readable part contains the same information as the 582 permission document (but in a human-readable format), including the 583 URIs to grant and deny permissions. User agents that do not 584 understand permission documents can still process the request and 585 display it in a sensible way to the user, as they would display any 586 other instant message. This way, even if the user agent does not 587 implement this framework, the (human) user will be able to manually 588 click on the correct URI in order to grant or deny permissions. 590 5.4. Permission Document Structure 592 A permission document is the XML representation of a permission. A 593 permission document contains several pieces of data: 595 Identity of the Sender: A URI representing the identity of the 596 sender for whom permissions are granted. 598 Identity of the Original Recipient: A URI representing the identity 599 of the original recipient, which is used as the input for the 600 translation operation. This is also called the target URI. 602 Identity of the Final Recipient: A URI representing the result of 603 the translation. The permission grants ability for the sender to 604 send requests to the target URI, and for a relay receiving those 605 requests to forward them to this URI. This is also called the 606 recipient URI. 608 URIs to Grant Permission: URIs that recipients can use to grant the 609 relay permission to perform the translation described in the 610 document. At least one of these URIs MUST be a SIP or SIPS URI. 611 HTTP and HTTPS URIs MAY also be used. 613 URIs to Deny Permission: URIs that recipients can use to deny the 614 relay permission to perform the translation described in the 615 document. At least one of these URIs MUST be a SIP or SIPS URI. 616 HTTP and HTTPS URIs MAY also be used. 618 Permission documents can contain wildcards. For example, a 619 permission document can request permission for any relay to forward 620 requests coming from a particular sender to a particular recipient. 622 Such a permission document would apply to any target URI. That is, 623 the field containing the identity of the original recipient would 624 match any URI. However, the recipient URI MUST NOT be wildcarded. 626 Entities implementing this framework MUST support the format for 627 permission documents defined in [I-D.ietf-sipping-consent-format] and 628 MAY support other formats. 630 In our example, the permission document in the MESSAGE request (3) 631 sent by the relay contains the following values: 633 Identity of the Sender: Any. 635 Identity of the Original Recipient: sip:friends@example.com 637 Identity of the Final Recipient: sip:B@example.com 639 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 641 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 643 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 645 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 647 It is expected that the Sender field often contains a wildcard. 648 However, scenarios involving request-contained URI lists, such as the 649 one described in Section 5.9, can require permission documents that 650 apply to a specific sender. In cases where the identity of the 651 sender matters, relays MUST authenticate senders. 653 5.5. Permission Requested Notification 655 On receiving the MESSAGE request (3), User B's store-and-forward 656 server stores it because User B is off line at that point. When User 657 B goes on line, User B fetches all the requests its store-and-forward 658 server has stored (9). 660 5.6. Permission Grant 662 A client gives a relay permission to execute the translation 663 described in a permission document by sending a SIP PUBLISH or an 664 HTTP GET request to one of the URIs to grant permissions contained in 665 the document. Similarly, a client denies a relay permission to 666 execute the translation described in a permission document by sending 667 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 668 permissions contained in the document. Requests to grant or deny 669 permissions contain an empty body. 671 In our example, User B obtains the permission document (10) that was 672 received earlier by its store-and-forward server in the MESSAGE 673 request (3). User B authorizes the translation described in the 674 permission document received by sending a PUBLISH request (11) to the 675 SIP URI to grant permissions contained in the permission document. 677 5.6.1. Relay's Behavior 679 Relays MUST ensure that the SIP PUBLISH or the HTTP GET request 680 received was generated by the recipient of the translation and not by 681 an attacker. Relays can use four methods to authenticate those 682 requests. SIP identity, P-Asserted-Identity [RFC3325], a return 683 routability test, or SIP digest. While return routability tests can 684 be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP 685 identity, P-Asserted-Identity, and SIP digest can only be used to 686 authenticate SIP PUBLISH requests. SIP digest can only be used to 687 authenticate clients that share a secret with the relay (e.g., 688 clients that are in the same domain as the relay). 690 5.6.1.1. SIP Identity 692 The SIP identity [RFC4474] mechanism can be used to authenticate the 693 sender of a PUBLISH request. The relay MUST check that the 694 originator of the PUBLISH request is the owner of the recipient URI 695 in the permission document. Otherwise, the PUBLISH request SHOULD be 696 responded with a 401 (Unauthorized) response and MUST NOT be 697 processed further. 699 5.6.1.2. P-Asserted-Identity 701 The P-Asserted-Identity [RFC3325] mechanism can also be used to 702 authenticate the sender of a PUBLISH request. However, as discussed 703 in [RFC3325], this mechanism is intended to be used only within 704 networks of trusted SIP servers. That is, the use of this mechanism 705 is only applicable inside an administrative domain with previously 706 agreed-upon policies. 708 The relay MUST check that the originator of the PUBLISH request is 709 the owner of the recipient URI in the permission document. 710 Otherwise, the PUBLISH request SHOULD be responded with a 401 711 (Unauthorized) response and MUST NOT be processed further. 713 5.6.1.3. Return Routability 715 SIP identity provides a good authentication mechanism for incoming 716 PUBLISH requests. Nevertheless, SIP identity is not widely available 717 on the public Internet yet. That is why an authentication mechanism 718 that can already be used at this point is needed. 720 Return routability tests do not provide the same level of security as 721 SIP identity, but they provide a better-than-nothing security level 722 in architectures where the SIP identity mechanism is not available 723 (e.g., the current Internet). The relay generates an unguessable URI 724 (i.e., with a cryptographically random user part) and places it in 725 the permission document in the MESSAGE request (3). The recipient 726 needs to send a SIP PUBLISH request or an HTTP GET request to that 727 URI. Any incoming request sent to that URI SHOULD be considered 728 authenticated by the relay. 730 Note that the return routability method is the only one that 731 allows the use of HTTP URIs in permission documents. The other 732 methods require the use of SIP URIs. 734 Relays using a return routability test to perform this authentication 735 MUST send the MESSAGE request with the permission document to a SIPS 736 URI. This ensures that attackers do not get access to the 737 (unguessable) URI. Thus, the only user able to use the (unguessable) 738 URI is the receiver of the MESSAGE request. Similarly, permission 739 documents sent by relays using a return routability test MUST only 740 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 741 permissions. The user part of these URIs MUST be cryptographically 742 random with at least 32 bits of randomness. 744 Relays can transition from return routability tests to SIP identity 745 by simply requiring the use of SIP identity for incoming PUBLISH 746 requests. That is, such a relay would reject PUBLISH requests that 747 did not use SIP identity. 749 5.6.1.4. SIP Digest 751 The SIP digest mechanism can be used to authenticate the sender of a 752 PUBLISH request as long as that sender shares a secret with the 753 relay. The relay MUST check that the originator of the PUBLISH 754 request is the owner of the recipient URI in the permission document. 755 Otherwise, the PUBLISH request SHOULD be responded with a 401 756 (Unauthorized) response and MUST NOT be processed further. 758 5.7. Permission Granted Notification 760 On receiving the PUBLISH request (11), the relay sends a NOTIFY 761 request (13) to inform user A that the permission for the translation 762 has been received and that the translation logic at the relay has 763 been updated. That is, 'sip:B@example.com' has been added as a 764 recipient URI. 766 5.8. Permission Revocation 768 At any time, if a recipient wants to revoke any permission, it uses 769 the URI it received in the permission document to deny the 770 permissions it previously granted. If a recipient loses this URI for 771 some reason, it needs to wait until it receives a new request 772 produced by the translation. Such a request will contain a Trigger- 773 Consent header field with a URI. That Trigger-Consent header field 774 will have a target-uri header field parameter identifying the target 775 URI of the translation. The recipient needs to send a PUBLISH 776 request with an empty body to the URI in the Trigger-Consent header 777 field in order to receive a MESSAGE request from the relay. Such a 778 MESSAGE request will contain a permission document with a URI to 779 revoke the permission that was previously granted. 781 Figure 5 shows an example of how a user that lost the URI to revoke 782 permissions at a relay can obtain a new URI using the Trigger-Consent 783 header field of an incoming request. The user rejects an incoming 784 INVITE (1) request, which contains a Trigger-Consent header field. 785 Using the URI in the that header field, the user sends a PUBLISH 786 request (4) to the relay. On receiving the PUBLISH request (4), the 787 relay generates a MESSAGE request (6) towards the user. Finally, the 788 user revokes the permissions by sending a PUBLISH request (8) to the 789 relay. 791 Relay B@example.com 792 |(1) INVITE | 793 | Trigger-Consent: sip:123@relay.example.com 794 | ;target-uri="sip:friends@relay.example.com" 795 |---------------------------->| 796 |(2) 603 Decline | 797 |<----------------------------| 798 |(3) ACK | 799 |---------------------------->| 800 |(4) PUBLISH sip:123@relay.example.com 801 |<----------------------------| 802 |(5) 200 OK | 803 |---------------------------->| 804 |(6) MESSAGE sip:B@example | 805 | Permission Document | 806 |---------------------------->| 807 |(7) 200 OK | 808 |<----------------------------| 809 |(8) PUBLISH uri-deny | 810 |<----------------------------| 811 |(9) 200 OK | 812 |---------------------------->| 813 Figure 5: Permission Revocation 815 5.9. Request-contained URI Lists 817 In the scenarios described so far, a user adds recipient URIs to the 818 translation logic of a relay. However, the relay does not perform 819 translations towards those recipient URIs until permissions are 820 obtained. 822 URI-list services using request-contained URI lists are a special 823 case because the selection of recipient URIs is performed at the same 824 time as the communication attempt. A user places a set of recipient 825 URIs in a request and sends it to a relay so that the relay sends a 826 similar request to all those recipient URIs. 828 Relays implementing this framework and providing this type of URI- 829 list services behave in a slightly different way as the relays 830 described so far. This type of relay also maintains a list of 831 recipient URIs for which permissions have been received. Clients 832 also manipulate this list using a manipulation mechanism (e.g., 833 XCAP). Nevertheless, this list does not represent the recipient URIs 834 of every translation performed by the relay. This list just 835 represents all the recipient URIs for which permissions have been 836 received. That is, the set of URIs that will be accepted if a 837 request containing a URI-list arrives to the relay. This set of URIs 838 is a super set of the recipient URIs of any particular translation 839 the relay performs. 841 5.9.1. Relay's Behavior 843 On receiving a request-contained URI-list, the relay checks whether 844 or not it has permissions for all the URIs contained in the incoming 845 URI-list. If it does, the relay performs the translation. If it 846 lacks permissions for one of more URIs, the relay does not perform 847 the translation and returns an error response. 849 A relay that receives a request-contained URI-list with a URI for 850 which the relay has no permissions SHOULD return a 470 (Consent 851 Needed) response. The relay SHOULD add a Permission-Missing header 852 field with the URIs for which the relay has no permissions. 854 5.9.2. Definition of the 470 Response Code 856 A 470 (Consent Needed) response indicates that the request that 857 triggered the response contained a URI-list with at least a URI for 858 which the relay had no permissions. The URI or URIs for which the 859 relay had not permissions are listed in a Permission-Missing header 860 field, should the response carry one. 862 A client receiving a 470 (Consent Needed) response uses a 863 manipulation mechanism (e.g., XCAP) to add those URIs to the relay's 864 list of URIs. The relay will obtain permissions for those URIs as 865 usual. 867 5.9.3. Definition of the Permission-Missing Header Field 869 Permission-Missing header fields carry URIs for which a relay did not 870 have permissions. The following is the augmented Backus-Naur Form 871 (BNF) [RFC4234] syntax of the Permission-Missing header field. Some 872 of its elements are defined in [RFC3261]. 874 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 875 *( COMMA per-miss-spec ) 876 per-miss-spec = ( name-addr / addr-spec ) 877 *( SEMI generic-param ) 879 The following is an example of a Permission-Missing header field: 881 Permission-Missing: sip:C@example.com 883 Figure 6 shows a relay that receives a request (1) that contains URIs 884 for which the relay does not have permission. The relay rejects the 885 request with a 470 (Consent Needed) response (2). That response 886 contains a Permission-Missing header field with the URIs for which 887 there was no permission. 889 A@example.com Relay 891 |(1) INVITE | 892 | sip:B@example.com | 893 | sip:C@example.com | 894 |---------------------->| 895 |(2) 470 Consent Needed | 896 | Permission-Missing: sip:C@example.com 897 |<----------------------| 898 |(3) ACK | 899 |---------------------->| 901 Figure 6: INVITE with a URI list in its body 903 5.10. Registrations 905 Even though the example used to specify this framework has been a 906 URI-list service, this framework applies to any type of translation 907 (i.e., not only to URI-list services). Registrations are a different 908 type of translations that deserve discussion. 910 Registrations are a special type of translations. The user 911 registering has a trust relationship with the registrar in its home 912 domain. This is not the case when a user gives any type of 913 permissions to a relay in a different domain. 915 Traditionally, REGISTER transactions have performed two operations at 916 the same time: setting up a translation and authorizing the use of 917 that translation. For example, a user registering its current 918 contact URI is giving permission to the registrar to forward traffic 919 sent to the user's AoR (Address of Records) to the registered contact 920 URI. This works fine when the entity registering is the same as the 921 one that will be receiving traffic at a later point (e.g., the entity 922 receives traffic over the same connection used for the registration 923 as described in [I-D.ietf-sip-outbound]). However, this schema 924 creates some potential attacks which relate to third-party 925 registrations. 927 An attacker binds, via a registration, his or her AoR with the 928 contact URI of a victim. Now, the victim will receive unsolicited 929 traffic that was originally addressed to the attacker. 931 The process of authorizing a registration is shown in Figure 7. User 932 A performs a third-party registration (1) and receives a 202 933 (Accepted) response (2). 935 Since the relay does not have permission from 936 'sip:a@ws123.example.com' to perform translations towards that 937 recipient URI, the relay places 'sip:a@ws123.example.com' in the 938 'pending' state. Once 'sip:a@ws123.example.com' is in the 939 'Permission Pending' state, the registrar needs to ask 940 'sip:a@ws123.example.com' for permission by sending a MESSAGE request 941 (3). 943 After receiving the response from the relay (2), user A subscribes to 944 the Pending Additions event package at the registrar (4). This 945 subscription keeps the user informed about the status of the 946 permissions (e.g., granted or denied) the registrar will obtain. The 947 rest of the process is similar to the one described in Section 5. 949 A@example.com Registrar a@ws123.example.com 951 |(1) REGISTER | | 952 | Contact: sip:a@ws123.example.com | 953 |------------------>| | 954 |(2) 202 Accepted OK| | 955 |<------------------| | 956 | |(3) MESSAGE sip:a@ws123.example 957 | | Permission Document 958 | |------------------>| 959 | |(4) 200 OK | 960 | |<------------------| 961 |(5) SUBSCRIBE | | 962 | Event: pending-additions | 963 |------------------>| | 964 |(6) 200 OK | | 965 |<------------------| | 966 |(7) NOTIFY | | 967 |<------------------| | 968 |(8) 200 OK | | 969 |------------------>| | 970 | |(9) PUBLISH uri-up | 971 | |<------------------| 972 | |(10) 200 OK | 973 | |------------------>| 974 |(11) NOTIFY | | 975 |<------------------| | 976 |(12) 200 OK | | 977 |------------------>| | 979 Figure 7: Registration 981 Permission documents generated by registrars are typically very 982 general. For example, in one such document a registrar can ask a 983 recipient for permission to forward any request from any sender to 984 the recipient's URI. This is the type of granularity that this 985 framework intends to provide for registrations. Users who want to 986 define how incoming requests are treated with a finer granularity 987 (e.g., requests from user A are only accepted between 9:00 and 11:00) 988 will have to use other mechanisms such as CPL [RFC3880]. 990 Note that, as indicated previously, user agents using the same 991 connection to register and to receive traffic from the registrar, 992 as described in [I-D.ietf-sip-outbound] do not need to use the 993 mechanism described in this section. 995 A user agent being registered by a third party can be unable to use 996 the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to 997 prove to the registrar that the user agent is the owner of the URI 998 being registered (e.g., sip:user@192.0.2.1), which is the recipient 999 URI of the translation. In this case, return routability MUST be 1000 used. 1002 5.11. Relays Generating Traffic towards Recipients 1004 Relays generating traffic towards recipient need to make sure that 1005 those recipients can revoke the permissions they gave at any time. 1006 The Trigger-Consent helps achieve this. 1008 5.11.1. Relay's Behavior 1010 A relay executing a translation that involves sending a request to a 1011 URI from which permissions were obtained previously SHOULD add a 1012 Trigger-Consent header field to the request. The URI in the Trigger- 1013 Consent header field MUST have a target-uri header field parameter 1014 identifying the target URI of the translation. 1016 On receiving a PUBLISH request addressed to the URI a relay placed in 1017 a Trigger-Consent header field, the relay SHOULD send a MESSAGE 1018 request to corresponding recipient URI with a permission document. 1019 Therefore, the relay needs to be able to correlate the URI it places 1020 in the Trigger-Consent header field with the recipient URI of the 1021 translation. 1023 5.11.2. Definition of the Trigger-Consent Header Field 1025 The following is the augmented Backus-Naur Form (BNF) [RFC4234] 1026 syntax of the Trigger-Consent header field. Some of its elements are 1027 defined in [RFC3261]. 1029 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 1030 *( COMMA trigger-cons-spec ) 1031 trigger-cons-spec = ( SIP-URI / SIPS-URI ) 1032 *( SEMI trigger-param ) 1033 trigger-param = target-uri / generic-param 1034 target-uri = "target-uri" EQUAL 1035 LDQUOT *( qdtext / quoted-pair ) RDQUOT 1037 The target-uri header field parameter MUST contain a URI. 1039 The following is an example of a Trigger-Consent header field: 1041 Trigger-Consent: sip:123@relay.example.com 1042 ;target-uri="sip:friends@relay.example.com" 1044 6. IANA Considerations 1046 The following sections request the IANA to register a SIP response 1047 code, two SIP header fields, and a SIP header field parameter. 1049 6.1. Registration of the 470 Response Code 1051 The IANA is requested to add the following new response code to the 1052 Methods and Response Codes subregistry under the SIP Parameters 1053 registry. 1055 Response Code Number: 470 1056 Default Reason Phrase: Consent Needed 1057 Reference: [RFCxxxx] 1059 Note to the RFC editor: substitute xxxx with the RFC number of this 1060 document. 1062 6.2. Registration of the Trigger-Consent Header Field 1064 The IANA is requested to add the following new SIP header field to 1065 the Header Fields subregistry under the SIP Parameters registry. 1067 Header Name: Trigger-Consent 1068 Compact Form: (none) 1069 Reference: [RFCxxxx] 1071 Note to the RFC editor: substitute xxxx with the RFC number of this 1072 document. 1074 6.3. Registration of the target-uri Header Field Parameter 1076 The IANA is requested to register the 'target-uri' Trigger-Consent 1077 header field parameter under the Header Field Parameters and 1078 Parameter Values subregistry within the SIP Parameters registry: 1080 Predefined 1081 Header Field Parameter Name Values Reference 1082 ---------------------------- --------------- --------- --------- 1083 Trigger-Consent target-uri No [RFCxxxx] 1085 Note to the RFC editor: substitute xxxx with the RFC number of this 1086 document. 1088 7. Security Considerations 1090 Security has been discussed throughout the whole document. However, 1091 there are some issues that deserve special attention. 1093 The specifications of mechanisms to manipulate translation logic at 1094 relays usually stress the importance of client authentication and 1095 authorization. Having relays authenticate and authorize clients 1096 manipulating their translation logic keeps unauthorized clients from 1097 adding recipients to a translation. However, this does not prevent 1098 authorized clients to add recipients to a translation without their 1099 consent. Additionally, some relays provide web interfaces for any 1100 client to add new recipients to the translation (e.g., many email 1101 mailing lists are operated in this way). In this situation, every 1102 client is considered authorized to manipulate the translation logic 1103 at the relay. This makes the use of this framework even more 1104 important. Therefore, it is RECOMMENDED that relays performing 1105 translations implement this framework. 1107 As pointed out in Section 5.6.1.3, when return routability tests are 1108 used to authenticate recipients granting or denying permissions, the 1109 URIs used to grant or deny permissions need to be protected from 1110 attackers. SIPS URIs provide a good tool to meet this requirement, 1111 as described in [I-D.ietf-sipping-consent-format]. When store-and- 1112 forward servers are used, the interface between a user agent and its 1113 store-and-forward server is frequently not based on SIP. In such 1114 case, SIPS cannot be used to secure those URIs. Implementations of 1115 store-and-forward servers MUST provide a mechanism for delivering 1116 encrypted and integrity-protected messages to their user agents. 1118 The information provided by the Pending Additions event package can 1119 be sensitive. For this reason, as described in 1120 [I-D.ietf-sipping-pending-additions], relays need to use strong means 1121 for authentication and information confidentiality. SIPS URIs are a 1122 good mechanism to meet this requirement. 1124 8. Acknowledgments 1126 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 1127 useful ideas on this document. Ben Campbell, AC Mahendran, Keith 1128 Drage, and Mary Barnes performed a thorough review of this document. 1130 9. References 1131 9.1. Normative References 1133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1134 Requirement Levels", BCP 14, RFC 2119, March 1997. 1136 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1137 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1138 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1140 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1141 A., Peterson, J., Sparks, R., Handley, M., and E. 1142 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1143 June 2002. 1145 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1146 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1147 for Instant Messaging", RFC 3428, December 2002. 1149 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1150 Specifications: ABNF", RFC 4234, October 2005. 1152 [I-D.ietf-sipping-uri-services] 1153 Camarillo, G. and A. Roach, "Framework and Security 1154 Considerations for Session Initiation Protocol (SIP) 1155 Uniform Resource Identifier (URI)-List Services", 1156 draft-ietf-sipping-uri-services-06 (work in progress), 1157 September 2006. 1159 [I-D.ietf-sipping-consent-format] 1160 Camarillo, G., "A Document Format for Requesting Consent", 1161 draft-ietf-sipping-consent-format-03 (work in progress), 1162 April 2007. 1164 [I-D.ietf-sipping-pending-additions] 1165 Camarillo, G., "The Session Initiation Protocol (SIP) 1166 Pending Additions Event Package", 1167 draft-ietf-sipping-pending-additions-02 (work in 1168 progress), April 2007. 1170 9.2. Informative References 1172 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1173 Extensions to the Session Initiation Protocol (SIP) for 1174 Asserted Identity within Trusted Networks", RFC 3325, 1175 November 2002. 1177 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1178 Language (CPL): A Language for User Control of Internet 1179 Telephony Services", RFC 3880, October 2004. 1181 [RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements 1182 for Consent-Based Communications in the Session Initiation 1183 Protocol (SIP)", RFC 4453, April 2006. 1185 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1186 Authenticated Identity Management in the Session 1187 Initiation Protocol (SIP)", RFC 4474, August 2006. 1189 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1190 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1192 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 1193 for Representing Resource Lists", RFC 4826, May 2007. 1195 [I-D.ietf-sip-outbound] 1196 Jennings, C. and R. Mahy, "Managing Client Initiated 1197 Connections in the Session Initiation Protocol (SIP)", 1198 draft-ietf-sip-outbound-08 (work in progress), March 2007. 1200 Authors' Addresses 1202 Jonathan Rosenberg 1203 Cisco Systems 1204 600 Lanidex Plaza 1205 Parsippany, NJ 07054 1206 US 1208 Phone: +1 973 952-5000 1209 Email: jdrosen@cisco.com 1210 URI: http://www.jdrosen.net 1212 Gonzalo Camarillo (editor) 1213 Ericsson 1214 Hirsalantie 11 1215 Jorvas 02420 1216 Finland 1218 Email: Gonzalo.Camarillo@ericsson.com 1219 Dean Willis 1220 Unaffiliated 1221 3100 Independence Pkwy #311-164 1222 Plano, TX 75075 1223 USA 1225 Email: dean.willis@softarmor.com 1227 Full Copyright Statement 1229 Copyright (C) The IETF Trust (2007). 1231 This document is subject to the rights, licenses and restrictions 1232 contained in BCP 78, and except as set forth therein, the authors 1233 retain all their rights. 1235 This document and the information contained herein are provided on an 1236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1238 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1239 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1240 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1243 Intellectual Property 1245 The IETF takes no position regarding the validity or scope of any 1246 Intellectual Property Rights or other rights that might be claimed to 1247 pertain to the implementation or use of the technology described in 1248 this document or the extent to which any license under such rights 1249 might or might not be available; nor does it represent that it has 1250 made any independent effort to identify any such rights. Information 1251 on the procedures with respect to rights in RFC documents can be 1252 found in BCP 78 and BCP 79. 1254 Copies of IPR disclosures made to the IETF Secretariat and any 1255 assurances of licenses to be made available, or the result of an 1256 attempt made to obtain a general license or permission for the use of 1257 such proprietary rights by implementers or users of this 1258 specification can be obtained from the IETF on-line IPR repository at 1259 http://www.ietf.org/ipr. 1261 The IETF invites any interested party to bring to its attention any 1262 copyrights, patents or patent applications, or other proprietary 1263 rights that may cover technology that may be required to implement 1264 this standard. Please address the information to the IETF at 1265 ietf-ipr@ietf.org. 1267 Acknowledgment 1269 Funding for the RFC Editor function is provided by the IETF 1270 Administrative Support Activity (IASA).