Internet DRAFT - draft-jones-perc-private-media-reqts
draft-jones-perc-private-media-reqts
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]
