idnits 2.17.1 draft-ietf-rtcweb-security-arch-19.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2019) is 1754 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-sdp-uks-05 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7918 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track July 7, 2019 5 Expires: January 8, 2020 7 WebRTC Security Architecture 8 draft-ietf-rtcweb-security-arch-19 10 Abstract 12 This document defines the security architecture for WebRTC, a 13 protocol suite intended for use with real-time applications that can 14 be deployed in browsers - "real time communication on the Web". 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 8, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5 66 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Media Consent Verification . . . . . . . . . . . . . . . 10 70 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11 71 4.4. Communications and Consent Freshness . . . . . . . . . . 11 72 5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12 73 5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 74 5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13 75 5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14 76 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14 77 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14 78 6. Detailed Technical Description . . . . . . . . . . . . . . . 14 79 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 80 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 81 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 82 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 83 6.5. Communications Security . . . . . . . . . . . . . . . . . 18 84 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 85 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 86 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 23 87 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 88 7.4. Binding Identity Assertions to JSEP Offer/Answer 89 Transactions . . . . . . . . . . . . . . . . . . . . . . 24 90 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 91 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 92 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 93 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 28 94 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 28 95 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 29 97 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 98 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 30 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 100 9.1. Communications Security . . . . . . . . . . . . . . . . . 31 101 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33 103 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 34 104 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 34 105 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 106 9.4.3. Privacy of IdP-generated identities and the hosting 107 site . . . . . . . . . . . . . . . . . . . . . . . . 35 108 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 35 109 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35 110 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 111 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 36 112 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 36 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 114 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 115 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 116 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 37 117 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37 118 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37 119 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 120 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38 121 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 122 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 123 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38 124 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 125 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 126 13.2. Informative References . . . . . . . . . . . . . . . . . 42 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 129 1. Introduction 131 The Real-Time Communications on the Web (RTCWEB) working group 132 standardized protocols for real-time communications between Web 133 browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The 134 major use cases for WebRTC technology are real-time audio and/or 135 video calls, Web conferencing, and direct data transfer. Unlike most 136 conventional real-time systems, (e.g., SIP-based [RFC3261] soft 137 phones) WebRTC communications are directly controlled by some Web 138 server, via a JavaScript (JS) API as shown in Figure 1. 140 +----------------+ 141 | | 142 | Web Server | 143 | | 144 +----------------+ 145 ^ ^ 146 / \ 147 HTTP / \ HTTP 148 / \ 149 / \ 150 v v 151 JS API JS API 152 +-----------+ +-----------+ 153 | | Media | | 154 | Browser |<---------->| Browser | 155 | | | | 156 +-----------+ +-----------+ 158 Figure 1: A simple WebRTC system 160 A more complicated system might allow for interdomain calling, as 161 shown in Figure 2. The protocol to be used between the domains is 162 not standardized by WebRTC, but given the installed base and the form 163 of the WebRTC API is likely to be something SDP-based like SIP or 164 something like Extensible Messaging and Presence Protocol (XMPP) 165 [RFC6120]. 167 +--------------+ +--------------+ 168 | | SIP,XMPP,...| | 169 | Web Server |<----------->| Web Server | 170 | | | | 171 +--------------+ +--------------+ 172 ^ ^ 173 | | 174 HTTP | | HTTP 175 | | 176 v v 177 JS API JS API 178 +-----------+ +-----------+ 179 | | Media | | 180 | Browser |<---------------->| Browser | 181 | | | | 182 +-----------+ +-----------+ 184 Figure 2: A multidomain WebRTC system 186 This system presents a number of new security challenges, which are 187 analyzed in [I-D.ietf-rtcweb-security]. This document describes a 188 security architecture for WebRTC which addresses the threats and 189 requirements described in that document. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 3. Trust Model 201 The basic assumption of this architecture is that network resources 202 exist in a hierarchy of trust, rooted in the browser, which serves as 203 the user's Trusted Computing Base (TCB). Any security property which 204 the user wishes to have enforced must be ultimately guaranteed by the 205 browser (or transitively by some property the browser verifies). 206 Conversely, if the browser is compromised, then no security 207 guarantees are possible. Note that there are cases (e.g., Internet 208 kiosks) where the user can't really trust the browser that much. In 209 these cases, the level of security provided is limited by how much 210 they trust the browser. 212 Optimally, we would not rely on trust in any entities other than the 213 browser. However, this is unfortunately not possible if we wish to 214 have a functional system. Other network elements fall into two 215 categories: those which can be authenticated by the browser and thus 216 can be granted permissions to access sensitive resources, and those 217 which cannot be authenticated and thus are untrusted. 219 3.1. Authenticated Entities 221 There are two major classes of authenticated entities in the system: 223 o Calling services: Web sites whose origin we can verify (optimally 224 via HTTPS, but in some cases because we are on a topologically 225 restricted network, such as behind a firewall, and can infer 226 authentication from firewall behavior). 228 o Other users: WebRTC peers whose origin we can verify 229 cryptographically (optimally via DTLS-SRTP). 231 Note that merely being authenticated does not make these entities 232 trusted. For instance, just because we can verify that 233 https://www.example.org/ is owned by Dr. Evil does not mean that we 234 can trust Dr. Evil to access our camera and microphone. However, it 235 gives the user an opportunity to determine whether he wishes to trust 236 Dr. Evil or not; after all, if he desires to contact Dr. Evil 237 (perhaps to arrange for ransom payment), it's safe to temporarily 238 give him access to the camera and microphone for the purpose of the 239 call, but he doesn't want Dr. Evil to be able to access his camera 240 and microphone other than during the call. The point here is that we 241 must first identify other elements before we can determine whether 242 and how much to trust them. Additionally, sometimes we need to 243 identify the communicating peer before we know what policies to 244 apply. 246 3.2. Unauthenticated Entities 248 Other than the above entities, we are not generally able to identify 249 other network elements, thus we cannot trust them. This does not 250 mean that it is not possible to have any interaction with them, but 251 it means that we must assume that they will behave maliciously and 252 design a system which is secure even if they do so. 254 4. Overview 256 This section describes a typical WebRTC session and shows how the 257 various security elements interact and what guarantees are provided 258 to the user. The example in this section is a "best case" scenario 259 in which we provide the maximal amount of user authentication and 260 media privacy with the minimal level of trust in the calling service. 261 Simpler versions with lower levels of security are also possible and 262 are noted in the text where applicable. It's also important to 263 recognize the tension between security (or performance) and privacy. 264 The example shown here is aimed towards settings where we are more 265 concerned about secure calling than about privacy, but as we shall 266 see, there are settings where one might wish to make different 267 tradeoffs--this architecture is still compatible with those settings. 269 For the purposes of this example, we assume the topology shown in the 270 figures below. This topology is derived from the topology shown in 271 Figure 1, but separates Alice and Bob's identities from the process 272 of signaling. Specifically, Alice and Bob have relationships with 273 some Identity Provider (IdP) that supports a protocol (such as OpenID 274 Connect) that can be used to demonstrate their identity to other 275 parties. For instance, Alice might have an account with a social 276 network which she can then use to authenticate to other web sites 277 without explicitly having an account with those sites; this is a 278 fairly conventional pattern on the Web. Section 7.1 provides an 279 overview of Identity Providers and the relevant terminology. Alice 280 and Bob might have relationships with different IdPs as well. 282 This separation of identity provision and signaling isn't 283 particularly important in "closed world" cases where Alice and Bob 284 are users on the same social network and have identities based on 285 that domain (Figure 3). However, there are important settings where 286 that is not the case, such as federation (calls from one domain to 287 another; Figure 4) and calling on untrusted sites, such as where two 288 users who have a relationship via a given social network want to call 289 each other on another, untrusted, site, such as a poker site. 291 Note that the servers themselves are also authenticated by an 292 external identity service, the SSL/TLS certificate infrastructure 293 (not shown). As is conventional in the Web, all identities are 294 ultimately rooted in that system. For instance, when an IdP makes an 295 identity assertion, the Relying Party consuming that assertion is 296 able to verify because it is able to connect to the IdP via HTTPS. 298 +----------------+ 299 | | 300 | Signaling | 301 | Server | 302 | | 303 +----------------+ 304 ^ ^ 305 / \ 306 HTTPS / \ HTTPS 307 / \ 308 / \ 309 v v 310 JS API JS API 311 +-----------+ +-----------+ 312 | | Media | | 313 Alice | Browser |<---------->| Browser | Bob 314 | | (DTLS+SRTP)| | 315 +-----------+ +-----------+ 316 ^ ^--+ +--^ ^ 317 | | | | 318 v | | v 319 +-----------+ | | +-----------+ 320 | |<--------+ | | 321 | IdP1 | | | IdP2 | 322 | | +------->| | 323 +-----------+ +-----------+ 325 Figure 3: A call with IdP-based identity 327 Figure 4 shows essentially the same calling scenario but with a call 328 between two separate domains (i.e., a federated case), as in 329 Figure 2. As mentioned above, the domains communicate by some 330 unspecified protocol and providing separate signaling and identity 331 allows for calls to be authenticated regardless of the details of the 332 inter-domain protocol. 334 +----------------+ Unspecified +----------------+ 335 | | protocol | | 336 | Signaling |<----------------->| Signaling | 337 | Server | (SIP, XMPP, ...) | Server | 338 | | | | 339 +----------------+ +----------------+ 340 ^ ^ 341 | | 342 HTTPS | | HTTPS 343 | | 344 | | 345 v v 346 JS API JS API 347 +-----------+ +-----------+ 348 | | Media | | 349 Alice | Browser |<--------------------------->| Browser | Bob 350 | | DTLS+SRTP | | 351 +-----------+ +-----------+ 352 ^ ^--+ +--^ ^ 353 | | | | 354 v | | v 355 +-----------+ | | +-----------+ 356 | |<-------------------------+ | | 357 | IdP1 | | | IdP2 | 358 | | +------------------------>| | 359 +-----------+ +-----------+ 361 Figure 4: A federated call with IdP-based identity 363 4.1. Initial Signaling 365 For simplicity, assume the topology in Figure 3. Alice and Bob are 366 both users of a common calling service; they both have approved the 367 calling service to make calls (we defer the discussion of device 368 access permissions until later). They are both connected to the 369 calling service via HTTPS and so know the origin with some level of 370 confidence. They also have accounts with some identity provider. 371 This sort of identity service is becoming increasingly common in the 372 Web environment (with technologies such as Federated Google Login, 373 Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as 374 a side effect service of a user's ordinary accounts with some 375 service. In this example, we show Alice and Bob using a separate 376 identity service, though the identity service may be the same entity 377 as the calling service or there may be no identity service at all. 379 Alice is logged onto the calling service and decides to call Bob. 380 She can see from the calling service that he is online and the 381 calling service presents a JS UI in the form of a button next to 382 Bob's name which says "Call". Alice clicks the button, which 383 initiates a JS callback that instantiates a PeerConnection object. 384 This does not require a security check: JS from any origin is allowed 385 to get this far. 387 Once the PeerConnection is created, the calling service JS needs to 388 set up some media. Because this is an audio/video call, it creates a 389 MediaStream with two MediaStreamTracks, one connected to an audio 390 input and one connected to a video input. At this point the first 391 security check is required: untrusted origins are not allowed to 392 access the camera and microphone, so the browser prompts Alice for 393 permission. 395 In the current W3C API, once some streams have been added, Alice's 396 browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep] 397 containing: 399 o Media channel information 401 o Interactive Connectivity Establishment (ICE) [RFC8445] candidates 403 o A fingerprint attribute binding the communication to a key pair 404 [RFC5763]. Note that this key may simply be ephemerally generated 405 for this call or specific to this domain, and Alice may have a 406 large number of such keys. 408 Prior to sending out the signaling message, the PeerConnection code 409 contacts the identity service and obtains an assertion binding 410 Alice's identity to her fingerprint. The exact details depend on the 411 identity service (though as discussed in Section 7 PeerConnection can 412 be agnostic to them), but for now it's easiest to think of as an 413 OAuth token. The assertion may bind other information to the 414 identity besides the fingerprint, but at minimum it needs to bind the 415 fingerprint. 417 This message is sent to the signaling server, e.g., by XMLHttpRequest 418 [XmlHttpRequest] or by WebSockets [RFC6455], over TLS [RFC5246]. The 419 signaling server processes the message from Alice's browser, 420 determines that this is a call to Bob and sends a signaling message 421 to Bob's browser (again, the format is currently undefined). The JS 422 on Bob's browser processes it, and alerts Bob to the incoming call 423 and to Alice's identity. In this case, Alice has provided an 424 identity assertion and so Bob's browser contacts Alice's identity 425 provider (again, this is done in a generic way so the browser has no 426 specific knowledge of the IdP) to verify the assertion. It is also 427 possible to have IdPs with which the browser has a specific 428 trustrelationship, as described in Section 7.1. This allows the 429 browser to display a trusted element in the browser chrome indicating 430 that a call is coming in from Alice. If Alice is in Bob's address 431 book, then this interface might also include her real name, a 432 picture, etc. The calling site will also provide some user interface 433 element (e.g., a button) to allow Bob to answer the call, though this 434 is most likely not part of the trusted UI. 436 If Bob agrees a PeerConnection is instantiated with the message from 437 Alice's side. Then, a similar process occurs as on Alice's browser: 438 Bob's browser prompts him for device permission, the media streams 439 are created, and a return signaling message containing media 440 information, ICE candidates, and a fingerprint is sent back to Alice 441 via the signaling service. If Bob has a relationship with an IdP, 442 the message will also come with an identity assertion. 444 At this point, Alice and Bob each know that the other party wants to 445 have a secure call with them. Based purely on the interface provided 446 by the signaling server, they know that the signaling server claims 447 that the call is from Alice to Bob. This level of security is 448 provided merely by having the fingerprint in the message and having 449 that message received securely from the signaling server. Because 450 the far end sent an identity assertion along with their message, they 451 know that this is verifiable from the IdP as well. Note that if the 452 call is federated, as shown in Figure 4 then Alice is able to verify 453 Bob's identity in a way that is not mediated by either her signaling 454 server or Bob's. Rather, she verifies it directly with Bob's IdP. 456 Of course, the call works perfectly well if either Alice or Bob 457 doesn't have a relationship with an IdP; they just get a lower level 458 of assurance. I.e., they simply have whatever information their 459 calling site claims about the caller/callee's identity. Moreover, 460 Alice might wish to make an anonymous call through an anonymous 461 calling site, in which case she would of course just not provide any 462 identity assertion and the calling site would mask her identity from 463 Bob. 465 4.2. Media Consent Verification 467 As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media 468 consent verification is provided via ICE. Thus, Alice and Bob 469 perform ICE checks with each other. At the completion of these 470 checks, they are ready to send non-ICE data. 472 At this point, Alice knows that (a) Bob (assuming he is verified via 473 his IdP) or someone else who the signaling service is claiming is Bob 474 is willing to exchange traffic with her and (b) that either Bob is at 475 the IP address which she has verified via ICE or there is an attacker 476 who is on-path to that IP address detouring the traffic. Note that 477 it is not possible for an attacker who is on-path between Alice and 478 Bob but not attached to the signaling service to spoof these checks 479 because they do not have the ICE credentials. Bob has the same 480 security guarantees with respect to Alice. 482 4.3. DTLS Handshake 484 Once the requisite ICE checks have completed, Alice and Bob can set 485 up a secure channel or channels. This is performed via DTLS 486 [RFC6347] and DTLS-SRTP [RFC5763] keying for SRTP [RFC3711] for the 487 media channel and SCTP over DTLS [RFC8261] for data channels. 488 Specifically, Alice and Bob perform a DTLS handshake on every 489 component which has been established by ICE. The total number of 490 channels depends on the amount of muxing; in the most likely case we 491 are using both RTP/RTCP mux and muxing multiple media streams on the 492 same channel, in which case there is only one DTLS handshake. Once 493 the DTLS handshake has completed, the keys are exported [RFC5705] and 494 used to key SRTP for the media channels. 496 At this point, Alice and Bob know that they share a set of secure 497 data and/or media channels with keys which are not known to any 498 third-party attacker. If Alice and Bob authenticated via their IdPs, 499 then they also know that the signaling service is not mounting a man- 500 in-the-middle attack on their traffic. Even if they do not use an 501 IdP, as long as they have minimal trust in the signaling service not 502 to perform a man-in-the-middle attack, they know that their 503 communications are secure against the signaling service as well 504 (i.e., that the signaling service cannot mount a passive attack on 505 the communications). 507 4.4. Communications and Consent Freshness 509 From a security perspective, everything from here on in is a little 510 anticlimactic: Alice and Bob exchange data protected by the keys 511 negotiated by DTLS. Because of the security guarantees discussed in 512 the previous sections, they know that the communications are 513 encrypted and authenticated. 515 The one remaining security property we need to establish is "consent 516 freshness", i.e., allowing Alice to verify that Bob is still prepared 517 to receive her communications so that Alice does not continue to send 518 large traffic volumes to entities which went abruptly offline. ICE 519 specifies periodic STUN keepalives but only if media is not flowing. 520 Because the consent issue is more difficult here, we require WebRTC 521 implementations to periodically send keepalives. As described in 522 Section 5.3, these keepalives MUST be based on the consent freshness 523 mechanism specified in [RFC7675]. If a keepalive fails and no new 524 ICE channels can be established, then the session is terminated. 526 5. SDP Identity Attribute 528 The SDP 'identity' attribute is a session-level attribute that is 529 used by an endpoint to convey its identity assertion to its peer. 530 The identity assertion value is encoded as Base-64, as described in 531 Section 4 of [RFC4648]. 533 The procedures in this section are based on the assumption that the 534 identity assertion of an endpoint is bound to the fingerprints of the 535 endpoint. This does not preclude the definition of alternative means 536 of binding an assertion to the endpoint, but such means are outside 537 the scope of this specification. 539 The semantics of multiple 'identity' attributes within an offer or 540 answer are undefined. Implementations SHOULD only include a single 541 'identity' attribute in an offer or answer and relying parties MAY 542 elect to ignore all but the first 'identity' attribute. 544 Name: identity 546 Value: identity-assertion 548 Usage Level: session 550 Charset Dependent: no 552 Default Value: N/A 554 Name: identity 556 Syntax: 558 identity-assertion = identity-assertion-value 559 *(SP identity-extension) 560 identity-assertion-value = base64 561 identity-extension = extension-name [ "=" extension-value ] 562 extension-name = token 563 extension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff) 564 ; byte-string from [RFC4566] 566 567 569 Example: 571 a=identity:\ 572 eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ 573 In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ 574 IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ 575 aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 577 Note that long lines in the example are folded to meet the column 578 width constraints of this document; the backslash ("\") at the end of 579 a line, the carriage return that follows, and whitespace shall be ignored. 581 This specification does not define any extensions for the attribute. 583 The identity-assertion value is a JSON [RFC8259] encoded string. The 584 JSON object contains two keys: "assertion" and "idp". The 585 "assertion" key value contains an opaque string that is consumed by 586 the IdP. The "idp" key value contains a dictionary with one or two 587 further values that identify the IdP. See Section 7.6 for more 588 details. 590 5.1. Offer/Answer Considerations 592 This section defines the SDP Offer/Answer [RFC6454] considerations 593 for the SDP 'identity' attribute. 595 Within this section, 'initial offer' refers to the first offer in the 596 SDP session that contains an SDP "identity" attribute. 598 5.1.1. Generating the Initial SDP Offer 600 When an offerer sends an offer, in order to provide its identity 601 assertion to the peer, it includes an 'identity' attribute in the 602 offer. In addition, the offerer includes one or more SDP 603 'fingerprint' attributes. The 'identity' attribute MUST be bound to 604 all the 'fingerprint' attributes in the session description. 606 5.1.2. Generating of SDP Answer 608 If the answerer elects to include an 'identity' attribute, it follows 609 the same steps as those in Section 5.1.1. The answerer can choose to 610 include or omit an 'identity' attribute independently, regardless of 611 whether the offerer did so. 613 5.1.3. Processing an SDP Offer or Answer 615 When an endpoint receives an offer or answer that contains an 616 'identity' attribute, the answerer can use the the attribute 617 information to contact the IdP and verify the identity of the peer. 618 If the identity requires a third-party IdP as described in 619 Section 7.1 then that IdP will need to have been specifically 620 configured. If the identity verification fails, the answerer MUST 621 discard the offer or answer as malformed. 623 5.1.4. Modifying the Session 625 When modifying a session, if the set of fingerprints is unchanged, 626 then the sender MAY send the same 'identity' attribute. In this 627 case, the established identity MUST be applied to existing DTLS 628 connections as well as new connections established using one of those 629 fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 630 requires that each media section use the same set of fingerprints for 631 every media section. If a new identity attribute is received, then 632 the receiver MUST apply that identity to all existing connections. 634 If the set of fingerprints changes, then the sender MUST either send 635 a new 'identity' attribute or none at all. Because a change in 636 fingerprints also causes a new DTLS connection to be established, the 637 receiver MUST discard all previously established identities. 639 6. Detailed Technical Description 641 6.1. Origin and Web Security Issues 643 The basic unit of permissions for WebRTC is the origin [RFC6454]. 644 Because the security of the origin depends on being able to 645 authenticate content from that origin, the origin can only be 646 securely established if data is transferred over HTTPS [RFC2818]. 647 Thus, clients MUST treat HTTP and HTTPS origins as different 648 permissions domains. Note: this follows directly from the origin 649 security model and is stated here merely for clarity. 651 Many web browsers currently forbid by default any active mixed 652 content on HTTPS pages. That is, when JavaScript is loaded from an 653 HTTP origin onto an HTTPS page, an error is displayed and the HTTP 654 content is not executed unless the user overrides the error. Any 655 browser which enforces such a policy will also not permit access to 656 WebRTC functionality from mixed content pages (because they never 657 display mixed content). Browsers which allow active mixed content 658 MUST nevertheless disable WebRTC functionality in mixed content 659 settings. 661 Note that it is possible for a page which was not mixed content to 662 become mixed content during the duration of the call. The major risk 663 here is that the newly arrived insecure JS might redirect media to a 664 location controlled by the attacker. Implementations MUST either 665 choose to terminate the call or display a warning at that point. 667 Also note that the security architecture depends on the keying 668 material not being available to move between origins. But, it is 669 assumed that the identity assertion can be passed to anyone that the 670 page cares to. 672 6.2. Device Permissions Model 674 Implementations MUST obtain explicit user consent prior to providing 675 access to the camera and/or microphone. Implementations MUST at 676 minimum support the following two permissions models for HTTPS 677 origins. 679 o Requests for one-time camera/microphone access. 681 o Requests for permanent access. 683 Because HTTP origins cannot be securely established against network 684 attackers, implementations MUST refuse all permissions grants for 685 HTTP origins. 687 In addition, they SHOULD support requests for access that promise 688 that media from this grant will be sent to a single communicating 689 peer (obviously there could be other requests for other peers), 690 eE.g., "Call customerservice@example.org". The semantics of this 691 request are that the media stream from the camera and microphone will 692 only be routed through a connection which has been cryptographically 693 verified (through the IdP mechanism or an X.509 certificate in the 694 DTLS-SRTP handshake) as being associated with the stated identity. 695 Note that it is unlikely that browsers would have X.509 certificates, 696 but servers might. Browsers servicing such requests SHOULD clearly 697 indicate that identity to the user when asking for permission. The 698 idea behind this type of permissions is that a user might have a 699 fairly narrow list of peers he is willing to communicate with, e.g., 700 "my mother" rather than "anyone on Facebook". Narrow permissions 701 grants allow the browser to do that enforcement. 703 API Requirement: The API MUST provide a mechanism for the requesting 704 JS to relinquish the ability to see or modify the media (e.g., via 705 MediaStream.record()). Combined with secure authentication of the 706 communicating peer, this allows a user to be sure that the calling 707 site is not accessing or modifying their conversion. 709 UI Requirement: The UI MUST clearly indicate when the user's camera 710 and microphone are in use. This indication MUST NOT be 711 suppressable by the JS and MUST clearly indicate how to terminate 712 device access, and provide a UI means to immediately stop camera/ 713 microphone input without the JS being able to prevent it. 715 UI Requirement: If the UI indication of camera/microphone use are 716 displayed in the browser such that minimizing the browser window 717 would hide the indication, or the JS creating an overlapping 718 window would hide the indication, then the browser SHOULD stop 719 camera and microphone input when the indication is hidden. [Note: 720 this may not be necessary in systems that are non-windows-based 721 but that have good notifications support, such as phones.] 723 o Browsers MUST NOT permit permanent screen or application sharing 724 permissions to be installed as a response to a JS request for 725 permissions. Instead, they must require some other user action 726 such as a permissions setting or an application install experience 727 to grant permission to a site. 729 o Browsers MUST provide a separate dialog request for screen/ 730 application sharing permissions even if the media request is made 731 at the same time as camera and microphone. 733 o The browser MUST indicate any windows which are currently being 734 shared in some unambiguous way. Windows which are not visible 735 MUST NOT be shared even if the application is being shared. If 736 the screen is being shared, then that MUST be indicated. 738 Browsers MAY permit the formation of data channels without any direct 739 user approval. Because sites can always tunnel data through the 740 server, further restrictions on the data channel do not provide any 741 additional security. (See Section 6.3 for a related issue). 743 Implementations which support some form of direct user authentication 744 SHOULD also provide a policy by which a user can authorize calls only 745 to specific communicating peers. Specifically, the implementation 746 SHOULD provide the following interfaces/controls: 748 o Allow future calls to this verified user. 750 o Allow future calls to any verified user who is in my system 751 address book (this only works with address book integration, of 752 course). 754 Implementations SHOULD also provide a different user interface 755 indication when calls are in progress to users whose identities are 756 directly verifiable. Section 6.5 provides more on this. 758 6.3. Communications Consent 760 Browser client implementations of WebRTC MUST implement ICE. Server 761 gateway implementations which operate only at public IP addresses 762 MUST implement either full ICE or ICE-Lite [RFC8445]. 764 Browser implementations MUST verify reachability via ICE prior to 765 sending any non-ICE packets to a given destination. Implementations 766 MUST NOT provide the ICE transaction ID to JavaScript during the 767 lifetime of the transaction (i.e., during the period when the ICE 768 stack would accept a new response for that transaction). The JS MUST 769 NOT be permitted to control the local ufrag and password, though it 770 of course knows it. 772 While continuing consent is required, the ICE [RFC8445]; Section 10 773 keepalives use STUN Binding Indications which are one-way and 774 therefore not sufficient. The current WG consensus is to use ICE 775 Binding Requests for continuing consent freshness. ICE already 776 requires that implementations respond to such requests, so this 777 approach is maximally compatible. A separate document will profile 778 the ICE timers to be used; see [RFC7675]. 780 6.4. IP Location Privacy 782 A side effect of the default ICE behavior is that the peer learns 783 one's IP address, which leaks large amounts of location information. 784 This has negative privacy consequences in some circumstances. The 785 API requirements in this section are intended to mitigate this issue. 786 Note that these requirements are not intended to protect the user's 787 IP address from a malicious site. In general, the site will learn at 788 least a user's server reflexive address from any HTTP transaction. 789 Rather, these requirements are intended to allow a site to cooperate 790 with the user to hide the user's IP address from the other side of 791 the call. Hiding the user's IP address from the server requires some 792 sort of explicit privacy preserving mechanism on the client (e.g., 793 Tor Browser [https://www.torproject.org/projects/torbrowser.html.en]) 794 and is out of scope for this specification. 796 API Requirement: The API MUST provide a mechanism to allow the JS to 797 suppress ICE negotiation (though perhaps to allow candidate 798 gathering) until the user has decided to answer the call [note: 799 determining when the call has been answered is a question for the 800 JS.] This enables a user to prevent a peer from learning their IP 801 address if they elect not to answer a call and also from learning 802 whether the user is online. 804 API Requirement: The API MUST provide a mechanism for the calling 805 application JS to indicate that only TURN candidates are to be 806 used. This prevents the peer from learning one's IP address at 807 all. This mechanism MUST also permit suppression of the related 808 address field, since that leaks local addresses. 810 API Requirement: The API MUST provide a mechanism for the calling 811 application to reconfigure an existing call to add non-TURN 812 candidates. Taken together, this and the previous requirement 813 allow ICE negotiation to start immediately on incoming call 814 notification, thus reducing post-dial delay, but also to avoid 815 disclosing the user's IP address until they have decided to 816 answer. They also allow users to completely hide their IP address 817 for the duration of the call. Finally, they allow a mechanism for 818 the user to optimize performance by reconfiguring to allow non- 819 TURN candidates during an active call if the user decides they no 820 longer need to hide their IP address 822 Note that some enterprises may operate proxies and/or NATs designed 823 to hide internal IP addresses from the outside world. WebRTC 824 provides no explicit mechanism to allow this function. Either such 825 enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or 826 the JS, or there needs to be browser support to set the "TURN-only" 827 policy regardless of the site's preferences. 829 6.5. Communications Security 831 Implementations MUST support SRTP [RFC3711]. Implementations MUST 832 support DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP 833 keying. Implementations MUST support SCTP over DTLS [RFC8261]. 835 All media channels MUST be secured via SRTP and SRTCP. Media traffic 836 MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, 837 implementations MUST NOT negotiate cipher suites with NULL encryption 838 modes. DTLS-SRTP MUST be offered for every media channel. WebRTC 839 implementations MUST NOT offer SDP Security Descriptions [RFC4568] or 840 select it if offered. A SRTP MKI MUST NOT be used. 842 All data channels MUST be secured via DTLS. 844 All Implementations MUST support DTLS 1.2 with the 845 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 846 curve [FIPS186]. Earlier drafts of this specification required DTLS 847 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and 848 at the time of this writing some implementations do not support DTLS 849 1.2; endpoints which support only DTLS 1.2 might encounter 850 interoperability issues. The DTLS-SRTP protection profile 851 SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. 852 Implementations MUST favor cipher suites which support (Perfect 853 Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD 854 over non-AEAD cipher suites. 856 Implementations MUST NOT implement DTLS renegotiation and MUST reject 857 it with a "no_renegotiation" alert if offered. 859 Endpoints MUST NOT implement TLS False Start [RFC7918]. 861 API Requirement: The API MUST generate a new authentication key pair 862 for every new call by default. This is intended to allow for 863 unlinkability. 865 API Requirement: The API MUST provide a means to reuse a key pair 866 for calls. This can be used to enable key continuity-based 867 authentication, and could be used to amortize key generation 868 costs. 870 API Requirement: Unless the user specifically configures an external 871 key pair, different key pairs MUST be used for each origin. (This 872 avoids creating a super-cookie.) 874 API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the 875 JS to obtain the negotiated keying material. This requirement 876 preserves the end-to-end security of the media. 878 UI Requirements: A user-oriented client MUST provide an "inspector" 879 interface which allows the user to determine the security 880 characteristics of the media. 882 The following properties SHOULD be displayed "up-front" in the 883 browser chrome, i.e., without requiring the user to ask for them: 885 * A client MUST provide a user interface through which a user may 886 determine the security characteristics for currently-displayed 887 audio and video stream(s) 889 * A client MUST provide a user interface through which a user may 890 determine the security characteristics for transmissions of 891 their microphone audio and camera video. 893 * If the far endpoint was directly verified, either via a third- 894 party verifiable X.509 certificate or via a Web IdP mechanism 895 (see Section 7) the "security characteristics" MUST include the 896 verified information. X.509 identities and Web IdP identities 897 have similar semantics and should be displayed in a similar 898 way. 900 The following properties are more likely to require some "drill- 901 down" from the user: 903 * The "security characteristics" MUST indicate the cryptographic 904 algorithms in use (For example: "AES-CBC".) 906 * The "security characteristics" MUST indicate whether PFS is 907 provided. 909 * The "security characteristics" MUST include some mechanism to 910 allow an out-of-band verification of the peer, such as a 911 certificate fingerprint or a Short Authentication String (SAS). 912 These are compared by the peers to authenticate one another. 914 7. Web-Based Peer Authentication 916 In a number of cases, it is desirable for the endpoint (i.e., the 917 browser) to be able to directly identify the endpoint on the other 918 side without trusting the signaling service to which they are 919 connected. For instance, users may be making a call via a federated 920 system where they wish to get direct authentication of the other 921 side. Alternately, they may be making a call on a site which they 922 minimally trust (such as a poker site) but to someone who has an 923 identity on a site they do trust (such as a social network.) 925 Recently, a number of Web-based identity technologies (OAuth, 926 Facebook Connect etc.) have been developed. While the details vary, 927 what these technologies share is that they have a Web-based (i.e., 928 HTTP/HTTPS) identity provider which attests to Alice's identity. For 929 instance, if Alice has an account at example.org, Alice could use the 930 example.org identity provider to prove to others that Alice is 931 alice@example.org. The development of these technologies allows us 932 to separate calling from identity provision: Alice could call you on 933 a poker site but identify herself as alice@example.org. 935 Whatever the underlying technology, the general principle is that the 936 party which is being authenticated is NOT the signaling site but 937 rather the user (and their browser). Similarly, the relying party is 938 the browser and not the signaling site. Thus, the browser MUST 939 generate the input to the IdP assertion process and display the 940 results of the verification process to the user in a way which cannot 941 be imitated by the calling site. 943 The mechanisms defined in this document do not require the browser to 944 implement any particular identity protocol or to support any 945 particular IdP. Instead, this document provides a generic interface 946 which any IdP can implement. Thus, new IdPs and protocols can be 947 introduced without change to either the browser or the calling 948 service. This avoids the need to make a commitment to any particular 949 identity protocol, although browsers may opt to directly implement 950 some identity protocols in order to provide superior performance or 951 UI properties. 953 7.1. Trust Relationships: IdPs, APs, and RPs 955 Any federated identity protocol has three major participants: 957 Authenticating Party (AP): The entity which is trying to establish 958 its identity. 960 Identity Provider (IdP): The entity which is vouching for the AP's 961 identity. 963 Relying Party (RP): The entity which is trying to verify the AP's 964 identity. 966 The AP and the IdP have an account relationship of some kind: the AP 967 registers with the IdP and is able to subsequently authenticate 968 directly to the IdP (e.g., with a password). This means that the 969 browser must somehow know which IdP(s) the user has an account 970 relationship with. This can either be something that the user 971 configures into the browser or that is configured at the calling site 972 and then provided to the PeerConnection by the Web application at the 973 calling site. The use case for having this information configured 974 into the browser is that the user may "log into" the browser to bind 975 it to some identity. This is becoming common in new browsers. 977 However, it should also be possible for the IdP information to simply 978 be provided by the calling application. 980 At a high level there are two kinds of IdPs: 982 Authoritative: IdPs which have verifiable control of some section 983 of the identity space. For instance, in the realm of e-mail, the 984 operator of "example.com" has complete control of the namespace 985 ending in "@example.com". Thus, "alice@example.com" is whoever 986 the operator says it is. Examples of systems with authoritative 987 identity providers include DNSSEC, RFC 4474, and Facebook Connect 988 (Facebook identities only make sense within the context of the 989 Facebook system). 991 Third-Party: IdPs which don't have control of their section of the 992 identity space but instead verify user's identities via some 993 unspecified mechanism and then attest to it. Because the IdP 994 doesn't actually control the namespace, RPs need to trust that the 995 IdP is correctly verifying AP identities, and there can 996 potentially be multiple IdPs attesting to the same section of the 997 identity space. Probably the best-known example of a third-party 998 identity provider is SSL/TLS certificates, where there are a large 999 number of CAs all of whom can attest to any domain name. 1001 If an AP is authenticating via an authoritative IdP, then the RP does 1002 not need to explicitly configure trust in the IdP at all. The 1003 identity mechanism can directly verify that the IdP indeed made the 1004 relevant identity assertion (a function provided by the mechanisms in 1005 this document), and any assertion it makes about an identity for 1006 which it is authoritative is directly verifiable. Note that this 1007 does not mean that the IdP might not lie, but that is a 1008 trustworthiness judgement that the user can make at the time he looks 1009 at the identity. 1011 By contrast, if an AP is authenticating via a third-party IdP, the RP 1012 needs to explicitly trust that IdP (hence the need for an explicit 1013 trust anchor list in PKI-based SSL/TLS clients). The list of 1014 trustable IdPs needs to be configured directly into the browser, 1015 either by the user or potentially by the browser manufacturer. This 1016 is a significant advantage of authoritative IdPs and implies that if 1017 third-party IdPs are to be supported, the potential number needs to 1018 be fairly small. 1020 7.2. Overview of Operation 1022 In order to provide security without trusting the calling site, the 1023 PeerConnection component of the browser must interact directly with 1024 the IdP. The details of the mechanism are described in the W3C API 1025 specification, but the general idea is that the PeerConnection 1026 component downloads JS from a specific location on the IdP dictated 1027 by the IdP domain name. That JS (the "IdP proxy") runs in an 1028 isolated security context within the browser and the PeerConnection 1029 talks to it via a secure message passing channel. 1031 Note that there are two logically separate functions here: 1033 o Identity assertion generation. 1035 o Identity assertion verification. 1037 The same IdP JS "endpoint" is used for both functions but of course a 1038 given IdP might behave differently and load new JS to perform one 1039 function or the other. 1041 +--------------------------------------+ 1042 | Browser | 1043 | | 1044 | +----------------------------------+ | 1045 | | https://calling-site.example.com | | 1046 | | | | 1047 | | Calling JS Code | | 1048 | | ^ | | 1049 | +---------------|------------------+ | 1050 | | API Calls | 1051 | v | 1052 | PeerConnection | 1053 | ^ | 1054 | | API Calls | 1055 | +-----------|-------------+ | +---------------+ 1056 | | v | | | | 1057 | | IdP Proxy |<-------->| Identity | 1058 | | | | | Provider | 1059 | | https://idp.example.org | | | | 1060 | +-------------------------+ | +---------------+ 1061 | | 1062 +--------------------------------------+ 1064 When the PeerConnection object wants to interact with the IdP, the 1065 sequence of events is as follows: 1067 1. The browser (the PeerConnection component) instantiates an IdP 1068 proxy. This allows the IdP to load whatever JS is necessary into 1069 the proxy. The resulting code runs in the IdP's security 1070 context. 1072 2. The IdP registers an object with the browser that conforms to the 1073 API defined in [webrtc-api]. 1075 3. The browser invokes methods on the object registered by the IdP 1076 proxy to create or verify identity assertions. 1078 This approach allows us to decouple the browser from any particular 1079 identity provider; the browser need only know how to load the IdP's 1080 JavaScript--the location of which is determined based on the IdP's 1081 identity--and to call the generic API for requesting and verifying 1082 identity assertions. The IdP provides whatever logic is necessary to 1083 bridge the generic protocol to the IdP's specific requirements. 1084 Thus, a single browser can support any number of identity protocols, 1085 including being forward compatible with IdPs which did not exist at 1086 the time the browser was written. 1088 7.3. Items for Standardization 1090 There are two parts to this work: 1092 o The precise information from the signaling message that must be 1093 cryptographically bound to the user's identity and a mechanism for 1094 carrying assertions in JSEP messages. This is specified in 1095 Section 7.4. 1097 o The interface to the IdP, which is defined in the companion W3C 1098 WebRTC API specification [webrtc-api]. 1100 The WebRTC API specification also defines JavaScript interfaces that 1101 the calling application can use to specify which IdP to use. That 1102 API also provides access to the assertion-generation capability and 1103 the status of the validation process. 1105 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions 1107 An identity assertion binds the user's identity (as asserted by the 1108 IdP) to the SDP offer/answer exchange and specifically to the media. 1109 In order to achieve this, the PeerConnection must provide the DTLS- 1110 SRTP fingerprint to be bound to the identity. This is provided as a 1111 JavaScript object (also known as a dictionary or hash) with a single 1112 "fingerprint" key, as shown below: 1114 { 1115 "fingerprint": 1116 [ 1117 { "algorithm": "sha-256", 1118 "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, 1119 { "algorithm": "sha-1", 1120 "digest": "74:E9:76:C8:19:...:F4:45:6B" } 1121 ] 1122 } 1124 The "fingerprint" value is an array of objects. Each object in the 1125 array contains "algorithm" and "digest" values, which correspond 1126 directly to the algorithm and digest values in the "fingerprint" 1127 attribute of the SDP [RFC8122]. 1129 This object is encoded in a JSON [RFC8259] string for passing to the 1130 IdP. The identity assertion returned by the IdP, which is encoded in 1131 the "identity" attribute, is a JSON object that is encoded as 1132 described in Section 7.4.1. 1134 This structure does not need to be interpreted by the IdP or the IdP 1135 proxy. It is consumed solely by the RP's browser. The IdP merely 1136 treats it as an opaque value to be attested to. Thus, new parameters 1137 can be added to the assertion without modifying the IdP. 1139 7.4.1. Carrying Identity Assertions 1141 Once an IdP has generated an assertion (see Section 7.6), it is 1142 attached to the SDP offer/answer message. This is done by adding a 1143 new 'identity' attribute to the SDP. The sole contents of this value 1144 is the identity assertion. The identity assertion produced by the 1145 IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648] 1146 to produce this string. For example: 1148 v=0 1149 o=- 1181923068 1181923196 IN IP4 ua1.example.com 1150 s=example1 1151 c=IN IP4 ua1.example.com 1152 a=fingerprint:sha-1 \ 1153 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1154 a=identity:\ 1155 eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ 1156 In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ 1157 IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ 1158 aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 1159 a=... 1160 t=0 0 1161 m=audio 6056 RTP/SAVP 0 1162 a=sendrecv 1163 ... 1165 Note that long lines in the example are folded to meet the column 1166 width constraints of this document; the backslash ("\") at the end of 1167 a line, the carriage return that follows, and whitespace shall be ignored. 1169 The 'identity' attribute attests to all "fingerprint" attributes in 1170 the session description. It is therefore a session-level attribute. 1172 Multiple "fingerprint" values can be used to offer alternative 1173 certificates for a peer. The "identity" attribute MUST include all 1174 fingerprint values that are included in "fingerprint" attributes of 1175 the session description. 1177 The RP browser MUST verify that the in-use certificate for a DTLS 1178 connection is in the set of fingerprints returned from the IdP when 1179 verifying an assertion. 1181 7.5. Determining the IdP URI 1183 In order to ensure that the IdP is under control of the domain owner 1184 rather than someone who merely has an account on the domain owner's 1185 server (e.g., in shared hosting scenarios), the IdP JavaScript is 1186 hosted at a deterministic location based on the IdP's domain name. 1187 Each IdP proxy instance is associated with two values: 1189 Authority: The authority [RFC3986] at which the IdP's service is 1190 hosted. 1192 protocol: The specific IdP protocol which the IdP is using. This is 1193 a completely opaque IdP-specific string, but allows an IdP to 1194 implement two protocols in parallel. This value may be the empty 1195 string. If no value for protocol is provided, a value of 1196 "default" is used. 1198 Each IdP MUST serve its initial entry page (i.e., the one loaded by 1199 the IdP proxy) from a well-known URI [RFC5785]. The well-known URI 1200 for an IdP proxy is formed from the following URI components: 1202 1. The scheme, "https:". An IdP MUST be loaded using HTTPS 1203 [RFC2818]. 1205 2. The authority [RFC3986]. As noted above, the authority MAY 1206 contain a non-default port number or userinfo sub-component. 1207 Both are removed when determining if an asserted identity matches 1208 the name of the IdP. 1210 3. The path, starting with "/.well-known/idp-proxy/" and appended 1211 with the IdP protocol. Note that the separator characters '/' 1212 (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, 1213 lest an attacker be able to direct requests outside of the 1214 controlled "/.well-known/" prefix. Query and fragment values MAY 1215 be used by including '?' or '#' characters. 1217 For example, for the IdP "identity.example.com" and the protocol 1218 "example", the URL would be: 1220 https://identity.example.com/.well-known/idp-proxy/example 1222 The IdP MAY redirect requests to this URL, but they MUST retain the 1223 "https" scheme. This changes the effective origin of the IdP, but 1224 not the domain of the identities that the IdP is permitted to assert 1225 and validate. I.e., the IdP is still regarded as authoritative for 1226 the original domain. 1228 7.5.1. Authenticating Party 1230 How an AP determines the appropriate IdP domain is out of scope of 1231 this specification. In general, however, the AP has some actual 1232 account relationship with the IdP, as this identity is what the IdP 1233 is attesting to. Thus, the AP somehow supplies the IdP information 1234 to the browser. Some potential mechanisms include: 1236 o Provided by the user directly. 1238 o Selected from some set of IdPs known to the calling site. E.g., a 1239 button that shows "Authenticate via Facebook Connect" 1241 7.5.2. Relying Party 1243 Unlike the AP, the RP need not have any particular relationship with 1244 the IdP. Rather, it needs to be able to process whatever assertion 1245 is provided by the AP. As the assertion contains the IdP's identity 1246 in the "idp" field of the JSON-encoded object (see Section 7.6), the 1247 URI can be constructed directly from the assertion, and thus the RP 1248 can directly verify the technical validity of the assertion with no 1249 user interaction. Authoritative assertions need only be verifiable. 1250 Third-party assertions also MUST be verified against local policy, as 1251 described in Section 8.1. 1253 7.6. Requesting Assertions 1255 The input to identity assertion is the JSON-encoded object described 1256 in Section 7.4 that contains the set of certificate fingerprints the 1257 browser intends to use. This string is treated as opaque from the 1258 perspective of the IdP. 1260 The browser also identifies the origin that the PeerConnection is run 1261 in, which allows the IdP to make decisions based on who is requesting 1262 the assertion. 1264 An application can optionally provide a user identifier hint when 1265 specifying an IdP. This value is a hint that the IdP can use to 1266 select amongst multiple identities, or to avoid providing assertions 1267 for unwanted identities. The "username" is a string that has no 1268 meaning to any entity other than the IdP, it can contain any data the 1269 IdP needs in order to correctly generate an assertion. 1271 An identity assertion that is successfully provided by the IdP 1272 consists of the following information: 1274 idp: The domain name of an IdP and the protocol string. This MAY 1275 identify a different IdP or protocol from the one that generated 1276 the assertion. 1278 assertion: An opaque value containing the assertion itself. This is 1279 only interpretable by the identified IdP or the IdP code running 1280 in the client. 1282 Figure 5 shows an example assertion formatted as JSON. In this case, 1283 the message has presumably been digitally signed/MACed in some way 1284 that the IdP can later verify it, but this is an implementation 1285 detail and out of scope of this document. 1287 { 1288 "idp":{ 1289 "domain": "example.org", 1290 "protocol": "bogus" 1291 }, 1292 "assertion": "{\"identity\":\"bob@example.org\", 1293 \"contents\":\"abcdefghijklmnopqrstuvwyz\", 1294 \"signature\":\"010203040506\"}" 1295 } 1297 Figure 5: Example assertion 1299 For use in signaling, the assertion is serialized into JSON, 1300 Base64-encoded [RFC4648], and used as the value of the "identity" 1301 attribute. IdPs SHOULD ensure that any assertions they generate 1302 cannot be interpreted in a different context. E.g., they should use 1303 a distinct format or have separate cryptographic keys for assertion 1304 generation and other purposes. Line breaks are inserted solely for 1305 readability. 1307 7.7. Managing User Login 1309 In order to generate an identity assertion, the IdP needs proof of 1310 the user's identity. It is common practice to authenticate users 1311 (using passwords or multi-factor authentication), then use Cookies 1312 [RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges. 1314 The IdP proxy is able to access cookies, HTTP authentication or other 1315 persistent session data because it operates in the security context 1316 of the IdP origin. Therefore, if a user is logged in, the IdP could 1317 have all the information needed to generate an assertion. 1319 An IdP proxy is unable to generate an assertion if the user is not 1320 logged in, or the IdP wants to interact with the user to acquire more 1321 information before generating the assertion. If the IdP wants to 1322 interact with the user before generating an assertion, the IdP proxy 1323 can fail to generate an assertion and instead indicate a URL where 1324 login should proceed. 1326 The application can then load the provided URL to enable the user to 1327 enter credentials. The communication between the application and the 1328 IdP is described in [webrtc-api]. 1330 8. Verifying Assertions 1332 The input to identity validation is the assertion string taken from a 1333 decoded 'identity' attribute. 1335 The IdP proxy verifies the assertion. Depending on the identity 1336 protocol, the proxy might contact the IdP server or other servers. 1337 For instance, an OAuth-based protocol will likely require using the 1338 IdP as an oracle, whereas with a signature-based scheme might be able 1339 to verify the assertion without contacting the IdP, provided that it 1340 has cached the relevant public key. 1342 Regardless of the mechanism, if verification succeeds, a successful 1343 response from the IdP proxy consists of the following information: 1345 identity: The identity of the AP from the IdP's perspective. 1346 Details of this are provided in Section 8.1. 1348 contents: The original unmodified string provided by the AP as input 1349 to the assertion generation process. 1351 Figure 6 shows an example response, which is JSON-formatted. 1353 { 1354 "identity": "bob@example.org", 1355 "contents": "{\"fingerprint\":[ ... ]}" 1356 } 1358 Figure 6: Example verification result 1360 8.1. Identity Formats 1362 The identity provided from the IdP to the RP browser MUST consist of 1363 a string representing the user's identity. This string is in the 1364 form "@", where "user" consists of any character, and 1365 domain is aninternationalized domain name [RFC5890] encoded as a 1366 sequence of U-labels. 1368 The PeerConnection API MUST check this string as follows: 1370 1. If the "domain" portion of the string is equal to the domain name 1371 of the IdP proxy, then the assertion is valid, as the IdP is 1372 authoritative for this domain. Comparison of domain names is 1373 done using the label equivalence rule defined in Section 2.3.2.4 1374 of [RFC5890]. 1376 2. If the "domain" portion of the string is not equal to the domain 1377 name of the IdP proxy, then the PeerConnection object MUST reject 1378 the assertion unless both: 1380 1. the IdP domain is trusted as an acceptable third-party IdP; 1381 and 1383 2. local policy is configured to trust this IdP domain for the 1384 domain portion of the identity string. 1386 Any "@" or "%" characters in the "user" portion of the identity MUST 1387 be escaped according to the "Percent-Encoding" rules defined in 1388 Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT 1389 be percent-encoded. For example, with a "user" of "user@133" and a 1390 "domain" of "identity.example.com", the resulting string will be 1391 encoded as "user%40133@identity.example.com". 1393 Implementations are cautioned to take care when displaying user 1394 identities containing escaped "@" characters. If such characters are 1395 unescaped prior to display, implementations MUST distinguish between 1396 the domain of the IdP proxy and any domain that might be implied by 1397 the portion of the "" portion that appears after the escaped 1398 "@" sign. 1400 9. Security Considerations 1402 Much of the security analysis of this problem is contained in 1403 [I-D.ietf-rtcweb-security] or in the discussion of the particular 1404 issues above. In order to avoid repetition, this section focuses on 1405 (a) residual threats that are not addressed by this document and (b) 1406 threats produced by failure/misbehavior of one of the components in 1407 the system. 1409 9.1. Communications Security 1411 IF HTTPS is not used to secure communications to the signaling 1412 server, and the identity mechanism used in Section 7 is not used, 1413 then any on-path attacker can replace the DTLS-SRTP fingerprints in 1414 the handshake and thus substitute its own identity for that of either 1415 endpoint. 1417 Even if HTTPS is used, the signaling server can potentially mount a 1418 man-in-the-middle attack unless implementations have some mechanism 1419 for independently verifying keys. The UI requirements in Section 6.5 1420 are designed to provide such a mechanism for motivated/security 1421 conscious users, but are not suitable for general use. The identity 1422 service mechanisms in Section 7 are more suitable for general use. 1423 Note, however, that a malicious signaling service can strip off any 1424 such identity assertions, though it cannot forge new ones. Note that 1425 all of the third-party security mechanisms available (whether X.509 1426 certificates or a third-party IdP) rely on the security of the third 1427 party--this is of course also true of the user's connection to the 1428 Web site itself. Users who wish to assure themselves of security 1429 against a malicious identity provider can only do so by verifying 1430 peer credentials directly, e.g., by checking the peer's fingerprint 1431 against a value delivered out of band. 1433 In order to protect against malicious content JavaScript, that 1434 JavaScript MUST NOT be allowed to have direct access to---or perform 1435 computations with---DTLS keys. For instance, if content JS were able 1436 to compute digital signatures, then it would be possible for content 1437 JS to get an identity assertion for a browser's generated key and 1438 then use that assertion plus a signature by the key to authenticate a 1439 call protected under an ephemeral Diffie-Hellman (DH) key controlled 1440 by the content JS, thus violating the security guarantees otherwise 1441 provided by the IdP mechanism. Note that it is not sufficient merely 1442 to deny the content JS direct access to the keys, as some have 1443 suggested doing with the WebCrypto API [webcrypto]. The JS must also 1444 not be allowed to perform operations that would be valid for a DTLS 1445 endpoint. By far the safest approach is simply to deny the ability 1446 to perform any operations that depend on secret information 1447 associated with the key. Operations that depend on public 1448 information, such as exporting the public key are of course safe. 1450 9.2. Privacy 1452 The requirements in this document are intended to allow: 1454 o Users to participate in calls without revealing their location. 1456 o Potential callees to avoid revealing their location and even 1457 presence status prior to agreeing to answer a call. 1459 However, these privacy protections come at a performance cost in 1460 terms of using TURN relays and, in the latter case, delaying ICE. 1461 Sites SHOULD make users aware of these tradeoffs. 1463 Note that the protections provided here assume a non-malicious 1464 calling service. As the calling service always knows the users 1465 status and (absent the use of a technology like Tor) their IP 1466 address, they can violate the users privacy at will. Users who wish 1467 privacy against the calling sites they are using must use separate 1468 privacy enhancing technologies such as Tor. Combined WebRTC/Tor 1469 implementations SHOULD arrange to route the media as well as the 1470 signaling through Tor. Currently this will produce very suboptimal 1471 performance. 1473 Additionally, any identifier which persists across multiple calls is 1474 potentially a problem for privacy, especially for anonymous calling 1475 services. Such services SHOULD instruct the browser to use separate 1476 DTLS keys for each call and also to use TURN throughout the call. 1477 Otherwise, the other side will learn linkable information that would 1478 allow them to correlate the browser across multiple calls. 1479 Additionally, browsers SHOULD implement the privacy-preserving CNAME 1480 generation mode of [RFC7022]. 1482 9.3. Denial of Service 1484 The consent mechanisms described in this document are intended to 1485 mitigate denial of service attacks in which an attacker uses clients 1486 to send large amounts of traffic to a victim without the consent of 1487 the victim. While these mechanisms are sufficient to protect victims 1488 who have not implemented WebRTC at all, WebRTC implementations need 1489 to be more careful. 1491 Consider the case of a call center which accepts calls via WebRTC. 1492 An attacker proxies the call center's front-end and arranges for 1493 multiple clients to initiate calls to the call center. Note that 1494 this requires user consent in many cases but because the data channel 1495 does not need consent, he can use that directly. Since ICE will 1496 complete, browsers can then be induced to send large amounts of data 1497 to the victim call center if it supports the data channel at all. 1498 Preventing this attack requires that automated WebRTC implementations 1499 implement sensible flow control and have the ability to triage out 1500 (i.e., stop responding to ICE probes on) calls which are behaving 1501 badly, and especially to be prepared to remotely throttle the data 1502 channel in the absence of plausible audio and video (which the 1503 attacker cannot control). 1505 Another related attack is for the signaling service to swap the ICE 1506 candidates for the audio and video streams, thus forcing a browser to 1507 send video to the sink that the other victim expects will contain 1508 audio (perhaps it is only expecting audio!) potentially causing 1509 overload. Muxing multiple media flows over a single transport makes 1510 it harder to individually suppress a single flow by denying ICE 1511 keepalives. Either media-level (RTCP) mechanisms must be used or the 1512 implementation must deny responses entirely, thus terminating the 1513 call. 1515 Yet another attack, suggested by Magnus Westerlund, is for the 1516 attacker to cross-connect offers and answers as follows. It induces 1517 the victim to make a call and then uses its control of other users 1518 browsers to get them to attempt a call to someone. It then 1519 translates their offers into apparent answers to the victim, which 1520 looks like large-scale parallel forking. The victim still responds 1521 to ICE responses and now the browsers all try to send media to the 1522 victim. Implementations can defend themselves from this attack by 1523 only responding to ICE Binding Requests for a limited number of 1524 remote ufrags (this is the reason for the requirement that the JS not 1525 be able to control the ufrag and password). 1527 [I-D.ietf-rtcweb-rtp-usage] Section 13 documents a number of 1528 potential RTCP-based DoS attacks and countermeasures. 1530 Note that attacks based on confusing one end or the other about 1531 consent are possible even in the face of the third-party identity 1532 mechanism as long as major parts of the signaling messages are not 1533 signed. On the other hand, signing the entire message severely 1534 restricts the capabilities of the calling application, so there are 1535 difficult tradeoffs here. 1537 9.4. IdP Authentication Mechanism 1539 This mechanism relies for its security on the IdP and on the 1540 PeerConnection correctly enforcing the security invariants described 1541 above. At a high level, the IdP is attesting that the user 1542 identified in the assertion wishes to be associated with the 1543 assertion. Thus, it must not be possible for arbitrary third parties 1544 to get assertions tied to a user or to produce assertions that RPs 1545 will accept. 1547 9.4.1. PeerConnection Origin Check 1549 Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by 1550 the browser, so nothing stops a Web attacker from creating their own 1551 IFRAME, loading the IdP proxy HTML/JS, and requesting a signature 1552 over his own keys rather than those generated in the browser. 1553 However, that proxy would be in the attacker's origin, not the IdP's 1554 origin. Only the browser itself can instantiate a context that (a) 1555 is in the IdP's origin and (b) exposes the correct API surface. 1556 Thus, the IdP proxy on the sender's side MUST ensure that it is 1557 running in the IdP's origin prior to issuing assertions. 1559 Note that this check only asserts that the browser (or some other 1560 entity with access to the user's authentication data) attests to the 1561 request and hence to the fingerprint. It does not demonstrate that 1562 the browser has access to the associated private key, and therefore 1563 an attacker can attach their own identity to another party's keying 1564 material, thus making a call which comes from Alice appear to come 1565 from the attacker. See [I-D.ietf-mmusic-sdp-uks] for defenses 1566 against this form of attack. 1568 9.4.2. IdP Well-known URI 1570 As described in Section 7.5 the IdP proxy HTML/JS landing page is 1571 located at a well-known URI based on the IdP's domain name. This 1572 requirement prevents an attacker who can write some resources at the 1573 IdP (e.g., on one's Facebook wall) from being able to impersonate the 1574 IdP. 1576 9.4.3. Privacy of IdP-generated identities and the hosting site 1578 Depending on the structure of the IdP's assertions, the calling site 1579 may learn the user's identity from the perspective of the IdP. In 1580 many cases this is not an issue because the user is authenticating to 1581 the site via the IdP in any case, for instance when the user has 1582 logged in with Facebook Connect and is then authenticating their call 1583 with a Facebook identity. However, in other case, the user may not 1584 have already revealed their identity to the site. In general, IdPs 1585 SHOULD either verify that the user is willing to have their identity 1586 revealed to the site (e.g., through the usual IdP permissions dialog) 1587 or arrange that the identity information is only available to known 1588 RPs (e.g., social graph adjacencies) but not to the calling site. 1589 The "domain" field of the assertion request can be used to check that 1590 the user has agreed to disclose their identity to the calling site; 1591 because it is supplied by the PeerConnection it can be trusted to be 1592 correct. 1594 9.4.4. Security of Third-Party IdPs 1596 As discussed above, each third-party IdP represents a new universal 1597 trust point and therefore the number of these IdPs needs to be quite 1598 limited. Most IdPs, even those which issue unqualified identities 1599 such as Facebook, can be recast as authoritative IdPs (e.g., 1600 123456@facebook.com). However, in such cases, the user interface 1601 implications are not entirely desirable. One intermediate approach 1602 is to have special (potentially user configurable) UI for large 1603 authoritative IdPs, thus allowing the user to instantly grasp that 1604 the call is being authenticated by Facebook, Google, etc. 1606 9.4.4.1. Confusable Characters 1608 Because a broad range of characters are permitted in identity 1609 strings, it may be possible for attackers to craft identities which 1610 are confusable with other identities (see [RFC6943] for more on this 1611 topic). This is a problem with any identifier space of this type 1612 (e.g., e-mail addresses). Those minting identifers should avoid 1613 mixed scripts and similar confusable characters. Those presenting 1614 these identifiers to a user should consider highlighting cases of 1615 mixed script usage (see [RFC5890], section 4.4). Other best 1616 practices are still in development. 1618 9.4.5. Web Security Feature Interactions 1620 A number of optional Web security features have the potential to 1621 cause issues for this mechanism, as discussed below. 1623 9.4.5.1. Popup Blocking 1625 When popup blocking is in use, the IdP proxy is unable to generate 1626 popup windows, dialogs or any other form of user interactions. This 1627 prevents the IdP proxy from being used to circumvent user 1628 interaction. The "LOGINNEEDED" message allows the IdP proxy to 1629 inform the calling site of a need for user login, providing the 1630 information necessary to satisfy this requirement without resorting 1631 to direct user interaction from the IdP proxy itself. 1633 9.4.5.2. Third Party Cookies 1635 Some browsers allow users to block third party cookies (cookies 1636 associated with origins other than the top level page) for privacy 1637 reasons. Any IdP which uses cookies to persist logins will be broken 1638 by third-party cookie blocking. One option is to accept this as a 1639 limitation; another is to have the PeerConnection object disable 1640 third-party cookie blocking for the IdP proxy. 1642 10. IANA Considerations 1644 This specification defines the "identity" SDP attribute per the 1645 procedures of Section 8.2.4 of [RFC4566]. The required information 1646 for the registration is included here: 1648 Contact Name: IESG (iesg@ietf.org) 1650 Attribute Name: identity 1652 Long Form: identity 1654 Type of Attribute: session-level 1656 Charset Considerations: This attribute is not subject to the charset 1657 attribute. 1659 Purpose: This attribute carries an identity assertion, binding an 1660 identity to the transport-level security session. 1662 Appropriate Values: See Section 5 of RFCXXXX [[Editor Note: This 1663 document.]] 1665 Mux Category: NORMAL. 1667 This section reqisters the "idp-proxy" well-known URI from [RFC5785]. 1669 URI suffix: idp-proxy 1670 Change controller: IETF 1672 11. Acknowledgements 1674 Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen 1675 Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin 1676 Thomson, Magnus Westerland. Matthew Kaufman provided the UI material 1677 in Section 6.5. Christer Holmberg provided the initial version of 1678 Section 5.1. 1680 12. Changes 1682 [RFC Editor: Please remove this section prior to publication.] 1684 12.1. Changes since -15 1686 Rewrite the Identity section in more conventional offer/answer 1687 format. 1689 Clarify rules on changing identities. 1691 12.2. Changes since -11 1693 Update discussion of IdP security model 1695 Replace "domain name" with RFC 3986 Authority 1697 Clean up discussion of how to generate IdP URI. 1699 Remove obsolete text about null cipher suites. 1701 Remove obsolete appendixes about older IdP systems 1703 Require support for ECDSA, PFS, and AEAD 1705 12.3. Changes since -10 1707 Update cipher suite profiles. 1709 Rework IdP interaction based on implementation experience in Firefox. 1711 12.4. Changes since -06 1713 Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the 1714 IETF WG 1716 Forbade use in mixed content as discussed in Orlando. 1718 Added a requirement to surface NULL ciphers to the top-level. 1720 Tried to clarify SRTP versus DTLS-SRTP. 1722 Added a section on screen sharing permissions. 1724 Assorted editorial work. 1726 12.5. Changes since -05 1728 The following changes have been made since the -05 draft. 1730 o Response to comments from Richard Barnes 1732 o More explanation of the IdP security properties and the federation 1733 use case. 1735 o Editorial cleanup. 1737 12.6. Changes since -03 1739 Version -04 was a version control mistake. Please ignore. 1741 The following changes have been made since the -04 draft. 1743 o Move origin check from IdP to RP per discussion in YVR. 1745 o Clarified treatment of X.509-level identities. 1747 o Editorial cleanup. 1749 12.7. Changes since -03 1751 12.8. Changes since -02 1753 The following changes have been made since the -02 draft. 1755 o Forbid persistent HTTP permissions. 1757 o Clarified the text in S 5.4 to clearly refer to requirements on 1758 the API to provide functionality to the site. 1760 o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp 1762 o Retarget the continuing consent section to assume Binding Requests 1764 o Added some more privacy and linkage text in various places. 1766 o Editorial improvements 1768 13. References 1770 13.1. Normative References 1772 [FIPS186] National Institute of Standards and Technology (NIST), 1773 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 1774 2013. 1776 [I-D.ietf-mmusic-sdp-uks] 1777 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 1778 uses of TLS with the Session Description Protocol (SDP)", 1779 draft-ietf-mmusic-sdp-uks-05 (work in progress), June 1780 2019. 1782 [I-D.ietf-rtcweb-jsep] 1783 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 1784 Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 1785 (work in progress), February 2019. 1787 [I-D.ietf-rtcweb-overview] 1788 Alvestrand, H., "Overview: Real Time Protocols for 1789 Browser-based Applications", draft-ietf-rtcweb-overview-19 1790 (work in progress), November 2017. 1792 [I-D.ietf-rtcweb-rtp-usage] 1793 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1794 Communication (WebRTC): Media Transport and Use of RTP", 1795 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 1796 2016. 1798 [I-D.ietf-rtcweb-security] 1799 Rescorla, E., "Security Considerations for WebRTC", draft- 1800 ietf-rtcweb-security-12 (work in progress), July 2019. 1802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1803 Requirement Levels", BCP 14, RFC 2119, 1804 DOI 10.17487/RFC2119, March 1997, 1805 . 1807 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1808 DOI 10.17487/RFC2818, May 2000, 1809 . 1811 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1812 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1813 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1814 . 1816 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1817 Resource Identifier (URI): Generic Syntax", STD 66, 1818 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1819 . 1821 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1822 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1823 July 2006, . 1825 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1826 Description Protocol (SDP) Security Descriptions for Media 1827 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 1828 . 1830 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1831 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1832 . 1834 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1835 (TLS) Protocol Version 1.2", RFC 5246, 1836 DOI 10.17487/RFC5246, August 2008, 1837 . 1839 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1840 for Establishing a Secure Real-time Transport Protocol 1841 (SRTP) Security Context Using Datagram Transport Layer 1842 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1843 2010, . 1845 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1846 Security (DTLS) Extension to Establish Keys for the Secure 1847 Real-time Transport Protocol (SRTP)", RFC 5764, 1848 DOI 10.17487/RFC5764, May 2010, 1849 . 1851 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1852 Uniform Resource Identifiers (URIs)", RFC 5785, 1853 DOI 10.17487/RFC5785, April 2010, 1854 . 1856 [RFC5890] Klensin, J., "Internationalized Domain Names for 1857 Applications (IDNA): Definitions and Document Framework", 1858 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1859 . 1861 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1862 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1863 January 2012, . 1865 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1866 DOI 10.17487/RFC6454, December 2011, 1867 . 1869 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1870 "Guidelines for Choosing RTP Control Protocol (RTCP) 1871 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 1872 September 2013, . 1874 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 1875 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 1876 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 1877 October 2015, . 1879 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1880 Layer Security (TLS) False Start", RFC 7918, 1881 DOI 10.17487/RFC7918, August 2016, 1882 . 1884 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1885 Transport over the Transport Layer Security (TLS) Protocol 1886 in the Session Description Protocol (SDP)", RFC 8122, 1887 DOI 10.17487/RFC8122, March 2017, 1888 . 1890 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1891 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1892 May 2017, . 1894 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1895 Interchange Format", STD 90, RFC 8259, 1896 DOI 10.17487/RFC8259, December 2017, 1897 . 1899 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 1900 "Datagram Transport Layer Security (DTLS) Encapsulation of 1901 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 1902 2017, . 1904 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1905 Connectivity Establishment (ICE): A Protocol for Network 1906 Address Translator (NAT) Traversal", RFC 8445, 1907 DOI 10.17487/RFC8445, July 2018, 1908 . 1910 [webcrypto] 1911 editors, W., "Web Cryptography API", June 2013. 1913 Available at http://www.w3.org/TR/WebCryptoAPI/ 1915 [webrtc-api] 1916 editors, W., "WebRTC 1.0: Real-time Communication Between 1917 Browsers", October 2011. 1919 Available at http://dev.w3.org/2011/webrtc/editor/ 1920 webrtc.html 1922 13.2. Informative References 1924 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1925 A., Peterson, J., Sparks, R., Handley, M., and E. 1926 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1927 DOI 10.17487/RFC3261, June 2002, 1928 . 1930 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1931 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1932 March 2010, . 1934 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1935 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1936 March 2011, . 1938 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1939 DOI 10.17487/RFC6265, April 2011, 1940 . 1942 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1943 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1944 . 1946 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 1947 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 1948 2013, . 1950 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1951 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1952 . 1954 [XmlHttpRequest] 1955 van Kesteren, A., "XMLHttpRequest Level 2", January 2012. 1957 Author's Address 1959 Eric Rescorla 1960 RTFM, Inc. 1961 2064 Edgewood Drive 1962 Palo Alto, CA 94303 1963 USA 1965 Phone: +1 650 678 2350 1966 Email: ekr@rtfm.com