idnits 2.17.1 draft-ietf-sip-content-indirect-mech-04.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 698. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 714), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 134 has weird spacing: '... to the me...' == Line 149 has weird spacing: '...most of these...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (July 16, 2004) is 7223 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) == Missing Reference: '10' is mentioned on line 663, but not defined == Unused Reference: '4' is defined on line 641, but no explicit reference was found in the text ** 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') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Session Initiation Protocol D. Willis, Ed. 2 Internet-Draft dynamicsoft Inc. 3 Expires: January 14, 2005 July 16, 2004 5 A Mechanism for Content Indirection in Session Initiation Protocol 6 (SIP) Messages 7 draft-ietf-sip-content-indirect-mech-04 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document proposes an extension to the URL MIME External- Body 41 Access-Type to satisfy the content indirection requirements for SIP. 42 These extensions are aimed at allowing any MIME part in a SIP message 43 to be referred to indirectly via a URI. 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 4 50 3.1 Presence Notification . . . . . . . . . . . . . . . . . . 4 51 3.2 Document Sharing . . . . . . . . . . . . . . . . . . . . . 5 52 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Application of RFC2017 to the Content Indirection Problem . 7 54 5.1 Specifying support for content indirection . . . . . . . . 7 55 5.2 Mandatory support for HTTP URI . . . . . . . . . . . . . . 7 56 5.3 Rejecting content indirection . . . . . . . . . . . . . . 7 57 5.4 Specifying the location of the content via a URI . . . . . 8 58 5.5 Specifying versioning information for the URI . . . . . . 8 59 5.6 Specifying the lifetime of the URI . . . . . . . . . . . . 8 60 5.7 Specifying the type of the indirect content . . . . . . . 9 61 5.8 Specifying the size of the indirect content . . . . . . . 9 62 5.9 Specifying the purpose of the indirect content . . . . . . 10 63 5.10 Specifying multiple URIs for content indirection . . . . 10 64 5.11 Specifying a hash value for the indirect content . . . . 11 65 5.12 Supplying additional comments about the indirect 66 content . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.13 Relationship to Call-Info, Error-Info, and Alert-Info 68 Headers . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1 Single Content Indirection . . . . . . . . . . . . . . . . 13 71 6.2 Multipart MIME with Content Indirection . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 74 9. Contributions . . . . . . . . . . . . . . . . . . . . . . . 16 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 77 10.2 References References . . . . . . . . . . . . . . . . . . 17 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . 18 81 1. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [5] 87 2. Introduction 89 The purpose of the Session Initiation Protocol [9] (SIP) is to 90 create, modify, or terminate sessions with one or more participants. 91 SIP messages, like HTTP, are sytnactically composed of a start line, 92 one or more headers, and an optional body. Unlike HTTP, SIP is not 93 designed as a general purpose transport of data. 95 There are numerous reasons why it might be desirable to indirectly 96 specify the content of the SIP message body. For bandwidth limited 97 applications such as cellular wireless, indirection provides a means 98 to annotate the (indirect) content with meta-data which may be used 99 by the recipient to determine whether or not to retrieve the content 100 over the resource limited link. 102 It is also possible that the content size to be transferred might 103 potentially overwhelm intermediate signaling proxies, thereby 104 unnecessarily increasing network latency. For time-sensitive SIP 105 applications, this may be unacceptable. Indirect content can remedy 106 this by moving the transfer of this content out of the SIP signaling 107 network and into a potentially separate data transfer channel. 109 There may also be scenarios where the session related data (body) 110 that needs to be conveyed does not directly reside on the endpoint or 111 User Agent. In such scenarios, it is desirable to have a mechanism 112 whereby the SIP message can contain an indirect reference to the 113 desired content. The receiving party would then use this indirect 114 reference to retrieve the content via a non-SIP transfer channel such 115 as HTTP, FTP, or LDAP. 117 The purpose of content indirection is purely to provide an 118 alternative transport mechanism for SIP MIME body parts. With the 119 exception of the transport mechanism, indirected body parts are 120 equivalent, and should have the same treatment, as in-line body 121 parts. 123 Previous attempts at solving the content indirection problem made use 124 of the text/uri-list [6] MIME type. While attractive for its 125 simplicity (a list of URIs delimted by end-of-line markers), it fails 126 to satisfy a number of the requirements for a more general purpose 127 content indirection mechanism in SIP. Most notably lacking is the 128 ability to specify various attributes on a per-URI basis. These 129 attributes might include version information, the MIME type of the 130 referenced content, etc. 132 In searching for a replacement for the text/uri-list MIME type, 133 RFC2017 defines a strong candidate. RFC2017 [1] defines an extension 134 to the message/external-body MIME type originally defined in 135 RFC2046 [3]. The extension that RFC2017 makes is to allow a generic 136 URI to specify the location of the content rather than protocol 137 specific parameters for FTP, etc. as originally defined in RFC2046. 138 While providing most of the functionality needed for a SIP content 139 indirection mechanism, RFC2017 by itself is not a complete solution. 140 This document will specify the usage of RFC2017 necessary to fulfill 141 the requirments outlined for content indirection. 143 The requirements can be classified as applying either to the URI 144 which indirectly references the desired content or to the content 145 itself. Where possible, existing MIME parameters and entity headers 146 are used to satisfy those requirements. MIME (Content-Type) 147 parameters are the preferred manner of describing the URI while 148 entity headers are the preferred manner of describing the (indirect) 149 content. See RFC 2045 [2] for a description of most of these entity 150 headers and MIME parameters. 152 3. Example Use Cases 154 There are several example users of such a content indirection 155 mechanism. These are examples only and are not intended to limit the 156 scope or applicability of the mechanism. 158 3.1 Presence Notification 160 The information carried in a presence document could potentially 161 exceed the recommended size for a SIP (NOTIFY) request, particularly 162 if the document carries aggregated information from multiple 163 endpoints. In such a situation, it would be desirable to send the 164 NOTIFY request with an indirect pointer to the presence document 165 which could then be retrieved by, for example, HTTP. 167 Watcher Presence Server 168 | | 169 | SUBSCRIBE | 170 |-------------------------->| 171 | 200 OK | 172 |<--------------------------| 173 | | 174 | NOTIFY | 175 |-------------------------->| 176 | 200 OK | 177 |<--------------------------| 178 | | 179 | NOTIFY (w/URI) | 180 |<--------------------------| 181 | 200 | 182 |-------------------------->| 183 | | 184 | HTTP GET | 185 |-------------------------->| 186 | | 187 | application/cpim-pidf+xml | 188 |<--------------------------| 189 | | 191 In this example, the presence server returns an HTTP URI pointing to 192 a presence document on the presence server which the watcher can then 193 fetch using an HTTP GET. 195 3.2 Document Sharing 197 During an instant messaging conversation, a useful service is 198 document sharing wherein one party sends an IM (MESSAGE request) with 199 an indirect pointer to a document which is meant to be rendered by 200 the remote party. Carrying such a document directly in the MESSAGE 201 request is not appropriate for most documents. Furthermore, the 202 document to be shared may reside on a completely independent server 203 from the originating party. 205 UAC UAS Web Server 206 | | | 207 | MESSAGE w/URI | | 208 |------------------->| | 209 | 200 | | 210 |<-------------------| | 211 | | | 212 | | HTTP GET | 213 | |--------------->| 214 | | image/jpeg | 215 | |<---------------| 216 | | | 218 In this example, a user wishes to exchange a JPEG image that she has 219 stored on her web server with another user she has a IM conversation 220 with. The JPEG is intended to be rendered inline in the IM 221 conversation. The recepient of the MESSAGE request launches a HTTP 222 GET request to the web server to retrieve the JPEG image. 224 4. Requirements 226 o It MUST be possible to specify the location of content via a URI. 227 Such URIS MUST be conformnt with RFC2396 [7] or its successors, 228 such as [10]. 229 o It MUST be possible to specify the length of the indirect content. 230 o It MUST be possible to specify the type of the indirect content. 231 o It MUST be possible to specify the disposition of each URI 232 independently. 233 o It MUST be possible to label each URI to identify if and when the 234 content referred to by that URI has changed. Applications of this 235 mechanism may send the same URI more than once. The intention of 236 this requirement is to allow the receiving party to determine if 237 the content referenced by the URI has changed without having to 238 actually retrieve that content. Example ways the URI could be 239 labelled include a sequence number, timestamp, version number, 240 etc. When used with HTTP, an entity-tag (ETAG) mechanism as 241 defined in RFC2068 [4]" may be appropriate. Note that we are not 242 labeling the URI itself, but the content to which the URI refers, 243 and that the label is therefore effectively "metadata" of the 244 content itself. 245 o It MUST be possible to specify the timespan for which a given URI 246 is valid. This may or may not be the same as the lifetime for the 247 content itself. 248 o It MUST be possible for the UAC and the UAS to indicate support of 249 this content indirection mechanism. A fallback mechanism SHOULD 250 be specified in the event that one of the parties is unable to 251 support content indirection. 253 o It MUST be possible for the UAC and UAS to negotiate the type of 254 the indirect content when using the content indirection mechanism. 255 o It MUST be possible for the UAC and UAS to negotiate support for 256 URI scheme(s) to be used in the content indirection mechanism. 257 This is in addition to the ability to negotiate the content type. 258 o It SHOULD be possible to ensure the integrity and privacy of the 259 URI when it is received by the remote party. 260 o It MUST be possible to process the content indirection without 261 human intervention. 262 o It MUST allow for indirect transference of content in any SIP 263 message which would otherwise carry that content as a body. 265 5. Application of RFC2017 to the Content Indirection Problem 267 The following text describes the application of RFC2017 to the 268 requirements for content indirection. 270 5.1 Specifying support for content indirection 272 A UAC/UAS may indicate support for content indirection through an 273 Accept header containing the message/external-body MIME type. The 274 UAC/UAS must supply additional values in the Accept header to 275 indicate the content types that it is willing to accept either 276 directly or through content indirection. User-Agents supporting 277 content indirection MUST support content indirection of the 278 application/sdp MIME type. 280 For example: 282 Accept: message/external-body, image/*, application/sdp 284 5.2 Mandatory support for HTTP URI 286 Applications which use this content indirection mechanism MUST 287 support at least the HTTP URI scheme. Additional URI schemes MAY be 288 used, but a UAC/UAS MUST support receiving a HTTP URI for indirect 289 content if it advertises support for content indirection. 291 The intention is to establish a baseline of support to further 292 strengthen interoperability. Implementors may design for the most 293 common case (HTTP) without having to worry about negotiation of 294 support for this particular URI scheme. 296 5.3 Rejecting content indirection 298 If a UAS receives a SIP request which contains a content indirection 299 payload, and the UAS cannot or does not wish to support such a 300 content type, it MUST reject the request with a 415 Unsupported Media 301 Type response as defined in section 21.4.13 of SIP [9]. In 302 particular, the UAC should note the absence of the message/ 303 external-body MIME type in the Accept header of this response to 304 indicate that the UAS does not support content indirection. 306 5.4 Specifying the location of the content via a URI 308 The URI for the indirect content is specified in a "URI" parameter of 309 the message/external-body MIME type. An access-type parameter 310 indicates that the external content is referenced by a URI. 312 For example: 314 Content-Type: message/external-body; 315 access-type="URL"; 316 URL="http://www.example.com/the-indirect-content" 318 5.5 Specifying versioning information for the URI 320 In order to determine whether or not the content indirectly 321 referenced by the URI has changed, a Content-ID entity header is 322 used. The syntax of this header is defined in RFC2045 [2]. Changes 323 in the underlying content referred to by a URI MUST result in a 324 change in the Content-ID associated with that URI. Multiple SIP 325 messages carrying URI that refer to the same content SHOULD reuse the 326 same Content-ID to allow the receiver to cache this content and avoid 327 unnecessary retrievals. The Content-ID is intended to be globally 328 unique and SHOULD be temporally unique across SIP dialogs. 330 For example: 332 Content-ID: <4232423424@www.example.com> 334 5.6 Specifying the lifetime of the URI 336 The URI supplied by in Content-Type header is not required to be 337 accessible or valid for an indefinite period of time. Rather, the 338 supplier of the URI MUST specify the time period for which this URI 339 is valid and accessible. This is done through an "EXPIRATION" 340 parameter of the Content-Type. The format of this expiration 341 parameter is a RFC1123 date-time value. This is further restricted 342 in this application to use only GMT time, consistent with the Date: 344 header in SIP. This is a mandatory parameter. Note that the 345 date-time value can range from minutes to days or even years. 347 For example: 349 Content-Type: message/external-body; 350 expiration="Mon, 24 June 2002 09:00:00 GMT" 352 5.7 Specifying the type of the indirect content 354 To support existing SIP mechanisms for the negotiation of content 355 types, a Content-Type entity header SHOULD be present in the entity 356 (payload) itself. If the protocol (scheme) of the URI supports its 357 own content negotiation mechanisms (e.g. HTTP), this header may be 358 omitted. The sender MUST however be prepared for the receiving party 359 to reject content indirection if the receiver is unable to negotiate 360 an appropriate MIME type using the underlying protocol for the URI 361 scheme. 363 For example: 365 Content-Type: message/external-body; access-type="URL"; 366 expiration="Mon, 24 June 2002 09:00:00 GMT"; 367 URL="http://www.example.com/the-indirect-content" 368 369 Content-Type: application/sdp 370 372 5.8 Specifying the size of the indirect content 374 When known in advance, the size of the indirect content should be 375 supplied via a size parameter on the Content-Type header. This is an 376 extension of RFC2017 but in line with other access types defined for 377 the message/external-body MIME type in RFC2046. The content size is 378 useful for the receiving party to make a determination about whether 379 or not to retrieve the content. As with directly supplied content, a 380 UAS may return a 513 error response in the event the content size is 381 too large. This is an optional parameter. 383 For example: 385 Content-Type: message/external-body; access-type="URL"; 386 expiration="Mon, 24 June 2002 09:00:00 GMT"; 387 URL="http://www.example.com/the-indirect-content"; 388 size=4123 390 5.9 Specifying the purpose of the indirect content 392 A Content-Disposition entity header SHOULD be present for all 393 indirect content. In the absence of an an explicit 394 Content-Disposition header, a content disposition of "session" should 395 be assumed. 397 For example: 399 Content-Type: message/external-body; access-type="URL"; 400 expiration="Mon, 24 June 2002 09:00:00 GMT"; 401 URL="http://www.example.com/the-indirect-content" 402 403 Content-Type: image/jpeg 404 Content-Disposition: render 406 5.10 Specifying multiple URIs for content indirection 408 If there is a need to send multiple URIs for the purpose of content 409 indirection, an appropriate multipart MIME type [3] should be used. 410 Each URI should be contained in a single entity. Indirect content 411 may be mixed with directly supplied content. This is particularly 412 useful with the multipart/alternative MIME type. 414 For example: 416 MIME-Version: 1.0 417 Content-Type: multipart/mixed; boundary=boundary42 419 --boundary42 420 Content-Type: text/plain; charset=us-ascii 422 The company announcement for June, 2002 follows: 423 --boundary42 424 Content-Type: message/external-body; 425 access-type="URL"; 426 expiration="Mon, 24 June 2002 09:00:00 GMT"; 427 URL="http://www.example.com/announcements/07242002"; 428 size=4123 430 Content-Type: text/html 431 Content-Disposition: render 433 --boundary42-- 435 5.11 Specifying a hash value for the indirect content 437 If the specific content being referenced by the indirection is known 438 to the sender, and the sender wishes the recipient to be able to 439 validate that this content has not been altered from that intended by 440 the sender, the sender includes a SHA-1 [8] hash of the content. If 441 included, the hash is encoded by extending the MIME syntax [3] to 442 include a "hash" parameter for the content type "message/ 443 external-body", the value of which is a base-64 enoding of the hash. 445 For example: 447 Content-Type: message/external-body; 448 access-type="URL"; 449 expiration="Mon, 24 June 2002 09:00:00 GMT"; 450 URL="http://www.example.com/the-indirect-content.au"; 451 size=52723 452 hash=10AB568E91245681AC1B 453 455 5.12 Supplying additional comments about the indirect content 457 Optional, freeform text may be supplied to comment on the indirect 458 content. This should be supplied in a Content-Description entity 459 header. This text may be displayed to the end user but MUST NOT used 460 by other elements to determine disposition of the body, as such as 461 usage would result in unreviewed extension to the COntent-type and 462 Content-disposition header field functions. 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"; 470 size=52723 471 472 Content-Description: Multicast gaming session 474 5.13 Relationship to Call-Info, Error-Info, and Alert-Info Headers 476 SIP [9] defines three headers which are used to supply additional 477 information with regard to a session, a particular error response, or 478 alerting. All three of these headers allow the UAC or UAS to 479 indicate additional information through a URI. They may be 480 considered a form of content indirection. The content indirection 481 mechanism defined in this document is not intended as a replacement 482 for these headers. Rather, the headers defined in SIP MUST be used 483 in preference to this mechanism where applicable because of the well 484 defined semantics of those headers. 486 6. Examples 487 6.1 Single Content Indirection 489 INVITE sip:boromir@example.com SIP/2.0 490 From: ;tag=347242 491 To: 492 Call-ID: 3573853342923422@nwt.com 493 CSeq: 2131 INVITE 494 Accept: message/external-body application/sdp 495 Content-Type: message/external-body; 496 ACCESS-TYPE=URL; 497 URL="http://www.nwt.com/party/06/2002/announcement"; 498 EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT" 499 size=231 500 Content-Length: ... 502 Content-Type: application/sdp 503 Content-Disposition: session 504 Content-ID: <4e5562cd1214427d@nwt.com> 506 6.2 Multipart MIME with Content Indirection 507 MESSAGE sip:boromir@example.com SIP/2.0 508 From: ;tag=34589882 509 To: 510 Call-ID: 9242892442211117@nwt.com 511 CSeq: 388 MESSAGE 512 Accept: message/external-body, text/html, text/plain, 513 image/*, text/x-emoticon 514 MIME-Version: 1.0 515 Content-Type: multipart/mixed; boundary=zz993453 517 --zz993453 518 Content-Type: message/external-body; 519 access-type="URL"; 520 expiration="Mon, 24 June 2002 09:00:00 GMT"; 521 URL="http://www.nwt.com/company_picnic/image1.png" 522 size=234422 524 Content-Type: image/png 525 Content-ID: <9535035333@nwt.com> 526 Content-Disposition: render 527 Content-Description: Kevin getting dunked in the wading pool 529 --zz993453 530 Content-Type: message/external-body; 531 access-type="URL"; 532 expiration="Mon, 24 June 2002 09:00:00 GMT"; 533 URL="http://www.nwt.com/company_picnic/image2.png" 534 size=233811 536 Content-Type: image/png 537 Content-ID: <1134299224244@nwt.com> 538 Content-Disposition: render 539 Content-Description: Peter on his tricycle 541 --zz993453-- 543 7. Security Considerations 545 Any content indirection mechanism introduces additional security 546 concerns. By its nature, content indirection requires an extra 547 processing step and information transfer. There are a number of 548 potential abuses of a content indirection mechanism: 549 o Content indirection allows the initiator to choose an alternative 550 protocol with weaker security or known vulnerabilities for the 551 content transfer. For example, asking the recipient to issue an 552 HTTP request which results in a Basic authentication challenge. 553 o Content indirection allows the initiator to ask the recipient to 554 consume additional resources in the information transfer and 555 content processing, potentially creating an avenue for denial of 556 service attacks. For example, an active FTP URL consuming 2 557 connections for every indirect content message. 558 o Content indirection could be used as a form of port scanning 559 attack where the indirect content URL is actually a bogus URL 560 pointing to an internal resource of the recipient. The response 561 to the content indirection request could reveal information about 562 open (and vulnerable) ports on these internal resources. 563 o A content indirection URL can disclose sensitive information about 564 the initiator such as an internal user name (as part of an HTTP 565 URL) or possibly geolocation information. 567 Fortunately, all of these potential threats can be mitigated through 568 careful screening of both the indirect content URIs that are received 569 as well as those that are sent. Integrity and privacy protection of 570 the indirect content URI can prevent additional attacks as well. 572 For confidentiality, integrity, and authentication, this content 573 indirection mechanism relies on the security mechanisms outlined in 574 RFC3261. In particular, the usage of S/MIME as defined in section 23 575 of RFC3261 provides the necessary mechanism to ensure integrity 576 protection and privacy of the indirect content URI and associated 577 parameters. 579 Securing the transfer of the indirect content is the responsibility 580 of the underlying protocol used for this transfer. If HTTP is used, 581 applications implementing this content indirection method MUST 582 support the HTTPS URI scheme for secure transfer of content and must 583 support the upgrading of connections to TLS using starttls. Note 584 that a failure to complete HTTPS or starttls (for example, due to 585 cert or encryption mismatch) after having accepted the indirect 586 content in the SIP request is not the same as rejecting the SIP 587 request, and may require additional user-user communication for 588 correction. 590 Access control to the content referenced by the URI is not defined by 591 this specification. Access control mechanisms may be defined by the 592 protocol for the scheme of the indirect content URI. 594 If the UAC knows the content in advance, the UAC SHOULD include a 595 hash parameter in the content indirection. The hash parameter is a 596 base64-encoded SHA-1 hash of the indirected content. [8] If a hash 597 value is included, the recipient MUST check the indirect content 598 against that hash and indicate any mismatch to the user. 600 In addition, if the hash parameter is included, and the target URI 601 involves setting up a security context using certificates, the UAS 602 MUST ignore the results of the certificate validation procedure, and 603 instead verify that the hash of the (canonicalized) content received 604 matches the hash presented in the content-indirection hash parameter. 606 If the hash parameter is NOT included, the sender SHOULD use only 607 schemes which offer message integrity (such as https:). When the 608 hash parameter is not included and security using certificates is 609 used, the UAS MUST verify any server certificates using the UAS's 610 list of trusted top-level certificate authorities. 612 If hashing of indirected content is not used, the possibility exists 613 that the content returned to the recipient by exercise of the 614 indirection has been altered from that intended by the sender. 616 8. IANA Considerations 618 This document raises no new IANA considerations. 620 9. Contributions 622 It should be noted that the vast majority of this document, including 623 editorship through the first IESG review, was provided by Sean Olson, 624 seanol@microsoft.com 626 10. References 628 10.1 Normative References 630 [1] Freed, N. and K. Moore, "Definition of the URL MIME 631 External-Body Access-Type", RFC 2017, October 1996. 633 [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 634 Extensions (MIME) Part One: Format of Internet Message Bodies", 635 RFC 2045, November 1996. 637 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 638 Extensions (MIME) Part Two: Media Types", RFC 2046, November 639 1996. 641 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. 642 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 643 2068, January 1997. 645 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 646 Levels", BCP 14, RFC 2119, March 1997. 648 [6] Daniel, R., "A Trivial Convention for using HTTP in URN 649 Resolution", RFC 2169, June 1997. 651 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 652 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 654 [8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 655 RFC 3174, September 2001. 657 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 658 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 659 Session Initiation Protocol", RFC 3261, June 2002. 661 10.2 References References 663 [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 664 Resource Identifier (URI): Generic Syntax", 665 draft-fielding-uri-rfc2396bis-05 (work in progress), April 666 2004. 668 Author's Address 670 Dean Willis (editor) 671 dynamicsoft Inc. 673 EMail: dean.willis@softarmor.com 674 URI: http://www.softarmor.com 676 Intellectual Property Statement 678 The IETF takes no position regarding the validity or scope of any 679 Intellectual Property Rights or other rights that might be claimed to 680 pertain to the implementation or use of the technology described in 681 this document or the extent to which any license under such rights 682 might or might not be available; nor does it represent that it has 683 made any independent effort to identify any such rights. Information 684 on the procedures with respect to rights in RFC documents can be 685 found in BCP 78 and BCP 79. 687 Copies of IPR disclosures made to the IETF Secretariat and any 688 assurances of licenses to be made available, or the result of an 689 attempt made to obtain a general license or permission for the use of 690 such proprietary rights by implementers or users of this 691 specification can be obtained from the IETF on-line IPR repository at 692 http://www.ietf.org/ipr. 694 The IETF invites any interested party to bring to its attention any 695 copyrights, patents or patent applications, or other proprietary 696 rights that may cover technology that may be required to implement 697 this standard. Please address the information to the IETF at 698 ietf-ipr@ietf.org. 700 Disclaimer of Validity 702 This document and the information contained herein are provided on an 703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 705 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 706 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 707 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 710 Copyright Statement 712 Copyright (C) The Internet Society (2004). This document is subject 713 to the rights, licenses and restrictions contained in BCP 78, and 714 except as set forth therein, the authors retain all their rights. 716 Acknowledgment 718 Funding for the RFC Editor function is currently provided by the 719 Internet Society.