idnits 2.17.1 draft-ono-sipping-end2middle-security-03.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 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 662. ** 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 5 instances of too long lines in the document, the longest one being 15 characters 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 422 has weird spacing: '... where prox...' == Line 424 has weird spacing: '... adr o ...' == Line 428 has weird spacing: '... where prox...' == Line 430 has weird spacing: '... adr o ...' == Line 431 has weird spacing: '...99 adr o ...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If a UA already knows that a selected proxy server needs to inspect a message body, the UA MAY NOT set such label. The proxy server MAY view a message body independently of the label, in order to inspect the target body using "recipientinfo" in CMS EnvelopedData or "Content-Type" MIME header. -- 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 (October 22, 2004) is 7124 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 496, but not defined == 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 2633 (ref. '4') (Obsoleted by RFC 3851) ** 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-03 Summary: 10 errors (**), 0 flaws (~~), 11 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: April 22, 2005 NTT Corporation 4 October 22, 2004 6 End-to-middle Security in the Session Initiation Protocol (SIP) 7 draft-ono-sipping-end2middle-security-03 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 April 22, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 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 all intermediaries except for 46 certain selected ones. This document proposes a mechanism for 47 securing information passed between an end user and a selected 48 intermediary using S/MIME. It also proposes mechanisms for notifying 49 the UA that an intermediary needs to inspect an S/MIME-secured 50 message body, and that the message body needs to be transmitted 51 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 . . . . . . . . 6 67 5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . 7 68 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . 12 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 80 11.2 Informative References . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . 15 84 1. Introduction 86 When a SIP [2] UA requires services provided by intermediaries that 87 depend on the message bodies in request/response messages, end-to-end 88 confidentiality will currently have to be disabled. This problem is 89 pointed out in Section 23 of [2]. Since such an intermediary is not 90 always adjacent to the UA, this situation requires security between 91 the UA and the intermediary for the message bodies. We call this 92 "end-to-middle security", where by "end" we mean a UA and by "middle" 93 we mean a specific intermediary, typically a proxy server. 95 This document describes proposed mechanisms for providing data 96 confidentiality and integrity for end-to-middle security to meet the 97 requirements discussed in [3]. Since the major requirement is to 98 have little impact on the standardized end-to-end security 99 mechanisms, the proposed mechanisms are based on S/MIME [4]. The 100 mechanisms consist of generating S/MIME-secured message body and 101 indicating the target message body for a selected proxy server. In 102 addition, it also includes mechanisms for notifying the UA that an 103 intermediary needs to inspect an S/MIME-secured message body, and 104 that the message body needs to be transmitted securely. 106 2. Generating S/MIME-secured message body 108 2.1 Generating S/MIME CMS EnvelopedData 110 For end-to-middle confidentiality, a UA MUST generate S/MIME CMS [5] 111 EnvelopedData, whose recipient list is specified in the 112 "recipientInfos" field. The structure of the S/MIME CMS 113 EnvelopedData contains data encrypted with a content-encryption-key 114 (CEK) and the CEK encrypted with different key-encryption-keys 115 (KEKs), one for each recipient as specified in [5]. The KEKs are the 116 public keys of each recipient or the shared keys between the UA and 117 each recipient. 119 If the data is encrypted only for a selected proxy server, the 120 recipient list contains only the proxy server. If there is encrypted 121 data destined for multiple proxy servers, the recipient list contains 122 the targeted proxy servers. If there is encrypted data destined for 123 each proxy server, the recipient list of each piece of encrypted data 124 contains the targeted proxy server. In order to concatenate multiple 125 pieces of encrypted data, the UAC MUST generate a multipart MIME 126 body. 128 Since proxy servers are prohibited from deleting any body, the 129 encrypted data for the proxy server is transmitted to the user agent 130 server (UAS) but the UAS will be unable to decrypt it. In order to 131 avoid causing unnecessary error conditions in the UAS, the user agent 132 client (UAC) MUST set the value "optional" in the handling parameter 133 of the "Content-Disposition" MIME header for the message body. 135 If the multipart MIME body consists of encrypted MIME bodies with the 136 value "optional", the "Content-Disposition" MIME header of the 137 multipart MIME body MUST also contain the value "optional" in the 138 handling parameter. The UAS SHOULD NOT try to decrypt encrypted data 139 that has the value "optional". 141 If the multipart MIME body contains a body with the value "required" 142 and another body with the value "optional", the multipart MIME body 143 SHOULD have the value "required" in the handling parameter of the 144 "Content-Disposition" MIME header. 146 If the encrypted data is meant to be shared with the UAS and selected 147 proxy servers, the recipient list SHOULD be addressed to the UAS and 148 the selected proxy servers. The UAC SHOULD set the value "required" 149 in the handling parameter of the "Content-Disposition" MIME header 150 for the message body. The UAS MUST try to decrypt the encrypted data 151 that has the value "required" in the handling parameter. If the 152 handling parameter is not set, the default behavior is the same as 153 for setting the value "required", as specified in [2]. 155 If a piece of encrypted data is destined for a selected proxy server 156 and another piece of encrypted data for the UAS, the recipient of 157 each piece of encrypted data is each respective entity. In this 158 case, the UAC MUST generate a multipart MIME body to concatenate the 159 two. 161 For example, a UA uses this mechanism when keying materials, such 162 as keys for use by Secure RTP (SRTP), are included in the SDP[9]. 163 One CMS EnvelopedData contains SDP that includes keying materials 164 of an SRTP stream only for the UA. The other CMS EnvelopedData 165 contains an SDP that does not include the keying materials of the 166 SRTP stream only for a selected proxy server that needs to view 167 SDP (i.e., for a firewall traversal service). 169 2.2 Generating S/MIME CMS SignedData 171 For end-to-end data integrity, a UA generates S/MIME CMS SignedData 172 that can be verified by any entity that knows the public key of the 173 UA. For end-to-middle data integrity, a UA MUST generate S/MIME CMS 174 SignedData in the same way as for end-to-end data integrity. 176 Note: Even if the handling parameter of the signature of the whole 177 message body is set to the value "optional", the UAS SHOULD 178 validate the signature of the whole message body since the 179 "Content-Disposition" might be modified by a malicious entity. 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. This document defines a new SIP 188 header, "Proxy-Required-Body", for the label. 190 Open Issue: There are four options for the label: a new SIP 191 header, a new parameter of an existing SIP header, a new MIME 192 header, or a new parameter for an existing MIME header. 194 1) Using a new SIP header, "Proxy-Required-Body", to indicate the 195 selected proxy server and the target body. The new SIP header 196 contains one or more "content-id" parameter(s) for setting the 197 "Content-ID" MIME header into the target body. When a message has 198 no target body destined for a proxy server, it is easier for this 199 option to determine that fact, as this only needs to look at the 200 SIP header. 201 To protect the integrity of the label in the SIP headers, UAs need 202 to generate an application/sipfrag body and attach a digital 203 signature for the whole body to protect the data integrity of the 204 label. Generating the application/sipfrag body would required an 205 additional multipart MIME structure. The validation cost for 206 integrity protection of these headers reduces the merit of using a 207 new SIP header. 208 2) Using a new parameter of the Route header, "content-id". Since 209 a proxy server is allowed to modify the Route header, there is no 210 way to protect the data integrity of the label against other proxy 211 servers along the signaling path. 212 3) Using a new MIME header, "Content-Target", as described in the 213 last version of this draft. When a message has a target body 214 destined for a proxy server, this shows better performance than 215 using a SIP header in searching the target body. This requires 216 only the inspection of the MIME header, while using a SIP header 217 requires the inspection of the SIP header "Content-ID" MIME 218 header. All that the UA needs to do to protect the integrity of 219 the label is to attach a digital signature for the whole body. 220 This is simpler than using a SIP header. 221 4) Using a new parameter of "Content-Disposition" MIME header, 222 "required-entity". This MIME header is ambiguous to indicate the 223 target entity. 225 When a UA labels the encrypted data, it SHOULD set the 226 "Proxy-Required-Body" SIP header that contains the address of the 227 server and "content-id" parameter indicating the S/MIME CMS 228 EnvelopedData. When a UA labels the data with signature, it SHOULD 229 set the "Proxy-Required-Body" SIP header that contains the address of 230 the server and "content-id" parameter indicating the S/MIME CMS 231 SignedData. When a proxy server receives a message, it SHOULD 232 inspect the "Proxy-Required-Body" SIP headers. 234 A UA SHOULD generate a digital signature of the whole message body 235 including an application/sipfrag body that contains the new SIP 236 header in order to protect the integrity of the label. The proxy 237 server SHOULD validate the signature of the whole message body to 238 check the integrity of the indication, even when the "content-id" 239 parameter contained in the "Proxy-Required-Body" SIP header is not 240 set for the whole message body. 242 Open Issue: Should the target proxy server remove the label before 243 forwarding the message? 245 If a UA already knows that a selected proxy server needs to inspect a 246 message body, the UA MAY NOT set such label. The proxy server MAY 247 view a message body independently of the label, in order to inspect 248 the target body using "recipientinfo" in CMS EnvelopedData or 249 "Content-Type" MIME header. 251 4. Notification of the Proxy Server's Policies 253 A notification mechanism for the proxy server's policies is needed 254 when a UA does not know the policies of the proxy server in a 255 signaling path and the proxy server has its own policies for 256 providing some services. There are two ways in which a UA can learn 257 the policies of the proxy server. The UA MAY learn them by getting a 258 policy package from a policy server[10]. When a proxy server needs 259 to inspect the message body contained in the response, it needs to 260 learn the policies from a policy server before sending the response. 261 Alternatively, the UA MAY learn them by receiving a response with an 262 error code. 264 When the proxy server receives a request in which it cannot view the 265 message body that has to be read in order to proceed, the proxy 266 server MUST send a response with an error code. If the request 267 contains encrypted data, the error code SHOULD be 493 268 (Undecipherable), accompanied by a proxy's public key certificate and 269 required Content-Type. 271 When the proxy server receives a request whose sending condition 272 cannot be accepted, the proxy server MUST also send a response with 273 an error code. If a digital signature is not attached to the request 274 and it required for an integrity check, the error code SHOULD be 403 275 (Forbidden) accompanied by a required Content-Type that is 276 "multipart/signed". 278 Open Issues: 279 Is it better to define a new error code for requiring a 280 signature attachment? 281 How should the error message indicate the Content-Type to which 282 a signature needs to be attached? Can these Content-Types be 283 nested such as "Content-Type: multipart/signed" for 284 "Content-Type: application/sdp"? 285 When proxy servers require both disclosure and an integrity 286 check, how should it be described? 288 When the UAC receives one of the above error codes, it needs to 289 authenticate the proxy server. Therefore, the error code SHOULD 290 contain the digital signature of the proxy server. 292 In the worst case, this notification mechanism requires two messages 293 for each proxy server in the signaling path to establish a session 294 between the UAs. In addition, it requires validation procedures 295 using the digital signatures for all proxy servers. Since this 296 causes an increase in the delay before session establishment, it is 297 recommended that a UA learns in advance the policies of as many proxy 298 servers as they can. 300 5. Behavior of UAs and Proxy Servers 302 We describe here an example of the behavior of UAs and proxy servers 303 in a model in which a proxy server that provides a logging service 304 for instant messages exists in a message path as shown in Figure 1. 306 +-----+ +-----+ +-----+ +-----+ 307 | C |-----| C |-----| * |-----| C | 308 +-----+ +-----+ +-----+ +-----+ 309 UA #1 Proxy #1 Proxy #2 UA #2 310 w/Logging function 312 C: Content that UA #1 allows the entity to inspect 313 *: Content that UA #1 prevents the entity from inspecting 315 Figure 1: Deployment example 317 5.1 UAC Behavior 319 When a UAC sends a MESSAGE [11] request including encrypted message 320 content for end-to-end and end-to-middle confidentiality, it MUST use 321 S/MIME CMS EnvelopedData to encrypt them. In this example, UA #1 is 322 assumed to know the services and the public key of Proxy #1. UA #1 323 MUST use S/MIME CMS EnvelopedData body for UA #2 and Proxy #1. UA #1 324 SHOULD specify the hostname of Proxy #1 and Content-ID of the S/MIME 325 CMS EnvelopedData to be decrypted in the "Proxy-Required-Body" SIP 326 header. 328 When the UAC sends a request and needs end-to-end and end-to-middle 329 integrity for the message body, it MUST use S/MIME CMS SignedData to 330 attach a digital signature. In this example, UA #1 MUST use the CMS 331 SignedData body of the contents. UA #1 SHOULD specify the hostname 332 of Proxy#1 and Content-ID of the CMS SignedData to be validated in 333 the "Proxy-Required-Body" SIP header. 335 When the UAC sends multiple requests to the same UAS, the CEK reuse 336 mechanism is beneficial in letting UAs efficiently encrypt/decrypt 337 data. The CEK reuse mechanism is described in [6][7]. The UAC 338 SHOULD use the "unprotectedAttrs" field to stipulate reuse of the CEK 339 and indicate its identifier. When the UAC reuses the CEK in the 340 previous request as the KEK, it generates CMS EnvelopedData with the 341 type "KEKRecipientInfo" of "RecipientInfo" attribute. 343 5.2 UAS Behavior 345 When a UAS sends a response to the request with this mechanism, the 346 use of the same type of S/MIME CMS data is recommended. For example, 347 if the UAS receives an INVITE request in which the SDP is encrypted 348 by using CMS EnvelopedData, the response is RECOMMENDED to be a "200 349 OK" containing the encrypted SDP based on the CMS EnvelopedData. In 350 the above example, however, the response of the MESSAGE request does 351 not need to use the same type of S/MIME CMS data since the response 352 does not contain the message content. 354 In particular, when the CMS EnvelopedData body of the request 355 contains the "unprotectedAttrs" attribute specifying reuse of the 356 CEK, the UAS SHOULD keep the CEK with the identifier specified in the 357 "unprotectedAttrs" attribute. 359 When the UAS receives a request that uses S/MIME, it decrypts and/or 360 validates the S/MIME bodies as usual. 362 Even when the UAS receives a request without this mechanism, the UAS 363 may need end-to-end and end-to-middle confidentiality of the message 364 bodies and/or headers in the response. In this case, the UAS MUST 365 use CMS EnvelopedData to encrypt them. When the UAS sends a response 366 and needs end-to-end and end-to-middle integrity of the message 367 bodies and/or headers, it MUST use CMS SignedData to attach a digital 368 signature. This is the same way in which the UAC normally operates 369 with this mechanism. 371 5.3 Proxy Behavior 373 When a proxy server supporting this mechanism receives a message, it 374 MUST inspect the "Proxy-Required-Body" SIP header. If the SIP header 375 includes the processing server's own hostname, the proxy server MUST 376 inspect the specified body in the "content-id" parameter. 378 When the specified body is CMS EnvelopedData, the proxy server MUST 379 inspect it and try to decrypt the "recipientInfos" field. If the 380 proxy server fails to decrypt that, it SHOULD cancel the subsequent 381 procedure and respond with a 493 (Undecipherable) response if it is a 382 request, otherwise any existing dialog MAY be terminated. If the 383 proxy server succeeds in this decryption, it MUST inspect the 384 "unprotectedAttrs" field of the CMS EnvelopedData body. If the 385 attribute gives the key's identifier, the proxy server MUST keep the 386 CEK with its identifier until the lifetime of the CEK has expired. 387 If it receives subsequent messages within the lifetime, it MUST try 388 to decrypt the type "KEKRecipientInfo" of the "RecipientInfo" 389 attribute by using this CEK. 391 When the specified content is CMS SignedData, the proxy server MUST 392 inspect it and validate the digital signature. If the verification 393 fails, the proxy server SHOULD reject the subsequent procedure and 394 respond with a 403 (Forbidden) response if the message is a request, 395 otherwise any existing dialog MAY be terminated. 397 When the proxy server forwards the request, it modifies the routing 398 headers normally. It does not need to modify the message body. 400 If a proxy does not support this mechanism and receives a message 401 with the "Proxy-Required-Body" SIP header, the proxy MUST ignore the 402 header and operate as usual. 404 6. Proxy-Required-Body Header Field Use 406 The following syntax specification uses the augmented Backus-Naur 407 Form (BNF) as described in RFC-2234 [8]. The new header 408 "Proxy-Required-Body" is defined as a SIP header. 410 Proxy-Required-Body = "Proxy-Required-Body" HCOLON required-proxy SEMI target-body 411 required-proxy = host 412 target-body = cid-param *(COMMA cid-param) 413 cid-param = "cid" EQUAL content-id 414 content-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 415 dot-atom = atom *( "." atom ) 416 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 417 "_" / "+" / "'" / "`" / "~" ) 419 Information about the use of headers in relation to SIP methods and 420 proxy processing is summarized in Table 1. 422 Header field where proxy ACK BYE CAN INV OPT REG 423 ------------------------------------------------------------------ 424 Proxy-Required-Body R adr o o o o o o 425 Proxy-Required-Body 200-699 adr - o - o o o 426 Proxy-Required-Body 1xx adr - - - o - - 428 Header field where proxy SUB NOT PRK IFO UPD MSG 429 ----------------------------------------------------------------- 430 Proxy-Required-Body R adr o o - o o o 431 Proxy-Required-Body 200-699 adr o o - o o o 433 Table 1: Summary of header field use 435 The "where" column gives the request and response types in which the 436 header field can be used. The values in the "where" column are as 437 follows: 438 * R: The header field may appear in requests 439 * 200-699: A numeral range indicates response codes with which 440 the header field can be used. 441 * a: A proxy can add or concatenate the header field if it is not 442 present. 443 * r: A proxy must be able to read the header field, so it cannot 444 be encrypted. 445 * d: A proxy can delete a header field value. 446 * o: The header field is optional. 448 7. Examples 450 The following examples illustrate the use of the mechanism defined in 451 the previous section. 453 7.1 Example of Request for End-to-Middle Confidentiality 455 In the following example, a UA needs the message content in a MESSAGE 456 request to be confidential and it allows a selected proxy server to 457 view the message content. It also needs to protect the label of the 458 target content. In addition, it needs to reuse the CEK in the 459 subsequent request messages. In the example encrypted message below, 460 the text with the box of asterisks ("*") is encrypted: 462 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 464 MESSAGE sip:bob@biloxi.example.com SIP/2.0 465 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 466 Max-Forwards: 70 467 Route: 468 From: Alice ;tag=9fxced76sl 469 To: Bob 470 Call-ID: 3848276298220188511@atlanta.example.com 471 CSeq: 1 MESSAGE 472 Date: Fri, 20 June 2003 13:02:03 GMT 473 Proxy-Required-Body: ss1.atlanta.example.com;cid=1234@atlanta.example.com 474 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 475 micalg=sha1;boundary=boundary1 476 Content-Length: ... 478 --boundary1 480 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 481 name=smime.p7m 482 Content-Transfer-Encoding: binary 483 Content-ID: 1234@atlanta.example.com 484 Content-Disposition: attachment;filename=smime.p7m;handling=required 485 Content-Length: ... 487 ****************************************************************** 488 * (encryptedContentInfo) * 489 * Content-Type: text/plain * 490 * Content-Length: ... * 491 * * 492 * Hello. * 493 * This is confidential. * 494 * * 495 * (recipientInfos) * 496 * RecipientInfo[0] for ss1.atlanta.example.com public key * 497 * RecipientInfo[1] for Bob's public key * 498 * * 499 * (unprotectedAttrs) * 500 * CEKReference * 501 ****************************************************************** 503 --boundary1-- 504 Content-Type: application/pkcs7-signature; name=smime.p7s 505 Content-Transfer-Encoding: binary 506 Content-Disposition: attachment; 507 filename=smime.p7s;handling=required 509 [ binary data ] 511 --boundary1-- 513 7.2 Example of Request for End-to-Middle Integrity 515 In the following example, a UA needs the integrity of the message 516 content in a MESSAGE request to be validated by a selected proxy 517 server before it views the message content. It also needs to protect 518 the label of the target content. 520 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 522 MESSAGE sip:bob@biloxi.example.com SIP/2.0 523 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 524 Max-Forwards: 70 525 Route: 526 From: Alice ;tag=9fxced76sl 527 To: Bob 528 Call-ID: 3848276298220188511@atlanta.example.com 529 CSeq: 1 MESSAGE 530 Date: Fri, 20 June 2003 13:02:03 GMT 531 Proxy-Required-Body: ss1.atlanta.example.com;cid=1234@atlanta.example.com 532 Content-Type: multipart/signed;protocol="application/pkcs7-signature"; 533 micalg=sha1;boundary=boundary1 534 Content-Length: ... 536 --boundary1 538 Content-Type: text/plain 539 Content-Length: ... 541 Hello. 542 This is protected with the signature. 544 --boundary1-- 545 Content-Type: application/pkcs7-signature; name=smime.p7s 546 Content-Transfer-Encoding: binary 547 Content-ID:1234@atlanta.example.com 548 Content-Disposition: attachment;filename=smime.p7s;handling=required 550 [ binary data ] 552 --boundary1-- 554 8. Security Considerations 556 This proposal allows a UA to encrypt data for multiple recipients, 557 such as multiple proxy servers, or the UAS and proxy servers. When a 558 proxy server or the UAS receives an encrypted data, the encrypted 559 data may be decrypted an modified at another entity on the recipient 560 list. If the encrypted data is meant to be shared with multiple 561 recipients, the UAC SHOULD generate S/MIME CMS SignedData for each 562 piece of data before encryption or for the whole message body. 564 9. IANA Considerations 566 This document requires a new "Proxy-Required-Body" SIP header. 568 10. Acknowledgments 570 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 571 this concept and to many people for useful comments, especially Jon 572 Peterson, Jonathan Rosenberg, Eric Burger. 574 11. References 576 11.1 Normative References 578 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 579 Levels", RFC 2119, BCP 14, March 1997. 581 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 582 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 583 Session Initiation Protocol", RFC 3261, June 2002. 585 [3] Ono, K. and S. Tachimoto, "Requirements for end-to-middle 586 security in the Session Initiation Protocol (SIP)", 587 draft-ietf-sipping-e2m-sec-reqs-04 (work in progress), October 588 2004. 590 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 591 2633, June 1992. 593 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 594 1999. 596 [6] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 597 Keys", RFC 3185, October 2001. 599 [7] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP", 600 draft-ono-sipping-keyreuse-smime-00 (work in progress), 601 February 2004. 603 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 604 Specifications: ABNF", RFC 2234, November 1997. 606 11.2 Informative References 608 [9] Andreasen, F., Baugher, M. and D. Wing, "Session Description 609 Protocol Security Descriptions for Media Streams", 610 draft-ietf-mmusic-sdescriptions-03.txt (work in progress), 611 February 2004. 613 [10] Hilt, V., Camarillo, G. and J. Rosenberg, "Profile Data for 614 Session Initiation Protocol (SIP) Policies", September 2003. 616 [11] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C. 617 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 618 Instant Messaging", RFC 3428, December 2002. 620 Authors' Addresses 622 Kumiko Ono 623 Network Service Systems Laboratories 624 NTT Corporation 625 9-11, Midori-Cho 3-Chome 626 Musashino-shi, Tokyo 180-8585 627 Japan 629 EMail: ono.kumiko@lab.ntt.co.jp 631 Shinya Tachimoto 632 Network Service Systems Laboratories 633 NTT Corporation 634 9-11, Midori-Cho 3-Chome 635 Musashino-shi, Tokyo 180-8585 636 Japan 638 EMail: tachimoto.shinya@lab.ntt.co.jp 640 Intellectual Property Statement 642 The IETF takes no position regarding the validity or scope of any 643 Intellectual Property Rights or other rights that might be claimed to 644 pertain to the implementation or use of the technology described in 645 this document or the extent to which any license under such rights 646 might or might not be available; nor does it represent that it has 647 made any independent effort to identify any such rights. Information 648 on the procedures with respect to rights in RFC documents can be 649 found in BCP 78 and BCP 79. 651 Copies of IPR disclosures made to the IETF Secretariat and any 652 assurances of licenses to be made available, or the result of an 653 attempt made to obtain a general license or permission for the use of 654 such proprietary rights by implementers or users of this 655 specification can be obtained from the IETF on-line IPR repository at 656 http://www.ietf.org/ipr. 658 The IETF invites any interested party to bring to its attention any 659 copyrights, patents or patent applications, or other proprietary 660 rights that may cover technology that may be required to implement 661 this standard. Please address the information to the IETF at 662 ietf-ipr@ietf.org. 664 Disclaimer of Validity 666 This document and the information contained herein are provided on an 667 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 668 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 669 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 670 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 671 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 672 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 674 Copyright Statement 676 Copyright (C) The Internet Society (2004). This document is subject 677 to the rights, licenses and restrictions contained in BCP 78, and 678 except as set forth therein, the authors retain all their rights. 680 Acknowledgment 682 Funding for the RFC Editor function is currently provided by the 683 Internet Society.