idnits 2.17.1 draft-ietf-sip-e2m-sec-06.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1355. 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 is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 696 has weird spacing: '... where pro...' == Line 701 has weird spacing: '... where pro...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (July 7, 2007) is 6136 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'C' on line 738 == Missing Reference: '0' is mentioned on line 961, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4189 (ref. '2') ** Obsolete normative reference: RFC 3850 (ref. '3') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 2630 (ref. '5') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '9') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '10') (Obsoleted by RFC 8224) == Outdated reference: A later version (-03) exists of draft-ietf-sipping-session-indep-policy-02 -- No information found for draft-ono-sipping-keyreuse-smime - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-11 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP K. Ono 3 Internet-Draft Columbia University 4 Expires: January 8, 2008 S. Tachimoto 5 NTT Corporation 6 July 7, 2007 8 End-to-middle Security in the Session Initiation Protocol (SIP) 9 draft-ietf-sip-e2m-sec-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 January 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Some services provided by intermediaries depend on their ability to 43 inspect a message body in the Session Initiation Protocol (SIP). 44 When sensitive information is included in the message body, a SIP 45 User Agent (UA) needs to protect it from other intermediaries than 46 those that the UA agreed to disclose it to. This document proposes a 47 mechanism for securing information passed between an end user and 48 intermediaries using S/MIME. It also proposes mechanisms for a UA to 49 discover intermediaries which need to inspect an S/MIME-secured 50 message body, or to receive the message body with data integrity 52 This specification is approved at the proposed standards level due to 53 the IANA registration requirements. Is is of sufficient quality for 54 that level, however, the use of this mechanism in this specification 55 are considered experimental. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 2. Generating S/MIME-secured Message Body . . . . . . . . . . . . 3 62 2.1. S/MIME-secured Message Body for Confidentiality . . . . . 3 63 2.2. S/MIME-secured Message Body for Data Integrity . . . . . . 5 64 2.3. S/MIME-secured Message Body for Confidentiality and 65 Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Indicating the Target Proxy and Content . . . . . . . . . . . 6 67 4. Discovering the Security Policies of Proxy Servers . . . . . . 7 68 4.1. Discovery with Error Responses . . . . . . . . . . . . . . 8 69 5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . . 10 70 5.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Proxy-Inspect-Body Header . . . . . . . . . . . . . . . . . . 15 74 7. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Message Examples of End-to-Middle Confidentiality . . . . 17 76 7.2. Message Examples of End-to-Middle Integrity . . . . . . . 22 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 78 8.1. Impersonating a Proxy Server . . . . . . . . . . . . . . . 24 79 8.2. Tampering with a Message Body . . . . . . . . . . . . . . 25 80 8.3. Tampering with the Label of the Target Content . . . . . . 25 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 82 9.1. 'Proxy-Inspect-Body' Header . . . . . . . . . . . . . . . 25 83 9.2. '495 Signature Required' Response Code . . . . . . . . . . 26 84 9.3. '496 Proxy Undecipherable' Response Code . . . . . . . . . 26 85 9.4. '380 Required to View Content-Type' Warn-code . . . . . . 26 86 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 92 Intellectual Property and Copyright Statements . . . . . . . . . . 30 94 1. Introduction 96 When a UA requires services provided by intermediaries that depend on 97 the message body in request/response messages, end-to-end 98 confidentiality currently has to be disabled. This problem is 99 pointed out in Section 23 of [1]. Since such intermediaries are not 100 always adjacent to the UA, this situation requires security between 101 the UA and the intermediaries for the message body. We call this 102 "end-to-middle security", where by "end" we mean a UA and by "middle" 103 we mean an intermediary, typically a proxy server. 105 End-to-middle security, as well as end-to-end security, consists of 106 peer authentication, data integrity, and data confidentiality. Peer 107 authentication is required to achieve data integrity and data 108 confidentiality respectively. The mechanisms of end-to-middle peer 109 authentication are established with pre-existing mechanisms such as 110 HTTP Digest authentication [9]. Therefore, this document focuses on 111 mechanisms for providing data confidentiality and integrity for end- 112 to-middle security to meet the requirements discussed in [2]. 114 The proposed mechanisms are based on S/MIME [3], since the major 115 requirement is to have little impact on standardized end-to-end 116 security mechanisms defined in [1], the way of handling S/MIME-secure 117 messages. The mechanisms consist of generating an S/MIME-secured 118 message body and indicating the target message body is for a specific 119 proxy server selected by the UA. In addition, this document 120 describes a mechanism for a UA to discover the intermediary which 121 needs to inspect an S/MIME-secured message body, or to receive the 122 message body with data integrity. 124 1.1. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119 [4]. 130 2. Generating S/MIME-secured Message Body 132 2.1. S/MIME-secured Message Body for Confidentiality 134 For end-to-middle confidentiality, a UA MUST generate S/MIME CMS [5] 135 EnvelopedData which contains encrypted data. Prior to generating it, 136 a UA needs to identify contents to be encrypted, identify the target 137 proxy servers and obtain their credentials, such as their public key 138 certificates or shared secrets. One method is shown in Section 4. 140 The structure of the S/MIME CMS EnvelopedData contains encrypted data 141 specified in the "encryptedContentInfo" field and its recipient list 142 specified in the "recipientInfos" field. The encrypted data is 143 encrypted with a content-encryption-key (CEK) and the recipient list 144 contains the CEKs encrypted with different key-encryption-keys 145 (KEKs), one for each recipient. The KEKs are either the public keys 146 of each recipient or the shared keys between the UA and each 147 recipient. 149 If the encrypted data is destined for one or more than one proxy 150 server(s), the recipient list MUST contain only the proxy server(s). 151 If the same encrypted data is shared with the user agent server (UAS) 152 and proxy servers, the recipient list (the "recipientInfos" field) 153 MUST be addressed to the UAS and the proxy servers (e.g., Proxy #1 154 and Proxy #2), as shown in Figure 1. 156 +-----------------------------------------------------------+ 157 | The "recipientInfos" field | 158 |+---------------------------------------------------------+| 159 || CEK encrypted with UAS's KEK || 160 |+---------------------------------------------------------+| 161 || CEK encrypted with Proxy #1's KEK || 162 |+---------------------------------------------------------+| 163 || CEK encrypted with Proxy #2's KEK || 164 |+---------------------------------------------------------+| 165 | The "encryptedContentInfo" field | 166 |+---------------------------------------------------------+| 167 || Content encrypted with CEK to be shared with recipients || 168 |+---------------------------------------------------------+| 169 +-----------------------------------------------------------+ 171 Figure 1: An Example Structure of EnvelopedData for Sharing 173 If there are multiple pieces encrypted data destined for each proxy 174 server, the recipient list in each piece of encrypted data MUST 175 contain the relevant proxy server. If a piece of encrypted data is 176 destined for a proxy server and another piece of encrypted data for 177 the UAS, the recipient of each piece of encrypted data MUST be each 178 entity respectively, as shown in Figure 2. In order to concatenate 179 more than one CMS EnvelopedData, the user agent client (UAC) MUST 180 generate a "multipart/mixed" MIME body. 182 +-----------------------------------------------------------+ 183 | The "recipientInfos" field | 184 |+---------------------------------------------------------+| 185 || CEK #1 encrypted with proxy's KEK || 186 |+---------------------------------------------------------+| 187 | The "encryptedContentInfo" field | 188 |+---------------------------------------------------------+| 189 || Content encrypted with CEK #1 for proxy || 190 |+---------------------------------------------------------+| 191 +-----------------------------------------------------------+ 192 +-----------------------------------------------------------+ 193 | The "recipientInfos" field | 194 |+---------------------------------------------------------+| 195 || CEK #2 encrypted with UAS's KEK || 196 |+---------------------------------------------------------+| 197 | The "encryptedContentInfo" field | 198 |+---------------------------------------------------------+| 199 || Content encrypted with CEK #2 for UAS || 200 |+---------------------------------------------------------+| 201 +-----------------------------------------------------------+ 203 Figure 2: An Example Structure of EnvelopedData not for Sharing 205 2.2. S/MIME-secured Message Body for Data Integrity 207 For end-to-middle data integrity, a UA SHOULD generate S/MIME CMS 208 SignedData to attach a digital signature for the target data. If 209 this is not done, then as an alternative, a UA MAY generate the 210 signature in the SIP Identity [10] mechanism. Generating the 211 signature requires the generator, i.e., the UA, has its own public 212 and private key pair that the UA is not required to have. These 213 mechanisms allow any entity to verify the data integrity, if it is 214 able to access the UA's public key. This is why the same mechanisms 215 can be used in both end-to-middle and end-to-end data integrity. 217 Note: There are other mechanisms which could provide data 218 integrity, such as S/MIME CMS AuthenticatedData, or CMS 219 DigestedData as defined in [5]. However, S/MIME CMS 220 AuthenticatedData requires that a UA obtains the credential of the 221 recipient proxy server in advance. Thus, it requires a mechanism 222 to securely transmit the credential from the proxy server to the 223 UA. On the other hand, S/MIME CMS DigestedData does not require 224 such mechanism. However, anybody can generate the digest data for 225 a message. Then, it does not offer the data integrity from the 226 originator. Additionally, neither of them is used in [1]. 227 Therefore, a UA MUST NOT use either of S/MIME CMS 228 AuthenticatedData or CMS DigestedData for interoperability. 230 2.3. S/MIME-secured Message Body for Confidentiality and Data Integrity 232 Both for end-to-middle confidentiality and the data integrity, a UA 233 SHOULD first generate the signature as CMS SignedData, and encrypt 234 the message containing the signature inside. Alternatively, a UA MAY 235 generate the signature in the SIP identity which is set outside. As 236 the third alternative, a UA MAY first encrypt the message, and attach 237 the signature as CMS SignedData as defined in [1]. 239 There are two ways to encrypt and sign data: encrypt data after 240 signing, and encrypt data before signing. It is more secure to 241 encrypt data after signing than attaching a signature after 242 encryption, generally because the signature outside is easily 243 detachable. If the proxy server does not accept any message 244 without the SIP identity, encrypting data before signing is secure 245 enough. 247 3. Indicating the Target Proxy and Content 249 A UA need a way to indicate the content which is expected to be 250 viewed by a proxy server, in order for the proxy server to easily 251 determine whether to process a MIME body and if so, which part. To 252 meet this requirement, the UA MUST set a label to indicate the proxy 253 server and its target content using a new SIP header, "Proxy-Inspect- 254 Body" for encrypted data. The UA MAY omit to set the "Proxy-Inspect- 255 Body" header for signed data. This header consists of a proxy 256 server's hostname and one or more "cid" parameter(s) pointing to the 257 "Content-ID" MIME header [11] placed in the target body. 259 This indication is useful for encrypted data, but less for signed 260 data. The hostname field for encrypted data is useful for a proxy 261 server to determine if the proxy server is destined to view the body. 262 The "cid" parameter(s) for encrypted data is useful for a proxy 263 server to specify the target part of a "multi-part/mixed" body to 264 decrypt. On the contrary, the "cid" parameter for signed data always 265 indicates the whole message body, since the signed data is always 266 protecting the whole body. Additionally, since any entities can 267 verify the signed data, the hostname indication for singed data is 268 also less useful than the indication for encrypted data. 270 If a UA needs to request multiple proxy servers to view the same 271 message body, it MUST set multiple "Proxy-Inspect-Body" headers that 272 contain the same "cid" parameter. If a UA needs to request a proxy 273 server to view multiple body parts that are nested, it MUST set the 274 "cid" parameter of the outer body first and that of the inner body 275 next in the "Proxy-Inspect-Body" header. 277 Note: The "cid" parameter indicates which part of the body is 278 expected to be viewed by a proxy server, not what kind of content. 279 If the message body is encrypted, the proxy server needs to 280 decrypt it to see if the message body contains a necessary 281 Content-Type, such as application/sdp. 283 Note: There were three other options to label a body: a new SIP 284 parameter to an existing SIP header, a new MIME header, or a new 285 parameter to an existing MIME header. 286 1) Using a new parameter to Route header. Since a proxy server 287 views this header when forwarding a request message, it seems to 288 be a reasonable option. However, it cannot work with strict 289 routing. 290 2) Using a new MIME header, "Content-Target", as proposed in a 291 previous version of this draft. Since this option is not 292 necessary as a generic mechanism of MIME, it is not preferred. 293 3) Using a new MIME parameter to "Content-Disposition". The same 294 reason as above. 296 When a proxy server receives a message with the "Proxy-Inspect-Body" 297 containing its hostname, the proxy server MUST try decrypting the 298 content if the content is CMS EnvelopedData, or MUST validate the 299 signature if the content is CMS SignedData. If it fails to decrypt 300 or to validate, it MUST respond with an error code as described in 301 Section 5.3. 303 When a proxy server receives a message missing the "Proxy-Inspect- 304 Body" header containing its hostname, the proxy server misses viewing 305 the message body. If the proxy server needs to avoid such failure 306 for their own services, the proxy server MAY attempt to view the 307 message body, regardless of the hostname field. No error code is 308 defined to inform the UA that the indication was missing. 310 A UA has no way to get any specific acknowledgment of this 311 indication. If a UA indicates a proxy server that is not along the 312 signaling path, or that does not support this mechanism, the UA does 313 not have any error response. The UA can only acknowledge the proxy 314 server's behavior or compliance through the service which requires 315 proxy server's inspection of the message body fails. 317 4. Discovering the Security Policies of Proxy Servers 319 A discovery mechanism for security policies of proxy servers is 320 needed when a UA does not statically know which proxy servers or 321 domains have such policies. Security policies require disclosure of 322 data and/or verification in order to provide some services which 323 needs UA's compliance. 325 A proxy security policy includes specification of the MIME types of 326 message bodies that the proxy inspects as part of providing service. 327 For each of these MIME types, if the proxy is unable to examine the 328 corresponding message body, the proxy's security policy MAY require 329 the proxy to reject the message with an error. Any message body for 330 which an error results when the proxy cannot view the message body is 331 called a proxy required message body (PRMB). The goal of security 332 policy discovery is for the UA to learn the set of proxy required 333 message bodies (PRMBs) for each proxy involved in the call, so that 334 it can make those PRMBs visible to the proxies that require them. 335 Configuration of proxy security policy, including selection of the 336 MIME types that correspond to PRMBs is the responsibility of the 337 proxy administrator. 339 There are two ways in which a UA can learn the policies of the proxy 340 servers. One is by receiving an error response from the proxy 341 servers. The error response shows the violation of the policies, 342 then a UAC can learn them. However, it is not applicable to the UAS 343 because there is no way to react a response message. Alternatively, 344 a policy server can provide a UAC and the UAS a package mentioning 345 proxy's policy as described in [12]. When a proxy server needs to 346 inspect the message body contained in the response, it needs to learn 347 the policies from a policy server before sending the response. This 348 document covers only the former. 350 4.1. Discovery with Error Responses 352 When the proxy server receives a request that does not satisfy the 353 proxy's security policy, the proxy server MUST reject the request 354 with an error response. The security policy may be violated because 355 a PRMB cannot be viewed, or because a PRMB is not present in the 356 message. 358 If the request contains encrypted data that the proxy cannot decrypt, 359 the proxy MUST assume that any missing PRMB is within the encrypted 360 data and MUST reject the message with a new error response, 496 361 (Proxy Undecipherable). The proxy's public key certificate and the 362 Content-Type of the PRMB SHOULD be included in the error response. 363 If more than one PRMB is missing, the proxy MAY use the Content-Type 364 of any missing PRMB in the error response. The proxy's public key 365 certificate SHOULD be set as an "application/pkix-cert" [6] MIME body 366 in the error response. 368 If the proxy is able to decrypt all of the encrypted data in the 369 request, but a PRMB is missing, the proxy MUST behave as if a a 370 completely unencrypted request had been sent without the PRMB. If 371 the message is a request, it MAY be rejected with a 403 372 (Forbidden) response. If it is a response, any existing dialog 373 MAY be terminated. 375 The Content-Type that the proxy server needs to view MUST be set in 376 the Warning header with a new warn-code, 380, except when the proxy 377 server needs to view the whole body. If no Warning header specifying 378 Content-Type is set, it indicates that the proxy server needs to view 379 the whole body, not specific content. For example, when the proxy 380 server needs to view a SDP, the following Warning header: 382 Warning: 380 example.com "Required to View Content-Type 383 'application/sdp'" 385 If the proxy server requires to view SDP and several sensitive 386 headers that are hidden in tunneling encryption data as described in 387 Section 23.4.3 of [1], the proxy server MAY respond with the Warning 388 header containing 'message/sip'. Instead of specifying Content-Type, 389 the proxy server MAY respond with no Warning header in order to 390 require to view the whole body including sensitive headers. 392 When a UAC receives a 496 (Proxy Undecipherable) response, the UAC 393 MUST check the respondent's name in the public key certificate and 394 the target Content-Type that the proxy server wants to view in the 395 Warning header, if they exist. 397 In a previous version of this document, 493 (Undecipherable) error 398 response had been proposed to be shared by the UAS and a proxy 399 server. However, the reactions requesting the UAC are different, 400 as pointed out in the SIP mailing list. On receiving the error 401 response from the UAS, the UAC should totally renew 402 "recipientInfos" by encrypted CEK with the KEK obtained from the 403 error response. On the other hand, on receiving the error 404 response from the proxy server, the UAC first should analyze the 405 feature of the message body and the proxy-requiring Content-Type 406 obtained from the Warning header. If the UAC decides to share the 407 message body with the UAS and the proxy server, the UAC will reuse 408 the "recipientInfos" of the previous request and add encrypted CEK 409 with the proxy's KEK obtained from the error response to it. If 410 the UAC decides to send two parts of the message body separately, 411 the UAC will add the EnvelopedData that contains a message body 412 for the proxy into the EnvelopedData in the previous request and 413 construct a "multipart/mixed" MIME body. 415 If a digital signature is not attached to the message body in the 416 request and the proxy server requires the integrity check, the proxy 417 server MUST reject with a 495 (Signature Required) error response. 418 When the attached signature just to the whole body is required, this 419 error response MUST contain no Warning header to specify Content-Type 420 that is required signature. When the attached signature to tunneling 421 SIP message is required as described in Section 23.4 of [1], this 422 error response MAY contain the Warning header with 380 warn-code, 423 specifying 'message/sip', or 'message/sipfrag' Content-Type. The 424 proxy server MAY attach the signature to a "message/sipfrag" [13] 425 body, in order to set the name of the proxy server in the error 426 response. 428 When a proxy server requires both disclosure and an integrity check 429 of the message body in a request message and the message satisfies 430 neither, the proxy server SHOULD send one error response at a time. 431 When a proxy server cannot decrypt the message body in a request 432 message and does not see if the signature is placed inside, a proxy 433 server SHOULD send an error response only for requesting disclosure. 434 After receiving a request message including encrypted data destined 435 for the proxy server, it finds out whether the message has a 436 signature attached and SHOULD send an error response for requesting 437 signature when the message lacks it. 439 When a UA receives the 495 error response and the confidentiality is 440 needed, the UA MUST recognize the error requiring the signature for 441 the data prior to the encryption. 443 This discovery mechanism requires two more message exchange for an 444 error condition per each proxy server in the signaling path in order 445 to establish a session between UAs. Since this causes a delay in 446 session establishment, it is desirable that the UAs learn the 447 security policies of the proxy servers in advance. 449 5. Behavior of UAs and Proxy Servers 451 We describe here the behavior of UAs and proxy servers that implement 452 end-to-middle security. 454 5.1. UAC Behavior 456 When a UAC sends a SIP request, such as an INVITE request including 457 encrypted message body for end-to-middle confidentiality, it MUST 458 generate S/MIME CMS EnvelopedData, and SHOULD specify the hostname of 459 destined proxy server and Content-ID of the S/MIME CMS EnvelopedData 460 which is to be decrypted by the proxy server in the "Proxy-Inspect- 461 Body" header. 463 If the UAC decides to share the message body with the UAS and the 464 proxy server that requires the inspection of the message body, the 465 UAC MUST list encrypted CEK with the proxy server's KEK and encrypted 466 CEK with the UAS's KEK at the "recipientInfos" of the CMS 467 EnvelopedData. If the UAC decides to set the message body 468 separately, the UAC MUST structure a "multipart/mixed" body that 469 contains two CMS EnvelopedData: one encrypted for the UAS and another 470 encrypted for the proxy server. The UAC MUST set the value 471 "optional" in the handling parameter of the "Content-Disposition" 472 MIME header for the EnvelopedData destined for Proxy #1, in order to 473 avoid unnecessary error conditions in the UAS. The "multipart/mixed" 474 MIME body MUST have either the value "required" in the handling 475 parameter or no handling parameter, since the default value is 476 "required" as specified in [1]. 478 If the UAC sends a SIP request including encrypted body just for end- 479 to-end, being unaware of the service provided by the proxy server 480 that requires the inspection of the message body, the UAC will get a 481 496 (Proxy Undecipherable) error response with the public key of the 482 proxy server. The error response MAY contain the Warning header 483 requiring the disclosure of a specific content, or no Warning header. 485 By obtaining the error response that the Warning header specifies 486 content, the UAC learns that the proxy server requires the disclosure 487 of a specific message body. If the error response contains no 488 Warning header, the UAC learns the proxy server require the 489 disclosure of the whole message body. If the UAC decides to meet the 490 requirement of the proxy server, the UAC MUST generates CMS 491 EnvelopedData and MUST set the "Proxy-Inspect-Body" header as 492 described above. If the UAC decides to share the message body with 493 the UAS and the proxy server, the UAC MUST update the 494 "recipientInfos" of the previous request by adding encrypted CEK with 495 the proxy server's KEK obtained from the error response. If the UAC 496 decides to set the message body separately for the proxy server, the 497 UAC MUST structure a "multipart/mixed" body by adding the CMS 498 EnvelopedData for the proxy server. 500 When the UAC sends a SIP request of which message body needs end-to- 501 middle integrity, it SHOULD generate S/MIME CMS SignedData to attach 502 a digital signature. The UAC MAY specify the hostname of the proxy 503 server and Content-ID of the CMS SignedData to be validated in the 504 "Proxy-Inspect-Body" SIP header. 506 If the UAC sends a SIP request without the signature, being unaware 507 of the proxy server's service that requires the verification of the 508 message body, the UAC will get a 495 (Signature Required) error 509 response with no Warning header requiring Content-Type. 511 By obtaining the 495 error response, the UAC learns that an entity in 512 the signaling path, such as the proxy server, requires the signature 513 of the whole message body. If the UAC decides to meet the 514 requirement and has its own public key, the UAC MUST generate the CMS 515 SignedData to attach a signature by computing with its own private 516 key. 518 When the UAC sends a request and needs both end-to-middle 519 confidentiality and integrity for the message body, it SHOULD first 520 generate S/MIME CMS SignedData to attach the digital signature for 521 the content, and then generate S/MIME EnvelopedData to encrypt the 522 CMS SignedData. The UAC MUST specify the hostname of the proxy 523 server and the Content-ID of the CMS EnvelopedData destined for the 524 proxy server in the "Proxy-Inspect-Body". The UAC also MAY specify 525 the Content-ID of the CMS SignedData following the Content-ID of the 526 CMS EnvelopedData in the header. 528 For example, if the UAC needs the confidentiality of the SDP, and it 529 knows that the destined proxy server needs to view the both SDPs in a 530 request and the response, the UAC MAY use the CEK reuse mechanism 531 [14][15]. The UAC indicates the identifier of the CEK to be reused 532 at the "unprotectedAttrs" field of the CMS EnvelopedData in an INVITE 533 request as showed in Figure 3. 535 +-------------------------------------------------------------+ 536 | The "recipientInfos" field | 537 |+-----------------------------------------------------------+| 538 || CEK encrypted with UAC's KEK || 539 |+-----------------------------------------------------------+| 540 || CEK encrypted with destined server's KEK || 541 |+-----------------------------------------------------------+| 542 | The "encryptedContentInfo" field | 543 |+-----------------------------------------------------------+| 544 || Content encrypted with CEK #1 to be shared with recipients|| 545 |+-----------------------------------------------------------+| 546 | The "unprotectedAttrs" field | 547 |+-----------------------------------------------------------+| 548 || Identifier of CEK #1 || 549 |+-----------------------------------------------------------+| 550 +-------------------------------------------------------------+ 552 Figure 3: EnvelopedData with CEK reuse in a request 554 5.2. UAS Behavior 556 When the UAS receives a request that contains a MIME body, the UAS 557 inspects the MIME body depending on the value of the handling 558 parameter in "Content-Disposition" header. If the MIME body 559 structures S/MIME, the UAS first decrypts and/or validates it as 560 usual. If the decryption and/or the validation is successful, the 561 UAS responds with a 200 OK. If the 200 OK response contains a MIME 562 body, the UAS is RECOMMENDED to construct the same S/MIME structure 563 with the request. 565 When the CMS EnvelopedData body of the request, destined for the UAS, 566 contains the "unprotectedAttrs" attribute specifying the identifier 567 of the CEK, the UAS MAY learn that the UAC is requesting to reuse the 568 CEK for the disclosure of the message body in the subsequent requests 569 or responses. By checking the "Proxy-Inspect-Body" header in the 570 receiving request, the UAS MAY know the destined proxy server and the 571 Content-Type to be disclosed. If the UAS accepts the disclosure, it 572 MAY keep the CEK with the identifier specified in the 573 "unprotectedAttrs" attribute. If the UAS receives an INVITE message 574 specifying the CEK reuse, the UAS MAY reuse the CEK (CEK #1) to 575 encrypt a new CEK (CEK #2) for encrypting the message body in the 576 response as showed in Figure 4 578 +-------------------------------------------------------------+ 579 | The "recipientInfos" field | 580 |+-----------------------------------------------------------+| 581 || CEK #2 encrypted with CEK #1 || 582 |+-----------------------------------------------------------+| 583 | The "encryptedContentInfo" field | 584 |+-----------------------------------------------------------+| 585 || Content encrypted with CEK #2 to be shared with recipients|| 586 |+-----------------------------------------------------------+| 587 +-------------------------------------------------------------+ 589 Figure 4: EnvelopedData with CEK reuse in a response 591 Even when the UAS receives a request that does not use S/MIME, the 592 UAS sometimes needs end-to-middle confidentiality for the message 593 body in a response, for example, the SDP offer/answer in a 200 594 response and ACK request. The behavior for generating S/MIME CMS 595 data is the same as how the UAC operates as described in Section 5.1, 596 while the behavior for discovering the security policies of destined 597 proxy server can not be not supported. 599 5.3. Proxy Behavior 601 When the proxy server implementing and activating this mechanism 602 receives a message, it MUST inspect the "Proxy-Inspect-Body" 603 header(s). If the header includes the host name of the proxy server 604 , the proxy server MUST inspect the body indicated by the "cid" 605 parameter. If multiple "cid" parameters exist in the header, the 606 proxy server MUST inspect the bodies in order. Even if the header 607 does not include the hostname of the proxy server, nor the header 608 exists, the proxy server MAY view the message body following its own 609 security policies. 611 The proxy server MAY activate this mechanism user by user. When 612 the proxy server receives a message from a user for whom the proxy 613 server does not activate this, the proxy server ignores the 614 "Proxy-Inspect-Body" header(s) and does not view the message body. 616 When the indicated body is CMS EnvelopedData, the proxy server MUST 617 try to decrypt the "recipientInfos" field. If there is a piece of 618 encrypted data for the proxy server, the proxy server will succeed in 619 obtaining the CEK to decrypt the encrypted content at the 620 "encryptedContentInfo" field. 622 If the proxy server fails to decrypt the message body that is 623 required to view, it MUST respond with a 496 (Proxy Undecipherable) 624 response, if it is a request, otherwise any existing dialog MUST be 625 terminated. If the proxy server requires the disclosure of a 626 specific content, the 496 response MUST include the Warning header, 627 containing "Required to view 'Content-Type'". If the proxy server 628 requires the disclosure of the whole message body, it MUST respond 629 without the Warning header containing Content-Type. 631 If the proxy server succeeds in this decryption, it MAY inspect the 632 "unprotectedAttrs" field of the CMS EnvelopedData body. If the 633 attribute gives the key's identifier, the proxy server MAY keep the 634 CEK with its identifier until the lifetime of the CEK expires. If it 635 receives subsequent messages within the lifetime, it MAY try to 636 decrypt the type "KEKRecipientInfo" of the "RecipientInfo" attribute 637 by using this CEK. 639 When the indicated content contains CMS SignedData body, the proxy 640 server MUST validate the digital signature. If the verification 641 fails, the proxy server SHOULD reject the subsequent procedure. It 642 MAY respond with a 403 (Forbidden) response if the message is a 643 request, otherwise any existing dialog MAY be terminated. 645 When the proxy server needs validate the data integrity of the 646 content but the indicated body does not contain CMS SignedData body, 647 the proxy server MUST respond with a 495 (Signature Required) 648 response if the message is a request, otherwise any existing dialog 649 MAY be terminated. A 495 response MAY contain no Warning header 650 requiring Content-Type to be attached a signature. 652 When the proxy server needs to validate the data integrity of the 653 content and view it, but the indicated content is the CMS 654 EnvelopedData, the proxy server does not see if the signature exists 655 inside. First, the proxy server tries to decrypt the CMS 656 EnvelopedData. If the decryption fails, the proxy server MUST 657 respond with 496 (Proxy Undecipherable) that contains its own public 658 key and no Warning header requiring a specific Content-Type. After 659 getting decipherable data, the proxy server inspects the content and 660 validate the signature, if it exists. If the signature for the whole 661 body does not exist, the proxy server MUST respond with 495 662 (Signature Required) that contains no Warning header requiring a 663 specific Content-Type. If the encrypted data is attached with the 664 signature outside, the proxy server MAY first validate the signature, 665 instead of checking the existence of the signature inside. 667 When the proxy server forwards the request, it MAY delete the "Proxy- 668 Inspect-Body" header that contains its own hostname. 670 When a provider operating the proxy server does not allow any 671 information related to its security policies to be revealed to 672 other proxy server, the proxy server MAY deletes the "Proxy- 673 Inspect-Body" header. However, there is no way to conceal the 674 header from the other proxy servers which exist between a UAC and 675 the proxy server. 677 6. Proxy-Inspect-Body Header 679 The following syntax specification uses the augmented Backus-Naur 680 Form (BNF) as described in RFC-2234 [7]. The new header "Proxy- 681 Inspect-Body" is defined as a SIP header. 683 Proxy-Inspect-Body = "Proxy-Inspect-Body" HCOLON inspecting-proxy 684 SEMI target-body *(SEMI generic-param) 685 inspecting-proxy = host 686 target-body = cid-param *(COMMA cid-param) 687 cid-param = "cid" EQUAL content-id 688 content-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 689 dot-atom = atom *( "." atom ) 690 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 691 "_" / "+" / "'" / "`" / "~" ) 693 Information about the use of headers in relation to SIP methods and 694 proxy processing is summarized in Table 1. 696 Header field where proxy ACK BYE CAN INV OPT REG REF 697 ----------------------------------------------------------------- 698 Proxy-Inspect-Body R dr o o - o o o o 699 Proxy-Inspect-Body 100-699 dr - o - o o o o 701 Header field where proxy SUB NOT PRK IFO UPD MSG PUB 702 ----------------------------------------------------------------- 703 Proxy-Inspect-Body R dr o o o o o o o 704 Proxy-Inspect-Body 100-699 dr o o - o o o o 705 Table 1: Summary of header field use 706 The "where" column gives the request and response types in which 707 the header field can be used. The values in the "where" column 708 are as follows: 709 * R: The header field may appear in requests 710 * 100-699: A numeral range indicates response codes with which 711 the header field can be used. 712 The "proxy" column gives the operations a proxy may perform on the 713 header field: 714 * d: A proxy can delete a header field value. 715 * r: A proxy must be able to read the header field, so it cannot 716 be encrypted. 717 The next columns relate to the presence of a header field in a 718 method: 719 * o: The header field is optional. 720 * -: The header field is not applicable. 722 7. Message Examples 724 We describe here the message examples in a model in which a proxy 725 server that provides a firewall traversal service for voice and 726 video, and a logging service for instant messages exists in a 727 signaling path as shown in Figure 7. The instant messages assumes to 728 use MESSAGE [16] requests. 730 +-----+ +-----+ +-----+ +-----+ 731 | C |-----| C |---------------| [C] |-----| C | 732 +-----+ +-----+ +-----+ +-----+ 733 UA #1 Proxy #1 Proxy #2 UA #2 734 w/Firewall traversal 735 and logging functions 737 C : Content that UA #1 allows the entities to inspect 738 [C]: Content that UA #1 prevents the entity from inspecting 740 Figure 7: Configuration example 742 In the message examples, the text with the box of asterisks ("*") is 743 encrypted. Although the Content-Length has no digit, the appropriate 744 length is to be set. The hostname and username for each entity are: 745 UA #1: alice@atlanta.example.com 746 UA #2: bob@biloxi.example.com 747 Proxy #1: ss1.atlanta.example.com 748 Proxy #2: ss1.biloxi.example.com 750 7.1. Message Examples of End-to-Middle Confidentiality 752 In the following example, UA #1 needs the SDP in an INVITE request to 753 be confidential and it allows a proxy server to view the SDP. 755 INVITE alice@atlanta.example.com --> ss1.atlanta.example.com 757 INVITE sip:bob@biloxi.example.com SIP/2.0 758 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 759 Max-Forwards: 70 760 From: Alice ;tag=9fxced76sl 761 To: Bob 762 Call-ID: 3848276298220188511@atlanta.example.com 763 CSeq: 1 INVITE 764 Date: Fri, 20 June 2003 13:02:03 GMT 765 Contact: 766 Proxy-Inspect-Body: ss1.atlanta.example.com; 767 cid=1234@atlanta.example.com 769 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 770 name=smime.p7m 771 Content-Transfer-Encoding: binary 772 Content-ID: 1234@atlanta.example.com 773 Content-Disposition: attachment;filename=smime.p7m;handling=required 774 Content-Length: 776 ****************************************************************** 777 * (recipientInfos) * 778 * RecipientInfo[0] for ss1.atlanta.example.com public key * 779 * RecipientInfo[1] for Bob's public key * 780 * * 781 * (encryptedContentInfo) * 782 * Content-Type: application/sdp * 783 * Content-Length: * 784 * * 785 * v=0 * 786 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 787 * s=- * 788 * c=IN IP4 192.0.2.101 * 789 * t=0 0 * 790 * m=audio 49172 RTP/AVP 0 * 791 * a=rtpmap:0 PCMU/8000 * 792 * * 793 ****************************************************************** 795 When Proxy #1 and UA #2 successfully views the SDP, UA #2 responds 796 with a 200 OK. The 200 OK is to be encrypted as follows: 798 200 OK alice@atlanta.example.com <-- ss1.atlanta.example.com 800 SIP/2.0 200 OK 801 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 802 ;received=192.0.2.101 803 From: Alice ;tag=9fxced76sl 804 To: Bob ;tag=8321234356 805 Call-ID: 3848276298220188511@atlanta.example.com 806 CSeq: 1 INVITE 807 Contact: 808 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 809 name=smime.p7m 810 Content-Transfer-Encoding: binary 811 Content-ID: 1234@atlanta.example.com 812 Content-Length: 814 ****************************************************************** 815 * (recipientInfos) * 816 * RecipientInfo[0] for Alice's public key * 817 * * 818 * (encryptedContentInfo) * 819 * Content-Type: application/sdp * 820 * Content-Length: * 821 * * 822 * v=0 * 823 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 824 * s=- * 825 * c=IN IP4 192.0.2.201 * 826 * t=0 0 * 827 * m=audio 3456 RTP/AVP 0 * 828 * a=rtpmap:0 PCMU/8000 * 829 ****************************************************************** 831 When keying materials, such as keys used for Secure RTP (SRTP), are 832 included in the SDP [17], UA #1 does not want to show the keying 833 materials to Proxy #1, although Proxy #1 needs to view the SDP for 834 the firewall traversal service. In this case, UA #1 sets two SDP 835 separately; one contains the keying materials for UA #2 and another 836 does not for Proxy #1 as follows: 838 INVITE alice@atlanta.example.com --> ss1.atlanta.example.com 840 INVITE sip:bob@biloxi.example.com SIP/2.0 841 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 842 Max-Forwards: 70 843 From: Alice ;tag=9fxced76sl 844 To: Bob 845 Call-ID: 3848276298220188511@atlanta.example.com 846 CSeq: 1 INVITE 847 Date: Fri, 20 June 2003 13:02:03 GMT 848 Contact: 849 Proxy-Inspect-Body: ss1.atlanta.example.com; 850 cid=1234@atlanta.example.com,cid=3333@atlanta.example.com 852 Content-Type: multipart/mixed; boundary=boundary1 853 Content-Transfer-Encoding: binary 854 Content-ID: 1234@atlanta.example.com 855 Content-Disposition: attachment;filename=smime.p7m;handling=required 856 Content-Length: 858 --boundary1 859 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 860 name=smime.p7m 861 Content-ID: 3333@atlanta.example.com 862 Content-Disposition: attachment;filename=smime.p7m;handling=required 863 ****************************************************************** 864 * (recipientInfos) * 865 * RecipientInfo[0] for ss1.atlanta.example.com public key * 866 * * 867 * (encryptedContentInfo) * 868 * Content-Type: application/sdp * 869 * Content-Length: * 870 * * 871 * v=0 * 872 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 873 * s=- * 874 * c=IN IP4 192.0.2.101 * 875 * t=0 0 * 876 * m=audio 49172 RTP/SAVP 0 * 877 * * 878 ****************************************************************** 880 --boundary1 881 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 882 name=smime.p7m 883 Content-ID: 4444@atlanta.example.com 884 Content-Disposition: attachment;filename=smime.p7m;handling=optional 885 ****************************************************************** 886 * (recipientInfos) * 887 * RecipientInfo[0] for Bob's public key * 888 * * 889 * (encryptedContentInfo) * 890 * Content-Type: application/sdp * 891 * Content-Length: * 892 * * 893 * v=0 * 894 * o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com* 895 * s=- * 896 * c=IN IP4 192.0.2.101 * 897 * t=0 0 * 898 * m=audio 49172 RTP/SAVP 0 * 899 * a=crypto:1 AES_CM_128_HMAC_SHA1_32 * 900 * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * 901 * * 902 ****************************************************************** 903 --boundary1-- 905 For firewall traversal service, Proxy #1 does not care about the 906 information only for UA #2. Even if UA #1 sets different port 907 information for UA #2 and Proxy #1 separately on purpose, the 908 firewall traversal service for UA #1 will just fail. 910 However, if Proxy #1 provides a call admission control using codec 911 information in SDP, Proxy #1 might care about the information for UA 912 #2. Proxy #1 wants to view the SDP destined not only for itself, but 913 also the SDP destined for UA #2 in order to confirm that both of the 914 codec information are the same. In other words, Proxy #1 needs to 915 police if UA #1 does not attempt to use a different codec that 916 requires more bandwidth. As a result, Proxy #1 will require 917 disclosure of all the message body by setting no Warning header 918 requiring Content-Type as follows: 920 496 Proxy Undecipherable alice@atlanta.example.com <-- 921 ss1.atlanta.example.com 923 SIP/2.0 496 Proxy Undeciperable 924 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 925 ;received=192.0.2.101 926 From: Alice ;tag=9fxced76sl 927 To: Bob ;tag=8321234356 928 Call-ID: 3848276298220188511@atlanta.example.com 929 CSeq: 1 INVITE 930 Content-Type: application/pkix-cert 931 Content-Length: 933 934 In the following example, UA #1 needs message content in a MESSAGE 935 request to be confidential and it allows Proxy #1 to view the message 936 body. 938 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 940 MESSAGE sip:bob@biloxi.example.com SIP/2.0 941 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 942 Max-Forwards: 70 943 Route: 944 From: Alice ;tag=9fxced76sl 945 To: Bob 946 Call-ID: 3848276298220188511@atlanta.example.com 947 CSeq: 1 MESSAGE 948 Date: Fri, 20 June 2003 13:02:03 GMT 949 Proxy-Inspect-Body: ss1.atlanta.example.com; 950 cid=1234@atlanta.example.com 952 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 953 name=smime.p7m 954 Content-Transfer-Encoding: binary 955 Content-ID: 1234@atlanta.example.com 956 Content-Disposition: attachment;filename=smime.p7m;handling=required 957 Content-Length: ... 959 ****************************************************************** 960 * (recipientInfos) * 961 * RecipientInfo[0] for ss1.atlanta.example.com public key * 962 * RecipientInfo[1] for Bob's public key * 963 * * 964 * (encryptedContentInfo) * 965 * Content-Type: text/plain * 966 * Content-Length: ... * 967 * * 968 * Hello. * 969 * This is confidential. * 970 * * 971 ****************************************************************** 973 If Proxy #1 and UA #2 successfully view the message body, UA #1 974 receives a 200 OK from UA #2 normally. However, if Proxy #1 fails to 975 view the message body, UA #1 receives a 496 (Proxy Undecipherable) 976 error response from Proxy #1, as follows: 978 496 Proxy Undecipherable alice@atlanta.example.com <-- 979 ss1.atlanta.example.com 981 SIP/2.0 496 Proxy Undeciperable 982 Warning: 380 ss1.atlanta.example.com "Required to view 'text/plain'" 983 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 984 ;received=192.0.2.101 985 From: Alice ;tag=9fxced76sl 986 To: Bob ;tag=8321234356 987 Call-ID: 3848276298220188511@atlanta.example.com 988 CSeq: 1 MESSAGE 989 Content-Type: application/pkix-cert 990 Content-Length: ... 992 994 7.2. Message Examples of End-to-Middle Integrity 996 In the following example, UA #1 needs the integrity of message 997 content in a MESSAGE request to be validated by Proxy #1 before it 998 views message content. 1000 MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com 1002 MESSAGE sip:bob@biloxi.example.com SIP/2.0 1003 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1004 Max-Forwards: 70 1005 Route: 1006 From: Alice ;tag=9fxced76sl 1007 To: Bob 1008 Call-ID: 3848276298220188511@atlanta.example.com 1009 CSeq: 1 MESSAGE 1010 Date: Fri, 20 June 2003 13:02:03 GMT 1011 Content-Type: multipart/signed;protocol="application/pkcs7-signature" 1012 ;micalg=sha1;boundary=boundary1 1013 Content-Length: ... 1015 --boundary1 1016 Content-Type: text/plain 1017 Content-Length: ... 1019 Hello. 1020 This is protected with the signature. 1021 --boundary1 1022 Content-Type: application/pkcs7-signature; name=smime.p7s 1023 Content-Transfer-Encoding: binary 1024 Content-ID:1234@atlanta.example.com 1025 Content-Disposition: attachment; 1026 filename=smime.p7s;handling=required 1028 [binary data] 1029 --boundary1-- 1031 If Proxy #1 successfully validates the integrity of the message body 1032 and UA #2 receive it, UA #1 normally receives a 200 OK from UA #2. if 1033 Proxy #1 does not receive a signature for the whole message body, UA 1034 #1 receives a 495 (Signature Required) error response from UA #1, as 1035 follows: 1037 495 Signature Required alice@atlanta.example.com <-- 1038 ss1.atlanta.example.com 1040 SIP/2.0 495 Signature Required 1041 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1042 ;received=192.0.2.101 1043 From: Alice ;tag=9fxced76sl 1044 To: Bob ;tag=8321234356 1045 Call-ID: 3848276298220188511@atlanta.example.com 1046 CSeq: 1 MESSAGE 1047 Content-Length: 0 1049 8. Security Considerations 1051 8.1. Impersonating a Proxy Server 1053 The discovery mechanism in Section 4 relies on error responses, such 1054 as 495 (Signature Required) and 496 (Proxy Undecipherable). As for 1055 the 495 response, the responder is not critical from the security 1056 perspective, since it does not require any kind of downgrading 1057 security, but upgrading security by attaching the signature that can 1058 be validated by any entities. On the other hand, the 496 response is 1059 critical and vulnerable to be forged by a malicious user, since it is 1060 attached with the public key certificate that requires the disclosure 1061 of the whole or the partial message body to the UA. 1063 To make sure that the 496 response contains the public key 1064 certificate of a proper proxy server, UA MUST see if the common name 1065 of the public key certificate is equal to the name of a proper proxy 1066 server. UA MUST recognize the name of legitimate proxies by the 1067 domain part of the SIP URIs of the UA and recipient, the name of 1068 configured outbound proxy and pre-configuration. That is, UA MUST be 1069 pre-configured with the domain name of a third party, if there are a 1070 third party proxy which offers some service viewing the message body. 1072 Additionally, a UA MUST verify whether the public key certificate is 1073 valid and not revoked as specified in [8]. If it is invalid and 1074 revoked, the UA MUST NOT retry to send the message with data 1075 encrypted by the public key. 1077 If a malicious user sends the public key certificate of the proper 1078 proxy server, it would not be a problem as long as the malicious user 1079 does not know the corresponding private key, since the malicious user 1080 will fail to decrypt the data the user sent. 1082 8.2. Tampering with a Message Body 1084 This document describes a mechanism to encrypt data for multiple 1085 recipients, such as multiple proxy servers, or a recipient UA and 1086 proxy servers. A piece of encrypted data is decipherable and 1087 vulnerable to tampering by proxy servers at the previous hops. 1089 In order to prevent such tampering, the UA SHOULD protect the data 1090 integrity before encryption, when the encrypted data is meant to be 1091 shared with multiple proxy servers, or to be shared with the UAS and 1092 selected proxy servers. The UA SHOULD generate S/MIME CMS SignedData 1093 and then SHOULD generate the EnvelopedData to encrypt attached data 1094 with a digital signature. The recipient entity MUST verify the 1095 signature to see if the encrypted data has been modified after 1096 decryption by an entity listed in the "recipientInfos" field. 1098 8.3. Tampering with the Label of the Target Content 1100 This document also describes a new SIP header for labeling a message 1101 body for a proxy server. If a malicious user or proxy server in the 1102 middle modified/added/deleted the label, the specified message body 1103 will be not inspected by the specified proxy server, and some 1104 services requiring its content can not be provided. Or a proxy 1105 server will conduct an unnecessary processing on message bodies such 1106 as unpacking MIME structure, and/or signature verification. This is 1107 a possible cause for a Denial-of-Services attack to a proxy server. 1109 To prevent such attacks, data integrity for the label is needed. UAs 1110 and proxy servers SHOULD use TLS mechanism to communicate with each 1111 other. Since a proxy server trusted to provide SIP routing is 1112 basically trusted to process SIP headers other than those related to 1113 routing, hop-by-hop security is reasonable to protect the label. In 1114 order to further protect the integrity of the label, UAs MAY generate 1115 a "message/sipfrag" body and attach a digital signature for the whole 1116 body. 1118 9. IANA Considerations 1120 This document requests requests to register a SIP header, two SIP 1121 response codes, and a SIP warn-code in the SIP parameters IANA 1122 registry. 1124 9.1. 'Proxy-Inspect-Body' Header 1126 This section includes the registration information for the 'Proxy- 1127 Inspect-Body' header which is described in Section 6 of this 1128 document. 1130 Header Name: Proxy-Inspect-Body 1131 Compact Form: (none) 1133 9.2. '495 Signature Required' Response Code 1135 This section includes the registration information for the '495 1136 Signature Required' response code which is described in Section 4 of 1137 this document. 1138 Response Code Number: 495 1139 Default Response Phrase: Signature Required 1141 9.3. '496 Proxy Undecipherable' Response Code 1143 This section includes the registration information for the '496 Proxy 1144 Undecipherable' response code which is described in Section 4 of this 1145 document. 1146 Response Code Number: 496 1147 Default Response Phrase: Proxy Undecipherable Code 1149 9.4. '380 Required to View Content-Type' Warn-code 1151 This section includes the registration information for the '380 1152 Required to view Content-Type' warn-code which is described in 1153 Section 4 of this document. 1154 Warning Code Number: 380 1155 Default Warning Phrase: Required to View Content-Type 1157 10. Changes 1159 Changed from -05. 1160 o Fixed the misuse of "acknowledge", to "learn" in Section 5.1 and 1161 5.2. 1162 o Clarified how to recognize legitimate proxy name in Section 8.1. 1163 o Fixed the problem condition in Section 8.1. 1165 Changed from -04. 1166 o Changed the header name "Proxy-Required-Body" to "Proxy-Inspect- 1167 Body". 1168 o Changed the constraint for labeling encrypted data from "SHOULD" 1169 to "MUST". 1170 o Changed the constraint for verifying certificate at the recipient 1171 from "SHOULD" to "MUST" in Section 8.2. 1172 o Removed the necessity of authentication in Section 8.3. 1173 o Added text for clarification. 1175 Changed from -03. 1177 Added text mentioning CMS Digest-Data. 1178 Added text related the order of sign and encryption in Section 1179 2.3. 1180 Added an example of Warning header in Section 4.1. 1181 Added how to support SIP tunneling sign and encryption in Section 1182 4.1. 1183 Removed examples from the Section 5 "Behavior of UA and Proxy 1184 Servers". Then, merged them to Section 7 "Message Examples". 1185 Added message examples with multipart/mixed structure. 1186 Referred to RFC3280 to validate certificated in Section 8.1. 1187 Added the necessity of authentication in Section 8.3 1189 Changes from -02. 1190 o Added text in the abstract. 1191 o Fixed the order of CMS data fields in the examples. 1192 o Modified the default response phrase for the 496 response code for 1193 the consistency with that of the 493 response code. 1194 o Added generic-params to the "Proxy-Required-Body" header for 1195 supporting extension parameters. 1196 o Added REFER and PUBLISH methods in the table. 1197 o Clarified a new parameter and responses in the section of IANA 1198 consideration. 1200 Changes from -01. 1201 o Changed an author's contact address. 1203 Changes from -00. 1204 o Added several figures that show the abstract of the structure of 1205 EnvelopedData. 1206 o Changed a error response that Proxy sends back in decryption 1207 failure from 493 (Undecipherable) to 496 (Proxy Indecipherable), a 1208 new one. 1209 o Changed the constraint of indicating CMS SignedData for a UA, from 1210 SHOULD to MAY/NOT RECOMMENDED. 1211 o Added the way that Proxy requires the disclosure for the whole 1212 body. 1213 o Added the way that Proxy sets its own name to a 495 response. 1214 o Corrected the applicability of the "Proxy-Inspect-Body" for ACK 1215 and PRACK. 1216 o Removed the parameters for the CEK reuse from the message 1217 examples. 1218 o Added text for detecting forged error response at impersonating 1219 proxy server in Security Consideration. 1221 11. Acknowledgments 1223 Thanks to Rohan Mahy and Cullen Jennings for their initial support of 1224 this concept and to many people for useful comments, especially Jon 1225 Peterson, Jonathan Rosenberg, Eric Burger, Russ Housely, Marjou 1226 Xavier, and Eric Rescorla. 1228 12. References 1230 12.1. Normative References 1232 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1233 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1234 Session Initiation Protocol", RFC 3261, June 2002. 1236 [2] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle 1237 Security for the Session Initiation Protocol (SIP)", RFC 4189, 1238 October 2005. 1240 [3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1241 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 1242 July 2004. 1244 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1245 Levels", RFC 2119, BCP 14, March 1997. 1247 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1248 June 1999. 1250 [6] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1251 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, 1252 May 1999. 1254 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1255 Specifications: ABNF", RFC 2234, November 1997. 1257 [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1258 Public Key Infrastructure Certificate and Certificate 1259 Revocation List (CRL) Profile", RFC 3280, April 2002. 1261 12.2. Informative References 1263 [9] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1264 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1265 Basic and Digest Access Authentication", RFC 2617, June 1999. 1267 [10] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1268 Identity Management in the Session Initiation Protocol (SIP)", 1269 RFC 4474, August 2006. 1271 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1272 Extensions (MIME) Part One: Format of Internet Message Bodies", 1273 RFC 2045, November 1996. 1275 [12] Hilt, V., Camarillo, G., and J. Rosenberg, "Session Initiation 1276 Protocol (SIP) Session Policies - Document Format and Session- 1277 Independent Delivery Mechanism", 1278 draft-ietf-sipping-session-indep-policy-02 (work in progress), 1279 February 2005. 1281 [13] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1282 November 2002. 1284 [14] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption 1285 Keys", RFC 3185, October 2001. 1287 [15] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP", 1288 draft-ono-sipping-keyreuse-smime-00 (work in progress), 1289 February 2004. 1291 [16] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1292 and D. Gurle, "Session Initiation Protocol (SIP) Extension for 1293 Instant Messaging", RFC 3428, December 2002. 1295 [17] Andreasen, F., Baugher, M., and D. Wing, "Session Description 1296 Protocol Security Descriptions for Media Streams", 1297 draft-ietf-mmusic-sdescriptions-11 (work in progress), 1298 June 2005. 1300 Authors' Addresses 1302 Kumiko Ono 1303 Columbia University 1304 Department of Computer Science 1305 New York, NY 10027 1306 USA 1308 Email: kumiko@cs.columbia.edu 1310 Shinya Tachimoto 1311 Network Service Systems Laboratories, NTT Corporation 1312 Musashino-shi, Tokyo 180-8585 1313 Japan 1315 Email: tachimoto.shinya@lab.ntt.co.jp 1317 Full Copyright Statement 1319 Copyright (C) The IETF Trust (2007). 1321 This document is subject to the rights, licenses and restrictions 1322 contained in BCP 78, and except as set forth therein, the authors 1323 retain all their rights. 1325 This document and the information contained herein are provided on an 1326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1328 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1329 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1330 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1333 Intellectual Property 1335 The IETF takes no position regarding the validity or scope of any 1336 Intellectual Property Rights or other rights that might be claimed to 1337 pertain to the implementation or use of the technology described in 1338 this document or the extent to which any license under such rights 1339 might or might not be available; nor does it represent that it has 1340 made any independent effort to identify any such rights. Information 1341 on the procedures with respect to rights in RFC documents can be 1342 found in BCP 78 and BCP 79. 1344 Copies of IPR disclosures made to the IETF Secretariat and any 1345 assurances of licenses to be made available, or the result of an 1346 attempt made to obtain a general license or permission for the use of 1347 such proprietary rights by implementers or users of this 1348 specification can be obtained from the IETF on-line IPR repository at 1349 http://www.ietf.org/ipr. 1351 The IETF invites any interested party to bring to its attention any 1352 copyrights, patents or patent applications, or other proprietary 1353 rights that may cover technology that may be required to implement 1354 this standard. Please address the information to the IETF at 1355 ietf-ipr@ietf.org. 1357 Acknowledgment 1359 Funding for the RFC Editor function is provided by the IETF 1360 Administrative Support Activity (IASA).