idnits 2.17.1 draft-ono-sipping-end2middle-security-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 685. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 407 has weird spacing: '... where pro...' == Line 413 has weird spacing: '... where pro...' -- 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 (February 19, 2005) is 6996 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) -- Looks like a reference, but probably isn't: 'C' on line 281 == Missing Reference: '0' is mentioned on line 486, but not defined == Unused Reference: '12' is defined on line 644, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-04 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-e2m-sec-reqs (ref. '3') ** Obsolete normative reference: RFC 3850 (ref. '4') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 2630 (ref. '5') (Obsoleted by RFC 3369, RFC 3370) -- No information found for draft-ono-sipping-keyreuse-smime - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-09 Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING K. Ono 2 Internet-Draft S. Tachimoto 3 Expires: August 23, 2005 NTT Corporation 4 February 19, 2005 6 End-to-middle Security in the Session Initiation Protocol (SIP) 7 draft-ono-sipping-end2middle-security-04 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 23, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Some services provided by intermediaries depend on the ability to 43 inspect the message bodies in the Session Initiation Protocol (SIP). 44 When sensitive information is included in these bodies, a SIP User 45 Agent (UA) needs to protect it from intermediaries except those that 46 the UA agreed to disclose it to. This document proposes a mechanism 47 for securing information passed between an end user and 48 intermediaries using S/MIME. It also proposes mechanisms for an 49 intermediary to notify the UA about its need to inspect an 50 S/MIME-secured message body, and to notify the need for the message 51 body to be transmitted securely. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [1]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Generating S/MIME-secured message body . . . . . . . . . . . 3 63 2.1 Generating S/MIME CMS EnvelopedData . . . . . . . . . . . . 3 64 2.2 Generating S/MIME CMS SignedData . . . . . . . . . . . . . . 4 65 3. Indicating the Target Content . . . . . . . . . . . . . . . 5 66 4. Notification of the Proxy Server's Policies . . . . . . . . 5 67 5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . 6 68 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Proxy-Required-Body Header Field Use . . . . . . . . . . . . 9 72 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1 Example of Request for End-to-Middle Confidentiality . . . . 10 74 7.2 Example of Request for End-to-Middle Integrity . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . 12 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 77 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 13 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 81 12.2 Informative References . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . 16 85 1. Introduction 87 When a SIP [2] UA requires services provided by intermediaries that 88 depend on the message bodies in request/response messages, end-to-end 89 confidentiality currently has to be disabled. This problem is 90 pointed out in Section 23 of [2]. Since such intermediaries are not 91 always adjacent to the UA, this situation requires security between 92 the UA and the intermediary for the message bodies. We call this 93 "end-to-middle security", where by "end" we mean a UA and by "middle" 94 we mean a specific intermediary, typically a proxy server. 96 This document describes proposed mechanisms for providing data 97 confidentiality and integrity for end-to-middle security to meet the 98 requirements discussed in [3]. Since the major requirement is to 99 have little impact on the standardized end-to-end security 100 mechanisms, the proposed mechanisms are based on S/MIME [4]. The 101 mechanisms consist of generating S/MIME-secured message body and 102 indicating the target message body for a proxy server selected by the 103 UA. In addition, this document includes mechanisms for an 104 intermediary to notify the UA about its need to inspect an 105 S/MIME-secured message body, and to notify that the message body 106 needs to be transmitted securely. 108 2. Generating S/MIME-secured message body 110 2.1 Generating S/MIME CMS EnvelopedData 112 For end-to-middle confidentiality, a UA MUST generate S/MIME CMS [5] 113 EnvelopedData. Before generating it, a UA needs to identify the 114 target proxy servers. The UA MUST obtain their credentials, such as 115 their public key certificates or shared secrets. The structure of 116 the S/MIME CMS EnvelopedData contains encrypted data specified in the 117 "encryptedContentInfo" field and its recipient list specified in the 118 "recipientInfos" field. The encrypted data is encrypted with a 119 content-encryption-key (CEK) and the recipient list contains the CEKs 120 encrypted with different key-encryption-keys (KEKs), one for each 121 recipient. The KEKs are the public keys of each recipient or the 122 shared keys between the UA and each recipient. 124 If the data is encrypted for a selected proxy server, the recipient 125 list contains only the selected proxy server. If the data is 126 encrypted and destined for multiple proxy servers, the recipient list 127 contains the multiple proxy servers. If there is encrypted data 128 destined for each proxy server, the recipient list of each piece of 129 encrypted data contains the targeted proxy server. In order to 130 concatenate multiple pieces of encrypted data, the UAC MUST generate 131 a multipart MIME body. 133 Since proxy servers are prohibited from deleting any body, the 134 encrypted data for the proxy server is transmitted to the user agent 135 server (UAS) but the UAS is not able to decrypt it. In order to 136 avoid causing unnecessary error conditions in the UAS, the user agent 137 client (UAC) MUST set the value "optional" in the handling parameter 138 of the "Content-Disposition" MIME header for the message body. 140 If the multipart MIME body consists of encrypted MIME bodies with the 141 value "optional", the "Content-Disposition" MIME header of the 142 multipart MIME body MUST also contain the value "optional" in the 143 handling parameter. The UAS SHOULD NOT try to decrypt encrypted data 144 that has the value "optional". 146 If the multipart MIME body contains a body with the value "required" 147 and another body with the value "optional", the multipart MIME body 148 SHOULD have the value "required" in the handling parameter of the 149 "Content-Disposition" MIME header. 151 If the encrypted data is meant to be shared with the UAS and selected 152 proxy servers, the recipient list SHOULD be addressed to the UAS and 153 the selected proxy servers. The UAC SHOULD set the value "required" 154 in the handling parameter of the "Content-Disposition" MIME header 155 for the message body. The UAS MUST try to decrypt the encrypted data 156 that has the value "required" in the handling parameter. If the 157 handling parameter is not set, the default behavior is the same as 158 for setting the value "required", as specified in [2]. 160 If a piece of encrypted data is destined for a selected proxy server 161 and another piece of encrypted data for the UAS, the recipient of 162 each piece of encrypted data is each entity respectively. In this 163 case, the UAC MUST generate a multipart MIME body to concatenate the 164 two. 166 For example, a UA uses this mechanism when keying materials, such 167 as keys used for Secure RTP (SRTP), are included in the SDP[9]. 168 One CMS EnvelopedData contains SDP that includes keying materials 169 of an SRTP stream only for the UA. The other CMS EnvelopedData 170 contains an SDP that does not include the keying materials for a 171 selected proxy server that needs to view SDP (i.e., for a firewall 172 traversal service). 174 2.2 Generating S/MIME CMS SignedData 176 For end-to-end data integrity, a UA generates S/MIME CMS SignedData 177 that can be verified by any entity that knows the public key of the 178 UA. For end-to-middle data integrity, a UA MUST generate S/MIME CMS 179 SignedData in the same way as end-to-end data integrity. 181 3. Indicating the Target Content 183 A UA needs a way to indicate content that they expect to be viewed by 184 a proxy server, in order for the proxy server to easily determine 185 whether to process MIME bodies and if so, which one. To meet this 186 requirement, the UAs SHOULD set a label to indicate a selected proxy 187 server and the target content with a new SIP header, 188 "Proxy-Required-Body". This header contains one or more "content-id" 189 parameter(s) for setting the "Content-ID" MIME header into the target 190 body. 192 Note: There were three other options to label a body: a new SIP 193 parameter to an existing SIP header, a new MIME header, or a new 194 parameter to an existing MIME header. 195 1) Using a new parameter to Route header. Since a proxy server 196 views this header when forwarding a request message, it seems to 197 be a reasonable option. However, it cannot work with strict 198 routing. 199 2) Using a new MIME header, "Content-Target", as proposed in a 200 previous version of this draft. Since this option is not 201 necessary as a generic mechanism of MIME, it is not preferred. 202 3) Using a new MIME parameter to "Content-Disposition". The same 203 reason as above. 205 When a UA labels the encrypted data, it SHOULD set the 206 "Proxy-Required-Body" SIP header that contains the address of the 207 server and "content-id" parameter indicating the S/MIME CMS 208 EnvelopedData. When a UA labels the data with signature, it SHOULD 209 set the "Proxy-Required-Body" SIP header that contains the address of 210 the server and "content-id" parameter indicating the S/MIME CMS 211 SignedData. 213 4. Notification of the Proxy Server's Policies 215 A notification mechanism for the proxy server's policies is needed 216 when a UA does not know the policies of the proxy server in a 217 signaling path and the proxy server has its own policies for 218 providing some services which needs the UA's compliance. There are 219 two ways in which a UA can learn the policies of the proxy server. 220 The UA MAY learn them by getting a policy package from a policy 221 server.[10] When a proxy server needs to inspect the message body 222 contained in the response, it needs to learn the policies from a 223 policy server before sending the response. 225 Alternatively, the UA MAY learn them by receiving a response with an 226 error code. When the proxy server receives a request in which it 227 cannot view the message body that has to be read in order to proceed, 228 the proxy server MUST send a response with an error code. If the 229 request contains encrypted data, the error code SHOULD be 493 230 (Undecipherable), accompanied with a proxy's public key certificate 231 and required Content-Type for viewing. The proxy public key 232 certificate is set as an "application/pkix-cert" body. The required 233 Content-Type is set in the Warning header. 235 When the proxy server receives a request that can not be accepted due 236 to its condition, the proxy server MUST also send a response with an 237 error code. If a digital signature is not attached to the request 238 and it required for an integrity check, the error code SHOULD be 495 239 (Signature Required) accompanied with a required Content-Type for the 240 integrity check. The required Content-Type is set in the Warning 241 header. 243 Note: 495 (Signature Required) response is not only generated by a 244 proxy server, but also by the UAS. Using this error code is more 245 explicit than using an existing error code 403, that was described in 246 the last version of this draft. 248 Open Issues: How should the error message indicate the 249 Content-Type to which a signature needs to be attached? Can these 250 Content-Types be nested such as "Content-Type: multipart/mixed" 251 for "Content-Type: application/sdp" and "Content-Type: 252 message/sipfrag"? 253 When proxy servers require both disclosure and an integrity check, 254 how should it be described? 256 When the UAC receives one of the above error codes, it needs to 257 authenticate the proxy server. Therefore, the error code SHOULD 258 contain the digital signature of the proxy server. 260 In the worst scenario, this notification mechanism requires two 261 messages for each proxy server in the signaling path to establish a 262 session between the UAs. In addition, it requires validation 263 procedures using the digital signatures for all proxy servers. Since 264 this causes an increase in the delay before session establishment, it 265 is recommended that a UA learns in advance the policies of as many 266 proxy servers as they can. 268 5. Behavior of UAs and Proxy Servers 270 We describe here an example of the behavior of UAs and proxy servers 271 in a model in which a proxy server that provides a logging service 272 for instant messages exists in a message path as shown in Figure 1. 274 +-----+ +-----+ +-----+ +-----+ 275 | C |-----| C |-----| [C] |-----| C | 276 +-----+ +-----+ +-----+ +-----+ 277 UA #1 Proxy #1 Proxy #2 UA #2 278 w/Logging function 280 C : Content that UA #1 allows the entity to inspect 281 [C]: Content that UA #1 prevents the entity from inspecting 283 Figure 1: Deployment example 285 5.1 UAC Behavior 287 When a UAC sends a MESSAGE [11] request including encrypted message 288 content for end-to-end and end-to-middle confidentiality, it MUST use 289 S/MIME CMS EnvelopedData to encrypt them. In this example, UA #1 is 290 assumed to know the services and the public key of Proxy #1. UA #1 291 MUST use S/MIME CMS EnvelopedData body for UA #2 and Proxy #1. UA #1 292 SHOULD specify the hostname of Proxy #1 and Content-ID of the S/MIME 293 CMS EnvelopedData to be decrypted in the "Proxy-Required-Body" SIP 294 header. 296 When the UAC sends a request and needs both end-to-end and 297 end-to-middle integrity for the message body, it MUST use S/MIME CMS 298 SignedData to attach a digital signature. In this example, UA #1 299 MUST use the CMS SignedData body of the contents. UA #1 SHOULD 300 specify the hostname of Proxy#1 and Content-ID of the CMS SignedData 301 to be validated in the "Proxy-Required-Body" SIP header. 303 When the UAC sends multiple requests to the same UAS, the CEK reuse 304 mechanism is beneficial in letting UAs efficiently encrypt/decrypt 305 data. The CEK reuse mechanism is described in [6][7]. The UAC 306 SHOULD use the "unprotectedAttrs" field to stipulate reuse of the CEK 307 and indicate its identifier. When the UAC reuses the CEK in the 308 previous request as the KEK, it generates CMS EnvelopedData with the 309 type "KEKRecipientInfo" of "RecipientInfo" attribute. 311 5.2 UAS Behavior 313 When a UAS sends a response to the request with this mechanism, the 314 use of the same type of S/MIME CMS data is recommended. For example, 315 if the UAS receives an INVITE request in which the SDP is encrypted 316 by using CMS EnvelopedData body, the response is RECOMMENDED to be a 317 "200 OK" containing the encrypted SDP based on the CMS EnvelopedData 318 body. In the above example, however, the response of the MESSAGE 319 request does not need to use the same type of S/MIME CMS data since 320 the response does not contain the message content. 322 In particular, when the CMS EnvelopedData body of the request 323 contains the "unprotectedAttrs" attribute specifying reuse of the 324 CEK, the UAS SHOULD keep the CEK with the identifier specified in the 325 "unprotectedAttrs" attribute. 327 When the UAS receives a request that uses S/MIME, it decrypts and/or 328 validates the S/MIME bodies as usual. 330 Even when the UAS receives a request without this mechanism, the UAS 331 MAY need end-to-end and end-to-middle confidentiality of the message 332 bodies and/or headers in the response. In this case, the UAS MUST 333 use CMS EnvelopedData to encrypt them. When the UAS sends a response 334 and needs end-to-end and end-to-middle integrity of the message 335 bodies and/or headers, it MUST use CMS SignedData to attach a digital 336 signature. This is no different from how the UAC normally operates 337 with this mechanism. 339 5.3 Proxy Behavior 341 When a proxy server supporting this mechanism receives a message, it 342 MUST inspect the "Proxy-Required-Body" header. If the header 343 includes the processing server's own hostname, the proxy server MUST 344 inspect the specified body in the Content-ID. When the specified 345 body is CMS EnvelopedData, the proxy server MUST inspect it and try 346 to decrypt the "recipientInfos" field. 348 Even if there is the header does not include the server's own name, 349 nor the header exists, the proxy server MAY view a message body. If 350 the UA encrypted data for the proxy, the proxy server will succeed in 351 decryption using the "recipientInfos" field. 353 If the proxy server fails to decrypt that, it SHOULD cancel the 354 subsequent procedure and respond with a 493 (Undecipherable) response 355 if it is a request, otherwise any existing dialog MAY be terminated. 356 If the proxy server succeeds in this decryption, it MUST inspect the 357 "unprotectedAttrs" field of the CMS EnvelopedData body. If the 358 attribute gives the key's identifier, the proxy server MUST keep the 359 CEK with its identifier until the lifetime of the CEK has expired. 360 If it receives subsequent messages within the lifetime, it MUST try 361 to decrypt the type "KEKRecipientInfo" of the "RecipientInfo" 362 attribute by using this CEK. 364 When the specified content is CMS SignedData body, the proxy server 365 MUST inspect it and validate the digital signature. If the 366 verification fails, the proxy server SHOULD reject the subsequent 367 procedure and respond with a 495 (Signature Required) response if the 368 message is a request, otherwise any existing dialog MAY be 369 terminated. 371 When the proxy server forwards the request, it modifies the routing 372 headers normally, but does not modify the message body. The proxy 373 server MAY delete the "Proxy-Required-Body" header that contains own 374 hostname. 376 When a provider operating the proxy server does not allow any 377 information related to its security policies to be revealed to the 378 proxy serving the recipient UA, the proxy server deletes the 379 "Proxy-Required-Body" header. However, when a request message is 380 transmitted to the proxy server via a proxy server operated by 381 another provider, there is no way to conceal the header from the 382 other proxy server. 384 If a proxy does not support this mechanism and receives a message 385 with the "Proxy-Required-Body" header, the proxy MUST ignore the 386 header and operate as usual. 388 6. Proxy-Required-Body Header Field Use 390 The following syntax specification uses the augmented Backus-Naur 391 Form (BNF) as described in RFC-2234 [8]. The new header 392 "Proxy-Required-Body" is defined as a SIP header. 394 Proxy-Required-Body = "Proxy-Required-Body" HCOLON required-proxy 395 SEMI target-body 396 required-proxy = host 397 target-body = cid-param *(COMMA cid-param) 398 cid-param = "cid" EQUAL content-id 399 content-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 400 dot-atom = atom *( "." atom ) 401 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 402 "_" / "+" / "'" / "`" / "~" ) 404 Information about the use of headers in relation to SIP methods and 405 proxy processing is summarized in Table 1. 407 Header field where proxy ACK BYE CAN INV OPT REG 408 -------------------------------------------------------------- 409 Proxy-Required-Body R adr - o - o o o 410 Proxy-Required-Body 200-699 adr - o - o o o 411 Proxy-Required-Body 1xx adr - - - o - - 413 Header field where proxy SUB NOT PRK IFO UPD MSG 414 -------------------------------------------------------------- 415 Proxy-Required-Body R adr o o - o o o 416 Proxy-Required-Body 200-699 adr o o - o o o 418 Table 1: Summary of header field use 419 The "where" column gives the request and response types in which 420 the header field can be used. The values in the "where" column 421 are as follows: 422 * R: The header field may appear in requests 423 * 200-699: A numeral range indicates response codes with which 424 the header field can be used. 425 The "proxy" column gives the operations a proxy may perform on the 426 header field: 427 * a: A proxy can add or concatenate the header field if it is not 428 present. 429 * r: A proxy must be able to read the header field, so it cannot 430 be encrypted. 431 * d: A proxy can delete a header field value. 432 The next six columns relate to the presence of a header field in a 433 method: 434 * o: The header field is optional. 435 * -: The header field is not applicable. 437 7. Examples 439 The following examples illustrate the use of the mechanism defined in 440 the previous section. 442 7.1 Example of Request for End-to-Middle Confidentiality 444 In the following example, a UA needs the message content in a MESSAGE 445 request to be confidential and it allows a selected proxy server to 446 view the message content. It also needs to protect the label of the 447 target content. In addition, it needs to reuse the CEK in the 448 subsequent request messages. In the example encrypted message below, 449 the text with the box of asterisks ("*") is encrypted: 451 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 453 MESSAGE sip:bob@biloxi.example.com SIP/2.0 454 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 455 Max-Forwards: 70 456 Route: 457 From: Alice ;tag=9fxced76sl 458 To: Bob 459 Call-ID: 3848276298220188511@atlanta.example.com 460 CSeq: 1 MESSAGE 461 Date: Fri, 20 June 2003 13:02:03 GMT 462 Proxy-Required-Body: ss1.atlanta.example.com; 463 cid=1234@atlanta.example.com 464 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 465 micalg=sha1;boundary=boundary1 467 Content-Length: ... 469 --boundary1 470 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 471 name=smime.p7m 472 Content-Transfer-Encoding: binary 473 Content-ID: 1234@atlanta.example.com 474 Content-Disposition: attachment;filename=smime.p7m;handling=required 475 Content-Length: ... 477 ****************************************************************** 478 * (encryptedContentInfo) * 479 * Content-Type: text/plain * 480 * Content-Length: ... * 481 * * 482 * Hello. * 483 * This is confidential. * 484 * * 485 * (recipientInfos) * 486 * RecipientInfo[0] for ss1.atlanta.example.com public key * 487 * RecipientInfo[1] for Bob's public key * 488 * * 489 * (unprotectedAttrs) * 490 * CEKReference * 491 ****************************************************************** 492 --boundary1-- 493 Content-Type: application/pkcs7-signature; name=smime.p7s 494 Content-Transfer-Encoding: binary 495 Content-Disposition: attachment; 496 filename=smime.p7s;handling=required 498 [binary data] 499 --boundary1-- 501 7.2 Example of Request for End-to-Middle Integrity 503 In the following example, a UA needs the integrity of the message 504 content in a MESSAGE request to be validated by a selected proxy 505 server before it views the message content. It also needs to protect 506 the label of the target content. 508 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 510 MESSAGE sip:bob@biloxi.example.com SIP/2.0 511 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 512 Max-Forwards: 70 513 Route: 514 From: Alice ;tag=9fxced76sl 515 To: Bob 516 Call-ID: 3848276298220188511@atlanta.example.com 517 CSeq: 1 MESSAGE 518 Date: Fri, 20 June 2003 13:02:03 GMT 519 Proxy-Required-Body: ss1.atlanta.example.com; 520 cid=1234@atlanta.example.com 521 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 522 micalg=sha1;boundary=boundary1 523 Content-Length: ... 525 --boundary1 526 Content-Type: text/plain 527 Content-Length: ... 529 Hello. 530 This is protected with the signature. 531 --boundary1-- 532 Content-Type: application/pkcs7-signature; name=smime.p7s 533 Content-Transfer-Encoding: binary 534 Content-ID:1234@atlanta.example.com 535 Content-Disposition: attachment; 536 filename=smime.p7s;handling=required 538 [binary data] 539 --boundary1-- 541 8. Security Considerations 543 This document describes a mechanism to encrypt data for multiple 544 recipients, such as multiple proxy servers, or the recipient UA and 545 proxy servers. This means that the encrypted data is decipherable at 546 a previous hop and it may be modified by an entity at the previous 547 hop. Therefore, the UA SHOULD protect the data integrity before 548 encryption, when the encrypted data is meant to be shared with 549 multiple proxy servers, or to be shared with the UAS and selected 550 proxy servers. The UA SHOULD generate S/MIME CMS SignedData and then 551 SHOULD generate the EnvelopedData to encrypt attached data with a 552 digital signature. The recipient entity SHOULD verify the signature 553 to see if the encrypted data has been modified after decryption at 554 another entity on the recipient list. 556 This document also describes a new SIP header for labeling a message 557 body for a proxy server. If a malicious user or proxy server 558 modified/added/deleted the label, the specified message body will not 559 be inspected by the specified proxy server, and then some service 560 using its content can not be served. Or a proxy server will do 561 unnecessary processing on message bodies such as unpacking MIME 562 structure, and/or signature verification. This causes a 563 Denial-of-Services attack to a proxy server. 565 To prevent such attacks, protection of the label integrity is needed. 566 UAs and proxy servers SHOULD use TLS mechanism to communicate each 567 other. A proxy server trusted to provide SIP routing is basically 568 trusted to process SIP headers other than those related to routing. 569 Therefore, hop-by-hop security is reasonable for the protection. Of 570 course, UAs MAY generate a "message/sipfrag" body and attach a 571 digital signature for the whole body in order to protect the label 572 integrity. 574 9. IANA Considerations 576 This document requires a new "Proxy-Required-Body" SIP header. 578 10. Open Issues 579 o How should the error message indicate the Content-Type to which a 580 signature needs to be attached? Can these Content-Types be nested 581 such as "Content-Type: multipart/mixed" for 582 "Content-Type:application/sdp" and "Content-Type: 583 message/sipfrag"? 584 o When proxy servers require both disclosure and an integrity check, 585 how should it be described? 586 o If the label of the target body has a wrong value, what should we 587 do? 403 (Forbidden) response? 588 o Do we need to add text about CMS AuthenticationData for the 589 integrity protection? 590 o Do we need to add text about the reason we don't have to define a 591 new option-tag? 593 11. Acknowledgments 595 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 596 this concept and to many people for useful comments, especially Jon 597 Peterson, Jonathan Rosenberg, Eric Burger. 599 12. References 601 12.1 Normative References 603 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 604 Levels", RFC 2119, BCP 14, March 1997. 606 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 607 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 608 Session Initiation Protocol", RFC 3261, June 2002. 610 [3] Ono, K. and S. Tachimoto, "Requirements for end-to-middle 611 security in the Session Initiation Protocol (SIP)", 612 Internet-Draft draft-ietf-sipping-e2m-sec-reqs-04, October 2004. 614 [4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 615 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. 617 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 618 1999. 620 [6] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 621 Keys", RFC 3185, October 2001. 623 [7] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP", 624 Internet-Draft draft-ono-sipping-keyreuse-smime-00, February 625 2004. 627 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 628 Specifications: ABNF", RFC 2234, November 1997. 630 12.2 Informative References 632 [9] Andreasen, F., Baugher, M. and D. Wing, "Session Description 633 Protocol Security Descriptions for Media Streams", 634 Internet-Draft draft-ietf-mmusic-sdescriptions-09, February 635 2005. 637 [10] Hilt, V., Camarillo, G. and J. Rosenberg, "Profile Data for 638 Session Initiation Protocol (SIP) Policies", September 2003. 640 [11] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C. 641 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 642 Instant Messaging", RFC 3428, December 2002. 644 [12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 645 November 2002. 647 Authors' Addresses 649 Kumiko Ono 650 Network Service Systems Laboratories, NTT Corporation 651 Musashino-shi, Tokyo 180-8585 652 Japan 654 Email: ono.kumiko@lab.ntt.co.jp 656 Shinya Tachimoto 657 Network Service Systems Laboratories, NTT Corporation 658 Musashino-shi, Tokyo 180-8585 659 Japan 661 Email: tachimoto.shinya@lab.ntt.co.jp 663 Intellectual Property Statement 665 The IETF takes no position regarding the validity or scope of any 666 Intellectual Property Rights or other rights that might be claimed to 667 pertain to the implementation or use of the technology described in 668 this document or the extent to which any license under such rights 669 might or might not be available; nor does it represent that it has 670 made any independent effort to identify any such rights. Information 671 on the procedures with respect to rights in RFC documents can be 672 found in BCP 78 and BCP 79. 674 Copies of IPR disclosures made to the IETF Secretariat and any 675 assurances of licenses to be made available, or the result of an 676 attempt made to obtain a general license or permission for the use of 677 such proprietary rights by implementers or users of this 678 specification can be obtained from the IETF on-line IPR repository at 679 http://www.ietf.org/ipr. 681 The IETF invites any interested party to bring to its attention any 682 copyrights, patents or patent applications, or other proprietary 683 rights that may cover technology that may be required to implement 684 this standard. Please address the information to the IETF at 685 ietf-ipr@ietf.org. 687 Disclaimer of Validity 689 This document and the information contained herein are provided on an 690 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 691 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 692 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 693 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 694 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 697 Copyright Statement 699 Copyright (C) The Internet Society (2005). This document is subject 700 to the rights, licenses and restrictions contained in BCP 78, and 701 except as set forth therein, the authors retain all their rights. 703 Acknowledgment 705 Funding for the RFC Editor function is currently provided by the 706 Internet Society.