idnits 2.17.1 draft-mahy-sipping-body-add-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 676), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 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 (Jul 2004) is 7218 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) ** Obsolete normative reference: RFC 2633 (ref. '3') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3489 (ref. '8') (Obsoleted by RFC 5389) == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-01 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-e2m-sec-reqs (ref. '10') == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-02 == Outdated reference: A later version (-06) exists of draft-ietf-sip-history-info-02 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-03 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-04) exists of draft-ono-sipping-end2middle-security-02 -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-04) exists of draft-jennings-sipping-certs-03 -- Possible downref: Normative reference to a draft: ref. '17' -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '18') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '21') (Obsoleted by RFC 5727) == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-06 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-01 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-03 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING WG R. Mahy 2 Internet-Draft Cisco Systems, Inc. 3 Expires: December 30, 2004 Jul 2004 5 Pros and Cons of allowing SIP Intermediaries to add MIME bodies 6 draft-mahy-sipping-body-add-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 30, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The SIPPING Working Group has developed requirements for session 40 policy (including bandwidth and codec restrictions, logging, and 41 middlebox traversal), request history, and identity. This document 42 discusses the pros and cons of allowing intermediaries to add SIP 43 message bodies to address these requirements. It is intended to 44 provoke serious discussion rather than as a complete proposal. 46 Table of Contents 48 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Overview of the body addition proposal . . . . . . . . . . . . 6 52 5. Applications with and without body modification . . . . . . . 9 53 5.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 5.2 Session codec / bandwidth policy checking . . . . . . . . 10 55 5.3 Midcom-style firewall traversal . . . . . . . . . . . . . 10 56 5.4 NAT traversal (including v4/v6 translators) . . . . . . . 10 57 5.5 3rd-party Asserted Identity . . . . . . . . . . . . . . . 10 58 5.6 Request History . . . . . . . . . . . . . . . . . . . . . 11 59 5.7 3rd Party Authentication Service . . . . . . . . . . . . . 11 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 65 9.2 Informational References . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . 15 69 1. Conventions 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [2]. 75 2. Introduction 77 Certain classes of applications the SIP and SIPPING WGs are 78 considering ([9], [10], [11], [12]), lend themselves casually to an 79 approach where intermediaries can inspect, add, or modify bodies. 80 Unfortunately, this practice as currently implemented is completely 81 incompatible with the S/MIME [3] end-to-end security mechanisms 82 specified in the core SIP specification (RFC 3261 [1]), and 83 consequently an explicit violation of the spec. The SIP community is 84 at an impasse regarding how these classes of feature need to be 85 implemented. This document attempts to present an overview of the 86 two major proposals for moving forward. 88 One proposal suggests that body additions (as opposed to 89 modifications) can be done safely by SIP intermediaries if these 90 bodies are optional in nature and if certain restrictions are placed 91 on which intermediaries are allowed to add bodies and under what 92 circumstances. This proposal would require a relaxation of one 93 sentence in the SIP specification and would effectively enable a 94 generic mechanism which could be used for a variety of applications. 95 This mechanism would not interfere with user agents which do 96 end-to-end security directly. Intermediaries which could add bodies 97 could sign or encrypt these as the product of a specific 98 intermediary. The receiving user agent would be responsible for 99 verifying the validity and trustworthiness of each body part. 101 Another proposal suggests that allowing intermediaries to add bodies 102 introduces unneeded complexity and a handful of other undesirable 103 properties. These undesirable properties could be avoided by 104 addressing each of the requirements individually while carefully 105 limiting the scope of some of these applications. In addition, this 106 proposal accommodates a model where a new intermediary role called an 107 Authentication Service which has a direct TLS [4] connection and a 108 specific trust relationship with one of the user agents could make 109 change to bodies on behalf of that user agent if also performing 110 end-to-end security operations on its behalf. 112 In addition to supporting the required applications in the presence 113 of true end-to-end security, it is highly desirable to support a 114 mechanism that allows specific intermediaries to safely sign and 115 verify and possibly encrypt and decrypt requests and responses on 116 behalf of user agents which have not implemented S/MIME. This allows 117 for a migration path from existing implementations to a completely 118 end-to-end environment in a safe manner. 120 3. Topologies 122 An explicit policy fetch allows user agents to fetch a policy 123 document directly from their intermediaries, for example using the 124 approach described in [14] and [13]. This significantly reduces, but 125 does not completely eliminate the need for policy "corrections" by 126 specific intermediaries for specific sessions. The remainder of this 127 section assumes that available policy information available in the 128 local domain has already been exhausted. Note that through 129 configuration or prior negotiation, Alice and atlanta.com probably 130 have few policy conflicts, and Bob and biloxi.com probably have few 131 policy conflicts. The bulk of policy conflicts are likely to be 132 between Alice or atlanta.com and Bob or biloxi.com. 134 This section explores the possible paths that a request can take from 135 sip:alice@phone2.atlanta.com to sip:bob@pc1.biloxi.com and the policy 136 implications. 138 Full Redirect Model: This topology results in Alice sending a request 139 to sip:bob@biloxi.com, which redirects her request to 140 bob@pc1.biloxi.com. Alice opens a new connection directly to 141 pc1.biloxi.com and sends her request directly with no intermediate 142 proxies . There is no opportunity for either atlanta.com or 143 biloxi.com to enforce session policy here at all, since neither is 144 involved in further signaling. 146 INVITE sip:bob@biloxi.com SIP/2.0 148 [biloxi.com redirects] 149 SIP/2.0 302 Moved 150 Contact: 152 [Alice retries request to new target URI] 153 INVITE sip:bob@pc1.biloxi.com SIP/2.0 155 Triangle Signaling Model: Alice opens a connection to biloxi.com 156 which routes Alice's request to bob@pc1.biloxi.com. This offers an 157 opportunity for biloxi.com to issue a repairable error response which 158 Alice could fix and retry. This is the most elegant toplogy because 159 it has the simplest security characteristics. Unfortunately this 160 model does not allow atlanta.com to influence requests from Alice. 161 Many organizations require policy influence over requests which 162 originate within their networks. 164 INVITE sip:bob@biloxi.com SIP/2.0 166 [biloxi.com retargets] 167 INVITE sip:bob@pc1.biloxi.com SIP/2.0 169 Trapezoid Signaling Model: Alice routes its request to bob@biloxi.com 170 through atlanta.com. Then biloxi.com retargets the requests and 171 forwards it to bob@pc1.biloxi.com. This model allows both 172 atlanta.com and biloxi.com to influence policy on new sessions. 173 There are still variations of how atlanta.com and biloxi.com can 174 influence the session. 176 INVITE sip:bob@biloxi.com SIP/2.0 177 Route: sip:atlanta.com;lr 179 [atlanta.com forwards the request to biloxi.com] 180 INVITE sip:bob@biloxi.com SIP/2.0 182 [biloxi.com retargets] 183 INVITE sip:bob@pc1.biloxi.com SIP/2.0 185 One way to allow proxies to influence policy in the trapezoid model 186 causes an extra round trip to allow Alice to "consent" to each 187 proposed policy change. For example, atlanta.com could issue a 188 repairable error response to influence a new request, and then 189 biloxi.com could likewise issue a repairable error response to add 190 its policy requirements. This model results in many messages and can 191 result in significant additional delay due to extra round trips. In 192 addition, information which is potentially private between biloxi.com 193 and Bob is sent to Alice. Also, Alice may be asked to forward opaque 194 or encrypted data from an intermediary with whom Alice has no trust 195 relationship. It hard to imagine how Alice could decide on what 196 basis to "consent" to include such content. 198 Alice -> atlanta.com 200 [atlanta.com asks Alice to comply with specific policy] 201 Alice -> atlanta.com -> biloxi.com 203 [biloxi.com asks Alice to comply with specific policy 204 or forward opaque data to Bob] 205 Alice -> atlanta.com -> biloxi.com -> bob@pc1.biloxi.com 207 Alternatively, many existing deployments "piggyback" extra 208 information at atlanta.com and biloxi.com (or modify the MIME [5] 209 content). In addition to expressly violating RFC 3261 [1] and 210 breaking any end-to-end security used by Alice and Bob, this model 211 can cause Alice or Bob to receive MIME bodies with Content-Types 212 which they don't understand (This is known as the "415" problem after 213 the 415 response code). Imagine Alice sends a requests including 214 only the text/foo MIME type, but receives a 415 Unacceptable response 215 which includes text/foo as an acceptable MIME type. Alice has no 216 information about what happened (Bob rejected the text/bar MIME type 217 inserted by atlanta.com), and cannot do anything to repair the 218 "error". 220 The compromise approach described in the next section allows 221 atlanta.com to "challenge" Alice with repairable error responses to 222 comply with atlanta's policies, while biloxi.com can add a message 223 body intended for consumption by Bob. This may be a technically 224 workable solution, but requires complex MIME and authorization 225 processing by intermediaries that participate in policy. This 226 approach would still require a relaxation of Section 16.6, Step 1 of 227 RFC 3261 [1]. 229 Alice -> atlanta.com 231 [atlanta.com asks Alice to comply with specific policy] 232 Alice -> atlanta.com -> biloxi.com 234 [biloxi adds its policy requests to the request] 235 -> Bob 237 Pentagram Signaling Model: In this model, extra intermediaries who 238 are not directly associated with either Alice or Bob are included. 239 This model is to be avoided as it dramatically increases the 240 complexity of the security required. 242 Alice -- atlanta.com -- provider.net -- biloxi.com -- Bob 244 4. Overview of the body addition proposal 246 Of prime importance to the body addition proposal is insuring that 247 the mechanism can be added in a backwards compatible way. To 248 facilitate backward compatibility, the body addition proposal 249 introduces a new option-tag called "repack" which indicates that a 250 user agent supports multipart MIME [6] and allows bodies to be 251 addressed to and from intermediaries. User Agents include this token 252 in a Supported header when registering along with an Accept header 253 with all the MIME types the User Agent supports. 255 When a User Agent supports body repacking, we assume that the 256 wrapping of the outermost MIME type in the SIP body is not relevant 257 for the authentication purposes. Each of the MIME parts inside the 258 outermost part can stand alone as a separate message. Each of these 259 MIME parts MUST have a Content-Disposition MIME header. If the MIME 260 part is sent to or from an intermediary (instead of the original UAC 261 or the final UAS), the Content-Disposition header MUST contain a src 262 or dest parameter indicating the source or destination of the 263 request. 265 If the UAC needs to include some content for a specific intermediary, 266 it indicates this by adding a content parameter to the Route header 267 field value which corresponds to the target intermediary. The 268 content parameter contains a content ID [7] which is referenced in 269 the appropriate body. (For illustrative purposes, a band of 270 asterisks (*****) surrounds content that would actually be signed 271 or encrypted using S/MIME). 273 INVITE sip:bob@biloxi.example.com 274 From: 275 To: 276 Route: ;content="lki290s8" 277 ... 278 Content-Type: multipart/mixed;boundary=bar 280 --bar 281 Content-ID: 282 Content-Disposition: policy ;handling=optional ;dest="sip:atlanta.example.com" 283 ***** 284 * ... 285 ***** 286 --bar 287 Content-Disposition: session ;handling=required 288 ***** 289 * Content-Type: application/sdp 290 * ... 291 ***** 292 --bar 294 When an intermediary operating on the UACs behalf requires additional 295 information in a request it needs to send a repairable error response 296 asking for the appropriate additional information. We can define a 297 new response code for this, for example "497 Policy Error". However, 298 the UAC and intermediaries operating on the UACs behalf are expected 299 to be well matched, for example mutually configured using session 300 independent policies, so this extra round trip should not happen very 301 often. 303 When an intermediary operating on behalf of the UAS needs to include 304 additional information about the request, it can add a body part to 305 the message if it knows that the UAS supports the repack option and 306 that any required body types that were added are acceptable to the 307 UAS. In most cases, the UAS registered with the repack option-tag in 308 a Supported header or is administratively configured to known that 309 the UAS supports the extension. In addition, the UAS proxy can 310 include any MIME types as long as the handling parameter (in the 311 Content-Disposition header) indicates the body part is optional. In 312 addition, if the intermediary is collocated with the registrar for 313 the UAS, the intermediary can observe the MIME types listed in the 314 Accept header and send these even as "required" body parts. Any body 315 parts added by the intermediary need to have a src parameter which 316 corresponds the SIP URI of the intermediary that added the body part. 317 In addition, these MIME parts MUST be signed using S/MIME using the 318 key from a certificate which contains a SubjectAltName field which 319 exactly matches the SIP URI in the src parameter. 321 Content-Disposition: policy ;handling=optional ;src="sip:biloxi.example.com" 322 ***** 323 * Content-Type: application/sip-session-policy+xml 324 * ... 325 ***** 327 When a UAC receives a request, it MUST examine the src parameter for 328 each body type that it understands. If any of the body parts are 329 signed it then must discard body parts from untrusted sources, or 330 improperly signed body parts. The UAC can then clearly distinguish 331 the body parts which were signed by the UAC from the body parts that 332 were signed by the a proxy operating on behalf of the UAS. 334 When the UAS sends a response, intermediaries operating on behalf of 335 the UAS can examine the response and forward the response along. 336 Typically the response will cooperate with the policies that were 337 just sent in the request, but if not, the intermediary can send a 500 338 Server Error response to the request and drop the illegal response it 339 received from the UAS. Intermediaries can similarly add body parts 340 to the response as long as the UAC indicated support for the repack 341 option-tag and all "required" MIME types are acceptable to the UAC. 342 Finally, when the UAC receives the response, it MUST examine the src 343 parameter for each body type that it understands, discard untrusted 344 or improperly signed body parts and act on body parts sent by the UAS 345 differently from body parts added by its intermediary. 347 This proposal addresses the three most serious technical concerns 348 with adding bodies. The proposal is backward safe and can operate 349 even if only one side supports the extension. It is impossible for 350 the UAC to receive a 415 Not Acceptable response due to content 351 inserted by an intermediary. The User Agents can distinguish which 352 body parts were sent by the other User Agent and which were added by 353 an intermediary. 355 Unfortunately the proposal requires very sophisticated MIME parsing 356 and verification/generation of multiple S/MIME signatures per message 357 on both User Agents and intermediaries which decide to add bodies. 358 This requires that UACs either sign all bodies, no bodies, or that 359 they trust an appropriate service to do so (and that the protocol 360 support necessary for this is available). On first glance, it may 361 also seem to increase message size and processing time, however 362 initial analysis does not suggest any significant difference between 363 this approach and any other proposals in this regard. Note also, 364 that this approach opens up opportunities for intermediaries to abuse 365 this functionality for so-called "middle-to-middle" communications 366 which can introduce a significant burden on other SIP intermediaries 367 and the infrastructure of the Internet. 369 Finally, this approach can be modified slightly to allow a 3rd party 370 user agent to sign, verify, encrypt, and decrypt SIP messages on 371 behalf of a user agent which does not support end-to-end security. 372 This SIP node would keep credentials for the address-of-record of the 373 user agent and apply these to each of its messages. It could handle 374 all the authorization and verification duties (for example, throwing 375 away bodies inserted by malicious intemediaries) normally required of 376 user agents under this proposal. 378 5. Applications with and without body modification 380 5.1 Logging 382 This application [10] requires an intermediary to inspect SIP message 383 bodies. This can be session descriptions [18] which reference 384 specific streams, or in the case of the MESSAGE method [22], actual 385 content. If this session description or content is encrypted, either 386 the logging service needs to receive a copy of the Content Encryption 387 Key or it needs to receive another copy of the message. 389 It is clear that if Alice wants to provide a copy of Content 390 Encryption Key to her logging proxy she can, but less clear how she 391 can (directly or indirectly) provide this information to Bob's 392 logging proxy. Bob could provide this information to its proxy, but 393 this requires that either Bob's proxy ask for this information (and 394 that Alice provide it) or that Bob provide the Content Encryption Key 395 to his proxy in a way that is easy to correlate. 397 For this application, it is not necessary for an intermediary to ever 398 add its own body (commonly called end-to-middle [15] security or 399 e2m). Addressing some bodies from a user agent to an intermediary 400 instead of the other user agent could be used here, but this 401 application could be accomodated nearly as easily without addressing 402 bodies at intermediaries. 404 5.2 Session codec / bandwidth policy checking 406 This application requires an intermediary to inspect session 407 descriptions, but does not require them to be changed. This is 408 problematic if the session description is encrypted however, 409 especially if the session description contains keying information 410 [24] which Alice or Bob don't want to be provided to an intermediary 411 and is not otherwise required. 413 Directing a copy of a portion of the session description at an 414 intermediary (e2m) could mitigate the privacy lost here, but does not 415 require body addition. 417 5.3 Midcom-style firewall traversal 419 Like the previous application, a firewall traversal intermediary (ex: 420 using the MIDCOM architecture [19]) needs access to the transport 421 protocols, IP addresses, and ports in use for each m-line. Again, if 422 the session description is encrypted and contains sensitive keying 423 material, it would be desirable to provide an additional copy of this 424 information in another body using e2m. No body additions by 425 intermediaries are required for this application either. 427 5.4 NAT traversal (including v4/v6 translators) 429 NAT [20] traversal using protocols such as STUN [8] and ICE [25] 430 would not normally require body modification, addition, or even 431 inspection. (An intermediary might need to provide an address of a 432 STUN server for example.) NAT traversal using a MIDCOM-style 433 approach however introduces a tremendous amount of complexity. 435 This application is fairly complex with the body modification 436 proposal (a specific proposal is described in the next paragraph, 437 which does ), and even more challenging when body modifications are 438 not permitted. However, it may be prudent for the SIP community to 439 completely reject this as a valid application of the SIP session 440 policy mechanism when superior mechanisms for NAT traversal are 441 available. 443 [Description of MIDCOM-style NAT traversal with body addition 444 approach] 446 5.5 3rd-party Asserted Identity 448 This application involves an intermediary providing an assertion of 449 the identity of the sender of the message. A proposal which 450 describes this concept using a body (in this case an authenticated 451 identity body) is described in 452 . 453 A proposal which describes this concept using a header is [11]. Note 454 that the auth-id [16] body could be replaced with a different body to 455 allow unambiguous use in both requests and responses. 457 End-to-end identity could be provided in such a way to provide a 458 secure binding between the original Request-URI and a Contact header 459 provided. When used in a body, this would unfortunately require a 460 new Identity header anytime a Contact header changes (for example 461 when transitioning from a 2-party call to a SIP conference [26]). 463 5.6 Request History 465 This application involves an intermediary providing an assertion that 466 a request was retargetted. Request history using body addition [12] 467 is extremely natural. An auth-id body is provided for every 468 retargetting signed by the proxy performing that retargetting. This 469 provides an alternative way of binding an original Request-URI with a 470 provided Contact header. 472 History without body addition could be accomplished in one of three 473 ways. The Request-History header field value itself could contain a 474 cryptographic object similar to the current Identity proposal. The 475 Request-History service could be restricted so it can only be 476 provided by a server which also provides the Identity service (the 477 most common cases), Finally, request history could be provided as a 478 P-Header [21] only for use in certain administrative domains using a 479 technique similar to RFC 3325 [23] (P-Asserted-Identity) that 480 requires specific trust relationships. 482 5.7 3rd Party Authentication Service 484 This service signs, verifies, encrypts, and decrypts on behalf of a 485 user agent which cannot perform these functions itself. A third 486 party which performs these functions most definitely needs to inspect 487 and add MIME bodies. This third part however would have credentials 488 used on behalf of the user, and would presumably be reachable 489 directly over a secure channel (for example over a TLS connection). 490 This application is easily implemented using the body addition 491 proposal. If Alice needed a new request signed or encrypted she 492 would need to send her request to this server, which would return her 493 signed or encrypted content. She would then resend the request. 494 Bob's service could add a MIME body with the decrypted and verified 495 contents, and also encrpyt and/or sign Bob's response. 497 As an alternative to the body addition proposal, you could relax the 498 body modification requirement just for this specific application 499 which would be defined as a new SIP role with specific normative 500 behavior. 502 In either case, such a service could be collocated with a SIP 503 Credential Service [17] or an 504 505 . 507 6. Security Considerations 509 Much to talk about here. 511 7. IANA Considerations 513 8. Acknowledgments 515 Thanks to Jon Peterson and Cullen Jennings for a hearty discussion. 517 9. References 519 9.1 Normative References 521 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 522 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 523 Session Initiation Protocol", RFC 3261, June 2002. 525 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 526 Levels", BCP 14, RFC 2119, March 1997. 528 [3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 529 2633, June 1999. 531 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 532 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 533 1999. 535 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 536 Extensions (MIME) Part One: Format of Internet Message Bodies", 537 RFC 2045, November 1996. 539 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 540 Extensions (MIME) Part Two: Media Types", RFC 2046, November 541 1996. 543 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 544 Locators", RFC 2392, August 1998. 546 [8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 547 Simple Traversal of User Datagram Protocol (UDP) Through 548 Network Address Translators (NATs)", RFC 3489, March 2003. 550 [9] Rosenberg, J., "Requirements for Session Policy for the Session 551 Initiation Protocol (SIP)", 552 draft-ietf-sipping-session-policy-req-01 (work in progress), 553 February 2004. 555 [10] Ono, K. and S. Tachimoto, "Requirements for End-to-middle 556 Security for the Session Initiation Protocol (SIP)", 557 draft-ietf-sipping-e2m-sec-reqs-03 (work in progress), July 558 2004. 560 [11] Peterson, J., "Enhancements for Authenticated Identity 561 Management in the Session Initiation Protocol (SIP)", 562 draft-ietf-sip-identity-02 (work in progress), May 2004. 564 [12] Barnes, M., "An Extension to the Session Initiation Protocol 565 for Request History Information", 566 draft-ietf-sip-history-info-02 (work in progress), February 567 2004. 569 [13] Petrie, D., "A Framework for Session Initiation Protocol User 570 Agent Profile Delivery", draft-ietf-sipping-config-framework-03 571 (work in progress), May 2004. 573 [14] Hilt, V., "Session-Independent Policies for the Session 574 Initiation Protocol (SIP)", 575 draft-hilt-sipping-session-indep-policy-01 (work in progress), 576 May 2004. 578 [15] Ono, K. and S. Tachimoto, "End-to-middle security in the 579 Session Initiation Protocol(SIP)", 580 draft-ono-sipping-end2middle-security-02 (work in progress), 581 May 2004. 583 [16] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 584 draft-ietf-sip-authid-body-03 (work in progress), May 2004. 586 [17] Jennings, C., "Certificate Management Service for SIP", 587 draft-jennings-sipping-certs-03 (work in progress), May 2004. 589 9.2 Informational References 591 [18] Handley, M. and V. Jacobson, "SDP: Session Description 592 Protocol", RFC 2327, April 1998. 594 [19] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 595 Rayhan, "Middlebox communication architecture and framework", 596 RFC 3303, August 2002. 598 [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 599 (NAT) Terminology and Considerations", RFC 2663, August 1999. 601 [21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 602 Rosen, "Change Process for the Session Initiation Protocol 603 (SIP)", BCP 67, RFC 3427, December 2002. 605 [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 606 D. Gurle, "Session Initiation Protocol (SIP) Extension for 607 Instant Messaging", RFC 3428, December 2002. 609 [23] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 610 to the Session Initiation Protocol (SIP) for Asserted Identity 611 within Trusted Networks", RFC 3325, November 2002. 613 [24] Andreasen, F., Baugher, M. and D. Wing, "Session Description 614 Protocol Security Descriptions for Media Streams", 615 draft-ietf-mmusic-sdescriptions-06 (work in progress), July 616 2004. 618 [25] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 619 Methodology for Network Address Translator (NAT) Traversal for 620 Multimedia Session Establishment Protocols", 621 draft-ietf-mmusic-ice-01 (work in progress), February 2004. 623 [26] Johnston, A. and O. Levin, "Session Initiation Protocol Call 624 Control - Conferencing for User Agents", 625 draft-ietf-sipping-cc-conferencing-03 (work in progress), 626 February 2004. 628 Author's Address 630 Rohan Mahy 631 Cisco Systems, Inc. 632 5617 Scotts Valley Drive, Suite 200 633 Scotts Valley, CA 95066 634 USA 636 EMail: rohan@cisco.com 638 Intellectual Property Statement 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; nor does it represent that it has 645 made any independent effort to identify any such rights. Information 646 on the procedures with respect to rights in RFC documents can be 647 found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use of 652 such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository at 654 http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention any 657 copyrights, patents or patent applications, or other proprietary 658 rights that may cover technology that may be required to implement 659 this standard. Please address the information to the IETF at 660 ietf-ipr@ietf.org. 662 Disclaimer of Validity 664 This document and the information contained herein are provided on an 665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 667 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 668 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 669 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 672 Copyright Statement 674 Copyright (C) The Internet Society (2004). This document is subject 675 to the rights, licenses and restrictions contained in BCP 78, and 676 except as set forth therein, the authors retain all their rights. 678 Acknowledgment 680 Funding for the RFC Editor function is currently provided by the 681 Internet Society.