idnits 2.17.1 draft-ietf-avt-srtp-not-mandatory-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '...ution is that we MUST implement strong...' RFC 2119 keyword, line 90: '...curity must be a MUST IMPLEMENT so tha...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 79 has weird spacing: '...rements for I...' -- 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 (October 31, 2011) is 4533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-28 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 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 3, 2012 Ericsson 6 October 31, 2011 8 Why RTP Does Not Mandate a Single Security Mechanism 9 draft-ietf-avt-srtp-not-mandatory-08.txt 11 Abstract 13 This memo discusses the problem of securing real-time multimedia 14 sessions, and explains why the Real-time Transport Protocol (RTP), 15 and the associated RTP control protocol (RTCP), do not mandate a 16 single media security mechanism. It also discusses how applications 17 using RTP can meet the goals of BCP 61 to have strong and mandatory 18 to implement security. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3 56 3. Implications for RTP Security . . . . . . . . . . . . . . . . 4 57 4. Implications for Key Management . . . . . . . . . . . . . . . 5 58 5. On the Requirement for Strong Security in IETF protocols . . . 7 59 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 The Real-time Transport Protocol (RTP) [RFC3550] is widely used for 69 voice over IP, Internet television, video conferencing, and various 70 other real-time and streaming media applications. Despite this, the 71 base RTP specification provides very limited options for media 72 security, and defines no standard key exchange mechanism. Rather, a 73 number of extensions are defined to provide confidentiality and 74 authentication of RTP media streams and RTCP control messages, and to 75 exchange security keys. This memo outlines why it is appropriate 76 that multiple extension mechanisms are defined, rather than mandating 77 a single security and keying mechanism. 79 The consensus for Strong Security Requirements for IETF Standard 80 Protocols (BCP61) [RFC3365] describes the Danvers Doctrine, which 81 states that: 83 "The solution is that we MUST implement strong security in all 84 protocols to provide for the all too frequent day when the 85 protocol comes into widespread use in the global Internet." 87 BCP 61 also discusses that security must be implemented, and makes 88 the following statement: 90 "However security must be a MUST IMPLEMENT so that end users will 91 have the option of enabling it when the situation calls for it." 93 This IETF consensus provides a clear challange for RTP security, due 94 to the heterogenous scenarios in which RTP can be used, and the wide 95 choice of security mechanisms available. This memo describes how RTP 96 based applications, or classes of applications, can best meet the 97 security goals of BCP 61. 99 This memo provides information for the community; it does not specify 100 a standard of any kind. 102 The structure of this memo is as follows. Section 2 describes a 103 number of scenarios in which RTP is deployed. Following this, 104 Section 3 outlines the implications of this range of scenarios for 105 media confidentially and authentication, and Section 4 outlines the 106 implications for key exchange. Section 5 outlines how the RTP 107 framework can meet the requirement of BCP 61. Section 6 then 108 concludes and gives some recommendations. 110 2. RTP Applications and Deployment Scenarios 112 The range of application and deployment scenarios where RTP has been 113 used includes, but is not limited to, the following: 115 o Point-to-point voice telephony (fixed and wireless networks) 117 o Point-to-point voice and video conferencing 119 o Centralised group video conferencing with a multipoint conference 120 unit (MCU) 122 o Any Source Multicast video conferencing (light-weight sessions; 123 Mbone conferencing) 125 o Point-to-point streaming audio and/or video 127 o Source-specific multicast (SSM) streaming to large group (IPTV and 128 3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS]) 130 o Replicated unicast streaming to a group 132 o Interconnecting components in music production studios and video 133 editing suites 135 o Interconnecting components of distributed simulation systems 137 o Streaming real-time sensor data 139 As can be seen, these scenarios vary from point-to-point to very 140 large multicast groups, from interactive to non-interactive, and from 141 low bandwidth (kilobits per second) to very high bandwidth (multiple 142 gigabits per second). While most of these applications run over UDP 143 [RFC0768], some use TCP [RFC0793], [RFC4614] or DCCP [RFC4340] as 144 their underlying transport. Some run on highly reliable optical 145 networks, others use low rate unreliable wireless networks. Some 146 applications of RTP operate entirely within a single trust domain, 147 others are inter-domain, with untrusted (and potentially unknown) 148 users. The range of scenarios is wide, and growing both in number 149 and in heterogeneity. 151 3. Implications for RTP Security 153 The wide range of application scenarios where RTP is used has led to 154 the development of multiple solutions for securing RTP media streams 155 and RTCP control messages, considering different requirements. 156 Perhaps the most widely applicable of these solutions is the Secure 157 RTP (SRTP) framework [RFC3711]. This is an application-level media 158 security solution, encrypting the media payload data (but not the RTP 159 headers) to provide some degree of confidentiality, and providing 160 optional source origin authentication. It was carefully designed to 161 be both low overhead, and to support the group communication features 162 of RTP, across a range of networks. 164 SRTP is not the only media security solution in use, however, and 165 alternatives are more appropriate for some scenarios. For example, 166 many client-server streaming media applications can run over a single 167 TCP connection, multiplexing media data with control information on 168 that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used 169 example of such a protocol). One way to provide media security for 170 such client-server media applications is to use TLS [RFC5246] to 171 protect the TCP connection, sending the RTP media data over the TLS 172 connection. Using the SRTP framework in addition to TLS is 173 unnecessary, and would result in double encryption of the media, and 174 SRTP cannot be used instead of TLS since it is RTP-specific, and so 175 cannot protect the control traffic. 177 Other RTP use cases work over networks which provide security at the 178 network layer, using IPsec. For example, certain 3GPP networks need 179 IPsec security associations for other purposes, and can reuse those 180 to secure the RTP session [TS-33210]. SRTP is, again, unnecessary in 181 such environments, and its use would only introduce overhead for no 182 gain. 184 For some applications it is sufficient to protect the RTP payload 185 data while leaving RTP, transport, and network layer headers 186 unprotected. An example of this is RTP broadcast over DVB-H 187 [ETSI.TS.102.474], where one mode of operation uses ISMA Cryp 2.0 188 [ISMA] to encrypt the RTP payload data only. 190 All these are application scenarios where RTP has seen commercial 191 deployment. Other use cases exist, with additional requirements. 192 For example, if the media transport is done over UDP [RFC0768], DCCP 193 [RFC4340] or SCTP [RFC4960], then using DTLS [RFC4347] to protect the 194 whole RTP packets is an option. There is no media security protocol 195 that is appropriate for all these environments. Accordingly, 196 multiple RTP media security protocols can be expected to remain in 197 wide use. 199 4. Implications for Key Management 201 With such a diverse range of use cases come a range of different 202 protocols for RTP session establishment. Mechanisms used to provide 203 security keying for these different session establishment protocols 204 can basically be put into two categories: inband and out-of-band in 205 relation to the session establishment mechanism. The requirements 206 for these solutions are highly varying. Thus a wide range of 207 solutions have been developed in this space: 209 o A common use case for RTP is probably point-to-point voice calls 210 or centralised group conferences, negotiated using SIP [RFC3261] 211 with the SDP offer/answer model [RFC3264], operating on a trusted 212 infrastructure. In such environments, SDP security descriptions 213 [RFC4568], or the MIKEY [RFC3830] protocol using the Key 214 Management Extensions for SDP [RFC4567], are appropriate keying 215 mechanisms, where the keying messages/material are embedded in the 216 SDP [RFC4566] exchange. The infrastructure may be secured by 217 protecting the SDP exchange in SIP using TLS or S/MIME, for 218 example [RFC3261]. Protocols such as DTLS-SRTP [RFC5764] or ZRTP 219 [RFC6189] are also appropriate in such environments. 221 o Point-to-point RTP sessions may be negotiated using SIP with the 222 offer/answer model, but operating over a network with untrusted 223 infrastructure. In such environments, the key management protocol 224 can be run on the media path, bypassing the untrusted 225 infrastructure. Protocols such as DTLS-SRTP [RFC5764] or ZRTP 226 [RFC6189] are useful here, as are inband mechanism that protect 227 the keying material such as MIKEY [RFC3830] using the Key 228 Management Extensions for SDP [RFC4567]. It should be noted that 229 the end-points for all the above mechanisms must prevent total 230 downgrade to no security for the RTP media streams. 232 o For point-to-point client-server streaming of RTP over RTSP, a TLS 233 association is appropriate to manage keying material, in much the 234 same manner as would be used to secure an HTTP session. But also 235 using SRTP with DTLS-SRTP keying or DTLS are appropriate choices. 237 o A session description may be sent by email, secured using S/MIME 238 or PGP, or retrieved from a web page, using HTTP with TLS. 240 o A session description may be distributed to a multicast group 241 using SAP or FLUTE secured with S/MIME. 243 o A session description may be distributed using the Open Mobile 244 Alliance DRM key management specification [OMA-DRM] when using a 245 point-to-point streaming session setup with RTSP in the 3GPP PSS 246 environment [PSS]. 248 o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system, 249 HTTP and MIKEY are used for key management [MBMS-SEC]. 251 A more detailed survey of requirements for media security management 252 protocols can be found in [RFC5479]. As can be seen, the range of 253 use cases is wide, and there is no single protocol that is 254 appropriate for all scenarios. These solutions have been further 255 diversified by the existence of infrastructure elements such as 256 authentication solutions that are tied into the key management. 258 5. On the Requirement for Strong Security in IETF protocols 260 BCP 61 [RFC3365] puts a requirement on IETF protocols to provide 261 strong, mandatory to implement, security solution. This is actually 262 quite a difficult requirement for any type of framework protocol like 263 RTP, or for that matter the Reliable Multicast Transport suite 264 [RFC3048], since one can never know all the deployment scenarios, and 265 if they are covered by the security solution. It would clearly be 266 desirable if a single media security solution and a single key 267 management solution could be developed, satisfying the range of use 268 cases for RTP. The authors are not aware of any such solution, 269 however, and believe it is unlikely that any single solution can be 270 developed. 272 For a framework protocol it appears that the only sensible solution 273 to the requirement of BCP 61 is to develop or use security building 274 blocks, like SRTP, SDP security descriptions, MIKEY, DTLS, DTLS-SRTP, 275 or IPsec, to provide the basic security services of authorization, 276 data integrity protection and date confidentiality protection. When 277 new usages of the RTP framework arise, one needs to analyze the 278 situation, to determine if the existing building blocks satisfy the 279 requirements. If not, it is necessary to develop new security 280 building blocks. 282 When it comes to fulfilling the "MUST Implement" strong security for 283 a specific application, or class of applications, it will fall on 284 that application to actually consider what building blocks it is 285 required to support. To maximize interoperability it is desirable if 286 certain applications, or classes of application with similar 287 requirements, agree on what data security mechanisms and key- 288 management should be used. If such agreement is not possible, there 289 will be increased cost, either in the lack of interoperability, or in 290 the need to implement more solutions. Unfortunately this situation, 291 if not handled reasonably well, can result in a failure to satisfy 292 the requirement of providing the users with an option of turning on 293 strong security when desired. 295 The IETF needs to perform this selection of security building blocks 296 whenever it is possible. This can be done if the application, or 297 class of applications, is being specified within the IETF, or wich a 298 scope where the IETF can take the role to provide a security profile. 299 However, it is clear that many applications, or classes of 300 application, are specified outside the scope and influence of the 301 IETF. In those case we can't do other than strongly recommend these 302 organizations perform a security analysis, taking into account other 303 applications, to try to maximize the security and interoperability. 305 6. Conclusions 307 As discussed earlier it appears that a single solution can't be 308 designed to meet the diverse requirements. In the absence of such a 309 solution, it is hoped that this memo explains why SRTP is not 310 mandatory as the media security solution for RTP-based systems, and 311 why we can expect multiple key management solutions for systems using 312 RTP. 314 It is very important for any RTP-based application to consider how it 315 meets the security requirements. This will require some analysis to 316 determine these requirements, followed by the selection of a 317 mandatory to implement solution, or in exceptional scenarios several 318 solutions, including the desired RTP traffic protection and key- 319 management. When defining applications or protocols using RTP within 320 the IETF, the responsibility for fulfilling the BCP 61 requirements 321 will fall onto the developers of these applications. IETF also 322 should be open to help other standards bodies by defining security 323 profiles suitable for classes of applications. 325 Anyone defining an RTP based application needs to take care to 326 consider how to fulfill its security goals and specify which 327 mechanisms that are to be implemented. In that work interoperability 328 with similar applications should be considered, so that when such 329 applications becomes desirable to interconnect those applications, 330 their security solutions are compatible and will not require 331 additional implementation or costly gateways that also reduce 332 security by forcing a trusted third party. 334 SRTP is a preferred solution for the protection of the RTP traffic in 335 those use cases where it is applicable. It is out of scope for this 336 memo to recommend a preferred key management solution in general. 337 The authors do note that DTLS-SRTP was developed in the IETF to meet 338 the goals of point to point media sessions established by SIP. 340 7. Security Considerations 342 This entire memo is about security. 344 8. IANA Considerations 346 No IANA actions are required. 348 9. Acknowledgements 350 Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, 351 Martin Ellis, Ali Begen, and Keith Drage for their feedback. 353 10. Informative References 355 [ETSI.TS.102.474] 356 ETSI, "Digital Video Broadcasting (DVB); IP Datacast over 357 DVB-H: Service Purchase and Protection", ETSI TS 102 474, 358 November 2007. 360 [I-D.ietf-mmusic-rfc2326bis] 361 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 362 and M. Stiemerling, "Real Time Streaming Protocol 2.0 363 (RTSP)", draft-ietf-mmusic-rfc2326bis-28 (work in 364 progress), October 2011. 366 [ISMA] Internet Streaming Media Alliance, "Encryption and 367 Authentication Version 2.0", November 2007. 369 [MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 370 Protocols and codecs TS 26.346". 372 [MBMS-SEC] 373 3GPP, "Security of Multimedia Broadcast/Multicast Service 374 (MBMS) TS 33.246". 376 [OMA-DRM] Open Mobile Alliance, "DRM Specification 2.0". 378 [PSS] 3GPP, "Transparent end-to-end Packet-switched Streaming 379 Service (PSS); Protocols and codecs TS 26.234". 381 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 382 August 1980. 384 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 385 RFC 793, September 1981. 387 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 388 Floyd, S., and M. Luby, "Reliable Multicast Transport 389 Building Blocks for One-to-Many Bulk-Data Transfer", 390 RFC 3048, January 2001. 392 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 393 A., Peterson, J., Sparks, R., Handley, M., and E. 394 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 395 June 2002. 397 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 398 with Session Description Protocol (SDP)", RFC 3264, 399 June 2002. 401 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 402 Engineering Task Force Standard Protocols", BCP 61, 403 RFC 3365, August 2002. 405 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 406 Jacobson, "RTP: A Transport Protocol for Real-Time 407 Applications", STD 64, RFC 3550, July 2003. 409 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 410 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 411 RFC 3711, March 2004. 413 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 414 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 415 August 2004. 417 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 418 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 420 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 421 Security", RFC 4347, April 2006. 423 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 424 Description Protocol", RFC 4566, July 2006. 426 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 427 Carrara, "Key Management Extensions for Session 428 Description Protocol (SDP) and Real Time Streaming 429 Protocol (RTSP)", RFC 4567, July 2006. 431 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 432 Description Protocol (SDP) Security Descriptions for Media 433 Streams", RFC 4568, July 2006. 435 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 436 for Transmission Control Protocol (TCP) Specification 437 Documents", RFC 4614, September 2006. 439 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 440 RFC 4960, September 2007. 442 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 443 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 445 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 446 "Requirements and Analysis of Media Security Management 447 Protocols", RFC 5479, April 2009. 449 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 450 Security (DTLS) Extension to Establish Keys for the Secure 451 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 453 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 454 Path Key Agreement for Unicast Secure RTP", RFC 6189, 455 April 2011. 457 [TS-33210] 458 3GPP, "IP network layer security", 3GPP TS 33.210. 460 Authors' Addresses 462 Colin Perkins 463 University of Glasgow 464 Department of Computing Science 465 Glasgow G12 8QQ 466 UK 468 Email: csp@csperkins.org 470 Magnus Westerlund 471 Ericsson 472 Farogatan 6 473 Kista SE-164 80 474 Sweden 476 Email: magnus.westerlund@ericsson.com