MSEC WG D. Ignjatic Internet-Draft L. Dondeti Expires: July 25, 2005 Nortel Networks January 21, 2005 An additional mode of key distribution in MIKEY draft-ignjatic-msec-mikey-rsa-r-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 July 25, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The MIKEY specification [2] describes several modes of key distribution to setup SRTP [4] sessions, viz., pre-shared key, public-key, and an optional Diffie-Hellman key exchange. In the public-key mode the initiator encrypts a random key with the responder's public key and sends it to the responder. In many VoIP calling scenarios, the initiator may not know the responder's public Ignjatic & Dondeti Expires July 25, 2005 [Page 1] Internet-Draft MIKEY RSAr January 2005 key or in some cases the responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. Conventions Used In This Document This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 [1]. Table of Contents 1. Revision History . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Outline . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Impact of the receiver choosing the TGK . . . . . . . . . . 4 4. A new MIKEY RSA mode . . . . . . . . . . . . . . . . . . . . . 5 5. Some specific additions to RFC 3830 . . . . . . . . . . . . . 6 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1 Normative References . . . . . . . . . . . . . . . . . . . 7 10.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Ignjatic & Dondeti Expires July 25, 2005 [Page 2] Internet-Draft MIKEY RSAr January 2005 1. Revision History 1. 00 Initial proposal to invite discussion on the problem and the proposal. 2. Problem description The MIKEY protocol (RFC 3830) has several three different methods for key transport or exchange: a pre-shared key mode (PSK), a public-key (RSA) mode and finally an optional Diffie-Hellman exchange (DHE) mode. The primary motivation in the design is efficiency and thus all the exchanges finish in .5 to 1 round-trips. The PSK mode might not scale to large deployments and the RFC includes a mechanism to bootstrap the PSK mode with the RSA mode. The DH mode is optional for various reasons, including because it does not support key download, as defined. The RSA mode while efficient, raises some deployment issues. In this mode, the Initiator selects a TEK Generation Key (TGK), encrypts and authenticates it with an envelope key and sends it to the Responder, as part of the first message, viz., I_MESSAGE. The Initiator also includes the envelope key, encrypted with the Responder's public key, in the same message. I_MESSAGE is replay protected with timestamps, and signed with the Initiator's public key. The Initiator's ID, CERT and the responder's ID that the Initiator intends to talk may be included in I_MESSAGE. If the Initiator knows several public-keys of the Responder, it can indicate the key used in a CHASH payload. However, there is no provision in MIKEY for the Initiator to initiate key download/establishment if it is unaware of the Responder's public key. 2.1 Motivation In many VoIP call scenarios, the Initiator may not have the Responder's public key handy. A possible solution might be to provision the Initiator with a mechanism and parameters (e.g., address of another entity) necessary to lookup any potential end-point. However, note that it might not be feasible for all deployments. Furthermore, in some cases, the Initiator might not even know the correct ID of the responder. For instance the Responder might have several IDs and phone numbers, and the Initiator might be willing to let the other party establish identity and prove it via an Initiator-trusted third party (e.g., CA). Ignjatic & Dondeti Expires July 25, 2005 [Page 3] Internet-Draft MIKEY RSAr January 2005 3. Solution Outline The proposed solution is fairly simple and requires only 1 round trip. Suppose the Initiator does not have access to the Responder's cert. We propose that the Initiator send a signed message to the intended Responder requesting the Responder to send the SRTP keying material. In this case I_MESSAGE would include the Initiator's CERT, and the responder can include its CERT in the R_MESSAGE. The Responder can use the Initiator's public key from the CERT in the I_MESSAGE to send the encrypted TGK in the R_MESSAGE. Upon receiving the R_MESSAGE, the Initiator can use the CERT in the R_MESSAGE to verify whether the Responder is in fact the party that it wants to communicate to. 3.1 Impact of the receiver choosing the TGK In MIKEY RSA or PSK modes, the Initiator chooses the TGK and the responder has the option to accept the key or not. The primary consideration for the Responder might be to verify whether the key is a known weak key (Q: Is this an issue with AES-CM or AES-f8 TBD). Other than that who chooses the key has no impact on SRTP (verify this). Thus, in case of one-to-one VoIP calls, there is no impact on the functionality provided by the MIKEY RSA mode and our modified mode being outlined earlier. Whereas MIKEY RSA mode allows R_MESSAGE to be optional, in the new mode, it is required. However, as noted earlier, the new mode allows simpler provisioning at the VoIP entity. More interestingly, the proposed mode supports group conferencing as well. First, it is clear that this mode requires that the Responder select the TGK and supply to the Initiator. Notice that this is quite similar to group key download as specified in GDOI [2], GSAKMP, and GKDP protocols (also see [5]. The catch however is that the participating entities must know that they need to contact a well-known address as far as that conferencing group is concerned. Note that they only need the Responder's ID, not necessarily its CERT. If the group members have the Responder's CERT, there is no harm; they simply do not need the CERT to compose I_MESSAGE. At the time of this writing, the authors' opinion is that this mode may not easily support 3-way calling, under the assumptions that motivated the design. Simply put, an extra message may be required compared to the original RSA mode specified in RFC 3830. Consider that A wants to talk to B and C, but does not have B's or C's CERT. A might contact B and request that B supply a key for a 3-way call. Now if B knows C's CERT, then B can simply use the MIKEY RSA mode (as defined in RFC 3830) to send the TGK to C. If not, then the solution Ignjatic & Dondeti Expires July 25, 2005 [Page 4] Internet-Draft MIKEY RSAr January 2005 is not straightforward. For instance, A might ask C to contact B or itself to get the TGK, in effect initiating a 3-way exchange. We will consider this case in detail in a future revision of this draft. 4. A new MIKEY RSA mode MIKEY RSA_R mode exchange is defined as follows: Initiator Responder --------- --------- I_MESSAGE = HDR, T, CERTi, [IDr], [SP], SIGNi --> R_MESSAGE = HDR, T, RAND, IDr|CERTr, {SP}, KEMAC, PKE, SIGNr Figure 1: MIKEY RSA_R mode The main objective of the Initiator's message is to present its public key/certificate to the Responder. The message also contains the timestamp (T) for replay protection, and optionally the Responder's identity (IDr) indicating the responder that the Initiator is interested in talking to. The optional SP payload allows the Initiator to specify its preferences of security parameters. I_MESSAGE is signed to protect against DoS attacks (should this be optional? Perhaps.) SIGNi is a signature covering the entire MIKEY message, using the Initiator's signature key (see Section 5.2 of RFC 3830 for the exact definition). This method requires a full roundtrip to download the TGKs. The response message uses the envelope approach where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key is sent to the Initiator encrypted with the public key of the Initiator. The PKE contains the encrypted envelope key: PKE = E(PKi, env_key). It is encrypted using the Initiator's public key (PKi). The KEMAC payload contains a set of encrypted sub-payloads and a MAC: KEMAC = E(encr_key, IDr || {TGK}) || MAC The first payload (IDr) in KEMAC is the identity of the Responder (not a certificate, but generally the same ID as the one specified in the certificate). Each of the following payloads (TGK) includes a TGK randomly and independently chosen by the Responder (and possible other related parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. of RFC 3830. The payload definitions Ignjatic & Dondeti Expires July 25, 2005 [Page 5] Internet-Draft MIKEY RSAr January 2005 are also specified in Section 6.2 of RFC 3830. Note that the V bit in the common header in this method still indicates a requirement for the Responder's authentication though since the Responder is responsible for generating the KEMAC a derived signature key cannot be used hence the optional CERTr and SIGNr should then be included. See Section 6.9 of RFC 3830 for payload definition. 5. Some specific additions to RFC 3830 Modified Table 6.1a from RFC 3830: Data type | Value | Comment ------------------------------------------------------------------ Pre-shared | 0 | Initiator's pre-shared key message PSK ver msg | 1 | Verification message of a Pre-shared key msg Public key | 2 | Initiator's public-key transport message PK ver msg | 3 | Verification message of a public-key message D-H init | 4 | Initiator's DH exchange message D-H resp | 5 | Responder's DH exchange message Error | 6 | Error message RSA_R I_MSG | 7 | Initiator's public-key message in RSA_R mode RSA_R R_MSG | 8 | Responder's public-key message in RSA_R mode Figure 2: Table 6.1a (Revised) 6. Conclusion We propose a new MIKEY RSA mode where the Responder is responsible for generating TGKs. This mode is motivated by deployment scenarios where the Initiator might not have the Responder's CERT handy, or has no easy way of obtaining it. The proposed mode requires a full round-trip, still uses timestamps for replay protection, and requires that both messages be signed by the sending entity. The proposed mode also supports group keying easily - in a similar fashion as the group key pull paradigm suggested in several group key distribution protocols designed by the MSEC WG. 7. Security Considerations We offer a brief overview of the security properties of the exchange. There are two messages, viz., I_MESSAGE and R_MESSAGE. I_MESSAGE is a signed request by an Initiator requesting the Responder to select a Ignjatic & Dondeti Expires July 25, 2005 [Page 6] Internet-Draft MIKEY RSAr January 2005 TGK to be used to protect SRTP session. The message is signed, which assures the Responder that the claimed Initiator has indeed generated the message. This automatically provides message integrity as well. There is a timestamp in I_MESSAGE, which when generated and interpreted in the context of the MIKEY specification assures the Responder that the request is live and not a replay. Indirectly, this also provides protection against a DoS attack. The Responder however would have to verify the Initiator's signature and the timestamp, and thus would spend significant computing resources. It is possible to mitigate this by caching recently received and verified requests R_MESSAGE is quite similar to the I_MESSAGE in the original MIKEY RSA mode and has all the same security properties. More TBD. 8. IANA Considerations TBD 9. Acknowledgments The scenario that motivated this design was the result of discussions between the authors and several people; the authors would like to especially Francois Audet's thoughts on this problem. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 10.2 Informative References [3] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [4] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", Ignjatic & Dondeti Expires July 25, 2005 [Page 7] Internet-Draft MIKEY RSAr January 2005 RFC 3711, March 2004. [5] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, "MSEC Group Key Management Architecture", Internet-Draft (Work in Progress) draft-ietf-msec-gkmarch-08, June 2004. Authors' Addresses Dragan Ignjatic Nortel Networks 250 Sidney St. Belleville, Ontario K8P3Z3 Canada Phone: Email: ignjatic@nortel.com Lakshminath Dondeti Nortel Networks 600 Technology Park drive Billerica, MA 01821 US Phone: +1 978 288 6406 Email: ldondeti@nortel.com Ignjatic & Dondeti Expires July 25, 2005 [Page 8] Internet-Draft MIKEY RSAr January 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Ignjatic & Dondeti Expires July 25, 2005 [Page 9] Internet-Draft MIKEY RSAr January 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ignjatic & Dondeti Expires July 25, 2005 [Page 10]