INTERNET DRAFT Kavita Jain Category: Informational Mitel Networks Title: draft-jain-sipping-srtp-00.txt John Albert Date: August 2003 Mitel Networks February, 2004 Using SRTP with SIP 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 in February, 2004. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 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 BCP 14, RFC 2119 [KEYWORD]. Abstract The Secured Real Time Protocol (SRTP) is a lightweight protocol that secures voice data between two end points. The Session Initiation Protocol (SIP) is a simple and adaptive session-controlling protocol. Efforts have been underway to get these two protocols working together. Several ideas have been presented in different documents in past. This document describes one more way to accomplish this task. The proposed approach is simple and does not consume too much CPU cycles. However, some assumptions need to be made in lack of the specific SIP and SDP fields. 1 Introduction In order to secure voice data using SRTP[1], peers exchange SRTP parameters during call establishment. The most important parameter is encryption/decryption key. The key must be secured and correct. If SIP[2] is being used to establish the session, the key needs to be exchanged in SIP messages. This document first addresses the issues involved and then explains the assumptions that need to be made. This is being followed by the detail of how the proposed way exploits the currently available SIP/SDP[3] fields to accomplish the task. 2 Issues Currently, SIP message does not have a field to transport a key to encrypt/decrypt media. The SDP payload of a SIP message provides the ôkö field to exchange the keys for the media. However, the content of the ôkö field can be either clear text, or encrypted with Basic encryption. Another approach is to store the key at a secured website and send the web site URL in the ôkö field. The latter approach is a secured one, but it has the following disadvantages: a) A lengthy process of obtaining a key b) Maintenance of keys at the website c) Maintenance of the website itself Therefore, the proposed idea to exchange keys suggests sending keys in the ôkö field of the SDP payload in clear text. The key can be Basic encrypted. 3 Assumptions In lack of the specific SIP and SDP fields, the following assumptions need to be made: a) The key is a 64-bit Diffie-Hellmann (DH) [4] key b) Encryption/decryption algorithm is DES [5] c) The Initiation Vector (IV) can be derived by performing a bit-wise operation (say OR or XOR) between the public part of the key and a default IV mask. Or it can have a default value d) The prime number to generate a DH key has a default value e) The ôbaseö number to generate the DH key has a default value NOTE: These assumptions can later be defined as the default values of the fields, once fields are being defined. 4 The Proposed Approach The basic idea is that the public part of a DH key can be exchanged safely in clear text using the ôkö field in SDP payload of a SIP message. Before sending an INVITE message, the caller will generate its DH key. The caller would send its public key in the SDP payload of the INVITE SIP message so that the callee would know that the caller has SRTP capability. The callee will generate its own DH key and will send its public key in its own SDP payload in the ô200 OKö SIP message. Now, each peer will have an ôownö key that it itself has generated and a ôpeerö key that it has received from the peer. With these two kinds of keys, the two ends will calculate the ôSRTPö key to encrypt and decrypt the voice data. Each side will calculate its encryption/decryption IV by performing a bit-wise operation between the IV mask and ôownö/ôpeerö public key, respectively. The DES algorithm will be configured with the ôSRTPö key and the encryption/decryption IVs. DES algorithm can be run on voice data either in hardware or software. An SRTP connection will be in affect only if both parties send their keys. Otherwise, it will be assumed that the peer does not support SRTP and voice data will not be encrypted. 5 References [1] Baugher, M., Carrara, E., McGrew, D. A., Nausland, M., and Norrman, K. "The Secure Real-time Transport Protocol" IETF, Work in Progress. [2] Rosenberg, J, Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP: Session Initiation Protocol" RFC 3261, June 2002. [3] Handley, M. and Jacobson, V,. "SDP: Session Description Protocol", RFC 2327, April 1998. [4] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). 6 Acknowledgements The authors would like to thank Lee Dilkie and Mark Baugher for sharing their expert thoughts and knowledge. 7 Authors' Addresses Kavita Jain Mitel Networks 350 Legget Drive Kanata, ON Canada, K2K 2X3 phone: +1 613-592-2122 E-mail: kavita_jain@mitel.com John Albert Mitel Networks 350 Legget Drive Kanata, ON Canada, K2K 2X3 Phone: +1 613-592-2122 E-mail: john_albert@mitel.com 8 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 docu- ment 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 develop- ing 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 lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS 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. 9 Expiration Date This memo is filed as and expires in February, 2004.