SIPPING K. Ono Internet-Draft S. Tachimoto Expires: January 19, 2006 NTT Corporation July 18, 2005 Key reuse in Secure MIME for the Session Initiation Protocol(SIP) draft-ono-sipping-smime-keyreuse-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The SIP User Agent uses Secure MIME (S/MIME) Cryptographic Message Syntax (CMS) EnvelopedData to protect SIP messages for confidentiality. While SIP messages can be encrypted with different keying materials for each message in a dialog, it usually requires a public key operation for each message and the computational cost of such operations are relatively expensive. This draft proposes a method of bidirectional key exchange to reuse keying materials for S/MIME-secured messages in a dialog and use a symmetric key mechanism Ono & Tachimoto Expires January 19, 2006 [Page 1] Internet-Draft Key reuse in S/MIME for SIP July 2005 instead of an asymmetric key mechanism such as a public key operation. The proposed mechanism also achieves the sharing of keying material among multiple entities simply. Conventions used in this document 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. Overview of Proposed Solution . . . . . . . . . . . . . . . . 3 2.1 Preparation for Reuse . . . . . . . . . . . . . . . . . . 4 2.2 Reuse CEK as KEK . . . . . . . . . . . . . . . . . . . . . 4 2.3 Lifetime of Key Reuse . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Example of Key Reuse in End-to-end Confidentiality . . . . 5 3.2 Example of Key Reuse in End-to-middle Confidentiality . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.1 Tampering "unprotectedAttrs" in CMS EnvelopedData . . . . 7 4.2 Eavesdropping by Un-participated Users . . . . . . . . . . 7 4.3 Decryption at Unspecified Proxy Server . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Ono & Tachimoto Expires January 19, 2006 [Page 2] Internet-Draft Key reuse in S/MIME for SIP July 2005 1. Introduction The SIP [2] User Agent (UA) supports S/MIME [3] CMS [4] EnvelopedData to encrypt the message body for its confidentiality. The CMS EnvelopedData contains content encrypted with a content encryption key (CEK) and the CEKs are encrypted with key encryption keys (KEKs). which are usually public keys of recipients. Although CMS EnvelopedData support symmetric keys, it is difficult to exchange a shared key between UAs prior to starting a dialog. Several messages are transmitted among UAs via proxy servers in a dialog. Since public key operations and asymmetric key mechanisms are usually required for each recipient and each message in a dialog, the computational cost of such operations are relatively expensive. In end-to-end confidentiality, a User Agent Client (UAC) firstly needs to obtains the public key certificate (PKC) of the User Agent Server (UAS) via the Credential Service [6] in order to encrypt the CEK of a request. Then the UAC needs to send a request with its own public key certificate (PKC), which is a relatively large amount of data, in order to make sure that the UAC can receive a response properly using the CMS EnvelopedData. If multiple UAs join the same dialog, all UAs need to send other UAs a request with its own PKC and send other UAs subsequent messages with multiple CEKs encrypted for the other UAs. (Although the initial UAC knows the PKCs of the other participants, the other participants do not know the PKCs each other.) These operations increase the data size of the messages by including the PKC and multiple CEKs. This draft proposes a method to reuse keying materials, that is based on [5], for effective encryption and decryption of messages in the SIP. Since the reuse mechanisms allow UAs to avoid public key operations except for the first message, UAs can generate and inspect CMS EnvelopedData with low computational cost. In addition, the reuse mechanism also achieves the sharing of keying materials among multiple entities including proxy servers in a simple way. It can also reduce the data size of the initial request, the number of KEKs in subsequent messages, and the complication of the end-to-middle security's specification. 2. Overview of Proposed Solution This proposed solution has three phases based on [5]. The first phase is preparing for a CEK to be reused as the KEK in a subsequent message. The second phase is reusing the KEK derived from a CEK in subsequent messages, while the CEK is updated for each message. The third phase is ending the reuse when a KEK is updated or the lifetime for key reuse ends. This phase needs some extra considerations when used in the SIP. Ono & Tachimoto Expires January 19, 2006 [Page 3] Internet-Draft Key reuse in S/MIME for SIP July 2005 2.1 Preparation for Reuse As described in [5], we need to set an identifier of a CEK, a symmetric key, to be reused as the KEK of the EnvelopedData in a subsequent message. A UA MUST include a key identifier of the CEK at a "CEKReference" in "unprotectedAttrs" attributes of the EnvelopedData to stipulate reuse of the CEK in subsequent messages. 2.2 Reuse CEK as KEK The following describes the method for KEK reuse, where the KEK is derived from a CEK. When the UAS receives EnvelopedData, the UAS MUST see the "CEKReference" attribute and detect the UAC's preferences to reuse the CEK in subsequent messages. If the "CEKReference" has a key identifier, the UAS MUST keep the pair of the key identifier and the CEK. If the response has the message body to be encrypted, the UAS MUST generate an EnvelopedData with a new CEK and the KEK derived by reversing the bytes of the CEK. The "recipientInfo" attribute of the CMS EnvelopedData MUST contain a "KEKRecipientInfo" type, which indicates a symmetric KEK is used. The UAS does not set a key identifier of the new CEK at a "CEKReference" attribute since the subsequent KEK is not reused with the new CEK. If a UAC has no knowledge whether the UAS supports this key reuse mechanism, the UAC is able to determine that the UAS supports key reuse and uses it by receiving the response with the "KEKRecipientInfo" type, instead with the "KeyTransRecipientInfo" type. If a UAC knows that the UAS supports and uses this key reuse mechanism, the UAC does not need to send its own PKC to the UAS. This is because the UAS can create the CMS EnvelopedData with a new CEK and the KEK derived from a CEK previously received from the UAC. If the UAS does not support this reuse mechanism, or for some reason cannot use it based on a policy, the UAS MUST generate an EnvelopedData with a new CEK and the KEK that is the UAC's PKC to encrypt a response. The "recipientInfo" attribute MUST contain a "KeyTransRecipientInfo" type, which indicates a public key is used. 2.3 Lifetime of Key Reuse The CEK can be reused until the KEK is updated or the maximum lifetime expires. The originator and recipients MUST maintain the set of the CEK, its key identifier, and the maximum lifetime until the reused CEK expires. In the SIP, the default value of the maximum lifetime of key reuse SHOULD equal to the time until the dialog ends. If the message that indicates the reuse of the CEK does not relate to any dialog, the maximum lifetime SHOULD equal to the transaction. Ono & Tachimoto Expires January 19, 2006 [Page 4] Internet-Draft Key reuse in S/MIME for SIP July 2005 This is a departure from [5]. In [5], the maximum lifetime of the CEK is indicated in a "CEKMaxDecrypts" attribute in the "unprotectedAttrs" field of EnvelopedData. If "CEKMaxDecrypts" is missing, or has the value "1", then each CEK will be reused once as the KEK for the next message. All UAs in a dialog SHOULD reuse the same CEK and maintain the maximum lifetime of the CEK. It increases the chances of reusing CEK and relatively simplify to maintain the reused CEK, though the UAs are unaware of the recipients of the encrypted message explicitly. Even though the effect of this reuse mechanisms is reduced, each UA MAY reuse its own CEK and maintain each maximum lifetime further securely. In this case, the UAS needs to know the UAC's PKC to encrypt the response. Each UA needs to maintain the set of the CEK, its key identifier, and the maximum lifetime for each participant in a dialog. Reusing the same key many times is weak from a security viewpoint. A UA MUST update the CEK before used in a certain times or a certain minutes, even while the dialog continues. If a UA wants to update the CEK in the next message before the expiry time ends, , the UA MUST generate CMS EnvelopedData with the key identifier of a new CEK in a "CEKReference" in the same method of the reuse preparation. If a UA wants to stop reusing the CEK immediately, the UA MUST generate CMS EnvelopedData with the recipient's PKC as the KEK. 3. Examples The following examples illustrate the use of the mechanism described in the previous section. 3.1 Example of Key Reuse in End-to-end Confidentiality When a UA needs to protect Session Description Protocol (SDP) in a message for end-to-end confidentiality, the messages that include the offer/answer procedures use the CMS EnvelopedData. The CEK is reversed the bytes and used as the KEKs in a dialog as illustrated in Figure 1. Ono & Tachimoto Expires January 19, 2006 [Page 5] Internet-Draft Key reuse in S/MIME for SIP July 2005 UAC -> UAS: INVITE E-CEK_1(Content), E-pub_key.UAS(CEK_1),CEK_1_id UAC <- UAS: 200 OK E-CEK_2(Content), E-CEK_1(CEK_2) UAC -> UAS: re-INVITE E-CEK_3(Content), E-CEK_1(CEK_3) UAC <- UAS: 200 OK E-CEK_4(Content), E-CEK_1(CEK_4) Figure 1: Example of Key Reuse in a Dialog for End-to-end Confidentiality E-CEK_n(Content) : Content encrypted using CEK_n E-pub_key.x(CEK_n): CEK_n encrypted using x's public key E-CEK_n(CEK_m) : CEK_m encrypted using CEK_n CEK_n_id : Key identifier of CEK_n in "CEKReference" 3.2 Example of Key Reuse in End-to-middle Confidentiality When a UA needs to protect SDP in a message for end-to-middle confidentiality that is concurrently with end-to-end one, the messages for the offer/answer procedures use the CMS EnvelopedData. The CEK is reused in a dialog as illustrated in Figure 2. UAC -> Proxy: INVITE E-CEK_1(Content), E-pub_key.UAS(CEK_1), E-pub_key.proxy(CEK_1), CEK_1_id Proxy -> UAS: INVITE E-CEK_1(Content), E-pub_key.UAS(CEK_1), E-pub_key.proxy(CEK_1), CEK_1_id Proxy <- UAS: 200 OK E-CEK_2(Content), E-CEK_1(CEK_2) UAC <- Proxy: 200 OK E-CEK_2(Content), E-CEK_1(CEK_2) UAC -> Proxy: re-INVITE E-CEK_3(Content), E-CEK_1(CEK_3) Proxy -> UAS: re-INVITE E-CEK_3(Content), E-CEK_1(CEK_3) Proxy <- UAS: 200 OK E-CEK_4(Content), E-CEK_1(CEK_4) UAC <- Proxy: 200 OK E-CEK_4(Content), E-CEK_1(CEK_4) Ono & Tachimoto Expires January 19, 2006 [Page 6] Internet-Draft Key reuse in S/MIME for SIP July 2005 Figure 2: Example of Key Reuse in a Dialog for End-to-middle Confidentiality 4. Security Considerations This mechanism allows UAs to encrypt a message with a symmetric key instead of the recipient's PKC. In exchange of getting relatively low computational cost, UAs encrypt a message for unspecified recipients in a signaling path. Followings are some threat models and the prevention. 4.1 Tampering "unprotectedAttrs" in CMS EnvelopedData This mechanism set a key identifier of the CEK to be reused at "CEKReference" in "unprotectedAttrs" where is neither encrypted nor signed in CMS EnvelopedData. Anyone could generate the CMS EnvelopedData with the same key identifier at the "CEKReference". The recipient MUST NOT assume that using the right CEKReference means that message originator is genuine. Even when someone modifies the key identifier in the CMS EnveloedData, the CEK value in the initial message is not decipherable by others than the recipients specified with their PKCs. Although the reused mechanism does not work in the subsequent messages, the UAs can detect the modification with the error condition. 4.2 Eavesdropping by Un-participated Users When an INVITE message is forked to multiple users, all users receiving the forked INVITE message receive a CEK which is to be used as KEK. Depending the connection policy of the forking proxy server, all recipients do not always participate the dialog. Although some users participate in the dialog, the CEK is passed onto the others who do not participate in the dialog. This allows users who are not participating in the dialog to eavesdrop, even though the subsequent messages are encrypted, since the CEK in INVITE is used as the KEK in the messages. When this key reuse mechanism is used in a conference call where multiple users participate, all participates share the same CEK and reuse it as KEK. Even after a participant left, the ex-participant is allowed to eavesdrop the conference call. To prevent the un-participated users from eavesdropping, a UA SHOULD NOT reuse the CEK sent in an INVITE message, since there is no way for the UA to know if a forking proxy is in the signaling path. A UA Ono & Tachimoto Expires January 19, 2006 [Page 7] Internet-Draft Key reuse in S/MIME for SIP July 2005 SHOULD update the KEK with a new CEK by sending a re-INVITE or UPDATE message to the participants. In the case of conference, conference participants MAY update the CEK every time the participants change. 4.3 Decryption at Unspecified Proxy Server When a UAC encrypt an INVITE message for the UAS and a proxy server, the proxy server receives a CEK which is to be used as KEK. This allows the proxy server to decrypt the message from the UAS who doest not know the capability of the proxy server, even though the UAC permits the proxy server to decrypt it. To prevent unspecified proxy server to decrypt, each UA SHOULD NOT share the reused CEK, and SHOLD maintain the reused CEK separately. 5. IANA Considerations This document introduces no additional considerations for IANA. 6. Acknowledgments The authors would like to thanks to Cullen Jennings, Jim Schaad, and Kenichi Osuga for their support. 7. References 7.1 Normative 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] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. [4] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [5] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption Keys", RFC 3185, October 2001. 7.2 Informative References [6] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", Internt-Draft draft-ietf-sipping-certs-01, February 2005. Ono & Tachimoto Expires January 19, 2006 [Page 8] Internet-Draft Key reuse in S/MIME for SIP July 2005 [7] Ono, K. and S. Tachimoto, "End-to-middle Security in the Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-00 (work in progress), July 2005. 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 January 19, 2006 [Page 9] Internet-Draft Key reuse in S/MIME for SIP July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ono & Tachimoto Expires January 19, 2006 [Page 10]