idnits 2.17.1 draft-ietf-rtcweb-security-arch-04.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 abstract seems to contain references ([I-D.ietf-rtcweb-security]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 22, 2012) is 4203 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) == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-03 == Outdated reference: A later version (-04) exists of draft-muthu-behave-consent-freshness-01 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-01 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 RTCWEB Security Architecture 8 draft-ietf-rtcweb-security-arch-04 10 Abstract 12 The Real-Time Communications on the Web (RTCWEB) working group is 13 tasked with standardizing protocols for enabling real-time 14 communications within user-agents using web technologies (e.g 15 JavaScript). The major use cases for RTCWEB technology are real-time 16 audio and/or video calls, Web conferencing, and direct data transfer. 17 Unlike most conventional real-time systems (e.g., SIP-based soft 18 phones) RTCWEB communications are directly controlled by some Web 19 server, which poses new security challenges. For instance, a Web 20 browser might expose a JavaScript API which allows a server to place 21 a video call. Unrestricted access to such an API would allow any 22 site which a user visited to "bug" a user's computer, capturing any 23 activity which passed in front of their camera. [I-D.ietf-rtcweb- 24 security] defines the RTCWEB threat model. This document defines an 25 architecture which provides security within that threat model. 27 Legal 29 THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON 30 AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 31 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 32 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL 33 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 34 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 35 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 36 FOR A PARTICULAR PURPOSE. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 25, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6 88 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6 89 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 91 4.2. Media Consent Verification . . . . . . . . . . . . . . . . 10 92 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 11 93 4.4. Communications and Consent Freshness . . . . . . . . . . . 11 94 5. Detailed Technical Description . . . . . . . . . . . . . . . . 11 95 5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 11 96 5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 12 97 5.3. Communications Consent . . . . . . . . . . . . . . . . . . 14 98 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 14 99 5.5. Communications Security . . . . . . . . . . . . . . . . . 15 100 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 16 101 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 17 102 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 19 103 5.6.3. Binding Identity Assertions to JSEP Offer/Answer 104 Transactions . . . . . . . . . . . . . . . . . . . . . 20 105 5.6.3.1. Input to Assertion Generation Process . . . . . . 20 106 5.6.3.2. Carrying Identity Assertions . . . . . . . . . . . 21 107 5.6.4. IdP Interaction Details . . . . . . . . . . . . . . . 21 108 5.6.4.1. General Message Structure . . . . . . . . . . . . 21 109 5.6.4.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 22 110 5.7. Security Considerations . . . . . . . . . . . . . . . . . 27 111 5.7.1. Communications Security . . . . . . . . . . . . . . . 27 112 5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 113 5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 28 114 5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 29 115 5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 29 116 5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 30 117 5.7.4.3. Privacy of IdP-generated identities and the 118 hosting site . . . . . . . . . . . . . . . . . . . 30 119 5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 30 120 5.7.4.5. Web Security Feature Interactions . . . . . . . . 30 121 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 122 7. Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 31 123 8. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 31 124 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 125 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 126 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 127 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 33 128 A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 33 129 A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 36 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 133 1. Introduction 135 The Real-Time Communications on the Web (RTCWEB) working group is 136 tasked with standardizing protocols for real-time communications 137 between Web browsers. The major use cases for RTCWEB technology are 138 real-time audio and/or video calls, Web conferencing, and direct data 139 transfer. Unlike most conventional real-time systems, (e.g., SIP- 140 based[RFC3261] soft phones) RTCWEB communications are directly 141 controlled by some Web server, as shown in Figure 1. 143 +----------------+ 144 | | 145 | Web Server | 146 | | 147 +----------------+ 148 ^ ^ 149 / \ 150 HTTP / \ HTTP 151 / \ 152 / \ 153 v v 154 JS API JS API 155 +-----------+ +-----------+ 156 | | Media | | 157 | Browser |<---------->| Browser | 158 | | | | 159 +-----------+ +-----------+ 161 Figure 1: A simple RTCWEB system 163 This system presents a number of new security challenges, which are 164 analyzed in [I-D.ietf-rtcweb-security]. This document describes a 165 security architecture for RTCWEB which addresses the threats and 166 requirements described in that document. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 3. Trust Model 176 The basic assumption of this architecture is that network resources 177 exist in a hierarchy of trust, rooted in the browser, which serves as 178 the user's TRUSTED COMPUTING BASE (TCB). Any security property which 179 the user wishes to have enforced must be ultimately guaranteed by the 180 browser (or transitively by some property the browser verifies). 181 Conversely, if the browser is compromised, then no security 182 guarantees are possible. Note that there are cases (e.g., Internet 183 kiosks) where the user can't really trust the browser that much. In 184 these cases, the level of security provided is limited by how much 185 they trust the browser. 187 Optimally, we would not rely on trust in any entities other than the 188 browser. However, this is unfortunately not possible if we wish to 189 have a functional system. Other network elements fall into two 190 categories: those which can be authenticated by the browser and thus 191 are partly trusted--though to the minimum extent necessary--and those 192 which cannot be authenticated and thus are untrusted. This is a 193 natural extension of the end-to-end principle. 195 3.1. Authenticated Entities 197 There are two major classes of authenticated entities in the system: 199 o Calling services: Web sites whose origin we can verify (in 200 practice this means HTTPS). 201 o Other users: RTCWEB peers whose origin we can verify 202 cryptographically (optimally via DTLS-SRTP). 204 Note that merely being authenticated does not make these entities 205 trusted. For instance, just because we can verify that 206 https://www.evil.org/ is owned by Dr. Evil does not mean that we can 207 trust Dr. Evil to access our camera and microphone. However, it 208 gives the user an opportunity to determine whether he wishes to trust 209 Dr. Evil or not; after all, if he desires to contact Dr. Evil 210 (perhaps to arrange for ransom payment), it's safe to temporarily 211 give him access to the camera and microphone for the purpose of the 212 call, but he doesn't want Dr. Evil to be able to access his camera 213 and microphone other than during the call. The point here is that we 214 must first identify other elements before we can determine whether 215 and how much to trust them. 217 It's also worth noting that there are settings where authentication 218 is non-cryptographic, such as other machines behind a firewall. 219 Naturally, the level of trust one can have in identities verified in 220 this way depends on how strong the topology enforcement is. 222 3.2. Unauthenticated Entities 224 Other than the above entities, we are not generally able to identify 225 other network elements, thus we cannot trust them. This does not 226 mean that it is not possible to have any interaction with them, but 227 it means that we must assume that they will behave maliciously and 228 design a system which is secure even if they do so. 230 4. Overview 232 This section describes a typical RTCWeb session and shows how the 233 various security elements interact and what guarantees are provided 234 to the user. The example in this section is a "best case" scenario 235 in which we provide the maximal amount of user authentication and 236 media privacy with the minimal level of trust in the calling service. 237 Simpler versions with lower levels of security are also possible and 238 are noted in the text where applicable. It's also important to 239 recognize the tension between security (or performance) and privacy. 240 The example shown here is aimed towards settings where we are more 241 concerned about secure calling than about privacy, but as we shall 242 see, there are settings where one might wish to make different 243 tradeoffs--this architecture is still compatible with those settings. 245 For the purposes of this example, we assume the topology shown in the 246 figure below. This topology is derived from the topology shown in 247 Figure 1, but separates Alice and Bob's identities from the process 248 of signaling. Specifically, Alice and Bob have relationships with 249 some Identity Provider (IdP) that supports a protocol such OpenID or 250 BrowserID) that can be used to attest to their identity. This 251 separation isn't particularly important in "closed world" cases where 252 Alice and Bob are users on the same social network and have 253 identities based on that network. However, there are important 254 settings where that is not the case, such as federation (calls from 255 one network to another) and calling on untrusted sites, such as where 256 two users who have a relationship via a given social network want to 257 call each other on another, untrusted, site, such as a poker site. 259 +----------------+ 260 | | 261 | Signaling | 262 | Server | 263 | | 264 +----------------+ 265 ^ ^ 266 / \ 267 HTTPS / \ HTTPS 268 / \ 269 / \ 270 v v 271 JS API JS API 272 +-----------+ +-----------+ 273 | | Media | | 274 Alice | Browser |<---------->| Browser | Bob 275 | | (DTLS-SRTP)| | 276 +-----------+ +-----------+ 277 ^ ^--+ +--^ ^ 278 | | | | 279 v | | v 280 +-----------+ | | +-----------+ 281 | |<--------+ | | 282 | IdP | | | IdP | 283 | | +------->| | 284 +-----------+ +-----------+ 286 Figure 2: A call with IdP-based identity 288 4.1. Initial Signaling 290 Alice and Bob are both users of a common calling service; they both 291 have approved the calling service to make calls (we defer the 292 discussion of device access permissions till later). They are both 293 connected to the calling service via HTTPS and so know the origin 294 with some level of confidence. They also have accounts with some 295 identity provider. This sort of identity service is becoming 296 increasingly common in the Web environment in technologies such 297 (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, 298 WebFinger), and is often provided as a side effect service of your 299 ordinary accounts with some service. In this example, we show Alice 300 and Bob using a separate identity service, though they may actually 301 be using the same identity service as calling service or have no 302 identity service at all. 304 Alice is logged onto the calling service and decides to call Bob. She 305 can see from the calling service that he is online and the calling 306 service presents a JS UI in the form of a button next to Bob's name 307 which says "Call". Alice clicks the button, which initiates a JS 308 callback that instantiates a PeerConnection object. This does not 309 require a security check: JS from any origin is allowed to get this 310 far. 312 Once the PeerConnection is created, the calling service JS needs to 313 set up some media. Because this is an audio/video call, it creates 314 two MediaStreams, one connected to an audio input and one connected 315 to a video input. At this point the first security check is 316 required: untrusted origins are not allowed to access the camera and 317 microphone. In this case, because Alice is a long-term user of the 318 calling service, she has made a permissions grant (i.e., a setting in 319 the browser) to allow the calling service to access her camera and 320 microphone any time it wants. The browser checks this setting when 321 the camera and microphone requests are made and thus allows them. 323 In the current W3C API, once some streams have been added, Alice's 324 browser + JS generates a signaling message The format of this data is 325 currently undefined. It may be a complete message as defined by ROAP 326 [I-D.jennings-rtcweb-signaling] or separate media description and 327 transport messages as defined in [I-D.ietf-rtcweb-jsep] or may be 328 assembled piecemeal by the JS. In either case, it will contain: 330 o Media channel information 331 o ICE candidates 332 o A fingerprint attribute binding the communication to Alice's 333 public key [RFC5763] 335 [Note that it is currently unclear where JSEP will eventually put 336 this information, in the SDP or in the transport info.] Prior to 337 sending out the signaling message, the PeerConnection code contacts 338 the identity service and obtains an assertion binding Alice's 339 identity to her fingerprint. The exact details depend on the 340 identity service (though as discussed in Section 5.6 PeerConnection 341 can be agnostic to them), but for now it's easiest to think of as a 342 BrowserID assertion. The assertion may bind other information to the 343 identity besides the fingerprint, but at minimum it needs to bind the 344 fingerprint. 346 This message is sent to the signaling server, e.g., by XMLHttpRequest 347 [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server 348 processes the message from Alice's browser, determines that this is a 349 call to Bob and sends a signaling message to Bob's browser (again, 350 the format is currently undefined). The JS on Bob's browser 351 processes it, and alerts Bob to the incoming call and to Alice's 352 identity. In this case, Alice has provided an identity assertion and 353 so Bob's browser contacts Alice's identity provider (again, this is 354 done in a generic way so the browser has no specific knowledge of the 355 IdP) to verify the assertion. This allows the browser to display a 356 trusted element indicating that a call is coming in from Alice. If 357 Alice is in Bob's address book, then this interface might also 358 include her real name, a picture, etc. The calling site will also 359 provide some user interface element (e.g., a button) to allow Bob to 360 answer the call, though this is most likely not part of the trusted 361 UI. 363 If Bob agrees [I am ignoring early media for now], a PeerConnection 364 is instantiated with the message from Alice's side. Then, a similar 365 process occurs as on Alice's browser: Bob's browser verifies that 366 the calling service is approved, the media streams are created, and a 367 return signaling message containing media information, ICE 368 candidates, and a fingerprint is sent back to Alice via the signaling 369 service. If Bob has a relationship with an IdP, the message will 370 also come with an identity assertion. 372 At this point, Alice and Bob each know that the other party wants to 373 have a secure call with them. Based purely on the interface provided 374 by the signaling server, they know that the signaling server claims 375 that the call is from Alice to Bob. Because the far end sent an 376 identity assertion along with their message, they know that this is 377 verifiable from the IdP as well. Of course, the call works perfectly 378 well if either Alice or Bob doesn't have a relationship with an IdP; 379 they just get a lower level of assurance. Moreover, Alice might wish 380 to make an anonymous call through an anonymous calling site, in which 381 case she would of course just not provide any identity assertion and 382 the calling site would mask her identity from Bob. 384 4.2. Media Consent Verification 386 As described in ([I-D.ietf-rtcweb-security]; Section 4.2) This 387 proposal specifies that media consent verification be performed via 388 ICE. Thus, Alice and Bob perform ICE checks with each other. At the 389 completion of these checks, they are ready to send non-ICE data. 391 At this point, Alice knows that (a) Bob (assuming he is verified via 392 his IdP) or someone else who the signaling service is claiming is Bob 393 is willing to exchange traffic with her and (b) that either Bob is at 394 the IP address which she has verified via ICE or there is an attacker 395 who is on-path to that IP address detouring the traffic. Note that 396 it is not possible for an attacker who is on-path but not attached to 397 the signaling service to spoof these checks because they do not have 398 the ICE credentials. Bob's security guarantees with respect to Alice 399 are the converse of this. 401 4.3. DTLS Handshake 403 Once the ICE checks have completed [more specifically, once some ICE 404 checks have completed], Alice and Bob can set up a secure channel. 405 This is performed via DTLS [RFC4347] (for the data channel) and DTLS- 406 SRTP [RFC5763] for the media channel. Specifically, Alice and Bob 407 perform a DTLS handshake on every channel which has been established 408 by ICE. The total number of channels depends on the amount of 409 muxing; in the most likely case we are using both RTP/RTCP mux and 410 muxing multiple media streams on the same channel, in which case 411 there is only one DTLS handshake. Once the DTLS handshake has 412 completed, the keys are exported [RFC5705] and used to key SRTP for 413 the media channels. 415 At this point, Alice and Bob know that they share a set of secure 416 data and/or media channels with keys which are not known to any 417 third-party attacker. If Alice and Bob authenticated via their IdPs, 418 then they also know that the signaling service is not attacking them. 419 Even if they do not use an IdP, as long as they have minimal trust in 420 the signaling service not to perform a man-in-the-middle attack, they 421 know that their communications are secure against the signaling 422 service as well. 424 4.4. Communications and Consent Freshness 426 From a security perspective, everything from here on in is a little 427 anticlimactic: Alice and Bob exchange data protected by the keys 428 negotiated by DTLS. Because of the security guarantees discussed in 429 the previous sections, they know that the communications are 430 encrypted and authenticated. 432 The one remaining security property we need to establish is "consent 433 freshness", i.e., allowing Alice to verify that Bob is still prepared 434 to receive her communications. ICE specifies periodic STUN 435 keepalizes but only if media is not flowing. Because the consent 436 issue is more difficult here, we require RTCWeb implementations to 437 periodically send keepalives. As described in Section 5.3, these 438 keepalives MUST be based on the consent freshness mechanism specified 439 in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no 440 new ICEchannels can be established, then the session is terminated. 442 5. Detailed Technical Description 444 5.1. Origin and Web Security Issues 446 The basic unit of permissions for RTCWEB is the origin [RFC6454]. 447 Because the security of the origin depends on being able to 448 authenticate content from that origin, the origin can only be 449 securely established if data is transferred over HTTPS [RFC2818]. 450 Thus, clients MUST treat HTTP and HTTPS origins as different 451 permissions domains. [Note: this follows directly from the origin 452 security model and is stated here merely for clarity.] 454 Many web browsers currently forbid by default any active mixed 455 content on HTTPS pages. I.e., when JS is loaded from an HTTP origin 456 onto an HTTPS page, an error is displayed and the content is not 457 executed unless the user overrides the error. Any browser which 458 enforces such a policy will also not permit access to RTCWEB 459 functionality from mixed content pages. It is RECOMMENDED that 460 browsers which allow active mixed content nevertheless disable RTCWEB 461 functionality in mixed content settings. [[ OPEN ISSUE: Should this 462 be a 2119 MUST? It's not clear what set of conditions would make 463 this OK, other than that browser manufacturers have traditionally 464 been permissive here here.]] Note that it is possible for a page 465 which was not mixed content to become mixed content during the 466 duration of the call. Implementations MAY choose to terminate the 467 call or display a warning at that point, but it is also permissible 468 to ignore this condition. This is a deliberate implementation 469 complexity versus security tradeoff. [[ OPEN ISSUE:: Should we be 470 more aggressive about this?]] 472 5.2. Device Permissions Model 474 Implementations MUST obtain explicit user consent prior to providing 475 access to the camera and/or microphone. Implementations MUST at 476 minimum support the following two permissions models for HTTPS 477 origins. 479 o Requests for one-time camera/microphone access. 480 o Requests for permanent access. 482 Because HTTP origins cannot be securely established against network 483 attackers, implementations MUST NOT allow the setting of permanent 484 access permissions for HTTP origins. Implementations MAY also opt to 485 refuse all permissions grants for HTTP origins, but it is RECOMMENDED 486 that currently they support one-time camera/microphone access. 488 In addition, they SHOULD support requests for access to a single 489 communicating peer. E.g., "Call customerservice@ford.com". Browsers 490 servicing such requests SHOULD clearly indicate that identity to the 491 user when asking for permission. 493 API Requirement: The API MUST provide a mechanism for the requesting 494 JS to indicate which of these forms of permissions it is 495 requesting. This allows the client to know what sort of user 496 interface experience to provide, i.e., to allow the client to 497 clearly indicate to the user what he is agreeing to. In 498 particular, browsers might display a non-invasive door hanger 499 ("some features of this site may not work..." when asking for 500 long-term permissions) but a more invasive UI ("here is your own 501 video") for single-call permissions. The API MAY grant weaker 502 permissions than the JS asked for if the user chooses to authorize 503 only those permissions, but if it intends to grant stronger ones 504 it SHOULD display the appropriate UI for those permissions and 505 MUST clearly indicate what permissions are being requested. 507 API Requirement: The API MUST provide a mechanism for the requesting 508 JS to relinquish the ability to see or modify the media (e.g., via 509 MediaStream.record()). Combined with secure authentication of the 510 communicating peer, this allows a user to be sure that the calling 511 site is not accessing or modifying their conversion. 513 UI Requirement: The UI MUST clearly indicate when the user's camera 514 and microphone are in use. This indication MUST NOT be 515 suppressable by the JS and MUST clearly indicate how to terminate 516 a call, and provide a UI means to immediately stop camera/ 517 microphone input without the JS being able to prevent it. 519 UI Requirement: If the UI indication of camera/microphone use are 520 displayed in the browser such that minimizing the browser window 521 would hide the indication, or the JS creating an overlapping 522 window would hide the indication, then the browser SHOULD stop 523 camera and microphone input. [Note: this may not be necessary in 524 systems that are non-windows-based but that have good 525 notifications support, such as phones.] 527 Clients MAY permit the formation of data channels without any direct 528 user approval. Because sites can always tunnel data through the 529 server, further restrictions on the data channel do not provide any 530 additional security. (though see Section 5.3 for a related issue). 532 Implementations which support some form of direct user authentication 533 SHOULD also provide a policy by which a user can authorize calls only 534 to specific counterparties. Specifically, the implementation SHOULD 535 provide the following interfaces/controls: 537 o Allow future calls to this verified user. 538 o Allow future calls to any verified user who is in my system 539 address book (this only works with address book integration, of 540 course). 542 Implementations SHOULD also provide a different user interface 543 indication when calls are in progress to users whose identities are 544 directly verifiable. Section 5.5 provides more on this. 546 5.3. Communications Consent 548 Browser client implementations of RTCWEB MUST implement ICE. Server 549 gateway implementations which operate only at public IP addresses may 550 implement ICE-Lite instead of ICE but MUST implement one of the two. 552 Browser implementations MUST verify reachability via ICE prior to 553 sending any non-ICE packets to a given destination. Implementations 554 MUST NOT provide the ICE transaction ID to JavaScript during the 555 lifetime of the transaction (i.e., during the period when the ICE 556 stack would accept a new response for that transaction). [Note: 557 this document takes no position on the split between ICE in JS and 558 ICE in the browser. The above text is written the way it is for 559 editorial convenience and will be modified appropriately if the WG 560 decides on ICE in the JS.] 562 Implementations MUST send keepalives no less frequently than every 30 563 seconds regardless of whether traffic is flowing or not. If a 564 keepalive fails then the implementation MUST either attempt to find a 565 new valid path via ICE or terminate media for that ICE component. 566 Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding 567 Indications which are one-way and therefore not sufficient. Instead, 568 the consent freshness mechanism [I-D.muthu-behave-consent-freshness] 569 MUST be used. 571 5.4. IP Location Privacy 573 A side effect of the default ICE behavior is that the peer learns 574 one's IP address, which leaks large amounts of location information, 575 especially for mobile devices. This has negative privacy 576 consequences in some circumstances. The API requirements in this 577 section are intended to mitigate this issue. Note that these 578 requirements are NOT intended to protect the user's IP address from a 579 malicious site. In general, the site will learn at least a user's 580 server reflexive address from any HTTP transaction. Rather, these 581 requirements are intended to allow a site to cooperate with the user 582 to hide the user's IP address from the other side of the call. 583 Hiding the user's IP address from the server requires some sort of 584 explicit privacy preserving mechanism on the client (e.g., Torbutton 585 [https://www.torproject.org/torbutton/]) and is out of scope for this 586 specification. 588 API Requirement: The API MUST provide a mechanism to allow the JS to 589 suppress ICE negotiation (though perhaps to allow candidate 590 gathering) until the user has decided to answer the call [note: 591 determining when the call has been answered is a question for the 592 JS.] This enables a user to prevent a peer from learning their IP 593 address if they elect not to answer a call and also from learning 594 whether the user is online. 596 API Requirement: The API MUST provide a mechanism for the calling 597 application JS to indicate that only TURN candidates are to be 598 used. This prevents the peer from learning one's IP address at 599 all. The API MUST provide a mechanism for the calling application 600 to reconfigure an existing call to add non-TURN candidates. Taken 601 together, these requirements allow ICE negotiation to start 602 immediately on incoming call notification, thus reducing post-dial 603 delay, but also to avoid disclosing the user's IP address until 604 they have decided to answer. They also allow users to completely 605 hide their IP address for the duration of the call. Finally, they 606 allow a mechanism for the user to optimize performance by 607 reconfiguring to allow non-TURN candidates during an active call 608 if the user decides they no longer need to hide their IP address 610 5.5. Communications Security 612 Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP 613 [RFC5763][RFC5764]. All data channels MUST be secured via DTLS. 614 DTLS-SRTP MUST be offered for every media channel and MUST be the 615 default; i.e., if an implementation receives an offer for DTLS-SRTP 616 and SDES, DTLS-SRTP MUST be selected. Media traffic MUST NOT be sent 617 over plain (unencrypted) RTP. 619 [OPEN ISSUE: What should the settings be here? MUST?] 620 Implementations MAY support SDES and RTP for media traffic for 621 backward compatibility purposes. 623 API Requirement: The API MUST provide a mechanism to indicate that a 624 fresh DTLS key pair is to be generated for a specific call. This 625 is intended to allow for unlinkability. Note that there are also 626 settings where it is attractive to use the same keying material 627 repeatedly, especially those with key continuity-based 628 authentication. 630 API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the 631 JS to obtain the negotiated keying material. This requirement 632 preserves the end-to-end security of the media. 634 UI Requirements: A user-oriented client MUST provide an 635 "inspector" interface which allows the user to determine the 636 security characteristics of the media. [largely derived from 637 [I-D.kaufman-rtcweb-security-ui] 638 The following properties SHOULD be displayed "up-front" in the 639 browser chrome, i.e., without requiring the user to ask for them: 641 * A client MUST provide a user interface through which a user may 642 determine the security characteristics for currently-displayed 643 audio and video stream(s) 644 * A client MUST provide a user interface through which a user may 645 determine the security characteristics for transmissions of 646 their microphone audio and camera video. 647 * The "security characteristics" MUST include an indication as to 648 whether the cryptographic keys were delivered out-of-band (from 649 a server) or were generated as a result of a pairwise 650 negotiation. 651 * If the far endpoint was directly verified, either via a third- 652 party verifiable X.509 certificate or via a Web IdP mechanism 653 (see Section 5.6) the "security characteristics" MUST include 654 the verified information. 655 The following properties are more likely to require some "drill- 656 down" from the user: 658 * The security characteristics MUST indicate the cryptographic 659 algorithms in use (For example: "AES-CBC" or "Null Cipher".) 660 * The "security characteristics" MUST indicate whether PFS is 661 provided. 662 * The "security characteristics" MUST include some mechanism to 663 allow an out-of-band verification of the peer, such as a 664 certificate fingerprint or an SAS. 666 5.6. Web-Based Peer Authentication 668 In a number of cases, it is desirable for the endpoint (i.e., the 669 browser) to be able to directly identity the endpoint on the other 670 side without trusting only the signaling service to which they are 671 connected. For instance, users may be making a call via a federated 672 system where they wish to get direct authentication of the other 673 side. Alternately, they may be making a call on a site which they 674 minimally trust (such as a poker site) but to someone who has an 675 identity on a site they do trust (such as a social network.) 677 Recently, a number of Web-based identity technologies (OAuth, 678 BrowserID, Facebook Connect), etc. have been developed. While the 679 details vary, what these technologies share is that they have a Web- 680 based (i.e., HTTP/HTTPS identity provider) which attests to your 681 identity. For instance, if I have an account at example.org, I could 682 use the example.org identity provider to prove to others that I was 683 alice@example.org. The development of these technologies allows us 684 to separate calling from identity provision: I could call you on 685 Poker Galaxy but identify myself as alice@example.org. 687 Whatever the underlying technology, the general principle is that the 688 party which is being authenticated is NOT the signaling site but 689 rather the user (and their browser). Similarly, the relying party is 690 the browser and not the signaling site. Thus, the browser MUST 691 securely generate the input to the IdP assertion process and MUST 692 securely display the results of the verification process to the user 693 in a way which cannot be imitated by the calling site. 695 In order to make this work, we must standardize the following items: 697 o The precise information from the signaling message that must be 698 cryptographically bound to the user's identity and a mechanism for 699 carrying assertions in JSEP messages. Section 5.6.3 700 o The interface to the IdP. Section 5.6.4 specifies a specific 701 protocol mechanism which allows the use of any identity protocol 702 without requiring specific further protocol support in the browser 703 o The JavaScript interfaces which the calling application can use to 704 specify the IdP to use to generate assertions and to discover what 705 assertions were received. 707 The first two items are defined in this document. The final one is 708 defined in the companion W3C WebRTC API specification [TODO:REF] 710 The mechanisms in this document do not require the browser to 711 implement any particular identity protocol or to support any 712 particular IdP. Instead, this document provides a generic interface 713 which any IdP can implement. Thus, new IdPs and protocols can be 714 introduced without change to either the browser or the calling 715 service. This avoids the need to make a commitment to any particular 716 identity protocol, although browsers may opt to directly implement 717 some identity protocols in order to provide superior performance or 718 UI properties. 720 5.6.1. Trust Relationships: IdPs, APs, and RPs 722 Any federated identity protocol has three major participants: 724 Authenticating Party (AP): The entity which is trying to establish 725 its identity. 727 Identity Provider (IdP): The entity which is vouching for the AP's 728 identity. 730 Relying Party (RP): The entity which is trying to verify the AP's 731 identity. 733 The AP and the IdP have an account relationship of some kind: the AP 734 registers with the IdP and is able to subsequently authenticate 735 directly to the IdP (e.g., with a password). This means that the 736 browser must somehow know which IdP(s) the user has an account 737 relationship with. This can either be something that the user 738 configures into the browser or that is configured at the calling site 739 and then provided to the PeerConnection by the calling site. 741 At a high level there are two kinds of IdPs: 743 Authoritative: IdPs which have verifiable control of some section 744 of the identity space. For instance, in the realm of e-mail, the 745 operator of "example.com" has complete control of the namespace 746 ending in "@example.com". Thus, "alice@example.com" is whoever 747 the operator says it is. Examples of systems with authoritative 748 identity providers include DNSSEC, RFC 4474, and Facebook Connect 749 (Facebook identities only make sense within the context of the 750 Facebook system). 752 Third-Party: IdPs which don't have control of their section of the 753 identity space but instead verify user's identities via some 754 unspecified mechanism and then attest to it. Because the IdP 755 doesn't actually control the namespace, RPs need to trust that the 756 IdP is correctly verifying AP identities, and there can 757 potentially be multiple IdPs attesting to the same section of the 758 identity space. Probably the best-known example of a third-party 759 identity provider is SSL certificates, where there are a large 760 number of CAs all of whom can attest to any domain name. 762 If an AP is authenticating via an authoritative IdP, then the RP does 763 not need to explicitly trust the IdP at all: as long as the RP knows 764 how to verify that the IdP indeed made the relevant identity 765 assertion (a function provided by the mechanisms in this document), 766 then any assertion it makes about an identity for which it is 767 authoritative is directly verifiable. 769 By contrast, if an AP is authenticating via a third-party IdP, the RP 770 needs to explicitly trust that IdP (hence the need for an explicit 771 trust anchor list in PKI-based SSL/TLS clients). The list of 772 trustable IdPs needs to be configured directly into the browser, 773 either by the user or potentially by the browser manufacturer. This 774 is a significant advantage of authoritative IdPs and implies that if 775 third-party IdPs are to be supported, the potential number needs to 776 be fairly small. 778 5.6.2. Overview of Operation 780 In order to provide security without trusting the calling site, the 781 PeerConnection component of the browser must interact directly with 782 the IdP. The details of the mechanism are described in the W3C API 783 specification, but the general idea is that the PeerConnection 784 component downloads JS from a specific location on the IdP dictated 785 by the IdP domain name. That JS (the "IdP proxy") runs in an 786 isolated security context within the browser and the PeerConnection 787 talks to it via a secure message passing channel. 789 +------------------------------------+ 790 | https://calling-site.example.com | 791 | | 792 | | 793 | | 794 | Calling JS Code | 795 | ^ | 796 | | API Calls | 797 | v | 798 | PeerConnection | 799 | ^ | 800 | | postMessage() | 801 | v | 802 | +-------------------------+ | +---------------+ 803 | | https://idp.example.org | | | | 804 | | |<--------->| Identity | 805 | | IdP JS | | | Provider | 806 | | | | | | 807 | +-------------------------+ | +---------------+ 808 | | 809 +------------------------------------+ 811 When the PeerConnection object wants to interact with the IdP, the 812 sequence of events is as follows: 814 1. The browser (the PeerConnection component) instantiates an IdP 815 proxy with its source at the IdP. This allows the IdP to load 816 whatever JS is necessary into the proxy, which runs in the IdP's 817 security context. 818 2. If the user is not already logged in, the IdP does whatever is 819 required to log them in, such as soliciting a username and 820 password. 822 3. Once the user is logged in, the IdP proxy notifies the browser 823 that it is ready. 824 4. The browser and the IdP proxy communicate via a standardized 825 series of messages delivered via postMessage. For instance, the 826 browser might request the IdP proxy to sign or verify a given 827 identity assertion. 829 This approach allows us to decouple the browser from any particular 830 identity provider; the browser need only know how to load the IdP's 831 JavaScript--which is deterministic from the IdP's identity--and the 832 generic protocol for requesting and verifying assertions. The IdP 833 provides whatever logic is necessary to bridge the generic protocol 834 to the IdP's specific requirements. Thus, a single browser can 835 support any number of identity protocols, including being forward 836 compatible with IdPs which did not exist at the time the browser was 837 written. 839 5.6.3. Binding Identity Assertions to JSEP Offer/Answer Transactions 841 5.6.3.1. Input to Assertion Generation Process 843 As discussed above, an identity assertion binds the user's identity 844 (as asserted by the IdP) to the JSEP offer/exchange transaction and 845 specifically to the media. In order to achieve this, the 846 PeerConnection must provide the DTLS-SRTP fingerprint to be bound to 847 the identity. This is provided in a JSON structure for 848 extensibility, as shown below: 850 { 851 "fingerprint" : { 852 { 853 "algorithm":"SHA-1", 854 "digest":"4A:AD:B9:B1:3F:...:E5:7C:AB" 855 } 856 } 858 The "algorithm" and digest values correspond directly to the 859 algorithm and digest in the a=fingerprint line of the SDP. 861 Note: this structure does not need to be interpreted by the IdP or 862 the IdP proxy. It is consumed solely by the RP's browser. The IdP 863 merely treats it as an opaque value to be attested to. Thus, new 864 parameters can be added to the assertion without modifying the IdP. 866 5.6.3.2. Carrying Identity Assertions 868 Once an IdP has generated an assertion, the JSEP message. This is 869 done by adding a new a-line to the SDP, of the form a=identity. The 870 sole contents of this value are a base-64-encoded version of the 871 identity assertion. For example: 873 v=0 874 o=- 1181923068 1181923196 IN IP4 ua1.example.com 875 s=example1 876 c=IN IP4 ua1.example.com 877 a=setup:actpass 878 a=fingerprint: SHA-1 \ 879 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 880 a=identity: \ 881 ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n \ 882 dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v \ 883 cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs \ 884 XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg== 885 t=0 0 886 m=audio 6056 RTP/AVP 0 887 a=sendrecv 888 a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP 889 a=pcfg:1 t=1 891 Each identity attribute should be paired (and attests to) with an 892 a=fingerprint attribute and therefore can exist either at the session 893 or media level. Multiple identity attributes may appear at either 894 level, though implementations are discouraged from doing this unless 895 they have a clear idea of what security claim they intend to be 896 making. 898 5.6.4. IdP Interaction Details 900 5.6.4.1. General Message Structure 902 Messages between the PeerConnection object and the IdP proxy are 903 formatted using JSON [RFC4627]. For instance, the PeerConnection 904 would request a signature with the following "SIGN" message: 906 { 907 "type":"SIGN", 908 "id": "1", 909 "origin":"https://calling-site.example.com", 910 "message":"012345678abcdefghijkl" 911 } 913 All messages MUST contain a "type" field which indicates the general 914 meaning of the message. 916 All requests from the PeerConnection object MUST contain an "id" 917 field which MUST be unique for that PeerConnection object. Any 918 responses from the IdP proxy MUST contain the same id in response, 919 which allows the PeerConnection to correlate requests and responses. 921 All requests from the PeerConnection object MUST contain an "origin" 922 field containing the origin of the JS which initiated the PC (i.e., 923 the URL of the calling site). This origin value can be used by the 924 IdP to make access control decisions. For instance, an IdP might 925 only issue identity assertions for certain calling services in the 926 same way that some IdPs require that relying Web sites have an API 927 key before learning user identity. 929 Any message-specific data is carried in a "message" field. Depending 930 on the message type, this may either be a string or a richer JSON 931 object. 933 5.6.4.1.1. Errors 935 If an error occurs, the IdP sends a message of type "ERROR". The 936 message MAY have an "error" field containing freeform text data which 937 containing additional information about what happened. For instance: 939 { 940 "type":"ERROR", 941 "error":"Signature verification failed" 942 } 944 Figure 3: Example error 946 5.6.4.2. IdP Proxy Setup 948 In order to perform an identity transaction, the PeerConnection must 949 first create an IdP proxy. As stated above, the details of this are 950 specified in the W3C API document. From the perspective of this 951 specification, however, the relevant facts are: 953 o The JS runs in the IdP's security context with the base page 954 retrieved from the URL specified in Section 5.6.4.2.1 955 o The usual browser sandbox isolation mechanisms MUST be enforced 956 with respect to the IdP proxy. 957 o JS running in the IdP proxy MUST be able to send and receive 958 messages to the PeerConnection and the PC and IdP proxy are able 959 to verify the source and destination of these messages. 961 Initially the IdP proxy is in an unready state; the IdP JS must be 962 loaded and there may be several round trips to the IdP server, for 963 instance to log the user in. When the IdP proxy is ready to receive 964 commands, it delivers a "ready" message. As this message is 965 unsolicited, it simply contains: 967 { "type":"READY" } 969 Once the PeerConnection object receives the ready message, it can 970 send commands to the IdP proxy. 972 5.6.4.2.1. Determining the IdP URI 974 Each IdP proxy instance is associated with two values: 976 domain name: The IdP's domain name 977 protocol: The specific IdP protocol which the IdP is using. This is 978 a completely IdP-specific string, but allows an IdP to implement 979 two protocols in parallel. This value may be the empty string. 981 Each IdP MUST serve its initial entry page (i.e., the one loaded by 982 the IdP proxy) from the well-known URI specified in "/.well-known/ 983 idp-proxy/" on the IdP's web site. This URI MUST be loaded 984 via HTTPS [RFC2818]. For example, for the IdP "identity.example.com" 985 and the protocol "example", the URL would be: 987 https://example.com/.well-known/idp-proxy/example 989 5.6.4.2.1.1. Authenticating Party 991 How an AP determines the appropriate IdP domain is out of scope of 992 this specification. In general, however, the AP has some actual 993 account relationship with the IdP, as this identity is what the IdP 994 is attesting to. Thus, the AP somehow supplies the IdP information 995 to the browser. Some potential mechanisms include: 997 o Provided by the user directly. 998 o Selected from some set of IdPs known to the calling site. E.g., a 999 button that shows "Authenticate via Facebook Connect" 1001 5.6.4.2.1.2. Relying Party 1003 Unlike the AP, the RP need not have any particular relationship with 1004 the IdP. Rather, it needs to be able to process whatever assertion 1005 is provided by the AP. As the assertion contains the IdP's identity, 1006 the URI can be constructed directly from the assertion, and thus the 1007 RP can directly verify the technical validity of the assertion with 1008 no user interaction. Authoritative assertions need only be 1009 verifiable. Third-party assertions also MUST be verified against 1010 local policy, as described in Section 5.6.4.2.3.1. 1012 5.6.4.2.2. Requesting Assertions 1014 In order to request an assertion, the PeerConnection sends a "SIGN" 1015 message. Aside from the mandatory fields, this message has a 1016 "message" field containing a string. The contents of this string are 1017 defined above, but are opaque from the perspective of the IdP. 1019 A successful response to a "SIGN" message contains a message field 1020 which is a JS dictionary dictionary consisting of two fields: 1022 idp: A dictionary containing the domain name of the provider and the 1023 protocol string 1024 assertion: An opaque field containing the assertion itself. This is 1025 only interpretable by the idp or its proxy. 1027 Figure 4 shows an example transaction, with the message "abcde..." 1028 being signed and bound to identity "ekr@example.org". In this case, 1029 the message has presumably been digitally signed/MACed in some way 1030 that the IdP can later verify it, but this is an implementation 1031 detail and out of scope of this document. Line breaks are inserted 1032 solely for readability. 1034 PeerConnection -> IdP proxy: 1035 { 1036 "type":"SIGN", 1037 "id":1, 1038 "message":"abcdefghijklmnopqrstuvwyz" 1039 } 1041 IdPProxy -> PeerConnection: 1042 { 1043 "type":"SUCCESS", 1044 "id":1, 1045 "message": { 1046 "idp":{ 1047 "domain": "example.org" 1048 "protocol": "bogus" 1049 }, 1050 "assertion":\"{\"identity\":\"bob@example.org\", 1051 \"contents\":\"abcdefghijklmnopqrstuvwyz\", 1052 \"signature\":\"010203040506\"}" 1053 } 1054 } 1055 Figure 4: Example assertion request 1057 5.6.4.2.3. Verifying Assertions 1059 In order to verify an assertion, an RP sends a "VERIFY" message to 1060 the IdP proxy containing the assertion supplied by the AP in the 1061 "message" field. 1063 The IdP proxy verifies the assertion. Depending on the identity 1064 protocol, this may require one or more round trips to the IdP. For 1065 instance, an OAuth-based protocol will likely require using the IdP 1066 as an oracle, whereas with BrowserID the IdP proxy can likely verify 1067 the signature on the assertion without contacting the IdP, provided 1068 that it has cached the IdP's public key. 1070 Regardless of the mechanism, if verification succeeds, a successful 1071 response from the IdP proxy MUST contain a message field consisting 1072 of a dictionary/hash with the following fields: 1074 identity The identity of the AP from the IdP's perspective. Details 1075 of this are provided in Section 5.6.4.2.3.1 1076 contents The original unmodified string provided by the AP in the 1077 original SIGN request. 1079 Figure 5 shows an example transaction. Line breaks are inserted 1080 solely for readability. 1082 PeerConnection -> IdP Proxy: 1083 { 1084 "type":"VERIFY", 1085 "id":2, 1086 "message":\"{\"identity\":\"bob@example.org\", 1087 \"contents\":\"abcdefghijklmnopqrstuvwyz\", 1088 \"signature\":\"010203040506\"}" 1089 } 1091 IdP Proxy -> PeerConnection: 1092 { 1093 "type":"SUCCESS", 1094 "id":2, 1095 "message": { 1096 "identity" : { 1097 "name" : "bob@example.org", 1098 "displayname" : "Bob" 1099 }, 1100 "contents":"abcdefghijklmnopqrstuvwyz" 1101 } 1102 } 1104 Figure 5: Example verification request 1106 5.6.4.2.3.1. Identity Formats 1108 Identities passed from the IdP proxy to the PeerConnection are 1109 structured as JSON dictionaries with one mandatory field: "name". 1110 This field MUST consist of an RFC822-formatted string representing 1111 the user's identity. [[ OPEN ISSUE: Would it be better to have a 1112 typed field? ]] The PeerConnection API MUST check this string as 1113 follows: 1115 1. If the RHS of the string is equal to the domain name of the IdP 1116 proxy, then the assertion is valid, as the IdP is authoritative 1117 for this domain. 1118 2. If the RHS of the string is not equal to the domain name of the 1119 IdP proxy, then the PeerConnection object MUST reject the 1120 assertion unless (a) the IdP domain is listed as an acceptable 1121 third-party IdP and (b) local policy is configured to trust this 1122 IdP domain for the RHS of the identity string. 1124 Sites which have identities that do not fit into the RFC822 style 1125 (for instance, Facebook ids are simple numeric values) SHOULD convert 1126 them to this form by appending their IdP domain (e.g., 1127 12345@identity.facebook.com), thus ensuring that they are 1128 authoritative for the identity. 1130 The IdP proxy MAY also include a "displayname" field which contains a 1131 more user-friendly identity assertion. Browsers SHOULD take care in 1132 the UI to distinguish the "name" assertion which is verifiable 1133 directly from the "displayname" which cannot be verified and thus 1134 relies on trust in the IdP. In future, we may define other fields to 1135 allow the IdP to provide more information to the browser. 1137 5.7. Security Considerations 1139 Much of the security analysis of this problem is contained in 1140 [I-D.ietf-rtcweb-security] or in the discussion of the particular 1141 issues above. In order to avoid repetition, this section focuses on 1142 (a) residual threats that are not addressed by this document and (b) 1143 threats produced by failure/misbehavior of one of the components in 1144 the system. 1146 5.7.1. Communications Security 1148 While this document favors DTLS-SRTP, it permits a variety of 1149 communications security mechanisms and thus the level of 1150 communications security actually provided varies considerably. Any 1151 pair of implementations which have multiple security mechanisms in 1152 common are subject to being downgraded to the weakest of those common 1153 mechanisms by any attacker who can modify the signaling traffic. If 1154 communications are over HTTP, this means any on-path attacker. If 1155 communications are over HTTPS, this means the signaling server. 1156 Implementations which wish to avoid downgrade attack should only 1157 offer the strongest available mechanism, which is DTLS/DTLS-SRTP. 1158 Note that the implication of this choice will be that interop to non- 1159 DTLS-SRTP devices will need to happen through gateways. 1161 Even if only DTLS/DTLS-SRTP are used, the signaling server can 1162 potentially mount a man-in-the-middle attack unless implementations 1163 have some mechanism for independently verifying keys. The UI 1164 requirements in Section 5.5 are designed to provide such a mechanism 1165 for motivated/security conscious users, but are not suitable for 1166 general use. The identity service mechanisms in Section 5.6 are more 1167 suitable for general use. Note, however, that a malicious signaling 1168 service can strip off any such identity assertions, though it cannot 1169 forge new ones. Note that all of the third-party security mechanisms 1170 available (whether X.509 certificates or a third-party IdP) rely on 1171 the security of the third party--this is of course also true of your 1172 connection to the Web site itself. Users who wish to assure 1173 themselves of security against a malicious identity provider can only 1174 do so by verifing peer credentials directly, e.g., by checking the 1175 peer's fingerprint against a value delivered out of band. 1177 5.7.2. Privacy 1179 The requirements in this document are intended to allow: 1181 o Users to participate in calls without revealing their location. 1182 o Potential callees to avoid revealing their location and even 1183 presence status prior to agreeing to answer a call. 1185 However, these privacy protections come at a performance cost in 1186 terms of using TURN relays and, in the latter case, delaying ICE. 1187 Sites SHOULD make users aware of these tradeoffs. 1189 Note that the protections provided here assume a non-malicious 1190 calling service. As the calling service always knows the users 1191 status and (absent the use of a technology like Tor) their IP 1192 address, they can violate the users privacy at will. Users who wish 1193 privacy against the calling sites they are using must use separate 1194 privacy enhancing technologies such as Tor. Combined RTCWEB/Tor 1195 implementations SHOULD arrange to route the media as well as the 1196 signaling through Tor. [Currently this will produce very suboptimal 1197 performance.] 1199 5.7.3. Denial of Service 1201 The consent mechanisms described in this document are intended to 1202 mitigate denial of service attacks in which an attacker uses clients 1203 to send large amounts of traffic to a victim without the consent of 1204 the victim. While these mechanisms are sufficient to protect victims 1205 who have not implemented RTCWEB at all, RTCWEB implementations need 1206 to be more careful. 1208 Consider the case of a call center which accepts calls via RTCWeb. 1209 An attacker proxies the call center's front-end and arranges for 1210 multiple clients to initiate calls to the call center. Note that 1211 this requires user consent in many cases but because the data channel 1212 does not need consent, he can use that directly. Since ICE will 1213 complete, browsers can then be induced to send large amounts of data 1214 to the victim call center if it supports the data channel at all. 1215 Preventing this attack requires that automated RTCWEB 1216 implemementations implement sensible flow control and have the 1217 ability to triage out (i.e., stop responding to ICE probes on) calls 1218 which are behaving badly, and especially to be prepared to remotely 1219 throttle the data channel in the absence of plausible audio and video 1220 (which the attacker cannot control). 1222 Another related attack is for the signaling service to swap the ICE 1223 candidates for the audio and video streams, thus forcing a browser to 1224 send video to the sink that the other victim expects will contain 1225 audio (perhaps it is only expecting audio!) potentially causing 1226 overload. Muxing multiple media flows over a single transport makes 1227 it harder to individually suppress a single flow by denying ICE 1228 keepalives. Media-level (RTCP) mechanisms must be used in this case. 1230 Yet another attack, suggested by Magnus Westerlund, is for the 1231 attacker to cross-connect offers and answers as follows. It induces 1232 the victim to make a call and then uses its control of other users 1233 browsers to get them to attempt a call to someone. It then 1234 translates their offers into apparent answers to the victim, which 1235 looks like large-scale parallel forking. The victim still responds 1236 to ICE responses and now the browsers all try to send media to the 1237 victim. [[ OPEN ISSUE: How do we address this? ]] 1239 [TODO: Should we have a mechanism for verifying total expected 1240 bandwidth] 1242 Note that attacks based on confusing one end or the other about 1243 consent are possible primarily even in the face of the third-party 1244 identity mechanism as long as major parts of the signaling messages 1245 are not signed. On the other hand, signing the entire message 1246 severely restricts the capabilities of the calling application, so 1247 there are difficult tradeoffs here. 1249 5.7.4. IdP Authentication Mechanism 1251 This mechanism relies for its security on the IdP and on the 1252 PeerConnection correctly enforcing the security invariants described 1253 above. At a high level, the IdP is attesting that the user 1254 identified in the assertion wishes to be associated with the 1255 assertion. Thus, it must not be possible for arbitrary third parties 1256 to get assertions tied to a user or to produce assertions that RPs 1257 will accept. 1259 5.7.4.1. PeerConnection Origin Check 1261 Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by 1262 the browser, so nothing stops a Web attacker o from creating their 1263 own IFRAME, loading the IdP proxy HTML/JS, and requesting a 1264 signature. In order to prevent this attack, we require that all 1265 signatures be tied to a specific origin ("rtcweb://...") which cannot 1266 be produced by a page tied to a Web attacker. Thus, while an 1267 attacker can instantiate the IdP proxy, they cannot send messages 1268 from an appropriate origin and so cannot create acceptable 1269 assertions. [[OPEN ISSUE: Where is this enforced? ]] 1271 5.7.4.2. IdP Well-known URI 1273 As described in Section 5.6.4.2.1 the IdP proxy HTML/JS landing page 1274 is located at a well-known URI based on the IdP's domain name. This 1275 requirement prevents an attacker who can write some resources at the 1276 IdP (e.g., on one's Facebook wall) from being able to impersonate the 1277 IdP. 1279 5.7.4.3. Privacy of IdP-generated identities and the hosting site 1281 Depending on the structure of the IdP's assertions, the calling site 1282 may learn the user's identity from the perspective of the IdP. In 1283 many cases this is not an issue because the user is authenticating to 1284 the site via the IdP in any case, for instance when the user has 1285 logged in with Facebook Connect and is then authenticating their call 1286 with a Facebook identity. However, in other case, the user may not 1287 have already revealed their identity to the site. In general, IdPs 1288 SHOULD either verify that the user is willing to have their identity 1289 revealed to the site (e.g., through the usual IdP permissions dialog) 1290 or arrange that the identity information is only available to known 1291 RPs (e.g., social graph adjacencies) but not to the calling site. 1292 The "origin" field of the signature request can be used to check that 1293 the user has agreed to disclose their identity to the calling site; 1294 because it is supplied by the PeerConnection it can be trusted to be 1295 correct. 1297 5.7.4.4. Security of Third-Party IdPs 1299 As discussed above, each third-party IdP represents a new universal 1300 trust point and therefore the number of these IdPs needs to be quite 1301 limited. Most IdPs, even those which issue unqualified identities 1302 such as Facebook, can be recast as authoritative IdPs (e.g., 1303 123456@facebook.com). However, in such cases, the user interface 1304 implications are not entirely desirable. One intermediate approach 1305 is to have special (potentially user configurable) UI for large 1306 authoritative IdPs, thus allowing the user to instantly grasp that 1307 the call is being authenticated by Facebook, Google, etc. 1309 5.7.4.5. Web Security Feature Interactions 1311 A number of optional Web security features have the potential to 1312 cause issues for this mechanism, as discussed below. 1314 5.7.4.5.1. Popup Blocking 1316 If the user is not already logged into the IdP, the IdP proxy may 1317 need to pop up a top level window in order to prompt the user for 1318 their authentication information (it is bad practice to do this in an 1319 IFRAME inside the window because then users have no way to determine 1320 the destination for their password). If the user's browser is 1321 configured to prevent popups, this may fail (depending on the exact 1322 algorithm that the popup blocker uses to suppress popups). It may be 1323 necessary to provide a standardized mechanism to allow the IdP proxy 1324 to request popping of a login window. Note that care must be taken 1325 here to avoid PeerConnection becoming a general escape hatch from 1326 popup blocking. One possibility would be to only allow popups when 1327 the user has explicitly registered a given IdP as one of theirs (this 1328 is only relevant at the AP side in any case). This is what 1329 WebIntents does, and the problem would go away if WebIntents is used. 1331 5.7.4.5.2. Third Party Cookies 1333 Some browsers allow users to block third party cookies (cookies 1334 associated with origins other than the top level page) for privacy 1335 reasons. Any IdP which uses cookies to persist logins will be broken 1336 by third-party cookie blocking. One option is to accept this as a 1337 limitation; another is to have the PeerConnection object disable 1338 third-party cookie blocking for the IdP proxy. 1340 6. Acknowledgements 1342 Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Hadriel 1343 Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus 1344 Westerland. 1346 7. Changes since -03 1348 The following changes have been made since the -02 draft. 1350 o Editorial changes 1352 8. Changes since -02 1354 The following changes have been made since the -02 draft. 1356 o Forbid persistent HTTP permissions. 1357 o Clarified the text in S 5.4 to clearly refer to requirements on 1358 the API to provide functionality to the site. 1359 o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp 1361 9. References 1362 9.1. Normative References 1364 [I-D.ietf-rtcweb-security] 1365 Rescorla, E., "Security Considerations for RTC-Web", 1366 draft-ietf-rtcweb-security-03 (work in progress), 1367 June 2012. 1369 [I-D.muthu-behave-consent-freshness] 1370 Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for 1371 Consent Freshness and Session Liveness", 1372 draft-muthu-behave-consent-freshness-01 (work in 1373 progress), July 2012. 1375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1376 Requirement Levels", BCP 14, RFC 2119, March 1997. 1378 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1380 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1381 Security", RFC 4347, April 2006. 1383 [RFC4627] Crockford, D., "The application/json Media Type for 1384 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1386 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1387 (ICE): A Protocol for Network Address Translator (NAT) 1388 Traversal for Offer/Answer Protocols", RFC 5245, 1389 April 2010. 1391 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1392 for Establishing a Secure Real-time Transport Protocol 1393 (SRTP) Security Context Using Datagram Transport Layer 1394 Security (DTLS)", RFC 5763, May 2010. 1396 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1397 Security (DTLS) Extension to Establish Keys for the Secure 1398 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1400 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1401 December 2011. 1403 9.2. Informative References 1405 [I-D.ietf-rtcweb-jsep] 1406 Uberti, J. and C. Jennings, "Javascript Session 1407 Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work 1408 in progress), June 2012. 1410 [I-D.jennings-rtcweb-signaling] 1411 Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ 1412 Answer Protocol (ROAP)", 1413 draft-jennings-rtcweb-signaling-01 (work in progress), 1414 October 2011. 1416 [I-D.kaufman-rtcweb-security-ui] 1417 Kaufman, M., "Client Security User Interface Requirements 1418 for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in 1419 progress), June 2011. 1421 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1422 A., Peterson, J., Sparks, R., Handley, M., and E. 1423 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1424 June 2002. 1426 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1427 Layer Security (TLS)", RFC 5705, March 2010. 1429 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1430 RFC 6455, December 2011. 1432 [XmlHttpRequest] 1433 van Kesteren, A., "XMLHttpRequest Level 2". 1435 Appendix A. Example IdP Bindings to Specific Protocols 1437 This section provides some examples of how the mechanisms described 1438 in this document could be used with existing authentication protocols 1439 such as BrowserID or OAuth. Note that this does not require browser- 1440 level support for either protocol. Rather, the protocols can be fit 1441 into the generic framework. (Though BrowserID in particular works 1442 better with some client side support). 1444 A.1. BrowserID 1446 BrowserID [https://browserid.org/] is a technology which allows a 1447 user with a verified email address to generate an assertion 1448 (authenticated by their identity provider) attesting to their 1449 identity (phrased as an email address). The way that this is used in 1450 practice is that the relying party embeds JS in their site which 1451 talks to the BrowserID code (either hosted on a trusted intermediary 1452 or embedded in the browser). That code generates the assertion which 1453 is passed back to the relying party for verification. The assertion 1454 can be verified directly or with a Web service provided by the 1455 identity provider. It's relatively easy to extend this functionality 1456 to authenticate RTCWEB calls, as shown below. 1458 +----------------------+ +----------------------+ 1459 | | | | 1460 | Alice's Browser | | Bob's Browser | 1461 | | OFFER ------------> | | 1462 | Calling JS Code | | Calling JS Code | 1463 | ^ | | ^ | 1464 | | | | | | 1465 | v | | v | 1466 | PeerConnection | | PeerConnection | 1467 | | ^ | | | ^ | 1468 | Finger| |Signed | |Signed | | | 1469 | print | |Finger | |Finger | |"Alice"| 1470 | | |print | |print | | | 1471 | v | | | v | | 1472 | +--------------+ | | +---------------+ | 1473 | | IdP Proxy | | | | IdP Proxy | | 1474 | | to | | | | to | | 1475 | | BrowserID | | | | BrowserID | | 1476 | | Signer | | | | Verifier | | 1477 | +--------------+ | | +---------------+ | 1478 | ^ | | ^ | 1479 +-----------|----------+ +----------|-----------+ 1480 | | 1481 | Get certificate | 1482 v | Check 1483 +----------------------+ | certificate 1484 | | | 1485 | Identity |/-------------------------------+ 1486 | Provider | 1487 | | 1488 +----------------------+ 1490 The way this mechanism works is as follows. On Alice's side, Alice 1491 goes to initiate a call. 1493 1. The calling JS instantiates a PeerConnection and tells it that it 1494 is interested in having it authenticated via BrowserID (i.e., it 1495 provides "browserid.org" as the IdP name.) 1496 2. The PeerConnection instantiates the BrowserID signer in the IdP 1497 proxy 1498 3. The BrowserID signer contacts Alice's identity provider, 1499 authenticating as Alice (likely via a cookie). 1500 4. The identity provider returns a short-term certificate attesting 1501 to Alice's identity and her short-term public key. 1502 5. The Browser-ID code signs the fingerprint and returns the signed 1503 assertion + certificate to the PeerConnection. 1505 6. The PeerConnection returns the signed information to the calling 1506 JS code. 1507 7. The signed assertion gets sent over the wire to Bob's browser 1508 (via the signaling service) as part of the call setup. 1510 Obviously, the format of the signed assertion varies depending on 1511 what signaling style the WG ultimately adopts. However, for 1512 concreteness, if something like ROAP were adopted, then the entire 1513 message might look like: 1515 { 1516 "messageType":"OFFER", 1517 "callerSessionId":"13456789ABCDEF", 1518 "seq": 1 1519 "sdp":" 1520 v=0\n 1521 o=- 2890844526 2890842807 IN IP4 192.0.2.1\n 1522 s= \n 1523 c=IN IP4 192.0.2.1\n 1524 t=2873397496 2873404696\n 1525 m=audio 49170 RTP/AVP 0\n 1526 a=fingerprint: SHA-1 \ 1527 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n", 1528 "identity":{ 1529 "idp":{ // Standardized 1530 "domain":"browserid.org", 1531 "method":"default" 1532 }, 1533 "assertion": // Contents are browserid-specific 1534 "\"assertion\": { 1535 \"digest\":\"\", 1536 \"audience\": \"[TBD]\" 1537 \"valid-until\": 1308859352261, 1538 }, 1539 \"certificate\": { 1540 \"email\": \"rescorla@example.org\", 1541 \"public-key\": \"\", 1542 \"valid-until\": 1308860561861, 1543 }" // certificate is signed by example.org 1544 } 1545 } 1547 Note that while the IdP here is specified as "browserid.org", the 1548 actual certificate is signed by example.org. This is because 1549 BrowserID is a combined authoritative/third-party system in which 1550 browserid.org delegates the right to be authoritative (what BrowserID 1551 calls primary) to individual domains. 1553 On Bob's side, he receives the signed assertion as part of the call 1554 setup message and a similar procedure happens to verify it. 1556 1. The calling JS instantiates a PeerConnection and provides it the 1557 relevant signaling information, including the signed assertion. 1558 2. The PeerConnection instantiates the IdP proxy which examines the 1559 IdP name and brings up the BrowserID verification code. 1560 3. The BrowserID verifier contacts the identity provider to verify 1561 the certificate and then uses the key to verify the signed 1562 fingerprint. 1563 4. Alice's verified identity is returned to the PeerConnection (it 1564 already has the fingerprint). 1565 5. At this point, Bob's browser can display a trusted UI indication 1566 that Alice is on the other end of the call. 1568 When Bob returns his answer, he follows the converse procedure, which 1569 provides Alice with a signed assertion of Bob's identity and keying 1570 material. 1572 A.2. OAuth 1574 While OAuth is not directly designed for user-to-user authentication, 1575 with a little lateral thinking it can be made to serve. We use the 1576 following mapping of OAuth concepts to RTCWEB concepts: 1578 +----------------------+----------------------+ 1579 | OAuth | RTCWEB | 1580 +----------------------+----------------------+ 1581 | Client | Relying party | 1582 | Resource owner | Authenticating party | 1583 | Authorization server | Identity service | 1584 | Resource server | Identity service | 1585 +----------------------+----------------------+ 1587 Table 1 1589 The idea here is that when Alice wants to authenticate to Bob (i.e., 1590 for Bob to be aware that she is calling). In order to do this, she 1591 allows Bob to see a resource on the identity provider that is bound 1592 to the call, her identity, and her public key. Then Bob retrieves 1593 the resource from the identity provider, thus verifying the binding 1594 between Alice and the call. 1596 Alice IdP Bob 1597 --------------------------------------------------------- 1598 Call-Id, Fingerprint -------> 1599 <------------------- Auth Code 1600 Auth Code ----------------------------------------------> 1601 <----- Get Token + Auth Code 1602 Token ---------------------> 1603 <------------- Get call-info 1604 Call-Id, Fingerprint ------> 1606 This is a modified version of a common OAuth flow, but omits the 1607 redirects required to have the client point the resource owner to the 1608 IdP, which is acting as both the resource server and the 1609 authorization server, since Alice already has a handle to the IdP. 1611 Above, we have referred to "Alice", but really what we mean is the 1612 PeerConnection. Specifically, the PeerConnection will instantiate an 1613 IFRAME with JS from the IdP and will use that IFRAME to communicate 1614 with the IdP, authenticating with Alice's identity (e.g., cookie). 1615 Similarly, Bob's PeerConnection instantiates an IFRAME to talk to the 1616 IdP. 1618 Author's Address 1620 Eric Rescorla 1621 RTFM, Inc. 1622 2064 Edgewood Drive 1623 Palo Alto, CA 94303 1624 USA 1626 Phone: +1 650 678 2350 1627 Email: ekr@rtfm.com