idnits 2.17.1 draft-ietf-rtcweb-security-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.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2011) is 4560 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) == Missing Reference: 'REF' is mentioned on line 1122, but not defined -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTC-Web E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track October 30, 2011 5 Expires: May 2, 2012 7 Security Considerations for RTC-Web 8 draft-ietf-rtcweb-security-01 10 Abstract 12 The Real-Time Communications on the Web (RTC-Web) working group is 13 tasked with standardizing protocols for real-time communications 14 between Web browsers. The major use cases for RTC-Web technology are 15 real-time audio and/or video calls, Web conferencing, and direct data 16 transfer. Unlike most conventional real-time systems (e.g., SIP- 17 based soft phones) RTC-Web communications are directly controlled by 18 some Web server, which poses new security challenges. For instance, 19 a Web browser might expose a JavaScript API which allows a server to 20 place a video call. Unrestricted access to such an API would allow 21 any site which a user visited to "bug" a user's computer, capturing 22 any activity which passed in front of their camera. This document 23 defines the RTC-Web threat model and defines an architecture which 24 provides security within that threat model. 26 Legal 28 THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON 29 AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 30 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 31 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL 32 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 33 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 34 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 35 FOR A PARTICULAR PURPOSE. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 2, 2012. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. The Browser Threat Model . . . . . . . . . . . . . . . . . . . 6 86 3.1. Access to Local Resources . . . . . . . . . . . . . . . . 7 87 3.2. Same Origin Policy . . . . . . . . . . . . . . . . . . . . 7 88 3.3. Bypassing SOP: CORS, WebSockets, and consent to 89 communicate . . . . . . . . . . . . . . . . . . . . . . . 8 90 4. Security for RTC-Web Applications . . . . . . . . . . . . . . 8 91 4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 8 92 4.1.1. Calling Scenarios and User Expectations . . . . . . . 9 93 4.1.1.1. Dedicated Calling Services . . . . . . . . . . . . 9 94 4.1.1.2. Calling the Site You're On . . . . . . . . . . . . 9 95 4.1.1.3. Calling to an Ad Target . . . . . . . . . . . . . 10 96 4.1.2. Origin-Based Security . . . . . . . . . . . . . . . . 10 97 4.1.3. Security Properties of the Calling Page . . . . . . . 12 98 4.2. Communications Consent Verification . . . . . . . . . . . 13 99 4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 14 101 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . . 14 102 4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15 103 4.3. Communications Security . . . . . . . . . . . . . . . . . 15 104 4.3.1. Protecting Against Retrospective Compromise . . . . . 16 105 4.3.2. Protecting Against During-Call Attack . . . . . . . . 17 106 4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . . 17 107 4.3.2.2. Short Authentication Strings . . . . . . . . . . . 18 108 4.3.2.3. Recommendations . . . . . . . . . . . . . . . . . 19 109 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 110 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 111 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 113 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 114 Appendix A. A Proposed Security Architecture [No Consensus on 115 This] . . . . . . . . . . . . . . . . . . . . . . . . 22 116 A.1. Trust Hierarchy . . . . . . . . . . . . . . . . . . . . . 22 117 A.1.1. Authenticated Entities . . . . . . . . . . . . . . . . 22 118 A.1.2. Unauthenticated Entities . . . . . . . . . . . . . . . 23 119 A.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 A.2.1. Initial Signaling . . . . . . . . . . . . . . . . . . 24 121 A.2.2. Media Consent Verification . . . . . . . . . . . . . . 26 122 A.2.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . 26 123 A.2.4. Communications and Consent Freshness . . . . . . . . . 27 124 A.3. Detailed Technical Description . . . . . . . . . . . . . . 27 125 A.3.1. Origin and Web Security Issues . . . . . . . . . . . . 27 126 A.3.2. Device Permissions Model . . . . . . . . . . . . . . . 28 127 A.3.3. Communications Consent . . . . . . . . . . . . . . . . 29 128 A.3.4. IP Location Privacy . . . . . . . . . . . . . . . . . 29 129 A.3.5. Communications Security . . . . . . . . . . . . . . . 30 130 A.3.6. Web-Based Peer Authentication . . . . . . . . . . . . 31 131 A.3.6.1. Generic Concepts . . . . . . . . . . . . . . . . . 31 132 A.3.6.2. BrowserID . . . . . . . . . . . . . . . . . . . . 32 133 A.3.6.3. OAuth . . . . . . . . . . . . . . . . . . . . . . 35 134 A.3.6.4. Generic Identity Support . . . . . . . . . . . . . 36 135 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 137 1. Introduction 139 The Real-Time Communications on the Web (RTC-Web) working group is 140 tasked with standardizing protocols for real-time communications 141 between Web browsers. The major use cases for RTC-Web technology are 142 real-time audio and/or video calls, Web conferencing, and direct data 143 transfer. Unlike most conventional real-time systems, (e.g., SIP- 144 based[RFC3261] soft phones) RTC-Web communications are directly 145 controlled by some Web server. A simple case is shown below. 147 +----------------+ 148 | | 149 | Web Server | 150 | | 151 +----------------+ 152 ^ ^ 153 / \ 154 HTTP / \ HTTP 155 / \ 156 / \ 157 v v 158 JS API JS API 159 +-----------+ +-----------+ 160 | | Media | | 161 | Browser |<---------->| Browser | 162 | | | | 163 +-----------+ +-----------+ 165 Figure 1: A simple RTC-Web system 167 In the system shown in Figure 1, Alice and Bob both have RTC-Web 168 enabled browsers and they visit some Web server which operates a 169 calling service. Each of their browsers exposes standardized 170 JavaScript calling APIs which are used by the Web server to set up a 171 call between Alice and Bob. While this system is topologically 172 similar to a conventional SIP-based system (with the Web server 173 acting as the signaling service and browsers acting as softphones), 174 control has moved to the central Web server; the browser simply 175 provides API points that are used by the calling service. As with 176 any Web application, the Web server can move logic between the server 177 and JavaScript in the browser, but regardless of where the code is 178 executing, it is ultimately under control of the server. 180 It should be immediately apparent that this type of system poses new 181 security challenges beyond those of a conventional VoIP system. In 182 particular, it needs to contend with malicious calling services. For 183 example, if the calling service can cause the browser to make a call 184 at any time to any callee of its choice, then this facility can be 185 used to bug a user's computer without their knowledge, simply by 186 placing a call to some recording service. More subtly, if the 187 exposed APIs allow the server to instruct the browser to send 188 arbitrary content, then they can be used to bypass firewalls or mount 189 denial of service attacks. Any successful system will need to be 190 resistant to this and other attacks. 192 2. Terminology 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC2119]. 198 3. The Browser Threat Model 200 The security requirements for RTC-Web follow directly from the 201 requirement that the browser's job is to protect the user. Huang et 202 al. [huang-w2sp] summarize the core browser security guarantee as: 204 Users can safely visit arbitrary web sites and execute scripts 205 provided by those sites. 207 It is important to realize that this includes sites hosting arbitrary 208 malicious scripts. The motivation for this requirement is simple: 209 it is trivial for attackers to divert users to sites of their choice. 210 For instance, an attacker can purchase display advertisements which 211 direct the user (either automatically or via user clicking) to their 212 site, at which point the browser will execute the attacker's scripts. 213 Thus, it is important that it be safe to view arbitrarily malicious 214 pages. Of course, browsers inevitably have bugs which cause them to 215 fall short of this goal, but any new RTC-Web functionality must be 216 designed with the intent to meet this standard. The remainder of 217 this section provides more background on the existing Web security 218 model. 220 In this model, then, the browser acts as a TRUSTED COMPUTING BASE 221 (TCB) both from the user's perspective and to some extent from the 222 server's. While HTML and JS provided by the server can cause the 223 browser to execute a variety of actions, those scripts operate in a 224 sandbox that isolates them both from the user's computer and from 225 each other, as detailed below. 227 Conventionally, we refer to either WEB ATTACKERS, who are able to 228 induce you to visit their sites but do not control the network, and 229 NETWORK ATTACKERS, who are able to control your network. Network 230 attackers correspond to the [RFC3552] "Internet Threat Model". In 231 general, it is desirable to build a system which is secure against 232 both kinds of attackers, but realistically many sites do not run 233 HTTPS [RFC2818] and so our ability to defend against network 234 attackers is necessarily somewhat limited. Most of the rest of this 235 section is devoted to web attackers, with the assumption that 236 protection against network attackers is provided by running HTTPS. 238 3.1. Access to Local Resources 240 While the browser has access to local resources such as keying 241 material, files, the camera and the microphone, it strictly limits or 242 forbids web servers from accessing those same resources. For 243 instance, while it is possible to produce an HTML form which will 244 allow file upload, a script cannot do so without user consent and in 245 fact cannot even suggest a specific file (e.g., /etc/passwd); the 246 user must explicitly select the file and consent to its upload. 247 [Note: in many cases browsers are explicitly designed to avoid 248 dialogs with the semantics of "click here to screw yourself", as 249 extensive research shows that users are prone to consent under such 250 circumstances.] 252 Similarly, while Flash SWFs can access the camera and microphone, 253 they explicitly require that the user consent to that access. In 254 addition, some resources simply cannot be accessed from the browser 255 at all. For instance, there is no real way to run specific 256 executables directly from a script (though the user can of course be 257 induced to download executable files and run them). 259 3.2. Same Origin Policy 261 Many other resources are accessible but isolated. For instance, 262 while scripts are allowed to make HTTP requests via the 263 XMLHttpRequest() API those requests are not allowed to be made to any 264 server, but rather solely to the same ORIGIN from whence the script 265 came.[I-D.abarth-origin] (although CORS [CORS] and WebSockets 266 [I-D.ietf-hybi-thewebsocketprotocol] provides a escape hatch from 267 this restriction, as described below.) This SAME ORIGIN POLICY (SOP) 268 prevents server A from mounting attacks on server B via the user's 269 browser, which protects both the user (e.g., from misuse of his 270 credentials) and the server (e.g., from DoS attack). 272 More generally, SOP forces scripts from each site to run in their 273 own, isolated, sandboxes. While there are techniques to allow them 274 to interact, those interactions generally must be mutually consensual 275 (by each site) and are limited to certain channels. For instance, 276 multiple pages/browser panes from the same origin can read each 277 other's JS variables, but pages from the different origins--or even 278 iframes from different origins on the same page--cannot. 280 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate 282 While SOP serves an important security function, it also makes it 283 inconvenient to write certain classes of applications. In 284 particular, mash-ups, in which a script from origin A uses resources 285 from origin B, can only be achieved via a certain amount of hackery. 286 The W3C Cross-Origin Resource Sharing (CORS) spec [CORS] is a 287 response to this demand. In CORS, when a script from origin A 288 executes what would otherwise be a forbidden cross-origin request, 289 the browser instead contacts the target server to determine whether 290 it is willing to allow cross-origin requests from A. If it is so 291 willing, the browser then allows the request. This consent 292 verification process is designed to safely allow cross-origin 293 requests. 295 While CORS is designed to allow cross-origin HTTP requests, 296 WebSockets [I-D.ietf-hybi-thewebsocketprotocol] allows cross-origin 297 establishment of transparent channels. Once a WebSockets connection 298 has been established from a script to a site, the script can exchange 299 any traffic it likes without being required to frame it as a series 300 of HTTP request/response transactions. As with CORS, a WebSockets 301 transaction starts with a consent verification stage to avoid 302 allowing scripts to simply send arbitrary data to another origin. 304 While consent verification is conceptually simple--just do a 305 handshake before you start exchanging the real data--experience has 306 shown that designing a correct consent verification system is 307 difficult. In particular, Huang et al. [huang-w2sp] have shown 308 vulnerabilities in the existing Java and Flash consent verification 309 techniques and in a simplified version of the WebSockets handshake. 310 In particular, it is important to be wary of CROSS-PROTOCOL attacks 311 in which the attacking script generates traffic which is acceptable 312 to some non-Web protocol state machine. In order to resist this form 313 of attack, WebSockets incorporates a masking technique intended to 314 randomize the bits on the wire, thus making it more difficult to 315 generate traffic which resembles a given protocol. 317 4. Security for RTC-Web Applications 319 4.1. Access to Local Devices 321 As discussed in Section 1, allowing arbitrary sites to initiate calls 322 violates the core Web security guarantee; without some access 323 restrictions on local devices, any malicious site could simply bug a 324 user. At minimum, then, it MUST NOT be possible for arbitrary sites 325 to initiate calls to arbitrary locations without user consent. This 326 immediately raises the question, however, of what should be the scope 327 of user consent. 329 For the rest of this discussion we assume that the user is somehow 330 going to grant consent to some entity (e.g., a social networking 331 site) to initiate a call on his behalf. This consent may be limited 332 to a single call or may be a general consent. In order for the user 333 to make an intelligent decision about whether to allow a call (and 334 hence his camera and microphone input to be routed somewhere), he 335 must understand either who is requesting access, where the media is 336 going, or both. So, for instance, one might imagine that at the time 337 access to camera and microphone is requested, the user is shown a 338 dialog that says "site X has requested access to camera and 339 microphone, yes or no" (though note that this type of in-flow 340 interface violates one of the guidelines in Section 3). The user's 341 decision will of course be based on his opinion of Site X. However, 342 as discussed below, this is a complicated concept. 344 4.1.1. Calling Scenarios and User Expectations 346 While a large number of possible calling scenarios are possible, the 347 scenarios discussed in this section illustrate many of the 348 difficulties of identifying the relevant scope of consent. 350 4.1.1.1. Dedicated Calling Services 352 The first scenario we consider is a dedicated calling service. In 353 this case, the user has a relationship with a calling site and 354 repeatedly makes calls on it. It is likely that rather than having 355 to give permission for each call that the user will want to give the 356 calling service long-term access to the camera and microphone. This 357 is a natural fit for a long-term consent mechanism (e.g., installing 358 an app store "application" to indicate permission for the calling 359 service.) A variant of the dedicated calling service is a gaming 360 site (e.g., a poker site) which hosts a dedicated calling service to 361 allow players to call each other. 363 With any kind of service where the user may use the same service to 364 talk to many different people, there is a question about whether the 365 user can know who they are talking to. In general, this is difficult 366 as most of the user interface is presented by the calling site. 367 However, communications security mechanisms can be used to give some 368 assurance, as described in Section 4.3.2. 370 4.1.1.2. Calling the Site You're On 372 Another simple scenario is calling the site you're actually visiting. 373 The paradigmatic case here is the "click here to talk to a 374 representative" windows that appear on many shopping sites. In this 375 case, the user's expectation is that they are calling the site 376 they're actually visiting. However, it is unlikely that they want to 377 provide a general consent to such a site; just because I want some 378 information on a car doesn't mean that I want the car manufacturer to 379 be able to activate my microphone whenever they please. Thus, this 380 suggests the need for a second consent mechanism where I only grant 381 consent for the duration of a given call. As described in 382 Section 3.1, great care must be taken in the design of this interface 383 to avoid the users just clicking through. Note also that the user 384 interface chrome must clearly display elements showing that the call 385 is continuing in order to avoid attacks where the calling site just 386 leaves it up indefinitely but shows a Web UI that implies otherwise. 388 4.1.1.3. Calling to an Ad Target 390 In both of the previous cases, the user has a direct relationship 391 (though perhaps a transient one) with the target of the call. 392 Moreover, in both cases he is actually visiting the site of the 393 person he is being asked to trust. However, this is not always so. 394 Consider the case where a user is a visiting a content site which 395 hosts an advertisement with an invitation to call for more 396 information. When the user clicks the ad, they are connected with 397 the advertiser or their agent. 399 The relationships here are far more complicated: the site the user 400 is actually visiting has no direct relationship with the advertiser; 401 they are just hosting ads from an ad network. The user has no 402 relationship with the ad network, but desires one with the 403 advertiser, at least for long enough to learn about their products. 404 At minimum, then, whatever consent dialog is shown needs to allow the 405 user to have some idea of the organization that they are actually 406 calling. 408 However, because the user also has some relationship with the hosting 409 site, it is also arguable that the hosting site should be allowed to 410 express an opinion (e.g., to be able to allow or forbid a call) since 411 a bad experience with an advertiser reflect negatively on the hosting 412 site [this idea was suggested by Adam Barth]. However, this 413 obviously presents a privacy challenge, as sites which host 414 advertisements often learn very little about whether individual users 415 clicked through to the ads, or even which ads were presented. 417 4.1.2. Origin-Based Security 419 As discussed in Section 3.2, the basic unit of Web sandboxing is the 420 origin, and so it is natural to scope consent to origin. 421 Specifically, a script from origin A MUST only be allowed to initiate 422 communications (and hence to access camera and microphone) if the 423 user has specifically authorized access for that origin. It is of 424 course technically possible to have coarser-scoped permissions, but 425 because the Web model is scoped to origin, this creates a difficult 426 mismatch. 428 Arguably, origin is not fine-grained enough. Consider the situation 429 where Alice visits a site and authorizes it to make a single call. 430 If consent is expressed solely in terms of origin, then at any future 431 visit to that site (including one induced via mash-up or ad network), 432 the site can bug Alice's computer, use the computer to place bogus 433 calls, etc. While in principle Alice could grant and then revoke the 434 privilege, in practice privileges accumulate; if we are concerned 435 about this attack, something else is needed. There are a number of 436 potential countermeasures to this sort of issue. 438 Individual Consent 439 Ask the user for permission for each call. 441 Callee-oriented Consent 442 Only allow calls to a given user. 444 Cryptographic Consent 445 Only allow calls to a given set of peer keying material or to a 446 cryptographically established identity. 448 Unfortunately, none of these approaches is satisfactory for all 449 cases. As discussed above, individual consent puts the user's 450 approval in the UI flow for every call. Not only does this quickly 451 become annoying but it can train the user to simply click "OK", at 452 which point the consent becomes useless. Thus, while it may be 453 necessary to have individual consent in some case, this is not a 454 suitable solution for (for instance) the calling service case. Where 455 necessary, in-flow user interfaces must be carefully designed to 456 avoid the risk of the user blindly clicking through. 458 The other two options are designed to restrict calls to a given 459 target. Unfortunately, Callee-oriented consent does not work well 460 because a malicious site can claim that the user is calling any user 461 of his choice. One fix for this is to tie calls to a 462 cryptographically established identity. While not suitable for all 463 cases, this approach may be useful for some. If we consider the 464 advertising case described in Section 4.1.1.3, it's not particularly 465 convenient to require the advertiser to instantiate an iframe on the 466 hosting site just to get permission; a more convenient approach is to 467 cryptographically tie the advertiser's certificate to the 468 communication directly. We're still tying permissions to origin 469 here, but to the media origin (and-or destination) rather than to the 470 Web origin. 472 Another case where media-level cryptographic identity makes sense is 473 when a user really does not trust the calling site. For instance, I 474 might be worried that the calling service will attempt to bug my 475 computer, but I also want to be able to conveniently call my friends. 476 If consent is tied to particular communications endpoints, then my 477 risk is limited. However, this is also not that convenient an 478 interface, since managing individual user permissions can be painful. 480 While this is primarily a question not for IETF, it should be clear 481 that there is no really good answer. In general, if you cannot trust 482 the site which you have authorized for calling not to bug you then 483 your security situation is not really ideal. It is RECOMMENDED that 484 browsers have explicit (and obvious) indicators that they are in a 485 call in order to mitigate this risk. 487 4.1.3. Security Properties of the Calling Page 489 Origin-based security is intended to secure against web attackers. 490 However, we must also consider the case of network attackers. 491 Consider the case where I have granted permission to a calling 492 service by an origin that has the HTTP scheme, e.g., 493 http://calling-service.example.com. If I ever use my computer on an 494 unsecured network (e.g., a hotspot or if my own home wireless network 495 is insecure), and browse any HTTP site, then an attacker can bug my 496 computer. The attack proceeds like this: 498 1. I connect to http://anything.example.org/. Note that this site 499 is unaffiliated with the calling service. 500 2. The attacker modifies my HTTP connection to inject an IFRAME (or 501 a redirect) to http://calling-service.example.com 502 3. The attacker forges the response apparently 503 http://calling-service.example.com/ to inject JS to initiate a 504 call to himself. 506 Note that this attack does not depend on the media being insecure. 507 Because the call is to the attacker, it is also encrypted to him. 508 Moreover, it need not be executed immediately; the attacker can 509 "infect" the origin semi-permanently (e.g., with a web worker or a 510 popunder) and thus be able to bug me long after I have left the 511 infected network. This risk is created by allowing calls at all from 512 a page fetched over HTTP. 514 Even if calls are only possible from HTTPS sites, if the site embeds 515 active content (e.g., JavaScript) that is fetched over HTTP or from 516 an untrusted site, because that JavaScript is executed in the 517 security context of the page [finer-grained]. Thus, it is also 518 dangerous to allow RTC-Web functionality from HTTPS origins that 519 embed mixed content. Note: this issue is not restricted to PAGES 520 which contain mixed content. If a page from a given origin ever 521 loads mixed content then it is possible for a network attacker to 522 infect the browser's notion of that origin semi-permanently. 524 [[ OPEN ISSUE: What recommendation should IETF make about (a) 525 whether RTCWeb long-term consent should be available over HTTP pages 526 and (b) How to handle origins where the consent is to an HTTPS URL 527 but the page contains active mixed content? ]] 529 4.2. Communications Consent Verification 531 As discussed in Section 3.3, allowing web applications unrestricted 532 network access via the browser introduces the risk of using the 533 browser as an attack platform against machines which would not 534 otherwise be accessible to the malicious site, for instance because 535 they are topologically restricted (e.g., behind a firewall or NAT). 536 In order to prevent this form of attack as well as cross-protocol 537 attacks it is important to require that the target of traffic 538 explicitly consent to receiving the traffic in question. Until that 539 consent has been verified for a given endpoint, traffic other than 540 the consent handshake MUST NOT be sent to that endpoint. 542 4.2.1. ICE 544 Verifying receiver consent requires some sort of explicit handshake, 545 but conveniently we already need one in order to do NAT hole- 546 punching. ICE [RFC5245] includes a handshake designed to verify that 547 the receiving element wishes to receive traffic from the sender. It 548 is important to remember here that the site initiating ICE is 549 presumed malicious; in order for the handshake to be secure the 550 receiving element MUST demonstrate receipt/knowledge of some value 551 not available to the site (thus preventing the site from forging 552 responses). In order to achieve this objective with ICE, the STUN 553 transaction IDs must be generated by the browser and MUST NOT be made 554 available to the initiating script, even via a diagnostic interface. 555 Verifying receiver consent also requires verifying the receiver wants 556 to receive traffic from a particular sender, and at this time; for 557 example a malicious site may simply attempt ICE to known servers that 558 are using ICE for other sessions. ICE provides this verification as 559 well, by using the STUN credentials as a form of per-session shared 560 secret. Those credentials are known to the Web application, but 561 would need to also be known and used by the STUN-receiving element to 562 be useful. 564 There also needs to be some mechanism for the browser to verify that 565 the target of the traffic continues to wish to receive it. 566 Obviously, some ICE-based mechanism will work here, but it has been 567 observed that because ICE keepalives are indications, they will not 568 work here, so some other mechanism is needed. 570 4.2.2. Masking 572 Once consent is verified, there still is some concern about 573 misinterpretation attacks as described by Huang et al.[huang-w2sp]. 574 As long as communication is limited to UDP, then this risk is 575 probably limited, thus masking is not required for UDP. I.e., once 576 communications consent has been verified, it is most likely safe to 577 allow the implementation to send arbitrary UDP traffic to the chosen 578 destination, provided that the STUN keepalives continue to succeed. 579 In particular, this is true for the data channel if DTLS is used 580 because DTLS (with the anti-chosen plaintext mechanisms required by 581 TLS 1.1) does not allow the attacker to generate predictable 582 ciphertext. However, with TCP the risk of transparent proxies 583 becomes much more severe. If TCP is to be used, then WebSockets 584 style masking MUST be employed. 586 4.2.3. Backward Compatibility 588 A requirement to use ICE limits compatibility with legacy non-ICE 589 clients. It seems unsafe to completely remove the requirement for 590 some check. All proposed checks have the common feature that the 591 browser sends some message to the candidate traffic recipient and 592 refuses to send other traffic until that message has been replied to. 593 The message/reply pair must be generated in such a way that an 594 attacker who controls the Web application cannot forge them, 595 generally by having the message contain some secret value that must 596 be incorporated (e.g., echoed, hashed into, etc.). Non-ICE 597 candidates for this role (in cases where the legacy endpoint has a 598 public address) include: 600 o STUN checks without using ICE (i.e., the non-RTC-web endpoint sets 601 up a STUN responder.) 602 o Use or RTCP as an implicit reachability check. 604 In the RTCP approach, the RTC-Web endpoint is allowed to send a 605 limited number of RTP packets prior to receiving consent. This 606 allows a short window of attack. In addition, some legacy endpoints 607 do not support RTCP, so this is a much more expensive solution for 608 such endpoints, for which it would likely be easier to implement ICE. 609 For these two reasons, an RTCP-based approach does not seem to 610 address the security issue satisfactorily. 612 In the STUN approach, the RTC-Web endpoint is able to verify that the 613 recipient is running some kind of STUN endpoint but unless the STUN 614 responder is integrated with the ICE username/password establishment 615 system, the RTC-Web endpoint cannot verify that the recipient 616 consents to this particular call. This may be an issue if existing 617 STUN servers are operated at addresses that are not able to handle 618 bandwidth-based attacks. Thus, this approach does not seem 619 satisfactory either. 621 If the systems are tightly integrated (i.e., the STUN endpoint 622 responds with responses authenticated with ICE credentials) then this 623 issue does not exist. However, such a design is very close to an 624 ICE-Lite implementation (indeed, arguably is one). An intermediate 625 approach would be to have a STUN extension that indicated that one 626 was responding to RTC-Web checks but not computing integrity checks 627 based on the ICE credentials. This would allow the use of standalone 628 STUN servers without the risk of confusing them with legacy STUN 629 servers. If a non-ICE legacy solution is needed, then this is 630 probably the best choice. 632 Once initial consent is verified, we also need to verify continuing 633 consent, in order to avoid attacks where two people briefly share an 634 IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges 635 for a large, unstoppable, traffic flow to the network and then 636 leaves. The appropriate technologies here are fairly similar to 637 those for initial consent, though are perhaps weaker since the 638 threats is less severe. 640 [[ OPEN ISSUE: Exactly what should be the requirements here? 641 Proposals include ICE all the time or ICE but with allowing one of 642 these non-ICE things for legacy. ]] 644 4.2.4. IP Location Privacy 646 Note that as soon as the callee sends their ICE candidates, the 647 callee learns the callee's IP addresses. The callee's server 648 reflexive address reveals a lot of information about the callee's 649 location. In order to avoid tracking, implementations may wish to 650 suppress the start of ICE negotiation until the callee has answered. 651 In addition, either side may wish to hide their location entirely by 652 forcing all traffic through a TURN server. 654 4.3. Communications Security 656 Finally, we consider a problem familiar from the SIP world: 657 communications security. For obvious reasons, it MUST be possible 658 for the communicating parties to establish a channel which is secure 659 against both message recovery and message modification. (See 660 [RFC5479] for more details.) This service must be provided for both 661 data and voice/video. Ideally the same security mechanisms would be 662 used for both types of content. Technology for providing this 663 service (for instance, DTLS [RFC4347] and DTLS-SRTP [RFC5763]) is 664 well understood. However, we must examine this technology to the 665 RTC-Web context, where the threat model is somewhat different. 667 In general, it is important to understand that unlike a conventional 668 SIP proxy, the calling service (i.e., the Web server) controls not 669 only the channel between the communicating endpoints but also the 670 application running on the user's browser. While in principle it is 671 possible for the browser to cut the calling service out of the loop 672 and directly present trusted information (and perhaps get consent), 673 practice in modern browsers is to avoid this whenever possible. "In- 674 flow" modal dialogs which require the user to consent to specific 675 actions are particularly disfavored as human factors research 676 indicates that unless they are made extremely invasive, users simply 677 agree to them without actually consciously giving consent. 678 [abarth-rtcweb]. Thus, nearly all the UI will necessarily be 679 rendered by the browser but under control of the calling service. 680 This likely includes the peer's identity information, which, after 681 all, is only meaningful in the context of some calling service. 683 This limitation does not mean that preventing attack by the calling 684 service is completely hopeless. However, we need to distinguish 685 between two classes of attack: 687 Retrospective compromise of calling service. 688 The calling service is is non-malicious during a call but 689 subsequently is compromised and wishes to attack an older call. 691 During-call attack by calling service. 692 The calling service is compromised during the call it wishes to 693 attack. 695 Providing security against the former type of attack is practical 696 using the techniques discussed in Section 4.3.1. However, it is 697 extremely difficult to prevent a trusted but malicious calling 698 service from actively attacking a user's calls, either by mounting a 699 MITM attack or by diverting them entirely. (Note that this attack 700 applies equally to a network attacker if communications to the 701 calling service are not secured.) We discuss some potential 702 approaches and why they are likely to be impractical in 703 Section 4.3.2. 705 4.3.1. Protecting Against Retrospective Compromise 707 In a retrospective attack, the calling service was uncompromised 708 during the call, but that an attacker subsequently wants to recover 709 the content of the call. We assume that the attacker has access to 710 the protected media stream as well as having full control of the 711 calling service. 713 If the calling service has access to the traffic keying material (as 714 in SDES [RFC4568]), then retrospective attack is trivial. This form 715 of attack is particularly serious in the Web context because it is 716 standard practice in Web services to run extensive logging and 717 monitoring. Thus, it is highly likely that if the traffic key is 718 part of any HTTP request it will be logged somewhere and thus subject 719 to subsequent compromise. It is this consideration that makes an 720 automatic, public key-based key exchange mechanism imperative for 721 RTC-Web (this is a good idea for any communications security system) 722 and this mechanism SHOULD provide perfect forward secrecy (PFS). The 723 signaling channel/calling service can be used to authenticate this 724 mechanism. 726 In addition, the system MUST NOT provide any APIs to extract either 727 long-term keying material or to directly access any stored traffic 728 keys. Otherwise, an attacker who subsequently compromised the 729 calling service might be able to use those APIs to recover the 730 traffic keys and thus compromise the traffic. 732 4.3.2. Protecting Against During-Call Attack 734 Protecting against attacks during a call is a more difficult 735 proposition. Even if the calling service cannot directly access 736 keying material (as recommended in the previous section), it can 737 simply mount a man-in-the-middle attack on the connection, telling 738 Alice that she is calling Bob and Bob that he is calling Alice, while 739 in fact the calling service is acting as a calling bridge and 740 capturing all the traffic. While in theory it is possible to 741 construct techniques which protect against this form of attack, in 742 practice these techniques all require far too much user intervention 743 to be practical, given the user interface constraints described in 744 [abarth-rtcweb]. 746 4.3.2.1. Key Continuity 748 One natural approach is to use "key continuity". While a malicious 749 calling service can present any identity it chooses to the user, it 750 cannot produce a private key that maps to a given public key. Thus, 751 it is possible for the browser to note a given user's public key and 752 generate an alarm whenever that user's key changes. SSH [RFC4251] 753 uses a similar technique. (Note that the need to avoid explicit user 754 consent on every call precludes the browser requiring an immediate 755 manual check of the peer's key). 757 Unfortunately, this sort of key continuity mechanism is far less 758 useful in the RTC-Web context. First, much of the virtue of RTC-Web 759 (and any Web application) is that it is not bound to particular piece 760 of client software. Thus, it will be not only possible but routine 761 for a user to use multiple browsers on different computers which will 762 of course have different keying material (SACRED [RFC3760] 763 notwithstanding.) Thus, users will frequently be alerted to key 764 mismatches which are in fact completely legitimate, with the result 765 that they are trained to simply click through them. As it is known 766 that users routinely will click through far more dire warnings 767 [cranor-wolf], it seems extremely unlikely that any key continuity 768 mechanism will be effective rather than simply annoying. 770 Moreover, it is trivial to bypass even this kind of mechanism. 771 Recall that unlike the case of SSH, the browser never directly gets 772 the peer's identity from the user. Rather, it is provided by the 773 calling service. Even enabling a mechanism of this type would 774 require an API to allow the calling service to tell the browser "this 775 is a call to user X". All the calling service needs to do to avoid 776 triggering a key continuity warning is to tell the browser that "this 777 is a call to user Y" where Y is close to X. Even if the user actually 778 checks the other side's name (which all available evidence indicates 779 is unlikely), this would require (a) the browser to trusted UI to 780 provide the name and (b) the user to not be fooled by similar 781 appearing names. 783 4.3.2.2. Short Authentication Strings 785 ZRTP [RFC6189] uses a "short authentication string" (SAS) which is 786 derived from the key agreement protocol. This SAS is designed to be 787 read over the voice channel and if confirmed by both sides precludes 788 MITM attack. The intention is that the SAS is used once and then key 789 continuity (though a different mechanism from that discussed above) 790 is used thereafter. 792 Unfortunately, the SAS does not offer a practical solution to the 793 problem of a compromised calling service. "Voice conversion" 794 systems, which modify voice from one speaker to make it sound like 795 another, are an active area of research. These systems are already 796 good enough to fool both automatic recognition systems 797 [farus-conversion] and humans [kain-conversion] in many cases, and 798 are of course likely to improve in future, especially in an 799 environment where the user just wants to get on with the phone call. 800 Thus, even if SAS is effective today, it is likely not to be so for 801 much longer. Moreover, it is possible for an attacker who controls 802 the browser to allow the SAS to succeed and then simulate call 803 failure and reconnect, trusting that the user will not notice that 804 the "no SAS" indicator has been set (which seems likely). 806 Even were SAS secure if used, it seems exceedingly unlikely that 807 users will actually use it. As discussed above, the browser UI 808 constraints preclude requiring the SAS exchange prior to completing 809 the call and so it must be voluntary; at most the browser will 810 provide some UI indicator that the SAS has not yet been checked. 811 However, it it is well-known that when faced with optional mechanisms 812 such as fingerprints, users simply do not check them [whitten-johnny] 813 Thus, it is highly unlikely that users will ever perform the SAS 814 exchange. 816 Once uses have checked the SAS once, key continuity is required to 817 avoid them needing to check it on every call. However, this is 818 problematic for reasons indicated in Section 4.3.2.1. In principle 819 it is of course possible to render a different UI element to indicate 820 that calls are using an unauthenticated set of keying material 821 (recall that the attacker can just present a slightly different name 822 so that the attack shows the same UI as a call to a new device or to 823 someone you haven't called before) but as a practical matter, users 824 simply ignore such indicators even in the rather more dire case of 825 mixed content warnings. 827 4.3.2.3. Recommendations 829 [[ OPEN ISSUE: What are the best UI recommendations to make? 830 Proposal: take the text from [I-D.kaufman-rtcweb-security-ui] 831 Section 2]] 833 [[ OPEN ISSUE: Exactly what combination of media security primitives 834 should be specified and/or mandatory to implement? In particular, 835 should we allow DTLS-SRTP only, or both DTLS-SRTP and SDES. Should 836 we allow RTP for backward compatibility? ]] 838 5. Security Considerations 840 This entire document is about security. 842 6. Acknowledgements 844 Bernard Aboba, Harald Alvestrand, Cullen Jennings, Hadriel Kaplan (S 845 4.2.1), Matthew Kaufman, Magnus Westerland. 847 7. References 849 7.1. Normative References 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 7.2. Informative References 856 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing". 858 [I-D.abarth-origin] 859 Barth, A., "The Web Origin Concept", 860 draft-abarth-origin-09 (work in progress), November 2010. 862 [I-D.ietf-hybi-thewebsocketprotocol] 863 Fette, I. and A. Melnikov, "The WebSocket protocol", 864 draft-ietf-hybi-thewebsocketprotocol-17 (work in 865 progress), September 2011. 867 [I-D.kaufman-rtcweb-security-ui] 868 Kaufman, M., "Client Security User Interface Requirements 869 for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in 870 progress), June 2011. 872 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 874 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 875 A., Peterson, J., Sparks, R., Handley, M., and E. 876 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 877 June 2002. 879 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 880 Text on Security Considerations", BCP 72, RFC 3552, 881 July 2003. 883 [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely 884 Available Credentials (SACRED) - Credential Server 885 Framework", RFC 3760, April 2004. 887 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 888 Protocol Architecture", RFC 4251, January 2006. 890 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 891 Security", RFC 4347, April 2006. 893 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 894 Description Protocol (SDP) Security Descriptions for Media 895 Streams", RFC 4568, July 2006. 897 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 898 (ICE): A Protocol for Network Address Translator (NAT) 899 Traversal for Offer/Answer Protocols", RFC 5245, 900 April 2010. 902 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 903 "Requirements and Analysis of Media Security Management 904 Protocols", RFC 5479, April 2009. 906 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 907 for Establishing a Secure Real-time Transport Protocol 908 (SRTP) Security Context Using Datagram Transport Layer 909 Security (DTLS)", RFC 5763, May 2010. 911 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 912 Path Key Agreement for Unicast Secure RTP", RFC 6189, 913 April 2011. 915 [abarth-rtcweb] 916 Barth, A., "Prompting the user is security failure", RTC- 917 Web Workshop. 919 [cranor-wolf] 920 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 921 L. cranor, "Crying Wolf: An Empirical Study of SSL Warning 922 Effectiveness", Proceedings of the 18th USENIX Security 923 Symposium, 2009. 925 [farus-conversion] 926 Farrus, M., Erro, D., and J. Hernando, "Speaker 927 Recognition Robustness to Voice Conversion". 929 [finer-grained] 930 Barth, A. and C. Jackson, "Beware of Finer-Grained 931 Origins", W2SP, 2008. 933 [huang-w2sp] 934 Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. 935 Jackson, "Talking to Yourself for Fun and Profit", W2SP, 936 2011. 938 [kain-conversion] 939 Kain, A. and M. Macon, "Design and Evaluation of a Voice 940 Conversion Algorithm based on Spectral Envelope Mapping 941 and Residual Prediction", Proceedings of ICASSP, May 942 2001. 944 [whitten-johnny] 945 Whitten, A. and J. Tygar, "Why Johnny Can't Encrypt: A 946 Usability Evaluation of PGP 5.0", Proceedings of the 8th 947 USENIX Security Symposium, 1999. 949 Appendix A. A Proposed Security Architecture [No Consensus on This] 951 This section contains a proposed security architecture, based on the 952 considerations discussed in the main body of this memo. This section 953 is currently the opinion of the author and does not have consensus 954 though some (many?) elements of this proposal do seem to have general 955 consensus. 957 A.1. Trust Hierarchy 959 The basic assumption of this proposal is that network resources exist 960 in a hierarchy of trust, rooted in the browser, which serves as the 961 user's TRUSTED COMPUTING BASE (TCB). Any security property which the 962 user wishes to have enforced must be ultimately guaranteed by the 963 browser (or transitively by some property the browser verifies). 964 Conversely, if the browser is compromised, then no security 965 guarantees are possible. Note that there are cases (e.g., Internet 966 kiosks) where the user can't really trust the browser that much. In 967 these cases, the level of security provided is limited by how much 968 they trust the browser. 970 Optimally, we would not rely on trust in any entities other than the 971 browser. However, this is unfortunately not possible if we wish to 972 have a functional system. Other network elements fall into two 973 categories: those which can be authenticated by the browser and thus 974 are partly trusted--though to the minimum extent necessary--and those 975 which cannot be authenticated and thus are untrusted. This is a 976 natural extension of the end-to-end principle. 978 A.1.1. Authenticated Entities 980 There are two major classes of authenticated entities in the system: 982 o Calling services: Web sites whose origin we can verify (optimally 983 via HTTPS). 984 o Other users: RTC-Web peers whose origin we can verify 985 cryptographically (optimally via DTLS-SRTP). 987 Note that merely being authenticated does not make these entities 988 trusted. For instance, just because we can verify that 989 https://www.evil.org/ is owned by Dr. Evil does not mean that we can 990 trust Dr. Evil to access our camera an microphone. However, it gives 991 the user an opportunity to determine whether he wishes to trust Dr. 992 Evil or not; after all, if he desires to contact Dr. Evil, it's safe 993 to temporarily give him access to the camera and microphone for the 994 purpose of the call. The point here is that we must first identify 995 other elements before we can determine whether to trust them. 997 It's also worth noting that there are settings where authentication 998 is non-cryptographic, such as other machines behind a firewall. 999 Naturally, the level of trust one can have in identities verified in 1000 this way depends on how strong the topology enforcement is. 1002 A.1.2. Unauthenticated Entities 1004 Other than the above entities, we are not generally able to identify 1005 other network elements, thus we cannot trust them. This does not 1006 mean that it is not possible to have any interaction with them, but 1007 it means that we must assume that they will behave maliciously and 1008 design a system which is secure even if they do so. 1010 A.2. Overview 1012 This section describes a typical RTCWeb session and shows how the 1013 various security elements interact and what guarantees are provided 1014 to the user. The example in this section is a "best case" scenario 1015 in which we provide the maximal amount of user authentication and 1016 media privacy with the minimal level of trust in the calling service. 1017 Simpler versions with lower levels of security are also possible and 1018 are noted in the text where applicable. It's also important to 1019 recognize the tension between security (or performance) and privacy. 1020 The example shown here is aimed towards settings where we are more 1021 concerned about secure calling than about privacy, but as we shall 1022 see, there are settings where one might wish to make different 1023 tradeoffs--this architecture is still compatible with those settings. 1025 For the purposes of this example, we assume the topology shown in the 1026 figure below. This topology is derived from the topology shown in 1027 Figure 1, but separates Alice and Bob's identities from the process 1028 of signaling. Specifically, Alice and Bob have relationships with 1029 some Identity Provider (IDP) that supports a protocol such OpenID or 1030 BrowserID) that can be used to attest to their identity. This 1031 separation isn't particularly important in "closed world" cases where 1032 Alice and Bob are users on the same social network and have 1033 identities based on that network. However, there are important 1034 settings where that is not the case, such as federation (calls from 1035 one network to another) and calling on untrusted sites, such as where 1036 two users who have a relationship via a given social network want to 1037 call each other on another, untrusted, site, such as a poker site. 1039 +----------------+ 1040 | | 1041 | Signaling | 1042 | Server | 1043 | | 1044 +----------------+ 1045 ^ ^ 1046 / \ 1047 HTTPS / \ HTTPS 1048 / \ 1049 / \ 1050 v v 1051 JS API JS API 1052 +-----------+ +-----------+ 1053 | | Media | | 1054 Alice | Browser |<---------->| Browser | Bob 1055 | | (DTLS-SRTP)| | 1056 +-----------+ +-----------+ 1057 ^ ^--+ +--^ ^ 1058 | | | | 1059 v | | v 1060 +-----------+ | | +-----------+ 1061 | |<--------+ | | 1062 | IDP | | | IDP | 1063 | | +------->| | 1064 +-----------+ +-----------+ 1066 Figure 2: A call with IDP-based identity 1068 A.2.1. Initial Signaling 1070 Alice and Bob are both users of a common calling service; they both 1071 have approved the calling service to make calls (we defer the 1072 discussion of device access permissions till later). They are both 1073 connected to the calling service via HTTPS and so know the origin 1074 with some level of confidence. They also have accounts with some 1075 identity provider. This sort of identity service is becoming 1076 increasingly common in the Web environment in technologies such 1077 (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, 1078 WebFinger), and is often provided as a side effect service of your 1079 ordinary accounts with some service. In this example, we show Alice 1080 and Bob using a separate identity service, though they may actually 1081 be using the same identity service as calling service or have no 1082 identity service at all. 1084 Alice is logged onto the calling service and decides to call Bob. She 1085 can see from the calling service that he is online and the calling 1086 service presents a JS UI in the form of a button next to Bob's name 1087 which says "Call". Alice clicks the button, which initiates a JS 1088 callback that instantiates a PeerConnection object. This does not 1089 require a security check: JS from any origin is allowed to get this 1090 far. 1092 Once the PeerConnection is created, the calling service JS needs to 1093 set up some media. Because this is an audio/video call, it creates 1094 two MediaStreams, one connected to an audio input and one connected 1095 to a video input. At this point the first security check is 1096 required: untrusted origins are not allowed to access the camera and 1097 microphone. In this case, because Alice is a long-term user of the 1098 calling service, she has made a permissions grant (i.e., a setting in 1099 the browser) to allow the calling service to access her camera and 1100 microphone any time it wants. The browser checks this setting when 1101 the camera and microphone requests are made and thus allows them. 1103 In the current W3C API, once some streams have been added, Alice's 1104 browser + JS generates a signaling message The format of this data is 1105 currently undefined. It may be a complete message as defined by ROAP 1106 [REF] or may be assembled piecemeal by the JS. In either case, it 1107 will contain: 1109 o Media channel information 1110 o ICE candidates 1111 o A fingerprint attribute binding the message to Alice's public key 1112 [RFC5763] 1114 Prior to sending out the signaling message, the PeerConnection code 1115 contacts the identity service and obtains an assertion binding 1116 Alice's identity to her fingerprint. The exact details depend on the 1117 identity service (though as discussed in Appendix A.3.6.4 I believe 1118 PeerConnection can be agnostic to them), but for now it's easiest to 1119 think of as a BrowserID assertion. 1121 This message is sent to the signaling server, e.g., by XMLHttpRequest 1122 [REF] or by WebSockets [I-D.ietf-hybi-thewebsocketprotocol]. The 1123 signaling server processes the message from Alice's browser, 1124 determines that this is a call to Bob and sends a signaling message 1125 to Bob's browser (again, the format is currently undefined). The JS 1126 on Bob's browser processes it, and alerts Bob to the incoming call 1127 and to Alice's identity. In this case, Alice has provided an 1128 identity assertion and so Bob's browser contacts Alice's identity 1129 provider (again, this is done in a generic way so the browser has no 1130 specific knowledge of the IDP) to verity the assertion. This allows 1131 the browser to display a trusted element indicating that a call is 1132 coming in from Alice. If Alice is in Bob's address book, then this 1133 interface might also include her real name, a picture, etc. The 1134 calling site will also provide some user interface element (e.g., a 1135 button) to allow Bob to answer the call, though this is most likely 1136 not part of the trusted UI. 1138 If Bob agrees [I am ignoring early media for now], a PeerConnection 1139 is instantiated with the message from Alice's side. Then, a similar 1140 process occurs as on Alice's browser: Bob's browser verifies that 1141 the calling service is approved, the media streams are created, and a 1142 return signaling message containing media information, ICE 1143 candidates, and a fingerprint is sent back to Alice via the signaling 1144 service. If Bob has a relationship with an IDP, the message will 1145 also come with an identity assertion. 1147 At this point, Alice and Bob each know that the other party wants to 1148 have a secure call with them. Based purely on the interface provided 1149 by the signaling server, they know that the signaling server claims 1150 that the call is from Alice to Bob. Because the far end sent an 1151 identity assertion along with their message, they know that this is 1152 verifiable from the IDP as well. Of course, the call works perfectly 1153 well if either Alice or Bob doesn't have a relationship with an IDP; 1154 they just get a lower level of assurance. Moreover, Alice might wish 1155 to make an anonymous call through an anonymous calling site, in which 1156 case she would of course just not provide any identity assertion and 1157 the calling site would mask her identity from Bob. 1159 A.2.2. Media Consent Verification 1161 As described in Section 4.2. This proposal specifies that that be 1162 performed via ICE. Thus, Alice and Bob perform ICE checks with each 1163 other. At the completion of these checks, they are ready to send 1164 non-ICE data. 1166 At this point, Alice knows that (a) Bob (assuming he is verified via 1167 his IDP) or someone else who the signaling service is claiming is Bob 1168 is willing to exchange traffic with her and (b) that either Bob is at 1169 the IP address which she has verified via ICE or there is an attacker 1170 who is on-path to that IP address detouring the traffic. Note that 1171 it is not possible for an attacker who is on-path but not attached to 1172 the signaling service to spoof these checks because they do not have 1173 the ICE credentials. Bob's security guarantees with respect to Alice 1174 are the converse of this. 1176 A.2.3. DTLS Handshake 1178 Once the ICE checks have completed [more specifically, once some ICE 1179 checks have completed], Alice and Bob can set up a secure channel. 1180 This is performed via DTLS [RFC4347] (for the data channel) and DTLS- 1181 SRTP [RFC5763] for the media channel. Specifically, Alice and Bob 1182 perform a DTLS handshake on every channel which has been established 1183 by ICE. The total number of channels depends on the amount of 1184 muxing; in the most likely case we are using both RTP/RTCP mux and 1185 muxing multiple media streams on the same channel, in which case 1186 there is only one DTLS handshake. Once the DTLS handshake has 1187 completed, the keys are extracted and used to key SRTP for the media 1188 channels. 1190 At this point, Alice and Bob know that they share a set of secure 1191 data and/or media channels with keys which are not known to any 1192 third-party attacker. If Alice and Bob authenticated via their IDPs, 1193 then they also know that the signaling service is not attacking them. 1194 Even if they do not use an IDP, as long as they have minimal trust in 1195 the signaling service not to perform a man-in-the-middle attack, they 1196 know that their communications are secure against the signaling 1197 service as well. 1199 A.2.4. Communications and Consent Freshness 1201 From a security perspective, everything from here on in is a little 1202 anticlimactic: Alice and Bob exchange data protected by the keys 1203 negotiated by DTLS. Because of the security guarantees discussed in 1204 the previous sections, they know that the communications are 1205 encrypted and authenticated. 1207 The one remaining security property we need to establish is "consent 1208 freshness", i.e., allowing Alice to verify that Bob is still prepared 1209 to receive her communications. ICE specifies periodic STUN 1210 keepalizes but only if media is not flowing. Because the consent 1211 issue is more difficult here, we require RTCWeb implementations to 1212 periodically send keepalives. If a keepalive fails and no new ICE 1213 channels can be established, then the session is terminated. 1215 A.3. Detailed Technical Description 1217 A.3.1. Origin and Web Security Issues 1219 The basic unit of permissions for RTC-Web is the origin 1220 [I-D.abarth-origin]. Because the security of the origin depends on 1221 being able to authenticate content from that origin, the origin can 1222 only be securely established if data is transferred over HTTPS. 1223 Thus, clients MUST treat HTTP and HTTPS origins as different 1224 permissions domains and SHOULD NOT permit access to any RTC-Web 1225 functionality from scripts fetched over non-secure (HTTP) origins. 1226 If an HTTPS origin contains mixed active content (regardless of 1227 whether it is present on the specific page attempting to access RTC- 1228 Web functionality), any access MUST be treated as if it came from the 1229 HTTP origin. For instance, if a https://www.example.com/example.html 1230 loads https://www.example.com/example.js and 1231 http://www.example.org/jquery.js, any attempt by example.js to access 1232 RTCWeb functionality MUST be treated as if it came from 1233 http://www.example.com/. Note that many browsers already track mixed 1234 content and either forbid it by default or display a warning. 1236 A.3.2. Device Permissions Model 1238 Implementations MUST obtain explicit user consent prior to providing 1239 access to the camera and/or microphone. Implementations MUST at 1240 minimum support the following two permissions models: 1242 o Requests for one-time camera/microphone access. 1243 o Requests for permanent access. 1245 In addition, they SHOULD support requests for access to a single 1246 communicating peer. E.g., "Call customerservice@ford.com". Browsers 1247 servicing such requests SHOULD clearly indicate that identity to the 1248 user when asking for permission. 1250 API Requirement: The API MUST provide a mechanism for the requesting 1251 JS to indicate which of these forms of permissions it is 1252 requesting. This allows the client to know what sort of user 1253 interface experience to provide. In particular, browsers might 1254 display a non-invasive door hanger ("some features of this site 1255 may not work..." when asking for long-term permissions) but a more 1256 invasive UI ("here is your own video") for single-call 1257 permissions. The API MAY grant weaker permissions than the JS 1258 asked for if the user chooses to authorize only those permissions, 1259 but if it intends to grant stronger ones SHOULD display the 1260 appropriate UI for those permissions. 1262 API Requirement: The API MUST provide a mechanism for the requesting 1263 JS to relinquish the ability to see or modify the media (e.g., via 1264 MediaStream.record()). Combined with secure authentication of the 1265 communicating peer, this allows a user to be sure that the calling 1266 site is not accessing or modifying their conversion. 1268 UI Requirement: The UI MUST clearly indicate when the user's camera 1269 and microphone are in use. This indication MUST NOT be 1270 suppressable by the JS and MUST clearly indicate how to terminate 1271 a call, and provide a UI means to immediately stop camera/ 1272 microphone input without the JS being able to prevent it. 1274 UI Requirement: If the UI indication of camera/microphone use are 1275 displayed in the browser such that minimizing the browser window 1276 would hide the indication, or the JS creating an overlapping 1277 window would hide the indication, then the browser SHOULD stop 1278 camera and microphone input. 1280 Clients MAY permit the formation of data channels without any direct 1281 user approval. Because sites can always tunnel data through the 1282 server, further restrictions on the data channel do not provide any 1283 additional security. (though see Appendix A.3.3 for a related issue). 1285 Implementations which support some form of direct user authentication 1286 SHOULD also provide a policy by which a user can authorize calls only 1287 to specific counterparties. Specifically, the implementation SHOULD 1288 provide the following interfaces/controls: 1290 o Allow future calls to this verified user. 1291 o Allow future calls to any verified user who is in my system 1292 address book (this only works with address book integration, of 1293 course). 1295 Implementations SHOULD also provide a different user interface 1296 indication when calls are in progress to users whose identities are 1297 directly verifiable. Appendix A.3.5 provides more on this. 1299 A.3.3. Communications Consent 1301 Browser client implementations of RTC-Web MUST implement ICE. Server 1302 gateway implementations which operate only at public IP addresses may 1303 implement ICE-Lite. 1305 Browser implementations MUST verify reachability via ICE prior to 1306 sending any non-ICE packets to a given destination. Implementations 1307 MUST NOT provide the ICE transaction ID to JavaScript. [Note: this 1308 document takes no position on the split between ICE in JS and ICE in 1309 the browser. The above text is written the way it is for editorial 1310 convenience and will be modified appropriately if the WG decides on 1311 ICE in the JS.] 1313 Implementations MUST send keepalives no less frequently than every 30 1314 seconds regardless of whether traffic is flowing or not. If a 1315 keepalive fails then the implementation MUST either attempt to find a 1316 new valid path via ICE or terminate media for that ICE component. 1317 Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding 1318 Indications which are one-way and therefore not sufficient. We will 1319 need to define a new mechanism for this. [OPEN ISSUE: what to do 1320 here.] 1322 A.3.4. IP Location Privacy 1324 As mentioned in Section 4.2.4 above, a side effect of the default ICE 1325 behavior is that the peer learns one's IP address, which leaks large 1326 amounts of location information, especially for mobile devices. This 1327 has negative privacy consequences in some circumstances. The 1328 following two API requirements are intended to mitigate this issue: 1330 API Requirement: The API MUST provide a mechanism to suppress ICE 1331 negotiation (though perhaps to allow candidate gathering) until 1332 the user has decided to answer the call [note: determining when 1333 the call has been answered is a question for the JS.] This 1334 enables a user to prevent a peer from learning their IP address if 1335 they elect not to answer a call. 1337 API Requirement: The API MUST provide a mechanism for the calling 1338 application to indicate that only TURN candidates are to be used. 1339 This prevents the peer from learning one's IP address at all. 1341 A.3.5. Communications Security 1343 Implementations MUST implement DTLS and DTLS-SRTP. All data channels 1344 MUST be secured via DTLS. DTLS-SRTP MUST be offered for every media 1345 channel and MUST be the default; i.e., if an implementation receives 1346 an offer for DTLS-SRTP and SDES and/or plain RTP, DTLS-SRTP MUST be 1347 selected. 1349 [OPEN ISSUE: What should the settings be here? MUST?] 1350 Implementations MAY support SDES and RTP for media traffic for 1351 backward compatibility purposes. 1353 API Requirement: The API MUST provide a mechanism to indicate that a 1354 fresh DTLS key pair is to be generated for a specific call. This 1355 is intended to allow for unlinkability. Note that there are also 1356 settings where it is attractive to use the same keying material 1357 repeatedly, especially those with key continuity-based 1358 authentication. 1360 API Requirement: The API MUST provide a mechanism to indicate that a 1361 fresh DTLS key pair is to be generated for a specific call. This 1362 is intended to allow for unlinkability. 1364 API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the 1365 JS to obtain the negotiated keying material. This requirement 1366 preserves the end-to-end security of the media. 1368 UI Requirements: A user-oriented client MUST provide an 1369 "inspector" interface which allows the user to determine the 1370 security characteristics of the media. [largely derived from 1371 [I-D.kaufman-rtcweb-security-ui] 1372 The following properties SHOULD be displayed "up-front" in the 1373 browser chrome, i.e., without requiring the user to ask for them: 1375 * A client MUST provide a user interface through which a user may 1376 determine the security characteristics for currently-displayed 1377 audio and video stream(s) 1378 * A client MUST provide a user interface through which a user may 1379 determine the security characteristics for transmissions of 1380 their microphone audio and camera video. 1381 * The "security characteristics" MUST include an indication as to 1382 whether or not the transmission is cryptographically protected 1383 and whether that protection is based on a key that was 1384 delivered out-of-band (from a server) or was generated as a 1385 result of a pairwise negotiation. 1386 * If the far endpoint was directly verified Appendix A.3.6 the 1387 "security characteristics" MUST include the verified 1388 information. 1389 The following properties are more likely to require some "drill- 1390 down" from the user: 1392 * If the transmission is cryptographically protected, the The 1393 algorithms in use (For example: "AES-CBC" or "Null Cipher".) 1394 * If the transmission is cryptographically protected, the 1395 "security characteristics" MUST indicate whether PFS is 1396 provided. 1397 * If the transmission is cryptographically protected via an end- 1398 to-end mechanism the "security characteristics" MUST include 1399 some mechanism to allow an out-of-band verification of the 1400 peer, such as a certificate fingerprint or an SAS. 1402 A.3.6. Web-Based Peer Authentication 1404 A.3.6.1. Generic Concepts 1406 In a number of cases, it is desirable for the endpoint (i.e., the 1407 browser) to be able to directly identity the endpoint on the other 1408 side without trusting only the signaling service to which they are 1409 connected. For instance, users may be making a call via a federated 1410 system where they wish to get direct authentication of the other 1411 side. Alternately, they may be making a call on a site which they 1412 minimally trust (such as a poker site) but to someone who has an 1413 identity on a site they do trust (such as a social network.) 1415 Recently, a number of Web-based identity technologies (OAuth, 1416 BrowserID, Facebook Connect), etc. have been developed. While the 1417 details vary, what these technologies share is that they have a Web- 1418 based (i.e., HTTP/HTTPS identity provider) which attests to your 1419 identity. For instance, if I have an account at example.org, I could 1420 use the example.org identity provider to prove to others that I was 1421 alice@example.org. The development of these technologies allows us 1422 to separate calling from identity provision: I could call you on 1423 Poker Galaxy but identify myself as alice@example.org. 1425 Whatever the underlying technology, the general principle is that the 1426 party which is being authenticated is NOT the signaling site but 1427 rather the user (and their browser). Similarly, the relying party is 1428 the browser and not the signaling site. This means that the 1429 PeerConnection API MUST arrange to talk directly to the identity 1430 provider in a way that cannot be impersonated by the calling site. 1431 The following sections provide two examples of this. 1433 A.3.6.2. BrowserID 1435 BrowserID [https://browserid.org/] is a technology which allows a 1436 user with a verified email address to generate an assertion 1437 (authenticated by their identity provider) attesting to their 1438 identity (phrased as an email address). The way that this is used in 1439 practice is that the relying party embeds JS in their site which 1440 talks to the BrowserID code (either hosted on a trusted intermediary 1441 or embedded in the browser). That code generates the assertion which 1442 is passed back to the relying party for verification. The assertion 1443 can be verified directly or with a Web service provided by the 1444 identity provider. It's relatively easy to extend this functionality 1445 to authenticate RTC-Web calls, as shown below. 1447 +----------------------+ +----------------------+ 1448 | | | | 1449 | Alice's Browser | | Bob's Browser | 1450 | | OFFER ------------> | | 1451 | Calling JS Code | | Calling JS Code | 1452 | ^ | | ^ | 1453 | | | | | | 1454 | v | | v | 1455 | PeerConnection | | PeerConnection | 1456 | | ^ | | | ^ | 1457 | Finger| |Signed | |Signed | | | 1458 | print | |Finger | |Finger | |"Alice"| 1459 | | |print | |print | | | 1460 | v | | | v | | 1461 | +--------------+ | | +---------------+ | 1462 | | BrowserID | | | | BrowserID | | 1463 | | Signer | | | | Verifier | | 1464 | +--------------+ | | +---------------+ | 1465 | ^ | | ^ | 1466 +-----------|----------+ +----------|-----------+ 1467 | | 1468 | Get certificate | 1469 v | Check 1470 +----------------------+ | certificate 1471 | | | 1472 | Identity |/-------------------------------+ 1473 | Provider | 1474 | | 1475 +----------------------+ 1477 The way this mechanism works is as follows. On Alice's side, Alice 1478 goes to initiate a call. 1480 1. The calling JS instantiates a PeerConnection and tells it that it 1481 is interested in having it authenticated via BrowserID. 1482 2. The PeerConnection instantiates the BrowserID signer in an 1483 invisible IFRAME. The IFRAME is tagged with an origin that 1484 indicates that it was generated by the PeerConnection (this 1485 prevents ordinary JS from implementing it). The BrowserID signer 1486 is provided with Alice's fingerprint. Note that the IFRAME here 1487 does not render any UI. It is being used solely to allow the 1488 browser to load the BrowserID signer in isolation, especially 1489 from the calling site. 1490 3. The BrowserID signer contacts Alice's identity provider, 1491 authenticating as Alice (likely via a cookie). 1492 4. The identity provider returns a short-term certificate attesting 1493 to Alice's identity and her short-term public key. 1495 5. The Browser-ID code signs the fingerprint and returns the signed 1496 assertion + certificate to the PeerConnection. [Note: there are 1497 well-understood Web mechanisms for this that I am excluding here 1498 for simplicity.] 1499 6. The PeerConnection returns the signed information to the calling 1500 JS code. 1501 7. The signed assertion gets sent over the wire to Bob's browser 1502 (via the signaling service) as part of the call setup. 1504 Obviously, the format of the signed assertion varies depending on 1505 what signaling style the WG ultimately adopts. However, for 1506 concreteness, if something like ROAP were adopted, then the entire 1507 message might look like: 1509 { 1510 "messageType":"OFFER", 1511 "callerSessionId":"13456789ABCDEF", 1512 "seq": 1 1513 "sdp":" 1514 v=0\n 1515 o=- 2890844526 2890842807 IN IP4 192.0.2.1\n 1516 s= \n 1517 c=IN IP4 192.0.2.1\n 1518 t=2873397496 2873404696\n 1519 m=audio 49170 RTP/AVP 0\n 1520 a=fingerprint: SHA-1 \ 1521 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n", 1522 "identity":{ 1523 "identityType":"browserid", 1524 "assertion": { 1525 "digest":"", 1526 "audience": "[TBD]" 1527 "valid-until": 1308859352261, 1528 }, // signed using user's key 1529 "certificate": { 1530 "email": "rescorla@gmail.com", 1531 "public-key": "", 1532 "valid-until": 1308860561861, 1533 } // certificate is signed by gmail.com 1534 } 1535 } 1537 Note that we only expect to sign the fingerprint values and the 1538 session IDs, in order to allow the JS or calling service to modify 1539 the rest of the SDP, while protecting the identity binding. [OPEN 1540 ISSUE: should we sign seq too?] 1542 [TODO: NEed to talk about Audience a bit.] 1543 On Bob's side, he receives the signed assertion as part of the call 1544 setup message and a similar procedure happens to verify it. 1546 1. The calling JS instantiates a PeerConnection and provides it the 1547 relevant signaling information, including the signed assertion. 1548 2. The PeerConnection instantiates a BrowserID verifier in an IFRAME 1549 and provides it the signed assertion. 1550 3. The BrowserID verifier contacts the identity provider to verify 1551 the certificate and then uses the key to verify the signed 1552 fingerprint. 1553 4. Alice's verified identity is returned to the PeerConnection (it 1554 already has the fingerprint). 1555 5. At this point, Bob's browser can display a trusted UI indication 1556 that Alice is on the other end of the call. 1558 When Bob returns his answer, he follows the converse procedure, which 1559 provides Alice with a signed assertion of Bob's identity and keying 1560 material. 1562 A.3.6.3. OAuth 1564 While OAuth is not directly designed for user-to-user authentication, 1565 with a little lateral thinking it can be made to serve. We use the 1566 following mapping of OAuth concepts to RTC-Web concepts: 1568 +----------------------+----------------------+ 1569 | OAuth | RTCWeb | 1570 +----------------------+----------------------+ 1571 | Client | Relying party | 1572 | Resource owner | Authenticating party | 1573 | Authorization server | Identity service | 1574 | Resource server | Identity service | 1575 +----------------------+----------------------+ 1577 Table 1 1579 The idea here is that when Alice wants to authenticate to Bob (i.e., 1580 for Bob to be aware that she is calling). In order to do this, she 1581 allows Bob to see a resource on the identity provider that is bound 1582 to the call, her identity, and her public key. Then Bob retrieves 1583 the resource from the identity provider, thus verifying the binding 1584 between Alice and the call. 1586 Alice IDP Bob 1587 --------------------------------------------------------- 1588 Call-Id, Fingerprint -------> 1589 <------------------- Auth Code 1590 Auth Code ----------------------------------------------> 1591 <----- Get Token + Auth Code 1592 Token ---------------------> 1593 <------------- Get call-info 1594 Call-Id, Fingerprint ------> 1596 This is a modified version of a common OAuth flow, but omits the 1597 redirects required to have the client point the resource owner to the 1598 IDP, which is acting as both the resource server and the 1599 authorization server, since Alice already has a handle to the IDP. 1601 Above, we have referred to "Alice", but really what we mean is the 1602 PeerConnection. Specifically, the PeerConnection will instantiate an 1603 IFRAME with JS from the IDP and will use that IFRAME to communicate 1604 with the IDP, authenticating with Alice's identity (e.g., cookie). 1605 Similarly, Bob's PeerConnection instantiates an IFRAME to talk to the 1606 IDP. 1608 A.3.6.4. Generic Identity Support 1610 I believe it's possible to build a generic interface between the 1611 PeerConnection and any identity sub-module so that the PeerConnection 1612 just gets pointed to the IDP (which the relying party either trusts 1613 or not) and JS from the IDP provides the concrete interfaces. 1614 However, I need to work out the details, so I'm not specifying this 1615 yet. If it works, the previous two sections will just be examples. 1617 Author's Address 1619 Eric Rescorla 1620 RTFM, Inc. 1621 2064 Edgewood Drive 1622 Palo Alto, CA 94303 1623 USA 1625 Phone: +1 650 678 2350 1626 Email: ekr@rtfm.com