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

Versions: 00

Network Working Group                                     P. Jones (Ed.)
Internet Draft                                                 N. Ismail
Intended status: Informational                                 D. Benham
Expires: January 6, 2016                                      N. Buckles
                                                           Cisco Systems
                                                             J. Mattsson
                                                                Ericsson
                                                               R. Barnes
                                                                 Mozilla
                                                            July 6, 2015



      Private Media Requirements in Privacy Enhanced RTP Conferencing
                  draft-jones-perc-private-media-reqts-00


Abstract

   This document specifies the requirements for ensuring the privacy and
   integrity of real-time transport protocol (RTP) media flows between
   two or more endpoints communicating through one or more centrally
   located media distribution devices (MDDs).

Status of this Memo

   This Internet-Draft is submitted to IETF 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 January 6, 2015.

Copyright Notice

   Copyright (c) 2015 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


Jones, et al.          Expires January 6, 2016                  [Page 1]


Internet-Draft        Private Media Requirements               July 2015


   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. Requirements Language..........................................3
   3. Terminology....................................................3
   4. Background.....................................................4
   5. Motivation for Private Media using switching MDDs..............5
      5.1. Switching Media in Cloud Services.........................5
      5.2. Private Media Security through Switching..................7
   6. Private Media Trust Model......................................8
      6.1. Trusted Elements..........................................9
      6.2. Untrusted Elements.......................................10
   7. Goals and Non-Goals...........................................11
      7.1. Goals....................................................11
         7.1.1. Ensure End-To-End Confidentiality...................11
         7.1.2. Ensure End-To-End Source Authentication of Media....11
         7.1.3. Provide a More Efficient Service than "Full-Mesh"...12
         7.1.4. Support Cloud-Based Conferencing....................12
         7.1.5. Limiting an Endpoint's Access to Content............12
         7.1.6. Compatibility with the WebRTC Security Architecture.12
      7.2. Non-Goals................................................13
         7.2.1. Securing the Endpoints..............................13
         7.2.2. Concealing that Communication Occurs................13
         7.2.3. Individual Media Source Authentication..............13
         7.2.4. Multicast -based Conferencing.......................14
   8. Requirements..................................................14
   9. IANA Considerations...........................................15
   10. Security Considerations......................................15
   11. References...................................................15
      11.1. Normative References....................................15
      11.2. Informative References..................................16
   12. Acknowledgments..............................................16
   13. Contributors.................................................17
   Authors' Addresses...............................................18


1. Introduction

   Users of multimedia communication products and services have privacy
   expectations that are largely satisfied with the use of SRTP
   [RFC3711] and related technologies when communicating point-to-point
   over the Internet.  When two or more endpoints communicate through a
   traditional media server, it is necessary for those endpoints to
   share the SRTP master key and salt information with the traditional
   media server so that it can authenticate and decrypt received RTP and
   RTCP packets.  The key material is needed so that a traditional media
   server can perform various operations on the media, such as mixing,



Jones, et al.          Expires January 6, 2016                  [Page 2]


Internet-Draft        Private Media Requirements               July 2015


   transcoding, and transrating.  The traditional media server also
   needs the master key and salt in order to transmit media packets to
   other endpoints in the conference.  The need for a traditional media
   server to have the master key represents a security risk.

   Within a corporate or other isolated environment where all
   conferencing resources, including both call control and media
   processing functions, are tightly controlled, this security risk can
   be effectively managed.  However, managing this risk is becoming
   increasing difficult as conferencing resources are deployed in
   networks that are not so strictly managed or controlled, including
   resources on virtualized servers deployed in third-party cloud
   environments.

   There are also existing public voice and video conferencing service
   providers in which users must place full trust by sharing media
   encryption keys in order to use those services.  This exposes
   corporations, for example, to a higher risk of being subjected to
   corporate espionage.  While it is not the intent of this draft to
   suggest that any existing service provider would permit or condone
   any illicit use of its service, the fact is that security threats can
   come from either internal or external sources and remain undiscovered
   for long periods of time.

   It is possible to ensure real-time transport protocol (RTP) media
   privacy in deployments using one or more centrally located media
   distribution devices (MDDs) with limited changes in the security
   mechanisms used today.  This document discusses this possibility in
   more detail and presents a set of requirements that are neutral with
   respect to session signaling protocols.

   This document is focused on ensuring the privacy of RTP media in
   centralized MDD models only.  Other types of media are out of scope.
   Other, non-centralized media distribution models are also out of
   scope.

2. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]
   when they appear in ALL CAPS.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

3. Terminology

   Adversary - An unauthorized entity that may attempt to compromise the
   performance of a media distribution device through various means,
   including, but not limited to, the transmission of bogus media
   packets or attempt to gain access to the plaintext of the media.



Jones, et al.          Expires January 6, 2016                  [Page 3]


Internet-Draft        Private Media Requirements               July 2015


   Media content - The portion of the RTP (i.e., the encrypted RTP
   payload) or other packet containing the actual audio, video, or other
   multimedia information that is considered confidential and is subject
   to end-to-end encryption.  This does not include, for example, RTP
   headers, RTP header extensions, or RTCP packets.

   Switching media distribution device - A media distribution device
   that does not decrypt RTP media flows or perform processing on the
   media payload, but instead simply forwards the received media from a
   sender to the other endpoints in a multimedia conference.  A
   switching media distribution device may modify some portion of the
   RTP header and may often consume and create RTCP messages for
   efficient media handling.

4. Background

   Traditional media servers used for multimedia conferencing would mix,
   transcode, transrate, and/or recompose media flows from one or more
   conference participants' endpoints, sending out a different audio and
   video flow to each endpoint.  For audio, this might entail mixing
   some number of input flows that appear to contain audio intended to
   be heard by the other participants, with each endpoint receiving a
   flow that does not contain that participant's own audio.  For video,
   the traditional media server may elect to send only video showing the
   current active speaker, a tiled composition of all participants or
   the most recent active speakers, a video flow with the active speaker
   presented prominently with other participants presented as thumbnail
   images, or some other composite arrangement.  It is also common for
   audio or video to be transcoded.  A typical traditional media server
   is depicted in Figure 1.

                           +-------------------+
            +---+ --{A}--> |                   | <--{C}-- +---+
            | A |          | Media Composition |          | C |
            +---+ <-{BCD}- |                   | -{ABD}-> +---+
                           |    Transcoders    |
            +---+ --{B}--> |    Transraters    | <--{D}-- +---+
            | B |          |                   |          | D |
            +---+ <-{ACD}- |   Decrypt/Encrypt | -{ABC}-> +---+
                           +-------------------+

                     Figure 1 - Traditional Media Server

   Traditional media servers require a significant amount of processing
   power, which in turn translates into a high cost for conferencing
   hardware manufacturers.  Significantly, too, it is very difficult to
   deploy these servers in a cloud environment due to the high
   processing demands, as the specialized hardware found in the
   traditional media server does not exist in a cloud environment.





Jones, et al.          Expires January 6, 2016                  [Page 4]


Internet-Draft        Private Media Requirements               July 2015


   To enable the traditional media server to perform its job, the server
   establishes one or more SRTP sessions with each of the conference
   endpoints wherein it is given access to the keys required to decrypt
   and encrypt media flows from and to each endpoint.  This means that
   the traditional media server is necessarily a fully trusted entity in
   the communication path.  Any time these servers are deployed in a
   network that is not secured, it increases the risk that an adversary
   might gain access to cryptographic key material, allowing the
   adversary to be able to see and listen to ongoing conferences.  In
   some instances, depending on how the hardware is designed and how
   keys and certificates are managed, it might be possible for an
   adversary to see and listen to previously recorded conferences or
   future conferences.

   The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
   of RTP, which can provide confidentiality, message authentication,
   and replay protection to the RTP traffic and to the RTP Control
   Protocol (RTCP).  Encryption of header extension in SRTP [RFC6904]
   provides a mechanism extending the mechanisms of [RFC3711], to
   selectively encrypt RTP header extensions in SRTP.  [RFC3711] and
   [RFC6904] solves end-to-end use cases between two endpoints, and does
   not consider use cases where a sender delivers media to a receiver
   via a cloud-based conferencing service.

5. Motivation for Private Media using switching MDDs

5.1. Switching Media in Cloud Services

   There is a trend in the industry for enterprises to use cloud
   services to host multi-party conferences and meet-me services, either
   exclusively or to meet peak loads on-demand.  At the same time, there
   is shift toward using lightweight, cost-effective switching MDDs in
   cloud services that do not necessarily need to mix audio or
   composite/transcode video.  Also fueling the use of such lightweight
   MDDs is the desire to fully exploit virtualized computing resources
   and dynamic scalability potential available in cloud computing
   environments.

   The increased use of cloud services has exposed a problem.  There are
   two different trust domains from a media perspective: endpoints and
   other devices in a trusted domain, and MDDs controlled by the cloud
   service in an untrusted domain.  Other examples of conference devices
   spread across trusted and untrusted domains are likely, but the cloud
   service trend is triggering the urgency to address the need to allow
   for lightweight media conference while enabling media privacy at the
   same time.

   With a switching MDD, each endpoint transmits media as it would with
   a traditional media server.  However, the switching MDD merely
   forwards all or a subset of the media to the other endpoints in the
   conference (where at least one other endpoint may be associated with



Jones, et al.          Expires January 6, 2016                  [Page 5]


Internet-Draft        Private Media Requirements               July 2015


   a cascaded media distribution device), leaving composition to the
   receiving endpoint.  It is also worth noting that, for a switching
   MDD model to work successfully, each endpoint in the conference must
   support the media formats transmitted by all other endpoints in the
   conference.  More modern endpoints support multiple codecs and
   formats, making this commercially practical.

   Figure 2 depicts an example of a switching MDD wherein each endpoint
   is receiving the media flows transmitted by each of the other
   endpoints in the conference.

                           +--------------------+
            +---+ --{A}--> |                    | <-{C}--- +---+
            | A | <-{B}--- |   Switching MDD    | --{A}--> | C |
            |   | <-{C}--- |                    | --{B}--> |   |
            +---+ <-{D}--- |                    | --{D}--> +---+
                           |       Packet       |
            +---+ --{B}--> |   Authentication   | <-{D}--- +---+
            | B | <-{A}--- |                    | --{A}--> | D |
            |   | <-{C}--- |                    | --{B}--> |   |
            +---+ <-{D}--- |   Media Privacy    | --{C}--> +---+
                           +--------------------+

               Figure 2 - Switching Media Distribution Device

   Note - The use of multiple arrows directed toward each endpoint is
   not intended to suggest the use of separate RTP sessions.

   By using methods such as those described in [RFC6464], it is possible
   for the switching MDD to transmit the appropriate audio and video
   flows to endpoints without having knowledge of the content of the
   encrypted media.  The following "Active Speaker Switching" examples
   help illustrate this point.

   In Figure 3, endpoints A, B and D receive the video streams from
   endpoint C, the currently active speaker, which is receiving video
   from endpoint A, the previous active speaker.  Later when endpoint B
   becomes the active speaker (Figure 4), endpoints A, C and D will
   start to receive video from B, while endpoint B continues to receive
   video from endpoint C.  Finally in Figure 5, endpoint A becomes the
   active speaker.













Jones, et al.          Expires January 6, 2016                  [Page 6]


Internet-Draft        Private Media Requirements               July 2015


                           +--------------------+
            +---+ --{A}--> |                    | <--{C}-- +---+
            | A |          |   Switching MDD    |          | C |*
            +---+ <-{C}--- |                    | ---{A}-> +---+
                           |                    |
            +---+ --{B}--> |                    | <--{D}-- +---+
            | B |          |                    |          | D |
            +---+ <-{C}--- |                    | ---{C}-> +---+
                           +--------------------+

                Figure 3 - Endpoint "C" is the Active Speaker

                           +--------------------+
            +---+ --{A}--> |                    | <--{C}-- +---+
            | A |          |   Switching MDD    |          | C |
            +---+ <-{B}--- |                    | ---{B}-> +---+
                           |                    |
            +---+ --{B}--> |                    | <--{D}-- +---+
           *| B |          |                    |          | D |
            +---+ <-{C}--- |                    | ---{B}-> +---+
                           +--------------------+

                Figure 4 - Endpoint "B" is the Active Speaker

                           +--------------------+
            +---+ --{A}--> |                    | <--{C}-- +---+
           *| A |          |   Switching MDD    |          | C |
            +---+ <-{B}--- |                    | ---{A}-> +---+
                           |                    |
            +---+ --{B}--> |                    | <--{D}-- +---+
            | B |          |                    |          | D |
            +---+ <-{A}--- |                    | ---{A}-> +---+
                           +--------------------+

                Figure 5 - Endpoint "A" is the Active Speaker

   Switched media can also enable conferences to scale to include many
   more endpoints simultaneously than would be possible with a
   traditional media server.  Like traditional media servers, switching
   MDDs can also be cascaded or interconnected in a meshed topology to
   increase the size of the conference without putting undue burden on
   any particular server.

5.2. Private Media Security through Switching

   A traditional media server, or MCU, establishes an SRTP session with
   each endpoint separately, and needs to decrypt packets containing
   media for presentation to other endpoints.  By using a switching MDD,
   it is possible to keep the media encryption keys private to the
   endpoints such that the MDD does not have access to the keys used for




Jones, et al.          Expires January 6, 2016                  [Page 7]


Internet-Draft        Private Media Requirements               July 2015


   media encryption.  The switching MDD just forwards media received to
   each of the other endpoints in the conference.

   This provides for a significantly improved security model, as one
   can, for example, utilize conferencing resources in the cloud that do
   not have to be trusted.  That said, there may be situations where the
   switching MDD needs to modify the RTP packet received from an
   endpoint, such as by adding or removing an RTP header extension,
   modifying the payload type value, etc.  It would be the
   responsibility of the switching MDD to ensure that media of the
   expected type and containing the correct information is received by a
   recipient.

   Thus, there is a need to utilize an end-to-end encryption and
   authentication key (or pair of keys) and a hop-by-hop encryption and
   authentication key (or pair of keys).  The end-to-end encryption and
   authentication key(s) is to ensure that media remains private to the
   trusted endpoints.  The hop-by-hop authentication key allows the
   switching MDD to authenticate RTP and RTCP packets and to optionally
   modify certain elements of those packet.  The hop-by-hop encryption
   key is to optionally encrypt RTP header extensions and optionally
   encrypt RTCP packets.  The current SRTP and related specifications do
   not define use of a dual-key (hop-by-hop and end-to-end) approach.
   However, such an approach is possible and would result in ensuring
   the privacy of media while also enabling the more scalable switched
   conferencing model.

   This dual-key model does necessitate a change in the way that keys
   are managed.  However, the topic of key management is outside the
   scope of this requirements document.  High-level assumptions, such as
   if the end-to-end context uses a group key as SRTP master key or if
   individual SRTP master keys (that may be derived/negotiated from
   another group key), are likely to influence the solution derived from
   this document.

6. Private Media Trust Model

   The architectural model suggested in this document enables switching
   MDDs to be hosted in domains in which the network elements may have
   low trust, or where the trustworthiness is uncertain.  This does not
   mean that the service provider is completely untrusted; it simply
   means that high enough trust with media decryption is not required.
   This has the benefit of protecting the endpoint's media in the case
   of external attacks against the MDD.

   In this model, certain elements are considered trusted and others are
   considered untrusted.  Trust in the context of this document means
   that the element can be in possession of the media encryption key(s)
   for a past, current, or potentially future conference (or portion
   thereof) used to protect media content.




Jones, et al.          Expires January 6, 2016                  [Page 8]


Internet-Draft        Private Media Requirements               July 2015


   In the general case, only the endpoint and an associated key
   management function, which may be integrated with the endpoint or in
   a separate stand-alone entity, needs to be trusted.  However, it is
   recognized that in certain deployments, some elements that are
   classified as untrusted in this document might be placed into the
   trusted domain and thus be considered trusted.  One example might be
   a gateway, traditional media server or other MDD in a trusted
   environment connecting endpoints to the same private media
   conference.  This document does not preclude such deployment
   combinations, but does not rely on them in order to keep the examples
   and model definitions focused on the simple, most general case.

   Each of the elements discussed below has a direct or indirect
   relationship with each other.  The following diagram depicts the
   trust relationships described in the following sub-sections and the
   media or signaling interfaces that exist between them, showing the
   trusted elements on the left and untrusted elements on the right.
   Note that this is a functional diagram and elements may be co-located
   or further divided into multiple separate physical entities.
   Further, it is not necessary that every interface exist between all
   elements, such as both an interface from the endpoint and call
   processing function to a key management function, though both are
   possible options.

                                     |
                                     |
                 +----------+        |       +-----------------+
                 | Endpoint |        |       | Call Processing |
                 +----------+        |       +-----------------+
                                     |
                                     |
              +----------------+     |       +-----------------+
              | Key Management |     |       | Switching Media |
              |    Function    |     |       |     Server      |
              +----------------+     |       +-----------------+
                                     |
                   Trusted           |            Untrusted
                   Elements          |            Elements
                                     |
                                     |

          Figure 6 - Relationship of Trusted and Untrusted Elements

6.1. Trusted Elements

   The endpoint is considered a trusted element, as it will be sourcing
   media flows transmitted to other endpoints and will be receiving
   media for rendering.  While it is possible for an endpoint to be
   compromised and perform in unexpected ways, such as transmitting a
   decrypted copy of media content to an adversary, such security issues
   and defenses are outside the scope of this document.



Jones, et al.          Expires January 6, 2016                  [Page 9]


Internet-Draft        Private Media Requirements               July 2015


   The other trusted element is a key management function (KMF), which
   may be integrated with the endpoints or exist standalone.  This
   function is responsible for providing cryptographic keys to the
   endpoints for encrypting and authenticating media content.  The KMF
   is also responsible for providing cryptographic keys to the
   conferencing resources, such as the MDD, to enable authentication of
   media packets received by an endpoint.  Interaction between the KMF
   and untrusted call processing functions may be necessary to ensure
   endpoints are delivered the appropriate keys.  The KMF needs to be
   tightly controlled and managed to prevent exploitation by an
   adversary, as any kind of security compromise of the KMF puts the
   security of the conference at risk.

6.2. Untrusted Elements

   The call processing function is responsible for such things as
   authenticating the user or endpoint for the purpose of joining a
   conference, signing messages, and processing call signaling messages.
   This element is responsible for ensuring the integrity, and
   optionally the confidentiality, of call signaling messages between
   itself, the endpoint, and other network elements.  However, it is
   considered an untrusted element for the purposes of this document, as
   it cannot be trusted to have access to or be able to gain access to
   cryptographic key material that provides privacy and integrity of
   media packets.

   There might be several independent call processing functions within
   an enterprise, service provider network, or the Internet that are
   classified as untrusted.  Any signaling information that passes
   through these untrusted entities is subject to inspection by that
   element and might be altered by an adversary.

   Likewise, there may be certain deployment models where the call
   processing function is considered trusted.  In such cases, trusted
   call processing functions MUST take responsibility for ensuring the
   integrity of received messages before delivering those to the
   endpoint.  How signaling message integrity is ensured is outside the
   scope of this document, but might use such methods as defined in
   [RFC4474].

   The final element is the switching MDD, which is responsible for
   forwarding encrypted media packets and conference control information
   to endpoints in the conference.  It is also responsible for conveying
   secured signaling between the endpoints and the key management
   function, acquiring per-hop authentication keys from the KMF, and
   performing per-hop authentication operations for media packets.  This
   function might also aggregate conference control information and
   initiate various conference control requests.  Forwarding of media
   packets requires that the switching MDD have access to RTP headers or
   header extensions and potentially modify those message elements, but




Jones, et al.          Expires January 6, 2016                 [Page 10]


Internet-Draft        Private Media Requirements               July 2015


   the actual media content MUST not be decipherable by the switching
   MDD.

   Further, the switching MDD does not have the ability to determine
   whether an endpoint is authorized to have access to media encryption
   keys.  Merely joining a conference MUST NOT be interpreted as having
   authority.  Media encryption keys are conveyed to the endpoint by the
   KMF in such a way as to prevent the switching MDD from having access
   to those keys.

   It is assumed that an adversary might have access to the switching
   MDD and have the ability to read any of the contents that pass
   through.  For this reason, it is untrusted to have access to the
   media encryption keys.

   As with the call processing functions, it is appreciated that there
   may be some deployments wherein the switching MDD is trusted.
   However, for the purposes of this document, the switching MDD is
   considered untrusted so that we can be ensure to develop a solution
   that will work even in the most hostile environments.

   It is expected that a switching MDD performs its role in properly
   forwarding media packets, taking measures to safeguard against replay
   attacks, etc.  If a MDD is exploited, an adversary may do such things
   as discard packets, replay packets, or introduce unacceptable delay
   in packet delivery.

7. Goals and Non-Goals

7.1. Goals

7.1.1. Ensure End-To-End Confidentiality

   The content of the communication and all media needs to be
   confidential within the group of entities explicitly invited into the
   conference.  An external monitoring adversary should not be able to
   deduce the human-to-human communication that actually occurred from
   capturing the media packets.

   At the same time, it is necessary to allow switching MDDs to
   manipulate certain RTP header fields like the payload type value.

7.1.2. Ensure End-To-End Source Authentication of Media

   In a conference system with multiple endpoints it is vital that the
   media content presented to any of the human participants is from the
   stated endpoint, and not an adversary that attempts to inject
   misleading content.  Nor should an adversary be able to fool the
   system into becoming a trusted party in the conference.  Only
   explicitly invited parties shall be able to contribute content.




Jones, et al.          Expires January 6, 2016                 [Page 11]


Internet-Draft        Private Media Requirements               July 2015


7.1.3. Provide a More Efficient Service than "Full-Mesh"

   A multi-party conference that has the goals of confidentiality and
   source authentication can be established as a "full mesh" (i.e., each
   participating endpoint directly addresses each of the other
   endpoints).  However, this has a significant issue with the amount of
   consumed resources in both the uplink and the downlink from each
   endpoint.

   A switched conferencing model would yield the efficiencies desired.

7.1.4. Support Cloud-Based Conferencing

   To achieve cost-effective and scalable conferencing, it must be
   possible to run the MDD instances in a cloud-based virtualized
   environment.

   From a security standpoint, this is a significant issue since the
   virtualized server instance and the underlying hardware and software
   upon which it runs might not be secure from an adversary.

7.1.5. Limiting an Endpoint's Access to Content

   Since an invited endpoint will be provided with the content
   protection keys, the endpoint can decrypt content from time periods
   before and after the endpoint joined the conference.  However, this
   is not always desirable.  It should be possible to re-key the content
   protection keys every time a participant joins or leaves the
   conference so each particular set of endpoints uses a unique key.

   This also changes the trust level required on the conference roster
   handling at any point and how to keep that accurate and secured.

   It should be noted that timely completion of the re-keying operations
   become an obstacle in system design and operation.  Thus, it is a
   goal to allow for this possibility when it is deemed essential, but
   it should not be a requirement on a system to re-key each time the
   participant list changes.

7.1.6. Compatibility with the WebRTC Security Architecture

   It is a goal of this work to ensure compatibility with the WebRTC
   security architecture as described in [I.D-rtcweb-security-arch].  As
   an example, local resources that are considered a part of the trusted
   computing base (TCB), such as keying material derived using DTLS-
   SRTP, will remain within the TCB and not exposed to untrusted
   entities.

   The browser is reliant on an external calling service to convey
   signaling information that may open the door for a man-in-the-middle
   attack, such as the conveyance of certificate fingerprints over the



Jones, et al.          Expires January 6, 2016                 [Page 12]


Internet-Draft        Private Media Requirements               July 2015


   interface between the browser and the calling service.  However, as
   described in [I.D-rtcweb-security-arch], the browser may utilize
   additional services, such as a trusted identify provider, to mitigate
   such risks.

   Having said the foregoing, this document does not aim to define
   requirements for end-to-end security for the WebRTC data channel.

7.2. Non-Goals

7.2.1. Securing the Endpoints

   The security of a communication session requires that the endpoints
   are not compromised and that the users are trustworthy.  If not,
   credentials and decrypted content may be shared with third parties.
   However, this is hard to prevent through system design.  Thus, it
   should be assumed that the endpoint is secure and the user is
   trustworthy; how to achieve this is out of scope this document.

7.2.2. Concealing that Communication Occurs

   A non-goal is to attempt to prevent a pervasive monitoring adversary
   from knowing that the communication session has occurred.  The reason
   for excluding this as a goal is that it is extremely difficult to
   achieve, as a pervasive monitoring adversary can be expected to be
   able to have knowledge of all IP flows that enter or exit local ISPs,
   across links that straddle national borders or internet exchange
   points.  To hide the fact communication occurred, the flows required
   to achieve the communication session need to be highly difficult to
   correlate between different legs of the communication.

   At this stage this is deemed too difficult to attempt and will need
   to be a subject for further study.  Existing attempts include The
   Onion Router (TOR), against which it has been claimed to be possible
   to monitor, at least partially, by an adversary with sufficient
   reach.

   Also of consideration is that trying to conceal the fact that
   communication occurred actually makes it more difficult for network
   administrators to effectively manage and troubleshoot issues with
   conference calls.

7.2.3. Individual Media Source Authentication

   Although the endpoints in the conference are authenticated, it is not
   a goal to provide source authentication of the media at the
   individual user level, instead being satisfied with being able to
   authenticate media as coming from an invited endpoint or not.

   There exist solutions that can provide individual media source
   authentication (e.g., TESLA).  However, they impact the performance



Jones, et al.          Expires January 6, 2016                 [Page 13]


Internet-Draft        Private Media Requirements               July 2015


   or security properties they provide.  Thus, further study is required
   to determine impact and resulting security properties if desired to
   have individual source authentication.

7.2.4. Multicast -based Conferencing

   Using multicast to construct a non-centralized media distribution
   model is out of scope.  This document is focused only on models where
   endpoints, or other devices, participating in a conference unicast
   media to a centrally located media distribution device.

8. Requirements

   The following are the security solution requirements for switched
   conferencing that enable end-to-end media privacy between all
   endpoints.

   Note that while some switching MDDs might be fully trusted entities,
   the intent of this solution and purpose for these requirements is to
   address those servers that are not trusted.

   PM-01:  Switching media distribution device MUST be able to switch
           the media between endpoints in a conference without having
           access to unencrypted media content.

   PM-02:  Solution MUST maintain all current SRTP security goals,
           namely the ability to provide for end-to-end confidentiality,
           provide for hop-by-hop replay protection, and ensure hop-by-
           hop and end-to-end message integrity.

   PM-03:  Solution MUST extend replay protection to cover each hop in
           the media path, both ensuring that any received packet is
           destined for the recipient and not a duplicate.

   PM-04:  Keys used for end-to-end encryption and authentication of RTP
           payloads and other information deemed unsuitable for access
           by the switching media distribution device MUST NOT be
           generated by or accessible to any component that is not
           trusted.

   PM-05:  The switching media distribution device MUST be allowed to
           make changes to the RTP header and the RTP header extensions.

   PM-06:  A cryptographic context suitable for enabling end-to-end
           authenticated encryption MUST be defined.

   PM-07:  The switching media distribution device, or any entity that
           is not fully trusted, MUST NOT be involved in the user or
           endpoint authentication for the purpose of media key
           distribution.




Jones, et al.          Expires January 6, 2016                 [Page 14]


Internet-Draft        Private Media Requirements               July 2015


   PM-08:  The switching media distribution device MUST be able to
           switch an already active RTP stream to a new receiver, while
           guaranteeing the timely synchronization between the RTP
           security context of the transmitter and its current and new
           receivers.

   PM-09:  It MUST be possible for the switching media distribution
           device to determine if a received media packet was
           transmitted by an endpoint in possession of a valid hop-by-
           hop key for that conference.

   PM-10:  It MUST be possible for a conference to be optionally re-
           keyed as desired, such as each time a participant joins or
           leaves the conference.

   PM-11:  Any solution satisfying this requirements document MUST
           provide for a means through which WebRTC-compliant endpoints
           can participate in a switched conference using private media
           as outlined herein.

   PM-12:  All RTP senders, including the switching media distribution
           device, MUST adhere to all congestion control requirements
           that are required by the RTP profile and topology in use,
           including RTP circuit breakers [I.D-ietf-avtcore-rtp-circuit-
           breakers].  Since the switching media distribution device is
           unable to perform transcoding or transrating that requires
           access to the unencrypted media, its reaction to congestion
           signals is often limited to dropping packets that would
           otherwise be forwarded in the absence of congestion, and
           signaling congestion to the RTP source.  This is similar to
           the congestion control behavior of the Media Switching Mixer
           and Selective Forwarding Middlebox/Unit in [I.D-ietf-avtcore-
           rtp-topologies-update].

   PM-13:  It MUST be possible for a media distribution device or an
           endpoint to authenticate a received RTCP packet.

9. IANA Considerations

   There are no IANA considerations for this document.

10. Security Considerations

   [TBD]

11. References

11.1. Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.



Jones, et al.          Expires January 6, 2016                 [Page 15]


Internet-Draft        Private Media Requirements               July 2015


   [RFC3711]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
               Norrman, "The Secure Real-time Transport Protocol
               (SRTP)", RFC 3711, March 2004.

   [RFC6464]   Lennox, J., Ivov, E., and E. Marocco, "A Real-time
               Transport Protocol (RTP) Header Extension for Client-to-
               Mixer Audio Level Indication", RFC 6464, December 2011.

   [I.D-rtcweb-security-arch]
               E. Rescorla, "WebRTC Security Architecture", Work in
               Progress, March 2015.

   [RFC6904]   J. Lennox, "Encryption of Header Extensions in the Secure
               Real-time Transport Protocol (SRTP)", RFC 6904, December
               2013.

   [I.D-ietf-avtcore-rtp-topologies-update]
               Westerlund, M., and S. Wenger, "RTP Topologies", Work in
               Progress, March 2015.

   [I.D-ietf-avtcore-rtp-circuit-breakers]
               Perkins, C. S., and V. Singh, "Multimedia Congestion
               Control: Circuit Breakers for Unicast RTP Sessions", Work
               in Progress, March 2015.

11.2. Informative References

   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M., and E.
               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
               June 2002.

   [RFC4474]   Peterson, J. and C. Jennings, "Enhancements for
               Authenticated Identity Management in the Session
               Initiation Protocol (SIP)", RFC 4474, August 2006.

12. Acknowledgments

   The authors would like to thank Marcello Caramma, Matthew Miller,
   Christian Oien, Magnus Westerlund, Cullen Jennings, Christer
   Holmberg, Bo Burman, Jonathan Lennox, Suhas Nandakumar, Dan Wing,
   Roni Even, and Mo Zanaty for their invaluable input.












Jones, et al.          Expires January 6, 2016                 [Page 16]


Internet-Draft        Private Media Requirements               July 2015


13. Contributors

   Yi Cheng
   Ericsson
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 17 589
   Email: yi.cheng@ericsson.com













































Jones, et al.          Expires January 6, 2016                 [Page 17]


Internet-Draft        Private Media Requirements               July 2015


Authors' Addresses

   Paul E. Jones
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709
   USA

   Phone: +1 919 476 2048
   Email: paulej@packetizer.com


   Nermeen Ismail
   Cisco Systems, Inc.
   170 W Tasman Dr.
   San Jose
   USA

   Email: nermeen@cisco.com


   David Benham
   Cisco Systems, Inc.
   170 W Tasman Dr.
   San Jose
   USA

   Email: dbenham@cisco.com


   Nathan Buckles
   Cisco Systems, Inc.
   170 W Tasman Dr.
   San Jose
   USA

   Email: nbuckles@cisco.com


   John Mattsson
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 43 501
   Email: john.mattsson@ericsson.com


   Richard Barnes
   Mozilla
   331 E Evelyn Ave.



Jones, et al.          Expires January 6, 2016                 [Page 18]


Internet-Draft        Private Media Requirements               July 2015


   Mountain View
   USA

   Email: rlb@ipv.sx


















































Jones, et al.          Expires January 6, 2016                 [Page 19]


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