idnits 2.17.1 draft-ietf-avt-srtp-not-mandatory-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 375. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2008) is 5743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Informational M. Westerlund 5 Expires: January 30, 2009 Ericsson 6 July 29, 2008 8 Why RTP Does Not Mandate a Single Security Mechanism 9 draft-ietf-avt-srtp-not-mandatory-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 30, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo discusses the problem of securing real-time multimedia 43 sessions, and explains why the Real-time Transport Protocol (RTP) 44 does not mandate a single media security mechanism. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. RTP Applications and Deployment Scenarios . . . . . . . . . . . 3 50 3. Implications for RTP Media Security . . . . . . . . . . . . . . 4 51 4. Implications for Key Management . . . . . . . . . . . . . . . . 5 52 5. On the Requirement for Strong Security in IETF protocols . . . 6 53 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 10. Informative References . . . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Introduction 63 The Real-time Transport Protocol (RTP) [1] is widely used for voice 64 over IP, Internet television, video conferencing, and various other 65 real-time and streaming media applications. Despite this, the base 66 RTP specification provides very limited options for media security, 67 and defines no standard key exchange mechanism. Rather, a number of 68 extensions are defined to provide confidentiality and authentication 69 of media streams, and to exchange security keys. This memo outlines 70 why it is appropriate that multiple extension mechanisms are defined, 71 rather than mandating a single media security and keying mechanism. 73 This memo provides information for the community; it does not specify 74 a standard of any kind. 76 The structure of this memo is as follows: we begin, in Section 2 by 77 describing the scenarios in which RTP is deployed. Following this, 78 Section 3 outlines the implications of this range of scenarios for 79 media confidentially and authentication, and Section 4 outlines the 80 implications for key exchange. Section 5 outlines how the RTP 81 framework meets the requirement of BCP 61. Section 6 then concludes 82 and gives some recommendations. Finally, Section 7 outlines the 83 security considerations, and Section 8 outlines IANA considerations. 85 2. RTP Applications and Deployment Scenarios 87 The range of application and deployment scenarios where RTP has been 88 used includes, but is not limited to, the following: 90 o Point-to-point voice telephony (fixed and wireless networks) 92 o Point-to-point video conferencing 94 o Centralised group video conferencing with a multipoint conference 95 unit (MCU) 97 o Any Source Multicast video conferencing (light-weight sessions; 98 Mbone conferencing) 100 o Point-to-point streaming audio and/or video 102 o Single Source Multicast streaming to large group (IPTV and MBMS 103 [2]) 105 o Replicated unicast streaming to a group 106 o Interconnecting components in music production studios and video 107 editing suites 109 o Interconnecting components of distributed simulation systems 111 o Streaming real-time sensor data 113 As can be seen, these scenarios vary from point-to-point to very 114 large multicast groups, from interactive to non-interactive, and from 115 low bandwidth (kilobits per second) to very high bandwidth (multiple 116 gigabits per second). While most of these applications run over UDP, 117 some use TCP or DCCP as their transport. Some run on highly reliable 118 optical networks, others use low rate unreliable wireless networks. 119 Some applications of RTP operate entirely within a single trust 120 domain, others are inter-domain, with untrusted (and potentially 121 unknown) users. The range of scenarios is wide, and growing both in 122 number and in heterogeneity. 124 3. Implications for RTP Media Security 126 The wide range of application scenarios where RTP is used has led to 127 the development of multiple solutions for media security, considering 128 different requirements. Perhaps the most general of these solutions 129 is the Secure RTP (SRTP) framework [3]. This is an application-level 130 media security solution, encrypting the media payload data (not the 131 RTP headers) to provide some degree of confidentiality, and providing 132 optional source origin authentication. It was carefully designed to 133 be both low overhead, and to support the group communication features 134 of RTP, across a range of networks. 136 SRTP is not the only media security solution in use, however, and 137 alternatives are more appropriate for some scenarios. For example, 138 many client-server streaming media applications run over a single TCP 139 connection, multiplexing media data with control information on that 140 connection (for example, on an RTSP connection). The natural way to 141 provide media security for such client-server media applications is 142 to use TLS to protect the TCP connection, sending the RTP media data 143 over the TLS connection. Using the SRTP framework in addition to TLS 144 is unncessary, and would result in double encryption of the media, 145 and SRTP cannot be used instead of TLS since it is RTP-specific, and 146 so cannot protect the control traffic. 148 Finally, the link layer may be secure, and it may be known that the 149 RTP media data is constrained to that single link (for example, when 150 operating in a studio environment, with physical link security). An 151 environment like this is inherently constrained, but might avoid the 152 need for application, transport, or network layer media security. 154 All these are application scenarios where RTP has seen commerical 155 deployment. Other use case also exist, with additional requirements. 156 There is no media security protocol that is appropriate for all these 157 environments. Accordingly, multiple RTP media security protocols can 158 be expected to remain in wide use. 160 4. Implications for Key Management 162 More diverse than the different use cases is the different protocols 163 used for RTP session establishment. Providing keying for these 164 different session establishment can basically be put into two 165 categories, inband and out-of-band in relation to the session 166 establishment mechanism. The requirement on these solution are 167 highly varying. Thus a wide range of solutions have been developed 168 in this space: 170 o The most common use case for RTP is probably point-to-point voice 171 calls or centralised group conferences, negotiated using SIP with 172 the SDP offer/answer model, operating on a trusted infrastructure. 173 In such environments, SDP security descriptions [4] or the MIKEY 174 [5] protocol are appropriate keying mechanisms, piggybacked onto 175 the SDP exchange. 177 o SIP/SDP with SIPS 179 o SIP/SDP with S/MIME 181 o Point-to-point RTP sessions may be negotiated using SIP with the 182 offer/answer model, but operating over a network with untrusted 183 infrastructure. In such environments, the key management protocol 184 is run on the media path, bypassing the untrusted infrastructure. 185 Protocols such as ZRTP or DTLS protocols are useful here. 187 o For point-to-point client-server streaming of RTP over RTSP, a TLS 188 association is appropriate to manage keying material, in much the 189 same manner as would be used to secure an HTTP session. 191 o Email with SDP, secured using X.500 or PGP 193 o SDP file retrieved using HTTPS 195 o FLUTE using S/MIME to secure SDP 197 o SAP with SDP 199 o OMAs DRM keymanagement [6] with pointer from SDP for point to 200 point streamingsetup with RTSP in 3GPP [7]. 202 o Usage of HTTP and MIKEY for key management in MBMS [8]. 204 A more detailed survey of requirements for media security management 205 protocols can be found in [9]. As can be seen, the range of use 206 cases is wide, and there is no single protocol that is appropriate 207 for all scenarios. These solutions have be further diversified by 208 the existence of infrastructure elements such as authentication 209 solutions that is tied into the key manangement. 211 5. On the Requirement for Strong Security in IETF protocols 213 BCP 61 [10] puts a requirement on IETF protocols to provide strong, 214 mandatory to implement, security solutions. This is actually quite a 215 difficult requirement for any type of framework protocol, like RTP, 216 since one can never know all the deployement scenarios, and if the 217 security solution provided covers them. It would clearly be 218 desirable if a single media security solution and a single key 219 management solution could be developed, satisfying the range of use 220 cases for RTP. The authors are not aware of any such solution, 221 however, and it is not clear that any single solution can be 222 developed. 224 For a framework protocol it appears that the only sensible solution 225 to the requirement of BCP 61 is to develop or use security building 226 blocks, like SRTP, SDES, MIKEY, DTLS, or IPsec, to provide the basic 227 security services of authorization, data integrity protocetion and 228 date confidentiality protection. When new usages of the RTP 229 framework arise, one needs to analyze the situation, to determine of 230 the existing building blocks satisfy the requirements. If not, it is 231 necessary to develop new security building blocks. 233 When it comes to fulfilling the "MUST Implement" strong security for 234 a specific application, it will fall on that application to actually 235 consider what building blocks it is required to support. To maximize 236 interoperability it is desirable if certain applications, or classes 237 of application with similar requirements, agree on what data security 238 mechanisms and key-management should be used. If such agreement is 239 not possible, there will be increased cost, either in the lack of 240 interoperability, or in the need to implement more solutions. 241 Unfortunately this situation, if not handled reasonably well, can 242 result in a failure to satisfy the requirement of providing the users 243 with an option of turining on strong security when desired. 245 6. Conclusions 247 As discussed earlier it appears that a single solution can't be 248 designed meet the diverse requirements. In the absense of such a 249 solution, it is hoped that this memo explains why SRTP is not 250 mandatory as the media security solution for RTP-based systems, and 251 why we can expect multiple key management solutions for systems using 252 RTP. 254 In respect to the above it is important for any RTP-based application 255 to consider how they meet the application's security requirements. 256 This will requires some analysis to determine these requirements. 257 Followed by a selection of preferably a single to mandatory to 258 implement solution including the desired RTP traffic protection and 259 key-management. As SRTP can be used in a large number of use cases, 260 it is a preferred solution for the protection of the RTP traffic, for 261 those use cases where it is applicable. Currently it is much harder 262 to point out a preferred key-management solution. 264 7. Security Considerations 266 This entire memo is about security. 268 8. IANA Considerations 270 No IANA actions are required. 272 9. To Do 274 Update references 276 IPsec example 278 10. Informative References 280 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 281 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 282 RFC 3550, July 2003. 284 [2] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols 285 and codecs TS 26.346". 287 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 288 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 289 RFC 3711, March 2004. 291 [4] Andreasen, F., Baugher, M., and D. Wing, "Session Description 292 Protocol (SDP) Security Descriptions for Media Streams", 293 RFC 4568, July 2006. 295 [5] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 296 Carrara, "Key Management Extensions for Session Description 297 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 298 RFC 4567, July 2006. 300 [6] Open Mobile Alliance, "DRM Specification 2.0". 302 [7] 3GPP, "Transparent end-to-end Packet-switched Streaming Service 303 (PSS); Protocols and codecs TS 26.234". 305 [8] 3GPP, "Security of Multimedia Broadcast/Multicast Service 306 (MBMS) TS 33.246". 308 [9] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 309 "Requirements and Analysis of Media Security Management 310 Protocols", draft-ietf-sip-media-security-requirements-02 (work 311 in progress), January 2008. 313 [10] Schiller, J., "Strong Security Requirements for Internet 314 Engineering Task Force Standard Protocols", BCP 61, RFC 3365, 315 August 2002. 317 Authors' Addresses 319 Colin Perkins 320 University of Glasgow 321 Department of Computing Science 322 Sir Alwyn Williams Building 323 Lilybank Gardens 324 Glasgow G12 8QQ 325 UK 327 Email: csp@csperkins.org 329 Magnus Westerlund 330 Ericsson 331 Torshamgatan 23 332 Stockholm SE-164 80 333 Sweden 335 Email: magnus.westerlund@ericsson.com 337 Full Copyright Statement 339 Copyright (C) The IETF Trust (2008). 341 This document is subject to the rights, licenses and restrictions 342 contained in BCP 78, and except as set forth therein, the authors 343 retain all their rights. 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 348 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 349 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 350 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Intellectual Property 355 The IETF takes no position regarding the validity or scope of any 356 Intellectual Property Rights or other rights that might be claimed to 357 pertain to the implementation or use of the technology described in 358 this document or the extent to which any license under such rights 359 might or might not be available; nor does it represent that it has 360 made any independent effort to identify any such rights. Information 361 on the procedures with respect to rights in RFC documents can be 362 found in BCP 78 and BCP 79. 364 Copies of IPR disclosures made to the IETF Secretariat and any 365 assurances of licenses to be made available, or the result of an 366 attempt made to obtain a general license or permission for the use of 367 such proprietary rights by implementers or users of this 368 specification can be obtained from the IETF on-line IPR repository at 369 http://www.ietf.org/ipr. 371 The IETF invites any interested party to bring to its attention any 372 copyrights, patents or patent applications, or other proprietary 373 rights that may cover technology that may be required to implement 374 this standard. Please address the information to the IETF at 375 ietf-ipr@ietf.org. 377 Acknowledgment 379 Funding for the RFC Editor function is provided by the IETF 380 Administrative Support Activity (IASA).