idnits 2.17.1 draft-roach-perc-webrtc-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-02 == Outdated reference: A later version (-12) exists of draft-ietf-perc-dtls-tunnel-00 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-02 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Roach 3 Internet-Draft Mozilla 4 Intended status: Informational March 10, 2017 5 Expires: September 11, 2017 7 Using Privacy Enhanced Real-time Conferencing (PERC) in a WebRTC Context 8 draft-roach-perc-webrtc-00 10 Abstract 12 The Privacy-Enhanced Realtime Conferencing (PERC) architecture 13 defines a system by which multiparty conferences can be handled by a 14 conference server that is "semi-trusted": that is, it is trusted to 15 correctly handle media packets, but it is not trusted with the actual 16 contents of the media streams. In order to use this architecture 17 within WebRTC, we must describe how information is conveyed among 18 various network functions. This document describes the information 19 to be conveyed and how it is transferred. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 11, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Key Distributor Co-Located with Browser . . . . . . . . . 3 60 4.1.1. Conference Establishment . . . . . . . . . . . . . . 5 61 4.1.2. Owner Sends Offer to Conference . . . . . . . . . . . 7 62 4.1.3. Conference Processes Owner Offer . . . . . . . . . . 9 63 4.1.4. Owner Processes Answer . . . . . . . . . . . . . . . 10 64 4.1.5. Owner sets up media connection . . . . . . . . . . . 11 65 4.1.6. Participant Joins Conference . . . . . . . . . . . . 11 66 4.1.7. Conference Processes Participant Offer . . . . . . . 13 67 4.1.8. Participant Processes Answer . . . . . . . . . . . . 14 68 4.1.9. Participant sets up media connection . . . . . . . . 15 69 4.2. Key Distributor Separate From Browser . . . . . . . . . . 16 70 5. New Mechanisms Required . . . . . . . . . . . . . . . . . . . 16 71 5.1. New Key Distributor DOM Object . . . . . . . . . . . . . 16 72 5.2. New "sign" Tunnel Message . . . . . . . . . . . . . . . . 17 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 77 8.2. Informative References . . . . . . . . . . . . . . . . . 18 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 The Privacy-Enhanced Realtime Conferencing (PERC) architecture 83 [I-D.ietf-perc-private-media-framework] defines a system by which 84 multiparty conferences can be handled by a conference server that is 85 "semi-trusted": that is, it is trusted to correctly handle media 86 packets, but it is not trusted with the actual contents of the media 87 streams. In order to use this architecture within WebRTC 88 [W3C.WD-webrtc-20170313], we must describe how information is 89 conveyed among various network functions. This document describes 90 the information to be conveyed and how it is transferred. 92 Note that the current document is a fairly high-level thumbnail 93 sketch of information flow. It will be expanded with further detail 94 once we have consensus on the general direction for the mechanism. 96 2. Terminology 98 This document also uses a number of terms defined in section 2 of 99 [I-D.ietf-perc-private-media-framework]. Of particular note, the 100 definitions for "Media Distributor (MD)" and "Key Distributor (KD)" 101 are provided by that document. 103 3. Goals 105 A key goal of the mechanisms described in this document is that it 106 should work with a minimal set of changes to web browsers that 107 already implement WebRTC. In particular: PERC requires the use of 108 strong identity assertions in order to provide any value whatsoever. 109 WebRTC already contains an identity mechanism 110 [I-D.ietf-rtcweb-security-arch]; we do not seek to introduce a second 111 one. Regarding identity, this document assumes: 113 o From a WebRTC perspective, the remote identity presented to each 114 conference participant will be the identity of the Key Distributor 115 (KD). Whether this is identical to the PeerConnection identity 116 presented by the conference owner is a matter of policy for the 117 conference application. (Note that this is an emergent property 118 of the system rather than a design decision, since the DTLS 119 associations used to key the SRTP terminate at the KD in the PERC 120 architecture.) 122 o The KD will validate the identity of each user as they join the 123 conference. The roster of current users must be available to at 124 least one of the participants through a means that can be trusted 125 as being authentically generated by the KD. 127 We also seek to support a system that allows for the Key Distributor 128 (KD) to be co-located with an endpoint as a primary goal, and for the 129 KD to be located on a dedicated server as an important secondary 130 goal. 132 4. Data Flows 134 4.1. Key Distributor Co-Located with Browser 136 When the KD is co-located with the browser, the browser that serves 137 the role of KD must join the conference before any other media can be 138 exchanged. It is up to the application to determine whether this is 139 simply the first participant to join, or a specific participant who 140 has an administrative relationship with the conference instance. For 141 concision, we will use the term "conference owner" to refer to the 142 browser serving in this role, even though its assignment may be 143 arbitrary. 145 We further posit that browsers that serve as KDs will have specific 146 objects available as part of their Document Object Model (DOM). 147 These objects will give applications the ability to instantiate and 148 control such KDs, but without actually being able to obtain access to 149 the keying material itself. The definition of the interface for such 150 objects is not defined in this document more than necessary. We 151 envision a companion document, submitted to the W3C, to describe this 152 API in detail. 154 The following callflows illustrate the information exchanged among 155 these entities: 157 Identity Service: This is the server that acts as in Identity 158 Provider (IdP), as that term is defined in 159 [I-D.ietf-rtcweb-security-arch]. Note that the Owner and the 160 Participant may use different Identity Services to vouch for their 161 identities. 163 Owner Browser: This is the web browser execution environment for the 164 web browser that is acting as the KD. 166 Owner PeerConnection: This is the RTCPeerConnection object created 167 and used by conferencing web application running in the Owner 168 Browser. It is shown separately from the Owner Browser to clearly 169 indicate those tasks which are performed directly by the 170 RTCPeerConnection without the ability for the conferencing web 171 application to intervene. 173 KD: This is the Key Distributor function created and used by the 174 conferencing web application running in the Owner Browser. It is 175 shown separately from the Owner Browser to clearly indicate those 176 tasks which are performed directly by the Key Distributor without 177 the ability for the conferencing web application to intervene. 179 HTTP Server: This is the HTTP server that handles the signaling for 180 the conference. 182 MD: This is the media distributor that handles the media the 183 conference. Note that the interface between the HTTP Server and 184 the MD is an implementation detail for the developer of the 185 conference server. The messages exchanged between them are 186 intended to illustrate the information required to be exchanged 187 between them to have a properly functioning PERC conference. 189 Participant Browser: This is the web browser execution environment 190 for a web browser that is not acting as the KD. 192 Participant PeerConnection: This is the RTCPeerConnection object 193 created and used by conferencing web application running in the 194 Participant Browser. It is shown separately from the Participant 195 Browser to clearly indicate those tasks which are performed 196 directly by the RTCPeerConnection without the ability for the 197 conferencing web application to intervene. 199 The following sub sections step through an illustrative call flow 200 that demonstrates how the information needed to create a PERC 201 conference in a WebRTC environment is exchanged among the 202 aforementioned functions. The call flows occur in the order shown by 203 these sections - division into sections is done primarily to limit 204 the number of elements in any diagram to no more than four, since the 205 limitations of the internet-draft format makes wider diagrams 206 impossible. 208 4.1.1. Conference Establishment 209 Owner KD HTTP Server MD 210 Browser | | | 211 | | | | 212 | | | | 213 |(1) GET /perc/room-identifier | | 214 |-------------------------------------->| | 215 |(2) 200 OK (with app) | | 216 |<--------------------------------------| | 217 |(3) new KD(); | | | 218 |------------------>| | | 219 |(4) kd.setIdentity(id1); | | 220 |------------------>| | | 221 |(5) kd.getFingerprint(); | | 222 |------------------>| | | 223 |(6) fingerprint | | | 224 |<------------------| | | 225 |(7) POST /start-conf (KD fingerprint) | | 226 |-------------------------------------->| | 227 | | |(8) New Conference | 228 | | | (KD fingerprint)| 229 | | |------------------>| 230 | | |(9) ack | 231 | | |<------------------| 232 |(10) 200 (MD name and port) | | 233 |<--------------------------------------| | 234 |(11) kd.connect(mdName,port) | | 235 |------------------>| | | 236 | |(12) TLS setup | | 237 | |-------------------------------------->| 238 | | | | 239 | |KD checks that MD cert matches name | 240 | | | | 241 | MD checks that the client fingerprint matches | 242 | | | | 243 | |(13) Profiles | | 244 | |<--------------------------------------| 245 |(14) resolve connect promise | | 246 |<------------------| | | 247 | | | | 249 1. The conference owner loads the conference application. Although 250 not required, information sufficient to identify the conference 251 is frequently sent as part of the URL. 253 2. The HTTP server returns the conferencing web application. 255 3. The conferencing web application instantiates a new Key 256 Distributor (KD) object. Upon instantiation, this KD creates a 257 new certificate. 259 4. The conferencing web app sets the owner's identity on the KD. 261 5. The application asks for the certificate's fingerprint... 263 6. ...which the KD provides 265 7. The application initiates the conference, including the KD cert 266 fingerprint as part of the initiation message. 268 8. The HTTP server passes the KD fingerprint along to the Media 269 Distributor (MD). This is used later by the MD to ensure that 270 the correct KD is connecting to it. 272 9. The MD acknowledges creation of a new conference. This 273 acknowledgement contains the hostname and port that the MD is 274 listening on for the KD to connect to. 276 10. The web server responds to the conferencing web app with the 277 hostname of the MD as well as the port it is listening on for 278 the KD to connect. 280 11. The application passes along the MD name and port to the KD 281 object. 283 12. The KD initiates a TLS connection to the MD. This connection 284 uses the protocol defined in [I-D.ietf-perc-dtls-tunnel]. The 285 KD verifies that the certificate presented by the MD matches the 286 name it used to connect to it, and that it chains up to a 287 trusted certificate authority. The MD verifies that the client 288 cert provided by the KD matches the fingerprint that it received 289 earlier from the HTTP server. 291 13. The MD returns its list of supported profiles, as described in 292 [I-D.ietf-perc-dtls-tunnel]. 294 14. The KD object indicates to the conferencing app that the KD-MD 295 connection has been successfully established. 297 4.1.2. Owner Sends Offer to Conference 298 Identity Owner Owner HTTP 299 Service Browser PeerConnection Server 300 | | | | 301 | | | | 302 | |(1) new PC(); | | 303 | |------------------>| | 304 | |(2) setIdentity(id1); | 305 | |------------------>| | 306 | |(3) createOffer(); | | 307 | |------------------>| | 308 |(4) GET /.well-known/idp-proxy/default | | 309 |<--------------------------------------| | 310 |(5) 200 | | | 311 |-------------------------------------->| | 312 |(6) XHR POST /sign (offer) | | 313 |<--------------------------------------| | 314 |(7) 200 (signed offer) | | 315 |-------------------------------------->| | 316 | |(8) resolve createOffer() promise | 317 | |<------------------| | 318 | |(9) POST /perc/offer?room-identifier | 319 | |(with signed offer)| | 320 | |-------------------------------------->| 321 | | | | 323 1. The conferencing web application creates a new WebRTC 324 RTCPeerConnection (PC) object to allow sending and receiving 325 media. 327 2. The conferencing web app sets the owner's identity on the PC... 329 3. ...and requests an offer to be created. 331 4. As described in [I-D.ietf-rtcweb-security-arch], the PC requests 332 the IDP proxy code from the Identity Service... 334 5. ...which it returns. 336 6. Upon being executed, the idp-proxy code sends the offer to the 337 Identity service... 339 7. ...which verifies user's identity, the signs the offer, and 340 returns the signed offer to the PC. 342 8. The PC then returns the signed offer to the conferencing web app. 344 9. The conferencing web app sends the signed offer to the HTTP 345 server to begin establishing the media connection. 347 4.1.3. Conference Processes Owner Offer 349 Identity KD HTTP MD 350 Service Server 351 | | | | 352 | | |(1) signed offer | 353 | | |------------------>| 354 | | | | 355 | |(2) sign(offer, answer) | 356 | |<--------------------------------------| 357 |(3) GET /.well-known/idp-proxy/default | | 358 |<------------------| | | 359 |(4) 200 (with public key) | | 360 |------------------>| | | 361 |(5) GET /.well-known/idp-proxy/default | | 362 |<------------------| | | 363 |(6) 200 | | | 364 |------------------>| | | 365 |(7) XHR POST /sign (MD answer) | | 366 |<------------------| | | 367 |(8) 200 (signed MD answer) | | 368 |------------------>| | | 369 | |(9) signed answer, KD identity | 370 | |-------------------------------------->| 371 | | |(10) signed answer | 372 | | |<------------------| 373 | | | | 375 In this section of the flow, the MD sends generates an answer. It 376 sends this answer to the KD so that it can sign it with an assertion 377 of the KD's identity. It also sends the corresponding offer to the 378 KD so that the KD can validate that the authenticated party who 379 generated the offer is authorized to join the conference, and to 380 allow the KD to add that user to its own notion of the current 381 conference roster. 383 1. The HTTP server sends the signed offer to the MD to allow it to 384 start setting up the media connection. 386 2. The MD creates an answer to the received offer, and sends both 387 offer and answer over the MD-KD tunnel connection. 389 3. Similar to the PC validation procedure described in 390 [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy 391 code from the Identity Service based on the identity in the 392 offer... 394 4. ...which it returns. The KD uses the IDP proxy code to validate 395 the identity of the party that generated the offer. 397 5. Similar to the PC signing procedure described in 398 [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy 399 code from the Identity Service... 401 6. ...which it returns. 403 7. Upon being executed, the idp-proxy code sends the MD answer to 404 the Identity Service... 406 8. ...which verifies KD's identity, the signs the MD answer, and 407 returns the signed MD answer to the KD. 409 9. The KD sends the signed MD answer back to the MD. 411 10. The MD sends the signed answer to the HTTP server. 413 4.1.4. Owner Processes Answer 415 Identity Owner Owner HTTP 416 Service Browser PeerConnection Server 417 | | | | 418 | | | | 419 | | | | 420 | |(1) 200 (signed answer) | 421 | |<--------------------------------------| 422 | |(2) setRemoteDescription(answer) | 423 | |------------------>| | 424 |(3) GET /.well-known/idp-proxy/default | | 425 |<--------------------------------------| | 426 |(4) 200 (with public key) | | 427 |-------------------------------------->| | 428 |PC validates signature with public key from Identity Service 429 | | | | 430 | | | | 432 1. To complete the offer/answer exchange, the HTTP server returns 433 the signed answer (asserting the KD's identity) to the owner's 434 conference web app. 436 2. The conference web app sets the remote description on the PC to 437 the received answer 439 3. Using the identity validation procedure described in 440 [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy 441 code from the Identity Service based on the identity in the 442 answer... 444 4. ...which it returns. The PC uses the IDP proxy code to validate 445 the identity of the party that generated the answer. 447 4.1.5. Owner sets up media connection 449 Note: ICE/ICE Lite is not shown in this flow, but is assumed to have 450 taken place. 452 Owner KD MD 453 PeerConnection 454 | | | 455 | | | 456 |(1) DTLS setup | | 457 |-------------------------------------->| 458 | |(2) Tunnel(DTLS setup) 459 | |<------------------| 460 |(3) Double encrypted media | 461 |.......................................| 462 | | | 463 | | | 465 1. The PC, using the addressing information present in the answer, 466 negotiates a DTLS association towards the MD. We make an 467 assumption that the SDP generated by the MD contains a port 468 number that is unique to the conference, allowing it to correlate 469 the incoming DTLS messages to the correct KD. 471 2. The MD uses the tunneling protocol defined in 472 [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages 473 between the PC and the KD. These DTLS setup messages make use of 474 the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to 475 establish end-to-end keys for the media. 477 3. Using the mechanism described in [I-D.ietf-perc-double], the PC 478 now begins to send and received SRTP-encrypted media to and from 479 the MD. 481 4.1.6. Participant Joins Conference 483 After the conference has been established as described in the 484 preceding sections, each new participant triggers a flow that closely 485 mirrors the owner PC's interaction with the conference. These steps 486 are shown in the following sections. 488 HTTP Participant Participant Identity 489 Server Browser PeerConnection Service 490 | | | | 491 |(1) GET /perc/room-identifier | | 492 |<------------------| | | 493 |(2) 200 OK (with app) | | 494 |------------------>| | | 495 | |(3) new PC(); | | 496 | |------------------>| | 497 | |(4) setIdentity(id2); | 498 | |------------------>| | 499 | |(5) createOffer(); | | 500 | |------------------>| | 501 | | |(6) GET | 502 | | |/.well-known/idp-proxy/default 503 | | |------------------>| 504 | | |(7) 200 | 505 | | |<------------------| 506 | | |(8) XHR POST /sign (offer) 507 | | |------------------>| 508 | | |(9) 200 (signed offer) 509 | | |<------------------| 510 | |(10) resolve createOffer() promise | 511 | |<------------------| | 512 |(11) POST /perc/offer?room-identifier (signed offer) | 513 |<------------------| | | 514 | | | | 516 1. The conference owner loads the conference application. Although 517 not required, information sufficient to identify the conference 518 is frequently sent as part of the URL. 520 2. The HTTP server returns the conferencing web application. 522 3. The conferencing web application creates a new WebRTC 523 RTCPeerConnection (PC) object to allow sending and receiving 524 media. 526 4. The conferencing web app sets the owner's identity on the PC... 528 5. ...and requests an offer to be created. 530 6. As described in [I-D.ietf-rtcweb-security-arch], the PC requests 531 the IDP proxy code from the Identity Service... 533 7. ...which it returns. 535 8. Upon being executed, the idp-proxy code sends the offer to the 536 Identity service... 538 9. ...which verifies user's identity, the signs the offer, and 539 returns the signed offer to the PC. 541 10. The PC then returns the signed offer to the conferencing web 542 app. 544 11. The conferencing web app sends the signed offer to the HTTP 545 server to begin establishing the media connection. 547 4.1.7. Conference Processes Participant Offer 549 Identity KD HTTP MD 550 Service Server 551 | | | | 552 | | |(1) offer | 553 | | |------------------>| 554 | |(2) sign(offer, answer) | 555 | |<--------------------------------------| 556 |(3) GET /.well-known/idp-proxy/default | | 557 |<------------------| | | 558 |(4) 200 (with public key) | | 559 |------------------>| | | 560 |(5) GET /.well-known/idp-proxy/default | | 561 |<------------------| | | 562 |(6) 200 | | | 563 |------------------>| | | 564 |(7) XHR POST /sign (MD answer) | | 565 |<------------------| | | 566 |(8) 200 (signed MD answer) | | 567 |------------------>| | | 568 | |(9) signed answer, KD identity | 569 | |-------------------------------------->| 570 | | |(10) signed answer | 571 | | |<------------------| 572 | | | | 574 This flow is identical to conference processing of the owner's offer. 575 It is included here for completeness. 577 1. The HTTP server sends the signed offer to the MD to allow it to 578 start setting up the media connection. 580 2. The MD creates an answer to the received offer, and sends both 581 offer and answer over the MD-KD tunnel connection. 583 3. Similar to the PC validation procedure described in 584 [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy 585 code from the Identity Service based on the identity in the 586 offer... 588 4. ...which it returns. The KD uses the IDP proxy code to validate 589 the identity of the party that generated the offer. 591 5. Similar to the PC signing procedure described in 592 [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy 593 code from the Identity Service... 595 6. ...which it returns. 597 7. Upon being executed, the idp-proxy code sends the MD answer to 598 the Identity Service... 600 8. ...which verifies KD's identity, the signs the MD answer, and 601 returns the signed MD answer to the KD. 603 9. The KD sends the signed MD answer back to the MD. 605 10. The MD sends the signed answer to the HTTP server. 607 4.1.8. Participant Processes Answer 609 Identity HTTP Participant Participant 610 Service Server Browser PeerConnection 611 | | | | 612 | | | | 613 | | | | 614 | |(1) 200 (signed answer) | 615 | |------------------>| | 616 | | |(2) setRemoteDescription 617 | | | (answer) | 618 | | |------------------>| 619 |(3) GET /.well-known/idp-proxy/default | | 620 |<----------------------------------------------------------| 621 |(4) 200 (with public key) | | 622 |---------------------------------------------------------->| 623 |PC validates signature with public key from Identity Service 624 | | | | 626 This flow is identical to owner's processing of the conference's 627 answer. It is included here for completeness. 629 1. To complete the offer/answer exchange, the HTTP server returns 630 the signed answer (asserting the KD's identity) to the owner's 631 conference web app. 633 2. The conference web app sets the remote description on the PC to 634 the received answer 636 3. Using the identity validation procedure described in 637 [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy 638 code from the Identity Service based on the identity in the 639 answer... 641 4. ...which it returns. The PC uses the IDP proxy code to validate 642 the identity of the party that generated the answer. 644 4.1.9. Participant sets up media connection 646 KD MDD Participant 647 PeerConnection 648 | | | 649 | |(1) DTLS setup | 650 | |<------------------| 651 |(2) Tunnel(DTLS setup) | 652 |<------------------| | 653 | |(3) Double encrypted media 654 | |...................| 655 | | | 657 This flow is identical to the owner's establishment of encrypted 658 media. It is included here for completeness. 660 1. The PC, using the addressing information present in the answer, 661 negotiates a DTLS association towards the MD. We make an 662 assumption that the SDP generated by the MD contains a port 663 number that is unique to the conference, allowing it to correlate 664 the incoming DTLS messages to the correct KD. 666 2. The MD uses the tunneling protocol defined in 667 [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages 668 between the PC and the KD. These DTLS setup messages make use of 669 the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to 670 establish end-to-end keys for the media. 672 3. Using the mechanism described in [I-D.ietf-perc-double], the PC 673 now begins to send and received SRTP-encrypted media to and from 674 the MD. 676 4.2. Key Distributor Separate From Browser 678 This configuration introduces a couple of challenges. It is not 679 explored in depth in this version of the document; however, we 680 highlight the following two issues: 682 o Because identity in WebRTC is inherently based on evaluation of 683 Javascript, and because the KD must validate identities to perform 684 its intended purpose, the KD will be required to include a 685 Javascript execution environment. 687 o Because the KD is the only trusted node that inherently has access 688 to the list of active conference participants, we must introduce 689 additional mechanisms that allow it to convey this information to 690 conference participants in a way that can be authenticated. 692 5. New Mechanisms Required 694 Based on the foregoing message flows, we need to add a small number 695 of new mechanisms to the overall system. 697 5.1. New Key Distributor DOM Object 699 Although the formal definition of the Key Distributor DOM object will 700 be provided by a W3C document, the foregoing message flows imply that 701 we will need an interface that looks roughly like the following. 702 This interface is expressed using the syntax defined by 703 [W3C.CR-WebIDL-1-20160308], and refers to a number of structures 704 defined in [W3C.WD-webrtc-20170313]. 706 interface RTCKeyDistributor : EventTarget { 707 void setIdentityProvider(DOMString provider, 708 optional RTCIdentityProviderOptions options); 710 Promise getIdentityAssertion(); 711 readonly attribute Promise peerIdentity; 712 readonly attribute DOMString? idpLoginUrl; 713 readonly attribute DOMString? idpErrorInfo; 715 Promise getCertificate(); 717 Promise connect(DOMString mdHost, unsigned short mdPort); 719 attribute EventHandler onfingerprintfailure; 720 } 722 5.2. New "sign" Tunnel Message 724 We also need to add new "sign_answer" and "sign_answer_ack" MsgTypes 725 to the protocol defined in [I-D.ietf-perc-dtls-tunnel]. These are 726 used by the MD to request that the KD sign its answer. 728 The "SignAnswer" message is defined as follows: 730 struct { 731 opaque offer<1..2^24-1>; 732 opaque answer<1..2^24-1>; 733 } SignAnswer; 735 The "SignAnswerAck" message is defined as follows: 737 struct { 738 opaque answer<1..2^24-1>; 739 } SignAnswerAck; 741 6. Security Considerations 743 This section will be fleshed out further after the working group has 744 general agreement about the direction this mechanism should take. 746 The means by which the KD determines that the offer being presented 747 in the "sign" message corresponds to the current conference and has 748 not been replayed has not yet been analyzed. 750 We need to ensure that MD answers signed by the KD cannot be used by 751 the MD as offers in other contexts, as doing so would allow the MD to 752 impersonate the KD's identity. 754 7. IANA Considerations 756 This document requires no actions from IANA. 758 8. References 760 8.1. Normative References 762 [I-D.ietf-perc-double] 763 Jennings, C., Jones, P., and A. Roach, "SRTP Double 764 Encryption Procedures", draft-ietf-perc-double-02 (work in 765 progress), October 2016. 767 [I-D.ietf-perc-dtls-tunnel] 768 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 769 between a Media Distributor and Key Distributor to 770 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00 771 (work in progress), March 2017. 773 [I-D.ietf-perc-srtp-ekt-diet] 774 Jennings, C., Mattsson, J., McGrew, D., and D. Wing, 775 "Encrypted Key Transport for Secure RTP", draft-ietf-perc- 776 srtp-ekt-diet-02 (work in progress), October 2016. 778 [I-D.ietf-rtcweb-security-arch] 779 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 780 rtcweb-security-arch-12 (work in progress), June 2016. 782 [W3C.CR-WebIDL-1-20160308] 783 McCormack, C. and B. Zbarsky, "WebIDL Level 1", World Wide 784 Web Consortium CR CR-WebIDL-1-20160308, March 2016, 785 . 787 [W3C.WD-webrtc-20170313] 788 Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., 789 and B. Aboba, "WebRTC 1.0: Real-time Communication Between 790 Browsers", World Wide Web Consortium WD WD-webrtc- 791 20170313, March 2017, . 794 8.2. Informative References 796 [I-D.ietf-perc-private-media-framework] 797 Jones, P., Benham, D., and C. Groves, "A Solution 798 Framework for Private Media in Privacy Enhanced RTP 799 Conferencing", draft-ietf-perc-private-media-framework-02 800 (work in progress), October 2016. 802 Author's Address 804 Adam Roach 805 Mozilla 806 \ 807 Dallas 808 US 810 Phone: +1 650 903 0800 x863 811 Email: adam@nostrum.com