idnits 2.17.1 draft-ietf-sipping-consent-framework-05.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 1063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1053. ** 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 (June 12, 2006) is 6521 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 894 ** 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-03 -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-reqs (ref. '13') == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 10 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: December 14, 2006 G. Camarillo, Ed. 4 Ericsson 5 D. Willis 6 Cisco Systems 7 June 12, 2006 9 A Framework for Consent-Based Communications in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sipping-consent-framework-05.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 December 14, 2006. 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. Permission 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 . . . . . . . . . . . . 12 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.7. Permission Granted Notification . . . . . . . . . . . . . 14 75 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 15 76 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 16 77 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 17 78 5.11. Relays Generating Traffic towards Recipients . . . . . . . 20 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 Intellectual Property and Copyright Statements . . . . . . . . . . 25 88 1. Introduction 90 The Session Initiation Protocol (SIP) [3] supports communications 91 across many media types, including real-time audio, video, text, 92 instant messaging, and presence. This communication is established 93 by the transmission of various SIP requests (such as INVITE and 94 MESSAGE [5]) from an initiator to the recipient with whom 95 communication is desired. Although a recipient of such a SIP request 96 can reject the request, and therefore decline the session, a SIP 97 network will deliver a SIP request to its recipients without their 98 explicit consent. 100 Receipt of these requests without explicit consent can cause a number 101 of problems in SIP networks. These include amplification and DoS 102 (Denial of Service) attacks. These problems are described in more 103 detail in a companion requirements document [13]. 105 This specification defines a basic framework for adding consent-based 106 communication to SIP. 108 2. Definitions and Terminology 110 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 111 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 112 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 113 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 114 compliant implementations. 116 Recipient URI: The Request-URI of an outgoing request sent by an 117 entity (e.g., a user agent or a proxy). The sending of such 118 request may have been the result of a translation operation. 120 Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or 121 some hybrid, that receives a request, translates its Request-URI 122 into one or more next-hop URIs (i.e., recipient URIs), and 123 delivers the request to those URIs. 125 Target URI: The Request-URI of an incoming request that arrives to a 126 relay that will perform a translation operation. 128 Translation operation: Operation by which a relay translates the 129 request URI of an incoming request (i.e., the target URI) into one 130 or more URIs (i.e., recipient URIs) which are used as the request 131 URIs of one or more outgoing requests. 133 3. Relays and Translations 135 Relays play a key role in this framework. A relay is defined as any 136 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 137 hybrid, which receives a request, translates its Request-URI into one 138 or more next hop URIs, and delivers the request to those URIs. The 139 Request-URI of the incoming request is referred to as 'target URI' 140 and the destination URIs of the outgoing requests are referred to as 141 'recipient URIs', as shown in Figure 1. 143 +---------------+ 144 | | recipient URI 145 | |----------------> 146 target URI | Translation | 147 -------------->| Operation | recipient URI 148 | |----------------> 149 | | 150 +---------------+ 152 Figure 1: Translation operation 154 Thus, an essential aspect of a relay is that of translation. When a 155 relay receives a request, it translates, following its translation 156 logic, the Request-URI into one or more additional URIs. That is, 157 the relay can create outgoing requests to one or more additional 158 URIs. The translation operation is what creates the consent problem. 160 Additionally, since the translation operation can result in more than 161 one URI, it is also the source of amplification. Servers that do not 162 perform translations, such as outbound proxy servers, do not cause 163 amplification. 165 Since the translation operation is based on local policy or local 166 data (such as registrations), it is the vehicle by which a request is 167 delivered directly to an endpoint, when it would not otherwise be 168 possible to. In other words, if a spammer has the address of a user, 169 'user@example.com', it cannot deliver a MESSAGE request to the UA 170 (User Agent) of that user without having access to the registration 171 data that maps 'user@example.com' to the user agent on which that 172 user is present. Thus, it is the usage of this registration data, 173 and more generally, the translation logic, which must be authorized 174 in order to prevent undesired communications. Of course, if the 175 spammer knows the address of the user agent, it will be able to 176 deliver requests directly to it. 178 Figure 2 shows a relay that performs translations. The user agent 179 client in the figure sends a SIP request to a URI representing a 180 resource in the domain 'example.com' (resource@example.com). This 181 request may pass through a local outbound proxy (not shown), but 182 eventually arrives at a server authoritative for the domain 183 'example.com'. This server, which acts as a relay, performs a 184 translation operation, translating the target URI into one or more 185 recipient URIs, which may or may not belong to the domain 186 'example.com'. This relay may be, for instance, a proxy server or a 187 URI-list service [14]. 189 +-------+ 190 | | 191 >| UA | 192 / | | 193 / +-------+ 194 / 195 / 196 +-----------------------+ / 197 | | / 198 +-----+ | Relay | / +-------+ 199 | | | |/ | | 200 | UA |------>| |-------->| Proxy | 201 | | |+---------------------+|\ | | 202 +-----+ || Translation || \ +-------+ 203 || Logic || \ 204 |+---------------------+| \ [...] 205 +-----------------------+ \ 206 \ 207 \ +-------+ 208 \ | | 209 >| B2BUA | 210 | | 211 +-------+ 213 Figure 2: Relay performing a translation 215 This framework allows potential recipients of a translation to agree 216 to be actual recipients by giving the relay performing the 217 translation permission to send them traffic. 219 4. Architecture 221 Figure 3 shows the architectural elements of this framework. 222 Section 4.1 describes the role of permissions at a relay. 223 Section 4.2 discusses the actions taken by a relay when its 224 translation logic is manipulated by a client. Section 4.3 introduces 225 permission servers and their functionality. Section 4.4 describes 226 how potential recipients can grant a relay permissions to add them to 227 the relay's translation logic. 229 +-----------------------+ Permission +------------+ 230 | | Request | | 231 +--------+ | Relay |----------->| Permission | 232 | | | | | Server | 233 | Client | | | | | 234 | | |+-------+ +-----------+| +------------+ 235 +--------+ ||Transl.| |Permissions|| | 236 | ||Logic | | || Permission | 237 | |+-------+ +-----------+| Request | 238 | +-----------------------+ V 239 | ^ ^ +------------+ 240 | Manipulation | | Permission Grant | | 241 +---------------+ +-------------------| Recipient | 242 | | 243 +------------+ 245 Figure 3: Reference Architecture 247 4.1. Permissions at a Relay 249 Relays implementing this framework obtain and store permissions 250 associated to their translation logics. These permissions indicate 251 if a particular recipient has agreed to receive traffic or not at any 252 given time. Recipients that have not given the relay permission to 253 send them traffic are simply ignored by the relay when performing a 254 translation. 256 Permissions are valid as long as the context where they were granted 257 is valid or until they are revoked. For example, the permissions 258 obtained by a URI-list SIP service that distributes MESSAGE requests 259 to a set of recipients will be valid as long as the URI-list SIP 260 service exists or until the permissions are revoked. 262 4.2. Consenting Manipulations on a Relay's Transaction Logic 264 This framework aims to ensure that any particular relay only performs 265 translations towards destinations that have given the relay 266 permission to perform such a translation. Consequently, when the 267 translation logic of a relay is manipulated (e.g., a new recipient 268 URI is added), the relay obtains permission from the new recipient in 269 order to install the new translation logic. Relays ask recipients 270 for permission using MESSAGE [5] requests. 272 For example, the relay hosting the URI-list service at 273 'friends@example.com' performs a translation from that URI to a set 274 of recipient URIs. When a client (e.g., the administrator of that 275 URI-list service) adds 'bob@example.org' as a new recipient URI, the 276 relay sends a MESSAGE request to 'bob@example.org' asking whether or 277 not it is OK to perform the translation from 'friends@example.com' to 278 'bob@example.org'. The MESSAGE request carries in its message body a 279 permission document that describes the translation for which 280 permissions are being requested and a human readable part that also 281 describes the translation. If the answer is positive, the new 282 translation logic is installed at the relay. That is, the new 283 recipient URI is added. 285 The human-readable part is included so that user agents that do 286 not understand permission documents can still process the request 287 and display it in a sensible way to the user. 289 Note that the mechanism to be used to manipulate the translation 290 logic of a particular relay depends on the relay. Two existing 291 mechanisms to manipulate translation logic are XCAP [11] and REGISTER 292 transactions. 294 In any case, relays implementing this framework SHOULD have a means 295 to indicate that a particular recipient URI is in the states 296 specified in [10] (i.e., pending, waiting, error, denied, or 297 granted). 299 4.3. Permission Servers 301 When a MESSAGE request with a permission document arrives to the 302 recipient URI to which it was sent by the relay, the receiving user 303 can grant or deny the permission needed to perform the translation. 304 Nevertheless, users are not on-line all the time and, so, sometimes 305 are not able to receive MESSAGE requests. 307 This issue is also found in presence, where a user's status is 308 reported by a presence server instead of by the user's user agents, 309 which can go on and off line. Similarly, we define permission 310 servers, which are a key element of this framework. Permission 311 servers are network elements that act as SIP user agents and handle 312 MESSAGE requests for a user. 314 So, a permission server stores incoming MESSAGE requests when the 315 user is unavailable and delivers them when the user is available 316 again. Conceptually, a permission server provides a store-and- 317 forward message service. 319 There are several mechanisms to implement store-and-forward message 320 services (e.g., with an instant message to email gateway). Any of 321 these mechanisms can be used between a user agent and its permission 322 server as long as they agree on which mechanism to use. Therefore, 323 this framework does not make any recommendation on the interface 324 between user agents and their permission servers. 326 Note that the same store-and-forward message service can handle 327 all incoming MESSAGE requests for a user while this is off line, 328 not only those MESSAGE requests with a permission document in 329 their bodies. 331 4.4. Recipients Grant Permissions 333 Relays include in the permission documents they generate URIs that 334 can be used by the recipient of the document to grant or deny the 335 relay the permission described in the document. Relays always 336 include SIP URIs and may include HTTP [2] URIs for this purpose. 337 Consequently, recipients provide relays with permissions using SIP 338 PUBLISH requests or HTTP GET requests. 340 5. Framework Operations 342 This section specifies this consent framework using an example of the 343 prototypical call flow. The elements described in Section 4 (i.e., 344 relays, translations, and permission servers) play an essential role 345 in this call flow. 347 Figure 4 shows the complete process to add a recipient URI 348 ('B@example.com') to the translation logic of a relay. User A 349 attempts to add 'B@example.com' as a new recipient URI to the 350 translation logic of the relay (1). User A uses XCAP [11] and the 351 XML (Extensible Markup Language) format for representing resource 352 lists [12] to perform this addition. Since the relay does not have 353 permission from 'B@example.com' to perform translations towards that 354 URI, the relay places 'B@example.com' in the pending state, as 355 specified in [10]. 357 A@example.com Relay B's Permission B@example.com 358 Server 359 |(1) Add Recipient B@example.com | | 360 |--------------->| | | 361 |(2) HTTP 202 (Accepted) | | 362 |<---------------| | | 363 | |(3) MESSAGE B@example | 364 | |Permission Document | 365 | |--------------->| | 366 | |(4) 202 Accepted| | 367 | |<---------------| | 368 |(5) SUBSCRIBE | | | 369 |Event: pending-additions | | 370 |--------------->| | | 371 |(6) 200 OK | | | 372 |<---------------| | | 373 |(7) NOTIFY | | | 374 |<---------------| | | 375 |(8) 200 OK | | | 376 |--------------->| | | 377 | | | |User B goes 378 | | | | on line 379 | | |(9) Request for | 380 | | | stored messages 381 | | |<---------------| 382 | | |(10) Delivery of| 383 | | | stored messages 384 | | |--------------->| 385 | |(11) PUBLISH uri-up | 386 | |Permission Document | 387 | |<--------------------------------| 388 | |(12) 200 OK | | 389 | |-------------------------------->| 390 |(13) NOTIFY | | | 391 |<---------------| | | 392 |(14) 200 OK | | | 393 |--------------->| | | 395 Figure 4: Prototypical call flow 397 5.1. Amplification Avoidance 399 Once 'B@example.com' is in the pending state, the relay needs to ask 400 user B for permission by sending a MESSAGE request to 401 'B@example.com'. However, the relay needs to ensure that it is not 402 used as an amplifier to launch amplification attacks. 404 In such an attack, the attacker would add a large number of recipient 405 URIs to the translation logic of a relay. The relay would then send 406 a MESSAGE request to each of those URIs. The bandwidth generated by 407 the relay would be much higher than the bandwidth used by the 408 attacker to add those URIs to the translation logic of the relay. 410 This framework uses a credit-based authorization mechanism to avoid 411 the attack just described. It requires users adding new recipient 412 URIs to a translation to generate an amount of bandwidth that is 413 comparable to the bandwidth the relay will generate when sending 414 MESSAGE requests towards those recipient URIs. When XCAP is used, 415 this requirement is met by not allowing clients to add more than one 416 URI per HTTP transaction. 418 Therefore, relays implementing this framework MUST NOT allow clients 419 to add more than one URI per HTTP transaction. If a client attempts 420 to add more than one URI in a single HTTP transaction, the XCAP 421 server SHOULD return an HTTP 403 (Forbidden) response. The XCAP 422 server SHOULD describe the reason for the refusal (i.e., only one URI 423 can be added at a time) in the entity, as described in [2]. 425 5.2. Subscription to the Permission Status 427 Clients can use the Pending Additions SIP event package [10] to be 428 informed about the status of the operations they requested. That is, 429 the client will be informed when an operation (e.g., the addition of 430 a URI to the translation logic of a relay) is authorized (and thus 431 executed) or rejected. 433 OPEN ISSUE: how do clients obtain the URI to subscribe to the Pending 434 Additions event package, both when using XCAP and when using 435 REGISTERs to manipulate the translation? 437 In our example, after receiving the response from the server (2), 438 user A subscribes to the Pending Additions event package at the relay 439 (5). This subscription keeps user A informed about the status of the 440 permissions (e.g., granted or denied) the relay will obtain. 442 5.3. Request for Permission 444 Relays MUST obtain permissions from potential recipients before 445 adding them to their translation logics. Relays request permissions 446 from potential recipients using MESSAGE requests. 448 MESSAGE requests sent to request permissions MUST include a 449 permission document and SHOULD include a human-readable part in their 450 bodies. MESSAGE requests also carry a body part that contains the 451 same information as the permission document but in a human-readable 452 format so that user agents that do not understand permission 453 documents can still process the request and display it in a sensible 454 way to the user. 456 Section 5.6 describes three methods a relay can use to authenticate 457 recipients giving the relay permission to perform a particular 458 translation. Relays that use the method consisting of a return 459 routability test have to send their MESSAGE requests to a SIPS URI, 460 as specified in Section 5.6. 462 In our example, on receiving the request to add User B to the 463 translation logic of the relay (1), the relay generates a MESSAGE 464 request (3) towards 'B@example.com'. This MESSAGE request carries a 465 permission document, which describes the translation that needs to be 466 authorized and carries a set of URIs to be used by the recipient to 467 grant or to deny the relay permission to perform that translation. 468 User B will authorize the translation by using one of those URIs, as 469 described in Section 5.6. The MESSAGE request also carry a body part 470 that contains the same information as the permission document but in 471 a human-readable format. 473 When User B uses one of the URIs in the permission document to grant 474 or deny permissions, the relay needs to make sure that it was 475 actually User B the one using that URI, and not an attacker. The 476 relay can use three methods to authenticate the permission document: 477 SIP identity [7], P-Asserted-Identity [4], or a return routability 478 test. These methods are described in Section 5.6. 480 5.4. Permission Document Structure 482 A permission document is the XML representation of a permission. A 483 permission document contains several pieces of data: 485 Identity of the Sender: A URI representing the identity of the sender 486 for whom permissions are granted. 488 Identity of the Original Recipient: A URI representing the identity 489 of the original recipient, which is used as the input for the 490 translation operation. This is also called the target URI. 492 Identity of the Final Recipient: A URI representing the result of the 493 translation. The permission grants ability for the sender to send 494 requests to the target URI, and for a relay receiving those 495 requests to forward them to this URI. This is also called the 496 recipient URI. 498 URIs to Grant Permission: URIs that recipients can use to grant the 499 relay permission to perform the translation described in the 500 document. At least one of these URIs MUST be a SIP or SIPS URI. 501 HTTP and HTTPS URIs MAY also be used. 503 URIs to Deny Permission: URIs that recipients can use to deny the 504 relay permission to perform the translation described in the 505 document. At least one of these URIs MUST be a SIP or SIPS URI. 506 HTTP and HTTPS URIs MAY also be used. 508 Permission documents may contain wildcards. For example, a 509 permission document may request permission for any relay to forward 510 requests coming from a particular sender to a particular recipient. 511 Such a permission document would apply to any target URI. That is, 512 the field containing the identity of the original recipient would 513 match any URI. 515 Entities implementing this framework MUST support the format for 516 permission documents defined in [9]. 518 In our example, the permission document in the MESSAGE request (3) 519 sent by the relay contains the following values: 521 Identity of the Sender: Any. 523 Identity of the Original Recipient: friends@example.com 525 Identity of the Final Recipient: B@example.com 527 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 529 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 531 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 533 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 535 It is expected that the Sender field often contains a wildcard. 536 However, scenarios involving request-contained URI lists, such as the 537 one described in Section 5.9, may require permission documents that 538 apply to a specific sender. Of course, in cases where the identity 539 of the sender matters, relays MUST authenticate senders. 541 5.5. Permission Requested Notification 543 On receiving the MESSAGE request (3), User B's permission server 544 stores it because User B is off line at that point. When User B goes 545 on line, User B fetches all the requests its permission server has 546 stored (9). 548 5.6. Permission Grant 550 A client gives a relay permission to execute the translation 551 described in a permission document by sending a SIP PUBLISH or an 552 HTTP GET request to one of the URIs to grant permissions contained in 553 the document. Similarly, a client denies a relay permission to 554 execute the translation described in a permission document by sending 555 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 556 permissions contained in the document. 558 In our example, User B obtains the permission document (10) that was 559 received earlier by its permission server in the MESSAGE request (3). 560 User B authorizes the translation described in the permission 561 document received by sending a PUBLISH request (11) to the SIP URI to 562 grant permissions contained in the permission document. 564 Relays need to ensure that the SIP PUBLISH or the HTTP GET request 565 received was generated by the recipient of the translation and not by 566 an attacker. Relays can use three methods to authenticate those 567 requests: SIP identity, P-Asserted-Identity [4], or a return 568 routability test. While return routability tests can be used to 569 authenticate both SIP PUBLISH and HTTP GET requests, SIP identity and 570 P-Asserted-Identity can only be used to authenticate SIP PUBLISH 571 requests. 573 5.6.1. SIP Identity 575 The SIP identity [7] mechanism can be used to authenticate the sender 576 of a PUBLISH request. The relay MUST check that the originator of 577 the PUBLISH request is the owner of the recipient URI in the 578 permission document. Otherwise, the PUBLISH request SHOULD be 579 responded with a 401 (Unauthorized) response and MUST NOT be 580 processed further. 582 5.6.2. P-Asserted-Identity 584 The P-Asserted-Identity [4] mechanism can also be used to 585 authenticate the sender of a PUBLISH request. However, as discussed 586 in RFC 3325 [4], this mechanism should only be used within networks 587 of trusted SIP servers. That is, the use of this mechanism is only 588 applicable inside an administrative domain with previously agreed- 589 upon policies. 591 The relay MUST check that the originator of the PUBLISH request is 592 the owner of the recipient URI in the permission document. 594 Otherwise, the PUBLISH request SHOULD be responded with a 401 595 (Unauthorized) response and MUST NOT be processed further. 597 5.6.3. Return Routability 599 SIP identity provides a good authentication mechanism for incoming 600 PUBLISH requests. Nevertheless, SIP identity is not widely available 601 on the public Internet yet. That is why an authentication mechanism 602 that can already be used at this point is needed. 604 Return routability tests do not provide the same level of security as 605 SIP identity, but they provide a good-enough security level in 606 architectures where the SIP identity mechanism is not available 607 (e.g., the current Internet). The relay generates an unguessable URI 608 (i.e., with a long and random-looking user part) and places it in the 609 permission document in the MESSAGE request (3). The recipient needs 610 to send a SIP PUBLISH request or an HTTP GET request to that URI. 611 Any incoming request sent to that URI SHOULD be considered 612 authenticated by the relay. 614 Note that the return routability method is the only one that 615 allows the use of HTTP URIs in permission documents. The other 616 methods require the use of SIP URIs. 618 Relays using a return routability test to perform this authentication 619 MUST send the MESSAGE request with the permission document to a SIPS 620 URI. This ensures that attackers do not get access to the 621 (unguessable) URI. Thus, the only user able to use the (unguessable) 622 URI is the receiver of the MESSAGE request. Similarly, permission 623 documents sent by relays using a return routability test MUST only 624 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 625 permissions. The user part of these URIs MUST be cryptographically 626 random with at least 32 bits of randomness. 628 Relays can transition from return routability tests to SIP identity 629 by simply requiring the use of SIP identity for incoming PUBLISH 630 requests. That is, such a relay would reject PUBLISH requests that 631 did not use SIP identity. 633 5.7. Permission Granted Notification 635 On receiving the PUBLISH request (11), the relay sends a NOTIFY 636 request (13) to inform user A that the permission for the translation 637 has been received and that the translation logic at the relay has 638 been updated. That is, 'B@example.com' has been added as a recipient 639 URI. 641 5.8. Permission Revocation 643 At any time, if a client wants to revoke any permission, it uses the 644 URI it received in the permission document to deny the permissions it 645 previously granted. If a client loses this URI for some reason, it 646 needs to wait until it receives a new request produced by the 647 translation. Such a request will contain a Trigger-Consent header 648 field with a URI. That URI will have an escaped Refer-To header 649 field identifying the client (i.e., the recipient of the 650 translation). The client needs to send a REFER request to the URI in 651 the Trigger-Consent header field in order to receive a MESSAGE 652 request from the relay. Such a MESSAGE request will contain a 653 permission document with a URI to revoke the permission that was 654 previously granted. 656 Figure 5 shows an example of how a user that lost the URI to revoke 657 permissions at a relay can obtain a new URI using the Trigger-Consent 658 header field of an incoming request. The user rejects an incoming 659 INVITE (1) request, which contains a Trigger-Consent header field. 660 Using the URI in the that header field, the user sends a REFER 661 request (4) to the relay. On receiving the REFER request (4), the 662 relay generates a MESSAGE request (6) towards the user. Finally, the 663 user revokes the permissions by sending a PUBLISH request (8) to the 664 relay. 666 Relay B@example.com 667 |(1) INVITE | 668 | Trigger-Consent: <123@relay.example.com> 669 | ?Refer-To= 670 |---------------------------->| 671 |(2) 603 Decline | 672 |<----------------------------| 673 |(3) ACK | 674 |---------------------------->| 675 |(4) REFER 123@relay.example.com 676 | Refer-To: B@example.com | 677 |<----------------------------| 678 |(5) 200 OK | 679 |---------------------------->| 680 |(6) MESSAGE B@example | 681 | Permission Document | 682 |---------------------------->| 683 |(7) 200 OK | 684 |<----------------------------| 685 |(8) PUBLISH uri-deny | 686 |<----------------------------| 687 |(9) 200 OK | 688 |---------------------------->| 690 Figure 5: Permission Revocation 692 5.9. Request-contained URI Lists 694 In the scenarios described so far, a user adds recipient URIs to the 695 translation logic of a relay. However, the relay does not perform 696 translations towards those URIs until permissions are obtained. 698 URI-list services using request-contained URI lists are a special 699 case because the selection of recipient URIs is performed at the same 700 time as the communication attempt. A user places a set of recipient 701 URIs in a request and sends it to a relay so that the relay sends a 702 similar request to all those recipient URIs. 704 Relays implementing this framework and providing this type of URI- 705 list services MUST maintain a list of recipient URIs from which 706 permission have been received. This list is manipulated in the same 707 way as described in Section 5 and represents the set of URIs that 708 will be accepted if a request containing a URI-list arrives to the 709 relay. 711 A relay that receives a request-contained URI-list with a URI for 712 which the relay has no permissions SHOULD return a 470 (Consent 713 Needed) response. The relay SHOULD add a Permission-Missing header 714 field with the URIs for which the relay has no permissions. 716 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 717 the Permission-Missing header field. Some of its elements are 718 defined in RFC 3261 [3]. 720 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 721 *( COMMA per-miss-spec ) 722 per-miss-spec = ( name-addr / addr-spec ) 723 *( SEMI generic-param ) 725 The following is an example of a Permission-Missing header field: 727 Permission-Missing: 729 Figure 6 shows a relay that receives a request (1) that contains URIs 730 for which the relay does not have permission. The relay rejects the 731 request with a 470 (Consent Needed) response (2). That response 732 contains a Permission-Missing header field with the URIs for which 733 there was no permission. 735 A@example.com Relay 736 |(1) INVITE | 737 | B@example.com | 738 | C@example.com | 739 |---------------------->| 740 |(2) 470 Consent Needed | 741 | Permission-Missing: C@example.com 742 |<----------------------| 743 |(3) ACK | 744 |---------------------->| 746 Figure 6: INVITE with a URI list in its body 748 5.10. Registrations 750 Registrations are a special type of translations. The user 751 registering has a trust relationship with the registrar in its home 752 domain. This is not the case when a user gives any type of 753 permissions to a relay in a different domain. 755 Traditionally, REGISTER transactions have performed two operations at 756 the same time: setting up a translation and authorizing the use of 757 that translation. For example, a user registering its current 758 contact URI is giving permission to the registrar to forward traffic 759 sent to the user's AoR (Address of Records) to the registered contact 760 URI. This works fine when the entity registering is the same as the 761 one that will be receiving traffic at a later point (e.g., the entity 762 receives traffic over the same connection used for the registration 763 as described in [8]). However, this schema creates some potential 764 attacks which relate to third-party registrations. 766 An attacker binds, via a registration, his or her AoR with the 767 contact URI of a victim. Now, the victim will receive unsolicited 768 traffic that was originally addressed to the attacker. 770 The process of authorizing a registration is shown in Figure 7. User 771 A performs a third-party registration (1) and receives a 202 772 (Accepted) response (2). 774 Since the relay does not have permission from 'a@ws123.example.com' 775 to perform translations towards that URI, the relay places 776 'a@ws123.example.com' in the 'pending' state. Once 777 'a@ws123.example.com' is in the 'Permission Pending' state, the 778 registrar needs to ask 'a@ws123.example.com' for permission by 779 sending a MESSAGE request (3). 781 After receiving the response from the server (2), user A subscribes 782 to the Pending Additions event package at the registrar (4). This 783 subscription keeps the user informed about the status of the 784 permissions (e.g., granted or denied) the registrar will obtain. The 785 rest of the process is similar to the one described in Section 5. 787 A@example.com Registrar a@ws123.example.com 788 |(1) REGISTER | | 789 |Contact: a@ws123.example.com | 790 |------------------>| | 791 |(2) 202 Accepted OK| | 792 |<------------------| | 793 | |(3) MESSAGE a@ws123.example 794 | |Permission Document| 795 | |------------------>| 796 | |(4) 200 OK | 797 | |<------------------| 798 |(5) SUBSCRIBE | | 799 |Event: pending-additions | 800 |------------------>| | 801 |(6) 200 OK | | 802 |<------------------| | 803 |(7) NOTIFY | | 804 |<------------------| | 805 |(8) 200 OK | | 806 |------------------>| | 807 | |(9) PUBLISH uri-up | 808 | |<------------------| 809 | |(10) 200 OK | 810 | |------------------>| 811 |(11) NOTIFY | | 812 |<------------------| | 813 |(12) 200 OK | | 814 |------------------>| | 816 Figure 7: Registration 818 Permission documents generated by registrars are typically very 819 general. For example, in one such document a registrar may ask a 820 recipient for permission to forward any request from any sender to 821 the recipient's URI. This is the type of granularity that this 822 framework intends to provide for registrations. Users who want to 823 define how incoming requests are treated with a finer granularity 824 (e.g., requests from user A should only be accepted between 9:00 and 825 11:00) should use other mechanisms such as CPL [15]. 827 Note that, as indicated previously, user agents using the same 828 connection to register and to receive traffic from the registrar, as 829 described in [8] do not need to use the mechanism described in this 830 section. 832 A user agent being registered by a third party may not be able to use 833 the SIP Identity or P-Asserted-Identity mechanisms to prove to the 834 registrar that the user agent is the owner of the URI being 835 registered (e.g., sip:user@192.0.2.1), which is the recipient URI of 836 the translation. In this case, return routability MUST be used. 838 5.11. Relays Generating Traffic towards Recipients 840 A relay executing a translation that involves sending a request to a 841 URI from which permissions were obtained previously SHOULD add a 842 Trigger-Consent header field to the request. The URI in the Trigger- 843 Consent header field MUST have an escaped Refer-To header field 844 identifying the recipient of the translation so that a REFER request 845 sent to that URI will cause a MESSAGE request to be sent to the 846 recipient. 848 On receiving a REFER request addressed to the URI a relay placed in a 849 Trigger-Consent header field, the relay SHOULD send a MESSAGE request 850 to the URI in the Refer-To header field with a permission document. 852 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 853 the Trigger-Consent header field. Some of its elements are defined 854 in RFC 3261 [3]. 856 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 857 *( COMMA trigger-cons-spec ) 858 trigger-cons-spec = ( name-addr / addr-spec ) 859 *( SEMI generic-param ) 861 The following is an example of a Trigger-Consent header field: 863 Trigger-Consent:> 866 6. IANA Considerations 868 The IANA is requested to add the following new response code to the 869 Methods and Response Codes subregistry under the SIP Parameters 870 registry. 872 Response Code Number: 470 873 Default Reason Phrase: Consent Needed 874 Reference: [RFCxxxx] 876 Note to the RFC editor: substitute xxxx with the RFC number of this 877 document. 879 The IANA is requested to add the following new SIP header field to 880 the Header Fields subregistry under the SIP Parameters registry. 882 Header Name: Trigger-Consent 883 Compact Form: (none) 884 Reference: [RFCxxxx] 886 Note to the RFC editor: substitute xxxx with the RFC number of this 887 document. 889 The IANA is requested to add the following new SIP header field to 890 the Header Fields subregistry under the SIP Parameters registry. 892 Header Name: Permission-Missing 893 Compact Form: (none) 894 Reference: [RFCxxxx] 896 Note to the RFC editor: substitute xxxx with the RFC number of this 897 document. 899 7. Security Considerations 901 Security has been discussed throughout the whole document. However, 902 there are some issues that deserve special attention. 904 The specifications of mechanisms to manipulate translation logic at 905 relays usually stress the importance of client authentication and 906 authorization. Having relays authenticate and authorize clients 907 manipulating their translation logic keeps unauthorized clients from 908 adding recipients to a translation. However, this does not prevent 909 authorized clients to add recipients to a translation without their 910 consent. Additionally, some relays provide web interfaces for any 911 client to add new recipients to the translation (e.g., many email 912 mailing lists are operated in this way). In this situation, every 913 client is considered authorized to manipulate the translation logic 914 at the relay. This makes the use of this framework even more 915 important. Therefore, it is RECOMMENDED that relays performing 916 translations implement this framework. 918 As pointed out in Section 5.6.3, when return routability tests are 919 used to authenticate recipients granting or denying permissions, the 920 URIs used to grant or deny permissions need to be protected from 921 attackers. SIPS URIs provide a good tool to meet this requirement, 922 as described in [9]. 924 The information provided by the Pending Additions event package can 925 be sensitive. For this reason, as described in [10], relays need to 926 use strong means for authentication and information confidentiality. 927 SIPS URIs are a good mechanism to meet this requirement. 929 8. Acknowledges 931 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 932 useful ideas on this document. 934 9. References 936 9.1. Normative References 938 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 939 Levels", BCP 14, RFC 2119, March 1997. 941 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 942 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 943 HTTP/1.1", RFC 2616, June 1999. 945 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 946 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 947 Session Initiation Protocol", RFC 3261, June 2002. 949 [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 950 to the Session Initiation Protocol (SIP) for Asserted Identity 951 within Trusted Networks", RFC 3325, November 2002. 953 [5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 954 D. Gurle, "Session Initiation Protocol (SIP) Extension for 955 Instant Messaging", RFC 3428, December 2002. 957 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 958 Specifications: ABNF", RFC 4234, October 2005. 960 [7] Peterson, J. and C. Jennings, "Enhancements for Authenticated 961 Identity Management in the Session Initiation Protocol (SIP)", 962 draft-ietf-sip-identity-06 (work in progress), October 2005. 964 [8] Jennings, C. and R. Mahy, "Managing Client Initiated 965 Connections in the Session Initiation Protocol (SIP)", 966 draft-ietf-sip-outbound-03 (work in progress), March 2006. 968 [9] Camarillo, G., "A Document Format for Requesting Consent", 969 draft-camarillo-sipping-consent-format-01 (work in progress), 970 June 2006. 972 [10] Camarillo, G., "The Session Initiation Protocol (SIP) Pending 973 Additions Event Package", 974 draft-camarillo-sipping-pending-additions-00 (work in 975 progress), June 2006. 977 [11] Rosenberg, J., "The Extensible Markup Language (XML) 978 Configuration Access Protocol (XCAP)", 979 draft-ietf-simple-xcap-11 (work in progress), May 2006. 981 [12] Rosenberg, J., "Extensible Markup Language (XML) Formats for 982 Representing Resource Lists", 983 draft-ietf-simple-xcap-list-usage-05 (work in progress), 984 February 2005. 986 [13] Rosenberg, J., "Requirements for Consent-Based Communications 987 in the Session Initiation Protocol (SIP)", 988 draft-ietf-sipping-consent-reqs-04 (work in progress), 989 January 2006. 991 [14] Camarillo, G. and A. Roach, "Framework and Security 992 Considerations for Session Initiation Protocol (SIP) Uniform 993 Resource Identifier (URI)-List Services", 994 draft-ietf-sipping-uri-services-05 (work in progress), 995 January 2006. 997 9.2. Informative References 999 [15] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1000 Language (CPL): A Language for User Control of Internet 1001 Telephony Services", RFC 3880, October 2004. 1003 Authors' Addresses 1005 Jonathan Rosenberg 1006 Cisco Systems 1007 600 Lanidex Plaza 1008 Parsippany, NJ 07054 1009 US 1011 Phone: +1 973 952-5000 1012 Email: jdrosen@cisco.com 1013 URI: http://www.jdrosen.net 1015 Gonzalo Camarillo (editor) 1016 Ericsson 1017 Hirsalantie 11 1018 Jorvas 02420 1019 Finland 1021 Email: Gonzalo.Camarillo@ericsson.com 1023 Dean Willis 1024 Cisco Systems 1025 2200 E. Pres. George Bush Turnpike 1026 Richardson, TX 75082 1027 USA 1029 Email: dean.willis@softarmor.com 1031 Intellectual Property Statement 1033 The IETF takes no position regarding the validity or scope of any 1034 Intellectual Property Rights or other rights that might be claimed to 1035 pertain to the implementation or use of the technology described in 1036 this document or the extent to which any license under such rights 1037 might or might not be available; nor does it represent that it has 1038 made any independent effort to identify any such rights. Information 1039 on the procedures with respect to rights in RFC documents can be 1040 found in BCP 78 and BCP 79. 1042 Copies of IPR disclosures made to the IETF Secretariat and any 1043 assurances of licenses to be made available, or the result of an 1044 attempt made to obtain a general license or permission for the use of 1045 such proprietary rights by implementers or users of this 1046 specification can be obtained from the IETF on-line IPR repository at 1047 http://www.ietf.org/ipr. 1049 The IETF invites any interested party to bring to its attention any 1050 copyrights, patents or patent applications, or other proprietary 1051 rights that may cover technology that may be required to implement 1052 this standard. Please address the information to the IETF at 1053 ietf-ipr@ietf.org. 1055 Disclaimer of Validity 1057 This document and the information contained herein are provided on an 1058 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1059 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1060 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1061 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1062 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1063 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1065 Copyright Statement 1067 Copyright (C) The Internet Society (2006). This document is subject 1068 to the rights, licenses and restrictions contained in BCP 78, and 1069 except as set forth therein, the authors retain all their rights. 1071 Acknowledgment 1073 Funding for the RFC Editor function is currently provided by the 1074 Internet Society.