idnits 2.17.1 draft-ietf-sip-consent-framework-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1086. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 17, 2006) is 6431 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) -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 928 ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '4') ** Obsolete normative reference: RFC 4234 (ref. '6') (Obsoleted by RFC 5234) ** Downref: Normative reference to an Informational RFC: RFC 4453 (ref. '7') ** Obsolete normative reference: RFC 4474 (ref. '8') (Obsoleted by RFC 8224) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-consent-format-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-pending-additions-00 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: March 21, 2007 G. Camarillo, Ed. 4 Ericsson 5 D. Willis 6 Cisco Systems 7 September 17, 2006 9 A Framework for Consent-Based Communications in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sip-consent-framework-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 21, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The Session Initiation Protocol (SIP) supports communications across 45 many media types, including real-time audio, video, text, instant 46 messaging, and presence. In its current form, it allows session 47 invitations, instant messages, and other requests to be delivered 48 from one party to another without requiring explicit consent of the 49 recipient. Without such consent, it is possible for SIP to be used 50 for malicious purposes, including amplification, and DoS (Denial of 51 Service) attacks. This document identifies a framework for consent- 52 based communications in SIP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 58 3. Relays and Translations . . . . . . . . . . . . . . . . . . . 4 59 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 6 61 4.2. Consenting Manipulations on a Relay's Transaction Logic . 6 62 4.3. Store-and-forward Servers . . . . . . . . . . . . . . . . 7 63 4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 8 64 5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 9 66 5.2. Subscription to the Permission Status . . . . . . . . . . 10 67 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 10 68 5.4. Permission Document Structure . . . . . . . . . . . . . . 11 69 5.5. Permission Requested Notification . . . . . . . . . . . . 13 70 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 13 71 5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 13 72 5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 13 73 5.6.3. Return Routability . . . . . . . . . . . . . . . . . . 14 74 5.6.4. SIP Digest . . . . . . . . . . . . . . . . . . . . . . 15 75 5.7. Permission Granted Notification . . . . . . . . . . . . . 15 76 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 15 77 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 16 78 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 18 79 5.11. Relays Generating Traffic towards Recipients . . . . . . . 20 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 87 Intellectual Property and Copyright Statements . . . . . . . . . . 25 89 1. Introduction 91 The Session Initiation Protocol (SIP) [3] supports communications 92 across many media types, including real-time audio, video, text, 93 instant messaging, and presence. This communication is established 94 by the transmission of various SIP requests (such as INVITE and 95 MESSAGE [5]) from an initiator to the recipient with whom 96 communication is desired. Although a recipient of such a SIP request 97 can reject the request, and therefore decline the session, a SIP 98 network will deliver a SIP request to its recipients without their 99 explicit consent. 101 Receipt of these requests without explicit consent can cause a number 102 of problems in SIP networks. These include amplification and DoS 103 (Denial of Service) attacks. These problems are described in more 104 detail in a companion requirements document [7]. 106 This specification defines a basic framework for adding consent-based 107 communication to SIP. 109 2. Definitions and Terminology 111 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 112 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 113 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 114 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 115 compliant implementations. 117 Recipient URI: The Request-URI of an outgoing request sent by an 118 entity (e.g., a user agent or a proxy). The sending of such 119 request may have been the result of a translation operation. 121 Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User 122 Agent), or some hybrid, that receives a request, translates its 123 Request-URI into one or more next-hop URIs (i.e., recipient URIs), 124 and delivers the request to those URIs. 126 Target URI: The Request-URI of an incoming request that arrives to a 127 relay that will perform a translation operation. 129 Translation operation: Operation by which a relay translates the 130 request URI of an incoming request (i.e., the target URI) into one 131 or more URIs (i.e., recipient URIs) which are used as the request 132 URIs of one or more outgoing requests. 134 3. Relays and Translations 136 Relays play a key role in this framework. A relay is defined as any 137 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 138 hybrid, which receives a request, translates its Request-URI into one 139 or more next hop URIs, and delivers the request to those URIs. The 140 Request-URI of the incoming request is referred to as 'target URI' 141 and the destination URIs of the outgoing requests are referred to as 142 'recipient URIs', as shown in Figure 1. 144 +---------------+ 145 | | recipient URI 146 | |----------------> 147 target URI | Translation | 148 -------------->| Operation | recipient URI 149 | |----------------> 150 | | 151 +---------------+ 153 Figure 1: Translation operation 155 Thus, an essential aspect of a relay is that of translation. When a 156 relay receives a request, it translates, following its translation 157 logic, the Request-URI into one or more additional URIs. That is, 158 the relay can create outgoing requests to one or more additional 159 URIs. The translation operation is what creates the consent problem. 161 Additionally, since the translation operation can result in more than 162 one URI, it is also the source of amplification. Servers that do not 163 perform translations, such as outbound proxy servers, do not cause 164 amplification. 166 Since the translation operation is based on local policy or local 167 data (such as registrations), it is the vehicle by which a request is 168 delivered directly to an endpoint, when it would not otherwise be 169 possible to. In other words, if a spammer has the address of a user, 170 'user@example.com', it cannot deliver a MESSAGE request to the UA 171 (User Agent) of that user without having access to the registration 172 data that maps 'user@example.com' to the user agent on which that 173 user is present. Thus, it is the usage of this registration data, 174 and more generally, the translation logic, which must be authorized 175 in order to prevent undesired communications. Of course, if the 176 spammer knows the address of the user agent, it will be able to 177 deliver requests directly to it. 179 Figure 2 shows a relay that performs translations. The user agent 180 client in the figure sends a SIP request to a URI representing a 181 resource in the domain 'example.com' (resource@example.com). This 182 request may pass through a local outbound proxy (not shown), but 183 eventually arrives at a server authoritative for the domain 184 'example.com'. This server, which acts as a relay, performs a 185 translation operation, translating the target URI into one or more 186 recipient URIs, which may or may not belong to the domain 187 'example.com'. This relay may be, for instance, a proxy server or a 188 URI-list service [11]. 190 +-------+ 191 | | 192 >| UA | 193 / | | 194 / +-------+ 195 / 196 / 197 +-----------------------+ / 198 | | / 199 +-----+ | Relay | / +-------+ 200 | | | |/ | | 201 | UA |------>| |-------->| Proxy | 202 | | |+---------------------+|\ | | 203 +-----+ || Translation || \ +-------+ 204 || Logic || \ 205 |+---------------------+| \ [...] 206 +-----------------------+ \ 207 \ 208 \ +-------+ 209 \ | | 210 >| B2BUA | 211 | | 212 +-------+ 214 Figure 2: Relay performing a translation 216 This framework allows potential recipients of a translation to agree 217 to be actual recipients by giving the relay performing the 218 translation permission to send them traffic. 220 4. Architecture 222 Figure 3 shows the architectural elements of this framework. 223 Section 4.1 describes the role of permissions at a relay. 224 Section 4.2 discusses the actions taken by a relay when its 225 translation logic is manipulated by a client. Section 4.3 discusses 226 store-and-forward servers and their functionality. Section 4.4 227 describes how potential recipients can grant a relay permissions to 228 add them to the relay's translation logic. 230 +-----------------------+ Permission +-------------+ 231 | | Request | | 232 +--------+ | Relay |----------->| Store & Fwd | 233 | | | | | Server | 234 | Client | | | | | 235 | | |+-------+ +-----------+| +-------------+ 236 +--------+ ||Transl.| |Permissions|| | 237 | ||Logic | | || Permission | 238 | |+-------+ +-----------+| Request | 239 | +-----------------------+ V 240 | ^ ^ +-------------+ 241 | Manipulation | | Permission Grant | | 242 +---------------+ +-------------------| Recipient | 243 | | 244 +-------------+ 246 Figure 3: Reference Architecture 248 4.1. Permissions at a Relay 250 Relays implementing this framework obtain and store permissions 251 associated to their translation logics. These permissions indicate 252 if a particular recipient has agreed to receive traffic or not at any 253 given time. Recipients that have not given the relay permission to 254 send them traffic are simply ignored by the relay when performing a 255 translation. 257 Permissions are valid as long as the context where they were granted 258 is valid or until they are revoked. For example, the permissions 259 obtained by a URI-list SIP service that distributes MESSAGE requests 260 to a set of recipients will be valid as long as the URI-list SIP 261 service exists or until the permissions are revoked. 263 4.2. Consenting Manipulations on a Relay's Transaction Logic 265 This framework aims to ensure that any particular relay only performs 266 translations towards destinations that have given the relay 267 permission to perform such a translation. Consequently, when the 268 translation logic of a relay is manipulated (e.g., a new recipient 269 URI is added), the relay obtains permission from the new recipient in 270 order to install the new translation logic. Relays ask recipients 271 for permission using MESSAGE [5] requests. 273 For example, the relay hosting the URI-list service at 274 'friends@example.com' performs a translation from that URI to a set 275 of recipient URIs. When a client (e.g., the administrator of that 276 URI-list service) adds 'bob@example.org' as a new recipient URI, the 277 relay sends a MESSAGE request to 'bob@example.org' asking whether or 278 not it is OK to perform the translation from 'friends@example.com' to 279 'bob@example.org'. The MESSAGE request carries in its message body a 280 permission document that describes the translation for which 281 permissions are being requested and a human readable part that also 282 describes the translation. If the answer is positive, the new 283 translation logic is installed at the relay. That is, the new 284 recipient URI is added. 286 The human-readable part is included so that user agents that do 287 not understand permission documents can still process the request 288 and display it in a sensible way to the user. 290 Note that the mechanism to be used to manipulate the translation 291 logic of a particular relay depends on the relay. Two existing 292 mechanisms to manipulate translation logic are XCAP [9] and REGISTER 293 transactions. 295 In any case, relays implementing this framework SHOULD have a means 296 to indicate that a particular recipient URI is in the states 297 specified in [13] (i.e., pending, waiting, error, denied, or 298 granted). 300 4.3. Store-and-forward Servers 302 When a MESSAGE request with a permission document arrives to the 303 recipient URI to which it was sent by the relay, the receiving user 304 can grant or deny the permission needed to perform the translation. 305 Nevertheless, users are not on-line all the time and, so, sometimes 306 are not able to receive MESSAGE requests. 308 This issue is also found in presence, where a user's status is 309 reported by a presence server instead of by the user's user agents, 310 which can go on and off line. Similarly, store-and-forward servers 311 are network elements that act as SIP user agents and handle MESSAGE 312 requests for a user. A store-and-forward server stores incoming 313 MESSAGE requests when the user is unavailable and delivers them when 314 the user is available again. 316 There are several mechanisms to implement store-and-forward message 317 services (e.g., with an instant message to email gateway). Any of 318 these mechanisms can be used between a user agent and its store-and- 319 forward server as long as they agree on which mechanism to use. 320 Therefore, this framework does not make any recommendation on the 321 interface between user agents and their store-and-forward servers. 323 Note that the same store-and-forward message service can handle 324 all incoming MESSAGE requests for a user while this is off line, 325 not only those MESSAGE requests with a permission document in 326 their bodies. 328 4.4. Recipients Grant Permissions 330 Relays include in the permission documents they generate URIs that 331 can be used by the recipient of the document to grant or deny the 332 relay the permission described in the document. Relays always 333 include SIP URIs and may include HTTP [2] URIs for this purpose. 334 Consequently, recipients provide relays with permissions using SIP 335 PUBLISH requests or HTTP GET requests. 337 5. Framework Operations 339 This section specifies this consent framework using an example of the 340 prototypical call flow. The elements described in Section 4 (i.e., 341 relays, translations, and permission servers) play an essential role 342 in this call flow. 344 Figure 4 shows the complete process to add a recipient URI 345 ('B@example.com') to the translation logic of a relay. User A 346 attempts to add 'B@example.com' as a new recipient URI to the 347 translation logic of the relay (1). User A uses XCAP [9] and the XML 348 (Extensible Markup Language) format for representing resource lists 349 [10] to perform this addition. Since the relay does not have 350 permission from 'B@example.com' to perform translations towards that 351 URI, the relay places 'B@example.com' in the pending state, as 352 specified in [13]. 354 A@example.com Relay B's Store & Fwd B@example.com 355 Server 357 |(1) Add Recipient B@example.com | | 358 |--------------->| | | 359 |(2) HTTP 202 (Accepted) | | 360 |<---------------| | | 361 | |(3) MESSAGE B@example | 362 | |Permission Document | 363 | |--------------->| | 364 | |(4) 202 Accepted| | 365 | |<---------------| | 366 |(5) SUBSCRIBE | | | 367 |Event: pending-additions | | 368 |--------------->| | | 369 |(6) 200 OK | | | 370 |<---------------| | | 371 |(7) NOTIFY | | | 372 |<---------------| | | 373 |(8) 200 OK | | | 374 |--------------->| | | 375 | | | |User B goes 376 | | | | on line 377 | | |(9) Request for | 378 | | | stored messages 379 | | |<---------------| 380 | | |(10) Delivery of| 381 | | | stored messages 382 | | |--------------->| 383 | |(11) PUBLISH uri-up | 384 | |Permission Document | 385 | |<--------------------------------| 386 | |(12) 200 OK | | 387 | |-------------------------------->| 388 |(13) NOTIFY | | | 389 |<---------------| | | 390 |(14) 200 OK | | | 391 |--------------->| | | 393 Figure 4: Prototypical call flow 395 5.1. Amplification Avoidance 397 Once 'B@example.com' is in the pending state, the relay needs to ask 398 user B for permission by sending a MESSAGE request to 399 'B@example.com'. However, the relay needs to ensure that it is not 400 used as an amplifier to launch amplification attacks. 402 In such an attack, the attacker would add a large number of recipient 403 URIs to the translation logic of a relay. The relay would then send 404 a MESSAGE request to each of those URIs. The bandwidth generated by 405 the relay would be much higher than the bandwidth used by the 406 attacker to add those URIs to the translation logic of the relay. 408 This framework uses a credit-based authorization mechanism to avoid 409 the attack just described. It requires users adding new recipient 410 URIs to a translation to generate an amount of bandwidth that is 411 comparable to the bandwidth the relay will generate when sending 412 MESSAGE requests towards those recipient URIs. When XCAP is used, 413 this requirement is met by not allowing clients to add more than one 414 URI per HTTP transaction. When a REGISTER transaction is used, this 415 requirement is met by not allowing clients to register more than one 416 contact per REGISTER transaction. 418 Therefore, relays implementing this framework MUST NOT allow clients 419 to add more than one URI per transaction. If a client using XCAP 420 attempts to add more than one URI in a single HTTP transaction, the 421 XCAP server SHOULD return an HTTP 409 (Conflict) response. The XCAP 422 server SHOULD describe the reason for the refusal in an XML body 423 using the element, as described in [9]. If a 424 client attempts to register more than one contact in a single 425 REGISTER transaction, the registrar SHOULD return a SIP 403 response 426 and explain the reason for the refusal in its reason phrase (e.g., 427 Maximum one contact per registration). 429 5.2. Subscription to the Permission Status 431 Clients can use the Pending Additions SIP event package [13] to be 432 informed about the status of the operations they requested. That is, 433 the client will be informed when an operation (e.g., the addition of 434 a URI to the translation logic of a relay) is authorized (and thus 435 executed) or rejected. Clients use the target URI of the SIP 436 translation being manipulated to subscribe to the 'pending-additions' 437 event package. 439 In our example, after receiving the response from the server (2), 440 user A subscribes to the Pending Additions event package at the relay 441 (5). This subscription keeps user A informed about the status of the 442 permissions (e.g., granted or denied) the relay will obtain. 444 5.3. Request for Permission 446 Relays MUST obtain permissions from potential recipients before 447 adding them to their translation logics. Relays request permissions 448 from potential recipients using MESSAGE requests. 450 MESSAGE requests sent to request permissions MUST include a 451 permission document and SHOULD include a human-readable part in their 452 bodies. MESSAGE requests also carry a body part that contains the 453 same information as the permission document but in a human-readable 454 format so that user agents that do not understand permission 455 documents can still process the request and display it in a sensible 456 way to the user. 458 Section 5.6 describes the methods a relay can use to authenticate 459 recipients giving the relay permission to perform a particular 460 translation. These methods are SIP identity [8], P-Asserted-Identity 461 [4], a return routability test, or SIP digest. 463 Relays that use the method consisting of a return routability test 464 have to send their MESSAGE requests to a SIPS URI, as specified in 465 Section 5.6. 467 In our example, on receiving the request to add User B to the 468 translation logic of the relay (1), the relay generates a MESSAGE 469 request (3) towards 'B@example.com'. This MESSAGE request carries a 470 permission document, which describes the translation that needs to be 471 authorized and carries a set of URIs to be used by the recipient to 472 grant or to deny the relay permission to perform that translation. 473 User B will authorize the translation by using one of those URIs, as 474 described in Section 5.6. The MESSAGE request also carry a body part 475 that contains the same information as the permission document but in 476 a human-readable format. 478 When User B uses one of the URIs in the permission document to grant 479 or deny permissions, the relay needs to make sure that it was 480 actually User B the one using that URI, and not an attacker. The 481 relay can use any of the methods described in Section 5.6 to 482 authenticate the permission document. 484 5.4. Permission Document Structure 486 A permission document is the XML representation of a permission. A 487 permission document contains several pieces of data: 489 Identity of the Sender: A URI representing the identity of the sender 490 for whom permissions are granted. 492 Identity of the Original Recipient: A URI representing the identity 493 of the original recipient, which is used as the input for the 494 translation operation. This is also called the target URI. 496 Identity of the Final Recipient: A URI representing the result of the 497 translation. The permission grants ability for the sender to send 498 requests to the target URI, and for a relay receiving those 499 requests to forward them to this URI. This is also called the 500 recipient URI. 502 URIs to Grant Permission: URIs that recipients can use to grant the 503 relay permission to perform the translation described in the 504 document. At least one of these URIs MUST be a SIP or SIPS URI. 505 HTTP and HTTPS URIs MAY also be used. 507 URIs to Deny Permission: URIs that recipients can use to deny the 508 relay permission to perform the translation described in the 509 document. At least one of these URIs MUST be a SIP or SIPS URI. 510 HTTP and HTTPS URIs MAY also be used. 512 Permission documents may contain wildcards. For example, a 513 permission document may request permission for any relay to forward 514 requests coming from a particular sender to a particular recipient. 515 Such a permission document would apply to any target URI. That is, 516 the field containing the identity of the original recipient would 517 match any URI. However, the recipient URI MUST NOT be wildcarded. 519 Entities implementing this framework MUST support the format for 520 permission documents defined in [12]. 522 In our example, the permission document in the MESSAGE request (3) 523 sent by the relay contains the following values: 525 Identity of the Sender: Any. 527 Identity of the Original Recipient: friends@example.com 529 Identity of the Final Recipient: B@example.com 531 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 533 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 535 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 537 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 539 It is expected that the Sender field often contains a wildcard. 540 However, scenarios involving request-contained URI lists, such as the 541 one described in Section 5.9, may require permission documents that 542 apply to a specific sender. Of course, in cases where the identity 543 of the sender matters, relays MUST authenticate senders. 545 5.5. Permission Requested Notification 547 On receiving the MESSAGE request (3), User B's store-and-forward 548 server stores it because User B is off line at that point. When User 549 B goes on line, User B fetches all the requests its store-and-forward 550 server has stored (9). 552 5.6. Permission Grant 554 A client gives a relay permission to execute the translation 555 described in a permission document by sending a SIP PUBLISH or an 556 HTTP GET request to one of the URIs to grant permissions contained in 557 the document. Similarly, a client denies a relay permission to 558 execute the translation described in a permission document by sending 559 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 560 permissions contained in the document. 562 In our example, User B obtains the permission document (10) that was 563 received earlier by its store-and-forward server in the MESSAGE 564 request (3). User B authorizes the translation described in the 565 permission document received by sending a PUBLISH request (11) to the 566 SIP URI to grant permissions contained in the permission document. 568 Relays need to ensure that the SIP PUBLISH or the HTTP GET request 569 received was generated by the recipient of the translation and not by 570 an attacker. Relays can use four methods to authenticate those 571 requests. SIP identity, P-Asserted-Identity [4], a return 572 routability test, or SIP digest. While return routability tests can 573 be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP 574 identity, P-Asserted-Identity, and SIP digest can only be used to 575 authenticate SIP PUBLISH requests. SIP digest can only be used to 576 authenticate clients that share a secret with the relay (e.g., 577 clients that are in the same domain as the relay). 579 5.6.1. SIP Identity 581 The SIP identity [8] mechanism can be used to authenticate the sender 582 of a PUBLISH request. The relay MUST check that the originator of 583 the PUBLISH request is the owner of the recipient URI in the 584 permission document. Otherwise, the PUBLISH request SHOULD be 585 responded with a 401 (Unauthorized) response and MUST NOT be 586 processed further. 588 5.6.2. P-Asserted-Identity 590 The P-Asserted-Identity [4] mechanism can also be used to 591 authenticate the sender of a PUBLISH request. However, as discussed 592 in RFC 3325 [4], this mechanism should only be used within networks 593 of trusted SIP servers. That is, the use of this mechanism is only 594 applicable inside an administrative domain with previously agreed- 595 upon policies. 597 The relay MUST check that the originator of the PUBLISH request is 598 the owner of the recipient URI in the permission document. 599 Otherwise, the PUBLISH request SHOULD be responded with a 401 600 (Unauthorized) response and MUST NOT be processed further. 602 5.6.3. Return Routability 604 SIP identity provides a good authentication mechanism for incoming 605 PUBLISH requests. Nevertheless, SIP identity is not widely available 606 on the public Internet yet. That is why an authentication mechanism 607 that can already be used at this point is needed. 609 Return routability tests do not provide the same level of security as 610 SIP identity, but they provide a good-enough security level in 611 architectures where the SIP identity mechanism is not available 612 (e.g., the current Internet). The relay generates an unguessable URI 613 (i.e., with a cryptographically random user part) and places it in 614 the permission document in the MESSAGE request (3). The recipient 615 needs to send a SIP PUBLISH request or an HTTP GET request to that 616 URI. Any incoming request sent to that URI SHOULD be considered 617 authenticated by the relay. 619 Note that the return routability method is the only one that 620 allows the use of HTTP URIs in permission documents. The other 621 methods require the use of SIP URIs. 623 Relays using a return routability test to perform this authentication 624 MUST send the MESSAGE request with the permission document to a SIPS 625 URI. This ensures that attackers do not get access to the 626 (unguessable) URI. Thus, the only user able to use the (unguessable) 627 URI is the receiver of the MESSAGE request. Similarly, permission 628 documents sent by relays using a return routability test MUST only 629 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 630 permissions. The user part of these URIs MUST be cryptographically 631 random with at least 32 bits of randomness. 633 Relays can transition from return routability tests to SIP identity 634 by simply requiring the use of SIP identity for incoming PUBLISH 635 requests. That is, such a relay would reject PUBLISH requests that 636 did not use SIP identity. 638 5.6.4. SIP Digest 640 The SIP digest mechanism can be used to authenticate the sender of a 641 PUBLISH request as long as that sender shares a secret with the 642 relay. The relay MUST check that the originator of the PUBLISH 643 request is the owner of the recipient URI in the permission document. 644 Otherwise, the PUBLISH request SHOULD be responded with a 401 645 (Unauthorized) response and MUST NOT be processed further. 647 5.7. Permission Granted Notification 649 On receiving the PUBLISH request (11), the relay sends a NOTIFY 650 request (13) to inform user A that the permission for the translation 651 has been received and that the translation logic at the relay has 652 been updated. That is, 'B@example.com' has been added as a recipient 653 URI. 655 5.8. Permission Revocation 657 At any time, if a client wants to revoke any permission, it uses the 658 URI it received in the permission document to deny the permissions it 659 previously granted. If a client loses this URI for some reason, it 660 needs to wait until it receives a new request produced by the 661 translation. Such a request will contain a Trigger-Consent header 662 field with a URI. That URI will have an escaped Refer-To header 663 field identifying the client (i.e., the recipient of the 664 translation). The client needs to send a REFER request to the URI in 665 the Trigger-Consent header field in order to receive a MESSAGE 666 request from the relay. Such a MESSAGE request will contain a 667 permission document with a URI to revoke the permission that was 668 previously granted. 670 Figure 5 shows an example of how a user that lost the URI to revoke 671 permissions at a relay can obtain a new URI using the Trigger-Consent 672 header field of an incoming request. The user rejects an incoming 673 INVITE (1) request, which contains a Trigger-Consent header field. 674 Using the URI in the that header field, the user sends a REFER 675 request (4) to the relay. On receiving the REFER request (4), the 676 relay generates a MESSAGE request (6) towards the user. Finally, the 677 user revokes the permissions by sending a PUBLISH request (8) to the 678 relay. 680 Relay B@example.com 682 |(1) INVITE | 683 | Trigger-Consent: <123@relay.example.com> 684 | ?Refer-To= 685 |---------------------------->| 686 |(2) 603 Decline | 687 |<----------------------------| 688 |(3) ACK | 689 |---------------------------->| 690 |(4) REFER 123@relay.example.com 691 | Refer-To: B@example.com | 692 |<----------------------------| 693 |(5) 200 OK | 694 |---------------------------->| 695 |(6) MESSAGE B@example | 696 | Permission Document | 697 |---------------------------->| 698 |(7) 200 OK | 699 |<----------------------------| 700 |(8) PUBLISH uri-deny | 701 |<----------------------------| 702 |(9) 200 OK | 703 |---------------------------->| 705 Figure 5: Permission Revocation 707 5.9. Request-contained URI Lists 709 In the scenarios described so far, a user adds recipient URIs to the 710 translation logic of a relay. However, the relay does not perform 711 translations towards those URIs until permissions are obtained. 713 URI-list services using request-contained URI lists are a special 714 case because the selection of recipient URIs is performed at the same 715 time as the communication attempt. A user places a set of recipient 716 URIs in a request and sends it to a relay so that the relay sends a 717 similar request to all those recipient URIs. 719 Relays implementing this framework and providing this type of URI- 720 list services behave in a slight different way as the relays 721 described so far. This type of relay also maintains a list of 722 recipient URIs for which permissions have been received. Clients 723 also manipulate this list using a manipulation mechanism (e.g., 724 XCAP). Nevertheless, this list does not represent the recipient URIs 725 of every translation performed by the relay. This list just 726 represents all the recipient URIs for which permissions have been 727 received. That is, the set of URIs that will be accepted if a 728 request containing a URI-list arrives to the relay. This set of URIs 729 is a super set of the recipient URIs of any particular translation 730 the relay performs. 732 On receiving a request-contained URI-list, the relay checks whether 733 or not it has permissions for all the URIs contained in the incoming 734 URI-list. If it does, the relay performs the translation. If it 735 lacks permissions for one of more URIs, the relay does not perform 736 the translation and returns an error response. 738 A relay that receives a request-contained URI-list with a URI for 739 which the relay has no permissions SHOULD return a 470 (Consent 740 Needed) response. The relay SHOULD add a Permission-Missing header 741 field with the URIs for which the relay has no permissions. 743 A client receiving such a response uses a manipulation mechanism 744 (e.g., XCAP) to add those URIs to the relay's list of URIs. The 745 relay obtains permissions for those URIs as usual. 747 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 748 the Permission-Missing header field. Some of its elements are 749 defined in RFC 3261 [3]. 751 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 752 *( COMMA per-miss-spec ) 753 per-miss-spec = ( name-addr / addr-spec ) 754 *( SEMI generic-param ) 756 The following is an example of a Permission-Missing header field: 758 Permission-Missing: 760 Figure 6 shows a relay that receives a request (1) that contains URIs 761 for which the relay does not have permission. The relay rejects the 762 request with a 470 (Consent Needed) response (2). That response 763 contains a Permission-Missing header field with the URIs for which 764 there was no permission. 766 A@example.com Relay 768 |(1) INVITE | 769 | B@example.com | 770 | C@example.com | 771 |---------------------->| 772 |(2) 470 Consent Needed | 773 | Permission-Missing: C@example.com 774 |<----------------------| 775 |(3) ACK | 776 |---------------------->| 778 Figure 6: INVITE with a URI list in its body 780 5.10. Registrations 782 Registrations are a special type of translations. The user 783 registering has a trust relationship with the registrar in its home 784 domain. This is not the case when a user gives any type of 785 permissions to a relay in a different domain. 787 Traditionally, REGISTER transactions have performed two operations at 788 the same time: setting up a translation and authorizing the use of 789 that translation. For example, a user registering its current 790 contact URI is giving permission to the registrar to forward traffic 791 sent to the user's AoR (Address of Records) to the registered contact 792 URI. This works fine when the entity registering is the same as the 793 one that will be receiving traffic at a later point (e.g., the entity 794 receives traffic over the same connection used for the registration 795 as described in [15]). However, this schema creates some potential 796 attacks which relate to third-party registrations. 798 An attacker binds, via a registration, his or her AoR with the 799 contact URI of a victim. Now, the victim will receive unsolicited 800 traffic that was originally addressed to the attacker. 802 The process of authorizing a registration is shown in Figure 7. User 803 A performs a third-party registration (1) and receives a 202 804 (Accepted) response (2). 806 Since the relay does not have permission from 'a@ws123.example.com' 807 to perform translations towards that URI, the relay places 808 'a@ws123.example.com' in the 'pending' state. Once 809 'a@ws123.example.com' is in the 'Permission Pending' state, the 810 registrar needs to ask 'a@ws123.example.com' for permission by 811 sending a MESSAGE request (3). 813 After receiving the response from the server (2), user A subscribes 814 to the Pending Additions event package at the registrar (4). This 815 subscription keeps the user informed about the status of the 816 permissions (e.g., granted or denied) the registrar will obtain. The 817 rest of the process is similar to the one described in Section 5. 819 A@example.com Registrar a@ws123.example.com 821 |(1) REGISTER | | 822 |Contact: a@ws123.example.com | 823 |------------------>| | 824 |(2) 202 Accepted OK| | 825 |<------------------| | 826 | |(3) MESSAGE a@ws123.example 827 | |Permission Document| 828 | |------------------>| 829 | |(4) 200 OK | 830 | |<------------------| 831 |(5) SUBSCRIBE | | 832 |Event: pending-additions | 833 |------------------>| | 834 |(6) 200 OK | | 835 |<------------------| | 836 |(7) NOTIFY | | 837 |<------------------| | 838 |(8) 200 OK | | 839 |------------------>| | 840 | |(9) PUBLISH uri-up | 841 | |<------------------| 842 | |(10) 200 OK | 843 | |------------------>| 844 |(11) NOTIFY | | 845 |<------------------| | 846 |(12) 200 OK | | 847 |------------------>| | 849 Figure 7: Registration 851 Permission documents generated by registrars are typically very 852 general. For example, in one such document a registrar may ask a 853 recipient for permission to forward any request from any sender to 854 the recipient's URI. This is the type of granularity that this 855 framework intends to provide for registrations. Users who want to 856 define how incoming requests are treated with a finer granularity 857 (e.g., requests from user A should only be accepted between 9:00 and 858 11:00) should use other mechanisms such as CPL [14]. 860 Note that, as indicated previously, user agents using the same 861 connection to register and to receive traffic from the registrar, as 862 described in [15] do not need to use the mechanism described in this 863 section. 865 A user agent being registered by a third party may not be able to use 866 the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to 867 prove to the registrar that the user agent is the owner of the URI 868 being registered (e.g., sip:user@192.0.2.1), which is the recipient 869 URI of the translation. In this case, return routability MUST be 870 used. 872 5.11. Relays Generating Traffic towards Recipients 874 A relay executing a translation that involves sending a request to a 875 URI from which permissions were obtained previously SHOULD add a 876 Trigger-Consent header field to the request. The URI in the Trigger- 877 Consent header field MUST have an escaped Refer-To header field 878 identifying the recipient of the translation so that a REFER request 879 sent to that URI will cause a MESSAGE request to be sent to the 880 recipient. 882 On receiving a REFER request addressed to the URI a relay placed in a 883 Trigger-Consent header field, the relay SHOULD send a MESSAGE request 884 to the URI in the Refer-To header field with a permission document. 886 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 887 the Trigger-Consent header field. Some of its elements are defined 888 in RFC 3261 [3]. 890 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 891 *( COMMA trigger-cons-spec ) 892 trigger-cons-spec = ( name-addr / addr-spec ) 893 *( SEMI generic-param ) 895 The following is an example of a Trigger-Consent header field: 897 Trigger-Consent:> 900 6. IANA Considerations 902 The IANA is requested to add the following new response code to the 903 Methods and Response Codes subregistry under the SIP Parameters 904 registry. 906 Response Code Number: 470 907 Default Reason Phrase: Consent Needed 908 Reference: [RFCxxxx] 910 Note to the RFC editor: substitute xxxx with the RFC number of this 911 document. 913 The IANA is requested to add the following new SIP header field to 914 the Header Fields subregistry under the SIP Parameters registry. 916 Header Name: Trigger-Consent 917 Compact Form: (none) 918 Reference: [RFCxxxx] 920 Note to the RFC editor: substitute xxxx with the RFC number of this 921 document. 923 The IANA is requested to add the following new SIP header field to 924 the Header Fields subregistry under the SIP Parameters registry. 926 Header Name: Permission-Missing 927 Compact Form: (none) 928 Reference: [RFCxxxx] 930 Note to the RFC editor: substitute xxxx with the RFC number of this 931 document. 933 7. Security Considerations 935 Security has been discussed throughout the whole document. However, 936 there are some issues that deserve special attention. 938 The specifications of mechanisms to manipulate translation logic at 939 relays usually stress the importance of client authentication and 940 authorization. Having relays authenticate and authorize clients 941 manipulating their translation logic keeps unauthorized clients from 942 adding recipients to a translation. However, this does not prevent 943 authorized clients to add recipients to a translation without their 944 consent. Additionally, some relays provide web interfaces for any 945 client to add new recipients to the translation (e.g., many email 946 mailing lists are operated in this way). In this situation, every 947 client is considered authorized to manipulate the translation logic 948 at the relay. This makes the use of this framework even more 949 important. Therefore, it is RECOMMENDED that relays performing 950 translations implement this framework. 952 As pointed out in Section 5.6.3, when return routability tests are 953 used to authenticate recipients granting or denying permissions, the 954 URIs used to grant or deny permissions need to be protected from 955 attackers. SIPS URIs provide a good tool to meet this requirement, 956 as described in [12]. 958 The information provided by the Pending Additions event package can 959 be sensitive. For this reason, as described in [13], relays need to 960 use strong means for authentication and information confidentiality. 961 SIPS URIs are a good mechanism to meet this requirement. 963 8. Acknowledges 965 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 966 useful ideas on this document. 968 9. References 970 9.1. Normative References 972 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 973 Levels", BCP 14, RFC 2119, March 1997. 975 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 976 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 977 HTTP/1.1", RFC 2616, June 1999. 979 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 980 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 981 Session Initiation Protocol", RFC 3261, June 2002. 983 [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 984 to the Session Initiation Protocol (SIP) for Asserted Identity 985 within Trusted Networks", RFC 3325, November 2002. 987 [5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 988 D. Gurle, "Session Initiation Protocol (SIP) Extension for 989 Instant Messaging", RFC 3428, December 2002. 991 [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 992 Specifications: ABNF", RFC 4234, October 2005. 994 [7] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements for 995 Consent-Based Communications in the Session Initiation Protocol 996 (SIP)", RFC 4453, April 2006. 998 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 999 Identity Management in the Session Initiation Protocol (SIP)", 1000 RFC 4474, August 2006. 1002 [9] Rosenberg, J., "The Extensible Markup Language (XML) 1003 Configuration Access Protocol (XCAP)", 1004 draft-ietf-simple-xcap-11 (work in progress), May 2006. 1006 [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for 1007 Representing Resource Lists", 1008 draft-ietf-simple-xcap-list-usage-05 (work in progress), 1009 February 2005. 1011 [11] Camarillo, G. and A. Roach, "Framework and Security 1012 Considerations for Session Initiation Protocol (SIP) Uniform 1013 Resource Identifier (URI)-List Services", 1014 draft-ietf-sipping-uri-services-05 (work in progress), 1015 January 2006. 1017 [12] Camarillo, G., "A Document Format for Requesting Consent", 1018 draft-ietf-sipping-consent-format-00 (work in progress), 1019 September 2006. 1021 [13] Camarillo, G., "The Session Initiation Protocol (SIP) Pending 1022 Additions Event Package", 1023 draft-ietf-sipping-pending-additions-00 (work in progress), 1024 September 2006. 1026 9.2. Informative References 1028 [14] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1029 Language (CPL): A Language for User Control of Internet 1030 Telephony Services", RFC 3880, October 2004. 1032 [15] Jennings, C. and R. Mahy, "Managing Client Initiated 1033 Connections in the Session Initiation Protocol (SIP)", 1034 draft-ietf-sip-outbound-04 (work in progress), June 2006. 1036 Authors' Addresses 1038 Jonathan Rosenberg 1039 Cisco Systems 1040 600 Lanidex Plaza 1041 Parsippany, NJ 07054 1042 US 1044 Phone: +1 973 952-5000 1045 Email: jdrosen@cisco.com 1046 URI: http://www.jdrosen.net 1048 Gonzalo Camarillo (editor) 1049 Ericsson 1050 Hirsalantie 11 1051 Jorvas 02420 1052 Finland 1054 Email: Gonzalo.Camarillo@ericsson.com 1056 Dean Willis 1057 Cisco Systems 1058 2200 E. Pres. George Bush Turnpike 1059 Richardson, TX 75082 1060 USA 1062 Email: dean.willis@softarmor.com 1064 Intellectual Property Statement 1066 The IETF takes no position regarding the validity or scope of any 1067 Intellectual Property Rights or other rights that might be claimed to 1068 pertain to the implementation or use of the technology described in 1069 this document or the extent to which any license under such rights 1070 might or might not be available; nor does it represent that it has 1071 made any independent effort to identify any such rights. Information 1072 on the procedures with respect to rights in RFC documents can be 1073 found in BCP 78 and BCP 79. 1075 Copies of IPR disclosures made to the IETF Secretariat and any 1076 assurances of licenses to be made available, or the result of an 1077 attempt made to obtain a general license or permission for the use of 1078 such proprietary rights by implementers or users of this 1079 specification can be obtained from the IETF on-line IPR repository at 1080 http://www.ietf.org/ipr. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights that may cover technology that may be required to implement 1085 this standard. Please address the information to the IETF at 1086 ietf-ipr@ietf.org. 1088 Disclaimer of Validity 1090 This document and the information contained herein are provided on an 1091 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1092 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1093 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1094 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1095 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1096 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1098 Copyright Statement 1100 Copyright (C) The Internet Society (2006). This document is subject 1101 to the rights, licenses and restrictions contained in BCP 78, and 1102 except as set forth therein, the authors retain all their rights. 1104 Acknowledgment 1106 Funding for the RFC Editor function is currently provided by the 1107 Internet Society.