SIPPING K. Ono Internet-Draft S. Tachimoto Expires: November 15, 2004 NTT Corporation May 17, 2004 End-to-middle Security in the Session Initiation Protocol(SIP) draft-ono-sipping-end2middle-security-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Some services provided the intermediaries depend on the ability to inspect the message bodies in the Session Initiation Protocol (SIP). When sensitive information is included in them, a SIP User Agent needs to protect it from all intermediaries except the certain selected intermediaries. This document proposes a mechanism for securing information passed between an end user and a selected intermediary using S/MIME. This also proposes a mechanism for the discovery of an intermediary that needs to inspect an S/MIME-secured message body. Conventions used in this document Ono & Tachimoto Expires November 15, 2004 [Page 1] Internet-Draft End-to-middle security in SIP May 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Generating S/MIME CMS Data . . . . . . . . . . . . . . . . . . 3 3. Indicating the Target Content . . . . . . . . . . . . . . . . 4 4. Discovery of the Proxy Server's Policies . . . . . . . . . . . 5 5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . . 6 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Content-Target Header Field Use . . . . . . . . . . . . . . . 8 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 Request Example for End-to-Middle Confidentiality . . . . . . 8 7.2 Request Example for End-to-Middle Integrity . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Ono & Tachimoto Expires November 15, 2004 [Page 2] Internet-Draft End-to-middle security in SIP May 2004 1. Introduction When a SIP [2] UA requires services that are provided by intermediaries depending on the message bodies in request/response messages, end-to-end confidentiality will currently have to be disabled to take advantage of the services. This problem is pointed out in Section 23 of [2]. Since such an intermediary is not always adjacent to the UA, this situation requires security between the UA and the intermediary for the message bodies. We call this "end-to-middle security", where by "end" we mean a UA and by "middle" we mean a specific intermediary, typically a proxy server. This document describes proposed mechanisms to provide data confidentiality and integrity for end-to-middle security to meet the requirements discussed in [3]. Since the major requirement is to have little impact on the standardized end-to-end security mechanisms, the proposed mechanisms are based on S/MIME [4]. The mechanisms consist of generating S/MIME CMS [5] data and indicating target message body for a selected proxy server. In addition, it also includes a mechanism for the discovery of selected proxy servers. 2. Generating S/MIME CMS Data For end-to-middle confidentiality, a UAC MUST be able to generate S/ MIME CMS EnvelopedData, whose recipients are specified in the "recipientInfos" field. The structure of the S/MIME CMS EnvelopedData contains data encrypted with a content-encryption-key (CEK) and the CEK encrypted with different key-encryption-keys (KEKs), one for each recipient as specified in [5]. The KEKs are the public keys of each recipient or the shared keys between the UAC and each recipient. If the data is encrypted only for a selected proxy server, the recipients contain only the proxy server. If there is encrypted data for destined for different proxy servers, the recipient list of each encrypted piece of data will contain the targeted proxy servers. The UAC MUST generate a multipart MIME body to contain the encrypted data. When the message body including the encrypted data is transmitted to a UAS, the UAS will be unable to decrypt it. The UAC MUST set the value "optional" in the handling parameter of the Content-Disposition MIME header for the message body in order to avoid causing unneeded error condition in the UAS. Open Issue: Is it necessary that a multipart MIME body contains the handling parameter of Content-Disposition header? How should it be set when the multipart MIME body contains a body with the value "required" and another body with the value "optional"? If the encrypted data is meant to be shared with the UAS and selected proxy servers, the recipients SHOULD be addressed to the UAS and Ono & Tachimoto Expires November 15, 2004 [Page 3] Internet-Draft End-to-middle security in SIP May 2004 selected proxy servers. The UAS SHOULD decrypt the message body including the encrypted data. The UAC SHOULD set the value "required" in the handling parameter of the Content-Disposition MIME header for the message body. If the handling parameter is not set, the default behavior is the same as setting the value "required" as specified in [2] If an encrypted piece of data is destined for a selected proxy server and another encrypted data is for the UAS, the recipient of each encrypted data is each entity. In this case, the UAC MUST generate them part of a multipart MIME body. For example, UAs use this method when keying materials, such keys for use by Secure RTP (SRTP), are included in the SDP[6]. One CMS EnvelopedData body contains SDP that includes keying materials of an SRTP stream only for the UA. The other EnvelopedData body contains an SDP that does not include the keying materials of an SRTP stream only for a selected proxy server that needs to view SDP (i.e.: for a firewall traversal service). For end-to-end data integrity, UAs use S/MIME CMS SignedData body that can be validated by any entity. Therefore no new CMS SignedData generating mechanism is required for end-to-middle data integrity. Note: Even when the handling parameter is set to the value "optional", the UAS SHOULD validate the signature of whole MIME body, since Content-Disposition might be modified by a malicious entity. 3. Indicating the Target Content UAs needs a way to indicate the target of the content in order that a proxy server can easily determine whether to process S/MIME bodies and if so, which one. The UA SHOULD set a new "Content-Target" MIME header to label the target message body for a selected proxy server. When UAs label the encrypted data, the UA SHOULD set the "Content-Target" MIME header of the S/MIME CMS EnvelopedData. When UAs label the data with signature, the UA SHOULD set the "Content-Target" MIME header of the S/MIME CMS SignedData. When proxy servers receive a message, the proxy server SHOULD inspect the "Content-Target" MIME header. UAs SHOULD generate a digital signature of whole message body including the "Content-Target" MIME header in order to protect the indication. The proxy server SHOULD validate the signature of whole message body to check the integrity of the indication, even when the "Content-Target" MIME header is not set to whole message body. This method of indicating the target has less of an impact on proxy Ono & Tachimoto Expires November 15, 2004 [Page 4] Internet-Draft End-to-middle security in SIP May 2004 servers that do not support end-to-middle security because these proxy servers do not inspect the MIME header anyway. Also there is less of an impact on UAs that do not support this MIME header, because the UAs will ignore irrelevant MIME headers. Note: In the last version of this proposal, we used a new parameter in "Content-Disposition" MIME header. As pointed out, the semantic of the header is ambiguous. A new MIME header is better. Note: There is an alternative option, the use of a new SIP header. This proposed mechanism puts more load on proxy servers to determine the necessity of MIME body handling than using a new SIP header would. However, the proxy can view the indicated MIME body more effectively than using a new SIP header. Also, the validation cost for integrity protection of these headers reduces the merit on using a new SIP header. For the integrity protection of SIP headers, a message body that is application/sipfrag [7] needed. In addition, using a new SIP header could have a negative impact on intermediary proxy servers that do not support end-to-middle security, causing unnecessary processing load. We feel that this MIME header mechanism is not as simple, but it is equally effective. 4. Discovery of the Proxy Server's Policies A discovery mechanism for proxy server's policies is needed when UAs do not know the policies of the proxy server in a signaling path and the proxy server has its own policy for providing some services. When the proxy server receives a request in which it cannot view some data that must be read in order to proceed or the proxy server receives a request whose sending policy cannot be accepted, the proxy MUST send a response with an error code. If the request is in plain text, the error code SHOULD be 403 (Forbidden) accompanied with a required Content-Type, such as "application/sdp". If the request is in plain text and the digital signature of it is required for an integrity check, the error code SHOULD be 403 (Forbidden) accompanied with a required Content-Type that is "multipart/signed". Open Issue: How does the error message indicate the Content-Type to be attached with a signature? Can these Content-Type be nested such as "Content-Type: multipart/signed" for "Content-Type: application/sdp"? Is it better to define a new error code for requiring a signature attachment? If the request contains encrypted data, the error code SHOULD be 493 (Undecipherable), accompanied with a proxy's public key certificate and required Content-Type. Open Issue: Instead of 493, SHOULD it be 403 that is the same as for requiring a signature attachment? When proxy servers require both of disclosure and the integrity check, how will it be Ono & Tachimoto Expires November 15, 2004 [Page 5] Internet-Draft End-to-middle security in SIP May 2004 described? When the UAC receives one of the above error codes, the UAC needs to authenticate the proxy server. Therefore, the error code SHOULD contain the digital signature of the proxy server. In the worst case, this discovery mechanism requires two messages for each proxy server in the signaling path to establish a session between the UAs. In addition, it requires validation procedures using the digital signatures for all proxy servers. Since this causes a increase in the delay before session establishment, it is recommended that UAs learn in advance the policies of as many proxy servers as they can. Open Issue: How does this mechanism apply in the case when a proxy server needs to inspect the message body contained in the response? This might be happen when the SDP offer/answer is done with 200/ACK messages. 5. Behavior of UAs and Proxy Servers We describe here an example of the behavior of UAs and proxy servers in a model in which a proxy server that provides logging services for instant messages exists in a message path as shown in Figure 1. +-----+ +-----+ +-----+ +-----+ | C |-----| C |-----| * |-----| C | +-----+ +-----+ +-----+ +-----+ UA #1 Proxy #1 Proxy #2 UA #2 w/Logging function C: Content that UA #1 allows the entity to inspect *: Content that UA #1 prevents the entity from inspecting Figure 1: Deployment example 5.1 UAC Behavior When a UAC sends an MESSAGE [8] request including encrypted message content for end-to-end and end-to-middle confidentiality, it MUST use S/MIME CMS EnvelopedData to encrypt them. In this example, UA #1 is assumed to know the services and the public key of Proxy #1. UA #1 MUST use CMS EnvelopedData for UA #2 and Proxy #1. UA #1 SHOULD specify Proxy #1 in the "Content-Target" MIME header of the message body to be decrypted. When the UAC sends a request and needs end-to-end and end-to-middle integrity for the message body, it MUST use S/MIME CMS SignedData to Ono & Tachimoto Expires November 15, 2004 [Page 6] Internet-Draft End-to-middle security in SIP May 2004 attach a digital signature. In this example, UA #1 MUST use the CMS SignedData of the contents. UA #1 SHOULD specify Proxy #1 in the "Content-Target" MIME header of the signature to be validated. When the UAC sends multiple requests to the UAS, the CEK reuse mechanism is beneficial that UAs efficiently encrypt/decrypt data. The CEK reuse mechanism is described in [9][10]. the UAC SHOULD uses the "unprotectedAttrs" field to stipulate reuse of the CEK and indicate its identifier. When the UAC reuses the CEK in the previous request as the KEK, the UAC generate CMS EnvelopedData with the type "KEKRecipientInfo" of "RecipientInfo" attribute. 5.2 UAS Behavior When a UAS sends a response for the request with this mechanism, using the same type of S/MIME CMS data is recommended. For example, if the UAS receives an INVITE request in which the SDP is encrypted by using CMS EnvelopedData body, the response is RECOMMENDED to be a "200 OK" containing the encrypted SDP based on CMS EnvelopedData body. In the above example, however, the response of the MESSAGE request does not need to use the same type of S/MIME CMS data, since the response does not contain the message content. In particular, when the CMS EnvelopedData body of the request contains the "unprotectedAttrs" attribute specifying reuse of the CEK, the UAS SHOULD keep the CEK with the identifier specified in the "unprotectedAttrs" attribute. When the UAS receives a request that uses S/MIME, it decrypts and/or validates the S/MIME bodies as usual. Even when the UAS receives the request without this mechanism, UAS MAY need end-to-end and end-to-middle confidentiality of the message bodies and/or headers in the response. In this case, the UAS MUST use CMS EnvelopedData to encrypt them. When the UAS sends a response and needs end-to-end and end-to-middle integrity of the message bodies and/or headers, it MUST use CMS SignedData to attach a digital signature. This is the same way the UAC normally performs with this mechanism. 5.3 Proxy Behavior When a proxy supporting this mechanism receives a message, the proxy server MUST inspect the "Content-Target" MIME header. If the MIME header includes the processing server's own name, the proxy server MUST inspect the specified body. When the specified body is CMS EnvelopedData, the proxy server MUST Ono & Tachimoto Expires November 15, 2004 [Page 7] Internet-Draft End-to-middle security in SIP May 2004 inspect it and try to decrypt the "recipientInfos" field. If the proxy server fails to decrypt that, it SHOULD cancel the subsequent procedure and respond with a 493 (Undecipherable) response if it is a request, or any existing dialog MAY be terminated. If the proxy server succeeds in this decryption, it MUST inspect the "unprotectedAttrs" field of the CMS EnvelopedData. If the attribute gives the key's identifier, the proxy server MUST keep the CEK with its identifier until the lifetime of the CEK is expired. When it receives subsequent messages within the lifetime, it MUST try to decrypt the type "KEKRecipientInfo" of "RecipientInfo" attribute by using this CEK. When the specified content is CMS SignedData body, the proxy server MUST inspect it and validate the digital signature. If the verification is failed, the proxy server SHOULD reject the subsequent procedure and respond with a 403 (Forbidden) response if the message is a request, or any existing dialog MAY be terminated. When the proxy server forwards the request, it modifies the routing headers normally. It does not need to modify the S/MIME body. If a proxy does not support this mechanism and receives a message with the "Content-Target" MIME header, the proxy MUST ignore the header and perform as usual. 6. Content-Target Header Field Use The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [11]. The new header "Content-Target" is defined as a MIME header. Content-Target = "Content-Target" HCOLON target-entity target-entity = proxy-uri *(COMMA proxy-uri) proxy-uri = ( name-addr / addr-spec ) 7. Examples The following examples illustrate the use of the mechanisms defined in the previous sections. 7.1 Request Example for End-to-Middle Confidentiality In the following example, a UA needs the message content in a MESSAGE request to be confidential and the UA allows a selected proxy server to view the message content. The UA also needs to protect the label of the target content. In addition, the UA needs to reuse the CEK in the subsequent request messages. In the example encrypted message Ono & Tachimoto Expires November 15, 2004 [Page 8] Internet-Draft End-to-middle security in SIP May 2004 below, the text with the box of asterisks ("*") is encrypted: MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com MESSAGE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 MESSAGE Date: Fri, 20 June 2003 13:02:03 GMT Content-Type: multipart/signed;protocol="application/pkcs7-signature"; micalg=sha1;boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: binary Content-Disposition: attachment;filename=smime.p7m Content-Target: ss1.atlanta.example.com Content-Length: ... ****************************************************************** * (encryptedContentInfo) * * Content-Type: text/plain * * Content-Length: ... * * * * Hello. * * This is confidential. * * * * (recipientInfos) * * RecipientInfo[0] for ss1.atlanta.example.com public key * * RecipientInfo[1] for bob's public key * * * * (unprotectedAttrs) * * CEKReference * ****************************************************************** --boundary1-- Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: binary Content-Disposition: attachment; filename=smime.p7s;handling=required Ono & Tachimoto Expires November 15, 2004 [Page 9] Internet-Draft End-to-middle security in SIP May 2004 [binary data] --boundary1-- 7.2 Request Example for End-to-Middle Integrity In the following example, a UA needs the integrity of the message content in a MESSAGE request to be validated by a selected proxy server. The UA also needs to protect the label of the target content. MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com MESSAGE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 MESSAGE Date: Fri, 20 June 2003 13:02:03 GMT Content-Type: multipart/signed;protocol="application/pkcs7-signature"; micalg=sha1;boundary=boundary1 Content-Length: ... --boundary1 Content-Type: text/plain Content-Length: ... Hello. This is protected with the signature. --boundary1-- Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: binary Content-Target: ss1.atlanta.example.com Content-Disposition: attachment; filename=smime.p7s;handling=required [binary data] --boundary1-- Ono & Tachimoto Expires November 15, 2004 [Page 10] Internet-Draft End-to-middle security in SIP May 2004 8. Security Considerations TBD. 9. IANA Considerations This document requires a new "Content-Target" MIME header. 10. Acknowledgments Thanks to Rohan Mahy and Cullen Jennings for their initial support of this concept, and to Jon Peterson for his helpful comments. Jonathan Rosenberg gave us a useful comment. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Ono, K. and S. Tachimoto, "Requirements for end-to-middle security in the Session Initiation Protocol (SIP)", draft-ietf-sipping-e2m-sec-reqs-02 (work in progress), May 2004. [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1992. [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [6] Andreasen, F., Baugher, M. and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-03.txt (work in progress), February 2004. [7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [9] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption Keys", RFC 3185, October 2001. Ono & Tachimoto Expires November 15, 2004 [Page 11] Internet-Draft End-to-middle security in SIP May 2004 [10] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP", draft-ono-sipping-keyreuse-smime-00 (work in progress), February 2004. [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Authors' Addresses Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan EMail: ono.kumiko@lab.ntt.co.jp Shinya Tachimoto Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan EMail: tachimoto.shinya@lab.ntt.co.jp Ono & Tachimoto Expires November 15, 2004 [Page 12] Internet-Draft End-to-middle security in SIP May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Ono & Tachimoto Expires November 15, 2004 [Page 13] Internet-Draft End-to-middle security in SIP May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ono & Tachimoto Expires November 15, 2004 [Page 14]