idnits 2.17.1 draft-ietf-sip-consent-framework-01.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 1159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1149. ** 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 (November 26, 2006) is 6361 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 985 ** 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: May 30, 2007 G. Camarillo, Ed. 4 Ericsson 5 D. Willis 6 Cisco Systems 7 November 26, 2006 9 A Framework for Consent-Based Communications in the Session Initiation 10 Protocol (SIP) 11 draft-ietf-sip-consent-framework-01.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 May 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 6 61 4.2. Consenting Manipulations on a Relay's Transaction Logic . 7 62 4.3. Store-and-forward Servers . . . . . . . . . . . . . . . . 8 63 4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 9 64 5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 10 66 5.2. Subscription to the Permission Status . . . . . . . . . . 11 67 5.3. Request for Permission . . . . . . . . . . . . . . . . . . 12 68 5.4. Permission Document Structure . . . . . . . . . . . . . . 12 69 5.5. Permission Requested Notification . . . . . . . . . . . . 14 70 5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 14 71 5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 15 72 5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 15 73 5.6.3. Return Routability . . . . . . . . . . . . . . . . . . 15 74 5.6.4. SIP Digest . . . . . . . . . . . . . . . . . . . . . . 16 75 5.7. Permission Granted Notification . . . . . . . . . . . . . 16 76 5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 16 77 5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 17 78 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 19 79 5.11. Relays Generating Traffic towards Recipients . . . . . . . 21 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 82 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 87 Intellectual Property and Copyright Statements . . . . . . . . . . 27 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 logic: The logic that defines a translation operation at 130 a relay. This logic includes the translation's target and 131 recipient URIs. 133 Translation operation: Operation by which a relay translates the 134 Request-URI of an incoming request (i.e., the target URI) into one 135 or more URIs (i.e., recipient URIs) which are used as the Request- 136 URIs of one or more outgoing requests. 138 3. Relays and Translations 140 Relays play a key role in this framework. A relay is defined as any 141 SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 142 hybrid, which receives a request, translates its Request-URI into one 143 or more next hop URIs, and delivers the request to those URIs. The 144 Request-URI of the incoming request is referred to as 'target URI' 145 and the destination URIs of the outgoing requests are referred to as 146 'recipient URIs', as shown in Figure 1. 148 +---------------+ 149 | | recipient URI 150 | |----------------> 151 target URI | Translation | 152 -------------->| Operation | recipient URI 153 | |----------------> 154 | | 155 +---------------+ 157 Figure 1: Translation operation 159 Thus, an essential aspect of a relay is that of translation. When a 160 relay receives a request, it translates the Request-URI (target URI) 161 into one or more additional URIs (recipient URIs). Through this 162 translation operation, the relay can create outgoing requests to one 163 or more additional URIs, thus creating the consent problem. 165 The consent problem is created by two types of translations: 166 translations based on local data and translations that involve 167 amplifications. 169 Translation operations based on local policy or local data (such as 170 registrations) are the vehicle by which a request is delivered 171 directly to an endpoint, when it would not otherwise be possible to. 172 In other words, if a spammer has the address of a user, 173 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA 174 (User Agent) of that user without having access to the registration 175 data that maps 'sip:user@example.com' to the user agent on which that 176 user is present. Thus, it is the usage of this registration data, 177 and more generally, the translation logic, which must be authorized 178 in order to prevent undesired communications. Of course, if the 179 spammer knows the address of the user agent, it will be able to 180 deliver requests directly to it. 182 Translation operations that result in more than one URI are a source 183 of amplification. Servers that do not perform translations, such as 184 outbound proxy servers, do not cause amplification. 186 Figure 2 shows a relay that performs translations. The user agent 187 client in the figure sends a SIP request to a URI representing a 188 resource in the domain 'example.com' (sip:resource@example.com). 189 This request may pass through a local outbound proxy (not shown), but 190 eventually arrives at a server authoritative for the domain 191 'example.com'. This server, which acts as a relay, performs a 192 translation operation, translating the target URI into one or more 193 recipient URIs, which may or may not belong to the domain 194 'example.com'. This relay may be, for instance, a proxy server or a 195 URI-list service [11]. 197 +-------+ 198 | | 199 >| UA | 200 / | | 201 / +-------+ 202 / 203 / 204 +-----------------------+ / 205 | | / 206 +-----+ | Relay | / +-------+ 207 | | | |/ | | 208 | UA |------>| |-------->| Proxy | 209 | | |+---------------------+|\ | | 210 +-----+ || Translation || \ +-------+ 211 || Logic || \ 212 |+---------------------+| \ [...] 213 +-----------------------+ \ 214 \ 215 \ +-------+ 216 \ | | 217 >| B2BUA | 218 | | 219 +-------+ 221 Figure 2: Relay performing a translation 223 This framework allows potential recipients of a translation to agree 224 to be actual recipients by giving the relay performing the 225 translation permission to send them traffic. 227 4. Architecture 229 Figure 3 shows the architectural elements of this framework. The 230 manipulation of a relay's translation logic typically causes the 231 relay to send a permission request, which in turn causes the 232 recipient to grant or deny the relay permissions for the translation. 233 Section 4.1 describes the role of permissions at a relay. 234 Section 4.2 discusses the actions taken by a relay when its 235 translation logic is manipulated by a client. Section 4.3 discusses 236 store-and-forward servers and their functionality. Section 4.4 237 describes how potential recipients can grant a relay permissions to 238 add them to the relay's translation logic. 240 +-----------------------+ Permission +-------------+ 241 | | Request | | 242 +--------+ | Relay |----------->| Store & Fwd | 243 | | | | | Server | 244 | Client | | | | | 245 | | |+-------+ +-----------+| +-------------+ 246 +--------+ ||Transl.| |Permissions|| | 247 | ||Logic | | || Permission | 248 | |+-------+ +-----------+| Request | 249 | +-----------------------+ V 250 | ^ ^ +-------------+ 251 | Manipulation | | Permission Grant | | 252 +---------------+ +-------------------| Recipient | 253 | | 254 +-------------+ 256 Figure 3: Reference Architecture 258 4.1. Permissions at a Relay 260 Relays implementing this framework obtain and store permissions 261 associated to their translation logic. These permissions indicate if 262 a particular recipient has agreed to receive traffic or not at any 263 given time. Recipients that have not given the relay permission to 264 send them traffic are simply ignored by the relay when performing a 265 translation. 267 In principle, permissions are valid as long as the context where they 268 were granted is valid or until they are revoked. For example, the 269 permissions obtained by a URI-list SIP service that distributes 270 MESSAGE requests to a set of recipients will be valid as long as the 271 URI-list SIP service exists or until the permissions are revoked. 273 Additionally, if a recipient is removed from a relay's translation 274 logic, the relay SHOULD delete the permissions related to that 275 recipient. For example, if the registration of a contact URI expires 276 or is otherwise terminated, the registrar deletes the permissions 277 related to that contact address. 279 It is also RECOMMENDED that relays request recipients to refresh 280 their permissions periodically. If a recipient fails to refresh its 281 permissions for a given period of time, the relay SHOULD delete the 282 permissions related to that recipient. 284 This framework does not provide any recommendation for the values 285 of the refreshment intervals because different applications may 286 have different requirements to set those values. 288 4.2. Consenting Manipulations on a Relay's Transaction Logic 290 This framework aims to ensure that any particular relay only performs 291 translations towards destinations that have given the relay 292 permission to perform such a translation. Consequently, when the 293 translation logic of a relay is manipulated (e.g., a new recipient 294 URI is added), the relay obtains permission from the new recipient in 295 order to install the new translation logic. Relays ask recipients 296 for permission using MESSAGE [5] requests. 298 For example, the relay hosting the URI-list service at 299 'sip:friends@example.com' performs a translation from that URI to a 300 set of recipient URIs. When a client (e.g., the administrator of 301 that URI-list service) adds 'bob@example.org' as a new recipient URI, 302 the relay sends a MESSAGE request to 'sip:bob@example.org' asking 303 whether or not it is OK to perform the translation from 304 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE 305 request carries in its message body a permission document that 306 describes the translation for which permissions are being requested 307 and a human readable part that also describes the translation. If 308 the answer is positive, the new translation logic is installed at the 309 relay. That is, the new recipient URI is added. 311 The human-readable part is included so that user agents that do 312 not understand permission documents can still process the request 313 and display it in a sensible way to the user. 315 Note that the mechanism to be used to manipulate the translation 316 logic of a particular relay depends on the relay. Two existing 317 mechanisms to manipulate translation logic are XCAP [9] and REGISTER 318 transactions. 320 In any case, relays implementing this framework SHOULD have a means 321 to indicate that a particular recipient URI is in the states 322 specified in [13] (i.e., pending, waiting, error, denied, or 323 granted). 325 4.3. Store-and-forward Servers 327 When a MESSAGE request with a permission document arrives to the 328 recipient URI to which it was sent by the relay, the receiving user 329 can grant or deny the permission needed to perform the translation. 330 However, users are not on-line all the time and, so, sometimes are 331 not able to receive MESSAGE requests. 333 This issue is also found in presence, where a user's status is 334 reported by a presence server instead of by the user's user agents, 335 which can go on and off line. Similarly, store-and-forward servers 336 are network elements that act as SIP user agents and handle MESSAGE 337 requests for a user. A store-and-forward server stores incoming 338 MESSAGE requests when the user is unavailable and delivers them when 339 the user is available again. 341 There are several mechanisms to implement store-and-forward message 342 services (e.g., with an instant message to email gateway). Any of 343 these mechanisms can be used between a user agent and its store-and- 344 forward server as long as they agree on which mechanism to use. 345 Therefore, this framework does not make any recommendation on the 346 interface between user agents and their store-and-forward servers. 348 Note that the same store-and-forward message service can handle 349 all incoming MESSAGE requests for a user while this is off line, 350 not only those MESSAGE requests with a permission document in 351 their bodies. 353 Even though store-and-forward servers perform a useful function and 354 they are expected to be deployed in most domains, some domains will 355 not deploy them from day one. However, user agents and relays in 356 domains without store-and-forward servers can still use this consent 357 framework. 359 When a relay requests permissions from an off-line user agent that 360 does not have an associated store-and-forward server, the relay will 361 obtain an error response indicating that its MESSAGE request could 362 not be delivered. The client that attempted to add the off-line user 363 to the relay's translation logic will be notified about the error 364 (e.g., using the Pending Additions event package [13]). This client 365 MAY attempt to add the same user at a later point, hopefully when the 366 user is on-line. Clients can discover whether or not a user is on- 367 line by using a presence service, for instance. 369 4.4. Recipients Grant Permissions 371 Relays include in the permission documents they generate URIs that 372 can be used by the recipient of the document to grant or deny the 373 relay the permission described in the document. Relays always 374 include SIP URIs and may include HTTP [2] URIs for this purpose. 375 Consequently, recipients provide relays with permissions using SIP 376 PUBLISH requests or HTTP GET requests. 378 5. Framework Operations 380 This section specifies this consent framework using an example of the 381 prototypical call flow. The elements described in Section 4 (i.e., 382 relays, translations, and permission servers) play an essential role 383 in this call flow. 385 Figure 4 shows the complete process to add a recipient URI 386 ('sip:B@example.com') to the translation logic of a relay. User A 387 attempts to add 'sip:B@example.com' as a new recipient URI to the 388 translation logic of the relay (1). User A uses XCAP [9] and the XML 389 (Extensible Markup Language) format for representing resource lists 390 [10] to perform this addition. Since the relay does not have 391 permission from 'sip:B@example.com' to perform translations towards 392 that URI, the relay places 'sip:B@example.com' in the pending state, 393 as specified in [13]. 395 A@example.com Relay B's Store & Fwd B@example.com 396 Server 398 |(1) Add Recipient | | 399 | sip:B@example.com | | 400 |--------------->| | | 401 |(2) HTTP 202 (Accepted) | | 402 |<---------------| | | 403 | |(3) MESSAGE sip:B@example | 404 | | Permission Document | 405 | |--------------->| | 406 | |(4) 202 Accepted| | 407 | |<---------------| | 408 |(5) SUBSCRIBE | | | 409 | Event: pending-additions | | 410 |--------------->| | | 411 |(6) 200 OK | | | 412 |<---------------| | | 413 |(7) NOTIFY | | | 414 |<---------------| | | 415 |(8) 200 OK | | | 416 |--------------->| | | 417 | | | |User B goes 418 | | | | on line 419 | | |(9) Request for | 420 | | | stored messages 421 | | |<---------------| 422 | | |(10) Delivery of| 423 | | | stored messages 424 | | |--------------->| 425 | |(11) PUBLISH uri-up | 426 | | Permission Document | 427 | |<--------------------------------| 428 | |(12) 200 OK | | 429 | |-------------------------------->| 430 |(13) NOTIFY | | | 431 |<---------------| | | 432 |(14) 200 OK | | | 433 |--------------->| | | 435 Figure 4: Prototypical call flow 437 5.1. Amplification Avoidance 439 Once 'sip:B@example.com' is in the pending state, the relay needs to 440 ask user B for permission by sending a MESSAGE request to 441 'sip:B@example.com'. However, the relay needs to ensure that it is 442 not used as an amplifier to launch amplification attacks. 444 In such an attack, the attacker would add a large number of recipient 445 URIs to the translation logic of a relay. The relay would then send 446 a MESSAGE request to each of those URIs. The bandwidth generated by 447 the relay would be much higher than the bandwidth used by the 448 attacker to add those URIs to the translation logic of the relay. 450 This framework uses a credit-based authorization mechanism to avoid 451 the attack just described. It requires users adding new recipient 452 URIs to a translation to generate an amount of bandwidth that is 453 comparable to the bandwidth the relay will generate when sending 454 MESSAGE requests towards those recipient URIs. When XCAP is used, 455 this requirement is met by not allowing clients to add more than one 456 URI per HTTP transaction. When a REGISTER transaction is used, this 457 requirement is met by not allowing clients to register more than one 458 contact per REGISTER transaction. 460 Therefore, relays implementing this framework MUST NOT allow clients 461 to add more than one URI per transaction. If a client using XCAP 462 attempts to add more than one URI in a single HTTP transaction, the 463 XCAP server SHOULD return an HTTP 409 (Conflict) response. The XCAP 464 server SHOULD describe the reason for the refusal in an XML body 465 using the element, as described in [9]. If a 466 client attempts to register more than one contact in a single 467 REGISTER transaction, the registrar SHOULD return a SIP 403 response 468 and explain the reason for the refusal in its reason phrase (e.g., 469 Maximum one contact per registration). 471 5.2. Subscription to the Permission Status 473 Clients need a way to be informed about the status of the operations 474 they requested. Otherwise, users may be waiting for an operation to 475 succeed when it has actually already failed. In particular, if the 476 target of the request for consent was not reachable and did not have 477 an associated store-and-forward server, the client needs to know to 478 retry the request later. The Pending Additions SIP event package 479 [13], which SHOULD be supported by relays, is a way to provide 480 clients with that information. 482 Clients can use the Pending Additions SIP event package to be 483 informed about the status of the operations they requested. That is, 484 the client will be informed when an operation (e.g., the addition of 485 a URI to a relay's translation logic) is authorized (and thus 486 executed) or rejected. Clients use the target URI of the SIP 487 translation being manipulated to subscribe to the 'pending-additions' 488 event package. 490 In our example, after receiving the response from the server (2), 491 user A subscribes to the Pending Additions event package at the relay 492 (5). This subscription keeps user A informed about the status of the 493 permissions (e.g., granted or denied) the relay will obtain. 495 5.3. Request for Permission 497 Relays that implement this framework MUST obtain permissions from 498 potential recipients before adding them to their translation logic. 499 Relays request permissions from potential recipients using MESSAGE 500 requests. 502 Section 5.6 describes the methods a relay can use to authenticate 503 recipients giving the relay permission to perform a particular 504 translation. These methods are SIP identity [8], P-Asserted-Identity 505 [4], a return routability test, or SIP digest. Relays that use the 506 method consisting of a return routability test have to send their 507 MESSAGE requests to a SIPS URI, as specified in Section 5.6. 509 MESSAGE requests sent to request permissions MUST include a 510 permission document and SHOULD include a human-readable part in their 511 bodies. The human-readable part contains the same information as the 512 permission document (but in a human-readable format), including the 513 URIs to grant and deny permissions. User agents that do not 514 understand permission documents can still process the request and 515 display it in a sensible way to the user, as they would display any 516 other instant message. This way, even if the user agent does not 517 implement this framework, the (human) user will be able to manually 518 click on the correct URI in order to grant or deny permissions. 520 In our example, on receiving the request to add User B to the 521 translation logic of the relay (1), the relay generates a MESSAGE 522 request (3) towards 'sip:B@example.com'. This MESSAGE request 523 carries a permission document, which describes the translation that 524 needs to be authorized and carries a set of URIs to be used by the 525 recipient to grant or to deny the relay permission to perform that 526 translation. User B will authorize the translation by using one of 527 those URIs, as described in Section 5.6. The MESSAGE request also 528 carries a body part that contains the same information as the 529 permission document but in a human-readable format. 531 When User B uses one of the URIs in the permission document to grant 532 or deny permissions, the relay needs to make sure that it was 533 actually User B the one using that URI, and not an attacker. The 534 relay can use any of the methods described in Section 5.6 to 535 authenticate the permission document. 537 5.4. Permission Document Structure 539 A permission document is the XML representation of a permission. A 540 permission document contains several pieces of data: 542 Identity of the Sender: A URI representing the identity of the sender 543 for whom permissions are granted. 545 Identity of the Original Recipient: A URI representing the identity 546 of the original recipient, which is used as the input for the 547 translation operation. This is also called the target URI. 549 Identity of the Final Recipient: A URI representing the result of the 550 translation. The permission grants ability for the sender to send 551 requests to the target URI, and for a relay receiving those 552 requests to forward them to this URI. This is also called the 553 recipient URI. 555 URIs to Grant Permission: URIs that recipients can use to grant the 556 relay permission to perform the translation described in the 557 document. At least one of these URIs MUST be a SIP or SIPS URI. 558 HTTP and HTTPS URIs MAY also be used. 560 URIs to Deny Permission: URIs that recipients can use to deny the 561 relay permission to perform the translation described in the 562 document. At least one of these URIs MUST be a SIP or SIPS URI. 563 HTTP and HTTPS URIs MAY also be used. 565 Permission documents may contain wildcards. For example, a 566 permission document may request permission for any relay to forward 567 requests coming from a particular sender to a particular recipient. 568 Such a permission document would apply to any target URI. That is, 569 the field containing the identity of the original recipient would 570 match any URI. However, the recipient URI MUST NOT be wildcarded. 572 Entities implementing this framework MUST support the format for 573 permission documents defined in [12]. 575 In our example, the permission document in the MESSAGE request (3) 576 sent by the relay contains the following values: 578 Identity of the Sender: Any. 580 Identity of the Original Recipient: sip:friends@example.com 582 Identity of the Final Recipient: sip:B@example.com 583 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com 585 URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 587 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com 589 URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 591 It is expected that the Sender field often contains a wildcard. 592 However, scenarios involving request-contained URI lists, such as the 593 one described in Section 5.9, may require permission documents that 594 apply to a specific sender. Of course, in cases where the identity 595 of the sender matters, relays MUST authenticate senders. 597 5.5. Permission Requested Notification 599 On receiving the MESSAGE request (3), User B's store-and-forward 600 server stores it because User B is off line at that point. When User 601 B goes on line, User B fetches all the requests its store-and-forward 602 server has stored (9). 604 5.6. Permission Grant 606 A client gives a relay permission to execute the translation 607 described in a permission document by sending a SIP PUBLISH or an 608 HTTP GET request to one of the URIs to grant permissions contained in 609 the document. Similarly, a client denies a relay permission to 610 execute the translation described in a permission document by sending 611 a SIP PUBLISH or an HTTP GET request to one of the URIs to deny 612 permissions contained in the document. Requests to grant or deny 613 permissions contain an empty body. 615 In our example, User B obtains the permission document (10) that was 616 received earlier by its store-and-forward server in the MESSAGE 617 request (3). User B authorizes the translation described in the 618 permission document received by sending a PUBLISH request (11) to the 619 SIP URI to grant permissions contained in the permission document. 621 Relays MUST ensure that the SIP PUBLISH or the HTTP GET request 622 received was generated by the recipient of the translation and not by 623 an attacker. Relays can use four methods to authenticate those 624 requests. SIP identity, P-Asserted-Identity [4], a return 625 routability test, or SIP digest. While return routability tests can 626 be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP 627 identity, P-Asserted-Identity, and SIP digest can only be used to 628 authenticate SIP PUBLISH requests. SIP digest can only be used to 629 authenticate clients that share a secret with the relay (e.g., 630 clients that are in the same domain as the relay). 632 5.6.1. SIP Identity 634 The SIP identity [8] mechanism can be used to authenticate the sender 635 of a PUBLISH request. The relay MUST check that the originator of 636 the PUBLISH request is the owner of the recipient URI in the 637 permission document. Otherwise, the PUBLISH request SHOULD be 638 responded with a 401 (Unauthorized) response and MUST NOT be 639 processed further. 641 5.6.2. P-Asserted-Identity 643 The P-Asserted-Identity [4] mechanism can also be used to 644 authenticate the sender of a PUBLISH request. However, as discussed 645 in RFC 3325 [4], this mechanism should only be used within networks 646 of trusted SIP servers. That is, the use of this mechanism is only 647 applicable inside an administrative domain with previously agreed- 648 upon policies. 650 The relay MUST check that the originator of the PUBLISH request is 651 the owner of the recipient URI in the permission document. 652 Otherwise, the PUBLISH request SHOULD be responded with a 401 653 (Unauthorized) response and MUST NOT be processed further. 655 5.6.3. Return Routability 657 SIP identity provides a good authentication mechanism for incoming 658 PUBLISH requests. Nevertheless, SIP identity is not widely available 659 on the public Internet yet. That is why an authentication mechanism 660 that can already be used at this point is needed. 662 Return routability tests do not provide the same level of security as 663 SIP identity, but they provide a better-than-nothing security level 664 in architectures where the SIP identity mechanism is not available 665 (e.g., the current Internet). The relay generates an unguessable URI 666 (i.e., with a cryptographically random user part) and places it in 667 the permission document in the MESSAGE request (3). The recipient 668 needs to send a SIP PUBLISH request or an HTTP GET request to that 669 URI. Any incoming request sent to that URI SHOULD be considered 670 authenticated by the relay. 672 Note that the return routability method is the only one that 673 allows the use of HTTP URIs in permission documents. The other 674 methods require the use of SIP URIs. 676 Relays using a return routability test to perform this authentication 677 MUST send the MESSAGE request with the permission document to a SIPS 678 URI. This ensures that attackers do not get access to the 679 (unguessable) URI. Thus, the only user able to use the (unguessable) 680 URI is the receiver of the MESSAGE request. Similarly, permission 681 documents sent by relays using a return routability test MUST only 682 contain secure URIs (i.e., SIPS and HTTPS) to grant and deny 683 permissions. The user part of these URIs MUST be cryptographically 684 random with at least 32 bits of randomness. 686 Relays can transition from return routability tests to SIP identity 687 by simply requiring the use of SIP identity for incoming PUBLISH 688 requests. That is, such a relay would reject PUBLISH requests that 689 did not use SIP identity. 691 5.6.4. SIP Digest 693 The SIP digest mechanism can be used to authenticate the sender of a 694 PUBLISH request as long as that sender shares a secret with the 695 relay. The relay MUST check that the originator of the PUBLISH 696 request is the owner of the recipient URI in the permission document. 697 Otherwise, the PUBLISH request SHOULD be responded with a 401 698 (Unauthorized) response and MUST NOT be processed further. 700 5.7. Permission Granted Notification 702 On receiving the PUBLISH request (11), the relay sends a NOTIFY 703 request (13) to inform user A that the permission for the translation 704 has been received and that the translation logic at the relay has 705 been updated. That is, 'sip:B@example.com' has been added as a 706 recipient URI. 708 5.8. Permission Revocation 710 At any time, if a recipient wants to revoke any permission, it uses 711 the URI it received in the permission document to deny the 712 permissions it previously granted. If a recipient loses this URI for 713 some reason, it needs to wait until it receives a new request 714 produced by the translation. Such a request will contain a Trigger- 715 Consent header field with a URI. That Trigger-Consent header field 716 will have a target-uri parameter identifying the target URI of the 717 translation. The recipient needs to send a PUBLISH request with an 718 empty body to the URI in the Trigger-Consent header field in order to 719 receive a MESSAGE request from the relay. Such a MESSAGE request 720 will contain a permission document with a URI to revoke the 721 permission that was previously granted. 723 Figure 5 shows an example of how a user that lost the URI to revoke 724 permissions at a relay can obtain a new URI using the Trigger-Consent 725 header field of an incoming request. The user rejects an incoming 726 INVITE (1) request, which contains a Trigger-Consent header field. 727 Using the URI in the that header field, the user sends a PUBLISH 728 request (4) to the relay. On receiving the PUBLISH request (4), the 729 relay generates a MESSAGE request (6) towards the user. Finally, the 730 user revokes the permissions by sending a PUBLISH request (8) to the 731 relay. 733 Relay B@example.com 734 |(1) INVITE | 735 | Trigger-Consent: sip:123@relay.example.com 736 | ;target-uri="sip:friends@relay.example.com" 737 |---------------------------->| 738 |(2) 603 Decline | 739 |<----------------------------| 740 |(3) ACK | 741 |---------------------------->| 742 |(4) PUBLISH sip:123@relay.example.com 743 |<----------------------------| 744 |(5) 200 OK | 745 |---------------------------->| 746 |(6) MESSAGE sip:B@example | 747 | Permission Document | 748 |---------------------------->| 749 |(7) 200 OK | 750 |<----------------------------| 751 |(8) PUBLISH uri-deny | 752 |<----------------------------| 753 |(9) 200 OK | 754 |---------------------------->| 756 Figure 5: Permission Revocation 758 5.9. Request-contained URI Lists 760 In the scenarios described so far, a user adds recipient URIs to the 761 translation logic of a relay. However, the relay does not perform 762 translations towards those URIs until permissions are obtained. 764 URI-list services using request-contained URI lists are a special 765 case because the selection of recipient URIs is performed at the same 766 time as the communication attempt. A user places a set of recipient 767 URIs in a request and sends it to a relay so that the relay sends a 768 similar request to all those recipient URIs. 770 Relays implementing this framework and providing this type of URI- 771 list services behave in a slightly different way as the relays 772 described so far. This type of relay also maintains a list of 773 recipient URIs for which permissions have been received. Clients 774 also manipulate this list using a manipulation mechanism (e.g., 775 XCAP). Nevertheless, this list does not represent the recipient URIs 776 of every translation performed by the relay. This list just 777 represents all the recipient URIs for which permissions have been 778 received. That is, the set of URIs that will be accepted if a 779 request containing a URI-list arrives to the relay. This set of URIs 780 is a super set of the recipient URIs of any particular translation 781 the relay performs. 783 On receiving a request-contained URI-list, the relay checks whether 784 or not it has permissions for all the URIs contained in the incoming 785 URI-list. If it does, the relay performs the translation. If it 786 lacks permissions for one of more URIs, the relay does not perform 787 the translation and returns an error response. 789 A relay that receives a request-contained URI-list with a URI for 790 which the relay has no permissions SHOULD return a 470 (Consent 791 Needed) response. The relay SHOULD add a Permission-Missing header 792 field with the URIs for which the relay has no permissions. 794 A client receiving such a response uses a manipulation mechanism 795 (e.g., XCAP) to add those URIs to the relay's list of URIs. The 796 relay obtains permissions for those URIs as usual. 798 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 799 the Permission-Missing header field. Some of its elements are 800 defined in RFC 3261 [3]. 802 Permission-Missing = "Permission-Missing" HCOLON per-miss-spec 803 *( COMMA per-miss-spec ) 804 per-miss-spec = ( name-addr / addr-spec ) 805 *( SEMI generic-param ) 807 The following is an example of a Permission-Missing header field: 809 Permission-Missing: sip:C@example.com 811 Figure 6 shows a relay that receives a request (1) that contains URIs 812 for which the relay does not have permission. The relay rejects the 813 request with a 470 (Consent Needed) response (2). That response 814 contains a Permission-Missing header field with the URIs for which 815 there was no permission. 817 A@example.com Relay 819 |(1) INVITE | 820 | sip:B@example.com | 821 | sip:C@example.com | 822 |---------------------->| 823 |(2) 470 Consent Needed | 824 | Permission-Missing: sip:C@example.com 825 |<----------------------| 826 |(3) ACK | 827 |---------------------->| 829 Figure 6: INVITE with a URI list in its body 831 5.10. Registrations 833 Registrations are a special type of translations. The user 834 registering has a trust relationship with the registrar in its home 835 domain. This is not the case when a user gives any type of 836 permissions to a relay in a different domain. 838 Traditionally, REGISTER transactions have performed two operations at 839 the same time: setting up a translation and authorizing the use of 840 that translation. For example, a user registering its current 841 contact URI is giving permission to the registrar to forward traffic 842 sent to the user's AoR (Address of Records) to the registered contact 843 URI. This works fine when the entity registering is the same as the 844 one that will be receiving traffic at a later point (e.g., the entity 845 receives traffic over the same connection used for the registration 846 as described in [15]). However, this schema creates some potential 847 attacks which relate to third-party registrations. 849 An attacker binds, via a registration, his or her AoR with the 850 contact URI of a victim. Now, the victim will receive unsolicited 851 traffic that was originally addressed to the attacker. 853 The process of authorizing a registration is shown in Figure 7. User 854 A performs a third-party registration (1) and receives a 202 855 (Accepted) response (2). 857 Since the relay does not have permission from 858 'sip:a@ws123.example.com' to perform translations towards that URI, 859 the relay places 'sip:a@ws123.example.com' in the 'pending' state. 860 Once 'sip:a@ws123.example.com' is in the 'Permission Pending' state, 861 the registrar needs to ask 'sip:a@ws123.example.com' for permission 862 by sending a MESSAGE request (3). 864 After receiving the response from the server (2), user A subscribes 865 to the Pending Additions event package at the registrar (4). This 866 subscription keeps the user informed about the status of the 867 permissions (e.g., granted or denied) the registrar will obtain. The 868 rest of the process is similar to the one described in Section 5. 870 A@example.com Registrar a@ws123.example.com 872 |(1) REGISTER | | 873 | Contact: sip:a@ws123.example.com | 874 |------------------>| | 875 |(2) 202 Accepted OK| | 876 |<------------------| | 877 | |(3) MESSAGE sip:a@ws123.example 878 | | Permission Document 879 | |------------------>| 880 | |(4) 200 OK | 881 | |<------------------| 882 |(5) SUBSCRIBE | | 883 | Event: pending-additions | 884 |------------------>| | 885 |(6) 200 OK | | 886 |<------------------| | 887 |(7) NOTIFY | | 888 |<------------------| | 889 |(8) 200 OK | | 890 |------------------>| | 891 | |(9) PUBLISH uri-up | 892 | |<------------------| 893 | |(10) 200 OK | 894 | |------------------>| 895 |(11) NOTIFY | | 896 |<------------------| | 897 |(12) 200 OK | | 898 |------------------>| | 900 Figure 7: Registration 902 Permission documents generated by registrars are typically very 903 general. For example, in one such document a registrar may ask a 904 recipient for permission to forward any request from any sender to 905 the recipient's URI. This is the type of granularity that this 906 framework intends to provide for registrations. Users who want to 907 define how incoming requests are treated with a finer granularity 908 (e.g., requests from user A should only be accepted between 9:00 and 909 11:00) should use other mechanisms such as CPL [14]. 911 Note that, as indicated previously, user agents using the same 912 connection to register and to receive traffic from the registrar, as 913 described in [15] do not need to use the mechanism described in this 914 section. 916 A user agent being registered by a third party may not be able to use 917 the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to 918 prove to the registrar that the user agent is the owner of the URI 919 being registered (e.g., sip:user@192.0.2.1), which is the recipient 920 URI of the translation. In this case, return routability MUST be 921 used. 923 5.11. Relays Generating Traffic towards Recipients 925 A relay executing a translation that involves sending a request to a 926 URI from which permissions were obtained previously SHOULD add a 927 Trigger-Consent header field to the request. The URI in the Trigger- 928 Consent header field MUST have a target-uri parameter identifying the 929 target-uri of the translation. 931 On receiving a PUBLISH request addressed to the URI a relay placed in 932 a Trigger-Consent header field, the relay SHOULD send a MESSAGE 933 request to corresponding recipient with a permission document. 934 Therefore, the relay needs to be able to correlate the URI that 935 places in the Trigger-Consent header field with the recipient of the 936 translation. 938 The following is the augmented Backus-Naur Form (BNF) [6] syntax of 939 the Trigger-Consent header field. Some of its elements are defined 940 in RFC 3261 [3]. 942 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 943 *( COMMA trigger-cons-spec ) 944 trigger-cons-spec = ( SIP-URI / SIPS-URI ) 945 *( SEMI trigger-param ) 946 trigger-param = target-uri / generic-param 947 target-uri = "target-uri" EQUAL 948 LDQUOT *( qdtext / quoted-pair ) RDQUOT 950 The target-uri header field parameter MUST contain a URI. 952 The following is an example of a Trigger-Consent header field: 954 Trigger-Consent: sip:123@relay.example.com 955 ;target-uri="sip:friends@relay.example.com" 957 6. IANA Considerations 959 The IANA is requested to add the following new response code to the 960 Methods and Response Codes subregistry under the SIP Parameters 961 registry. 963 Response Code Number: 470 964 Default Reason Phrase: Consent Needed 965 Reference: [RFCxxxx] 967 Note to the RFC editor: substitute xxxx with the RFC number of this 968 document. 970 The IANA is requested to add the following new SIP header field to 971 the Header Fields subregistry under the SIP Parameters registry. 973 Header Name: Trigger-Consent 974 Compact Form: (none) 975 Reference: [RFCxxxx] 977 Note to the RFC editor: substitute xxxx with the RFC number of this 978 document. 980 The IANA is requested to add the following new SIP header field to 981 the Header Fields subregistry under the SIP Parameters registry. 983 Header Name: Permission-Missing 984 Compact Form: (none) 985 Reference: [RFCxxxx] 987 Note to the RFC editor: substitute xxxx with the RFC number of this 988 document. 990 7. Security Considerations 992 Security has been discussed throughout the whole document. However, 993 there are some issues that deserve special attention. 995 The specifications of mechanisms to manipulate translation logic at 996 relays usually stress the importance of client authentication and 997 authorization. Having relays authenticate and authorize clients 998 manipulating their translation logic keeps unauthorized clients from 999 adding recipients to a translation. However, this does not prevent 1000 authorized clients to add recipients to a translation without their 1001 consent. Additionally, some relays provide web interfaces for any 1002 client to add new recipients to the translation (e.g., many email 1003 mailing lists are operated in this way). In this situation, every 1004 client is considered authorized to manipulate the translation logic 1005 at the relay. This makes the use of this framework even more 1006 important. Therefore, it is RECOMMENDED that relays performing 1007 translations implement this framework. 1009 As pointed out in Section 5.6.3, when return routability tests are 1010 used to authenticate recipients granting or denying permissions, the 1011 URIs used to grant or deny permissions need to be protected from 1012 attackers. SIPS URIs provide a good tool to meet this requirement, 1013 as described in [12]. When store-and-forward servers are used, the 1014 interface between a user agent and its store-and-forward server may 1015 not be based on SIP. In such case, SIPS cannot be used to secure 1016 those URIs. It MUST be possible for store-and-forward servers to 1017 deliver encrypted and integrity-protected messages to their user 1018 agents. 1020 The information provided by the Pending Additions event package can 1021 be sensitive. For this reason, as described in [13], relays need to 1022 use strong means for authentication and information confidentiality. 1023 SIPS URIs are a good mechanism to meet this requirement. 1025 8. Acknowledges 1027 Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided 1028 useful ideas on this document. Ben Campbell, AC Mahendran, and Mary 1029 Barnes performed a thorough review of this document. 1031 9. References 1033 9.1. Normative References 1035 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1036 Levels", BCP 14, RFC 2119, March 1997. 1038 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1039 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1040 HTTP/1.1", RFC 2616, June 1999. 1042 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1043 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1044 Session Initiation Protocol", RFC 3261, June 2002. 1046 [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1047 to the Session Initiation Protocol (SIP) for Asserted Identity 1048 within Trusted Networks", RFC 3325, November 2002. 1050 [5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1051 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1052 Instant Messaging", RFC 3428, December 2002. 1054 [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1055 Specifications: ABNF", RFC 4234, October 2005. 1057 [7] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements for 1058 Consent-Based Communications in the Session Initiation Protocol 1059 (SIP)", RFC 4453, April 2006. 1061 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1062 Identity Management in the Session Initiation Protocol (SIP)", 1063 RFC 4474, August 2006. 1065 [9] Rosenberg, J., "The Extensible Markup Language (XML) 1066 Configuration Access Protocol (XCAP)", 1067 draft-ietf-simple-xcap-11 (work in progress), May 2006. 1069 [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for 1070 Representing Resource Lists", 1071 draft-ietf-simple-xcap-list-usage-05 (work in progress), 1072 February 2005. 1074 [11] Camarillo, G. and A. Roach, "Framework and Security 1075 Considerations for Session Initiation Protocol (SIP) Uniform 1076 Resource Identifier (URI)-List Services", 1077 draft-ietf-sipping-uri-services-05 (work in progress), 1078 January 2006. 1080 [12] Camarillo, G., "A Document Format for Requesting Consent", 1081 draft-ietf-sipping-consent-format-00 (work in progress), 1082 September 2006. 1084 [13] Camarillo, G., "The Session Initiation Protocol (SIP) Pending 1085 Additions Event Package", 1086 draft-ietf-sipping-pending-additions-00 (work in progress), 1087 September 2006. 1089 9.2. Informative References 1091 [14] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1092 Language (CPL): A Language for User Control of Internet 1093 Telephony Services", RFC 3880, October 2004. 1095 [15] Jennings, C. and R. Mahy, "Managing Client Initiated 1096 Connections in the Session Initiation Protocol (SIP)", 1097 draft-ietf-sip-outbound-04 (work in progress), June 2006. 1099 Authors' Addresses 1101 Jonathan Rosenberg 1102 Cisco Systems 1103 600 Lanidex Plaza 1104 Parsippany, NJ 07054 1105 US 1107 Phone: +1 973 952-5000 1108 Email: jdrosen@cisco.com 1109 URI: http://www.jdrosen.net 1111 Gonzalo Camarillo (editor) 1112 Ericsson 1113 Hirsalantie 11 1114 Jorvas 02420 1115 Finland 1117 Email: Gonzalo.Camarillo@ericsson.com 1119 Dean Willis 1120 Cisco Systems 1121 2200 E. Pres. George Bush Turnpike 1122 Richardson, TX 75082 1123 USA 1125 Email: dean.willis@softarmor.com 1127 Intellectual Property Statement 1129 The IETF takes no position regarding the validity or scope of any 1130 Intellectual Property Rights or other rights that might be claimed to 1131 pertain to the implementation or use of the technology described in 1132 this document or the extent to which any license under such rights 1133 might or might not be available; nor does it represent that it has 1134 made any independent effort to identify any such rights. Information 1135 on the procedures with respect to rights in RFC documents can be 1136 found in BCP 78 and BCP 79. 1138 Copies of IPR disclosures made to the IETF Secretariat and any 1139 assurances of licenses to be made available, or the result of an 1140 attempt made to obtain a general license or permission for the use of 1141 such proprietary rights by implementers or users of this 1142 specification can be obtained from the IETF on-line IPR repository at 1143 http://www.ietf.org/ipr. 1145 The IETF invites any interested party to bring to its attention any 1146 copyrights, patents or patent applications, or other proprietary 1147 rights that may cover technology that may be required to implement 1148 this standard. Please address the information to the IETF at 1149 ietf-ipr@ietf.org. 1151 Disclaimer of Validity 1153 This document and the information contained herein are provided on an 1154 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1155 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1156 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1157 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1158 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1161 Copyright Statement 1163 Copyright (C) The Internet Society (2006). This document is subject 1164 to the rights, licenses and restrictions contained in BCP 78, and 1165 except as set forth therein, the authors retain all their rights. 1167 Acknowledgment 1169 Funding for the RFC Editor function is currently provided by the 1170 Internet Society.