idnits 2.17.1 draft-ietf-rtcweb-security-arch-09.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 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Browsers MUST not permit permanent screen or application sharing permissions to be installed as a response to a JS request for permissions. Instead, they must require some other user action such as a permissions setting or an application install experience to grant permission to a site. o Browsers MUST provide a separate dialog request for screen/ application sharing permissions even if the media request is made at the same time as camera and microphone. o The browser MUST indicate any windows which are currently being shared in some unambiguous way. Windows which are not visible MUST not be shared even if the application is being shared. If the screen is being shared, then that MUST be indicated. == 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 (February 14, 2014) is 3717 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-06 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-03 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Possible downref: Non-RFC (?) normative reference: ref. 'WebMessaging' == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-06 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 February 14, 2014 5 Expires: August 18, 2014 7 WebRTC Security Architecture 8 draft-ietf-rtcweb-security-arch-09 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 (commonly 15 called "WebRTC"). This document defines the security architecture 16 for WebRTC. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6 68 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6 69 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 9 71 4.2. Media Consent Verification . . . . . . . . . . . . . . . . 11 72 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Communications and Consent Freshness . . . . . . . . . . . 12 74 5. Detailed Technical Description . . . . . . . . . . . . . . . . 13 75 5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 13 76 5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 13 77 5.3. Communications Consent . . . . . . . . . . . . . . . . . . 15 78 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 16 79 5.5. Communications Security . . . . . . . . . . . . . . . . . 17 80 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 18 81 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 19 82 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 21 83 5.6.3. Items for Standardization . . . . . . . . . . . . . . 22 84 5.6.4. Binding Identity Assertions to JSEP Offer/Answer 85 Transactions . . . . . . . . . . . . . . . . . . . . . 22 86 5.6.4.1. Input to Assertion Generation Process . . . . . . 22 87 5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 23 88 5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 24 89 5.6.5.1. General Message Structure . . . . . . . . . . . . 24 90 5.6.5.2. Errors . . . . . . . . . . . . . . . . . . . . . . 25 91 5.6.5.3. IdP Proxy Setup . . . . . . . . . . . . . . . . . 25 92 5.7. Security Considerations . . . . . . . . . . . . . . . . . 30 93 5.7.1. Communications Security . . . . . . . . . . . . . . . 30 94 5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 31 95 5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 32 96 5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 33 97 5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 33 98 5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 34 99 5.7.4.3. Privacy of IdP-generated identities and the 100 hosting site . . . . . . . . . . . . . . . . . . . 34 101 5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 34 102 5.7.4.5. Web Security Feature Interactions . . . . . . . . 34 103 5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 105 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 106 7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 35 107 7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 36 108 7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 109 7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36 110 7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 36 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 113 8.2. Informative References . . . . . . . . . . . . . . . . . . 38 114 Appendix A. Example IdP Bindings to Specific Protocols . . . . . 39 115 A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39 116 A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 119 1. Introduction 121 The Real-Time Communications on the Web (WebRTC) working group is 122 tasked with standardizing protocols for real-time communications 123 between Web browsers. The major use cases for WebRTC technology are 124 real-time audio and/or video calls, Web conferencing, and direct data 125 transfer. Unlike most conventional real-time systems, (e.g., SIP- 126 based[RFC3261] soft phones) WebRTC communications are directly 127 controlled by some Web server, via a JavaScript (JS) API as shown in 128 Figure 1. 130 +----------------+ 131 | | 132 | Web Server | 133 | | 134 +----------------+ 135 ^ ^ 136 / \ 137 HTTP / \ HTTP 138 / \ 139 / \ 140 v v 141 JS API JS API 142 +-----------+ +-----------+ 143 | | Media | | 144 | Browser |<---------->| Browser | 145 | | | | 146 +-----------+ +-----------+ 148 Figure 1: A simple WebRTC system 150 A more complicated system might allow for interdomain calling, as 151 shown in Figure 2. The protocol to be used between the domains is 152 not standardized by WebRTC, but given the installed base and the form 153 of the WebRTC API is likely to be something SDP-based like SIP. 155 +--------------+ +--------------+ 156 | | SIP,XMPP,...| | 157 | Web Server |<----------->| Web Server | 158 | | | | 159 +--------------+ +--------------+ 160 ^ ^ 161 | | 162 HTTP | | HTTP 163 | | 164 v v 165 JS API JS API 166 +-----------+ +-----------+ 167 | | Media | | 168 | Browser |<---------------->| Browser | 169 | | | | 170 +-----------+ +-----------+ 172 Figure 2: A multidomain WebRTC system 174 This system presents a number of new security challenges, which are 175 analyzed in [I-D.ietf-rtcweb-security]. This document describes a 176 security architecture for WebRTC which addresses the threats and 177 requirements described in that document. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 3. Trust Model 187 The basic assumption of this architecture is that network resources 188 exist in a hierarchy of trust, rooted in the browser, which serves as 189 the user's TRUSTED COMPUTING BASE (TCB). Any security property which 190 the user wishes to have enforced must be ultimately guaranteed by the 191 browser (or transitively by some property the browser verifies). 192 Conversely, if the browser is compromised, then no security 193 guarantees are possible. Note that there are cases (e.g., Internet 194 kiosks) where the user can't really trust the browser that much. In 195 these cases, the level of security provided is limited by how much 196 they trust the browser. 198 Optimally, we would not rely on trust in any entities other than the 199 browser. However, this is unfortunately not possible if we wish to 200 have a functional system. Other network elements fall into two 201 categories: those which can be authenticated by the browser and thus 202 are partly trusted--though to the minimum extent necessary--and those 203 which cannot be authenticated and thus are untrusted. 205 3.1. Authenticated Entities 207 There are two major classes of authenticated entities in the system: 209 o Calling services: Web sites whose origin we can verify (optimally 210 via HTTPS, but in some cases because we are on a topologically 211 restricted network, such as behind a firewall, and can infer 212 authentication from firewall behavior). 213 o Other users: WebRTC peers whose origin we can verify 214 cryptographically (optimally via DTLS-SRTP). 216 Note that merely being authenticated does not make these entities 217 trusted. For instance, just because we can verify that 218 https://www.evil.org/ is owned by Dr. Evil does not mean that we can 219 trust Dr. Evil to access our camera and microphone. However, it 220 gives the user an opportunity to determine whether he wishes to trust 221 Dr. Evil or not; after all, if he desires to contact Dr. Evil 222 (perhaps to arrange for ransom payment), it's safe to temporarily 223 give him access to the camera and microphone for the purpose of the 224 call, but he doesn't want Dr. Evil to be able to access his camera 225 and microphone other than during the call. The point here is that we 226 must first identify other elements before we can determine whether 227 and how much to trust them. Additionally, sometimes we need to 228 identify the communicating peer before we know what policies to 229 apply. 231 It's also worth noting that there are settings where authentication 232 is non-cryptographic, such as other machines behind a firewall. 233 Naturally, the level of trust one can have in identities verified in 234 this way depends on how strong the topology enforcement is. 236 3.2. Unauthenticated Entities 238 Other than the above entities, we are not generally able to identify 239 other network elements, thus we cannot trust them. This does not 240 mean that it is not possible to have any interaction with them, but 241 it means that we must assume that they will behave maliciously and 242 design a system which is secure even if they do so. 244 4. Overview 246 This section describes a typical RTCWeb session and shows how the 247 various security elements interact and what guarantees are provided 248 to the user. The example in this section is a "best case" scenario 249 in which we provide the maximal amount of user authentication and 250 media privacy with the minimal level of trust in the calling service. 251 Simpler versions with lower levels of security are also possible and 252 are noted in the text where applicable. It's also important to 253 recognize the tension between security (or performance) and privacy. 254 The example shown here is aimed towards settings where we are more 255 concerned about secure calling than about privacy, but as we shall 256 see, there are settings where one might wish to make different 257 tradeoffs--this architecture is still compatible with those settings. 259 For the purposes of this example, we assume the topology shown in the 260 figures below. This topology is derived from the topology shown in 261 Figure 1, but separates Alice and Bob's identities from the process 262 of signaling. Specifically, Alice and Bob have relationships with 263 some Identity Provider (IdP) that supports a protocol such as OpenID 264 or BrowserID) that can be used to demonstrate their identity to other 265 parties. For instance, Alice might have an account with a social 266 network which she can then use to authenticate to other web sites 267 without explicitly having an account with those sites; this is a 268 fairly conventional pattern on the Web. Section 5.6.1 provides an 269 overview of Identity Providers and the relevant terminology. Alice 270 and Bob might have relationships with different IdPs as well. 272 This separation of identity provision and signaling isn't 273 particularly important in "closed world" cases where Alice and Bob 274 are users on the same social network and have identities based on 275 that domain (Figure 3) However, there are important settings where 276 that is not the case, such as federation (calls from one domain to 277 another; Figure 4) and calling on untrusted sites, such as where two 278 users who have a relationship via a given social network want to call 279 each other on another, untrusted, site, such as a poker site. 281 Note that the servers themselves are also authenticated by an 282 external identity service, the SSL/TLS certificate infrastructure 283 (not shown). As is conventional in the Web, all identities are 284 ultimately rooted in that system. For instance, when an IdP makes an 285 identity assertion, the Relying Party consuming that assertion is 286 able to verify because it is able to connect to the IdP via HTTPS. 288 +----------------+ 289 | | 290 | Signaling | 291 | Server | 292 | | 293 +----------------+ 294 ^ ^ 295 / \ 296 HTTPS / \ HTTPS 297 / \ 298 / \ 299 v v 300 JS API JS API 301 +-----------+ +-----------+ 302 | | Media | | 303 Alice | Browser |<---------->| Browser | Bob 304 | | (DTLS+SRTP)| | 305 +-----------+ +-----------+ 306 ^ ^--+ +--^ ^ 307 | | | | 308 v | | v 309 +-----------+ | | +-----------+ 310 | |<--------+ | | 311 | IdP1 | | | IdP2 | 312 | | +------->| | 313 +-----------+ +-----------+ 315 Figure 3: A call with IdP-based identity 317 Figure 4 shows essentially the same calling scenario but with a call 318 between two separate domains (i.e., a federated case), as in 319 Figure 2. As mentioned above, the domains communicate by some 320 unspecified protocol and providing separate signaling and identity 321 allows for calls to be authenticated regardless of the details of the 322 inter-domain protocol. 324 +----------------+ Unspecified +----------------+ 325 | | protocol | | 326 | Signaling |<----------------->| Signaling | 327 | Server | (SIP, XMPP, ...) | Server | 328 | | | | 329 +----------------+ +----------------+ 330 ^ ^ 331 | | 332 HTTPS | | HTTPS 333 | | 334 | | 335 v v 336 JS API JS API 337 +-----------+ +-----------+ 338 | | Media | | 339 Alice | Browser |<--------------------------->| Browser | Bob 340 | | DTLS+SRTP | | 341 +-----------+ +-----------+ 342 ^ ^--+ +--^ ^ 343 | | | | 344 v | | v 345 +-----------+ | | +-----------+ 346 | |<-------------------------+ | | 347 | IdP1 | | | IdP2 | 348 | | +------------------------>| | 349 +-----------+ +-----------+ 351 Figure 4: A federated call with IdP-based identity 353 4.1. Initial Signaling 355 For simplicity, assume the topology in Figure 3. Alice and Bob are 356 both users of a common calling service; they both have approved the 357 calling service to make calls (we defer the discussion of device 358 access permissions till later). They are both connected to the 359 calling service via HTTPS and so know the origin with some level of 360 confidence. They also have accounts with some identity provider. 361 This sort of identity service is becoming increasingly common in the 362 Web environment in technologies such (BrowserID, Federated Google 363 Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often 364 provided as a side effect service of a user's ordinary accounts with 365 some service. In this example, we show Alice and Bob using a 366 separate identity service, though the identity service may be the 367 same entity as the calling service or there may be no identity 368 service at all. 370 Alice is logged onto the calling service and decides to call Bob. She 371 can see from the calling service that he is online and the calling 372 service presents a JS UI in the form of a button next to Bob's name 373 which says "Call". Alice clicks the button, which initiates a JS 374 callback that instantiates a PeerConnection object. This does not 375 require a security check: JS from any origin is allowed to get this 376 far. 378 Once the PeerConnection is created, the calling service JS needs to 379 set up some media. Because this is an audio/video call, it creates a 380 MediaStream with two MediaStreamTracks, one connected to an audio 381 input and one connected to a video input. At this point the first 382 security check is required: untrusted origins are not allowed to 383 access the camera and microphone, so the browser prompts Alice for 384 permission. 386 In the current W3C API, once some streams have been added, Alice's 387 browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep] 388 containing: 390 o Media channel information 391 o Interactive Connectivity Establishment (ICE) [RFC5245] candidates 392 o A fingerprint attribute binding the communication to a key pair 393 [RFC5763]. Note that this key may simply be ephemerally generated 394 for this call or specific to this domain, and Alice may have a 395 large number of such keys. 397 Prior to sending out the signaling message, the PeerConnection code 398 contacts the identity service and obtains an assertion binding 399 Alice's identity to her fingerprint. The exact details depend on the 400 identity service (though as discussed in Section 5.6 PeerConnection 401 can be agnostic to them), but for now it's easiest to think of as a 402 BrowserID assertion. The assertion may bind other information to the 403 identity besides the fingerprint, but at minimum it needs to bind the 404 fingerprint. 406 This message is sent to the signaling server, e.g., by XMLHttpRequest 407 [XmlHttpRequest] or by WebSockets [RFC6455]. preferably over TLS 408 [RFC5246]. The signaling server processes the message from Alice's 409 browser, determines that this is a call to Bob and sends a signaling 410 message to Bob's browser (again, the format is currently undefined). 411 The JS on Bob's browser processes it, and alerts Bob to the incoming 412 call and to Alice's identity. In this case, Alice has provided an 413 identity assertion and so Bob's browser contacts Alice's identity 414 provider (again, this is done in a generic way so the browser has no 415 specific knowledge of the IdP) to verify the assertion. This allows 416 the browser to display a trusted element in the browser chrome 417 indicating that a call is coming in from Alice. If Alice is in Bob's 418 address book, then this interface might also include her real name, a 419 picture, etc. The calling site will also provide some user interface 420 element (e.g., a button) to allow Bob to answer the call, though this 421 is most likely not part of the trusted UI. 423 If Bob agrees a PeerConnection is instantiated with the message from 424 Alice's side. Then, a similar process occurs as on Alice's browser: 425 Bob's browser prompts him for device permission, the media streams 426 are created, and a return signaling message containing media 427 information, ICE candidates, and a fingerprint is sent back to Alice 428 via the signaling service. If Bob has a relationship with an IdP, 429 the message will also come with an identity assertion. 431 At this point, Alice and Bob each know that the other party wants to 432 have a secure call with them. Based purely on the interface provided 433 by the signaling server, they know that the signaling server claims 434 that the call is from Alice to Bob. This level of security is 435 provided merely by having the fingerprint in the message and having 436 that message received securely from the signaling server. Because 437 the far end sent an identity assertion along with their message, they 438 know that this is verifiable from the IdP as well. Note that if the 439 call is federated, as shown in Figure 4 then Alice is able to verify 440 Bob's identity in a way that is not mediated by either her signaling 441 server or Bob's. Rather, she verifies it directly with Bob's IdP. 443 Of course, the call works perfectly well if either Alice or Bob 444 doesn't have a relationship with an IdP; they just get a lower level 445 of assurance. I.e., they simply have whatever information their 446 calling site claims about the caller/calllee's identity. Moreover, 447 Alice might wish to make an anonymous call through an anonymous 448 calling site, in which case she would of course just not provide any 449 identity assertion and the calling site would mask her identity from 450 Bob. 452 4.2. Media Consent Verification 454 As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media 455 consent verification is provided via ICE. Thus, Alice and Bob 456 perform ICE checks with each other. At the completion of these 457 checks, they are ready to send non-ICE data. 459 At this point, Alice knows that (a) Bob (assuming he is verified via 460 his IdP) or someone else who the signaling service is claiming is Bob 461 is willing to exchange traffic with her and (b) that either Bob is at 462 the IP address which she has verified via ICE or there is an attacker 463 who is on-path to that IP address detouring the traffic. Note that 464 it is not possible for an attacker who is on-path between Alice and 465 Bob but not attached to the signaling service to spoof these checks 466 because they do not have the ICE credentials. Bob has the same 467 security guarantees with respect to Alice. 469 4.3. DTLS Handshake 471 Once the ICE checks have completed [more specifically, once some ICE 472 checks have completed], Alice and Bob can set up a secure channel or 473 channels. This is performed via DTLS [RFC4347] (for the data 474 channel) and DTLS-SRTP [RFC5763] keying for SRTP [RFC3711] for the 475 media channel and SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps] 476 for data channels. Specifically, Alice and Bob perform a DTLS 477 handshake on every channel which has been established by ICE. The 478 total number of channels depends on the amount of muxing; in the most 479 likely case we are using both RTP/RTCP mux and muxing multiple media 480 streams on the same channel, in which case there is only one DTLS 481 handshake. Once the DTLS handshake has completed, the keys are 482 exported [RFC5705] and used to key SRTP for the media channels. 484 At this point, Alice and Bob know that they share a set of secure 485 data and/or media channels with keys which are not known to any 486 third-party attacker. If Alice and Bob authenticated via their IdPs, 487 then they also know that the signaling service is not mounting a man- 488 in-the-middle attack on their traffic. Even if they do not use an 489 IdP, as long as they have minimal trust in the signaling service not 490 to perform a man-in-the-middle attack, they know that their 491 communications are secure against the signaling service as well 492 (i.e., that the signaling service cannot mount a passive attack on 493 the communications). 495 4.4. Communications and Consent Freshness 497 From a security perspective, everything from here on in is a little 498 anticlimactic: Alice and Bob exchange data protected by the keys 499 negotiated by DTLS. Because of the security guarantees discussed in 500 the previous sections, they know that the communications are 501 encrypted and authenticated. 503 The one remaining security property we need to establish is "consent 504 freshness", i.e., allowing Alice to verify that Bob is still prepared 505 to receive her communications so that Alice does not continue to send 506 large traffic volumes to entities which went abruptly offline. ICE 507 specifies periodic STUN keepalizes but only if media is not flowing. 508 Because the consent issue is more difficult here, we require RTCWeb 509 implementations to periodically send keepalives. As described in 510 Section 5.3, these keepalives MUST be based on the consent freshness 511 mechanism specified in [I-D.muthu-behave-consent-freshness]. If a 512 keepalive fails and no new ICE channels can be established, then the 513 session is terminated. 515 5. Detailed Technical Description 517 5.1. Origin and Web Security Issues 519 The basic unit of permissions for WebRTC is the origin [RFC6454]. 520 Because the security of the origin depends on being able to 521 authenticate content from that origin, the origin can only be 522 securely established if data is transferred over HTTPS [RFC2818]. 523 Thus, clients MUST treat HTTP and HTTPS origins as different 524 permissions domains. [Note: this follows directly from the origin 525 security model and is stated here merely for clarity.] 527 Many web browsers currently forbid by default any active mixed 528 content on HTTPS pages. That is, when JavaScript is loaded from an 529 HTTP origin onto an HTTPS page, an error is displayed and the HTTP 530 content is not executed unless the user overrides the error. Any 531 browser which enforces such a policy will also not permit access to 532 WebRTC functionality from mixed content pages (because they never 533 display mixed content). Browsers which allow active mixed content 534 MUST nevertheless disable WebRTC functionality in mixed content 535 settings. 537 Note that it is possible for a page which was not mixed content to 538 become mixed content during the duration of the call. The major risk 539 here is that the newly arrived insecure JS might redirect media to a 540 location controlled by the attacker. Implementations MUST either 541 choose to terminate the call or display a warning at that point. 543 5.2. Device Permissions Model 545 Implementations MUST obtain explicit user consent prior to providing 546 access to the camera and/or microphone. Implementations MUST at 547 minimum support the following two permissions models for HTTPS 548 origins. 550 o Requests for one-time camera/microphone access. 551 o Requests for permanent access. 553 Because HTTP origins cannot be securely established against network 554 attackers, implementations MUST NOT allow the setting of permanent 555 access permissions for HTTP origins. Implementations MAY also opt to 556 refuse all permissions grants for HTTP origins, but it is RECOMMENDED 557 that currently they support one-time camera/microphone access. 559 In addition, they SHOULD support requests for access that promise 560 that media from this grant will be sent to a single communicating 561 peer (obviously there could be other requests for other peers). 562 E.g., "Call customerservice@ford.com". The semantics of this request 563 are that the media stream from the camera and microphone will only be 564 routed through a connection which has been cryptographically verified 565 (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP 566 handshake) as being associated with the stated identity. Note that 567 it is unlikely that browsers would have an X.509 certificate, but 568 servers might. Browsers servicing such requests SHOULD clearly 569 indicate that identity to the user when asking for permission. The 570 idea behind this type of permissions is that a user might have a 571 fairly narrow list of peers he is willing to communicate with, e.g., 572 "my mother" rather than "anyone on Facebook". Narrow permissions 573 grants allow the browser to do that enforcement. 575 API Requirement: The API MUST provide a mechanism for the requesting 576 JS to indicate which of these forms of permissions it is 577 requesting. This allows the browser client to know what sort of 578 user interface experience to provide to the user, including what 579 permissions to request from the user and hence what to enforce 580 later. For instance, browsers might display a non-invasive door 581 hanger ("some features of this site may not work..." when asking 582 for long-term permissions) but a more invasive UI ("here is your 583 own video") for single-call permissions. The API MAY grant weaker 584 permissions than the JS asked for if the user chooses to authorize 585 only those permissions, but if it intends to grant stronger ones 586 it SHOULD display the appropriate UI for those permissions and 587 MUST clearly indicate what permissions are being requested. 589 API Requirement: The API MUST provide a mechanism for the requesting 590 JS to relinquish the ability to see or modify the media (e.g., via 591 MediaStream.record()). Combined with secure authentication of the 592 communicating peer, this allows a user to be sure that the calling 593 site is not accessing or modifying their conversion. 595 UI Requirement: The UI MUST clearly indicate when the user's camera 596 and microphone are in use. This indication MUST NOT be 597 suppressable by the JS and MUST clearly indicate how to terminate 598 device access, and provide a UI means to immediately stop camera/ 599 microphone input without the JS being able to prevent it. 601 UI Requirement: If the UI indication of camera/microphone use are 602 displayed in the browser such that minimizing the browser window 603 would hide the indication, or the JS creating an overlapping 604 window would hide the indication, then the browser SHOULD stop 605 camera and microphone input when the indication is hidden. [Note: 606 this may not be necessary in systems that are non-windows-based 607 but that have good notifications support, such as phones.] 609 [[OPEN ISSUE: This section does not have WG consensus. Because 610 screen/application sharing presents a more significant risk than 611 camera and microphone access (see the discussion in 612 [I-D.ietf-rtcweb-security] S 4.1.1), we require a higher level of 613 user consent. 615 o Browsers MUST not permit permanent screen or application sharing 616 permissions to be installed as a response to a JS request for 617 permissions. Instead, they must require some other user action 618 such as a permissions setting or an application install experience 619 to grant permission to a site. 620 o Browsers MUST provide a separate dialog request for screen/ 621 application sharing permissions even if the media request is made 622 at the same time as camera and microphone. 623 o The browser MUST indicate any windows which are currently being 624 shared in some unambiguous way. Windows which are not visible 625 MUST not be shared even if the application is being shared. If 626 the screen is being shared, then that MUST be indicated. 628 -- END OF OPEN ISSUE]] 630 Clients MAY permit the formation of data channels without any direct 631 user approval. Because sites can always tunnel data through the 632 server, further restrictions on the data channel do not provide any 633 additional security. (though see Section 5.3 for a related issue). 635 Implementations which support some form of direct user authentication 636 SHOULD also provide a policy by which a user can authorize calls only 637 to specific communicating peers. Specifically, the implementation 638 SHOULD provide the following interfaces/controls: 640 o Allow future calls to this verified user. 641 o Allow future calls to any verified user who is in my system 642 address book (this only works with address book integration, of 643 course). 645 Implementations SHOULD also provide a different user interface 646 indication when calls are in progress to users whose identities are 647 directly verifiable. Section 5.5 provides more on this. 649 5.3. Communications Consent 651 Browser client implementations of WebRTC MUST implement ICE. Server 652 gateway implementations which operate only at public IP addresses 653 MUST implement either full ICE or ICE-Lite [RFC5245]. 655 Browser implementations MUST verify reachability via ICE prior to 656 sending any non-ICE packets to a given destination. Implementations 657 MUST NOT provide the ICE transaction ID to JavaScript during the 658 lifetime of the transaction (i.e., during the period when the ICE 659 stack would accept a new response for that transaction). The JS MUST 660 NOT be permitted to control the local ufrag and password, though it 661 of course knows it. 663 While continuing consent is required, that ICE [RFC5245]; Section 10 664 keepalives STUN Binding Indications are one-way and therefore not 665 sufficient. The current WG consensus is to use ICE Binding Requests 666 for continuing consent freshness. ICE already requires that 667 implementations respond to such requests, so this approach is 668 maximally compatible. A separate document will profile the ICE 669 timers to be used; see [I-D.muthu-behave-consent-freshness]. 671 5.4. IP Location Privacy 673 A side effect of the default ICE behavior is that the peer learns 674 one's IP address, which leaks large amounts of location information. 675 This has negative privacy consequences in some circumstances. The 676 API requirements in this section are intended to mitigate this issue. 677 Note that these requirements are NOT intended to protect the user's 678 IP address from a malicious site. In general, the site will learn at 679 least a user's server reflexive address from any HTTP transaction. 680 Rather, these requirements are intended to allow a site to cooperate 681 with the user to hide the user's IP address from the other side of 682 the call. Hiding the user's IP address from the server requires some 683 sort of explicit privacy preserving mechanism on the client (e.g., 684 Torbutton [https://www.torproject.org/torbutton/]) and is out of 685 scope for this specification. 687 API Requirement: The API MUST provide a mechanism to allow the JS to 688 suppress ICE negotiation (though perhaps to allow candidate 689 gathering) until the user has decided to answer the call [note: 690 determining when the call has been answered is a question for the 691 JS.] This enables a user to prevent a peer from learning their IP 692 address if they elect not to answer a call and also from learning 693 whether the user is online. 695 API Requirement: The API MUST provide a mechanism for the calling 696 application JS to indicate that only TURN candidates are to be 697 used. This prevents the peer from learning one's IP address at 698 all. This mechanism MUST also permit suppression of the related 699 address field, since that leaks local addresses. 701 API Requirement: The API MUST provide a mechanism for the calling 702 application to reconfigure an existing call to add non-TURN 703 candidates. Taken together, this and the previous requirement 704 allow ICE negotiation to start immediately on incoming call 705 notification, thus reducing post-dial delay, but also to avoid 706 disclosing the user's IP address until they have decided to 707 answer. They also allow users to completely hide their IP address 708 for the duration of the call. Finally, they allow a mechanism for 709 the user to optimize performance by reconfiguring to allow non- 710 turn candidates during an active call if the user decides they no 711 longer need to hide their IP address 713 Note that some enterprises may operate proxies and/or NATs designed 714 to hide internal IP addresses from the outside world. WebRTC 715 provides no explicit mechanism to allow this function. Either such 716 enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or 717 the JS, or there needs to be browser support to set the "TURN-only" 718 policy regardless of the site's preferences. 720 5.5. Communications Security 722 Implementations MUST implement SRTP [RFC3711]. Implementations MUST 723 implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP 724 keying. Implementations MUST implement 725 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 727 All media channels MUST be secured via SRTP. Media traffic MUST NOT 728 be sent over plain (unencrypted) RTP. DTLS-SRTP MUST be offered for 729 every media channel. WebRTC implements MUST NOT offer SDES or select 730 it if offered. 732 All data channels MUST be secured via DTLS. 734 [[OPEN ISSUE: Are these the right cipher suites?]] All 735 implementations MUST implement the following two cipher suites: 736 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and 737 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and the DTLS-SRTP protection 738 profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor 739 cipher suites which support PFS over non-PFS cipher suites. 741 API Requirement: The API MUST provide a mechanism to indicate that a 742 fresh DTLS key pair is to be generated for a specific call. This 743 is intended to allow for unlinkability. Note that there are also 744 settings where it is attractive to use the same keying material 745 repeatedly, especially those with key continuity-based 746 authentication. Unless the user specifically configures an 747 external key pair, different key pairs MUST be used for each 748 origin. (This avoids creating a super-cookie.) 750 API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the 751 JS to obtain the negotiated keying material. This requirement 752 preserves the end-to-end security of the media. 754 UI Requirements: A user-oriented client MUST provide an 755 "inspector" interface which allows the user to determine the 756 security characteristics of the media. 757 The following properties SHOULD be displayed "up-front" in the 758 browser chrome, i.e., without requiring the user to ask for them: 760 * A client MUST provide a user interface through which a user may 761 determine the security characteristics for currently-displayed 762 audio and video stream(s) 763 * A client MUST provide a user interface through which a user may 764 determine the security characteristics for transmissions of 765 their microphone audio and camera video. 766 * The "security characteristics" MUST include an indication as to 767 whether the cryptographic keys were delivered out-of-band (from 768 a server) or were generated as a result of a pairwise 769 negotiation. 770 * If the far endpoint was directly verified, either via a third- 771 party verifiable X.509 certificate or via a Web IdP mechanism 772 (see Section 5.6) the "security characteristics" MUST include 773 the verified information. X.509 identities and Web IdP 774 identities have similar semantics and should be displayed in a 775 similar way. 777 The following properties are more likely to require some "drill- 778 down" from the user: 780 * The "security characteristics" MUST indicate the cryptographic 781 algorithms in use (For example: "AES-CBC" or "Null Cipher".) 782 However, if Null ciphers are used, that MUST be presented to 783 the user at the top-level UI. 784 * The "security characteristics" MUST indicate whether PFS is 785 provided. 786 * The "security characteristics" MUST include some mechanism to 787 allow an out-of-band verification of the peer, such as a 788 certificate fingerprint or an SAS. 790 5.6. Web-Based Peer Authentication 792 In a number of cases, it is desirable for the endpoint (i.e., the 793 browser) to be able to directly identity the endpoint on the other 794 side without trusting only the signaling service to which they are 795 connected. For instance, users may be making a call via a federated 796 system where they wish to get direct authentication of the other 797 side. Alternately, they may be making a call on a site which they 798 minimally trust (such as a poker site) but to someone who has an 799 identity on a site they do trust (such as a social network.) 801 Recently, a number of Web-based identity technologies (OAuth, 802 BrowserID, Facebook Connect), etc. have been developed. While the 803 details vary, what these technologies share is that they have a Web- 804 based (i.e., HTTP/HTTPS) identity provider which attests to your 805 identity. For instance, if I have an account at example.org, I could 806 use the example.org identity provider to prove to others that I was 807 alice@example.org. The development of these technologies allows us 808 to separate calling from identity provision: I could call you on 809 Poker Galaxy but identify myself as alice@example.org. 811 Whatever the underlying technology, the general principle is that the 812 party which is being authenticated is NOT the signaling site but 813 rather the user (and their browser). Similarly, the relying party is 814 the browser and not the signaling site. Thus, the browser MUST 815 securely generate the input to the IdP assertion process and MUST 816 securely display the results of the verification process to the user 817 in a way which cannot be imitated by the calling site. 819 The mechanisms defined in this document do not require the browser to 820 implement any particular identity protocol or to support any 821 particular IdP. Instead, this document provides a generic interface 822 which any IdP can implement. Thus, new IdPs and protocols can be 823 introduced without change to either the browser or the calling 824 service. This avoids the need to make a commitment to any particular 825 identity protocol, although browsers may opt to directly implement 826 some identity protocols in order to provide superior performance or 827 UI properties. 829 5.6.1. Trust Relationships: IdPs, APs, and RPs 831 Any federated identity protocol has three major participants: 833 Authenticating Party (AP): The entity which is trying to establish 834 its identity. 836 Identity Provider (IdP): The entity which is vouching for the AP's 837 identity. 839 Relying Party (RP): The entity which is trying to verify the AP's 840 identity. 842 The AP and the IdP have an account relationship of some kind: the AP 843 registers with the IdP and is able to subsequently authenticate 844 directly to the IdP (e.g., with a password). This means that the 845 browser must somehow know which IdP(s) the user has an account 846 relationship with. This can either be something that the user 847 configures into the browser or that is configured at the calling site 848 and then provided to the PeerConnection by the Web application at the 849 calling site. The use case for having this information configured 850 into the browser is that the user may "log into" the browser to bind 851 it to some identity. This is becoming common in new browsers. 852 However, it should also be possible for the IdP information to simply 853 be provided by the calling application. 855 At a high level there are two kinds of IdPs: 857 Authoritative: IdPs which have verifiable control of some section 858 of the identity space. For instance, in the realm of e-mail, the 859 operator of "example.com" has complete control of the namespace 860 ending in "@example.com". Thus, "alice@example.com" is whoever 861 the operator says it is. Examples of systems with authoritative 862 identity providers include DNSSEC, RFC 4474, and Facebook Connect 863 (Facebook identities only make sense within the context of the 864 Facebook system). 866 Third-Party: IdPs which don't have control of their section of the 867 identity space but instead verify user's identities via some 868 unspecified mechanism and then attest to it. Because the IdP 869 doesn't actually control the namespace, RPs need to trust that the 870 IdP is correctly verifying AP identities, and there can 871 potentially be multiple IdPs attesting to the same section of the 872 identity space. Probably the best-known example of a third-party 873 identity provider is SSL certificates, where there are a large 874 number of CAs all of whom can attest to any domain name. 876 If an AP is authenticating via an authoritative IdP, then the RP does 877 not need to explicitly configure trust in the IdP at all. The 878 identity mechanism can directly verify that the IdP indeed made the 879 relevant identity assertion (a function provided by the mechanisms in 880 this document), and any assertion it makes about an identity for 881 which it is authoritative is directly verifiable. Note that this 882 does not mean that the IdP might not lie, but that is a 883 trustworthiness judgement that the user can make at the time he looks 884 at the identity. 886 By contrast, if an AP is authenticating via a third-party IdP, the RP 887 needs to explicitly trust that IdP (hence the need for an explicit 888 trust anchor list in PKI-based SSL/TLS clients). The list of 889 trustable IdPs needs to be configured directly into the browser, 890 either by the user or potentially by the browser manufacturer. This 891 is a significant advantage of authoritative IdPs and implies that if 892 third-party IdPs are to be supported, the potential number needs to 893 be fairly small. 895 5.6.2. Overview of Operation 897 In order to provide security without trusting the calling site, the 898 PeerConnection component of the browser must interact directly with 899 the IdP. The details of the mechanism are described in the W3C API 900 specification, but the general idea is that the PeerConnection 901 component downloads JS from a specific location on the IdP dictated 902 by the IdP domain name. That JS (the "IdP proxy") runs in an 903 isolated security context within the browser and the PeerConnection 904 talks to it via a secure message passing channel. 906 Note that there are two logically separate functions here: 908 o Identity assertion generation. 909 o Identity assertion verification. 911 The same IdP JS "endpoint" is used for both functions but of course a 912 given IdP might behave differently and load new JS to perform one 913 function or the other. 915 +------------------------------------+ 916 | https://calling-site.example.com | 917 | | 918 | | 919 | | 920 | Calling JS Code | 921 | ^ | 922 | | API Calls | 923 | v | 924 | PeerConnection | 925 | ^ | 926 | | postMessage() | 927 | v | 928 | +-------------------------+ | +---------------+ 929 | | https://idp.example.org | | | | 930 | | |<--------->| Identity | 931 | | IdP JS | | | Provider | 932 | | | | | | 933 | +-------------------------+ | +---------------+ 934 | | 935 +------------------------------------+ 937 When the PeerConnection object wants to interact with the IdP, the 938 sequence of events is as follows: 940 1. The browser (the PeerConnection component) instantiates an IdP 941 proxy with its source at the IdP. This allows the IdP to load 942 whatever JS is necessary into the proxy, which runs in the IdP's 943 security context. 944 2. If the user is not already logged in, the IdP does whatever is 945 required to log them in, such as soliciting a username and 946 password. 947 3. Once the user is logged in, the IdP proxy notifies the browser 948 that it is ready. 949 4. The browser and the IdP proxy communicate via a standardized 950 series of messages delivered via a MessageChannel [WebMessaging]. 951 For instance, the browser might request the IdP proxy to sign or 952 verify a given identity assertion. 954 This approach allows us to decouple the browser from any particular 955 identity provider; the browser need only know how to load the IdP's 956 JavaScript--which is deterministic from the IdP's identity--and the 957 generic protocol for requesting and verifying assertions. The IdP 958 provides whatever logic is necessary to bridge the generic protocol 959 to the IdP's specific requirements. Thus, a single browser can 960 support any number of identity protocols, including being forward 961 compatible with IdPs which did not exist at the time the browser was 962 written. 964 5.6.3. Items for Standardization 966 In order to make this work, we must standardize the following items: 968 o The precise information from the signaling message that must be 969 cryptographically bound to the user's identity and a mechanism for 970 carrying assertions in JSEP messages. Section 5.6.4 971 o The interface to the IdP. Section 5.6.5 specifies a specific 972 protocol mechanism which allows the use of any identity protocol 973 without requiring specific further protocol support in the browser 974 o The JavaScript interfaces which the calling application can use to 975 specify the IdP to use to generate assertions and to discover what 976 assertions were received. 978 The first two items are defined in this document. The final one is 979 defined in the companion W3C WebRTC API specification [webrtc-api]. 981 5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions 983 5.6.4.1. Input to Assertion Generation Process 985 An identity assertion binds the user's identity (as asserted by the 986 IdP) to the JSEP offer/exchange transaction and specifically to the 987 media. In order to achieve this, the PeerConnection must provide the 988 DTLS-SRTP fingerprint to be bound to the identity. This is provided 989 as a JavaScript object (also known as a dictionary or hash) with a 990 single "fingerprint" key, as shown below: 992 { 993 "fingerprint": { 994 "algorithm": "sha-256", 995 "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" 996 } 997 } 999 This object is encoded in a JSON [RFC4627] string for passing to the 1000 IdP. 1002 The "algorithm" and "digest" values correspond directly to the 1003 algorithm and digest values in the a=fingerprint line of the SDP. 1004 [RFC4572]. 1006 Note: this structure does not need to be interpreted by the IdP or 1007 the IdP proxy. It is consumed solely by the RP's browser. The IdP 1008 merely treats it as an opaque value to be attested to. Thus, new 1009 parameters can be added to the assertion without modifying the IdP. 1011 5.6.4.2. Carrying Identity Assertions 1013 Once an IdP has generated an assertion, it is attached to the SDP 1014 message. This is done by adding a new a-line to the SDP, of the form 1015 a=identity. The sole contents of this value are a base-64 encoded 1016 [RFC4848] identity assertion. For example: 1018 v=0 1019 o=- 1181923068 1181923196 IN IP4 ua1.example.com 1020 s=example1 1021 c=IN IP4 ua1.example.com 1022 a=setup:actpass 1023 a=fingerprint:sha-1 \ 1024 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1025 a=identity:\ 1026 ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n\ 1027 dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v\ 1028 cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs\ 1029 XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg== 1030 t=0 0 1031 m=audio 6056 RTP/SAVP 0 1032 a=sendrecv 1033 ... 1035 Each identity attribute should be paired (and attests to) with an 1036 "a=fingerprint" attribute and therefore can exist either at the 1037 session or media level. Multiple identity attributes may appear at 1038 either level, though it is RECOMMENDED that implementations not do 1039 this, because it becomes very unclear what security claim that they 1040 are making and the UI guidelines above become unclear. Browsers MAY 1041 choose refuse to display any identity indicators in the face of 1042 multiple identity attributes with different identities but SHOULD 1043 process multiple attributes with the same identity as described 1044 above. 1046 TODO: write up paragraph on the consequences of multiple 1047 a=fingerprint attributes. 1049 5.6.5. IdP Interaction Details 1051 5.6.5.1. General Message Structure 1053 Messages between the PeerConnection object and the IdP proxy are 1054 JavaScript objects, shown in examples using JSON [RFC4627]. For 1055 instance, the PeerConnection would request a signature with the 1056 following "SIGN" message: 1058 { 1059 "type": "SIGN", 1060 "id": "1", 1061 "origin": "https://calling-site.example.com", 1062 "message": "012345678abcdefghijkl" 1063 } 1065 All messages MUST contain a "type" field which indicates the general 1066 meaning of the message. 1068 All requests from the PeerConnection object MUST contain an "id" 1069 field which MUST be unique within the scope of the interaction 1070 between the browser and the IdP instance. Responses from the IdP 1071 proxy MUST contain the same "id" in response, which allows the 1072 PeerConnection to correlate requests and responses, in case there are 1073 multiple requests/responses outstanding to the same proxy. 1075 All requests from the PeerConnection object MUST contain an "origin" 1076 field containing the origin of the JS which initiated the PC (i.e., 1077 the URL of the calling site). This origin value can be used by the 1078 IdP to make access control decisions. For instance, an IdP might 1079 only issue identity assertions for certain calling services in the 1080 same way that some IdPs require that relying Web sites have an API 1081 key before learning user identity. 1083 Any message-specific data is carried in a "message" field. Depending 1084 on the message type, this may either be a string or any JavaScript 1085 object that can be conveyed in a message channel. This includes any 1086 object that is able to be serialized to JSON. 1088 5.6.5.2. Errors 1090 If an error occurs, the IdP sends a message of type "ERROR". The 1091 message MAY have an "error" field containing freeform text data which 1092 containing additional information about what happened. For instance: 1094 { 1095 "type": "ERROR", 1096 "id": "1", 1097 "error": "Signature verification failed" 1098 } 1100 Figure 5: Example error 1102 5.6.5.3. IdP Proxy Setup 1104 In order to perform an identity transaction, the PeerConnection must 1105 first create an IdP proxy. While the details of this are specified 1106 in the W3C API document, from the perspective of this specification, 1107 however, the relevant facts are: 1109 o The JS runs in the IdP's security context with the base page 1110 retrieved from the URL specified in Section 5.6.5.3.1. 1111 o The usual browser sandbox isolation mechanisms MUST be enforced 1112 with respect to the IdP proxy. The IdP cannot be provided with 1113 escalated privileges. 1114 o JS running in the IdP proxy MUST be able to send and receive 1115 messages to the PeerConnection and the PC and IdP proxy are able 1116 to verify the source and destination of these messages. 1117 o The IdP proxy is unable to interact with the user. This includes 1118 the creation of popup windows and dialogs. 1120 Initially the IdP proxy is in an unready state; the IdP JS must be 1121 loaded and there may be several round trips to the IdP server to load 1122 and prepare necessary resources. 1124 When the IdP proxy is ready to receive commands, it delivers a 1125 "READY" message. As this message is unsolicited, it contains only 1126 the "type": 1128 { "type":"READY" } 1130 Once the PeerConnection object receives the ready message, it can 1131 send commands to the IdP proxy. 1133 5.6.5.3.1. Determining the IdP URI 1135 In order to ensure that the IdP is under control of the domain owner 1136 rather than someone who merely has an account on the domain owner's 1137 server (e.g., in shared hosting scenarios), the IdP JavaScript is 1138 hosted at a deterministic location based on the IdP's domain name. 1139 Each IdP proxy instance is associated with two values: 1141 domain name: The IdP's domain name 1142 protocol: The specific IdP protocol which the IdP is using. This is 1143 a completely IdP-specific string, but allows an IdP to implement 1144 two protocols in parallel. This value may be the empty string. 1146 Each IdP MUST serve its initial entry page (i.e., the one loaded by 1147 the IdP proxy) from a well-known URI [RFC5785]. The well-known URI 1148 for an IdP proxy is formed from the following URI components: 1149 1. The scheme, "https:". An IdP MUST be loaded using HTTPS 1150 [RFC2818]. 1151 2. The authority, which is the IdP domain name. The authority MAY 1152 contain a non-default port number. Any port number is removed 1153 when determining if an asserted identity matches the name of the 1154 IdP. The authority MUST NOT include a userinfo sub-component. 1155 3. The path, starting with "/.well-known/idp-proxy/" and appended 1156 with the IdP protocol. Note that the separator characters '/' 1157 (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, 1158 lest an attacker be able to direct requests outside of the 1159 controlled "/.well-known/" prefix. Query and fragment values MAY 1160 be used by including '?' or '#' characters. 1161 For example, for the IdP "identity.example.com" and the protocol 1162 "example", the URL would be: 1164 https://example.com/.well-known/idp-proxy/example 1166 5.6.5.3.1.1. Authenticating Party 1168 How an AP determines the appropriate IdP domain is out of scope of 1169 this specification. In general, however, the AP has some actual 1170 account relationship with the IdP, as this identity is what the IdP 1171 is attesting to. Thus, the AP somehow supplies the IdP information 1172 to the browser. Some potential mechanisms include: 1173 o Provided by the user directly. 1174 o Selected from some set of IdPs known to the calling site. E.g., a 1175 button that shows "Authenticate via Facebook Connect" 1177 5.6.5.3.1.2. Relying Party 1179 Unlike the AP, the RP need not have any particular relationship with 1180 the IdP. Rather, it needs to be able to process whatever assertion 1181 is provided by the AP. As the assertion contains the IdP's identity, 1182 the URI can be constructed directly from the assertion, and thus the 1183 RP can directly verify the technical validity of the assertion with 1184 no user interaction. Authoritative assertions need only be 1185 verifiable. Third-party assertions also MUST be verified against 1186 local policy, as described in Section 5.6.5.3.3.1. 1188 5.6.5.3.2. Requesting Assertions 1190 In order to request an assertion, the PeerConnection sends a "SIGN" 1191 message. Aside from the mandatory fields, this message has a 1192 "message" field containing a string. The string contains a JSON- 1193 encoded object containing certificate fingerprints but are treated as 1194 opaque from the perspective of the IdP. 1196 A successful response to a "SIGN" message contains a "message" field 1197 which is a JavaScript dictionary consisting of two fields: 1199 idp: A dictionary containing the domain name of the provider and the 1200 protocol string. 1201 assertion: An opaque value containing the assertion itself. This is 1202 only interpretable by the IdP or its proxy. 1204 Figure 6 shows an example transaction, with the message "abcde..." 1205 (remember, the messages are opaque at this layer) being signed and 1206 bound to identity "ekr@example.org". In this case, the message has 1207 presumably been digitally signed/MACed in some way that the IdP can 1208 later verify it, but this is an implementation detail and out of 1209 scope of this document. Line breaks are inserted solely for 1210 readability. 1212 PeerConnection -> IdP proxy: 1213 { 1214 "type": "SIGN", 1215 "id": "1", 1216 "origin": "https://calling-service.example.com/", 1217 "message": "abcdefghijklmnopqrstuvwyz" 1218 } 1220 IdPProxy -> PeerConnection: 1221 { 1222 "type": "SUCCESS", 1223 "id": "1", 1224 "message": { 1225 "idp":{ 1226 "domain": "example.org" 1227 "protocol": "bogus" 1228 }, 1229 "assertion": "{\"identity\":\"bob@example.org\", 1230 \"contents\":\"abcdefghijklmnopqrstuvwyz\", 1231 \"signature\":\"010203040506\"}" 1232 } 1233 } 1235 Figure 6: Example assertion request 1237 The "message" structure is serialized into JSON, base64-encoded 1238 [RFC4848], and placed in an "a=identity" attribute. 1240 5.6.5.3.3. Verifying Assertions 1242 In order to verify an assertion, an RP sends a "VERIFY" message to 1243 the IdP proxy containing the assertion supplied by the AP in the 1244 "message" field. 1246 The IdP proxy verifies the assertion. Depending on the identity 1247 protocol, the proxy might contact the IdP server or other servers. 1248 For instance, an OAuth-based protocol will likely require using the 1249 IdP as an oracle, whereas with BrowserID the IdP proxy can likely 1250 verify the signature on the assertion without contacting the IdP, 1251 provided that it has cached the IdP's public key. 1253 Regardless of the mechanism, if verification succeeds, a successful 1254 response from the IdP proxy MUST contain a message field consisting 1255 of a object with the following fields: 1257 identity: The identity of the AP from the IdP's perspective. 1258 Details of this are provided in Section 5.6.5.3.3.1. 1259 contents: The original unmodified string provided by the AP in the 1260 original SIGN request. 1262 Figure 7 shows an example transaction. Line breaks are inserted 1263 solely for readability. 1265 PeerConnection -> IdP Proxy: 1266 { 1267 "type": "VERIFY", 1268 "id": 2, 1269 "origin": "https://calling-service.example.com/", 1270 "message": "{\"identity\":\"bob@example.org\", 1271 \"contents\":\"abcdefghijklmnopqrstuvwyz\", 1272 \"signature\":\"010203040506\"}" 1273 } 1275 IdP Proxy -> PeerConnection: 1276 { 1277 "type": "SUCCESS", 1278 "id": 2, 1279 "message": { 1280 "identity": "bob@example.org", 1281 "contents": "abcdefghijklmnopqrstuvwyz" 1282 } 1283 } 1285 Figure 7: Example verification request 1287 5.6.5.3.3.1. Identity Formats 1289 Identities passed from the IdP proxy to the PeerConnection are passed 1290 in the "identity" field. This field MUST consist of a string 1291 representing the user's identity. This string is in the form 1292 "@", where "user" consists of any character except '@', 1293 and domain is an internationalized domain name [RFC5890]. 1295 The PeerConnection API MUST check this string as follows: 1296 1. If the domain portion of the string is equal to the domain name 1297 of the IdP proxy, then the assertion is valid, as the IdP is 1298 authoritative for this domain. Comparison of domain names is 1299 done using the label equivalence rule defined in Section 2.3.2.4 1300 of [RFC5890]. 1301 2. If the domain portion of the string is not equal to the domain 1302 name of the IdP proxy, then the PeerConnection object MUST reject 1303 the assertion unless: 1305 1. the IdP domain is trusted as an acceptable third-party IdP; 1306 and 1307 2. local policy is configured to trust this IdP domain for the 1308 RHS of the identity string. 1310 Sites which have identities that do not fit into the RFC822 style 1311 (for instance, identifiers that are simple numeric values, or values 1312 that contain '@' characters) SHOULD convert them to this form by 1313 escaping illegal characters and appending their IdP domain (e.g., 1314 user%40133@identity.example.com), thus ensuring that they are 1315 authoritative for the identity. 1317 5.7. Security Considerations 1319 Much of the security analysis of this problem is contained in 1320 [I-D.ietf-rtcweb-security] or in the discussion of the particular 1321 issues above. In order to avoid repetition, this section focuses on 1322 (a) residual threats that are not addressed by this document and (b) 1323 threats produced by failure/misbehavior of one of the components in 1324 the system. 1326 5.7.1. Communications Security 1328 While this document favors DTLS-SRTP, it permits a variety of 1329 communications security mechanisms and thus the level of 1330 communications security actually provided varies considerably. Any 1331 pair of implementations which have multiple security mechanisms in 1332 common are subject to being downgraded to the weakest of those common 1333 mechanisms by any attacker who can modify the signaling traffic. If 1334 communications are over HTTP, this means any on-path attacker. If 1335 communications are over HTTPS, this means the signaling server. 1336 Implementations which wish to avoid downgrade attack should only 1337 offer the strongest available mechanism, which is DTLS/DTLS-SRTP. 1338 Note that the implication of this choice will be that interop to non- 1339 DTLS-SRTP devices will need to happen through gateways. 1341 Even if only DTLS/DTLS-SRTP are used, the signaling server can 1342 potentially mount a man-in-the-middle attack unless implementations 1343 have some mechanism for independently verifying keys. The UI 1344 requirements in Section 5.5 are designed to provide such a mechanism 1345 for motivated/security conscious users, but are not suitable for 1346 general use. The identity service mechanisms in Section 5.6 are more 1347 suitable for general use. Note, however, that a malicious signaling 1348 service can strip off any such identity assertions, though it cannot 1349 forge new ones. Note that all of the third-party security mechanisms 1350 available (whether X.509 certificates or a third-party IdP) rely on 1351 the security of the third party--this is of course also true of your 1352 connection to the Web site itself. Users who wish to assure 1353 themselves of security against a malicious identity provider can only 1354 do so by verifying peer credentials directly, e.g., by checking the 1355 peer's fingerprint against a value delivered out of band. 1357 In order to protect against malicious content JavaScript, that 1358 JavaScript MUST NOT be allowed to have direct access to---or perform 1359 computations with---DTLS keys. For instance, if content JS were able 1360 to compute digital signatures, then it would be possible for content 1361 JS to get an identity assertion for a browser's generated key and 1362 then use that assertion plus a signature by the key to authenticate a 1363 call protected under an ephemeral DH key controlled by the content 1364 JS, thus violating the security guarantees otherwise provided by the 1365 IdP mechanism. Note that it is not sufficient merely to deny the 1366 content JS direct access to the keys, as some have suggested doing 1367 with the WebCrypto API. [webcrypto]. The JS must also not be allowed 1368 to perform operations that would be valid for a DTLS endpoint. By 1369 far the safest approach is simply to deny the ability to perform any 1370 operations that depend on secret information associated with the key. 1371 Operations that depend on public information, such as exporting the 1372 public key are of course safe. 1374 5.7.2. Privacy 1376 The requirements in this document are intended to allow: 1378 o Users to participate in calls without revealing their location. 1379 o Potential callees to avoid revealing their location and even 1380 presence status prior to agreeing to answer a call. 1382 However, these privacy protections come at a performance cost in 1383 terms of using TURN relays and, in the latter case, delaying ICE. 1384 Sites SHOULD make users aware of these tradeoffs. 1386 Note that the protections provided here assume a non-malicious 1387 calling service. As the calling service always knows the users 1388 status and (absent the use of a technology like Tor) their IP 1389 address, they can violate the users privacy at will. Users who wish 1390 privacy against the calling sites they are using must use separate 1391 privacy enhancing technologies such as Tor. Combined WebRTC/Tor 1392 implementations SHOULD arrange to route the media as well as the 1393 signaling through Tor. Currently this will produce very suboptimal 1394 performance. 1396 Additionally, any identifier which persists across multiple calls is 1397 potentially a problem for privacy, especially for anonymous calling 1398 services. Such services SHOULD instruct the browser to use separate 1399 DTLS keys for each call and also to use TURN throughout the call. 1400 Otherwise, the other side will learn linkable information. 1402 Additionally, browsers SHOULD implement the privacy-preserving CNAME 1403 generation mode of [I-D.ietf-avtcore-6222bis]. 1405 5.7.3. Denial of Service 1407 The consent mechanisms described in this document are intended to 1408 mitigate denial of service attacks in which an attacker uses clients 1409 to send large amounts of traffic to a victim without the consent of 1410 the victim. While these mechanisms are sufficient to protect victims 1411 who have not implemented WebRTC at all, WebRTC implementations need 1412 to be more careful. 1414 Consider the case of a call center which accepts calls via RTCWeb. 1415 An attacker proxies the call center's front-end and arranges for 1416 multiple clients to initiate calls to the call center. Note that 1417 this requires user consent in many cases but because the data channel 1418 does not need consent, he can use that directly. Since ICE will 1419 complete, browsers can then be induced to send large amounts of data 1420 to the victim call center if it supports the data channel at all. 1421 Preventing this attack requires that automated WebRTC implementations 1422 implement sensible flow control and have the ability to triage out 1423 (i.e., stop responding to ICE probes on) calls which are behaving 1424 badly, and especially to be prepared to remotely throttle the data 1425 channel in the absence of plausible audio and video (which the 1426 attacker cannot control). 1428 Another related attack is for the signaling service to swap the ICE 1429 candidates for the audio and video streams, thus forcing a browser to 1430 send video to the sink that the other victim expects will contain 1431 audio (perhaps it is only expecting audio!) potentially causing 1432 overload. Muxing multiple media flows over a single transport makes 1433 it harder to individually suppress a single flow by denying ICE 1434 keepalives. Either media-level (RTCP) mechanisms must be used or the 1435 implementation must deny responses entirely, thus terminating the 1436 call. 1438 Yet another attack, suggested by Magnus Westerlund, is for the 1439 attacker to cross-connect offers and answers as follows. It induces 1440 the victim to make a call and then uses its control of other users 1441 browsers to get them to attempt a call to someone. It then 1442 translates their offers into apparent answers to the victim, which 1443 looks like large-scale parallel forking. The victim still responds 1444 to ICE responses and now the browsers all try to send media to the 1445 victim. Implementations can defend themselves from this attack by 1446 only responding to ICE Binding Requests for a limited number of 1447 remote ufrags (this is the reason for the requirement that the JS not 1448 be able to control the ufrag and password). 1450 Note that attacks based on confusing one end or the other about 1451 consent are possible even in the face of the third-party identity 1452 mechanism as long as major parts of the signaling messages are not 1453 signed. On the other hand, signing the entire message severely 1454 restricts the capabilities of the calling application, so there are 1455 difficult tradeoffs here. 1457 5.7.4. IdP Authentication Mechanism 1459 This mechanism relies for its security on the IdP and on the 1460 PeerConnection correctly enforcing the security invariants described 1461 above. At a high level, the IdP is attesting that the user 1462 identified in the assertion wishes to be associated with the 1463 assertion. Thus, it must not be possible for arbitrary third parties 1464 to get assertions tied to a user or to produce assertions that RPs 1465 will accept. 1467 5.7.4.1. PeerConnection Origin Check 1469 Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by 1470 the browser, so nothing stops a Web attacker o from creating their 1471 own IFRAME, loading the IdP proxy HTML/JS, and requesting a 1472 signature. In order to prevent this attack, we require that all 1473 signatures be tied to a specific origin ("rtcweb://...") which cannot 1474 be produced by content JavaScript. Thus, while an attacker can 1475 instantiate the IdP proxy, they cannot send messages from an 1476 appropriate origin and so cannot create acceptable assertions. I.e., 1477 the assertion request must have come from the browser. This origin 1478 check is enforced on the relying party side, not on the 1479 authenticating party side. The reason for this is to take the burden 1480 of knowing which origins are valid off of the IdP, thus making this 1481 mechanism extensible to other applications besides WebRTC. The IdP 1482 simply needs to gather the origin information (from the posted 1483 message) and attach it to the assertion. 1485 Note that although this origin check is enforced on the RP side and 1486 not at the IdP, it is absolutely imperative that it be done. The 1487 mechanisms in this document rely on the browser enforcing access 1488 restrictions on the DTLS keys and assertion requests which do not 1489 come with the right origin may be from content JS rather than from 1490 browsers, and therefore those access restrictions cannot be assumed. 1492 Note that this check only asserts that the browser (or some other 1493 entity with access to the user's authentication data) attests to the 1494 request and hence to the fingerprint. It does not demonstrate that 1495 the browser has access to the associated private key. However, 1496 attaching one's identity to a key that the user does not control does 1497 not appear to provide substantial leverage to an attacker, so a proof 1498 of possession is omitted for simplicity. 1500 5.7.4.2. IdP Well-known URI 1502 As described in Section 5.6.5.3.1 the IdP proxy HTML/JS landing page 1503 is located at a well-known URI based on the IdP's domain name. This 1504 requirement prevents an attacker who can write some resources at the 1505 IdP (e.g., on one's Facebook wall) from being able to impersonate the 1506 IdP. 1508 5.7.4.3. Privacy of IdP-generated identities and the hosting site 1510 Depending on the structure of the IdP's assertions, the calling site 1511 may learn the user's identity from the perspective of the IdP. In 1512 many cases this is not an issue because the user is authenticating to 1513 the site via the IdP in any case, for instance when the user has 1514 logged in with Facebook Connect and is then authenticating their call 1515 with a Facebook identity. However, in other case, the user may not 1516 have already revealed their identity to the site. In general, IdPs 1517 SHOULD either verify that the user is willing to have their identity 1518 revealed to the site (e.g., through the usual IdP permissions dialog) 1519 or arrange that the identity information is only available to known 1520 RPs (e.g., social graph adjacencies) but not to the calling site. 1521 The "origin" field of the signature request can be used to check that 1522 the user has agreed to disclose their identity to the calling site; 1523 because it is supplied by the PeerConnection it can be trusted to be 1524 correct. 1526 5.7.4.4. Security of Third-Party IdPs 1528 As discussed above, each third-party IdP represents a new universal 1529 trust point and therefore the number of these IdPs needs to be quite 1530 limited. Most IdPs, even those which issue unqualified identities 1531 such as Facebook, can be recast as authoritative IdPs (e.g., 1532 123456@facebook.com). However, in such cases, the user interface 1533 implications are not entirely desirable. One intermediate approach 1534 is to have special (potentially user configurable) UI for large 1535 authoritative IdPs, thus allowing the user to instantly grasp that 1536 the call is being authenticated by Facebook, Google, etc. 1538 5.7.4.5. Web Security Feature Interactions 1540 A number of optional Web security features have the potential to 1541 cause issues for this mechanism, as discussed below. 1543 5.7.4.5.1. Popup Blocking 1545 If the user is not already logged into the IdP, the IdP proxy may 1546 need to pop up a top level window in order to prompt the user for 1547 their authentication information (it is bad practice to do this in an 1548 IFRAME inside the window because then users have no way to determine 1549 the destination for their password). If the user's browser is 1550 configured to prevent popups, this may fail (depending on the exact 1551 algorithm that the popup blocker uses to suppress popups). It may be 1552 necessary to provide a standardized mechanism to allow the IdP proxy 1553 to request popping of a login window. Note that care must be taken 1554 here to avoid PeerConnection becoming a general escape hatch from 1555 popup blocking. One possibility would be to only allow popups when 1556 the user has explicitly registered a given IdP as one of theirs (this 1557 is only relevant at the AP side in any case). 1559 5.7.4.5.2. Third Party Cookies 1561 Some browsers allow users to block third party cookies (cookies 1562 associated with origins other than the top level page) for privacy 1563 reasons. Any IdP which uses cookies to persist logins will be broken 1564 by third-party cookie blocking. One option is to accept this as a 1565 limitation; another is to have the PeerConnection object disable 1566 third-party cookie blocking for the IdP proxy. 1568 5.8. IANA Considerations 1570 [TODO: IANA registration for Identity header. Or should this be in 1571 MMUSIC?] 1573 6. Acknowledgements 1575 Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen 1576 Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin 1577 Thomson, Magnus Westerland. Matthew Kaufman provided the UI material 1578 in Section 5.5. 1580 7. Changes 1582 7.1. Changes since -06 1584 Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the 1585 IETF WG 1587 Forbade use in mixed content as discussed in Orlando. 1589 Added a requirement to surface NULL ciphers to the top-level. 1591 Tried to clarify SRTP versus DTLS-SRTP. 1593 Added a section on screen sharing permissions. 1595 Assorted editorial work. 1597 7.2. Changes since -05 1599 The following changes have been made since the -05 draft. 1601 o Response to comments from Richard Barnes 1602 o More explanation of the IdP security properties and the federation 1603 use case. 1604 o Editorial cleanup. 1606 7.3. Changes since -03 1608 Version -04 was a version control mistake. Please ignore. 1610 The following changes have been made since the -04 draft. 1612 o Move origin check from IdP to RP per discussion in YVR. 1613 o Clarified treatment of X.509-level identities. 1614 o Editorial cleanup. 1616 7.4. Changes since -03 1618 7.5. Changes since -02 1620 The following changes have been made since the -02 draft. 1622 o Forbid persistent HTTP permissions. 1623 o Clarified the text in S 5.4 to clearly refer to requirements on 1624 the API to provide functionality to the site. 1625 o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp 1626 o Retarget the continuing consent section to assume Binding Requests 1627 o Added some more privacy and linkage text in various places. 1628 o Editorial improvements 1630 8. References 1632 8.1. Normative References 1634 [I-D.ietf-avtcore-6222bis] 1635 Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1636 "Guidelines for Choosing RTP Control Protocol (RTCP) 1637 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 1638 (work in progress), July 2013. 1640 [I-D.ietf-rtcweb-security] 1641 Rescorla, E., "Security Considerations for WebRTC", 1642 draft-ietf-rtcweb-security-06 (work in progress), 1643 January 2014. 1645 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1646 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1647 Encapsulation of SCTP Packets", 1648 draft-ietf-tsvwg-sctp-dtls-encaps-03 (work in progress), 1649 February 2014. 1651 [I-D.muthu-behave-consent-freshness] 1652 Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage 1653 for Consent Freshness", 1654 draft-muthu-behave-consent-freshness-04 (work in 1655 progress), July 2013. 1657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1658 Requirement Levels", BCP 14, RFC 2119, March 1997. 1660 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1662 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1663 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1664 RFC 3711, March 2004. 1666 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1667 Security", RFC 4347, April 2006. 1669 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1670 Transport Layer Security (TLS) Protocol in the Session 1671 Description Protocol (SDP)", RFC 4572, July 2006. 1673 [RFC4627] Crockford, D., "The application/json Media Type for 1674 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1676 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1677 Using URIs and the Dynamic Delegation Discovery Service 1678 (DDDS)", RFC 4848, April 2007. 1680 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1681 (ICE): A Protocol for Network Address Translator (NAT) 1682 Traversal for Offer/Answer Protocols", RFC 5245, 1683 April 2010. 1685 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1686 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1688 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1689 for Establishing a Secure Real-time Transport Protocol 1690 (SRTP) Security Context Using Datagram Transport Layer 1691 Security (DTLS)", RFC 5763, May 2010. 1693 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1694 Security (DTLS) Extension to Establish Keys for the Secure 1695 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1697 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1698 Uniform Resource Identifiers (URIs)", RFC 5785, 1699 April 2010. 1701 [RFC5890] Klensin, J., "Internationalized Domain Names for 1702 Applications (IDNA): Definitions and Document Framework", 1703 RFC 5890, August 2010. 1705 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1706 December 2011. 1708 [WebMessaging] 1709 Hickson, "HTML5 Web Messaging", May 2012, 1710 . 1712 [webcrypto] 1713 Dahl, Sleevi, "Web Cryptography API", June 2013. 1715 Available at http://www.w3.org/TR/WebCryptoAPI/ 1717 [webrtc-api] 1718 Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0: 1719 Real-time Communication Between Browsers", October 2011. 1721 Available at 1722 http://dev.w3.org/2011/webrtc/editor/webrtc.html 1724 8.2. Informative References 1726 [I-D.ietf-rtcweb-jsep] 1727 Uberti, J. and C. Jennings, "Javascript Session 1728 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 1729 in progress), February 2014. 1731 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1732 A., Peterson, J., Sparks, R., Handley, M., and E. 1734 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1735 June 2002. 1737 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1738 Layer Security (TLS)", RFC 5705, March 2010. 1740 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1741 RFC 6455, December 2011. 1743 [XmlHttpRequest] 1744 van Kesteren, A., "XMLHttpRequest Level 2". 1746 Appendix A. Example IdP Bindings to Specific Protocols 1748 [[TODO: These still need some cleanup.]] 1750 This section provides some examples of how the mechanisms described 1751 in this document could be used with existing authentication protocols 1752 such as BrowserID or OAuth. Note that this does not require browser- 1753 level support for either protocol. Rather, the protocols can be fit 1754 into the generic framework. (Though BrowserID in particular works 1755 better with some client side support). 1757 A.1. BrowserID 1759 BrowserID [https://browserid.org/] is a technology which allows a 1760 user with a verified email address to generate an assertion 1761 (authenticated by their identity provider) attesting to their 1762 identity (phrased as an email address). The way that this is used in 1763 practice is that the relying party embeds JS in their site which 1764 talks to the BrowserID code (either hosted on a trusted intermediary 1765 or embedded in the browser). That code generates the assertion which 1766 is passed back to the relying party for verification. The assertion 1767 can be verified directly or with a Web service provided by the 1768 identity provider. It's relatively easy to extend this functionality 1769 to authenticate WebRTC calls, as shown below. 1771 +----------------------+ +----------------------+ 1772 | | | | 1773 | Alice's Browser | | Bob's Browser | 1774 | | OFFER ------------> | | 1775 | Calling JS Code | | Calling JS Code | 1776 | ^ | | ^ | 1777 | | | | | | 1778 | v | | v | 1779 | PeerConnection | | PeerConnection | 1780 | | ^ | | | ^ | 1781 | Finger| |Signed | |Signed | | | 1782 | print | |Finger | |Finger | |"Alice"| 1783 | | |print | |print | | | 1784 | v | | | v | | 1785 | +--------------+ | | +---------------+ | 1786 | | IdP Proxy | | | | IdP Proxy | | 1787 | | to | | | | to | | 1788 | | BrowserID | | | | BrowserID | | 1789 | | Signer | | | | Verifier | | 1790 | +--------------+ | | +---------------+ | 1791 | ^ | | ^ | 1792 +-----------|----------+ +----------|-----------+ 1793 | | 1794 | Get certificate | 1795 v | Check 1796 +----------------------+ | certificate 1797 | | | 1798 | Identity |/-------------------------------+ 1799 | Provider | 1800 | | 1801 +----------------------+ 1803 The way this mechanism works is as follows. On Alice's side, Alice 1804 goes to initiate a call. 1806 1. The calling JS instantiates a PeerConnection and tells it that it 1807 is interested in having it authenticated via BrowserID (i.e., it 1808 provides "browserid.org" as the IdP name.) 1809 2. The PeerConnection instantiates the BrowserID signer in the IdP 1810 proxy 1811 3. The BrowserID signer contacts Alice's identity provider, 1812 authenticating as Alice (likely via a cookie). 1813 4. The identity provider returns a short-term certificate attesting 1814 to Alice's identity and her short-term public key. 1815 5. The Browser-ID code signs the fingerprint and returns the signed 1816 assertion + certificate to the PeerConnection. 1818 6. The PeerConnection returns the signed information to the calling 1819 JS code. 1820 7. The signed assertion gets sent over the wire to Bob's browser 1821 (via the signaling service) as part of the call setup. 1823 The offer might look something like: 1825 { 1826 "type":"OFFER", 1827 "sdp": 1828 "v=0\n 1829 o=- 2890844526 2890842807 IN IP4 192.0.2.1\n 1830 s= \n 1831 c=IN IP4 192.0.2.1\n 1832 t=2873397496 2873404696\n 1833 a=fingerprint:SHA-1 ...\n 1834 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n 1835 a=identity [[base-64 encoding of identity assertion: 1836 { 1837 "idp":{ // Standardized 1838 "domain":"browserid.org", 1839 "method":"default" 1840 }, 1841 // Assertion contents are browserid-specific 1842 "assertion": "{ 1843 \"assertion\": { 1844 \"digest\":\"\", 1845 \"audience\": \"\" 1846 \"valid-until\": 1308859352261, 1847 }, 1848 \"certificate\": { 1849 \"email\": \"rescorla@example.org\", 1850 \"public-key\": \"\", 1851 \"valid-until\": 1308860561861, 1852 \"signature\": \"\" 1853 }, 1854 \"content\": \"\" 1855 }" 1856 } 1857 ]]\n 1858 m=audio 49170 RTP/AVP 0\n 1859 ..." 1860 } 1862 Note that while the IdP here is specified as "browserid.org", the 1863 actual certificate is signed by example.org. This is because 1864 BrowserID is a combined authoritative/third-party system in which 1865 browserid.org delegates the right to be authoritative (what BrowserID 1866 calls primary) to individual domains. 1868 On Bob's side, he receives the signed assertion as part of the call 1869 setup message and a similar procedure happens to verify it. 1871 1. The calling JS instantiates a PeerConnection and provides it the 1872 relevant signaling information, including the signed assertion. 1873 2. The PeerConnection instantiates the IdP proxy which examines the 1874 IdP name and brings up the BrowserID verification code. 1875 3. The BrowserID verifier contacts the identity provider to verify 1876 the certificate and then uses the key to verify the signed 1877 fingerprint. 1878 4. Alice's verified identity is returned to the PeerConnection (it 1879 already has the fingerprint). 1880 5. At this point, Bob's browser can display a trusted UI indication 1881 that Alice is on the other end of the call. 1883 When Bob returns his answer, he follows the converse procedure, which 1884 provides Alice with a signed assertion of Bob's identity and keying 1885 material. 1887 A.2. OAuth 1889 While OAuth is not directly designed for user-to-user authentication, 1890 with a little lateral thinking it can be made to serve. We use the 1891 following mapping of OAuth concepts to WebRTC concepts: 1893 +----------------------+----------------------+ 1894 | OAuth | WebRTC | 1895 +----------------------+----------------------+ 1896 | Client | Relying party | 1897 | Resource owner | Authenticating party | 1898 | Authorization server | Identity service | 1899 | Resource server | Identity service | 1900 +----------------------+----------------------+ 1902 Table 1 1904 The idea here is that when Alice wants to authenticate to Bob (i.e., 1905 for Bob to be aware that she is calling). In order to do this, she 1906 allows Bob to see a resource on the identity provider that is bound 1907 to the call, her identity, and her public key. Then Bob retrieves 1908 the resource from the identity provider, thus verifying the binding 1909 between Alice and the call. 1911 Alice IdP Bob 1912 --------------------------------------------------------- 1913 Call-Id, Fingerprint -------> 1914 <------------------- Auth Code 1915 Auth Code ----------------------------------------------> 1916 <----- Get Token + Auth Code 1917 Token ---------------------> 1918 <------------- Get call-info 1919 Call-Id, Fingerprint ------> 1921 This is a modified version of a common OAuth flow, but omits the 1922 redirects required to have the client point the resource owner to the 1923 IdP, which is acting as both the resource server and the 1924 authorization server, since Alice already has a handle to the IdP. 1926 Above, we have referred to "Alice", but really what we mean is the 1927 PeerConnection. Specifically, the PeerConnection will instantiate an 1928 IFRAME with JS from the IdP and will use that IFRAME to communicate 1929 with the IdP, authenticating with Alice's identity (e.g., cookie). 1930 Similarly, Bob's PeerConnection instantiates an IFRAME to talk to the 1931 IdP. 1933 Author's Address 1935 Eric Rescorla 1936 RTFM, Inc. 1937 2064 Edgewood Drive 1938 Palo Alto, CA 94303 1939 USA 1941 Phone: +1 650 678 2350 1942 Email: ekr@rtfm.com