Internet DRAFT - draft-mattsson-avtvore-cloud-conferencing-use-case
draft-mattsson-avtvore-cloud-conferencing-use-case
Network Working Group J. Mattsson
Internet-Draft Y. Cheng
Intended status: Informational Ericsson
Expires: January 5, 2015 July 4, 2014
Privacy Ensured Cloud Conferencing - Use Case and Goals
draft-mattsson-avtvore-cloud-conferencing-use-case-00
Abstract
The aim of this document is to describe the use case of privacy
ensured cloud conferencing in a pervasive monitoring landscape and to
point out goals for a solution mitigating the pervasive monitoring
threat [RFC7258].
Virtualized cloud-based conferencing is happening and IETF should
take action to make such services viable and trustworthy from a
pervasive monitoring perspective.
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
Mattsson & Cheng Expires January 5, 2015 [Page 1]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Ensure End-To-End(s) Confidentiality . . . . . . . . 4
3.1.2. Ensure End-To-End Source Authentication . . . . . . . 4
3.1.3. Provide a more efficient service than Full-Mesh . . . 4
3.1.4. Support Cloud Based Conferencing . . . . . . . . . . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Securing the endpoints . . . . . . . . . . . . . . . 5
3.2.2. Concealing that communication occurs . . . . . . . . 5
3.2.3. Individual Media Source Authentication . . . . . . . 5
3.2.4. Preventing invited user to access content . . . . . . 5
4. Problems with Current Technology . . . . . . . . . . . . . . 6
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document discusses the possibility to provide real-time
conference communication services to enterprises and other
organizations that try to ensure the privacy of their communication
in a world with pervasive monitoring. This includes being able to
purchase conferencing supporting network services, including cloud-
based ones that are resistant to content monitoring.
This document starts with a background section discussing the
development in the world that affects considerations for ensuring
communication privacy. Next goals and non-goals for privacy ensured
cloud conferencing are stated, followed by the considerations around
using current technology and standards.
Some strategies for secure cloud systems can be found in
[I-D.jennings-perpass-secure-rai-cloud].
Mattsson & Cheng Expires January 5, 2015 [Page 2]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
2. Background
Within the field of real-time conferencing there is an ongoing
transformation. A transformation towards more cloud based,
virtualized and software based conferencing server implementations.
The central conferencing server on dedicated hardware is under heavy
competition from virtualized servers. One enabling factor for this
is the increased capabilities of the end-points that allow them to
decode and process multiple simultaneously received media streams.
This in its turn has made the central conferring media nodes to
switch from mixing or composing media in the decoded domain to
instead perform the much less heavy-weight operation of selection,
switching and forwarding of media streams, at least for video. Thus
making virtualized cloud-based conferencing services viable.
This transformation to virtualization and cloud-based services
increases the threats towards the confidentiality of the content of
any conference. The reason is that an attacker interested in
surveillance of a conference now also has the possibility to attack
the cloud provider and attempt to get access to the actual hardware
or virtualization layer as a method of accessing what happens within
the conference services server instances.
From the pervasive monitoring debate we know that there are many
organizations that are actively performing large scale pervasive
monitoring, this includes national agencies, but also criminal
organizations may be engaged in such activities. It has been
revealed that several large service providers have been compromised,
resulting in people questioning the impact and security of sourcing
services for enterprise or governments to external providers. IETF
has stated that pervasive monitoring is an attack and that it should
be mitigated [RFC7258].
The trend of using virtualized cloud-based services (e.g.
conferencing) has a number of positive effects on flexibility, CAPEX,
ease of use, etc. IETF should take action to make such services
viable and trustworthy from a pervasive monitoring perspective. One
important part of pervasive monitoring is the passive pervasive
monitoring [I-D.trammell-perpass-ppa].
3. Goals and Non-Goals
This section proposed goals and non-goals for the privacy ensured
conferencing use case.
Mattsson & Cheng Expires January 5, 2015 [Page 3]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
3.1. Goals
3.1.1. Ensure End-To-End(s) Confidentiality
The content of the communication and all its media needs to be
confidential within the group of entities explicitly invited into the
conference. An external monitoring adversary should be unable to
deduce the human to human communication that actually occurred from
capturing the media packets within a time frame for which the
communication remains confidential.
3.1.2. Ensure End-To-End Source Authentication
In a conference system with multiple participants it is vital that
the multi-media content presented to any of the participant humans
are from the stated participants, 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.
3.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 end-point directly addresses each of the other
participants. However, this has a significant issue with the amount
of consumed resources in both the uplink and the downlink from each
participant. To reduce this issue one wants to consider other
topologies, which implies network or centralized server
functionalities.
3.1.4. Support Cloud Based Conferencing
To achieve a cost effective and scalable conferencing support the
conference central nodes must be possible to run as instances in a
cloud based virtualized environment.
From a security stand point this is a significant issue. In a
virtual, possibly multi-tenant, cloud environment the ones running
the conferencing supporting implementation instance can't trust that
anything maintained at that instance is secure from an adversary. A
pervasive monitoring entity may in fact have direct access to the
hardware through vulnerabilities in the virtualization layer the
instance runs in.
Mattsson & Cheng Expires January 5, 2015 [Page 4]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
3.2. Non-Goals
3.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
trustwothy, how to achieve this is out of scope.
3.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 first of all 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 nation borders or
internet exchange points. Thus 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 subject for
future studies. Existing attempts include The Onion Router (TOR),
which has been claimed to be possible to monitor, at least partially,
by an adversary with sufficient reach.
3.2.3. Individual Media Source Authentication
Although the participants in the conference are authenticated, it
should probably not be 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 conference
participant or not.
There exist solutions that can provide individual media source
authentication, e.g. TESLA. However they impact the performance or
security properties they provide. Thus, further studies are required
to determine impact and resulting security properties if desired to
have individual source authentication.
3.2.4. Preventing invited user to access content
As an invited user will be provided with the content protection keys,
an invited user can unless active measures are taken against this,
decrypt content from the time periods prior and post the user is
officially part of the conference.
Mattsson & Cheng Expires January 5, 2015 [Page 5]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
If this is a concern the solution could be extended to re-key the
content protection keys every time a user joins or leaves the
conference so each particular set of conference participants uses a
unique key. However, this also changes the trust level required on
the conference rooster handling at any point and how to keep that
accurate and secured. Further the re-keying operations and their
timely completion become an obstacle in system design.
4. Problems with Current Technology
If SRTP is used end-to-end, a multiparty conference where the
middlebox/server duplicates packets and forwards the complete
encrypted packets from a client to multiple participants, the RTP
handling is problematic.
The RTP mixer will be forced to behave like a video switching MCU in
RFC 5117. SRTP prevents the mixer from performing any type of RTP or
RTCP rewrite. However, to keep the bitrate in check its switching
decision will result in stopping RTP streams from reaching the
client. This results in RTP sequences with large gaps in them.
These gaps hide packet losses at the edges of the gaps, resulting in
that the receiver has issues in determining if loss near switching
point is intentional or not. This can cause repair attempts,
buffering issues, and triggering bit-rate adaptation. In addition
the congestion control mechanism has significant difficulties to act
correctly in such an environment.
Further the above topology requires the RTP stacks to be capable of
handling multiple remote peers, including for adaptation of
congestion control. This has previously been limited to any-source
multicast and transport relay topologies, not RTP mixer ones.
To enable this system's properties, enable RTP mixing, while not
letting the mixer get access to content, it's required to specify a
two level security mechanism. In any multi-vendor environments this
will require a specification as it will affect the cipher operations
and the data transmitted between participants. The application could
handle automatic key-management in the group of authorized
participants. One approach on how to do this is
[I-D.cheng-srtp-cloud]
To support video switching/relaying knowing from which points in the
video streams a receiving endpoint will be able to decode is
important. Thus markers for where switching points in the media
stream are will be required.
To enable the middle boxes to take local decisions on this, each
sender will need to include some speaker activity indication;
Mattsson & Cheng Expires January 5, 2015 [Page 6]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
preferably including some type of ranking of how likely this is to
contain speech. However, this activity indication also needs to leak
as little information as possible about the actual content of the
speech.
5. Conclusions
Virtualized cloud-based conferencing is happening and IETF should
take action to make such services viable and trustworthy from a
pervasive monitoring perspective.
From the goals and discussion above it is clear that to provide
effective cloud based conferencing while protecting from pervasive
monitoring, two layers of security is needed. This is not supported
by SRTP.
There is currently active work on secure objects in the form of JSON
objects in the IETF WG JOSE. But this is not applicable to RTP based
real-time media.
6. Security Considerations
The whole document is about making cloud-based conferencing viable
and trustworthy from a pervasive monitoring perspective.
7. Acknowledgements
The authors would like to thank Magnus Westerlund for providing much
of the input to this document as well as much of the text.
8. References
[I-D.cheng-srtp-cloud]
Cheng, Y., Mattsson, J., and Naslund, M., "Secure Real-
time Transport Protocol (SRTP) for Cloud Services", draft-
cheng-srtp-cloud-00 (work in progress), July 2014.
[I-D.jennings-perpass-secure-rai-cloud]
Jennings, C. and S. Nandakumar, "Trustable Cloud Systems -
Strategies and Recommendations", draft-jennings-perpass-
secure-rai-cloud-01 (work in progress), January 2014.
[I-D.trammell-perpass-ppa]
Trammell, B., Borkmann, D., and C. Huitema, "A Threat
Model for Pervasive Passive Surveillance", draft-trammell-
perpass-ppa-01 (work in progress), November 2013.
Mattsson & Cheng Expires January 5, 2015 [Page 7]
Internet-Draft Privacy Ensured Cloud Conferencing July 2014
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
Authors' Addresses
John Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
Yi Cheng
Ericsson
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 17 589
Email: yi.cheng@ericsson.com
Mattsson & Cheng Expires January 5, 2015 [Page 8]
