idnits 2.17.1 draft-ono-sipping-end2middle-security-00.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 7 instances of too long lines in the document, the longest one being 34 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. -- 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 445 has weird spacing: '...r field where...' == Line 447 has weird spacing: '... adr o ...' == Line 451 has weird spacing: '...r field where...' == Line 453 has weird spacing: '... adr o ...' == Line 454 has weird spacing: '...99 adr o ...' -- 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 (June 23, 2003) is 7614 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) == Missing Reference: '0' is mentioned on line 625, but not defined == Unused Reference: '10' is defined on line 692, 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' ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: December 22, 2003 NTT Corporation 5 June 23, 2003 7 End-to-middle security in the Session Initiation Protocol(SIP) 8 draft-ono-sipping-end2middle-security-00 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 December 22, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 End-to-end encryption for confidentiality services can conflict with 39 some of the features provided by intermediaries. For example, if a 40 SIP UA encrypts the message body by using S/MIME for end-to-end 41 security, it cannot use features that the proxy employs to inspect 42 the message body contained in the request. This situation requires 43 securing information passed between the UA and an intermediary proxy, 44 also called "end-to-middle security", which can work with end-to-end 45 security. This document describes a method of achieving 46 end-to-middle security, allowing a SIP UA to disclose message data to 47 selected intermediaries and protect the data from being seen by other 48 intermediaries. It describes how to apply S/MIME CMS EnvelopedData 49 body for use in end-to-middle security. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [1]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problems with the Existing Situations . . . . . . . . . . . . 4 61 3. Requirements for a Solution . . . . . . . . . . . . . . . . . 6 62 3.1 Requirements from UA's Perspective . . . . . . . . . . . . . . 6 63 3.2 Requirements from Proxy's Perspective . . . . . . . . . . . . 6 64 4. Overview of Proposed Mechanism . . . . . . . . . . . . . . . . 8 65 4.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.4 Summary of Header Field Use . . . . . . . . . . . . . . . . . 11 69 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1 Request example . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.2 Response example . . . . . . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 75 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 77 Intellectual Property and Copyright Statements . . . . . . . . 22 79 1. Introduction 81 The Session Initiation Protocol (SIP) [2] supports hop-by-hop 82 security using TLS [3] and end-to-end security using S/MIME [4]. 83 This assumes a SIP UA trusts all proxy servers in a request path to 84 decide whether or not to inspect the message bodies contained in a 85 message. 87 However, there is a model where trusted and partially-trusted proxy 88 servers are mixed through a message path. The partially-trusted proxy 89 servers are only trusted in terms of the SIP routing. Hop-by-hop 90 confidentiality services using TLS are not suitable for this model. 91 End-to-end confidentiality services using S/MIME are also not 92 suitable when the intermediaries provide features based on reading 93 the message bodies and/or headers. This problem is described in 94 Section 23 of [2]. 96 One example of such a feature is NAT/firewall control, where a midcom 97 [5] agent co-located with a proxy server controls a NAT/firewall 98 based on certain SDP attributes in a SIP transaction. Another example 99 of such a feature is the archiving of instant messaging traffic, 100 where the archiving function co-located with a proxy server logs the 101 message bodies in the MESSAGE [6] method. In these cases, a UA might 102 want to protect the message bodies and/or headers from proxy servers 103 excluding a selected proxy, which provides these features. 105 Such a proxy is not always the first hop for the UA. These situations 106 require security between the UA and the intermediary proxy for the 107 message bodies and/or message headers. We call this "end-to-middle 108 security". 110 End-to-middle security consists of authentication, message integrity, 111 and message confidentiality. As for authentication, HTTP digest 112 authentication described in [2] is used for user-to-proxy and 113 proxy-to-user authentication. The authenticating proxy is not limited 114 to the first hop for the UA. Thus, HTTP digest authentication can be 115 used for end-to-middle security. Digital signatures in a Public Key 116 Infrastructure, that is S/MIME CMS [7] SignedData body with 117 certificate, can also be used for authentication. As for message 118 integrity, S/MIME CMS SignedData body can be used. S/MIME CMS 119 SignedData body is created with the original data and the 120 originator's private key, and anyone can verify the integrity using 121 the originator's public key and the certificate. Thus, S/MIME CMS 122 SignedData body can be used for end-to-middle security at the same 123 time as end-to-end security. However, proxy servers usually transfer 124 SIP messages without interpreting the S/MIME bodies. This document 125 mainly discusses the message confidentiality and integrity of 126 end-to-middle security. 128 2. Problems with the Existing Situations 130 We describe here examples of models in which trusted and 131 partially-trusted proxy servers are mixed along a message path. These 132 situations demonstrate the reasons for requiring end-to-middle 133 security. 135 In the following example, Proxy#1 server is the home proxy server of 136 User#1 using UA#1. User#1 communicates with User#2 through Proxy#1 137 and Proxy#2 as shown in Figure 1 . UA#1 has already known the 138 public key certificate of Proxy#1, and it allows Proxy#1 to inspect 139 the message bodies in a request for some purpose. However, User#1 140 does not know whether Proxy#2 is trustworthy, and thus wants to 141 protect the message bodies in the request. Thus, there is the 142 problem of granting a trusted intermediary permission to inspect 143 message bodies while preserving their confidentiality with respect to 144 other intermediaries. 146 Even if UA#1's request message authorizes a selected proxy (Proxy#1) 147 to see the message body, UA#1 is unable to authorize the same proxy 148 to see the message body in the response from UA#2. Thus, there is the 149 problem of designating and sharing a key that can be reused as a CEK 150 for bidirectional exchanges of S/MIME-secured messages within SIP. 152 Note: This document describes the two different problems and 153 solutions. It might be a good idea to break this document into two 154 separate drafts. 156 Home network 157 +---------------------+ 158 | +-----+ +-----+ | +-----+ +-----+ 159 User#1------| | |-----| |-----| |-----| |-- User#2 160 | +-----+ +-----+ | +-----+ +-----+ 161 | UA#1 Proxy#1 | Proxy#2 UA#2 162 +---------------------+ 164 Figure 1: Deployment example#1 166 In the next example, User#1 connects UA#1 to a proxy server in a 167 visited network, e.g. a hotspot service or a roaming service. Since 168 User#1 wants to utilize certain home network services, UA#1 connects 169 to a home proxy server, Proxy#1. However, UA#1 has to connect 170 Proxy#1 via the proxy server of the visited network (Proxy A), 171 because User#1 has to follow the policy of that network. Proxy A may 172 perform access control based on the destination addresses of calls. 173 User#1 trusts Proxy A to route requests, but not to inspect the 174 message bodies they contained. User#1 trusts Proxy#1 both to route 175 requests and to inspect the message bodies for some purpose. 177 The same problems exist as those in the first example. 179 Visited network 180 +---------------------+ 181 | +-----+ +-----+ | +-----+ +-----+ +-----+ 182 User#1 -- | | |-----| |-----| |-----| |-----| | 183 | +-----+ +-----+ | +-----+ +-----+ +-----+ 184 | UA#1 Proxy A | Proxy#1 Proxy#2 UA#2 185 +---------------------+ 187 Figure 2: Deployment example#2 189 3. Requirements for a Solution 191 These requirements are similar to the general requirements described 192 in the Internet Draft of the Session Policy Requirements [8]. The 193 differences are that in this document a UA explicitly authorizes the 194 use of the features provided by intermediaries. In [8], the 195 intermediaries imposes a session policy without user authorization. 196 This document describes security issues related to authorizing an 197 intermediary to see message contents. 199 3.1 Requirements from UA's Perspective 201 1. The solution SHOULD work even with SIP end-to-end encryption for 202 confidentiality service enabled. 204 2. It SHOULD work even with SIP end-to-end integrity service 205 enabled. 207 3. It SHOULD have a minimal impact on the way to handle messages 208 with S/MIME bodies. 210 4. It SHOULD allow a UA to request selected proxy servers to view 211 selected message body. In addition, the request itself SHOULD be 212 secure. 214 5. It SHOULD allow a UA to request the UA on the opposite-side to 215 impose the same proxy policy on the same proxy server. In 216 addition, the request itself SHOULD be secure. 218 It is not appropriate for the UA on the opposite-side to have 219 knowledge of the public key certificate of the proxy server on 220 the originating network. This last requirement can be modified 221 into the following: 223 + The solution SHOULD allow a UA to request the opposite-side 224 UA to reuse a content-encryption-key in subsequent messages 225 during a dialog. 227 + It SHOULD allow a UA to request a selected proxy server to 228 keep a content-encryption-key in a message during a dialog. 230 + The above requests themselves SHOULD be secure. 232 3.2 Requirements from Proxy's Perspective 234 1. The solution SHOULD have no impact on proxy servers that do not 235 provide features based on S/MIME bodies in terms of handling the 236 existing SIP headers. 238 2. It SHOULD have less impact on proxy servers that provide features 239 based on S/MIME bodies. 241 When a proxy server receives an S/MIME message, it should be 242 able to quickly and easily determine the necessity to 243 investigate the S/MIME body. This last requirement can be 244 modified into the following: 246 + It SHOULD allow proxy servers to quickly and easily 247 determine whether to handle S/MIME bodies and, if so, how 248 and which one. 250 4. Overview of Proposed Mechanism 252 The proposed mechanism uses a new SIP header, "Proxy-Policy". The 253 "Proxy-Policy" header indicates that a UA wants selected proxy 254 servers to view selected S/MIME bodies. The proxy servers view the 255 "Proxy-Policy" to determine whether to handle the S/MIME bodies and 256 if so, which one. 258 Note: An alternative mechanism would be to add a parameter in the 259 "Content-Disposition" header. However, since proxy servers usually 260 do not inspect the "Content-Disposition" header, it is not as good 261 as using an additional SIP header. 263 In addition, the proposed mechanism employs the "unprotectedAttrs" 264 attribute in the S/MIME CMS EnvelopedData body to expresses a 265 sender's preferences to reuse a content-encryption-key in subsequent 266 messages during a dialog. 268 Note: An alternative mechanism would be to add a parameter in the 269 "Proxy-Policy" header. However, since the key reuse is executed 270 after the investigation of CMS data, it is not necessary to be set 271 at the SIP layer. In addition, since [9] has already defined the 272 reuse method of content-encryption-key using the 273 "unprotectedAttrs" attribute in the EnvelopedData, it is better to 274 use the existing mechanism. 276 We assume that UA#1 requires Proxy#1 to view the message body's SDP 277 in order to control a firewall for the session in the situation shown 278 in Figure 1. 280 Since UA#1 requires end-to-end and end-to-middle confidentiality for 281 the content of the SDP, it uses S/MIME CMS EnvelopedData for multiple 282 recipients and sets the "Content-ID" header to identify the content. 283 The "recipientInfos" data of the EnvelopedData contains the encrypted 284 content-encryption-keys for each recipient of the same encrypted 285 content. One of the "RecepientInfo" attributes is for Proxy#1, while 286 another is for UA#2. UA#1 may use the "unprotectedAttrs" attribute to 287 request UA#2 to reuse the content-encryption-key instead of a public 288 key to encrypt a content-encryption-key of a response. 290 +----------------+ +-------+ +-----+ +-----+ 291 |E-CEK(C) with |--->|C, |---->| |----->|C, | 292 |E-UA#2key(CEK)& | | | | | |CEK | 293 |E-P#1key(CEK) | |CEK | | | | | 294 +----------------+ +-------+ +-----+ +-----+ 295 UA#1 Proxy#1(P#1) Proxy#2 UA#2 296 C: Content of a request 297 CEK: Content-encryption-key 298 E-CEK(C): Content encrypted using CEK 299 E-Xkey(CEK): CEK encrypted using X's public key. 301 Figure 3: Overview of message with CMS EnvelopedData 303 +----------------+ +-------+ +-----+ +----------------+ 304 |C' |<---|C', |<----| |<-----|E-CEK'(C') with | 305 |CEK' | |CEK' | | | |E-CEK(CEK')& | 306 +----------------+ +-------+ +-----+ +----------------+ 307 UA#1 Proxy#1(P#1) Proxy#2 UA#2 309 C': Content of a response 310 CEK': Content-encryption-key. 312 Figure 4: Overview of subsequent message with CMS EnvelopedData 314 Issue:How does this mechanism apply for the case when Proxy#2 315 needs to inspect the message body contained in the request to 316 UA#2? 318 When UA#1 requires the message integrity for end-to-end and 319 end-to-middle security, it uses the S/MIME CMS SignedData for the 320 "message/sipfrag"[10] Content-type. When it requires confidentiality 321 and integrity for the message, it uses the S/MIME SignedData of the 322 S/MIME EnvelopedData for the message. 324 4.1 UAC Behavior 326 When a UAC sends a request and it requires end-to-end and 327 end-to-middle confidentiality of the message bodies and/or headers , 328 it uses S/MIME to encrypt them. In the above examples, UA#1 uses S/ 329 MIME EnvelopedData for UA#2 and Proxy#1. At the SIP layer, UA#1 330 requires Proxy#1 to decrypt selected content and to view the content 331 by using the "Proxy-Policy" header. Proxy#1 then provides some 332 feature based on the decrypted content. 334 When the UAC needs Proxy#1 to inspect the message bodies and/or 335 headers in the response, it SHOULD request the UAS to encrypt the 336 response by using the same content-encryption-key as for the request. 337 The UAC uses the "unprotectedAttrs" attribute to stipulate reuse of 338 the content-encryption-key and indicate its identifier. 340 Note: The "unprotectedAttrs" data is not protected, so it should 341 be protected using S/MIME SignedData. 343 When the UAC sends a request and needs the end-to-end and 344 end-to-middle integrity for the message bodies and/or headers, it 345 uses S/MIME to attach a digital signature. In the above examples, it 346 uses the S/MIME CMS SignedData of the contents. At the SIP layer, 347 UA#1 requires Proxy#1 to validate the integrity of the selected 348 content by employing the "Proxy-Policy" header. 350 When the UAC receives a response that uses S/MIME, it decrypts and/or 351 validates the S/MIME bodies as usual. If it receives a response that 352 uses S/MIME EnvelopedData with the "KEKRecipentInfo" type of 353 "RecepientInfo" attribute, it should decrypt the "RecipentInfo" by 354 using the same content-encryption-key as for the sending request. 356 4.2 UAS Behavior 358 When a UAS sends a response for the request with this mechanism, 359 using the same type of S/MIME CMS data is recommended. For example, 360 if the UAS receives an INVITE request in which the SDP is encrypted 361 by using S/MIME EnvelopedData, the recommended response would be a 362 "200 OK" containing the encrypted SDP based on the the S/MIME 363 EnvelopedData. 365 In particular, when the S/MIME EnvelopedData of the request contains 366 the "unprotectedAttrs" attribute specifying reuse of the 367 content-encryption-key, the UAS SHOULD encrypt a 368 content-encryption-key with the content-encryption-key that was used 369 in the request, instead of a public key of the UAC. The UAS SHOULD 370 use the S/MIME EnvelopedData to contain the encrypted SDP in the "200 371 OK" response. In addition, the UAS SHOULD set the same proxy server 372 as in the request and the Content-id of the encrypted SDP in the 373 "Proxy-Policy" header. 375 If the UAS encrypted the SDP with a content-encryption-key that was 376 itself encrypted with the content-encryption-key in the request, the 377 proxy server selected by the UAC can view the SDP in the "200 OK" 378 response. 380 Note: In the case when the response does not contain a message 381 body, even if the request contains a message body and was 382 encrypted by using S/MIME EnvelopedData, the UAS does not need to 383 use the S/MIME EnvelopedData. 385 When the UAS receives a request that uses S/MIME, it decrypts and/or 386 validates the S/MIME bodies as usual. 388 When the UAS sends a response for the request without this mechanism 389 and needs end-to-end and end-to-middle confidentiality of the message 390 bodies and/or headers , it uses S/MIME to encrypt them. When the UAC 391 sends a request and needs end-to-end and end-to-middle integrity of 392 the message bodies and/or headers, it uses S/MIME to attach a digital 393 signature. This is the same way the UAC normally performs with this 394 mechanism. 396 4.3 Proxy Behavior 398 When a proxy supporting this mechanism receives a message, the proxy 399 server inspects the "Proxy-Policy" header. If the header includes the 400 processing server's own name, the proxy server inspects the specified 401 Content-ID. 403 When the specified content is S/MIME EnvelopedData, the proxy server 404 inspects it and tries to decrypt the "RecipientInfo" attribute. If 405 the proxy fails to decrypt that, it should cancel the subsequent 406 procedure and respond with a 493 (Undecipherable) response if it is a 407 request, or any existing dialog MAY be terminated. If the proxy 408 succeeds in this decryption, it inspects the "unprotectedAttrs" data 409 of the S/MIME EnvelopedData. If the attribute gives the key's 410 identifier, the proxy must keep the content-encryption-key with its 411 identifier during the dialog. When it receives subsequent messages in 412 the dialog, it tries to decrypt the "KEKRecipientInfo" type of 413 "RecepientInfo" attribute by using this content-encryption-key. 415 When the specified content is S/MIME SignedData, the proxy server 416 inspects it and validates the digital signature. If the verification 417 is unsuccessful, the proxy server should reject the subsequent 418 procedure and respond with a 403 (Forbidden) response if the message 419 is a request, or any existing dialog MAY be terminated. 421 When the proxy server transfers the request, it modifies the routing 422 headers normally. It does not need to modify the S/MIME body. 424 If a proxy does not support this mechanism and receives a message 425 with the "Proxy-Policy" header, the proxy ignores the header and 426 perform as usual. 428 4.4 Summary of Header Field Use 430 The following syntax specification uses the augmented Backus-Naur 431 Form (BNF) as described in RFC-2234 [11]. 433 Proxy-Policy = HCOLON proxy-uri *( SEMI (proxy-policy-param) ) 434 proxy-uri = ( name-addr / addr-spec ) 435 proxy-policy-param = content-id ( SEMI policy ) 436 content-id = "cid" EQUAL cid 437 cid = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 438 dot-atom = atom *( "." atom ) 439 atom = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~" ) 440 policy = "policy" EQUAL ( token ) 442 Information about the use of headers in relation to SIP methods and 443 proxy processing is summarized in Table 1. 445 Header field where proxy ACK BYE CAN INV OPT REG 446 ----------------------------------------------------- 447 Proxy-Policy R adr o o o o o o 448 Proxy-Policy 200-699 adr - o - o o o 449 Proxy-Policy 1xx adr - - - o - - 451 Header field where proxy SUB NOT PRK IFO UPD MSG 452 ----------------------------------------------------- 453 Proxy-Policy R adr o o - o o o 454 Proxy-Policy 200-699 adr o o - o o o 456 Table 1: Summary of header field use 458 The "where" column gives the request and response types in which the 459 header field can be used. The values in the "where" column are as 460 follows: 462 * R: The header field may appear in requests 464 * 200-699: A numeral range indicates response codes with which 465 the header field can be used. 467 * a: A proxy can add or concatenate the header field if it is not 468 present. 470 * r: A proxy must be able to read the header field, and thus it 471 cannot be encrypted. 473 * d: A proxy can delete a header field value. 475 * o: The header field is optional. 477 5. Examples 479 The following examples illustrate the use of the mechanism defined in 480 the previous section. 482 5.1 Request example 484 In the following example, a UA needs the confidentiality of the SDP 485 in INVITE message and the UA allows a proxy server to view the SDP in 486 INVITE request. In addition, the UA needs to protect the policy for 487 the proxy server. In the example encrypted message below, the text 488 boxed in asterisks ("*") is encrypted: 490 INVITE alice@atlanta.example.com --> ss1.atlanta.example.com 492 INVITE sip:bob@biloxi.example.com SIP/2.0 493 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 494 Max-Forwards: 70 495 Route: 496 From: Alice ;tag=9fxced76sl 497 To: Bob 498 Call-ID: 3848276298220188511@atlanta.example.com 499 CSeq: 1 INVITE 500 Contact: 501 Date: Fri, 20 June 2003 13:02:03 GMT 502 Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@atlanta.example.com" 503 Content-Type: multipart/singed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary2 504 Content-Length: 878 506 --boundary1 508 Content-Type: multipart/mixed; boundary=boundary2 509 Content-Length: 568 511 --boundary2 512 Content-Type: message/sipfrag 514 From: Alice ;tag=9fxced76sl 515 To: Bob 516 Call-ID: 3848276298220188511@atlanta.example.com 517 CSeq: 1 INVITE 518 Contact: 519 Date: Fri, 20 June 2003 13:02:03 GMT 520 Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@atlanta.example.com" 522 --boundary2 523 Content-Type: application/pkcs7-mime; smime-type=enveloped-data;name=smime.p7m 524 Content-Transfer-Encoding: base64 525 Content-Disposition: session; filename=smime.p7m;handling=required 526 Content-ID: <2UWQFN309shb3@atlanta.example.com> 527 Content-Length: 231 529 ****************************************************************** 530 * (encryptedContentInfo) * 531 * Content-Type: application/sdp * 532 * Content-Length: 151 * 533 * * 534 * v=0 * 535 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 536 * s=- * 537 * c=IN IP4 192.0.2.101 * 538 * t=0 0 * 539 * m=audio 49172 RTP/AVP 0 * 540 * a=rtpmap:0 PCMU/8000 * 541 * * 542 * (recipientInfos) * 543 * RecepientInfo[0] for ss1.atlanta.example.com public key * 544 * RecepientInfo[1] for bob's public key * 545 * * 546 * (unprotectedAttr) * 547 * CEKReference * 548 ****************************************************************** 550 --boundary2-- 552 --boundary1-- 553 Content-Type: application/pkcs7-signature; name=smime.p7s 554 Content-Transfer-Encoding: base64 555 Content-Disposition: attachment; filename=smime.p7s;handling=required 557 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 558 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 559 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 560 7GhIGfHfYT64VQbnj756 562 --boundary1-- 564 5.2 Response example 566 In the following example, a UA sends a response with this mechanism. 567 In the example encrypted message below, the text boxed in asterisks 568 ("*") is encrypted: 570 200 OK bob@biloxi.example.com --> ss2.biloxi.example.com 572 SIP/2.0 200 OK 573 Via: SIP/2.0/TCP 574 ss2.biloxi.example.com:5060;branch=z9hG4bK721e418c4.1 575 ;received=192.0.2.222 576 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 577 ;received=192.0.2.111 578 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 579 ;received=192.0.2.101 580 Record-Route: , 581 582 From: Alice ;tag=9fxced76sl 583 To: Bob ;tag=314159 584 Call-ID: 3848276298220188511@atlanta.example.com 585 CSeq: 2 INVITE 586 Contact: 588 --boundary41 590 Content-Type: multipart/mixed; boundary=boundary2 591 Content-Length: 468 593 --boundary42 594 Content-Type: message/sipfrag 596 From: Alice ;tag=9fxced76sl 597 To: Bob ;tag=314159 598 Call-ID: 3848276298220188511@atlanta.example.com 599 CSeq: 2 INVITE 600 Contact: 601 Date: Fri, 20 June 2003 13:02:03 GMT 602 Proxy-Policy: ss1.atlanta.example.com; cid="2UWQFN309shb3@biloxi.example.com" 604 --boundary2 605 Content-Type: application/pkcs7-mime; smime-type=enveloped-data;name=smime.p7m 606 Content-Transfer-Encoding: base64 607 Content-Disposition: session; filename=smime.p7m;handling=required 608 Content-ID: <2UWQFN309shb3@biloxi.example.com> 609 Content-Length: 211 611 ****************************************************************** 612 * (encryptedContentInfo) * 613 * Content-Type: application/sdp * 614 * Content-Length: 147 * 615 * * 616 * v=0 * 617 * o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com * 618 * s=- * 619 * c=IN IP4 192.0.2.201 * 620 * t=0 0 * 621 * m=audio 3456 RTP/AVP 0 * 622 * a=rtpmap:0 PCMU/8000 * 623 * * 624 * (recipientInfos) * 625 * RecepientInfo[0] for KEKidentifier * 626 ****************************************************************** 628 --boundary42-- 630 --boundary41-- 631 Content-Type: application/pkcs7-signature; name=smime.p7s 632 Content-Transfer-Encoding: base64 633 Content-Disposition: attachment; filename=smime.p7s;handling=required 635 hhhHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 636 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 637 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 638 7GhIGfHfYT64VQbnj756 640 --boundary41-- 642 6. Security Considerations 644 This specification is about applying S/MIME-secured messages for use 645 in end-to-middle security. It is also applying the CEK reuse method 646 defined in [9]. This requires the same security consideration as 647 those of [4] and [9]. 649 7. IANA Considerations 651 This document requires a new header fields, namely "Proxy-Policy". 653 8. Acknowledgments 655 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 656 this concept, and to Jon Peterson for his helpful comments. 658 References 660 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 661 Levels", RFC 2119, BCP 14, March 1997. 663 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 664 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 665 Session Initiation Protocol", RFC 3261, June 2002. 667 [3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 668 2246, January 1999. 670 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 671 2633, June 1992. 673 [5] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A. 674 and A. Rayhan, "Middlebox communication architecture and 675 framework", RFC 3303, August 2002. 677 [6] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C. 678 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 679 Instant Messaging", RFC 3428, December 2002. 681 [7] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 682 1999. 684 [8] Rosenberg, J., "Requirements for Session Policy for the Session 685 Initiation Protocol (SIP)", 686 draft-rosenberg-sipping-session-policy-req-00 (work in 687 progress), December 2002. 689 [9] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 690 Keys", RFC 3185, October 2001. 692 [10] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 693 November 2002. 695 [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax 696 Specifications: ABNF", RFC 2234, November 1997. 698 Authors' Addresses 700 Kumiko Ono 701 Network Service Systems Laboratories 702 NTT Corporation 703 9-11, Midori-Cho 3-Chome 704 Musashino-shi, Tokyo 180-8585 705 Japan 707 EMail: ono.kumiko@lab.ntt.co.jp 709 Shinya Tachimoto 710 Network Service Systems Laboratories 711 NTT Corporation 712 9-11, Midori-Cho 3-Chome 713 Musashino-shi, Tokyo 180-8585 714 Japan 716 EMail: tachimoto.shinya@lab.ntt.co.jp 718 Intellectual Property Statement 720 The IETF takes no position regarding the validity or scope of any 721 intellectual property or other rights that might be claimed to 722 pertain to the implementation or use of the technology described in 723 this document or the extent to which any license under such rights 724 might or might not be available; neither does it represent that it 725 has made any effort to identify any such rights. Information on the 726 IETF's procedures with respect to rights in standards-track and 727 standards-related documentation can be found in BCP-11. Copies of 728 claims of rights made available for publication and any assurances of 729 licenses to be made available, or the result of an attempt made to 730 obtain a general license or permission for the use of such 731 proprietary rights by implementors or users of this specification can 732 be obtained from the IETF Secretariat. 734 The IETF invites any interested party to bring to its attention any 735 copyrights, patents or patent applications, or other proprietary 736 rights which may cover technology that may be required to practice 737 this standard. Please address the information to the IETF Executive 738 Director. 740 Full Copyright Statement 742 Copyright (C) The Internet Society (2003). All Rights Reserved. 744 This document and translations of it may be copied and furnished to 745 others, and derivative works that comment on or otherwise explain it 746 or assist in its implementation may be prepared, copied, published 747 and distributed, in whole or in part, without restriction of any 748 kind, provided that the above copyright notice and this paragraph are 749 included on all such copies and derivative works. However, this 750 document itself may not be modified in any way, such as by removing 751 the copyright notice or references to the Internet Society or other 752 Internet organizations, except as needed for the purpose of 753 developing Internet standards in which case the procedures for 754 copyrights defined in the Internet Standards process must be 755 followed, or as required to translate it into languages other than 756 English. 758 The limited permissions granted above are perpetual and will not be 759 revoked by the Internet Society or its successors or assignees. 761 This document and the information contained herein is provided on an 762 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 763 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 764 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 765 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 766 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 768 Acknowledgement 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.