[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           A. Roach
Internet-Draft                                                   Mozilla
Intended status: Informational                            March 10, 2017
Expires: September 11, 2017


Using Privacy Enhanced Real-time Conferencing (PERC) in a WebRTC Context
                       draft-roach-perc-webrtc-00

Abstract

   The Privacy-Enhanced Realtime Conferencing (PERC) architecture
   defines a system by which multiparty conferences can be handled by a
   conference server that is "semi-trusted": that is, it is trusted to
   correctly handle media packets, but it is not trusted with the actual
   contents of the media streams.  In order to use this architecture
   within WebRTC, we must describe how information is conveyed among
   various network functions.  This document describes the information
   to be conveyed and how it is transferred.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 11, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Roach                  Expires September 11, 2017               [Page 1]


Internet-Draft               PERC in WebRTC                   March 2017


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Data Flows  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Key Distributor Co-Located with Browser . . . . . . . . .   3
       4.1.1.  Conference Establishment  . . . . . . . . . . . . . .   5
       4.1.2.  Owner Sends Offer to Conference . . . . . . . . . . .   7
       4.1.3.  Conference Processes Owner Offer  . . . . . . . . . .   9
       4.1.4.  Owner Processes Answer  . . . . . . . . . . . . . . .  10
       4.1.5.  Owner sets up media connection  . . . . . . . . . . .  11
       4.1.6.  Participant Joins Conference  . . . . . . . . . . . .  11
       4.1.7.  Conference Processes Participant Offer  . . . . . . .  13
       4.1.8.  Participant Processes Answer  . . . . . . . . . . . .  14
       4.1.9.  Participant sets up media connection  . . . . . . . .  15
     4.2.  Key Distributor Separate From Browser . . . . . . . . . .  16
   5.  New Mechanisms Required . . . . . . . . . . . . . . . . . . .  16
     5.1.  New Key Distributor DOM Object  . . . . . . . . . . . . .  16
     5.2.  New "sign" Tunnel Message . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   The Privacy-Enhanced Realtime Conferencing (PERC) architecture
   [I-D.ietf-perc-private-media-framework] defines a system by which
   multiparty conferences can be handled by a conference server that is
   "semi-trusted": that is, it is trusted to correctly handle media
   packets, but it is not trusted with the actual contents of the media
   streams.  In order to use this architecture within WebRTC
   [W3C.WD-webrtc-20170313], we must describe how information is
   conveyed among various network functions.  This document describes
   the information to be conveyed and how it is transferred.

   Note that the current document is a fairly high-level thumbnail
   sketch of information flow.  It will be expanded with further detail
   once we have consensus on the general direction for the mechanism.





Roach                  Expires September 11, 2017               [Page 2]


Internet-Draft               PERC in WebRTC                   March 2017


2.  Terminology

   This document also uses a number of terms defined in section 2 of
   [I-D.ietf-perc-private-media-framework].  Of particular note, the
   definitions for "Media Distributor (MD)" and "Key Distributor (KD)"
   are provided by that document.

3.  Goals

   A key goal of the mechanisms described in this document is that it
   should work with a minimal set of changes to web browsers that
   already implement WebRTC.  In particular: PERC requires the use of
   strong identity assertions in order to provide any value whatsoever.
   WebRTC already contains an identity mechanism
   [I-D.ietf-rtcweb-security-arch]; we do not seek to introduce a second
   one.  Regarding identity, this document assumes:

   o  From a WebRTC perspective, the remote identity presented to each
      conference participant will be the identity of the Key Distributor
      (KD).  Whether this is identical to the PeerConnection identity
      presented by the conference owner is a matter of policy for the
      conference application.  (Note that this is an emergent property
      of the system rather than a design decision, since the DTLS
      associations used to key the SRTP terminate at the KD in the PERC
      architecture.)

   o  The KD will validate the identity of each user as they join the
      conference.  The roster of current users must be available to at
      least one of the participants through a means that can be trusted
      as being authentically generated by the KD.

   We also seek to support a system that allows for the Key Distributor
   (KD) to be co-located with an endpoint as a primary goal, and for the
   KD to be located on a dedicated server as an important secondary
   goal.

4.  Data Flows

4.1.  Key Distributor Co-Located with Browser

   When the KD is co-located with the browser, the browser that serves
   the role of KD must join the conference before any other media can be
   exchanged.  It is up to the application to determine whether this is
   simply the first participant to join, or a specific participant who
   has an administrative relationship with the conference instance.  For
   concision, we will use the term "conference owner" to refer to the
   browser serving in this role, even though its assignment may be
   arbitrary.



Roach                  Expires September 11, 2017               [Page 3]


Internet-Draft               PERC in WebRTC                   March 2017


   We further posit that browsers that serve as KDs will have specific
   objects available as part of their Document Object Model (DOM).
   These objects will give applications the ability to instantiate and
   control such KDs, but without actually being able to obtain access to
   the keying material itself.  The definition of the interface for such
   objects is not defined in this document more than necessary.  We
   envision a companion document, submitted to the W3C, to describe this
   API in detail.

   The following callflows illustrate the information exchanged among
   these entities:

   Identity Service:  This is the server that acts as in Identity
      Provider (IdP), as that term is defined in
      [I-D.ietf-rtcweb-security-arch].  Note that the Owner and the
      Participant may use different Identity Services to vouch for their
      identities.

   Owner Browser:  This is the web browser execution environment for the
      web browser that is acting as the KD.

   Owner PeerConnection:  This is the RTCPeerConnection object created
      and used by conferencing web application running in the Owner
      Browser.  It is shown separately from the Owner Browser to clearly
      indicate those tasks which are performed directly by the
      RTCPeerConnection without the ability for the conferencing web
      application to intervene.

   KD:  This is the Key Distributor function created and used by the
      conferencing web application running in the Owner Browser.  It is
      shown separately from the Owner Browser to clearly indicate those
      tasks which are performed directly by the Key Distributor without
      the ability for the conferencing web application to intervene.

   HTTP Server:  This is the HTTP server that handles the signaling for
      the conference.

   MD:  This is the media distributor that handles the media the
      conference.  Note that the interface between the HTTP Server and
      the MD is an implementation detail for the developer of the
      conference server.  The messages exchanged between them are
      intended to illustrate the information required to be exchanged
      between them to have a properly functioning PERC conference.

   Participant Browser:  This is the web browser execution environment
      for a web browser that is not acting as the KD.





Roach                  Expires September 11, 2017               [Page 4]


Internet-Draft               PERC in WebRTC                   March 2017


   Participant PeerConnection:  This is the RTCPeerConnection object
      created and used by conferencing web application running in the
      Participant Browser.  It is shown separately from the Participant
      Browser to clearly indicate those tasks which are performed
      directly by the RTCPeerConnection without the ability for the
      conferencing web application to intervene.

   The following sub sections step through an illustrative call flow
   that demonstrates how the information needed to create a PERC
   conference in a WebRTC environment is exchanged among the
   aforementioned functions.  The call flows occur in the order shown by
   these sections - division into sections is done primarily to limit
   the number of elements in any diagram to no more than four, since the
   limitations of the internet-draft format makes wider diagrams
   impossible.

4.1.1.  Conference Establishment


































Roach                  Expires September 11, 2017               [Page 5]


Internet-Draft               PERC in WebRTC                   March 2017


    Owner                KD              HTTP Server             MD
   Browser                |                   |                   |
      |                   |                   |                   |
      |                   |                   |                   |
      |(1) GET /perc/room-identifier          |                   |
      |-------------------------------------->|                   |
      |(2) 200 OK (with app)                  |                   |
      |<--------------------------------------|                   |
      |(3) new KD();      |                   |                   |
      |------------------>|                   |                   |
      |(4) kd.setIdentity(id1);               |                   |
      |------------------>|                   |                   |
      |(5) kd.getFingerprint();               |                   |
      |------------------>|                   |                   |
      |(6) fingerprint    |                   |                   |
      |<------------------|                   |                   |
      |(7) POST /start-conf (KD fingerprint)  |                   |
      |-------------------------------------->|                   |
      |                   |                   |(8) New Conference |
      |                   |                   |   (KD fingerprint)|
      |                   |                   |------------------>|
      |                   |                   |(9) ack            |
      |                   |                   |<------------------|
      |(10) 200 (MD name and port)            |                   |
      |<--------------------------------------|                   |
      |(11)  kd.connect(mdName,port)          |                   |
      |------------------>|                   |                   |
      |                   |(12) TLS setup     |                   |
      |                   |-------------------------------------->|
      |                   |                   |                   |
      |                   |KD checks that MD cert matches name    |
      |                   |                   |                   |
      |             MD checks that the client fingerprint matches |
      |                   |                   |                   |
      |                   |(13) Profiles      |                   |
      |                   |<--------------------------------------|
      |(14) resolve connect promise           |                   |
      |<------------------|                   |                   |
      |                   |                   |                   |

   1.   The conference owner loads the conference application.  Although
        not required, information sufficient to identify the conference
        is frequently sent as part of the URL.

   2.   The HTTP server returns the conferencing web application.






Roach                  Expires September 11, 2017               [Page 6]


Internet-Draft               PERC in WebRTC                   March 2017


   3.   The conferencing web application instantiates a new Key
        Distributor (KD) object.  Upon instantiation, this KD creates a
        new certificate.

   4.   The conferencing web app sets the owner's identity on the KD.

   5.   The application asks for the certificate's fingerprint...

   6.   ...which the KD provides

   7.   The application initiates the conference, including the KD cert
        fingerprint as part of the initiation message.

   8.   The HTTP server passes the KD fingerprint along to the Media
        Distributor (MD).  This is used later by the MD to ensure that
        the correct KD is connecting to it.

   9.   The MD acknowledges creation of a new conference.  This
        acknowledgement contains the hostname and port that the MD is
        listening on for the KD to connect to.

   10.  The web server responds to the conferencing web app with the
        hostname of the MD as well as the port it is listening on for
        the KD to connect.

   11.  The application passes along the MD name and port to the KD
        object.

   12.  The KD initiates a TLS connection to the MD.  This connection
        uses the protocol defined in [I-D.ietf-perc-dtls-tunnel].  The
        KD verifies that the certificate presented by the MD matches the
        name it used to connect to it, and that it chains up to a
        trusted certificate authority.  The MD verifies that the client
        cert provided by the KD matches the fingerprint that it received
        earlier from the HTTP server.

   13.  The MD returns its list of supported profiles, as described in
        [I-D.ietf-perc-dtls-tunnel].

   14.  The KD object indicates to the conferencing app that the KD-MD
        connection has been successfully established.

4.1.2.  Owner Sends Offer to Conference








Roach                  Expires September 11, 2017               [Page 7]


Internet-Draft               PERC in WebRTC                   March 2017


   Identity             Owner               Owner               HTTP
    Service             Browser         PeerConnection          Server
       |                   |                   |                   |
       |                   |                   |                   |
       |                   |(1) new PC();      |                   |
       |                   |------------------>|                   |
       |                   |(2) setIdentity(id1);                  |
       |                   |------------------>|                   |
       |                   |(3) createOffer(); |                   |
       |                   |------------------>|                   |
       |(4) GET /.well-known/idp-proxy/default |                   |
       |<--------------------------------------|                   |
       |(5) 200            |                   |                   |
       |-------------------------------------->|                   |
       |(6) XHR POST /sign (offer)             |                   |
       |<--------------------------------------|                   |
       |(7) 200 (signed offer)                 |                   |
       |-------------------------------------->|                   |
       |                   |(8) resolve createOffer() promise      |
       |                   |<------------------|                   |
       |                   |(9) POST /perc/offer?room-identifier   |
       |                   |(with signed offer)|                   |
       |                   |-------------------------------------->|
       |                   |                   |                   |

   1.  The conferencing web application creates a new WebRTC
       RTCPeerConnection (PC) object to allow sending and receiving
       media.

   2.  The conferencing web app sets the owner's identity on the PC...

   3.  ...and requests an offer to be created.

   4.  As described in [I-D.ietf-rtcweb-security-arch], the PC requests
       the IDP proxy code from the Identity Service...

   5.  ...which it returns.

   6.  Upon being executed, the idp-proxy code sends the offer to the
       Identity service...

   7.  ...which verifies user's identity, the signs the offer, and
       returns the signed offer to the PC.

   8.  The PC then returns the signed offer to the conferencing web app.

   9.  The conferencing web app sends the signed offer to the HTTP
       server to begin establishing the media connection.



Roach                  Expires September 11, 2017               [Page 8]


Internet-Draft               PERC in WebRTC                   March 2017


4.1.3.  Conference Processes Owner Offer

   Identity               KD                 HTTP                 MD
    Service                                 Server
       |                   |                   |                   |
       |                   |                   |(1) signed offer   |
       |                   |                   |------------------>|
       |                   |                   |                   |
       |                   |(2) sign(offer, answer)                |
       |                   |<--------------------------------------|
       |(3) GET /.well-known/idp-proxy/default |                   |
       |<------------------|                   |                   |
       |(4) 200 (with public key)              |                   |
       |------------------>|                   |                   |
       |(5) GET /.well-known/idp-proxy/default |                   |
       |<------------------|                   |                   |
       |(6) 200            |                   |                   |
       |------------------>|                   |                   |
       |(7) XHR POST /sign (MD answer)         |                   |
       |<------------------|                   |                   |
       |(8) 200 (signed MD answer)             |                   |
       |------------------>|                   |                   |
       |                   |(9) signed answer, KD identity         |
       |                   |-------------------------------------->|
       |                   |                   |(10) signed answer |
       |                   |                   |<------------------|
       |                   |                   |                   |

   In this section of the flow, the MD sends generates an answer.  It
   sends this answer to the KD so that it can sign it with an assertion
   of the KD's identity.  It also sends the corresponding offer to the
   KD so that the KD can validate that the authenticated party who
   generated the offer is authorized to join the conference, and to
   allow the KD to add that user to its own notion of the current
   conference roster.

   1.   The HTTP server sends the signed offer to the MD to allow it to
        start setting up the media connection.

   2.   The MD creates an answer to the received offer, and sends both
        offer and answer over the MD-KD tunnel connection.

   3.   Similar to the PC validation procedure described in
        [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
        code from the Identity Service based on the identity in the
        offer...





Roach                  Expires September 11, 2017               [Page 9]


Internet-Draft               PERC in WebRTC                   March 2017


   4.   ...which it returns.  The KD uses the IDP proxy code to validate
        the identity of the party that generated the offer.

   5.   Similar to the PC signing procedure described in
        [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
        code from the Identity Service...

   6.   ...which it returns.

   7.   Upon being executed, the idp-proxy code sends the MD answer to
        the Identity Service...

   8.   ...which verifies KD's identity, the signs the MD answer, and
        returns the signed MD answer to the KD.

   9.   The KD sends the signed MD answer back to the MD.

   10.  The MD sends the signed answer to the HTTP server.

4.1.4.  Owner Processes Answer

   Identity              Owner               Owner               HTTP
    Service             Browser         PeerConnection          Server
       |                   |                   |                   |
       |                   |                   |                   |
       |                   |                   |                   |
       |                   |(1) 200 (signed answer)                |
       |                   |<--------------------------------------|
       |                   |(2) setRemoteDescription(answer)       |
       |                   |------------------>|                   |
       |(3) GET /.well-known/idp-proxy/default |                   |
       |<--------------------------------------|                   |
       |(4) 200 (with public key)              |                   |
       |-------------------------------------->|                   |
       |PC validates signature with public key from Identity Service
       |                   |                   |                   |
       |                   |                   |                   |

   1.  To complete the offer/answer exchange, the HTTP server returns
       the signed answer (asserting the KD's identity) to the owner's
       conference web app.

   2.  The conference web app sets the remote description on the PC to
       the received answer

   3.  Using the identity validation procedure described in
       [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy




Roach                  Expires September 11, 2017              [Page 10]


Internet-Draft               PERC in WebRTC                   March 2017


       code from the Identity Service based on the identity in the
       answer...

   4.  ...which it returns.  The PC uses the IDP proxy code to validate
       the identity of the party that generated the answer.

4.1.5.  Owner sets up media connection

   Note: ICE/ICE Lite is not shown in this flow, but is assumed to have
   taken place.

           Owner                KD                  MD
      PeerConnection
             |                   |                   |
             |                   |                   |
             |(1) DTLS setup     |                   |
             |-------------------------------------->|
             |                   |(2) Tunnel(DTLS setup)
             |                   |<------------------|
             |(3) Double encrypted media             |
             |.......................................|
             |                   |                   |
             |                   |                   |

   1.  The PC, using the addressing information present in the answer,
       negotiates a DTLS association towards the MD.  We make an
       assumption that the SDP generated by the MD contains a port
       number that is unique to the conference, allowing it to correlate
       the incoming DTLS messages to the correct KD.

   2.  The MD uses the tunneling protocol defined in
       [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages
       between the PC and the KD.  These DTLS setup messages make use of
       the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to
       establish end-to-end keys for the media.

   3.  Using the mechanism described in [I-D.ietf-perc-double], the PC
       now begins to send and received SRTP-encrypted media to and from
       the MD.

4.1.6.  Participant Joins Conference

   After the conference has been established as described in the
   preceding sections, each new participant triggers a flow that closely
   mirrors the owner PC's interaction with the conference.  These steps
   are shown in the following sections.





Roach                  Expires September 11, 2017              [Page 11]


Internet-Draft               PERC in WebRTC                   March 2017


 HTTP           Participant         Participant          Identity
 Server           Browser         PeerConnection          Service
 |                   |                   |                   |
 |(1) GET /perc/room-identifier          |                   |
 |<------------------|                   |                   |
 |(2) 200 OK (with app)                  |                   |
 |------------------>|                   |                   |
 |                   |(3) new PC();      |                   |
 |                   |------------------>|                   |
 |                   |(4) setIdentity(id2);                  |
 |                   |------------------>|                   |
 |                   |(5) createOffer(); |                   |
 |                   |------------------>|                   |
 |                   |                   |(6) GET            |
 |                   |                   |/.well-known/idp-proxy/default
 |                   |                   |------------------>|
 |                   |                   |(7) 200            |
 |                   |                   |<------------------|
 |                   |                   |(8) XHR POST /sign (offer)
 |                   |                   |------------------>|
 |                   |                   |(9) 200 (signed offer)
 |                   |                   |<------------------|
 |                   |(10) resolve createOffer() promise     |
 |                   |<------------------|                   |
 |(11) POST /perc/offer?room-identifier (signed offer)       |
 |<------------------|                   |                   |
 |                   |                   |                   |

   1.   The conference owner loads the conference application.  Although
        not required, information sufficient to identify the conference
        is frequently sent as part of the URL.

   2.   The HTTP server returns the conferencing web application.

   3.   The conferencing web application creates a new WebRTC
        RTCPeerConnection (PC) object to allow sending and receiving
        media.

   4.   The conferencing web app sets the owner's identity on the PC...

   5.   ...and requests an offer to be created.

   6.   As described in [I-D.ietf-rtcweb-security-arch], the PC requests
        the IDP proxy code from the Identity Service...

   7.   ...which it returns.





Roach                  Expires September 11, 2017              [Page 12]


Internet-Draft               PERC in WebRTC                   March 2017


   8.   Upon being executed, the idp-proxy code sends the offer to the
        Identity service...

   9.   ...which verifies user's identity, the signs the offer, and
        returns the signed offer to the PC.

   10.  The PC then returns the signed offer to the conferencing web
        app.

   11.  The conferencing web app sends the signed offer to the HTTP
        server to begin establishing the media connection.

4.1.7.  Conference Processes Participant Offer

   Identity               KD                 HTTP                 MD
    Service                                 Server
       |                   |                   |                   |
       |                   |                   |(1) offer          |
       |                   |                   |------------------>|
       |                   |(2) sign(offer, answer)                |
       |                   |<--------------------------------------|
       |(3) GET /.well-known/idp-proxy/default |                   |
       |<------------------|                   |                   |
       |(4) 200 (with public key)              |                   |
       |------------------>|                   |                   |
       |(5) GET /.well-known/idp-proxy/default |                   |
       |<------------------|                   |                   |
       |(6) 200            |                   |                   |
       |------------------>|                   |                   |
       |(7) XHR POST /sign (MD answer)         |                   |
       |<------------------|                   |                   |
       |(8) 200 (signed MD answer)             |                   |
       |------------------>|                   |                   |
       |                   |(9) signed answer, KD identity         |
       |                   |-------------------------------------->|
       |                   |                   |(10) signed answer |
       |                   |                   |<------------------|
       |                   |                   |                   |

   This flow is identical to conference processing of the owner's offer.
   It is included here for completeness.

   1.   The HTTP server sends the signed offer to the MD to allow it to
        start setting up the media connection.

   2.   The MD creates an answer to the received offer, and sends both
        offer and answer over the MD-KD tunnel connection.




Roach                  Expires September 11, 2017              [Page 13]


Internet-Draft               PERC in WebRTC                   March 2017


   3.   Similar to the PC validation procedure described in
        [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
        code from the Identity Service based on the identity in the
        offer...

   4.   ...which it returns.  The KD uses the IDP proxy code to validate
        the identity of the party that generated the offer.

   5.   Similar to the PC signing procedure described in
        [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy
        code from the Identity Service...

   6.   ...which it returns.

   7.   Upon being executed, the idp-proxy code sends the MD answer to
        the Identity Service...

   8.   ...which verifies KD's identity, the signs the MD answer, and
        returns the signed MD answer to the KD.

   9.   The KD sends the signed MD answer back to the MD.

   10.  The MD sends the signed answer to the HTTP server.

4.1.8.  Participant Processes Answer

 Identity              HTTP             Participant         Participant
  Service             Server              Browser         PeerConnection
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |(1) 200 (signed answer)                |
     |                   |------------------>|                   |
     |                   |                   |(2) setRemoteDescription
     |                   |                   |    (answer)       |
     |                   |                   |------------------>|
     |(3) GET /.well-known/idp-proxy/default |                   |
     |<----------------------------------------------------------|
     |(4) 200 (with public key)              |                   |
     |---------------------------------------------------------->|
     |PC validates signature with public key from Identity Service
     |                   |                   |                   |

   This flow is identical to owner's processing of the conference's
   answer.  It is included here for completeness.






Roach                  Expires September 11, 2017              [Page 14]


Internet-Draft               PERC in WebRTC                   March 2017


   1.  To complete the offer/answer exchange, the HTTP server returns
       the signed answer (asserting the KD's identity) to the owner's
       conference web app.

   2.  The conference web app sets the remote description on the PC to
       the received answer

   3.  Using the identity validation procedure described in
       [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy
       code from the Identity Service based on the identity in the
       answer...

   4.  ...which it returns.  The PC uses the IDP proxy code to validate
       the identity of the party that generated the answer.

4.1.9.  Participant sets up media connection

            KD                  MDD             Participant
                                              PeerConnection
             |                   |                   |
             |                   |(1) DTLS setup     |
             |                   |<------------------|
             |(2) Tunnel(DTLS setup)                 |
             |<------------------|                   |
             |                   |(3) Double encrypted media
             |                   |...................|
             |                   |                   |

   This flow is identical to the owner's establishment of encrypted
   media.  It is included here for completeness.

   1.  The PC, using the addressing information present in the answer,
       negotiates a DTLS association towards the MD.  We make an
       assumption that the SDP generated by the MD contains a port
       number that is unique to the conference, allowing it to correlate
       the incoming DTLS messages to the correct KD.

   2.  The MD uses the tunneling protocol defined in
       [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages
       between the PC and the KD.  These DTLS setup messages make use of
       the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to
       establish end-to-end keys for the media.

   3.  Using the mechanism described in [I-D.ietf-perc-double], the PC
       now begins to send and received SRTP-encrypted media to and from
       the MD.





Roach                  Expires September 11, 2017              [Page 15]


Internet-Draft               PERC in WebRTC                   March 2017


4.2.  Key Distributor Separate From Browser

   This configuration introduces a couple of challenges.  It is not
   explored in depth in this version of the document; however, we
   highlight the following two issues:

   o  Because identity in WebRTC is inherently based on evaluation of
      Javascript, and because the KD must validate identities to perform
      its intended purpose, the KD will be required to include a
      Javascript execution environment.

   o  Because the KD is the only trusted node that inherently has access
      to the list of active conference participants, we must introduce
      additional mechanisms that allow it to convey this information to
      conference participants in a way that can be authenticated.

5.  New Mechanisms Required

   Based on the foregoing message flows, we need to add a small number
   of new mechanisms to the overall system.

5.1.  New Key Distributor DOM Object

   Although the formal definition of the Key Distributor DOM object will
   be provided by a W3C document, the foregoing message flows imply that
   we will need an interface that looks roughly like the following.
   This interface is expressed using the syntax defined by
   [W3C.CR-WebIDL-1-20160308], and refers to a number of structures
   defined in [W3C.WD-webrtc-20170313].

  interface RTCKeyDistributor : EventTarget {
      void setIdentityProvider(DOMString provider,
                           optional RTCIdentityProviderOptions options);

      Promise<DOMString> getIdentityAssertion();
      readonly attribute Promise<RTCIdentityAssertion> peerIdentity;
      readonly attribute DOMString?                    idpLoginUrl;
      readonly attribute DOMString?                    idpErrorInfo;

      Promise<RTCCertificate> getCertificate();

      Promise<void> connect(DOMString mdHost, unsigned short mdPort);

      attribute EventHandler              onfingerprintfailure;
  }






Roach                  Expires September 11, 2017              [Page 16]


Internet-Draft               PERC in WebRTC                   March 2017


5.2.  New "sign" Tunnel Message

   We also need to add new "sign_answer" and "sign_answer_ack" MsgTypes
   to the protocol defined in [I-D.ietf-perc-dtls-tunnel].  These are
   used by the MD to request that the KD sign its answer.

   The "SignAnswer" message is defined as follows:

   struct {
     opaque offer<1..2^24-1>;
     opaque answer<1..2^24-1>;
   } SignAnswer;

   The "SignAnswerAck" message is defined as follows:

   struct {
     opaque answer<1..2^24-1>;
   } SignAnswerAck;

6.  Security Considerations

   This section will be fleshed out further after the working group has
   general agreement about the direction this mechanism should take.

   The means by which the KD determines that the offer being presented
   in the "sign" message corresponds to the current conference and has
   not been replayed has not yet been analyzed.

   We need to ensure that MD answers signed by the KD cannot be used by
   the MD as offers in other contexts, as doing so would allow the MD to
   impersonate the KD's identity.

7.  IANA Considerations

   This document requires no actions from IANA.

8.  References

8.1.  Normative References

   [I-D.ietf-perc-double]
              Jennings, C., Jones, P., and A. Roach, "SRTP Double
              Encryption Procedures", draft-ietf-perc-double-02 (work in
              progress), October 2016.







Roach                  Expires September 11, 2017              [Page 17]


Internet-Draft               PERC in WebRTC                   March 2017


   [I-D.ietf-perc-dtls-tunnel]
              Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
              between a Media Distributor and Key Distributor to
              Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00
              (work in progress), March 2017.

   [I-D.ietf-perc-srtp-ekt-diet]
              Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
              "Encrypted Key Transport for Secure RTP", draft-ietf-perc-
              srtp-ekt-diet-02 (work in progress), October 2016.

   [I-D.ietf-rtcweb-security-arch]
              Rescorla, E., "WebRTC Security Architecture", draft-ietf-
              rtcweb-security-arch-12 (work in progress), June 2016.

   [W3C.CR-WebIDL-1-20160308]
              McCormack, C. and B. Zbarsky, "WebIDL Level 1", World Wide
              Web Consortium CR CR-WebIDL-1-20160308, March 2016,
              <http://www.w3.org/TR/2016/CR-WebIDL-1-20160308>.

   [W3C.WD-webrtc-20170313]
              Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,
              and B. Aboba, "WebRTC 1.0: Real-time Communication Between
              Browsers", World Wide Web Consortium WD WD-webrtc-
              20170313, March 2017, <https://www.w3.org/TR/2017/WD-
              webrtc-20170313>.

8.2.  Informative References

   [I-D.ietf-perc-private-media-framework]
              Jones, P., Benham, D., and C. Groves, "A Solution
              Framework for Private Media in Privacy Enhanced RTP
              Conferencing", draft-ietf-perc-private-media-framework-02
              (work in progress), October 2016.

Author's Address

   Adam Roach
   Mozilla
   \
   Dallas
   US

   Phone: +1 650 903 0800 x863
   Email: adam@nostrum.com






Roach                  Expires September 11, 2017              [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/