idnits 2.17.1 draft-ietf-avt-srtp-not-mandatory-01.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. 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 (November 2, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-06 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-10 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-18 == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-08 Summary: 1 error (**), 0 flaws (~~), 5 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: May 6, 2009 Ericsson 6 November 2, 2008 8 Why RTP Does Not Mandate a Single Security Mechanism 9 draft-ietf-avt-srtp-not-mandatory-01.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 May 6, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 58 Intellectual Property and Copyright Statements . . . . . . . . . . 10 60 1. Introduction 62 The Real-time Transport Protocol (RTP) [1] is widely used for voice 63 over IP, Internet television, video conferencing, and various other 64 real-time and streaming media applications. Despite this, the base 65 RTP specification provides very limited options for media security, 66 and defines no standard key exchange mechanism. Rather, a number of 67 extensions are defined to provide confidentiality and authentication 68 of media streams, and to exchange security keys. This memo outlines 69 why it is appropriate that multiple extension mechanisms are defined, 70 rather than mandating a single media security and keying mechanism. 72 This memo provides information for the community; it does not specify 73 a standard of any kind. 75 The structure of this memo is as follows: we begin, in Section 2 by 76 describing the scenarios in which RTP is deployed. Following this, 77 Section 3 outlines the implications of this range of scenarios for 78 media confidentially and authentication, and Section 4 outlines the 79 implications for key exchange. Section 5 outlines how the RTP 80 framework meets the requirement of BCP 61. Section 6 then concludes 81 and gives some recommendations. Finally, Section 7 outlines the 82 security considerations, and Section 8 outlines IANA considerations. 84 2. RTP Applications and Deployment Scenarios 86 The range of application and deployment scenarios where RTP has been 87 used includes, but is not limited to, the following: 89 o Point-to-point voice telephony (fixed and wireless networks) 91 o Point-to-point video conferencing 93 o Centralised group video conferencing with a multipoint conference 94 unit (MCU) 96 o Any Source Multicast video conferencing (light-weight sessions; 97 Mbone conferencing) 99 o Point-to-point streaming audio and/or video 101 o Single Source Multicast streaming to large group (IPTV and MBMS 102 [2]) 104 o Replicated unicast streaming to a group 105 o Interconnecting components in music production studios and video 106 editing suites 108 o Interconnecting components of distributed simulation systems 110 o Streaming real-time sensor data 112 As can be seen, these scenarios vary from point-to-point to very 113 large multicast groups, from interactive to non-interactive, and from 114 low bandwidth (kilobits per second) to very high bandwidth (multiple 115 gigabits per second). While most of these applications run over UDP, 116 some use TCP or DCCP as their underlying transport. Some run on 117 highly reliable optical networks, others use low rate unreliable 118 wireless networks. Some applications of RTP operate entirely within 119 a single trust domain, others are inter-domain, with untrusted (and 120 potentially unknown) users. The range of scenarios is wide, and 121 growing both in number and in heterogeneity. 123 3. Implications for RTP Media Security 125 The wide range of application scenarios where RTP is used has led to 126 the development of multiple solutions for media security, considering 127 different requirements. Perhaps the most widely applicable of these 128 solutions is the Secure RTP (SRTP) framework [3]. This is an 129 application-level media security solution, encrypting the media 130 payload data (but not the RTP headers) to provide some degree of 131 confidentiality, and providing optional source origin authentication. 132 It was carefully designed to be both low overhead, and to support the 133 group communication features of RTP, across a range of networks. 135 SRTP is not the only media security solution in use, however, and 136 alternatives are more appropriate for some scenarios. For example, 137 many client-server streaming media applications run over a single TCP 138 connection, multiplexing media data with control information on that 139 connection (for example, on an RTSP connection). The natural way to 140 provide media security for such client-server media applications is 141 to use TLS to protect the TCP connection, sending the RTP media data 142 over the TLS connection. Using the SRTP framework in addition to TLS 143 is unncessary, and would result in double encryption of the media, 144 and SRTP cannot be used instead of TLS since it is RTP-specific, and 145 so cannot protect the control traffic. 147 Other RTP use cases work over networks which provide security at the 148 network layer, using IPsec. For example, certain 3GPP networks need 149 IPsec security associations for other purposes, and can reuse those 150 to secure the RTP session [4]. SRTP is, again, unnecessary in such 151 environments, and its use would only introduce overhead for no gain. 153 For some applications it is sufficient to protect the RTP payload 154 data while leaving RTP, transport, and network layer headers 155 unprotected. An example of this is RTP broadcast over DVB-H [5], 156 where one mode of operation uses ISMAcryp to protect the media data 157 only. 159 Finally, the link layer may be secure, and it may be known that the 160 RTP media data is constrained to that single link (for example, when 161 operating in a studio environment, with physical link security). An 162 environment like this is inherently constrained, but might avoid the 163 need for application, transport, or network layer media security. 165 All these are application scenarios where RTP has seen commerical 166 deployment. Other use case also exist, with additional requirements. 167 There is no media security protocol that is appropriate for all these 168 environments. Accordingly, multiple RTP media security protocols can 169 be expected to remain in wide use. 171 4. Implications for Key Management 173 With such a diverse range of use case come a range of different 174 protocols for RTP session establishment. Mechanisms used to provide 175 security keying for these different session establishment protocols 176 can basically be put into two categories: inband and out-of-band in 177 relation to the session establishment mechanism. The requirements 178 for these solutions are highly varying. Thus a wide range of 179 solutions have been developed in this space: 181 o The most common use case for RTP is probably point-to-point voice 182 calls or centralised group conferences, negotiated using SIP with 183 the SDP offer/answer model, operating on a trusted infrastructure. 184 In such environments, SDP security descriptions [6] or the MIKEY 185 [7] protocol are appropriate keying mechanisms, piggybacked onto 186 the SDP exchange. The infrastructure may be secured by protecting 187 the SIP exchange using SIPS or S/MIME, for example. 189 o Point-to-point RTP sessions may be negotiated using SIP with the 190 offer/answer model, but operating over a network with untrusted 191 infrastructure. In such environments, the key management protocol 192 is run on the media path, bypassing the untrusted infrastructure. 193 Protocols such as DTLS [8] or ZRTP [9] are useful here. 195 o For point-to-point client-server streaming of RTP over RTSP [10], 196 a TLS association is appropriate to manage keying material, in 197 much the same manner as would be used to secure an HTTP session. 199 o A session description may be sent by email, secured using X.500 or 200 PGP, or retrieved from a web page, using HTTP with TLS. 202 o A session description may be distributed to a multicast group 203 using SAP or FLUTE secured with S/MIME. 205 o A session description may be distributed using OMA's DRM key 206 management [11] with pointer for point to point streaming setup 207 with RTSP in 3GPP [12]. 209 o In the 3GPP MBMS system, HTTP and MIKEY are used for key 210 management [13]. 212 A more detailed survey of requirements for media security management 213 protocols can be found in [14]. As can be seen, the range of use 214 cases is wide, and there is no single protocol that is appropriate 215 for all scenarios. These solutions have be further diversified by 216 the existence of infrastructure elements such as authentication 217 solutions that are tied into the key manangement. 219 5. On the Requirement for Strong Security in IETF protocols 221 BCP 61 [15] puts a requirement on IETF protocols to provide strong, 222 mandatory to implement, security solutions. This is actually quite a 223 difficult requirement for any type of framework protocol, like RTP, 224 since one can never know all the deployement scenarios, and if they 225 are covered by the security solution. It would clearly be desirable 226 if a single media security solution and a single key management 227 solution could be developed, satisfying the range of use cases for 228 RTP. The authors are not aware of any such solution, however, and it 229 is not clear that any single solution can be developed. 231 For a framework protocol it appears that the only sensible solution 232 to the requirement of BCP 61 is to develop or use security building 233 blocks, like SRTP, SDES, MIKEY, DTLS, or IPsec, to provide the basic 234 security services of authorization, data integrity protocetion and 235 date confidentiality protection. When new usages of the RTP 236 framework arise, one needs to analyze the situation, to determine of 237 the existing building blocks satisfy the requirements. If not, it is 238 necessary to develop new security building blocks. 240 When it comes to fulfilling the "MUST Implement" strong security for 241 a specific application, it will fall on that application to actually 242 consider what building blocks it is required to support. To maximize 243 interoperability it is desirable if certain applications, or classes 244 of application with similar requirements, agree on what data security 245 mechanisms and key-management should be used. If such agreement is 246 not possible, there will be increased cost, either in the lack of 247 interoperability, or in the need to implement more solutions. 248 Unfortunately this situation, if not handled reasonably well, can 249 result in a failure to satisfy the requirement of providing the users 250 with an option of turining on strong security when desired. 252 6. Conclusions 254 As discussed earlier it appears that a single solution can't be 255 designed to meet the diverse requirements. In the absense of such a 256 solution, it is hoped that this memo explains why SRTP is not 257 mandatory as the media security solution for RTP-based systems, and 258 why we can expect multiple key management solutions for systems using 259 RTP. 261 It is important for any RTP-based application to consider how it 262 meets the security requirements. This will require some analysis to 263 determine these requirements, followed by a selection of a mandatory 264 to implement solution, or in exceptional scenarios several solutions, 265 including the desired RTP traffic protection and key-management. 266 SRTP is a preferred solution for the protection of the RTP traffic in 267 those use cases where it is applicable. It is out of scope for this 268 memo to recommend a preferred key management solution. 270 7. Security Considerations 272 This entire memo is about security. 274 8. IANA Considerations 276 No IANA actions are required. 278 9. 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] 3GPP, "IP network layer security", 3GPP TS 33.210, 292 September 2008. 294 [5] ETSI, "Digital Video Broadcasting (DVB); IP Datacast over 295 DVB-H: Service Purchase and Protection", ETSI TS 102 474, 296 November 2007. 298 [6] Andreasen, F., Baugher, M., and D. Wing, "Session Description 299 Protocol (SDP) Security Descriptions for Media Streams", 300 RFC 4568, July 2006. 302 [7] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 303 Carrara, "Key Management Extensions for Session Description 304 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 305 RFC 4567, July 2006. 307 [8] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security 308 (DTLS) Extension to Establish Keys for Secure Real-time 309 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-06 (work 310 in progress), October 2008. 312 [9] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path 313 Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-10 314 (work in progress), October 2008. 316 [10] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. 317 Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", 318 draft-ietf-mmusic-rfc2326bis-18 (work in progress), May 2008. 320 [11] Open Mobile Alliance, "DRM Specification 2.0". 322 [12] 3GPP, "Transparent end-to-end Packet-switched Streaming Service 323 (PSS); Protocols and codecs TS 26.234". 325 [13] 3GPP, "Security of Multimedia Broadcast/Multicast Service 326 (MBMS) TS 33.246". 328 [14] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 329 "Requirements and Analysis of Media Security Management 330 Protocols", draft-ietf-sip-media-security-requirements-08 (work 331 in progress), October 2008. 333 [15] Schiller, J., "Strong Security Requirements for Internet 334 Engineering Task Force Standard Protocols", BCP 61, RFC 3365, 335 August 2002. 337 Authors' Addresses 339 Colin Perkins 340 University of Glasgow 341 Department of Computing Science 342 Sir Alwyn Williams Building 343 Lilybank Gardens 344 Glasgow G12 8QQ 345 UK 347 Email: csp@csperkins.org 349 Magnus Westerlund 350 Ericsson 351 Torshamgatan 23 352 Stockholm SE-164 80 353 Sweden 355 Email: magnus.westerlund@ericsson.com 357 Full Copyright Statement 359 Copyright (C) The IETF Trust (2008). 361 This document is subject to the rights, licenses and restrictions 362 contained in BCP 78, and except as set forth therein, the authors 363 retain all their rights. 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 368 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 369 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 370 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Intellectual Property 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Acknowledgment 399 Funding for the RFC Editor function is provided by the IETF 400 Administrative Support Activity (IASA).