idnits 2.17.1 draft-ono-sipping-end2middle-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 88 has weird spacing: '...dle" we mean ...' -- 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 (Feb 16, 2004) is 7368 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: '0' is mentioned on line 503, but not defined == Unused Reference: '5' is defined on line 551, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 579, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2633 (ref. '4') (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '5') ** Obsolete normative reference: RFC 2630 (ref. '7') (Obsoleted by RFC 3369, RFC 3370) -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-e2m-sec-reqs (ref. '9') -- No information found for draft-ono-sipping-keyreuse-smime - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2234 (ref. '13') (Obsoleted by RFC 4234) == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-03 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING K. Ono 3 Internet-Draft S. Tachimoto 4 Expires: August 16, 2004 NTT Corporation 5 Feb 16, 2004 7 End-to-middle Security in the Session Initiation Protocol(SIP) 8 draft-ono-sipping-end2middle-security-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 16, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 A Session Initiation Protocol (SIP) User Agent (UA) does not always 39 trust all proxy servers in a request path enough to allow them 40 inspect the message bodies and/or headers contained in a message. The 41 UA might want to protect the message bodies and/or headers from all 42 proxy servers except the particular proxy that provides services that 43 depend on the ability to inspect them. In this situation, SIP needs a 44 mechanism for securing information passed between the UA and an 45 intermediary proxy, also called "end-to-middle security", which can 46 work with end-to-end security. This document proposes mechanisms to 47 achieve end-to-middle security, mainly data confidentiality for 48 end-to-middle communication. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [1]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Overview of Proposed Mechanisms . . . . . . . . . . . . . . . 4 60 2.1 Creation of S/MIME CMS Bodies for UAs and Proxy servers . . . 4 61 2.2 Indicating the Target Content . . . . . . . . . . . . . . . . 5 62 2.3 Discovery of Proxy Server's Policies . . . . . . . . . . . . . 5 63 3. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . . 7 64 3.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Summary of Content-Disposition Header Field Use . . . . . . . 10 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1 Request Example . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2 Response Example . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . 19 78 1. Introduction 80 The Session Initiation Protocol (SIP) [2] supports hop-by-hop 81 security using TLS [3] and end-to-end security using S/MIME [4]. 82 However, a UA sometimes wants to protect the message bodies and/or 83 headers from all proxy servers except a selected proxy server, which 84 provides some sort of service based on their content. Such a proxy is 85 not always adjacent to the UA. These situations require security 86 between the UA and the intermediary proxy server for the message 87 bodies and/or message headers. We call this "end-to-middle security", 88 where by "end" we mean a UA and by "middle" we mean a specific 89 proxy. 91 End-to-middle security is useful in a network where trusted and 92 partially trusted proxy servers both exist in a message path. The 93 partially trusted proxy servers are trusted only to view headers 94 related to routing. The trusted proxy servers are trusted to view the 95 message bodies and/or headers to provide services based on their 96 content. For a UA requiring such services from intermediaries, 97 end-to-end confidentiality will currently have to be disabled to take 98 advantage of them. This problem is pointed out in Section 23 of [2]. 100 Some examples of services that a proxy provides using the content of 101 message bodies and/or headers follow. One example is firewall 102 traversal. A midcom agent co-located with a proxy server controls a 103 firewall entity. The agent needs to view certain Session Description 104 Protocol (SDP) attributes in a message body or the same kind of data 105 in a SIP header. Another example is the archiving of instant 106 messaging traffic, where the archiving function co-located with a 107 proxy server logs the message bodies in the MESSAGE method. A similar 108 example is the archiving of all SIP headers and bodies traffic after 109 being checked by the proxy server. These services might be deployed 110 for financial or health care applications, where archiving 111 communications is required by policies, as well as other 112 applications. 114 This document describes proposed mechanisms to achieve data 115 confidentiality and the integrity of end-to-middle security to meet 116 the requirements discussed in [9]. The major requirement is to be 117 compatible with the end-to-end encryption that the S/MIME mechanism 118 provides. Therefore, the proposed mechanisms are based on S/MIME. The 119 mechanisms consists of the creation of encrypted data that is not 120 readable by other proxy servers and the indication by the UA of the 121 data that the UA requests the proxy server to read. In addition, it 122 also includes a mechanism for the discovery of intermediate proxy 123 servers. 125 2. Overview of Proposed Mechanisms 127 First, UAs MUST support the creation of CMS EnvelopedData body for 128 multiple recipients for end-to-middle confidentiality. For 129 compatibility with end-to-end security, the data needs to be 130 encrypted for UAs and selected proxy servers. Second, UAs SHOULD 131 support an indication mechanism to specify content in S/MIME that 132 needs to be disclosed to a selected proxy server. Proxy servers MUST 133 support to inspect the indicated content in S/MIME CMS bodies. Third, 134 UAs MAY support a discovery mechanism to find which proxy in a 135 signaling path needs to inspect and/or validate what data. In some 136 cases, UAs will be statically configured with the intermediary 137 proxy's policies and so they would not need to use this discovery 138 mechanism. Proxy servers SHOULD provide the discovery mechanism to 139 notify their policies of UAs. 141 2.1 Creation of S/MIME CMS Bodies for UAs and Proxy servers 143 Since end-to-middle security needs to be compatible with end-to-end 144 security, a creation mechanism for S/MIME CMS body is required. For 145 end-to-end data integrity, UAs use S/MIME CMS SignedData body that 146 can be validated by any entity. Therefore no new CMS SignedData 147 creation mechanism is required. 149 For data confidentiality, UAs use S/MIME CMS EnvelopedData body, 150 whose recipients are specified. There are two ways of creating this 151 data. The first way is to create an S/MIME CMS EnvelopedData body 152 that contains encrypted content that is addressed to multiple 153 recipients, such as a UA and a selected proxy server. UA MUST create 154 an CMS EnvelopedData body can contain multiple recipients for 155 encrypted data as specified in [7]. The structure contains data 156 encrypted with a content-encryption-key (CEK) and the CEK is then 157 encrypted with different key-encryption-keys (KEKs), that are 158 actually the public keys for each recipient. For example, one would 159 be for the recipient UA and another would be for the selected proxy 160 server in the end-to-middle case. 162 The second way is to create multiple S/MIME CMS EnvelopedData bodies, 163 one for each recipient. For example, one for UA and one for a 164 selected proxy server, and make them part of a multipart MIME body. 165 UAs SHOULD use this method when keying materials, such keys for use 166 by Secure RTP (SRTP)[14], are included in the SDP. One CMS 167 EnvelopedData body contains SDP that includes keying materials of an 168 SRTP stream only for the UA, and the other EnvelopedData body 169 contains an SDP that does not include the keying materials of an SRTP 170 stream that are for the UA and a selected proxy server that needs to 171 view SDP (i.e.: for a firewall control service). 173 2.2 Indicating the Target Content 175 When proxy servers receive a message, the proxy server MUST inspect 176 the "Content-Disposition" MIME headers to determine whether to 177 process the S/MIME bodies and if so, which one. UA MUST support a new 178 parameter called "required-entity" in the "Content-Disposition" MIME 179 header that indicates required proxy servers to view the content of 180 the MIME body. There is less of an impact on proxy servers that do 181 not support end-to-middle security because these proxy servers do not 182 inspect the "Content-Disposition" MIME header anyway. 184 Note: There is an altenative option that use a new SIP header. The 185 proposed mechanism requires more cost on proxy servers to 186 determine the necessity of MIME body handling than using a new SIP 187 header. However, the proxy can view the indicated MIME body more 188 effectively than using a new SIP header. In addition, using a new 189 SIP header could be negative impact on intermediary proxy servers 190 that do not support end-to-middle security, causing unnecessary 191 processing load. We feel that this MIME header parameter mechanism 192 is not as simple, but it is equally effective. 194 2.3 Discovery of Proxy Server's Policies 196 A discovery mechanism for proxy server's policies is needed when UAs 197 do not know the policies of the proxy server in a signaling path and 198 the proxy server has its own policy for providing some services. 199 When the proxy server receives a request in which it cannot view some 200 data that must be read in order to proceed or the proxy server 201 receives a request whose sending policy cannot be accepted, the proxy 202 MUST send a response with an error code. If the request is in plain 203 text, the error code SHOULD be 403 (Forbidden) accompanied with a 204 required Content-Type, such as "application/sdp". If the request is 205 in plain text and the digital signature of it is required for an 206 integrity check, the error code SHOULD be 403 (Forbidden) accompanied 207 with a required Content-Type that is "multipart/signed". If the 208 request contains encrypted data, the error code SHOULD be 493 209 (Undecipherable), accompanied with a proxy's public key certificate 210 and required Content-Type. 212 Open Issues: Which header is the appropriate one to use to set the 213 required Content-Types in a response? When nested Content-Types 214 are required such as "Content-Type: multipart/signed" for 215 "Content-Type: application/pkcs7-mime;smime-type=enveloped-data", 216 how will it be described? 218 When the UA receives one of the above error codes, the UA needs to 219 authenticate the proxy server. Therefore, the error code SHOULD 220 contain the digital signature of the proxy server. 222 In the worst case, this discovery mechanism requires two messages for 223 each proxy server in the signaling path to establish a session 224 between the UAs. In addition, it requires validation procedures using 225 the digital signatures for all proxy servers. Since this causes a 226 increase in the delay before session establishment, it is recommended 227 that UAs learn in advance the policies of as many proxy servers as 228 they can. 230 Open Issue: How does this mechanism apply in the case when a proxy 231 server needs to inspect the message body contained in the request 232 in order to provide a service for a UAS? This might be happen 233 where there a firewall in the network on the UAS's side. 235 3. Behavior of UAs and Proxy Servers 237 We describe here some examples of the behavior of UAs and proxy 238 servers in a model in which trusted and partially trusted proxy 239 servers are mixed along a message path. In the following example, 240 User #1 does not know the services or security policies of Proxy #1. 241 User#1 sends an INVITE request including encrypted SDP for end-to-end 242 security as shown in Figure 1. Proxy #1 may reject the request 243 because its inability to offer a firewall traversal service. Or Proxy 244 #1 may delete the encrypted data from the body based on a security 245 policy that prevents it from sending unknown data. 247 Home network 248 +---------------------+ 249 | +-----+ +-----+ | +-----+ +-----+ 250 User #1------| | C |-----| * |-----| * |-----| C |-- User #2 251 | +-----+ +-----+ | +-----+ +-----+ 252 | UA #1 Proxy #1 | Proxy #2 UA #2 253 +---------------------+ 255 C: Content that UA #1 allows the entity to inspect 256 *: Content that UA #1 prevents the entity from inspecting 258 Figure 1: Deployment example 260 3.1 UAC Behavior 262 When a UAC sends a request and requires end-to-end and end-to-middle 263 confidentiality of the message bodies and/or headers, it uses S/MIME 264 to encrypt them. In the above examples, UA #1 MUST use CMS 265 EnvelopedData body for UA #2 and Proxy #1. At the SIP layer, UA #1 266 MUST require Proxy #1 to decrypt selected content and to view the 267 content by using the "required-entity" parameter in the 268 Content-Disposition header. Proxy #1 then provides some services 269 based on the decrypted content. 271 When the UAC needs Proxy #1 to inspect the message bodies and/or 272 headers in the response, it SHOULD request the UAS to encrypt the 273 response by using the same CEK as for the request. The UAC uses the 274 "unprotectedAttrs" attribute to stipulate reuse of the CEK and 275 indicate its identifier as described in [10] [11]. 277 When the UAC sends a request and needs end-to-end and end-to-middle 278 integrity for the message bodies and/or headers, it uses S/MIME to 279 attach a digital signature. In the above examples, it uses the CMS 280 SignedData body of the contents. At the SIP layer, UA #1 requires 281 Proxy #1 to validate the integrity of the selected content by 282 employing the "required-entity" parameter. 284 When the UAC receives a response that uses S/MIME, it decrypts and/or 285 validates the S/MIME bodies as usual. If it receives a response that 286 uses CMS EnvelopedData body with the "KEKRecipientInfo" type of 287 "RecepientInfo" attribute, it should decrypt the "RecipientInfo" by 288 using the same CEK as for the sending request. 290 3.2 UAS Behavior 292 When a UAS sends a response for the request with this mechanism, 293 using the same type of S/MIME CMS body is recommended. For example, 294 if the UAS receives an INVITE request in which the SDP is encrypted 295 by using CMS EnvelopedData body, the recommended response would be a 296 "200 OK" containing the encrypted SDP based on CMS EnvelopedData 297 body. 299 In particular, when the CMS EnvelopedData body of the request 300 contains the "unprotectedAttrs" attribute specifying reuse of the 301 CEK, the UAS SHOULD encrypt a CEK with the CEK that was used in the 302 request, instead of the public key of the UAC. The UAS SHOULD use the 303 CMS EnvelopedData body to contain the encrypted SDP in the "200 OK" 304 response. In addition, the UAS SHOULD set the same proxy server in 305 the "required-entity" parameter of the "Content-Dispositon" MIME 306 header in the request. 308 If the UAS encrypted the SDP with a CEK that was itself encrypted 309 with the CEK in the request, the proxy server selected by the UAC can 310 view the SDP in the "200 OK" response. 312 Note: In the case when the response does not contain a message 313 body, even if the request contains a message body and was 314 encrypted by using CMS EnvelopedData body, the UAS does not need 315 to use the CMS EnvelopedData body. 317 When the UAS receives a request that uses S/MIME, it decrypts and/or 318 validates the S/MIME bodies as usual. 320 When the UAS sends a response for the request without this mechanism 321 and needs end-to-end and end-to-middle confidentiality of the message 322 bodies and/or headers , it MUST use CMS EnvelopedData to encrypt 323 them. When the UAC sends a request and needs end-to-end and 324 end-to-middle integrity of the message bodies and/or headers, it MUST 325 use CMS SignedData to attach a digital signature. This is the same 326 way the UAC normally performs with this mechanism. 328 3.3 Proxy Behavior 329 When a proxy supporting this mechanism receives a message, the proxy 330 server MUST inspect the "Content-Disposition" MIME header and the 331 "required-entity" parameter of that. If the MIME header includes the 332 processing server's own name, the proxy server MUST inspect the 333 specified content. 335 When the specified content is CMS EnvelopedData body, the proxy 336 server MUST inspect it and try to decrypt the "recipientInfo" 337 attribute. If the proxy server fails to decrypt that, it SHOULD 338 cancel the subsequent procedure and respond with a 493 339 (Undecipherable) response if it is a request, or any existing dialog 340 MAY be terminated. If the proxy server succeeds in this decryption, 341 it MUST inspect the "unprotectedAttrs" data of the CMS EnvelopedData 342 body. If the attribute gives the key's identifier, the proxy server 343 MUST keep the CEK with its identifier during the dialog. When it 344 receives subsequent messages in the dialog, it MUST try to decrypt 345 the "KEKRecipientInfo" type of "recepientInfo" attribute by using 346 this CEK. 348 When the specified content is CMS SignedData body, the proxy server 349 MUST inspect it and validate the digital signature. If the 350 verification is failed, the proxy server SHOULD reject the subsequent 351 procedure and respond with a 403 (Forbidden) response if the message 352 is a request, or any existing dialog MAY be terminated. 354 When the proxy server forwards the request, it modifies the routing 355 headers normally. It does not need to modify the S/MIME body. 357 If a proxy does not support this mechanism and receives a message 358 with the "required-parameter" parameter in the "Content-Disposition" 359 header, the proxy MUST ignore the header and perform as usual. 361 4. Summary of Content-Disposition Header Field Use 363 The following syntax specification uses the augmented Backus-Naur 364 Form (BNF) as described in RFC-2234 [13]. The new parameter 365 "required-entity" is defined in "required-param" as one of 366 "disp-param". 368 Content-Disposition = "Content-Disposition" HCOLON 369 disp-type *( SEMI disp-param ) 370 disp-type = "render" / "session" / "icon" / "alert" 371 / disp-extension-token 372 disp-param = handling-param / required-param / generic-param 373 handling-param = "handling" EQUAL 374 ( "optional" / "required" / other-handling ) 375 other-handling = token 376 disp-extension-token = token 377 required-param = "required-entity" EQUAL 378 proxy-uri *(COMMA proxy-uri) 379 proxy-uri = ( name-addr / addr-spec ) 381 5. Examples 383 The following examples illustrate the use of the mechanism defined in 384 the previous section. 386 5.1 Request Example 388 In the following example, a UA needs SDP in an INVITE message to be 389 confidential and the UA allows a proxy server to view the SDP in an 390 INVITE request. In addition, the UA needs to protect the policy of 391 the proxy server. In the example encrypted message below, the text 392 with the box of asterisks ("*") is encrypted: 394 INVITE alice@atlanta.example.com --> ss1.atlanta.example.com 396 INVITE sip:bob@biloxi.example.com SIP/2.0 397 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 398 Max-Forwards: 70 399 Route: 400 From: Alice ;tag=9fxced76sl 401 To: Bob 402 Call-ID: 3848276298220188511@atlanta.example.com 403 CSeq: 1 INVITE 404 Contact: 405 Date: Fri, 20 June 2003 13:02:03 GMT 406 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 407 micalg=sha1;boundary=boundary1 408 Content-Length: ... 410 --boundary1 412 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 413 name=smime.p7m 414 Content-Transfer-Encoding: base64 415 Content-Disposition: session;filename=smime.p7m;handling=required; 416 required-entity=ss1.atlanta.example.com 417 Content-Length: ... 419 ****************************************************************** 420 * (encryptedContentInfo) * 421 * Content-Type: application/sdp * 422 * Content-Length: ... * 423 * * 424 * v=0 * 425 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 426 * s=- * 427 * c=IN IP4 192.0.2.101 * 428 * t=0 0 * 429 * m=audio 49172 RTP/AVP 0 * 430 * a=rtpmap:0 PCMU/8000 * 431 * * 432 * (recipientInfos) * 433 * RecepientInfo[0] for ss1.atlanta.example.com public key * 434 * RecepientInfo[1] for bob's public key * 435 * * 436 * (unprotectedAttr) * 437 * CEKReference * 438 ****************************************************************** 440 --boundary1-- 441 Content-Type: application/pkcs7-signature; name=smime.p7s 442 Content-Transfer-Encoding: base64 443 Content-Disposition: attachment; 444 filename=smime.p7s;handling=required 446 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 447 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 448 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 449 7GhIGfHfYT64VQbnj756 451 --boundary1-- 453 5.2 Response Example 455 In the following example, a UA sends a response with this mechanism. 456 In the example encrypted message below, the text boxed in asterisks 457 ("*") is encrypted: 459 200 OK bob@biloxi.example.com --> ss2.biloxi.example.com 461 SIP/2.0 200 OK 462 Via: SIP/2.0/TCP 463 ss2.biloxi.example.com:5060;branch=z9hG4bK721e418c4.1 464 ;received=192.0.2.222 465 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 466 ;received=192.0.2.111 467 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 468 ;received=192.0.2.101 469 Record-Route: , 470 471 From: Alice ;tag=9fxced76sl 472 To: Bob ;tag=314159 473 Call-ID: 3848276298220188511@atlanta.example.com 474 CSeq: 2 INVITE 475 Contact: 476 Content-Type:multipart/signed;protocol="application/pkcs7-signature"; 477 micalg=sha1;boundary=boundary41 478 Content-Length: ... 480 --boundary41 482 Content-Type: application/pkcs7-mime; 483 smime-type=enveloped-data;name=smime.p7m 484 Content-Transfer-Encoding: base64 485 Content-Disposition: session; 486 filename=smime.p7m;handling=required; 487 Content-Length: ... 489 ****************************************************************** 490 * (encryptedContentInfo) * 491 * Content-Type: application/sdp * 492 * Content-Length: ... * 493 * * 494 * v=0 * 495 * o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com * 496 * s=- * 497 * c=IN IP4 192.0.2.201 * 498 * t=0 0 * 499 * m=audio 3456 RTP/AVP 0 * 500 * a=rtpmap:0 PCMU/8000 * 501 * * 502 * (recipientInfos) * 503 * RecepientInfo[0] for KEKidentifier * 504 ****************************************************************** 506 --boundary41-- 508 Content-Type: application/pkcs7-signature; name=smime.p7s 509 Content-Transfer-Encoding: base64 510 Content-Disposition: attachment; filename=smime.p7s;handling=required 512 hhhHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 513 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 514 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 515 7GhIGfHfYT64VQbnj756 517 --boundary41-- 519 6. Security Considerations 521 This specification is about applying S/MIME-secured messages for use 522 in end-to-middle security. It is also about applying the CEK reuse 523 method defined in [10]. This requires the same security consideration 524 as those of [4] and [10]. 526 7. IANA Considerations 528 This document requires a new parameter in "Content-Disposition" 529 header fields, namely "required-entity". 531 8. Acknowledgments 533 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 534 this concept, and to Jon Peterson for his helpful comments. 536 References 538 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 539 Levels", RFC 2119, BCP 14, March 1997. 541 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 542 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 543 Session Initiation Protocol", RFC 3261, June 2002. 545 [3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 546 2246, January 1999. 548 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 549 2633, June 1992. 551 [5] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A. 552 and A. Rayhan, "Middlebox communication architecture and 553 framework", RFC 3303, August 2002. 555 [6] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C. 556 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 557 Instant Messaging", RFC 3428, December 2002. 559 [7] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 560 1999. 562 [8] Rosenberg, J., "Requirements for Session Policy for the Session 563 Initiation Protocol (SIP)", 564 draft-rosenberg-sipping-session-policy-req-00 (work in 565 progress), December 2002. 567 [9] Ono, K. and S. Tachimoto, "Requirements for end-to-middle 568 security in the Session Initiation Protocol (SIP)", 569 draft-ietf-sipping-e2m-sec-reqs-01 (work in progress), 570 February 2004. 572 [10] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 573 Keys", RFC 3185, October 2001. 575 [11] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP", 576 draft-ono-sipping-keyreuse-smime-00 (work in progress), 577 February 2004. 579 [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 580 November 2002. 582 [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax 583 Specifications: ABNF", RFC 2234, November 1997. 585 [14] Andreasen, F., Baugher, M. and D. Wing, "Session Description 586 Protocol Security Descriptions for Media Streams", 587 draft-ietf-mmusic-sdescriptions-03.txt (work in progress), 588 February 2004. 590 Authors' Addresses 592 Kumiko Ono 593 Network Service Systems Laboratories 594 NTT Corporation 595 9-11, Midori-Cho 3-Chome 596 Musashino-shi, Tokyo 180-8585 597 Japan 599 EMail: ono.kumiko@lab.ntt.co.jp 601 Shinya Tachimoto 602 Network Service Systems Laboratories 603 NTT Corporation 604 9-11, Midori-Cho 3-Chome 605 Musashino-shi, Tokyo 180-8585 606 Japan 608 EMail: tachimoto.shinya@lab.ntt.co.jp 610 Intellectual Property Statement 612 The IETF takes no position regarding the validity or scope of any 613 intellectual property or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; neither does it represent that it 617 has made any effort to identify any such rights. Information on the 618 IETF's procedures with respect to rights in standards-track and 619 standards-related documentation can be found in BCP-11. Copies of 620 claims of rights made available for publication and any assurances of 621 licenses to be made available, or the result of an attempt made to 622 obtain a general license or permission for the use of such 623 proprietary rights by implementors or users of this specification can 624 be obtained from the IETF Secretariat. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights which may cover technology that may be required to practice 629 this standard. Please address the information to the IETF Executive 630 Director. 632 Full Copyright Statement 634 Copyright (C) The Internet Society (2004). All Rights Reserved. 636 This document and translations of it may be copied and furnished to 637 others, and derivative works that comment on or otherwise explain it 638 or assist in its implementation may be prepared, copied, published 639 and distributed, in whole or in part, without restriction of any 640 kind, provided that the above copyright notice and this paragraph are 641 included on all such copies and derivative works. However, this 642 document itself may not be modified in any way, such as by removing 643 the copyright notice or references to the Internet Society or other 644 Internet organizations, except as needed for the purpose of 645 developing Internet standards in which case the procedures for 646 copyrights defined in the Internet Standards process must be 647 followed, or as required to translate it into languages other than 648 English. 650 The limited permissions granted above are perpetual and will not be 651 revoked by the Internet Society or its successors or assignees. 653 This document and the information contained herein is provided on an 654 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 655 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 656 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 657 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 658 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Acknowledgement 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.