idnits 2.17.1 draft-ohlsson-rtcweb-sdes-support-01.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 (August 20, 2012) is 4267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'I-D.kaplan-rtcweb-sip-interworking-requirements' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC4568' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC5763' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC5764' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-00 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-04 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-09 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Ohlsson 3 Internet-Draft Ericsson 4 Intended status: Informational August 20, 2012 5 Expires: February 21, 2013 7 Support of SDES in WebRTC 8 draft-ohlsson-rtcweb-sdes-support-01 10 Abstract 12 Which key management protocols to support has been lively debated in 13 WebRTC on several occasions. This document explains the benefits of 14 SDES and argues why allowing it as an alternative option has little 15 impact on security. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 21, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Benefits of Supporting SDES . . . . . . . . . . . . . . . . . 3 53 2.1. Reduced Complexity of WebRTC-SIP Gateway . . . . . . . . . 3 54 2.2. Reduced Processing (Less SRTP Terminations) . . . . . . . 3 55 2.3. Reduced Call Setup Time . . . . . . . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 3.1. SDES in case of an Outside Attacker . . . . . . . . . . . 5 58 3.1.1. Extraction of Log Data . . . . . . . . . . . . . . . . 6 59 3.1.2. Script Injection . . . . . . . . . . . . . . . . . . . 6 60 3.2. SDES in case of an Inside Attacker . . . . . . . . . . . . 7 61 3.2.1. Downgrade Attack . . . . . . . . . . . . . . . . . . . 7 62 3.2.2. Difficulties with Key Continuity . . . . . . . . . . . 8 63 3.2.3. 3rd Party Identity Assertion . . . . . . . . . . . . . 9 64 4. Discussion and Conclusion . . . . . . . . . . . . . . . . . . 9 65 5. Informative References . . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 Which key management protocols to support has been lively debated in 71 WebRTC on several occasions. The main question is the following: 72 Should applications be restricted to DTLS-SRTP or could SDES be 73 allowed as an alternative option? 75 In this document we identify and address the issues that have been 76 raised. We explain the benefits of SDES and argue why allowing it as 77 an alternative option has little impact on security. 79 2. Benefits of Supporting SDES 81 Being able to communicate from WebRTC applications to existing SIP/ 82 RTP endpoints is a highly desirable use case. The SIP installed base 83 is huge and contains millions of devices and a large number of 84 applications (e.g. conferencing and voicemail). Even more important, 85 nearly all mobile phones and landlines are reachable through SIP/RTP 86 gateways deployed in service provider networks. The same can also be 87 said for other signaling protocols, such as XMPP or H.323. As a 88 sidenote, the recent work on the DTMF tone API in WebRTC proves that 89 many members consider legacy interworking to be important. 91 2.1. Reduced Complexity of WebRTC-SIP Gateway 93 Communication between the Browser and SIP/RTP endpoint will most 94 likely require some form om media-plane gateway (due to the need to 95 terminate ICE). The development and testing costs for such gateways 96 are typically very high since they need to handle a large number of 97 users and often contain special purpose hardware. It is definitely 98 worthwhile to try to reduce costs by lowering the complexity and 99 removing functionality that is not strictly required. This would 100 result in lower prices which will lead to a higher degree of 101 interconnectivity between WebRTC and existing SIP deployments. 103 Already today there are Session Border Controllers (SBC) that perform 104 SRTP termination on behalf of endpoints with SDES based keying (there 105 are SBCs that support DTLS-SRTP but this is uncommon). If the 106 browser also supported SDES, the WebRTC gateway could simply forward 107 all SRTP packets to the SBC and let it decide whether to terminate 108 encryption or not (depending on the capabilities of the receiving 109 endpoint). 111 2.2. Reduced Processing (Less SRTP Terminations) 113 A large part of modern SIP/RTP devices support SRTP and most of them 114 that do, use SDES based keying. This is confirmed in the report from 115 the latest [SIPit] event which stated that: 117 o 80 percent of the tested implementations supported SRTP 119 o 100 percent of the SRTP implementations supported SDES 121 o 0 percent of the SRTP implementations supported DTLS-SRTP 123 Although these figures may not be entirely accurate, they at least 124 provide an indication of the current situation. 126 The 3rd Generation Partnership Project (3GPP) has also selected SDES 127 for key management in the IP Multimedia Subsystem (IMS) 128 [3GPP.33.328]. We can therefore expect the number of SDES capable 129 devices to increase as Voice over LTE (VoLTE) and other IMS based 130 systems become more widely deployed. 132 Provided SDES is included in browsers, calls between the WebRTC and 133 SIP domains do not need to be encrypted/decrypted by an intermediate 134 gateway when the SIP endpoint supports SDES. This leads to a 135 substantial reduction in processing cost for the gateway in SIP 136 domains where a large part of the devices support SDES. Another 137 benefit is that for those endpoints that support SDES the call will 138 be protected end-to-end for free. Achieving this with DTLS-SRTP 139 would require the gateway to first decrypt and then re-encrypt 140 traffic. 142 Note that the important question is whether the gateway needs to 143 terminate SRTP at all. Processing wise there is probably not that 144 much difference in terminating an SRTP + SDES or an SRTP + DTLS-SRTP 145 call. 147 DTLS-SRTP with Encrypted Key Transport (EKT) 148 [I-D.ietf-avtcore-srtp-ekt] has been suggested as an alternative to 149 avoid expensive encryption/decryption in gateways. If browsers 150 support DTLS-SRTP with EKT, a gateway can force the browser and the 151 SDES endpoint to agree on the same set of SRTP keys and algorithm 152 settings. Once this is done, the gateway will simply forward the 153 SRTP (and SRTCP) packets in both directions. The downside of using 154 this approach is the increased complexity of the gateway (new 155 protocols and additional signaling are required) and the lack of 156 implementation experience. 158 2.3. Reduced Call Setup Time 160 With SDES a peer can begin to send media as soon as an ICE candidate 161 pair has been nominated for use and the connectivity check for that 162 pair has succeeded. If DTLS-SRTP is being used the peer would also 163 need to wait for the DTLS-SRTP handshake to complete, which requires 164 two additional roundtrips. 166 Obviously, being able to start sending media quickly is not very 167 useful unless the receiver knows how to process the incoming packets. 168 One common argument against SDES is its inability to handle early 169 media (i.e. media that arrives at the SDP offerer before the SDP 170 answer arrives). However, this problem cannot occur if the offerer 171 is ICE full. To see why, recall that sending media requires that a 172 candidate pair has been nominated for use by the ICE controlling 173 agent, which is always the offerer when the offerer is ICE full. 174 Since nomination is done by sending a connectivity check (with the 175 nomination flag set) which requires the password provided in the SDP 176 answer, no pair gets nominated at the answerer and no media is sent 177 before the SDP answer has arrived at the offerer. 179 If the offerer is ICE lite or if multiplexing is used (i.e. all media 180 streams are sent over a single ICE candidate pair) and an additional 181 media stream is added later in time via an updated offer, then the 182 problem with early media could arise when SDES is used (but never 183 with DTLS-SRTP). 185 3. Security Considerations 187 At this point most readers should agree that SDES is favourable from 188 an interworking point of view. It is also clear that implementing 189 SDES in WebRTC is a relatively straight forward task. What remains 190 to be considered are its impacts on security. 192 We distinguish between the following two types of attackers: 194 Outside Attacker An external party attempts to intercept a call 195 (e.g. a host located on the same WLAN as the 196 user) 198 Inside Attacker The web application itself (or the signaling 199 server, in case the web server and signaling 200 server are separated) attempts to intercept a 201 call 203 3.1. SDES in case of an Outside Attacker 205 By requiring that signaling is secured using TLS, an outside attacker 206 that monitors network traffic will not be able to extract the SDES 207 keys. Therefore, in this scenario both SDES and DTLS-SRTP provide a 208 sufficient level of protection. 210 The two other types of attacks that have been mentioned in this 211 context are extraction of log data and code injection, each of which 212 are considered below. 214 3.1.1. Extraction of Log Data 216 In this scenario the attacker manages to decrypt a previously 217 recorded call by attacking the signaling server and extracting the 218 SDES keys from the server log. 220 First of all, if the attacker gets as far as reading the logging data 221 then eavesdropping of past calls is probably not the only problem. 222 The effort required to break into the server is also related to the 223 amount of trust the user assigns to the web application: well trusted 224 sites often have well protected servers. 226 Secondly, it can be questioned how common this type of extensive 227 logging really is. Storing passwords and other sensitive information 228 in log files is an implementation mistake that can easily be avoided. 230 Finally, SDES will primarily be used when interworking with existing 231 SIP systems deployed within enterprises or service providers. These 232 have been using SDES for a long time and know that it is critical to 233 protect the plain text keys. 235 3.1.2. Script Injection 237 In this scenario the attacker manages to inject his own piece of 238 JavaScript into the WebRTC application. The next time a user 239 downloads the application and places a call, the script will execute 240 and start eavesdropping on the conversation. 242 There are three major ways in which code can be injected into a web 243 application: 245 o The page itself or one of its included JavaScript files is 246 downloaded over a non-HTTPS link and is modified en route 248 o The web application intentionally includes JavaScript supplied by 249 the attacker (e.g. a third-party library or advertisement) 251 o HTML form input or URL parameters are not properly sanitized (i.e. 252 classical XSS vulnerability) 254 Modification en route is prevented by requiring HTTPS to be used for 255 all content. Whether the two other injection techniques are feasible 256 or not largely depends on the application. 258 If script injection occurs then there are other methods to intercept 259 a call, like establishing additional PeerConnection objects or use a 260 recording interface and send the data using WebSocket. As long as 261 these methods are available it does not matter much whether the 262 application uses SDES or DTLS-SRTP. 264 In general, if an attacker manages to execute even a small piece of 265 JavaScript then he has effectively gained full control of the 266 application (additional code can be included and HTML elements 267 removed/inserted). Since this situation is exactly the same as the 268 situation with an inside attacker, script injection will not be 269 discussed further. 271 3.2. SDES in case of an Inside Attacker 273 First of all, it can be questioned if we really want to protect 274 ourselves against an inside attacker. If consent is required every 275 time the application wants to record or forward media then the user 276 experience will suffer. One could also imagine future applications 277 that want to use their own codecs or filters (for example a voice 278 scrambler or face detection software), something which is difficult 279 to achieve without access to the underlying bitstreams. 281 We ignore this problem for now and simply assume that the application 282 cannot access the media from within the browser. In other words, we 283 only consider protection of the media during transport. 285 3.2.1. Downgrade Attack 287 The major argument against SDES is that it would make it trivial for 288 the application to perform interception. Let us compare what would 289 be required in both cases. 291 Interception of SDES call: 293 1. Copy and store the 'a=crypto:' lines in the offer/answer SDP 295 2. Force media to pass through TURN server by deleting all 296 candidates except the relayed one 298 3. Store all SRTP packets that pass through the TURN server and 299 decrypt them later on (using the keys from step 1) 301 Interception of DTLS-SRTP call: 303 1. Replace the 'a=fingerprint:' lines in the offer/answer SDP with 304 the fingerprint of a public key generated by the application 306 2. Force the media to go through the TURN server by deleting all ICE 307 candidates except the relayed one 309 3. Modify an existing TURN server implementation so that it decrypts 310 and re-encrypts the DTLS traffic (using the public-private key 311 pair from step 1) 313 Putting the modified TURN server into place is the hardest part of 314 intercepting a DTLS-SRTP call. Once this is done however, the 315 remaining steps are fairly straightforward. This shows that neither 316 DTLS-SRTP nor SDES provides any significant protection against an 317 inside attacker. 319 There is one benefit of DTLS-SRTP that is not directly apparent from 320 the above description. If both users read their respective 321 fingerprint values over the voice channel then they can detect if the 322 conversation is being intercepted. However, it is very unlikely that 323 the average user would bother doing this. 325 3.2.2. Difficulties with Key Continuity 327 The comparison in the previous section is somewhat simplified since 328 it does not consider DTLS-SRTP key continuity. The way this 329 mechanism works is that the browser will notify the user whenever it 330 receives a certificate which has not previously been seen (i.e. not 331 present in the browser cache). Since the user will receive this 332 notification every time he calls someone new and whenever someone 333 changes browser, it is very likely that he/she will simply ignore it. 335 Reuse of public keys also has privacy implications as it enables user 336 tracking. A user that wants to remain anonymous towards a service 337 provider would need to generate a fresh key for each interaction. 338 Furthermore, in order to avoid colluding service providers (e.g. 339 medical clinics and insurance agencies) from linking a user's 340 activities, separate certificates are needed for different domains. 341 However, storing domain names together with the certificates might 342 allow the next browser user (e.g. a family member) to see which sites 343 the previous user visited. All of this leads to more certificates 344 being generated which in turn results in even more "new key" 345 notifications. 347 It is also important to understand that the cached certificates are 348 not bound to any identity (the certificates are simple containers for 349 the public key without any additional information). This means that 350 if just one of the cached keys is compromised any user call can be 351 intercepted without causing the "new key" notification to be 352 displayed. Note that the risk of this happening is directly related 353 to the size of the cache, which grows over time. 355 3.2.3. 3rd Party Identity Assertion 357 [I-D.rescorla-rtcweb-generic-idp] suggests a way to strengthen the 358 security of DTLS-SRTP by validating the received fingerprint via an 359 identity provider. At the time of writing there are still some 360 details missing from the proposal (for example, it is not clear how 361 the identity provider is selected in practice or how the peer 362 identity is displayed to the user) but it definitely seems promising. 363 Such a mechanism (including the necessary browser chrome) would make 364 it significantly harder for the application to act as man-in-the- 365 middle. 367 The question is whether the identity mechanism is optional or not, 368 i.e. will it be possible for an application to use "plain" DTLS-SRTP. 369 The answer is most likely "yes" due to the following reasons: 371 o Many applications are already trusted by the user 373 o Some applications do not want to depend on third parties 375 o Some users do not have any identity provider account 377 o Users may not always want to reveal their identity 379 o Working out all the details of the identity mechanism will take 380 time (and if it is not mandatory from start there are backward 381 compatibility issues) 383 Note that allowing an application to be its own identity provider is 384 effectively the same as allowing plain DTLS-SRTP (the user trusts the 385 application) only more complicated. 387 4. Discussion and Conclusion 389 We are not looking to replace DTLS-SRTP with SDES. The 20-line 390 WebRTC developer will continue to use the default option which is 391 DTLS-SRTP, while others who are interested in interworking will 392 select SDES. The latter group will be required to use HTTPS for all 393 content and can be informed of the necessary precautions (secure 394 storage of log files or otherwise no extensive logging). 396 The main issue that appears to concern members is the application's 397 ability to downgrade security. But as we have seen it is not 398 significantly harder for the application to attack DTLS-SRTP. The 399 main advantage of DTLS-SRTP is the possibility to detect when a call 400 is being intercepted. However, doing so requires an effort from the 401 user and a certain degree of technical skill. 403 It has been suggested that additional identity mechanisms could 404 prevent the application from listening in on calls. While this is 405 certainly true, any such mechanism would most likely be made 406 optional. If that is the case or if an application can be its own 407 identity provider, then we are back at the situation where the user 408 has to decide which sites to trust. 410 It can also be questioned to what extent the application should be 411 restricted from accessing media since this limits usability and 412 innovativity. The W3C would need to update its specifications and 413 ensure that a web application cannot record or forward a MediaStream 414 without permission from the user. 416 5. Informative References 418 [3GPP.33.328] 419 3GPP, "IP Multimedia Subsystem (IMS) media plane 420 security", 3GPP TS 33.328 9.3.0, December 2010, 421 . 423 [I-D.ietf-avtcore-srtp-ekt] 424 McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 425 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 426 (work in progress), July 2012. 428 [I-D.ietf-rtcweb-overview] 429 Alvestrand, H., "Overview: Real Time Protocols for Brower- 430 based Applications", draft-ietf-rtcweb-overview-04 (work 431 in progress), June 2012. 433 [I-D.ietf-rtcweb-use-cases-and-requirements] 434 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 435 Time Communication Use-cases and Requirements", 436 draft-ietf-rtcweb-use-cases-and-requirements-09 (work in 437 progress), June 2012. 439 [I-D.kaplan-rtcweb-sip-interworking-requirements] 440 Kaplan, H., "Requirements for Interworking WebRTC with 441 Current SIP Deployments", 442 draft-kaplan-rtcweb-sip-interworking-requirements-02 (work 443 in progress), November 2011. 445 [I-D.rescorla-rtcweb-generic-idp] 446 Rescorla, E., "RTCWEB Generic Identity Provider 447 Interface", draft-rescorla-rtcweb-generic-idp-01 (work in 448 progress), March 2012. 450 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 451 Description Protocol (SDP) Security Descriptions for Media 452 Streams", RFC 4568, July 2006. 454 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 455 for Establishing a Secure Real-time Transport Protocol 456 (SRTP) Security Context Using Datagram Transport Layer 457 Security (DTLS)", RFC 5763, May 2010. 459 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 460 Security (DTLS) Extension to Establish Keys for the Secure 461 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 463 [SIPit] "SIPit27 Summary", 464 . 466 Author's Address 468 Oscar Ohlsson 469 Ericsson 470 Farogatan 6 471 SE-164 80 Kista 472 Sweden 474 Email: oscar.ohlsson@ericsson.com