Shyam Pallapothu Internet-Draft Sunil Mahajan Expires: Aug 19, 2007 ARICENT Feb 19, 2007 Selective Encryption Support in SRTP draft-smahajan-srtp-selective-encryption-01.txt 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 Aug 19, 2007. Copyright Notice Copyright (C) The IETF TRUST (2007). Abstract Selective Encryption is good mechanism to improve performance of devices that support media encode/decode and transport and still meets basic requirement of confidentiality. SRTP is one of the popular mechanism used to support confidential media transport over IP channels. This draft suggests some enhancements to SRTP protocol management to enable SRTP to support "Selective Encryption". Sunil Mahajan Expires Aug 19, 2007 [Page 1] Internet-Draft SRTP Selective Encryption Aug 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Selective Encryption in SRTP . . . . . . . . . . . . . . . . 5 2.1 Method-1 -> MKI overloading . . . . . . . . . . . . . . . . 5 2.1.Security Context . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2.Key Exchange Protocol . . . . . . . . . . . . . . . . . . 6 2.2 Method-2 -> Additional Paremeter in SRTP . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . 10 Sunil Mahajan Expires Aug 19, 2007 [Page 2] Internet-Draft SRTP Selective Encryption Aug 2007 1. Introduction It is clearly understood that to support media transport over IP networks transport protocols would need to support confidentiality and integrity of data, as these transports are typically shared access media for multiple users and are open to different kind of security attacks, unlike traditional PSTN networks where access and network transport is inherently and physically secured from malicious use. To support such requirements media transport shall provide mechanisms to encrypt and protect integrity of the user data. To achieve such requirements SRTP protocol is proposed to be used which is another profile of RTP protocol. SRTP provides all the required features for media communication over insecure and shared IP networks. However since most of these media communications originate from handheld devices like mobile phones or even fixed phones, processing power requirements at these devices to encrypt the complete media stream also increases which poses its own challenges. To avoid high processing requirements at these devices "Selective Encryption" techniques can be used. Also for network devices which originate or terminate large number of media streams, processing power required to encrypt each media stream will contribute a large amount of CPU and memory requirements for these devices and increases their cost. Selective Encryption: It is a method where part of the media stream is encrypted and other part is left unencrypted. There are 2 criterions which can be used to decide which parts of the media stream shall be encrypted and what parts can be left unencrypted. Scheme-1: This scheme depends on the mix of media available during a media based communication. In such communications there are generally more than one media contents mixed and their security requirements are also different. One media component requires high security, whereas other component might require less or no encryption at all. Such media streams can exploit selective encryption schemes to get benefits both on network devices and on user devices. Example of such media communications include 1) A video broadcast of a football match where contents of live match are encrypted and all the intermediate advertisement contents need not be encrypted. 2) A user while interacting with an IVR application would need his Sunil Mahajan Expires Aug 19, 2007 [Page 3] Internet-Draft SRTP Selective Encryption Aug 2007 communication with operator and any data that he supplies to system to be encrypted whereas all the recorded announcements need not be encrypted. Scheme-2: Unencrypted parts are such components of the media stream which can not be used by any kind of attacker to create original stream. Either the processing power required to created original stream is very very high or time needed is very large. Such schemes might have different level of security available to overall scheme dependig upon how unencrypted components are chosen. An application developer can choose level of security needed and hence the components to be used for unencrypted parts. Examples of such scheme include that the parts to be encrypted depends on the type of media and compression schemes used for media transport. It is required that sufficient information is encrypted so that any evesdroper should not be able to reconstruct the complete stream. E.g. for video transport, I frames are encrypted and others are sent in un-encrypted format. However it should be well understood by the application developer that the type of scheme used will determine level of security for the media stream. Some of the examples where level of security requirements is less are - 1) VoIP communication within enterprise environment, 2) Free VoIP Calls offered by internet service providers etc. Please note that by using such schemes, security or confidentiality does not go away completely but it is less as compared to full encryption support. However people expert on security can determine more appropriate method of choosing unencrypted components to make selective encryption relatively more secure. There are various research papers published on the benefits of Selective Encryption but still there are differing opinions on the usefulness of selective encryption. However the biggest benefit for IP based communication from handheld devices point of view is low processing power requirements and this is a good enough benefit for selective encryption to be considered. For network nodes which process large number of encrypted media streams, selective encryption can play an important role there too. Use of selective encryption shall be optional to the user and device and for critical projecs or communication needs where confidentiality is of prime importance, it shall not be used, however for other form of normal communication needs, it can be used. Current definition of SRTP protocol does not support selective Sunil Mahajan Expires Aug 19, 2007 [Page 4] Internet-Draft SRTP Selective Encryption Aug 2007 encryption. This draft proposes a method using which selective encryption can be supported. There are 2 ways to add support for selective encryption in SRTP 1) without changing the syntax of the protocol 2) Adding explicit support for selective encryption in SRTP protocol. This draft proposes both the methods and leaves it to working group to decide which is a better method. 2. Selective Encryption in SRTP Basic requirement in selective encryption is to encrypt some media packets and not encrypt some other. This requires that every packet shall carry an indicator which indicates whether packet is encrypted or not. This does not interfere with other security requirements, like message integrity or authentication of source etc. The first proposed method is based on MKI parameter overloading and second method is based on adding additional parameter to SRTP. 2.1 Method-1 -> MKI overloading SRTP uses a parameter called MKI (Master Key Index) which is an optional parameter in every SRTP packet and indicates the index of the master key in use. Current definition of SRTP protocol defines security context at both the ends of the communication which is established using other(other than SRTP)mechanisms and also creates Master Key. Master key is used to create session keys for encryption and integrity. SRTP allows multiple Master Keys to be used to provide enhanced security features where Master Key can be changed during media communication over SRTP by indicating different MKI value in the SRTP stream. Current definition of SRTP does not include encryption (cipher) algorithm to be part of Master Key Index, so basically while establishing security context at both ends of the communication, cipher algorithm is negotiated and multiple master keys are established and all the keys uses same cipher suite. SRTP also allows NULL encryption to be supported as valid cipher algorithm. If we change SRTP definition by linking encryption algorithm to the Master Key and each Master Key can hold its own cipher algorithms, SRTP can support selective encryption without changing protocol syntax. In order to support selective encryption between two endpoints, Sunil Mahajan Expires Aug 19, 2007 [Page 5] Internet-Draft SRTP Selective Encryption Aug 2007 security context establishment shall establish at least two master keys (which means two MKI values as well) and one of the master key carries a cipher algorithm and other one uses NULL Cipher. During RTP packet processing by SRTP stack, if encryption for that packet is needed, MKI value will be set to the one that has cipher algorithm attached and if encryption is not needed, MKI value will be set to one that has NULL Cipher. 2.1.1 Security Context Security context at each endpoint will change as per this new definition. Key material params (for each master key): SRTP and SRTCP encr transf. AES_CM/NULL AES_CM master key length 128 128 n_e (encr session key length) 128 128 n_a (auth session key length) 160 160 master salt key length of the master salt 112 112 n_s (session salt key length) 112 112 key derivation rate 0 0 key lifetime SRTP-packets-max-lifetime 2^48 2^48 SRTCP-packets-max-lifetime 2^31 2^31 from-to-lifetime MKI indicator 0 0 length of the MKI 0 0 value of the MKI Above table is modified table from RFC3711 section 8.2. 2.1.2 Key exchange protocol This new definition of SRTP protocol will also require changes to key exchange protocols like RFC4568 (Security Descriptions for Media Streams). For example crypto parameter as per RFC4568 shall be part of key definition. Following example is only suggestive and does not define the required syntax. (example is taken from RFC4568 section 7.1.5.) Sunil Mahajan Expires Aug 19, 2007 [Page 6] Internet-Draft SRTP Selective Encryption Aug 2007 v=0 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 s=SRTP Discussion i=A discussion of Secure RTP u=http://www.example.com/seminars/srtp.pdf e=marge@example.com (Marge Simpson) c=IN IP4 168.2.17.12 t=2873397496 2873404696 m=audio 49170 RTP/SAVP 0 a=crypto:1 F8_128_HMAC_SHA1_80 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; crypto:1 AES_CM_128_HMAC_SHA1_80 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 FEC_ORDER=FEC_SRTP For two endpoints agreeing to use selective encryption, one of the key parameter shall carry NULL Cipher and NULL key. 2.2 Method-2 -> Additional Paremeter in SRTP In this proposal there is an explicit parameter in each SRTP packet which indicates whether the payload is encrypted or not. This parameter is optional and the presence is indicated during key exchange by using the same mechanism as used for the presence of MKI paremeter in the payload. So if a particular communication does not require selective encryption, this parameter will not be present in SRTP packet. If selective encryption is used this parameter can be used to indicate whether packet is encrypted or not. Sunil Mahajan Expires Aug 19, 2007 [Page 7] Internet-Draft SRTP Selective Encryption Aug 2007 Extension to SRTP is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing source (CSRC) identifiers | | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP extension (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |E| FOR FUTURE EXTENSIONS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Encrypted Portion* Authenticated Portion ---+ E bit in the extension parameter will determine whether encryption is on or not. E=1 -> Encrypted, E=0 -> Not Encrypted 3. Security Considerations Selective Encryption with SRTP is an optional feature of SRTP and shall be used only if participating end points agree to use it. Algorithm to do selective encryption will determine effectiveness of this mechanism and overall security of the media. It should be well understood by all application developers who wish to use selective encryption that full encryption is always more secure than selective encryption - so only if developers see benefits of selective encryption compelling, they should opt for selective encryption. Scheme-1 defined in the draft requires the Sunil Mahajan Expires Aug 19, 2007 [Page 8] Internet-Draft SRTP Selective Encryption Aug 2007 application developer to clearly categorize the contents into 2 types, one which definitely requires encryption and other which can be seen as unencrypted contents by the users. For scheme-2 application developer would need to understand the coding or compression type clearly and evaluate the selective encryption mechanism only if either the security requirements are not very critical or developer is sure about the method used for determining the unencrypted contents will not compromise the security of overall contents. 4. Acknowledgements Thanks to Armstrong M and Senthil Gurusamy for fruitful discussions and inputs. Authors would like to acknowledge the contribution of all the members of working group for their useful comments and critical review of previous version of the draft. 5. References [RFC3261] 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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", Sunil Mahajan Expires Aug 19, 2007 [Page 9] Internet-Draft SRTP Selective Encryption Aug 2007 Authors' Addresses Sunil Mahajan Aricent Plot#31, Sector 18, Electronic City Gurgaon, Haryana INDIA Phone: +91-124-2346666 Email: sunil.mahajan@arcient.com Shyam SBK Gupta Pallapothu Aricent 9th Floor, Gamma Block, Sigma Soft Tech park, Varthur, Bangalore, Karnataka, INDIA Email: shyam.pallapothu@aricent.com 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. Sunil Mahajan Expires Aug 19, 2007 [Page 10] Internet-Draft SRTP Selective Encryption Aug 2007 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, THE IETF TRUST 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 IETF Trust (2007). 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. Sunil Mahajan Expires Aug 19, 2007 [Page 11]