Internet DRAFT - draft-westerlund-perc-webrtc-use-case
draft-westerlund-perc-webrtc-use-case
Network Working Group M. Westerlund
Internet-Draft J. Mattsson
Intended status: Informational Ericsson
Expires: April 21, 2016 October 19, 2015
WebRTC Use Case and Framework for Privacy Enhanced RTP Conferencing
(PERC)
draft-westerlund-perc-webrtc-use-case-01
Abstract
The work so far on Privacy Enhanced RTP Conferencing, which allows
end-to-end security also in centralized switched RTP based
conferences, has not considered WebRTC in detail. This document
looks at the use case of WebRTC based endpoints, it also considers
implications of using external providers for both conference
applications and centralized media distribution devices. From this a
number of challenges have been determined, and requirements are
derived from these. Finally the draft presents some straw man for
possible solutions.
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 April 21, 2016.
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
Westerlund & Mattsson Expires April 21, 2016 [Page 1]
Internet-Draft WebRTC use cases in PERC October 2015
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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. The Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Entities and Trust . . . . . . . . . . . . . . . . . . . . . 4
3.1. Trust Domains . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 5
3.3. Semi-trusted Entities . . . . . . . . . . . . . . . . . . 6
4. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Enable Delegation . . . . . . . . . . . . . . . . . . . . 7
4.2. Dealing with JavaScript related Attacks . . . . . . . . . 8
4.3. Forcing End-to-End Security . . . . . . . . . . . . . . . 8
4.4. Restricting Usage of the e2e Keying Material . . . . . . 9
4.5. Enabling Flexible Authentication . . . . . . . . . . . . 9
4.6. Binding Authorization to Endpoint . . . . . . . . . . . . 9
4.7. Secure Binding of e2e Source Identifier to User Name or
Alias . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Securing Group Membership Changes . . . . . . . . . . . . 9
4.9. Key Revocation . . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Solution Straw-man . . . . . . . . . . . . . . . . . . . . . 12
6.1. High Level Example Message Flows . . . . . . . . . . . . 12
6.2. Authentication and Authorization . . . . . . . . . . . . 13
6.3. Key Management . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
This document discusses the implications on PERC WG's work on
providing end-to-end secure centralized RTP conferencing using WebRTC
browsers as endpoints. The WebRTC environment contains a number of
challenges that needs to be considered; these may affect how the
final solution is designed. The authors have also have a strong
interest in enabling usages where significant amount of sourcing of
external resources are possible to perform. Not only the media
distribution devices (MDD) and STUN/TURN resources, but also the core
functionalities of the conference application, such as the find and
connect to establish the conference. However, the control over the
Westerlund & Mattsson Expires April 21, 2016 [Page 2]
Internet-Draft WebRTC use cases in PERC October 2015
end-to-end security needs to be possible to maintain within a single
organization. This organization needs to maintain control over both
who is authorized to participate in a particular conference, as well
as having control over the end-to-end keys used in that conference.
It needs to be stressed that the use case presented here is far from
the only one where WebRTC endpoints could be used to establish a
multiparty end-to-end secured conference. The authors have chose to
focus on use case that combines WebRTC endpoints, contextual
communication and outsourcing, a use case suitable for a number of
enterprises, businesses, and services.
Section 2 goes through a possible use case and its high level
motivation. Section 3 discusses the different trust domains as well
as the entities that are considered in this use case. Section 4
discusses a number of challenges where several are unique to WebRTC
compared to more native implementations of endpoints. Section 5
derives a number of requirements. Finally in Section 6 we present a
straw man solution to some of the challenges we raised.
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].
2. The Use Case
This section discusses the representative use case in more detail as
well as discussing relevant background information for this use case.
A use case (Enterprise Real-time contextual communication) is that an
enterprise has the need for multi-party real-time conferencing with
audio and video that is combined with enterprise's internal data that
can be viewed and manipulated using a web application. The
conferencing is intended to allow multiple employees or external
consultants to discuss the data and manipulate its content as well as
present during the discussion, i.e. a form of contextual
communication.
The already existing web application to view and manipulate the
internal data is desirable to be able to re-use and the conference
participants are already using a web browser for this purpose. Thus,
basing the solution on WebRTC appears logical as that will enable
integration of the Real-time communication (RTC) conferencing part
with the existing web application.
The enterprise has no desire to maintain substantial RTC
infrastructure to ensure well working conferencing, and prefers to
source the needed services and components from external providers.
Westerlund & Mattsson Expires April 21, 2016 [Page 3]
Internet-Draft WebRTC use cases in PERC October 2015
However, the enterprise has strong interests in maintaining control
of the security properties and ensure that its security goals are
meet, it may even have legal requirements on its communication.
The enterprise already has existing methods for authenticating their
employees, consultants and other external parties that have some
access rights to the enterprise's data. It would be highly desirable
to be able to re-use the existing user database and authorization
verification.
3. Entities and Trust
This section discusses various entities and the trust in these roles.
3.1. Trust Domains
The entities belong to three different trust domains:
Trusted: Entities in the trusted domain are fully trusted to perform
the role and actions put on them. They may have access to
unprotected content and keying material used to protect content
end-to-end.
Semi-trusted: Semi-trusted entities have no access to confidential
material such as the content and the keying material used to
protect content end-to-end. They are however trusted to perform
basic operations for selective forwarding of content as well as
session establishment.
Untrusted: Entities and functions in this domain are not trusted by
the other entities participating in the conference or system.
These entities are capable of preventing the conference from
functioning, however.
The entities in the trusted and semi-trusted domains are show in
Figure 1, and described in more detail in Sections 3.2 and 3.3. Note
that part of the "endpoint" is trusted, while other parts are only
semi-trusted. A PERC conference involves more than one conference
participant and may involve several MDDs.
Westerlund & Mattsson Expires April 21, 2016 [Page 4]
Internet-Draft WebRTC use cases in PERC October 2015
|
+------------------------+ | +------------------------+
| Service Provider | | | Conference Provider |
+------------------------+ | +------------------------+
|
+------------------------+ | +------------------------+
| Conference Initiator | | | Call Processing |
+------------------------+ | +------------------------+
|
+------------------------+ | +------------------------+
| Key Management | | | Media Distribution |
| Function (KMF) | | | Device (MDD) |
+------------------------+ | +------------------------+
|
+------------------------+ | +------------------------+
| Conference Participant | | | STUN/TURN |
+------------------------+ | +------------------------+
|
+-Endpoint------------------------------------------------+
| +--------------------+ : +--------------------+ |
| | Core | : | Conference | |
| | Application | : | Application | |
| +--------------------+ : +--------------------+ |
| +--------------------+ : |
| | User Agent (UA) | : |
| +--------------------+ : |
+---------------------------------------------------------+
|
|
Trusted | Semi-trusted
Figure 1: Entities in the Trusted and Semi-trusted Domains
3.2. Trusted Entities
The trusted entities that we consider in the use case are:
The Service Provider: The service provider is the organization that
establishes the requirement for the end-to-end security in its RTC
conference. It also has the control over entities that provide
functionalities in the trusted domain for enabling the conference,
such as the Key-Management Function and the Core Application.
This represents the enterprise in the above use case description.
Conference Initiator: A human that schedules a conference. The
conference contains a number of invited conference participants.
These and only these participants shall be able to join this
conference.
Westerlund & Mattsson Expires April 21, 2016 [Page 5]
Internet-Draft WebRTC use cases in PERC October 2015
Conference Participant: A conference participant is a human or
possibly another type of entity, like a conference room that has
one or more identities that has been invited into the conference.
User Agent: The user agent is the WebRTC enabled endpoint that the
conference participant uses to join the conference. In this
document this is assumed to be a browser.
Core Application: The web application residing both in the service
provider's server as well as the web based application in the User
Agent. Should be able to delegate almost everything to the
Conference Application. Non RTC content part of a contextual
application is generally handled by this application.
Key Management Function: The function within the service provider
that generates, stores and distributes the keys giving access to
the conference to User Agents that can provide identity assertions
that it can be verified and matches the invited participants.
Authorization Module: A sub-function of the Key Management Function
(KMF) that verifies identity assertions according to a particular
authorization method.
Conference Session Database: A sub-system of the KMF that contains
information about scheduled conferences and which identities that
have been invited by the Conference Initiator.
3.3. Semi-trusted Entities
The semi-trusted entities that we consider in the use case are:
Conference Provider: Provides the conferencing service, potentially
from within a separate administrative domain than the service
provider. This service contains find and connect functions to
establish the conference, media distribution devices to
selectively forward protected media content to the conference
participants as well as support functions for media path
establishment such as STUN and TURN services.
Conference Application: The web application residing both in the
conference provider's servers as well in the User Agent that
performs find and connect and other functions to establish and
maintain the conference.
Media Distribution Devices: A device that performs switching and
forwarding of protected media to the various conference
participants' user agents or to another cascading media
distribution device. The switching is performed based on meta
Westerlund & Mattsson Expires April 21, 2016 [Page 6]
Internet-Draft WebRTC use cases in PERC October 2015
information about the content that has been provided by the user
agent. It applies security policies that prevent forwarding of
traffic not originating with a user agent that is an invited
participant. This protection is through a hop-by-hop security
mechanism that provides integrity and source authentication as
well as confidentiality of the metadata.
STUN/TURN: Support functions that help establish the transport path
used to send media between a user agent and the media distribution
device.
4. Challenges
This section discusses a number of challenges in meeting the goals as
discussed in [I-D.jones-perc-private-media-reqts].
4.1. Enable Delegation
As described above, the Service Provider delegates the communication
service to the Conference Provider. The Conference Provider may in
turn delegate functions like the media distribution device and STUN/
TURN services by sourcing them from other providers. Further, the
infrastructure (servers and network) that these functions are run on,
can also be sourced from external providers. This puts even higher
demands on control and the ability to verify other entities actions
from the perspective of the Service Provider.
The main security goal of providing end-to-end confidentiality across
a centralized conferencing infrastructure is the main enabler of
delegation, as the required trust in large part of the infrastructure
are significantly reduced by freeing them from handle any content as
plain-text. However, that is not sufficient as not only the content
handling needs to be limited to only the entities that are required
to handle it. Also the key-management and authorization parts of the
solution need to consider how they can limit the trust. For example
the find and connect service is a semi-trusted part as it needs to be
capable of establishing the connectivity with the right entities.
However, the key-management and authorization system is the one that
verifies the participants and their right to participate in a
particular conference, and first then provides that participant's
endpoint with the necessary secrets.
The system design needs to minimize the privacy sensitive information
a particular functions needs. Thus, enabling as much functionality
as possible to be outside of the trusted domain. Important functions
in the semi-trusted domain, when so necessary to ensure secure
operation of the system, must be verified by trusted entities.
Westerlund & Mattsson Expires April 21, 2016 [Page 7]
Internet-Draft WebRTC use cases in PERC October 2015
4.2. Dealing with JavaScript related Attacks
The application, such as JavaScript application, running in the
browser is a potential attack vector. Using various attacks,
including cross-site scripting, the application can be compromised
and perform the actions an attacker dictates. Even if the
application running in the browser is malicious it must not be able
to compromise the security of the conference, only perform denial of
service attacks such as preventing the user from joining the
conference.
A compromised application must be prevented from getting access to
content. This will most likely mean that when using the end-to-end
confidentiality, corresponding measures to prevent forwarding (of
plain text content), access to raw data through APIs etc. that the
media confidentiality mode defined in [I-D.ietf-rtcweb-alpn] have to
be applied.
The compromised application will get access to who the peer(s) are in
the conference. This is unpreventable as the application is the
responsible for establishing the communication legs that is creating
the conference. An attacker will also be able to use a compromised
entity to forward protected content to a destination of its choice.
4.3. Forcing End-to-End Security
The Service Provider needs a method to ensure that when the
conference provider application launches the RTCPeerConnections, they
are forced to use end-to-end security with the keys provided by the
KMF the Service Provider designates, and not normal hop-by-hop
security only or end-to-end security with other keys. Thus, the
service provider needs a way of applying policies on an web
application context, or the conference participants must actively
check and understand information in the browser chrome. This first
approach could e.g. be done as the Service Provider web server
setting policies and restrictions that the UA enforces towards the
JavaScript. Policies that are inherited by any child contexts and
which can't be modified by the application in the user agent. A user
clicking the correct link would then be secure. The second approach
seems to give much weaker security as the average user do not look
for security information and do not understand it. A desirable model
is that of HTTPS, as long as an end user enters the correct URL, they
are guaranteed e2e security.
Westerlund & Mattsson Expires April 21, 2016 [Page 8]
Internet-Draft WebRTC use cases in PERC October 2015
4.4. Restricting Usage of the e2e Keying Material
While the RTCPeerConnection must use end-to-end security with the key
provided by the Service Provider, neither the core or conference
applications must be able to extract the key or even use the e2e key
material for anything other than encrypted key transport (EKT) as
this may lead to information leakage by e.g. so called two-time pad.
The user-agent will be required to have a secure key-store for the
duration the key-material is present at the user-agent and valid.
When the validity of the key-material expires the key-material needs
to be disposed of to reduce the risk of retrospective attacks.
4.5. Enabling Flexible Authentication
The authorization methods should be flexible and enable different
types of authorization back-ends. It is desirable that the method
for authorization does not need to be implemented as part of the user
agent. Requiring user agent modifications makes deployment of new
authorization method cumbersome and difficult and open up for down
grade attacks due to need for backwards compatibility support.
4.6. Binding Authorization to Endpoint
As the authorization will be used to retrieve the group key used to
secure the RTP session end-to-end, it is important that the
authorization is bound to the device and user agent where the user
gave the authorization. Otherwise the conference provider would be
able to move the authorization credentials to another endpoint, use
that endpoint to retrieve the key and export it from that endpoint.
4.7. Secure Binding of e2e Source Identifier to User Name or Alias
In many usages, it is important that the conference participants can
see in real-time who is participating and who is talking. This
requires that the endpoint can map the e2e source identifier to the
user name. The list of participant names as well as the binding to
the e2e source identifiers needs to be authenticated by a trusted
party to prevent attacks where an semi-trusted entity suggests an
incorrect binding between an e2e Source Identifier and a user name.
4.8. Securing Group Membership Changes
During an ongoing conference the set of participants participating in
a conference will vary. In some usages a late joining participant
should get access to keying material to decrypt a conference
recording. In other usages it is important that joining participant
can not use the received keying material to perform a retrospective
attack and decrypt the content of the conference from a point prior
Westerlund & Mattsson Expires April 21, 2016 [Page 9]
Internet-Draft WebRTC use cases in PERC October 2015
to the participant joining. Nor should the participant after having
left the conference be able continue to decrypt the content.
The known solution to this issue is to switch keys, both group key as
well as the transport keys each endpoint uses to protect its streams.
This puts certain requirements on key-management system. First the
key-management system must track the current set of participants and
on changes initiate the change of the group key. This results in a
second requirement that they key distribution method for the group
key can handle asynchronous distribution events in the KMF to
endpoint direction. Thirdly the transport key switching and
distribution needs to handle non-synchronized switching by the
different endpoints to the new group key.
A clear issue is how the KMF can ensure that a participant that is
leaving is correctly accounted for and the key change happens in a
timely fashion after the user left. First of all users may leave the
conference abruptly due to severed communication or an endpoint that
crashes. Secondly, the conference management application is only
semi-trusted. The design will have to make choices on how to balance
protocol complexities, resource consumption and achieved security
properties.
An additional complexity with this mode of operation is that the
conference participant likes to in a secure way know which other
participants that currently are part of the conference. This
information needs to be timely updated, and the current rooster needs
to be authenticated to prevent attacks where participants are fooled
to believe a particular participant has left, but is in fact still in
the conference.
4.9. Key Revocation
The conference e2e group key is only required to reside on an
endpoint for the duration its in use. That use is limited by the
duration of the conference. When the conference ends there are no
reasons to retain the key on the endpoint. Thus, when the conference
ends it is desirable to have the key be revoked and deleted from the
endpoint. This should be possible to initiate from the KMF when it
learns that the conference has ended.
The user agent should upon the user closing the browsing context
where the application runs deleting the keys to prevent their
leakage.
Westerlund & Mattsson Expires April 21, 2016 [Page 10]
Internet-Draft WebRTC use cases in PERC October 2015
5. Requirements
This section lists a number of derived requirements from the above
challenges. The requirements are:
a. The Web application running in the User Agent MUST NOT be able to
compromise the content confidentiality.
1. Including getting access to media content (raw or
unencrypted) in the user agent through API or shared
resources.
b. The conference provider's application (server as well as in the
user agent) MUST NOT be able to downgrade the intended security
properties and policies established by the service provider and
the core application.
c. The key material for the end-to-end protection MUST NOT be
possible to extract from any web application.
1. The user agent MUST protect the key-material against
extraction by user or other software running on the same
device.
2. The key material MUST be bound to the usage its intended to
prevent leakage.
3. Upon the termination of the conference or the browsing
context containing the application the key material SHALL be
deleted
d. Different Authorization methods MUST be supported.
1. It's preferable that authorization methods can be supported
without user agent modifications.
2. The authorization credentials MUST be bound to endpoint where
the participant provided its credentials.
e. The design SHOULD support confidentiality where only the current
set of participants has access to the media content.
f. The conference rooster and the binding to the e2e source
identifies MUST be provided by a trusted party.
Westerlund & Mattsson Expires April 21, 2016 [Page 11]
Internet-Draft WebRTC use cases in PERC October 2015
6. Solution Straw-man
6.1. High Level Example Message Flows
The following figure shows a very high level illustration of an
example message flow for Privacy Enhanced RTP Conferencing using
WebRTC.
+-----------+ +-------------+ +------------------+
| User/UA | | Conf. Prov. | | Service Provider |
+-----------+ +-------------+ +------------------+
| | |
| Invitation (Service Provider Conference URI) |
|<----------------------------------------------------|
| | |
| Launch Service Provider APP |
|<--------------------------------------------------->|
| User Authentication |
|<--------------------------------------------------->|
| Request Authorization Tokens |
|<--------------------------------------------------->|
| Request e2e Keying Material |
|<--------------------------------------------------->|
| | |
| Launch Conference APP | |
|<------------------------>| |
| Session Setup | |
|<------------------------>| |
| Setup PeerConnection | |
|<------------------------>| |
| DTLS-SRTP | |
|<------------------------>| |
| SRTP | |
|<------------------------>| |
The Conference Initiator schedules a conference and invitations are
sent out to the conference participants. This could for example be
done via e-mail.
At a later stage, when the conference is about to start, the
Conference Participant enters the conference URI in a browser it
trusts to launch the core web application. The user then
authenticates to the Service Provider Authorization Module (using a
authentication method of choice), and downloads the end-to-end keying
material from the Service Provider KMF.
Westerlund & Mattsson Expires April 21, 2016 [Page 12]
Internet-Draft WebRTC use cases in PERC October 2015
The UA then launches the Conference Application, negotiates the
session parameters and sets up the PeerConnection. The Conference
provider validates that the participant is authorized by the Service
Provider to join the conference. The hob-by-hop security is provided
by DTLS-SRTP and SRTP (modified to handle end-to-end and hop-by-hop).
The UA enforces the use of end-to-end security with the key provided
by the Service Provider.
All communication except the invitation and the PeerConnection is to
be done over HTTPS.
6.2. Authentication and Authorization
+-----------+ +-------------+ +------------------+
| User/UA | | Conf. Prov. | | Service Provider |
+-----------+ +-------------+ +------------------+
| | |
| HTTPS OAuth 2.0 Authorization Requests |
|---------------------------------------------------->|
| HTTPS OAuth 2.0 Access Tokens |
|<----------------------------------------------------|
| | |
| HTTPS Key Request (token1) |
|---------------------------------------------------->|
| HTTPS Key Response | |
|<----------------------------------------------------|
| | |
| HTTPS Join (token2) | |
|------------------------->| |
| HTTPS 200 OK | |
|------------------------->| |
One way to make the end-to-end security solution flexible and enable
integration with different types of Service Provider authorization
back-ends is to use a general authorization framework such as OAuth
2.0. The User requests access tokens for all the protected resources
from the Service Provider Authorization Module. The protected
resources can be hosted by the Service Provider (e.g. the Key
Management Function) as well as by the Conference provider. The use
of OAuth 2.0 allows the same framework to be used in both cases.
6.3. Key Management
Westerlund & Mattsson Expires April 21, 2016 [Page 13]
Internet-Draft WebRTC use cases in PERC October 2015
+-----------+ +-------------+ +-------------+
| UA | | MDD | | KMF |
+-----------+ +-------------+ +-------------+
| | |
| HTTPS POST (ConferenceID, token) |
|---------------------------------------------------->|
| HTTPS 200 OK (KeyID, e2e Key) |
|<----------------------------------------------------|
| DTLS-SRTP | |
|<------------------------>| |
| SRTP | |
|<------------------------>| |
The core web application requests the end-to-end keying material from
the Service Provider KMF. The successful HTTP response uses the HTTP
Encryption-Key header [I-D.thomson-http-encryption] to distribute the
end-to-end keying material to the UA. The new parameter "usage" and
its value "EKT" instructs the UA that the keying material will be
used with SRTP Encrypted Key Transport (EKT). The UA stores the
keyid and the keying material for usage as the EKT Key. Key material
received with the "usage=EKT" parameter SHALL NOT be extractable and
SHALL only be used for EKT. The EKT processing MUST be handled by
the UA.
An example successful HTTP response from the KMF is shown below:
HTTP/1.1 200 OK
Encryption-Key: keyid="pegh"; key="lupDujHomwIjlutebgharghmey";
usage="EKT"
Content-Length: 0
The hob-by-hop keying material is negotiated between the UA and the
MDD using DTLS-SRTP.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
The whole document is about making WebRTC based cloud-based
conferencing viable and trustworthy from a pervasive monitoring
perspective.
Westerlund & Mattsson Expires April 21, 2016 [Page 14]
Internet-Draft WebRTC use cases in PERC October 2015
9. Acknowledgements
The authors would like to thank Goeran AP Eriksson for challanging
discussions and Russ White for valuable comments.
10. Informative References
[I-D.ietf-rtcweb-alpn]
Thomson, M., "Application Layer Protocol Negotiation for
Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb-
alpn-01 (work in progress), February 2015.
[I-D.jones-perc-private-media-reqts]
Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
J., and R. Barnes, "Private Media Requirements in Privacy
Enhanced RTP Conferencing", draft-jones-perc-private-
media-reqts-00 (work in progress), July 2015.
[I-D.thomson-http-encryption]
Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
thomson-http-encryption-02 (work in progress), October
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
John Mattsson
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
Westerlund & Mattsson Expires April 21, 2016 [Page 15]