Internet DRAFT - draft-ono-sipping-smime-keyreuse
draft-ono-sipping-smime-keyreuse
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]
