idnits 2.17.1 draft-ietf-sip-content-indirect-mech-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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 745. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (October 25, 2004) is 7085 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2068 (ref. '4') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '6') ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '8') == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-02 == Outdated reference: A later version (-07) exists of draft-fielding-uri-rfc2396bis-06 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Initiation Protocol E. Burger, Ed. 3 Internet-Draft Brooktrout Technology, Inc. 4 Expires: April 25, 2005 October 25, 2004 6 A Mechanism for Content Indirection in Session Initiation Protocol 7 (SIP) Messages 8 draft-ietf-sip-content-indirect-mech-05 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document defines an extension to the URL MIME External-Body 44 Access-Type to satisfy the content indirection requirements for SIP. 45 These extensions are aimed at allowing any MIME part in a SIP message 46 to be referred to indirectly via a URI. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 4 53 3.1 Presence Notification . . . . . . . . . . . . . . . . . . 4 54 3.2 Document Sharing . . . . . . . . . . . . . . . . . . . . . 5 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Application of RFC2017 to the Content Indirection Problem . 7 57 5.1 Specifying support for content indirection . . . . . . . . 7 58 5.2 Mandatory support for HTTP URI . . . . . . . . . . . . . . 7 59 5.3 Rejecting content indirection . . . . . . . . . . . . . . 7 60 5.4 Specifying the location of the content via a URI . . . . . 8 61 5.5 Marking indirect content optional . . . . . . . . . . . . 8 62 5.6 Specifying versioning information for the URI . . . . . . 8 63 5.7 Specifying the lifetime of the URI . . . . . . . . . . . . 9 64 5.8 Specifying the type of the indirect content . . . . . . . 9 65 5.9 Specifying the size of the indirect content . . . . . . . 10 66 5.10 Specifying the purpose of the indirect content . . . . . 10 67 5.11 Specifying multiple URIs for content indirection . . . . 10 68 5.12 Specifying a hash value for the indirect content . . . . 11 69 5.13 Supplying additional comments about the indirect 70 content . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.14 Relationship to Call-Info, Error-Info, and Alert-Info 72 Headers . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1 Single Content Indirection . . . . . . . . . . . . . . . . 13 75 6.2 Multipart MIME with Content Indirection . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 78 9. Contributions . . . . . . . . . . . . . . . . . . . . . . . 16 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 11.1 Normative References . . . . . . . . . . . . . . . . . . . 17 82 11.2 Informative References . . . . . . . . . . . . . . . . . . 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . 19 86 1. Terminology 88 RFC 2119 [5] defines the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL". 92 2. Introduction 94 The purpose of the Session Initiation Protocol [9] (SIP) is to 95 create, modify, or terminate sessions with one or more participants. 96 SIP messages, like HTTP, are syntactically composed of a start line, 97 one or more headers, and an optional body. Unlike HTTP, SIP is not 98 designed as a general-purpose data transport protocol. 100 There are numerous reasons why it might be desirable to indirectly 101 specify the content of the SIP message body. For bandwidth limited 102 applications such as cellular wireless, indirection provides a means 103 to annotate the (indirect) content with meta-data which may be used 104 by the recipient to determine whether or not to retrieve the content 105 over the resource limited link. 107 It is also possible that the content size to be transferred might 108 potentially overwhelm intermediate signaling proxies, thereby 109 unnecessarily increasing network latency. For time-sensitive SIP 110 applications, this may be unacceptable. Indirect content can remedy 111 this by moving the transfer of this content out of the SIP signaling 112 network and into a potentially separate data transfer channel. 114 There may also be scenarios where the session related data (body) 115 that needs to be conveyed does not directly reside on the endpoint or 116 User Agent. In such scenarios, it is desirable to have a mechanism 117 whereby the SIP message can contain an indirect reference to the 118 desired content. The receiving party would then use this indirect 119 reference to retrieve the content via a non-SIP transfer channel such 120 as HTTP, FTP, or LDAP. 122 The purpose of content indirection is purely to provide an 123 alternative transport mechanism for SIP MIME body parts. With the 124 exception of the transport mechanism, indirect body parts are 125 equivalent, and should have the same treatment, as in-line body 126 parts. 128 Previous attempts at solving the content indirection problem made use 129 of the text/uri-list [6] MIME type. While attractive for its 130 simplicity (a list of URIs delimited by end-of-line markers), it 131 failed to satisfy a number of the requirements for a more 132 general-purpose content indirection mechanism in SIP. Most notably 133 lacking is the ability to specify various attributes on a per-URI 134 basis. These attributes might include version information, the MIME 135 type of the referenced content, etc. 137 In searching for a replacement for the text/uri-list MIME type, 138 RFC2017 defines a strong candidate. RFC2017 [1] defines an extension 139 to the message/external-body MIME type originally defined in RFC2046 140 [3]. The extension that RFC2017 makes is to allow a generic URI to 141 specify the location of the content rather than protocol specific 142 parameters for FTP, etc. as originally defined in RFC2046. While 143 providing most of the functionality needed for a SIP content 144 indirection mechanism, RFC2017 by itself is not a complete solution. 145 This document specifies the usage of RFC2017 necessary to fulfill the 146 requirements outlined for content indirection. 148 The requirements can be classified as applying either to the URI, 149 which indirectly references the desired content, or to the content 150 itself. Where possible, existing MIME parameters and entity headers 151 are used to satisfy those requirements. MIME (Content-Type) 152 parameters are the preferred manner of describing the URI while 153 entity headers are the preferred manner of describing the (indirect) 154 content. See RFC 2045 [2] for a description of most of these entity 155 headers and MIME parameters. 157 3. Example Use Cases 159 There are several example users of such a content indirection 160 mechanism. These are examples only and are not intended to limit the 161 scope or applicability of the mechanism. 163 3.1 Presence Notification 165 The information carried in a presence document could potentially 166 exceed the recommended size for a SIP (NOTIFY) request, particularly 167 if the document carries aggregated information from multiple 168 endpoints. In such a situation, it would be desirable to send the 169 NOTIFY request with an indirect pointer to the presence document 170 which could then be retrieved by, for example, HTTP. 172 Watcher Presence Server 173 | | 174 | SUBSCRIBE | 175 |-------------------------->| 176 | 200 OK | 177 |<--------------------------| 178 | | 179 | NOTIFY | 180 |-------------------------->| 181 | 200 OK | 182 |<--------------------------| 183 | | 184 | NOTIFY (w/URI) | 185 |<--------------------------| 186 | 200 | 187 |-------------------------->| 188 | | 189 | HTTP GET | 190 |-------------------------->| 191 | | 192 | application/cpim-pidf+xml | 193 |<--------------------------| 194 | | 196 In this example, the presence server returns an HTTP URI pointing to 197 a presence document on the presence server which the watcher can then 198 fetch using an HTTP GET. 200 3.2 Document Sharing 202 During an instant messaging conversation, a useful service is 203 document sharing wherein one party sends an IM (MESSAGE request) with 204 an indirect pointer to a document which is meant to be rendered by 205 the remote party. Carrying such a document directly in the MESSAGE 206 request is not appropriate for most documents. Furthermore, the 207 document to be shared may reside on a completely independent server 208 from the originating party. 210 UAC UAS Web Server 211 | | | 212 | MESSAGE w/URI | | 213 |------------------->| | 214 | 200 | | 215 |<-------------------| | 216 | | | 217 | | HTTP GET | 218 | |--------------->| 219 | | image/jpeg | 220 | |<---------------| 221 | | | 223 In this example, a user wishes to exchange a JPEG image that she has 224 stored on her web server with another user she has an IM conversation 225 with. She intends to render the JPEG inline in the IM conversation. 226 The recipient of the MESSAGE request launches a HTTP GET request to 227 the web server to retrieve the JPEG image. 229 4. Requirements 231 o It MUST be possible to specify the location of content via a URI. 232 Such URIs MUST conform with RFC2396 [7] or its successors, such as 233 [13]. 234 o It MUST be possible to specify the length of the indirect content. 235 o It MUST be possible to specify the type of the indirect content. 236 o It MUST be possible to specify the disposition of each URI 237 independently. 238 o It MUST be possible to label each URI to identify if and when the 239 content referred to by that URI has changed. Applications of this 240 mechanism may send the same URI more than once. The intention of 241 this requirement is to allow the receiving party to determine if 242 the content referenced by the URI has changed without having to 243 actually retrieve that content. Example ways the URI could be 244 labeled include a sequence number, timestamp, version number, etc. 245 When used with HTTP, the entity-tag (ETAG) mechanism as defined in 246 RFC2068 [4] may be appropriate. Note that we are not labeling the 247 URI itself, but the content to which the URI refers, and that the 248 label is therefore effectively "metadata" of the content itself. 249 o It MUST be possible to specify the time span for which a given URI 250 is valid. This may or may not be the same as the lifetime for the 251 content itself. 252 o It MUST be possible for the UAC and the UAS to indicate support of 253 this content indirection mechanism. A fallback mechanism SHOULD 254 be specified in the event that one of the parties is unable to 255 support content indirection. 257 o It MUST be possible for the UAC and UAS to negotiate the type of 258 the indirect content when using the content indirection mechanism. 259 o It MUST be possible for the UAC and UAS to negotiate support for 260 URI scheme(s) to be used in the content indirection mechanism. 261 This is in addition to the ability to negotiate the content type. 262 o It SHOULD be possible to ensure the integrity and confidentiality 263 of the URI when it is received by the remote party. 264 o It MUST be possible to process the content indirection without 265 human intervention. 266 o It MUST allow for indirect transference of content in any SIP 267 message that would otherwise carry that content as a body. 269 5. Application of RFC2017 to the Content Indirection Problem 271 The following text describes the application of RFC2017 to the 272 requirements for content indirection. 274 5.1 Specifying support for content indirection 276 A UAC/UAS indicates support for content indirection by including the 277 message/external-body MIME type in the Accept header. The UAC/UAS 278 MAY supply additional values in the Accept header to indicate the 279 content types that it is willing to accept, either directly or 280 through content indirection. User-Agents supporting content 281 indirection MUST support content indirection of the application/sdp 282 MIME type. 284 For example: 286 Accept: message/external-body, image/*, application/sdp 288 5.2 Mandatory support for HTTP URI 290 Applications which use this content indirection mechanism MUST 291 support the HTTP URI scheme. Additional URI schemes MAY be used, but 292 a UAC/UAS MUST support receiving a HTTP URI for indirect content if 293 it advertises support for content indirection. 295 The UAS MAY advertise alternate access schemes in the schemes 296 parameter of the Contact header in the UAS response to the UAC's 297 session establishment request (e.g., INVITE, SUBSCRIBE, etc.), as 298 described in Application Interaction [11]. 300 5.3 Rejecting content indirection 302 If a UAS receives a SIP request which contains a content indirection 303 payload, and the UAS cannot or does not wish to support such a 304 content type, it MUST reject the request with a 415 Unsupported Media 305 Type response as defined in section 21.4.13 of SIP [9] In 306 particular, the UAC should note the absence of the 307 message/external-body MIME type in the Accept header of this response 308 to indicate that the UAS does not support content indirection, or the 309 absence of the particular MIME type of the requested comment to 310 indicate that the UAS does not support the particular media type. 312 5.4 Specifying the location of the content via a URI 314 The URI for the indirect content is specified in a "URI" parameter of 315 the message/external-body MIME type. An access-type parameter 316 indicates that the external content is referenced by a URI. HTTP URI 317 specifications MUST conform to RFC2396 [7] or its successors [13]. 319 For example: 321 Content-Type: message/external-body; 322 access-type="URL"; 323 URL="http://www.example.com/the-indirect-content" 325 5.5 Marking indirect content optional 327 Some content is not critical to the context of the communication if 328 there is a fetch or conversion failure. The content indirection 329 mechanism uses the Critical-Content mechanism described in RFC3459 330 [10]. In particular, if the UAS is unable to fetch or render an 331 optional body part, then the server MUST NOT return an error to the 332 UAC. 334 5.6 Specifying versioning information for the URI 336 In order to determine whether or not the content indirectly 337 referenced by the URI has changed, a Content-ID entity header is 338 used. The syntax of this header is defined in RFC2045 [2]. Changes 339 in the underlying content referred to by a URI MUST result in a 340 change in the Content-ID associated with that URI. Multiple SIP 341 messages carrying URI that refer to the same content SHOULD reuse the 342 same Content-ID to allow the receiver to cache this content and avoid 343 unnecessary retrievals. The Content-ID is intended to be globally 344 unique and SHOULD be temporally unique across SIP dialogs. 346 For example: 348 Content-ID: <4232423424@www.example.com> 350 5.7 Specifying the lifetime of the URI 352 The URI supplied by in Content-Type header is not required to be 353 accessible or valid for an indefinite period of time. Rather, the 354 supplier of the URI MUST specify the time period for which this URI 355 is valid and accessible. This is done through an "EXPIRATION" 356 parameter of the Content-Type. The format of this expiration 357 parameter is a RFC1123 date-time value. This is further restricted 358 in this application to use only GMT time, consistent with the Date: 359 header in SIP. This is a mandatory parameter. Note that the 360 date-time value can range from minutes to days or even years. 362 For example: 364 Content-Type: message/external-body; 365 expiration="Mon, 24 June 2002 09:00:00 GMT" 367 5.8 Specifying the type of the indirect content 369 To support existing SIP mechanisms for the negotiation of content 370 types, a Content-Type entity header SHOULD be present in the entity 371 (payload) itself. If the protocol (scheme) of the URI supports its 372 own content negotiation mechanisms (e.g. HTTP), this header may be 373 omitted. The sender MUST however be prepared for the receiving party 374 to reject content indirection if the receiver is unable to negotiate 375 an appropriate MIME type using the underlying protocol for the URI 376 scheme. 378 For example: 380 Content-Type: message/external-body; access-type="URL"; 381 expiration="Mon, 24 June 2002 09:00:00 GMT"; 382 URL="http://www.example.com/the-indirect-content" 383 384 Content-Type: application/sdp 385 Content-Disposition: session 386 388 5.9 Specifying the size of the indirect content 390 When known in advance, the size of the indirect content SHOULD be 391 supplied via a size parameter on the Content-Type header. This is an 392 extension of RFC2017 but in line with other access types defined for 393 the message/external-body MIME type in RFC2046. The content size is 394 useful for the receiving party to make a determination about whether 395 or not to retrieve the content. As with directly supplied content, a 396 UAS may return a 513 error response in the event the content size is 397 too large. This is an optional parameter. 399 For example: 401 Content-Type: message/external-body; access-type="URL"; 402 expiration="Mon, 24 June 2002 09:00:00 GMT"; 403 URL="http://www.example.com/the-indirect-content"; 404 size=4123 406 5.10 Specifying the purpose of the indirect content 408 A Content-Disposition entity header MUST be present for all indirect 409 content. 411 For example: 413 Content-Type: message/external-body; access-type="URL"; 414 expiration="Mon, 24 June 2002 09:00:00 GMT"; 415 URL="http://www.example.com/the-indirect-content" 416 417 Content-Type: image/jpeg 418 Content-Disposition: render 420 5.11 Specifying multiple URIs for content indirection 422 If there is a need to send multiple URIs for the purpose of content 423 indirection, an appropriate multipart MIME type [3] should be used. 424 Each URI MUST be contained in a single entity. Indirect content may 425 be mixed with directly supplied content. This is particularly useful 426 with the multipart/alternative MIME type. 428 NOTE: This specification does not change the meanings of the 429 various multipart flavors, particularly multipart/related, as 430 described in RFC2387 [12]. 432 For example: 434 MIME-Version: 1.0 435 Content-Type: multipart/mixed; boundary=boundary42 437 --boundary42 438 Content-Type: text/plain; charset=us-ascii 440 The company announcement for June, 2002 follows: 441 --boundary42 442 Content-Type: message/external-body; 443 access-type="URL"; 444 expiration="Mon, 24 June 2002 09:00:00 GMT"; 445 URL="http://www.example.com/announcements/07242002"; 446 size=4123 448 Content-Type: text/html 449 Content-Disposition: render 451 --boundary42-- 453 5.12 Specifying a hash value for the indirect content 455 If the sender knows the specific content being referenced by the 456 indirection, and the sender wishes the recipient to be able to 457 validate that this content has not been altered from that intended by 458 the sender, the sender includes a SHA-1 [8] hash of the content. If 459 included, the hash is encoded by extending the MIME syntax [3] to 460 include a "hash" parameter for the content type 461 "message/external-body", the value of which is a hexadecimal encoding 462 of the hash. 464 For example: 466 Content-Type: message/external-body; 467 access-type="URL"; 468 expiration="Mon, 24 June 2002 09:00:00 GMT"; 469 URL="http://www.example.com/the-indirect-content.au"; 470 size=52723; 471 hash=10AB568E91245681AC1B 472 473 Content-Disposition: render 475 5.13 Supplying additional comments about the indirect content 477 One MAY use the Content-Description entity header to provide 478 optional, freeform text to comment on the indirect content. This 479 text MAY be displayed to the end user but MUST NOT used by other 480 elements to determine disposition of the body. 482 For example: 484 Content-Type: message/external-body; 485 access-type="URL"; 486 expiration="Mon, 24 June 2002 09:00:00 GMT"; 487 URL="http://www.example.com/the-indirect-content"; 488 size=52723 489 490 Content-Description: Multicast gaming session 491 Content-Disposition: render 493 5.14 Relationship to Call-Info, Error-Info, and Alert-Info Headers 495 SIP [9] defines three headers that supply additional information with 496 regard to a session, a particular error response, or alerting. All 497 three of these headers allow the UAC or UAS to indicate additional 498 information through a URI. They may be considered a form of content 499 indirection. The content indirection mechanism defined in this 500 document is not intended as a replacement for these headers. Rather, 501 the headers defined in SIP MUST be used in preference to this 502 mechanism where applicable because of the well-defined semantics of 503 those headers. 505 6. Examples 506 6.1 Single Content Indirection 508 INVITE sip:boromir@example.com SIP/2.0 509 From: ;tag=347242 510 To: 511 Call-ID: 3573853342923422@example.net 512 CSeq: 2131 INVITE 513 Accept: message/external-body application/sdp 514 Content-Type: message/external-body; 515 ACCESS-TYPE=URL; 516 URL="http://www.example.net/party/06/2002/announcement"; 517 EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; 518 size=231 519 Content-Length: ... 521 Content-Type: application/sdp 522 Content-Disposition: session 523 Content-ID: <4e5562cd1214427d@example.net> 525 6.2 Multipart MIME with Content Indirection 526 MESSAGE sip:boromir@example.com SIP/2.0 527 From: ;tag=34589882 528 To: 529 Call-ID: 9242892442211117@example.net 530 CSeq: 388 MESSAGE 531 Accept: message/external-body, text/html, text/plain, 532 image/*, text/x-emoticon 533 MIME-Version: 1.0 534 Content-Type: multipart/mixed; boundary=zz993453 536 --zz993453 537 Content-Type: message/external-body; 538 access-type="URL"; 539 expiration="Mon, 24 June 2002 09:00:00 GMT"; 540 URL="http://www.example.net/company_picnic/image1.png"; 541 size=234422 543 Content-Type: image/png 544 Content-ID: <9535035333@example.net> 545 Content-Disposition: render 546 Content-Description: Kevin getting dunked in the wading pool 548 --zz993453 549 Content-Type: message/external-body; 550 access-type="URL"; 551 expiration="Mon, 24 June 2002 09:00:00 GMT"; 552 URL="http://www.example.net/company_picnic/image2.png"; 553 size=233811 555 Content-Type: image/png 556 Content-ID: <1134299224244@example.net> 557 Content-Disposition: render 558 Content-Description: Peter on his tricycle 560 --zz993453-- 562 7. Security Considerations 564 Any content indirection mechanism introduces additional security 565 concerns. By its nature, content indirection requires an extra 566 processing step and information transfer. There are a number of 567 potential abuses of a content indirection mechanism: 569 o Content indirection allows the initiator to choose an alternative 570 protocol with weaker security or known vulnerabilities for the 571 content transfer. For example, asking the recipient to issue an 572 HTTP request that results in a Basic authentication challenge. 573 o Content indirection allows the initiator to ask the recipient to 574 consume additional resources in the information transfer and 575 content processing, potentially creating an avenue for denial of 576 service attacks. For example, an active FTP URL consuming 2 577 connections for every indirect content message. 578 o Content indirection could be used as a form of port scanning 579 attack where the indirect content URL is actually a bogus URL 580 pointing to an internal resource of the recipient. The response 581 to the content indirection request could reveal information about 582 open (and vulnerable) ports on these internal resources. 583 o A content indirection URL can disclose sensitive information about 584 the initiator such as an internal user name (as part of an HTTP 585 URL) or possibly geolocation information. 587 Fortunately, all of these potential threats can be mitigated through 588 careful screening of both the indirect content URIs that are received 589 as well as those that are sent. Integrity and confidentiality 590 protection of the indirect content URI can prevent additional attacks 591 as well. 593 For confidentiality, integrity, and authentication, this content 594 indirection mechanism relies on the security mechanisms outlined in 595 RFC3261. In particular, the usage of S/MIME as defined in section 23 596 of RFC3261 provides the necessary mechanism to ensure integrity, 597 protection, and confidentiality of the indirect content URI and 598 associated parameters. 600 Securing the transfer of the indirect content is the responsibility 601 of the underlying protocol used for this transfer. If HTTP is used, 602 applications implementing this content indirection method SHOULD 603 support the HTTPS URI scheme for secure transfer of content and MUST 604 support the upgrading of connections to TLS using starttls. Note 605 that a failure to complete HTTPS or starttls (for example, due to 606 cert or encryption mismatch) after having accepted the indirect 607 content in the SIP request is not the same as rejecting the SIP 608 request, and may require additional user-user communication for 609 correction. 611 Note that this document does not advocate the use of transitive 612 trust. That is, just because the UAS receives a URI from a UAC that 613 the UAS trusts, the UAS SHOULD NOT implicitly trust the object 614 referred to by the URI without establishing its own trust 615 relationship with the URI provider. 617 Access control to the content referenced by the URI is not defined by 618 this specification. Access control mechanisms may be defined by the 619 protocol for the scheme of the indirect content URI. 621 If the UAC knows the content in advance, the UAC SHOULD include a 622 hash parameter in the content indirection. The hash parameter is a 623 hexadecimal-encoded SHA-1 [8] hash of the indirect content. If a 624 hash value is included, the recipient MUST check the indirect content 625 against that hash and indicate any mismatch to the user. 627 In addition, if the hash parameter is included, and the target URI 628 involves setting up a security context using certificates, the UAS 629 MUST ignore the results of the certificate validation procedure, and 630 instead verify that the hash of the (canonicalized) content received 631 matches the hash presented in the content-indirection hash parameter. 633 If the hash parameter is NOT included, the sender SHOULD use only 634 schemes that offer message integrity (such as https:). When the hash 635 parameter is not included and security using certificates is used, 636 the UAS MUST verify any server certificates using the UAS's list of 637 trusted top-level certificate authorities. 639 If hashing of indirect content is not used, the possibility exists 640 that the content returned to the recipient by exercise of the 641 indirection has been altered from that intended by the sender. 643 8. IANA Considerations 645 This document raises no new IANA considerations. 647 9. Contributions 649 Sean Olson, seanol@microsoft.com, provided the vast majority of the 650 content of this document, including editorship through the first IESG 651 review. 653 Dean Willis touched it next. 655 Eric Burger edited the document and addressed IESG comments, 656 including the access protocol negotiation mechanism. 658 10. Acknowledgements 660 Cullen Jennings and Nancy Greene provided a through review and 661 valuable comments and suggestions. 663 11. References 664 11.1 Normative References 666 [1] Freed, N. and K. Moore, "Definition of the URL MIME 667 External-Body Access-Type", RFC 2017, October 1996. 669 [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 670 Extensions (MIME) Part One: Format of Internet Message Bodies", 671 RFC 2045, November 1996. 673 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 674 Extensions (MIME) Part Two: Media Types", RFC 2046, November 675 1996. 677 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. 678 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 679 2068, January 1997. 681 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 682 Levels", BCP 14, RFC 2119, March 1997. 684 [6] Daniel, R., "A Trivial Convention for using HTTP in URN 685 Resolution", RFC 2169, June 1997. 687 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 688 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 689 1998. 691 [8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 692 RFC 3174, September 2001. 694 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 695 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 696 Session Initiation Protocol", RFC 3261, June 2002. 698 [10] Burger, E., "Critical Content Multi-purpose Internet Mail 699 Extensions (MIME) Parameter", RFC 3459, January 2003. 701 [11] Rosenberg, J., "A Framework for Application Interaction in the 702 Session Initiation Protocol (SIP)", 703 draft-ietf-sipping-app-interaction-framework-02 (work in 704 progress), July 2004. 706 11.2 Informative References 708 [12] Levinson, E., "The MIME Multipart/Related Content-type", RFC 709 2387, August 1998. 711 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 712 Resource Identifier (URI): Generic Syntax", 713 draft-fielding-uri-rfc2396bis-06 (work in progress), July 2004. 715 Author's Address 717 Eric Burger (editor) 718 Brooktrout Technology, Inc. 720 EMail: eburger@brooktrout.com 721 URI: http://www.brooktrout.com 723 Intellectual Property Statement 725 The IETF takes no position regarding the validity or scope of any 726 Intellectual Property Rights or other rights that might be claimed to 727 pertain to the implementation or use of the technology described in 728 this document or the extent to which any license under such rights 729 might or might not be available; nor does it represent that it has 730 made any independent effort to identify any such rights. Information 731 on the procedures with respect to rights in RFC documents can be 732 found in BCP 78 and BCP 79. 734 Copies of IPR disclosures made to the IETF Secretariat and any 735 assurances of licenses to be made available, or the result of an 736 attempt made to obtain a general license or permission for the use of 737 such proprietary rights by implementers or users of this 738 specification can be obtained from the IETF on-line IPR repository at 739 http://www.ietf.org/ipr. 741 The IETF invites any interested party to bring to its attention any 742 copyrights, patents or patent applications, or other proprietary 743 rights that may cover technology that may be required to implement 744 this standard. Please address the information to the IETF at 745 ietf-ipr@ietf.org. 747 Disclaimer of Validity 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 752 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 753 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 754 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Copyright Statement 759 Copyright (C) The Internet Society (2004). This document is subject 760 to the rights, licenses and restrictions contained in BCP 78, and 761 except as set forth therein, the authors retain all their rights. 763 Acknowledgment 765 Funding for the RFC Editor function is currently provided by the 766 Internet Society.