idnits 2.17.1 draft-johnston-rtcweb-media-privacy-00.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2011) is 4712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Johnston 3 Internet-Draft Avaya 4 Intended status: Standards Track P. Zimmermann 5 Expires: December 2, 2011 Zfone Project 6 May 31, 2011 8 RTCWEB Media Privacy 9 draft-johnston-rtcweb-media-privacy-00 11 Abstract 13 RTCWEB is the joint effort between the IETF and the W3C to add real- 14 time voice, video, and communication capabilities to browsers. This 15 document looks at the requirements for media privacy and existing 16 mechanisms. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 2, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Media Security Requirements . . . . . . . . . . . . . . . . . . 3 54 3. Security Mechanism Discussion . . . . . . . . . . . . . . . . . 4 55 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1. Introduction 62 The requirements for real-time communications in web browsers or 63 RTCWEB are currently being discussed and developed. For both the 64 IETF and the W3C, there are significant challenges due to the unique 65 architecture of browsers. 67 The same is true for security as well - the requirements are 68 evolving, but starting to come into focus. This draft raises a few 69 issues relating to media security and privacy, something the authors 70 have spent considerable time and effort thinking, writing, and 71 deploying code over the past seven years. 73 2. Media Security Requirements 75 One possible model for RTCWEB is described in 76 [I-D.alvestrand-dispatch-rtcweb-protocols], which is summarized here. 77 To implement RTCWEB, both signaling and media is needed. Media for 78 audio and video will likely use RTP [RFC3550], and using some NAT 79 traversal/media authorization approach, will ideally go end-to-end 80 between the two browsers, bypassing the web server and any 81 intermediaries. ICE [RFC5245] is commonly mentioned as a potential 82 protocol for both the NAT traversal method and also for the media 83 authorization method. 85 Signaling is quite a different story, however. This approach does 86 not standardize any signaling between the browser and the web server. 87 Instead, the state machine and capability negotiation abilities will 88 be downloaded from the web server into the browser - the same way 89 other features and functionality are provided in web apps and pages 90 today. For example, Javascript could be used for this purpose. 92 There are two interesting side effects of this. It means that there 93 will be many different signaling protocols used for RTCWEB. Also, it 94 means that will not be any single security or trust model for the 95 signaling - it will depend on the web page, the application, and the 96 way in which the signaling works. 98 Both of these side effects pose significant challenges for media 99 security. The best way to secure RTP streams is to use SRTP 100 [RFC3711]. However, SRTP requires a key management protocol. A key 101 management protocol generates and distributes the symmetric secret 102 keys to the sender and receiver of the stream. The simplest SRTP key 103 management is to have the SRTP sender generate the key and use the 104 signaling channel to send it to the receiver. However, in order to 105 do this, the signaling protocol must meet some security requirements 106 relating to confidentiality. In the RTCWEB architecture, there is no 107 standardization of the signaling protocol possible, and hence this 108 approach can not be used. Another approach which does not rely on 109 security properties of the signaling protocol is to use a key 110 management system backed by a PKI. In this way, secret keys can be 111 transported by any signaling protocol. However, this requires public 112 private key pairs on every browser, and the infrastructure to manage 113 them. 115 Instead, what is needed is a key management protocol for SRTP that 116 does not place any reliance on the signaling protocol. 118 3. Security Mechanism Discussion 120 The issues and requirements in the previous section are very 121 different from those normally encountered in telephony systems. 122 Nearly all key management protocols for SRTP either rely on a PKI- 123 backed certificate or place strict requirements and trust on the 124 signaling layer. However, the ZRTP key management protocol [RFC6189] 125 does not. In fact, to read its design principles, one might come to 126 the conclusion that it was specifically designed for RTCWEB, despite 127 the fact that it predates the RTCWEB effort by five years. 129 ZRTP is an entirely self-contained key management protocol for SRTP 130 that places no requirements or reliance on the signaling path. It 131 was originally designed as an extension to RTP, but is now a separate 132 protocol that runs over the same ports and IP addresses as an RTP 133 stream. Today, ZRTP is used with SIP, Jingle, and even proprietary 134 VoIP (Voice over IP) and video systems - the only requirement is that 135 they use RTP for media. This flexibility is something that is simply 136 not possible for other key management protocols. It implements its 137 own discovery mechanism, having first applied the concept of "Best 138 Effort Encryption" to VoIP as defined in [RFC5479]. It uses an in- 139 band Diffie Hellman exchange to generate the secret keying material 140 for SRTP. ZRTP avoids the need for PKI backed certificates by using 141 techniques borrowed from SSH and key continuity. 143 ZRTP has been widely discussed in the IETF, and has been published by 144 the IETF as an informational RFC, to document an existing and 145 deployed security model. Through this process, ZRTP benefited from 146 significant review from the IETF and security community. ZRTP 147 inspired other media-path keying protocols such as DTLS/SRTP 148 [RFC5764]. However, DTLS-SRTP missed the mark on many of the key 149 advantages of ZRTP and has seen little or no deployment or interest 150 in the marketplace despite being published as a proposed standard. 151 The single most important failure is its reliance on either PKI 152 backed endpoint certificates, or on an end-to-end integrity protected 153 signaling path. While there are SIP mechanisms that have been 154 published to implement an end-to-end integrity protected signaling 155 path [RFC4474], this approach also has no deployment and no traction 156 in the industry. As discussed earlier, there is way to place any 157 requirements on the signaling protocol, let alone one as difficult as 158 end-to-end integrity protection. 160 In the development of ZRTP, it was realized that there are scenarios 161 in which the media can not be encrypted end-to-end. For example, 162 when a client has a trusted server or PBX which provides media 163 services in the path. For these cases, ZRTP developed mechanisms for 164 handling a "trusted MiTM" which can terminate than reoriginate the 165 SRTP encryption. This is done without compromising the basic 166 security of the protocol, or allowing arbitrary MiTM entities in the 167 media path. With RTCWEB applications, there may be cases where the 168 web server application is providing media services and hence needs 169 access to the media path. ZRTP can support these scenarios, allowing 170 for a user to explicitly authorize this, while still having all the 171 benefits of ZRTP. ZRTP also handles cases where each endpoint of a 172 communications session have a trusted MiTM. In this case, there will 173 actually be three separately encrypted media paths. These types of 174 scenarios could easily be encountered where each user has a trusted 175 MiTM web server. 177 To take full advantage of ZRTP, a voice path is needed in order for 178 users to compare the Short Authentication String (SAS). However, 179 ZRTP still provides security similar to SSH in its key continuity. 180 Also, ZRTP normally requires a display for rendering the SAS, but 181 this is not an issue for a browser. 183 RFC 6189 documents the ZRTP protocol as it is deployed today in VoIP 184 systems. For the RTCWEB application, it is likely that modifications 185 and enhancements might need to be made. It is the hope of the 186 authors that these modifications could be done by the working group 187 in a way that does not compromise the core principles of ZRTP, and 188 also perhaps provides fallback interoperabilty between browsers and 189 existing ZRTP VoIP devices and systems. 191 4. Summary 193 In summary, this draft has discussed some of the unique requirements 194 of RTCWEB media security and shown that ZRTP actually meets these. 195 In fact, the authors believe that ZRTP is ideally architected for 196 providing media security, privacy, and even some identity services 197 for RTCWEB. ZRTP is not perfect, but it has the correct architecture 198 that other protocols do not have, and can be adapted to meet the 199 needs of the RTCWEB effort. 201 5. Security Considerations 203 This whole document is about security. In the RTCWEB effort, we are 204 hoping to provide a browser based real-time communication platform 205 that can be trusted and used by Internet users worldwide. The 206 privacy of the browser to browser media path should be our most 207 important concern. Choosing the wrong media security approach will 208 hurt users of the Internet and limit the usefulness of the HTML5 209 RTCWEB extensions. It is the hope of the authors that the IETF will 210 take this responsibility seriously and give users of RTCWEB the best 211 options for media security and privacy. 213 6. Informative References 215 [I-D.alvestrand-dispatch-rtcweb-protocols] 216 Alvestrand, H., "Overview: Real Time Protocols for Brower- 217 based Applications", 218 draft-alvestrand-dispatch-rtcweb-protocols-01 (work in 219 progress), March 2011. 221 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 222 Jacobson, "RTP: A Transport Protocol for Real-Time 223 Applications", STD 64, RFC 3550, July 2003. 225 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 226 (ICE): A Protocol for Network Address Translator (NAT) 227 Traversal for Offer/Answer Protocols", RFC 5245, 228 April 2010. 230 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 231 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 232 RFC 3711, March 2004. 234 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 235 Path Key Agreement for Unicast Secure RTP", RFC 6189, 236 April 2011. 238 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 239 "Requirements and Analysis of Media Security Management 240 Protocols", RFC 5479, April 2009. 242 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 243 Security (DTLS) Extension to Establish Keys for the Secure 244 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 246 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 247 Authenticated Identity Management in the Session 248 Initiation Protocol (SIP)", RFC 4474, August 2006. 250 Authors' Addresses 252 Alan Johnston 253 Avaya 254 St. Louis, MO 63124 256 Email: alan.b.johnston@gmail.com 258 Philip Zimmermann 259 Zfone Project 261 Email: prz@mit.edu