draft-ietf-avtcore-rtp-security-options-03.txt   rfc7201.txt 
Network Working Group M. Westerlund Internet Engineering Task Force (IETF) M. Westerlund
Internet-Draft Ericsson Request for Comments: 7201 Ericsson
Intended status: Informational C. Perkins Category: Informational C. Perkins
Expires: November 07, 2013 University of Glasgow ISSN: 2070-1721 University of Glasgow
May 06, 2013 April 2014
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-03
Abstract Abstract
The Real-time Transport Protocol (RTP) is used in a large number of The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This heterogeneity different application domains and environments. This heterogeneity
implies that different security mechanisms are needed to provide implies that different security mechanisms are needed to provide
services such as confidentiality, integrity and source authentication services such as confidentiality, integrity, and source
of RTP/RTCP packets suitable for the various environments. The range authentication of RTP and RTP Control Protocol (RTCP) packets
of solutions makes it difficult for RTP-based application developers suitable for the various environments. The range of solutions makes
to pick the most suitable mechanism. This document provides an it difficult for RTP-based application developers to pick the most
overview of a number of security solutions for RTP, and gives suitable mechanism. This document provides an overview of a number
guidance for developers on how to choose the appropriate security of security solutions for RTP and gives guidance for developers on
mechanism. how to choose the appropriate security mechanism.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 07, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7201.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 4 2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 5
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 6
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 6
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 8
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 8
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 12
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 14
3.1.3. Key Management for SRTP: Security Descriptions . . . 13 3.1.3. Key Management for SRTP: Security Descriptions . . . 15
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 16
3.1.5. Key Management for SRTP: Other systems . . . . . . . 14 3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 17
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 17
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 18
3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 18
3.6. Payload-only Security Mechanisms . . . . . . . . . . . . 16 3.6. Media Content Security/Digital Rights Management . . . . 19
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 19
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 20
4.1. Application Requirements . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 20
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 20
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 22
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 23
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Application Structure . . . . . . . . . . . . . . . . . . 22 4.2. Application Structure . . . . . . . . . . . . . . . . . . 25
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22 4.3. Automatic Key Management . . . . . . . . . . . . . . . . 25
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.4. End-to-End Security vs. Tunnels . . . . . . . . . . . . . 25
5.1. Media Security for SIP-established Sessions using DTLS- 4.5. Plaintext Keys . . . . . . . . . . . . . . . . . . . . . 26
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 26
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 5.1. Media Security for SIP-Established Sessions Using
5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 5.4. 3GPP Packet-Switched Streaming Service (PSS) . . . . . . 29
9. Informative References . . . . . . . . . . . . . . . . . . . 27 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) [RFC3550] is widely used in a The Real-time Transport Protocol (RTP) [RFC3550] is widely used in a
large variety of multimedia applications, including Voice over IP large variety of multimedia applications, including Voice over IP
(VoIP), centralized multimedia conferencing, sensor data transport, (VoIP), centralized multimedia conferencing, sensor data transport,
and Internet television (IPTV) services. These applications can and Internet television (IPTV) services. These applications can
range from point-to-point phone calls, through centralised group range from point-to-point phone calls, through centralized group
teleconferences, to large-scale television distribution services. teleconferences, to large-scale television distribution services.
The types of media can vary significantly, as can the signalling The types of media can vary significantly, as can the signaling
methods used to establish the RTP sessions. methods used to establish the RTP sessions.
This multi-dimensional heterogeneity has so far prevented development So far, this multidimensional heterogeneity has prevented development
of a single security solution that meets the needs of the different of a single security solution that meets the needs of the different
applications. Instead significant number of different solutions have applications. Instead, a significant number of different solutions
been developed to meet different sets of security goals. This makes have been developed to meet different sets of security goals. This
it difficult for application developers to know what solutions exist, makes it difficult for application developers to know what solutions
and whether their properties are appropriate. This memo gives an exist and whether their properties are appropriate. This memo gives
overview of the available RTP solutions, and provides guidance on an overview of the available RTP solutions and provides guidance on
their applicability for different application domains. It also their applicability for different application domains. It also
attempts to provide indication of actual and intended usage at time attempts to provide an indication of actual and intended usage at the
of writing as additional input to help with considerations such as time of writing as additional input to help with considerations such
interoperability, availability of implementations etc. The guidance as interoperability, availability of implementations, etc. The
provided is not exhaustive, and this memo does not provide normative guidance provided is not exhaustive, and this memo does not provide
recommendations. normative recommendations.
It is important that application developers consider the security It is important that application developers consider the security
goals and requirements for their application. The IETF considers it goals and requirements for their application. The IETF considers it
important that protocols implement, and makes available to the user, important that protocols implement secure modes of operation and
secure modes of operation [RFC3365]. Because of the heterogeneity of makes them available to users [RFC3365]. Because of the
RTP applications and use cases, however, a single security solution heterogeneity of RTP applications and use cases, however, a single
cannot be mandated. Instead, application developers need to select security solution cannot be mandated [RFC7202]. Instead, application
mechanisms that provide appropriate security for their environment. developers need to select mechanisms that provide appropriate
It is strongly encouraged that common mechanisms are used by related security for their environment. It is strongly encouraged that
applications in common environments. The IETF publishes guidelines common mechanisms be used by related applications in common
for specific classes of applications, so it worth searching for such environments. The IETF publishes guidelines for specific classes of
guidelines. applications, so it is worth searching for such guidelines.
The remainder of this document is structured as follows. Section 2 The remainder of this document is structured as follows. Section 2
provides additional background. Section 3 outlines the available provides additional background. Section 3 outlines the available
security mechanisms at the time of this writing, and lists their key security mechanisms at the time of this writing and lists their key
security properties and constraints. That is followed by guidelines security properties and constraints. Section 4 provides guidelines
and important aspects to consider when securing an RTP application in and important aspects to consider when securing an RTP application.
Section 4. Finally, we give some examples of application domains Finally, in Section 5, we give some examples of application domains
where guidelines for security exist in Section 5. where guidelines for security exist.
2. Background 2. Background
RTP can be used in a wide variety of topologies, and combinations of RTP can be used in a wide variety of topologies due to its support
topologies, due to it's support for unicast, multicast groups, and for point-to-point sessions, multicast groups, and other topologies
broadcast topologies, and the existence of different types of RTP built around different types of RTP middleboxes. In the following,
middleboxes. In the following we review the different topologies we review the different topologies supported by RTP to understand
supported by RTP to understand their implications for the security their implications for the security properties and trust relations
properties and trust relations that can exist in RTP sessions. that can exist in RTP sessions.
2.1. Point to Point Sessions 2.1. Point-to-Point Sessions
The most basic use case is two directly connected end-points, shown The most basic use case is two directly connected endpoints, shown in
in Figure 1, where A has established an RTP session with B. In this Figure 1, where A has established an RTP session with B. In this
case the RTP security is primarily about ensuring that any third case, the RTP security is primarily about ensuring that any third
party can't compromise the confidentiality and integrity of the media party be unable to compromise the confidentiality and integrity of
communication. This requires confidentiality protection of the RTP the media communication. This requires confidentiality protection of
session, integrity protection of the RTP/RTCP packets, and source the RTP session, integrity protection of the RTP/RTCP packets, and
authentication of all the packets to ensure no man-in-the-middle source authentication of all the packets to ensure no man-in-the-
attack is taking place. middle (MITM) attack is taking place.
The source authentication can also be tied to a user or an end-points The source authentication can also be tied to a user or an endpoint's
verifiable identity to ensure that the peer knows who they are verifiable identity to ensure that the peer knows with whom they are
communicating with. Here the combination of the security protocol communicating. Here, the combination of the security protocol
protecting the RTP session and its RTP and RTCP traffic and the key- protecting the RTP session (and, hence, the RTP and RTCP traffic) and
management protocol becomes important in which security statements the key management protocol becomes important to determine what
one can do. security claims can be made.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Topology Figure 1: Point-to-Point Topology
2.2. Sessions Using an RTP Mixer 2.2. Sessions Using an RTP Mixer
An RTP mixer is an RTP session level middlebox that one can build an An RTP mixer is an RTP session-level middlebox around which one can
multi-party RTP based conference around. The RTP mixer might build a multiparty RTP-based conference. The RTP mixer might
actually perform media mixing, like mixing audio or compositing video actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the participant, or it might provide a conceptual stream; for example,
video of the current active speaker. From a security point of view, the video of the current active speaker. From a security point of
the important features of an RTP mixer is that it generates a new view, the important features of an RTP mixer are that it generates a
media stream, and has its own source identifier, and does not simply new media stream, has its own source identifier, and does not simply
forward the original media. forward the original media.
An RTP session using a mixer might have a topology like that in An RTP session using a mixer might have a topology like that in
Figure 2. In this examples, participants A-D each send unicast RTP Figure 2. In this example, participants A through D each send
traffic between themselves and the RTP mixer, and receive a RTP unicast RTP traffic to the RTP mixer, and receive an RTP stream from
stream from the mixer, comprising a mixture of the streams from the the mixer, comprising a mixture of the streams from the other
other participants. participants.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 2: Example RTP Mixer topology Figure 2: Example RTP Mixer Topology
A consequence of an RTP mixer having its own source identifier, and A consequence of an RTP mixer having its own source identifier and
acting as an active participant towards the other end-points, is that acting as an active participant towards the other endpoints is that
the RTP mixer needs to be a trusted device that is part of the the RTP mixer needs to be a trusted device that has access to the
security context(s) established. The RTP mixer can also become a security context(s) established. The RTP mixer can also become a
security enforcing entity. For example, a common approach to secure security-enforcing entity. For example, a common approach to secure
the topology in Figure 2 is to establish a security context between the topology in Figure 2 is to establish a security context between
the mixer and each participant independently, and have the mixer the mixer and each participant independently and have the mixer
source authenticate each peer. The mixer then ensures that one source authenticate each peer. The mixer then ensures that one
participant cannot impersonate another. participant cannot impersonate another.
2.3. Sessions Using an RTP Translator 2.3. Sessions Using an RTP Translator
RTP translators are middleboxes that provide various levels of in- RTP translators are middleboxes that provide various levels of
network media translation and transcoding. Their security properties in-network media translation and transcoding. Their security
vary widely, depending on which type of operations they attempt to properties vary widely, depending on which type of operations they
perform. We identify three different categories of RTP translator: attempt to perform. We identify and discuss three different
transport translators, gateways, and media transcoders. We discuss categories of RTP translators: transport translators, gateways, and
each in turn. media transcoders.
2.3.1. Transport Translator (Relay) 2.3.1. Transport Translator (Relay)
A transport translator [RFC5117] operates on a level below RTP and A transport translator [RFC5117] operates on a level below RTP and
RTCP. It relays the RTP/RTCP traffic from one end-point to one or RTCP. It relays the RTP/RTCP traffic from one endpoint to one or
more other addresses. This can be done based only on IP addresses more other addresses. This can be done based only on IP addresses
and transport protocol ports, with each receive port on the and transport protocol ports, and each receive port on the translator
translator can have a very basic list of where to forward traffic. can have a very basic list of where to forward traffic. Transport
Transport translators also need to implement ingress filtering to translators also need to implement ingress filtering to prevent
prevent random traffic from being forwarded that isn't coming from a random traffic from being forwarded that isn't coming from a
participant in the conference. participant in the conference.
Figure 3 shows an example transport translator, where traffic from Figure 3 shows an example transport translator, where traffic from
any one of the four participants will be forwarded to the other three any one of the four participants will be forwarded to the other three
participants unchanged. The resulting topology is very similar to participants unchanged. The resulting topology is very similar to an
Any source Multicast (ASM) session (as discussed in Section 2.4), but Any Source Multicast (ASM) session (as discussed in Section 2.4) but
implemented at the application layer. is implemented at the application layer.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | Relay | +---+ +---+ | Relay | +---+
| Translator | | Translator |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 3: RTP relay translator topology Figure 3: RTP Relay Translator Topology
A transport translator can often operate without needing to be in the A transport translator can often operate without needing access to
security context, as long as the security mechanism does not provide the security context, as long as the security mechanism does not
protection over the transport-layer information. A transport provide protection over the transport-layer information. A transport
translator does, however, make the group communication visible, and translator does, however, make the group communication visible and,
so can complicate keying and source authentication mechanisms. This thus, can complicate keying and source authentication mechanisms.
is further discussed in Section 2.4. This is further discussed in Section 2.4.
2.3.2. Gateway 2.3.2. Gateway
Gateways are deployed when the endpoints are not fully compatible. Gateways are deployed when the endpoints are not fully compatible.
Figure 4 shows an example topology. The functions a gateway provides Figure 4 shows an example topology. The functions a gateway provides
can be diverse, and range from transport layer relaying between two can be diverse and range from transport-layer relaying between two
domains not allowing direct communication, via transport or media domains not allowing direct communication, via transport or media
protocol function initiation or termination, to protocol or media protocol function initiation or termination, to protocol- or media-
encoding translation. The supported security protocol might even be encoding translation. The supported security protocol might even be
one of the reasons a gateway is needed. one of the reasons a gateway is needed.
+---+ +-----------+ +---+ +---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B | | A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+ +---+ +-----------+ +---+
Figure 4: RTP Gateway Topology Figure 4: RTP Gateway Topology
The choice of security protocol and the details of the gateway The choice of security protocol, and the details of the gateway
function will determine if the gateway needs to be a trusted part of function, will determine if the gateway needs to be trusted with
the application security context or not. Many gateways need to be access to the application security context. Many gateways need to be
trusted by all peers to perform the translation; in other cases some trusted by all peers to perform the translation; in other cases, some
or all peers might not be aware of the presence of the gateway. The or all peers might not be aware of the presence of the gateway. The
security protocols have different properties depending on the degree security protocols have different properties depending on the degree
of trust and visibility needed. Ensuring communication is possible of trust and visibility needed. Ensuring communication is possible
without trusting the gateway can be strong incentive for accepting without trusting the gateway can be a strong incentive for accepting
different security properties. Some security solutions will be able different security properties. Some security solutions will be able
to detect the gateways as manipulating the media stream, unless the to detect the gateways as manipulating the media stream, unless the
gateway is a trusted device. gateway is a trusted device.
2.3.3. Media Transcoder 2.3.3. Media Transcoder
A Media transcoder is a special type of gateway device that changes A media transcoder is a special type of gateway device that changes
the encoding of the media being transported by RTP. The discussion the encoding of the media being transported by RTP. The discussion
in Section 2.3.2 applies. A media transcoder alters the media data, in Section 2.3.2 applies. A media transcoder alters the media data
and thus needs to be trusted device that is part of the security and, thus, needs to be trusted with access to the security context.
context.
2.4. Any Source Multicast 2.4. Any Source Multicast
Any Source Multicast [RFC1112] is the original multicast model where Any Source Multicast [RFC1112] is the original multicast model where
any multicast group participant can send to the multicast group, and any multicast group participant can send to the multicast group and
get their packets delivered to all group members (see Figure 5). get their packets delivered to all group members (see Figure 5).
This form of communication has interesting security properties, due This form of communication has interesting security properties due to
to the many-to-many nature of the group. Source authentication is the many-to-many nature of the group. Source authentication is
important, but all participants in the group security context will important, but all participants with access to the group security
have access to the necessary secrets to decrypt and verify integrity context will have the necessary secrets to decrypt and verify the
of the traffic. Thus use of any symmetric security functions fails integrity of the traffic. Thus, use of any group security context
if the goal is to separate individual sources within the security fails if the goal is to separate individual sources; alternate
context; alternate solutions are needed. solutions are needed.
+-----+ +-----+
+---+ / \ +---+ +---+ / \ +---+
| A |----/ \---| B | | A |----/ \---| B |
+---+ / Multi- \ +---+ +---+ / \ +---+
+ Cast + + Multicast +
+---+ \ Network / +---+ +---+ \ Network / +---+
| C |----\ /---| D | | C |----\ /---| D |
+---+ \ / +---+ +---+ \ / +---+
+-----+ +-----+
Figure 5: Any Source Multicast Group Figure 5: Any Source Multicast (ASM) Group
In addition the potential large size of multicast groups creates some In addition, the potential large size of multicast groups creates
considerations for the scalability of the solution and how the key- some considerations for the scalability of the solution and how the
management is handled. key management is handled.
2.5. Source-Specific Multicast 2.5. Source-Specific Multicast
Source Specific Multicast [RFC4607] allows only a specific end-point Source-Specific Multicast (SSM) [RFC4607] allows only a specific
to send traffic to the multicast group. That end-point is labelled endpoint to send traffic to the multicast group, irrespective of the
the Distribution Source in Figure 6. It distributes traffic from a number of RTP media sources. The endpoint is known as the media
number of RTP media sources, MS1 to MSm. Figure 6 also depicts the distribution source. For the RTP session to function correctly with
feedback part of the SSM RTP session using unicast feedback [RFC5760] RTCP over an SSM session, extensions have been defined in [RFC5760].
from a number of receivers R1..Rn that sends feedback to a Feedback Figure 6 shows a sample SSM-based RTP session where several media
Target (FT) and eventually aggregated and distributed to the group. sources, MS1...MSm, all send media to a distribution source, which
then forwards the media data to the SSM group for delivery to the
The use of SSM makes it more difficult to inject traffic into the receivers, R1...Rn, and the feedback targets, FT1...FTn. RTCP
multicast group, but not impossible. Source authentication reception quality feedback is sent unicast from each receiver to one
requirements apply for SSM sessions too, and a non-symmetric of the feedback targets. The feedback targets aggregate reception
verification of who sent the RTP and RTCP packets is needed. quality feedback and forward it upstream towards the distribution
source. The distribution source forwards (possibly aggregated and
summarized) reception feedback to the SSM group and back to the
original media sources. The feedback targets are also members of the
SSM group and receive the media data, so they can send unicast repair
data to the receivers in response to feedback if appropriate.
The SSM communication channel needs to be securely established and +-----+ +-----+ +-----+
keyed. In addition one also have the individual unicast feedback | MS1 | | MS2 | .... | MSm |
that also needs to be secured. +-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
+-----+ +-----+ +-----+ Figure 6: Example SSM-Based RTP Session with Two Feedback Targets
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+
Figure 6: SSM-based RTP session with Unicast Feedback The use of SSM makes it more difficult to inject traffic into the
multicast group, but not impossible. Source authentication
requirements apply for SSM sessions, too; an individual verification
of who sent the RTP and RTCP packets is needed. An RTP session using
SSM will have a group security context that includes the media
sources, distribution source, feedback targets, and the receivers.
Each has a different role and will be trusted to perform different
actions. For example, the distribution source will need to
authenticate the media sources to prevent unwanted traffic from being
distributed via the SSM group. Similarly, the receivers need to
authenticate both the distribution source and their feedback target
to prevent injection attacks from malicious devices claiming to be
feedback targets. An understanding of the trust relationships and
group security context is needed between all components of the
system.
3. Security Options 3. Security Options
This section provides an overview of a number of currently defined This section provides an overview of security requirements and the
security mechanisms that can be used with RTP. This section will use current RTP security mechanisms that implement those requirements.
a number of different security related terms, if they are unknown to This cannot be a complete survey, since new security mechanisms are
the reader, please consult the "Internet Security Glossary, Version defined regularly. The goal is to help applications designers by
2" [RFC4949]. reviewing the types of solutions that are available. This section
will use a number of different security-related terms, as described
Part of this discussion will be indication of known deployments or at in the Internet Security Glossary, Version 2 [RFC4949].
least requirements in specification to support particular security
solutions. This will most certainly not be a complete picture and
also become obsolete as time progress since the time of writing this
document. The goal with including such information is to help the
designer, given multiple potential solutions that meets the security
design goals one can consider values such as interoperability,
maturity of implementations or experiences with solution components.
3.1. Secure RTP 3.1. Secure RTP
The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly The Secure Real-time Transport Protocol (SRTP) [RFC3711] is one of
used mechanisms to provide confidentiality, integrity protection, the most commonly used mechanisms to provide confidentiality,
source authentication and replay protection for RTP. SRTP was integrity protection, source authentication, and replay protection
developed with RTP header compression and third party monitors in for RTP. SRTP was developed with RTP header compression and third-
mind. Thus the RTP header is not encrypted in RTP data packets, and party monitors in mind. Thus, the RTP header is not encrypted in RTP
the first 8 bytes of the first RTCP packet header in each compound data packets, and the first 8 bytes of the first RTCP packet header
RTCP packet are not encrypted. The entirety of RTP packets and in each compound RTCP packet are not encrypted. The entirety of RTP
compound RTCP packets are integrity protected. This allows RTP packets and compound RTCP packets are integrity protected. This
header compression to work, and lets third party monitors determine allows RTP header compression to work and lets third-party monitors
what RTP traffic flows exist based on the SSRC fields, but protects determine what RTP traffic flows exist based on the synchronization
the sensitive content. source (SSRC) fields, but it protects the sensitive content.
The source authentication guarantees provided by SRTP are highly SRTP works with transforms where different combinations of encryption
dependent on the cryptographic transform and key-management scheme algorithm, authentication algorithm, and pseudorandom function can be
used. In some cases all a receiver can determine is whether the used, and the authentication tag length can be set to any value.
packets come from someone in the group security context, and not what SRTP can also be easily extended with additional cryptographic
group member send the packets. Thus, the source authentication transforms. This gives flexibility but requires more security
guarantees depend also on the session topology. Some cryptographic knowledge by the application developer. To simplify things, Session
transform have stronger authentication properties which can guarantee Description Protocol (SDP) security descriptions (see Section 3.1.3)
a given source, even over a multi-party session, e.g. those based on and Datagram Transport Layer Security Extension for SRTP (DTLS-SRTP)
TESLA [RFC4383]. (see Section 3.1.1) use predefined combinations of transforms, known
as SRTP crypto suites and SRTP protection profiles, that bundle
together transforms and other parameters, making them easier to use
but reducing flexibility. The Multimedia Internet Keying (MIKEY)
protocol (see Section 3.1.2) provides flexibility to negotiate the
full selection of transforms. At the time of this writing, the
following transforms, SRTP crypto suites, and SRTP protection
profiles are defined or under definition:
SRTP can easily be extended with additional cryptographic transforms. AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys
At the time of this writing, the following transforms are defined or combined with 160-bit keyed HMAC-SHA-1 with an 80-bit
under definition: authentication tag. This is the default cryptographic transform
that needs to be supported. The transforms are defined in SRTP
[RFC3711], with the corresponding SRTP crypto suite defined in
[RFC4568] and SRTP protection profile defined in [RFC5764].
AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits AES-f8 and HMAC-SHA-1: AES f8-mode encryption using 128-bit keys
keys combined with 128 bits keyed HMAC-SHA1 using 80 or 32 bits combined with keyed HMAC-SHA-1 using 80-bit authentication. The
authentication tags are the default cryptographic transform which transforms are defined in [RFC3711], with the corresponding SRTP
need to be supported. Defined in SRTP [RFC3711]. crypto suite defined in [RFC4568]. The corresponding SRTP
protection profile is not defined.
AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128 bits keys SEED: A Korean national standard cryptographic transform that is
combined with keyed HMAC-SHA1 using 80 or 32 bits authentication. defined to be used with SRTP in [RFC5669]. Three options are
Defined in SRTP [RFC3711]. defined: one using SHA-1 authentication, one using Counter Mode
with Cipher Block Chaining Message Authentication Code (CBC-MAC),
and one using Galois Counter Mode.
TESLA: As a complement to the regular symmetric keyed authentication ARIA: A Korean block cipher [ARIA-SRTP] that supports 128-, 192-,
transforms, like HMAC-SHA1. The TESLA based authentication scheme and 256-bit keys. It also defines three options: Counter Mode
can provide per-source authentication in some group communication where combined with HMAC-SHA-1 with 80- or 32-bit authentication
scenarios. The downside is need for buffering the packets for a tags, Counter Mode with CBC-MAC, and Galois Counter Mode. It also
while before authenticity can be verified. The TESLA transform defines a different key derivation function than the AES-based
for SRTP is defined in [RFC4383]. systems.
SEED: An Korean national standard cryptographic transform that is AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based
defined to be used with SRTP in [RFC5669]. It has three modes, on AES-192 and AES-256 Counter Mode encryption and 160-bit keyed
one using SHA-1 authentication, one using Counter with CBC-MAC, HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide
and finally one using Galois Counter mode. 192- and 256-bit encryption keys, but otherwise match the default
128-bit AES-CM transform. The transforms are defined in [RFC3711]
and [RFC6188], and the SRTP crypto suites are defined in
[RFC6188].
ARIA: An Korean block cipher [I-D.ietf-avtcore-aria-srtp], that AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter Mode
supports 128, 192 and 256 bits keys. It also has three modes, with CBC-MAC for AES-128 and AES-256. This authentication is
Counter mode where combined with HMAC-SHA1 with 80 or 32 bits included in the cipher text, which becomes expanded with the
authentication tags, Counter mode with CBC-MAC and Galois Counter length of the authentication tag instead of using the SRTP
mode. It also defines a different key derivation function than authentication tag. This is defined in [AES-GCM].
the AES based.
AES-192 and AES-256: cryptographic transforms for SRTP based on NULL: SRTP [RFC3711] also provides a NULL cipher that can be used
AES-192 and AES-256 counter mode encryption and 160-bit keyed when no confidentiality for RTP/RTCP is requested. The
HMAC-SHA1 with 80 and 32 bits authentication tags for corresponding SRTP protection profile is defined in [RFC5764].
authentication. Thus providing 192 and 256 bits encryption keys
and NSA Suite B included cryptographic transforms. Defined in
[RFC6188].
AES-GCM: There is also ongoing work to define AES-GCM (Galois The source authentication guarantees provided by SRTP depend on the
Counter Mode) and AES-CCM (Counter with CBC) authentication for cryptographic transform and key management used. Some transforms
AES-128 and AES-256. This authentication is included in the give strong source authentication even in multiparty sessions; others
cipher text which becomes expanded with the length of the give weaker guarantees and can authenticate group membership but not
authentication tag instead of using the SRTP authentication tag. sources. Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. [RFC4383] offers a complement to the regular symmetric keyed
authentication transforms, like HMAC-SHA-1, and can provide
per-source authentication in some group communication scenarios. The
downside is the need for buffering the packets for a while before
authenticity can be verified.
[RFC4771] defines a variant of the authentication tag that enables a [RFC4771] defines a variant of the authentication tag that enables a
receiver to obtain the Roll over Counter for the RTP sequence number receiver to obtain the Roll over Counter for the RTP sequence number
that is part of the Initialization vector (IV) for many cryptographic that is part of the Initialization Vector (IV) for many cryptographic
transforms. This enables quicker and easier options for joining a transforms. This enables quicker and easier options for joining a
long lived secure RTP group, for example a broadcast session. long-lived RTP group; for example, a broadcast session.
RTP header extensions are in normally carried in the clear and only RTP header extensions are normally carried in the clear and are only
integrity protected in SRTP. This can be problematic in some cases, integrity protected in SRTP. This can be problematic in some cases,
so [RFC6904] defines an extension to also encrypt selected header so [RFC6904] defines an extension to also encrypt selected header
extensions. extensions.
SRTP is specified and deployed in a number of RTP usage contexts; SRTP is specified and deployed in a number of RTP usage contexts;
Significant support in SIP established VoIP clients including IMS; significant support is provided in SIP-established VoIP clients,
RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. including IP Multimedia Subsystems (IMS), and in the Real Time
Thus SRTP in general is widely deployed. When it comes to Streaming Protocol (RTSP) [RTSP] and RTP-based media streaming.
cryptographic transforms the default (AES CM and HMAC-SHA1) is the Thus, SRTP in general is widely deployed. When it comes to
most common used. cryptographic transforms, the default (AES-CM and HMAC-SHA-1) is the
most commonly used, but it might be expected that AES-GCM,
AES-192-CM, and AES-256-CM will gain usage in future, especially due
to the AES- and GCM-specific instructions in new CPUs.
SRTP does not contain an integrated key-management solution, and SRTP does not contain an integrated key management solution; instead,
instead relies on an external key management protocol. There are it relies on an external key management protocol. There are several
several protocols that can be used. The following sections outline protocols that can be used. The following sections outline some
some popular schemes. popular schemes.
3.1.1. Key Management for SRTP: DTLS-SRTP 3.1.1. Key Management for SRTP: DTLS-SRTP
A Datagram Transport Layer Security extension exists for establishing A Datagram Transport Layer Security (DTLS) extension exists for
SRTP keys [RFC5763][RFC5764]. This extension provides secure key- establishing SRTP keys [RFC5763][RFC5764]. This extension provides
exchange between two peers, enabling perfect forward secrecy and secure key exchange between two peers, enabling Perfect Forward
binding strong identity verification to an end-point. The default Secrecy (PFS) and binding strong identity verification to an
key generation will generate a key that contains material contributed endpoint. PFS is a property of the key agreement protocol that
by both peers. The key-exchange happens in the media plane directly ensures that a session key derived from a set of long-term keys will
between the peers. The common key-exchange procedures will take two not be compromised if one of the long-term keys is compromised in the
round trips assuming no losses. TLS resumption can be used when future. The default key generation will generate a key that contains
establishing additional media streams with the same peer, used material contributed by both peers. The key exchange happens in the
reducing the set-up time to one RTT. media plane directly between the peers. The common key exchange
procedures will take two round trips assuming no losses. Transport
Layer Security (TLS) resumption can be used when establishing
additional media streams with the same peer, and it reduces the setup
time to one RTT for these streams (see [RFC5764] for a discussion of
TLS resumption in this context).
The actual security properties of an established SRTP session using The actual security properties of an established SRTP session using
DTLS will depend on the cipher suits offered and used. For example DTLS will depend on the cipher suites offered and used, as well as
some provides perfect forward secrecy (PFS), while other do not. the mechanism for identifying the endpoints of the handshake. For
When using DTLS the application designer needs to select which cipher example, some cipher suites provide PFS, while others do not. When
suits that DTLS-SRTP can offer and accept so that the desired using DTLS, the application designer needs to select which cipher
security properties are achieved. suites DTLS-SRTP can offer and accept so that the desired security
properties are achieved. The next choice is how to verify the
identity of the peer endpoint. One choice can be to rely on the
certificates and use a PKI to verify them to make an identity
assertion. However, this is not the most common way; instead, self-
signed certificates are common to use to establish trust through
signaling or other third-party solutions.
DTLS-SRTP key management can use the signalling protocol in three DTLS-SRTP key management can use the signaling protocol in four ways:
ways. First, to agree on using DTLS-SRTP for media security. First, to agree on using DTLS-SRTP for media security. Second, to
Secondly, to determine the network location (address and port) where determine the network location (address and port) where each side is
each side is running an DTLS listener to let the parts perform the running a DTLS listener to let the parts perform the key management
key-management handshakes that generate the keys used by SRTP. handshakes that generate the keys used by SRTP. Third, to exchange
Finally, to exchange hashes of each sides certificates to enable each hashes of each side's certificates to bind these to the signaling and
side to verify that they have connected to the by signalling ensure there is no MITM attack. This assumes that one can trust the
indicated port and not a man in the middle. That way enabling some signaling solution to be resistant to modification and not be in
binding between the key-exchange and the signalling. This usage is collaboration with an attacker. Finally, to provide an asserted
well defined for SIP/SDP in [RFC5763], and in most cases can be identity, e.g., [RFC4474], that can be used to prevent modification
adopted for use with other bi-directions signalling solutions. of the signaling and the exchange of certificate hashes. That way,
it enables binding between the key exchange and the signaling.
DTLS-SRTP usage and inclusion in specification are clearly on the This usage is well defined for SIP/SDP in [RFC5763] and, in most
rise. It is mandatory to support in WebRTC. It has a growing cases, can be adopted for use with other bidirectional signaling
support among SIP end-points, which is good considering that DTLS- solutions. It is to be noted that there is work underway to revisit
SRTP was primarily developed in IETF to meet security requirements the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
from SIP.
The main question regarding DTLS-SRTP's security properties is how
one verifies any peer identity or at least prevents MITM attacks.
This does require trust in some DTLS-SRTP external parties: either a
PKI, a signaling system, or some identity provider.
DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in Web Real-Time Communication (WebRTC). It has growing support
among SIP endpoints. DTLS-SRTP was developed in IETF primarily to
meet security requirements for RTP-based media established using SIP.
The requirements considered can be reviewed in "Requirements and
Analysis of Media Security Management Protocols" [RFC5479].
3.1.2. Key Management for SRTP: MIKEY 3.1.2. Key Management for SRTP: MIKEY
Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol
that has several modes with different properties. MIKEY can be used that has several modes with different properties. MIKEY can be used
in point-to-point applications using SIP and RTSP (e.g., VoIP calls), in point-to-point applications using SIP and RTSP (e.g., VoIP calls)
but is also suitable for use in broadcast and multicast applications, but is also suitable for use in broadcast and multicast applications
and centralized group communications. and centralized group communications.
MIKEY can establish multiple security contexts or cryptographic MIKEY can establish multiple security contexts or cryptographic
sessions with a single message. It is possible to use in scenarios sessions with a single message. It is usable in scenarios where one
where one entity generates the key and needs to distribute the key to entity generates the key and needs to distribute the key to a number
a number of participants. The different modes and the resulting of participants. The different modes and the resulting properties
properties are highly dependent on the cryptographic method used to are highly dependent on the cryptographic method used to establish
establish the Traffic Generation Key (TGK) that is used to derive the the session keys actually used by the security protocol, like SRTP.
keys actually used by the security protocol, like SRTP.
MIKEY has the following modes of operation: MIKEY has the following modes of operation:
Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto
used to secure a keying message carrying the already generated used to secure a keying message carrying the already-generated
TGK. This system is the most efficient from the perspective of session key. This system is the most efficient from the
having small messages and processing demands. The downside is perspective of having small messages and processing demands. The
scalability, where usually the effort for the provisioning of pre- downside is scalability, where usually the effort for the
shared keys is only manageable, if the number of endpoints is provisioning of pre-shared keys is only manageable if the number
small. of endpoints is small.
Public Key encryption: Uses a public key crypto to secure a keying Public Key Encryption: Uses a public key crypto to secure a keying
message carrying the already generated TGK. This is more resource message carrying the already-generated session key. This is more
consuming but enables scalable systems. It does require a public resource intensive but enables scalable systems. It does require
key infrastructure to enable verification. a public key infrastructure to enable verification.
Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the Diffie-Hellman: Uses Diffie-Hellman key agreement to generate the
TGK, thus providing perfect forward secrecy. The downside is session key, thus providing perfect forward secrecy. The downside
increased resource consumption in bandwidth and processing. This is high resource consumption in bandwidth and processing during
method can't be used to establish group keys as each pair of peers the MIKEY exchange. This method can't be used to establish group
performing the MIKEY exchange will establish different keys. keys as each pair of peers performing the MIKEY exchange will
establish different keys.
HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of
the Diffie-Hellman exchange that uses a pre-shared key in a keyed the Diffie-Hellman exchange that uses a pre-shared key in a keyed
HMAC to verify authenticity of the keying material instead of a Hashed Message Authentication Code (HMAC) to verify authenticity
digital signature as in the previous method. This method is still of the keying material instead of a digital signature as in the
restricted to point-to-point usage. previous method. This method is still restricted to
point-to-point usage.
RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the
public key method which doesn't rely on the initiator of the key- public key method, which doesn't rely on the initiator of the key
exchange knowing the responders certificate. This methods lets exchange knowing the responder's certificate. This method lets
both the initiator and the responder to specify the TGK material both the initiator and the responder specify the session keying
depending on use case. Usage of this mode requires one round trip material depending on the use case. Usage of this mode requires
time. one round-trip time.
TICKET: [RFC6043] is a MIKEY extension using trusted centralized key TICKET: Ticket Payload (TICKET) [RFC6043] is a MIKEY extension using
management service and tickets, like Kerberos. a trusted centralized key management service (KMS). The initiator
and responder do not share any credentials; instead, they trust a
third party, the KMS, with which they both have or can establish
shared credentials.
IBAKE: [RFC6267] uses a key management services (KMS) infrastructure IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) [RFC6267]
but with lower demand on the KMS. Claims to provides both perfect uses a KMS infrastructure but with lower demand on the KMS. It
forward and backwards secrecy, the exact meaning is unclear (See claims to provide both perfect forward and backwards secrecy.
Perfect Forward Secrecy in [RFC4949]).
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption (SAKKE) in
Based on Identity based Public Key Cryptography and a KMS MIKEY. It is based on Identity-based Public Key Cryptography and
infrastructure to establish a shared secret value and certificate a KMS infrastructure to establish a shared secret value and
less signatures to provide source authentication. It features certificateless signatures to provide source authentication. Its
include simplex transmission, scalability, low-latency call set- features include simplex transmission, scalability, low-latency
up, and support for secure deferred delivery. call setup, and support for secure deferred delivery.
MIKEY messages has several different defined transports. [RFC4567] MIKEY messages have several different transports. [RFC4567] defines
defines how MIKEY messages can be embedded in general SDP for usage how MIKEY messages can be embedded in general SDP for usage with the
with the signalling protocols SIP, SAP and RTSP. There also exist an signaling protocols SIP, Session Announcement Protocol (SAP), and
3GPP defined usage of MIKEY that sends MIKEY messages directly over RTSP. There also exists a usage of MIKEY defined by the Third
UDP to key the receivers of Multimedia Broadcast and Multicast Generation Partnership Project (3GPP) that sends MIKEY messages
Service (MBMS) [T3GPP.33.246]. directly over UDP [T3GPP.33.246] to key the receivers of Multimedia
Broadcast and Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830]
defines the application/mikey media type, allowing MIKEY to be used
in, e.g., email and HTTP.
Based on the many choices it is important to consider the properties Based on the many choices, it is important to consider the properties
needed in ones solution and based on that evaluate which modes that needed in one's solution and based on that evaluate which modes are
are candidates for ones usage. More information on the applicability candidates for use. More information on the applicability of the
of the different MIKEY modes can be found in [RFC5197]. different MIKEY modes can be found in [RFC5197].
MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246]. MIKEY with pre-shared keys is used by 3GPP MBMS [T3GPP.33.246], and
While RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies use of the IMS media security [T3GPP.33.328] specifies the use of the TICKET
RSA-R mode. There are some SIP end-points that supports MIKEY and mode transported over SIP and HTTP. RTSP 2.0 [RTSP] specifies use of
which mode they use are unknown by the authors. the RSA-R mode. There are some SIP endpoints that support MIKEY.
The modes they use are unknown to the authors.
3.1.3. Key Management for SRTP: Security Descriptions 3.1.3. Key Management for SRTP: Security Descriptions
[RFC4568] provides a keying solution based on sending plain text keys [RFC4568] provides a keying solution based on sending plaintext keys
in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/ in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/
Answer, and is well-defined in point to point sessions where each Answer model and is well defined in point-to-point sessions where
side declares its own unique key. Using Security Descriptions to each side declares its own unique key. Using security descriptions
establish group keys is less well defined, and can have security to establish group keys is less well defined and can have security
issues as the SSRC uniqueness property can't be guaranteed. issues since it's difficult to guarantee unique SSRCs (as needed to
avoid a "two-time pad" attack -- see Section 9 of [RFC3711]).
Since keys are transported in plain text in SDP, they can easily be Since keys are transported in plaintext in SDP, they can easily be
intercepted unless the SDP carrying protocol provides strong end-to- intercepted unless the SDP carrying protocol provides strong
end confidentiality and authentication guarantees. This is not the end-to-end confidentiality and authentication guarantees. This is
common use of security descriptions with SIP, where instead hop by not normally the case; instead, hop-by-hop security is provided
hop security is provided between signalling nodes using TLS. This between signaling nodes using TLS. This leaves the keying material
still leaves the keying material sensitive to capture by the sensitive to capture by the traversed signaling nodes. Thus, in most
traversed signalling nodes. Thus in most cases the security cases, the security properties of security descriptions are weak.
properties of security descriptions are weak. The usage of security The usage of security descriptions usually requires additional
descriptions usually requires additional security measures, e.g. the security measures; for example, the signaling nodes are trusted and
signalling nodes be trusted and protected by strict access control. protected by strict access control. Usage of security descriptions
Usage of security descriptions requires careful design in order to requires careful design in order to ensure that the security goals
ensure that the security goals can be met. can be met.
Security Descriptions is the most commonly deployed keying solution Security descriptions are the most commonly deployed keying solution
for SIP-based end-points, where almost all that supports SRTP also for SIP-based endpoints, where almost all endpoints that support SRTP
supports Security Descriptions. also support security descriptions. It is also used for access
protection in IMS Media Security [T3GPP.33.328].
3.1.4. Key Management for SRTP: Encrypted Key Transport 3.1.4. Key Management for SRTP: Encrypted Key Transport
Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP Encrypted Key Transport (EKT) [EKT] is an SRTP extension that enables
extension that enables group keying despite using a keying mechanism group keying despite using a keying mechanism like DTLS-SRTP that
that can't support group keys, like DTLS-SRTP. It is designed for doesn't support group keys. It is designed for centralized
centralized conferencing, but can also be used in sessions where an conferencing, but it can also be used in sessions where endpoints
end-points connect to a conference bridge or a gateway, and need to connect to a conference bridge or a gateway and need to be
be provisioned with the keys each participant on the bridge or provisioned with the keys each participant on the bridge or gateway
gateway uses to avoid decryption encryption cycles on the bridge or uses to avoid decryption and encryption cycles. This can enable
gateway. This can enable interworking between DTLS-SRTP and for interworking between DTLS-SRTP and other keying systems where either
example security descriptions or other keying systems where either party can set the key (e.g., interworking with security
part can set the key. descriptions).
The mechanism is based on establishing an additional EKT key which The mechanism is based on establishing an additional EKT key, which
everyone uses to protect their actual session key. The actual everyone uses to protect their actual session key. The actual
session key is sent in a expanded authentication tag to the other session key is sent in an expanded authentication tag to the other
session participants. This key are only sent occasionally or session participants. This key is only sent occasionally or
periodically depending on use cases depending on what requirements periodically depending on use cases and depending on what
exist for timely delivery or notification on when the key is needed requirements exist for timely delivery or notification.
by someone.
The only known deployment of EKT so far are in some Cisco Video The only known deployment of EKT so far is in some Cisco video
Conferencing products. conferencing products.
3.1.5. Key Management for SRTP: Other systems 3.1.5. Key Management for SRTP: ZRTP and Other Solutions
The ZRTP [RFC6189] key-management system for SRTP was proposed as an The ZRTP [RFC6189] key management system for SRTP was proposed as an
alternative to DTLS-SRTP. It wasn't adopted as an IETF standards alternative to DTLS-SRTP. ZRTP provides best effort encryption
track protocol, but was instead published as an informational RFC. independent of the signaling protocol and utilizes key continuity,
Short Authentication Strings, or a PKI for authentication. ZRTP
wasn't adopted as an IETF Standards Track protocol, but was instead
published as an Informational RFC in the IETF stream. Commercial
implementations exist.
Additional proprietary solutions are also known to exist. Additional proprietary solutions are also known to exist.
3.2. RTP Legacy Confidentiality 3.2. RTP Legacy Confidentiality
Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based Section 9 of the RTP standard [RFC3550] defines a Data Encryption
encryption of RTP and RTCP packets. This mechanism is keyed using Standard (DES) or 3DES-based encryption of RTP and RTCP packets.
plain text keys in SDP [RFC4566] using the "k=" SDP field. This This mechanism is keyed using plaintext keys in SDP [RFC4566] using
method of providing confidentiality has extremely weak security the "k=" SDP field. This method can provide confidentiality but, as
discussed in Section 9 of [RFC3550], it has extremely weak security
properties and is not to be used. properties and is not to be used.
3.3. IPsec 3.3. IPsec
IPsec [RFC4301] can be used independent of mode to protect RTP and IPsec [RFC4301] can be used in either tunnel or transport mode to
RTCP packets in transit from one network interface to another. This protect RTP and RTCP packets in transit from one network interface to
can be sufficient when the network interfaces have a direct relation, another. This can be sufficient when the network interfaces have a
or in a secured environment where it can be controlled who can read direct relation or in a secured environment where it can be
the packets from those interfaces. controlled who can read the packets from those interfaces.
The main concern with using IPsec to protect RTP traffic is that in The main concern with using IPsec to protect RTP traffic is that in
most cases using a VPN approach that terminates the security most cases, using a VPN approach that terminates the security
association at some node prior to the RTP end-point leaves the association at some node prior to the RTP endpoint leaves the traffic
traffic vulnerable to attack between the VPN termination node and the vulnerable to attack between the VPN termination node and the
end-point. Thus usage of IPsec requires careful thought and design endpoint. Thus, usage of IPsec requires careful thought and design
of its usage so that it really meets the security goals. A important of its usage so that it meets the security goals. An important
question is how one ensure the IPsec terminating peer and the question is how one ensures the IPsec terminating peer and the
ultimate destination is the same. ultimate destination are the same. Applications can have issues
using existing APIs when determining if IPsec is being used or not
and when determining who the authenticated peer entity is when IPsec
is used.
IPsec with RTP is more commonly used as security solution between IPsec with RTP is more commonly used as a security solution between
central nodes in an infrastructure that exchanges many RTP sessions infrastructure nodes that exchange many RTP sessions and media
and media streams between the peers. The establishment of a secure streams. The establishment of a secure tunnel between such nodes
tunnel between these peers minimizes the key-management overhead minimizes the key management overhead.
between these two boxes.
3.4. DTLS 3.4. RTP over TLS over TCP
Datagram Transport Layer Security (DTLS) [RFC6347] can provide point Just as RTP can be sent over TCP [RFC4571], it can also be sent over
to point security for RTP flows. The two peers would establish an TLS over TCP [RFC4572], using TLS to provide point-to-point security
DTLS association between each other, including the possibility to do services. The security properties TLS provides are confidentiality,
certificate-based source authentication when establishing the integrity protection, and possible source authentication if the
association. All RTP and RTCP packets flowing will be protected by client or server certificates are verified and provide a usable
this DTLS association. identity. When used in multiparty scenarios using a central node for
media distribution, the security provided is only between the central
node and the peers, so the security properties for the whole session
are dependent on what trust one can place in the central node.
Note: using DTLS is different to using DTLS-SRTP key management. RTSP 1.0 [RFC2326] and 2.0 [RTSP] specify the usage of RTP over the
DTLS-SRTP has the core key-management steps in common with DTLS, but same TLS/TCP connection that the RTSP messages are sent over. It
DTLS-SRTP uses SRTP for the per packet security operations, while appears that RTP over TLS/TCP is also used in some proprietary
DTLS uses the normal datagram TLS data protection. When using DTLS, solutions that use TLS to bypass firewalls.
RTP and RTCP packets are completely encrypted with no headers in the
clear, while DTLS-SRTP leaves the headers in the clear.
DTLS can use similar techniques to those available for DTLS-SRTP to 3.5. RTP over Datagram TLS (DTLS)
bind a signalling side agreement to communicate to the certificates
used by the end-point when doing the DTLS handshake. This enables
use without having a certificate based trust chain to a trusted
certificate root.
There appear to be no significant usage of RTP over DTLS. DTLS [RFC6347] is based on TLS [RFC5246] but designed to work over an
unreliable datagram-oriented transport rather than requiring reliable
byte stream semantics from the transport protocol. Accordingly, DTLS
can provide point-to-point security for RTP flows analogous to that
provided by TLS but over a datagram transport such as UDP. The two
peers establish a DTLS association between each other, including the
possibility to do certificate-based source authentication when
establishing the association. All RTP and RTCP packets flowing will
be protected by this DTLS association.
3.5. TLS over TCP Note that using DTLS for RTP flows is different from using DTLS-SRTP
key management. DTLS-SRTP uses the same key management steps as
DTLS, but uses SRTP for the per-packet security operations. Using
DTLS for RTP flows uses the normal datagram TLS data protection,
wrapping complete RTP packets. When using DTLS for RTP flows, the
RTP and RTCP packets are completely encrypted with no headers in the
clear; when using DTLS-SRTP, the RTP headers are in the clear and
only the payload data is encrypted.
When RTP is sent over TCP [RFC4571] it can also be sent over TLS over DTLS can use similar techniques to those available for DTLS-SRTP to
TCP [RFC4572], using TLS to provide point to point security services. bind a signaling-side agreement to communicate to the certificates
The security properties TLS provides are confidentiality, integrity used by the endpoint when doing the DTLS handshake. This enables use
protection and possible source authentication if the client or server without having a certificate-based trust chain to a trusted
certificates are verified and provide a usable identity. When used certificate root.
in multi-party scenarios using a central node for media distribution,
the security provide is only between then central node and the peers,
so the security properties for the whole session are dependent on
what trust one can place in the central node.
RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the There does not appear to be significant usage of DTLS for RTP.
usage of RTP over the same TLS/TCP connection that the RTSP messages
are sent over. It appears that RTP over TLS is also used in some
proprietary solutions that uses TLS to bypass firewalls.
3.6. Payload-only Security Mechanisms 3.6. Media Content Security/Digital Rights Management
Mechanisms have been defined that encrypt only the payload of the RTP Mechanisms have been defined that encrypt only the media content
packets, and leave the RTP headers and RTCP in the clear. There are operating within the RTP payload data and leaving the RTP headers and
several reasons why this might be appropriate, but a common rationale RTCP unaffected. There are several reasons why this might be
is to ensure that the content stored in RTP hint tracks in RTSP appropriate, but a common rationale is to ensure that the content
streaming servers has the media content in a protected format that stored by RTSP streaming servers has the media content in a protected
cannot be read by the streaming server (this is mostly done in the format that cannot be read by the streaming server (this is mostly
context of Digital Rights Management). These approaches then uses a done in the context of Digital Rights Management). These approaches
key-management solution between the rights provider and the consuming then use a key management solution between the rights provider and
client to deliver the key used to protect the content, usually after the consuming client to deliver the key used to protect the content
the appropriate method for charging has happened, and do not include and do not give the media server access to the security context.
the media server in the security context. Such methods have several Such methods have several security weaknesses such as the fact that
security weaknesses such the fact that the same key is handed out to the same key is handed out to a potentially large group of receiving
a potentially large group of receiving clients, increasing the risk clients, increasing the risk of a leak.
of a leak.
Use of this type of solution can be of interest in environments that Use of this type of solution can be of interest in environments that
allow middleboxes to rewrite the RTP headers and select what streams allow middleboxes to rewrite the RTP headers and select which streams
that are delivered to an end-point (e.g., some types of centralised are delivered to an endpoint (e.g., some types of centralized video
video conference systems). The advantage of encrypting and possibly conference systems). The advantage of encrypting and possibly
integrity protecting the payload but not the headers is that the integrity protecting the payload but not the headers is that the
middlebox can't eavesdrop on the media content, but can still provide middlebox can't eavesdrop on the media content, but it can still
stream switching functionality. The downside of such a system is provide stream switching functionality. The downside of such a
that it likely needs two levels of security: the payload level system is that it likely needs two levels of security: the payload-
solution to provide confidentiality and source authentication, and a level solution, to provide confidentiality and source authentication,
second layer with additional transport security ensuring source and a second layer with additional transport security ensuring source
authentication and integrity of the RTP headers associated with the authentication and integrity of the RTP headers associated with the
encrypted payloads. This can also results in the need to have two encrypted payloads. This can also result in the need to have two
different key-management systems as the entity protecting the packets different key management systems as the entity protecting the packets
and payloads are different with different set of keys. and payloads are different with a different set of keys.
The aspect of two tiers of security are present in ISMAcryp (see The aspect of two tiers of security are present in ISMACryp (see
Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service Section 3.6.1) and the deprecated 3GPP Packet-switched Streaming
Annex.K [T3GPP.26.234R8] solution. Service solution; see Annex K of [T3GPP.26.234R8].
3.6.1. ISMA Encryption and Authentication 3.6.1. ISMA Encryption and Authentication
The Internet Streaming Media Alliance (ISMA) has defined ISMA The Internet Streaming Media Alliance (ISMA) has defined ISMA
Encryption and Authentication 2.0 [ISMACrypt2]. This specification Encryption and Authentication 2.0 [ISMACryp2]. This specification
defines how one encrypts and packetizes the encrypted application defines how one encrypts and packetizes the encrypted application
data units (ADUs) in an RTP payload using the MPEG-4 Generic payload data units (ADUs) in an RTP payload using the MPEG-4 generic payload
format [RFC3640]. The ADU types that are allowed are those that can format [RFC3640]. The ADU types that are allowed are those that can
be stored as elementary streams in an ISO Media File format based be stored as elementary streams in an ISO Media File format-based
file. ISMAcryp uses SRTP for packet level integrity and source file. ISMACryp uses SRTP for packet-level integrity and source
authentication from a streaming server to the receiver. authentication from a streaming server to the receiver.
Key-management for a ISMACryp based system can be achieved through Key management for an ISMACryp-based system can be achieved through
Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2],
for example. for example.
4. Securing RTP Applications 4. Securing RTP Applications
In the following we provide guidelines for how to choose appropriate In the following, we provide guidelines for how to choose appropriate
security mechanisms for RTP applications. security mechanisms for RTP applications.
4.1. Application Requirements 4.1. Application Requirements
This section discusses a number of application requirements that need This section discusses a number of application requirements that need
be considered. An application designer choosing security solutions to be considered. An application designer choosing security
requires a good understanding of what level of security is needed and solutions requires a good understanding of what level of security is
what behaviour they strive to achieve. needed and what behavior they strive to achieve.
4.1.1. Confidentiality 4.1.1. Confidentiality
When it comes to confidentiality of an RTP session there are several When it comes to confidentiality of an RTP session, there are several
aspects to consider: aspects to consider:
Probability of compromise: When using encryption to provide media Probability of compromise: When using encryption to provide media
confidentiality, it is necessary to have some rough understanding confidentiality, it is necessary to have some rough understanding
of the security goal and how long one expect the protected content of the security goal and how long one can expect the protected
remain confidential. National or other regulations might provided content to remain confidential. National or other regulations
additional requirements on a particular usage of an RTP. From might provide additional requirements on a particular usage of an
that, one can determine what encryption algorithms are to be used RTP. From that, one can determine which encryption algorithms are
from the set of available transforms. to be used from the set of available transforms.
Potential for other leakage: RTP based security in most of its forms Potential for other leakage: RTP-based security in most of its forms
simply wraps RTP and RTCP packets into cryptographic containers. simply wraps RTP and RTCP packets into cryptographic containers.
This commonly means that the size of the original RTP payload, and This commonly means that the size of the original RTP payload is
details of the RTP and RTCP headers, are visible to observers of visible to observers of the protected packet flow. This can
the protected packet flow. This can provide information to those provide information to those observers. A well-documented case is
observers. A well documented case is the risk with variable bit- the risk with variable bitrate speech codecs that produce
rate speech codecs that produce different sized packets based on different sized packets based on the speech input [RFC6562].
the speech input [RFC6562]. Potential threats such as these need Potential threats such as these need to be considered and, if they
to be considered and, if they are significant, then restrictions are significant, then restrictions will be needed on mode choices
will be needed on mode choices in the codec, or additional padding in the codec, or additional padding will need to be added to make
will need to be added to make all packets equal size and remove all packets equal size and remove the informational leakage.
the informational leakage.
Another case is RTP header extensions. If SRTP is used, header Another case is RTP header extensions. If SRTP is used, header
extensions are normally not protected by the security mechanism extensions are normally not protected by the security mechanism
protecting the RTP payload. If the header extension carries protecting the RTP payload. If the header extension carries
information that is considered sensitive, then the application information that is considered sensitive, then the application
needs to be modified to ensure that mechanisms used to protect needs to be modified to ensure that mechanisms used to protect
against such information leakage are employed. against such information leakage are employed.
Who has access: When considering the confidentiality properties of a Who has access: When considering the confidentiality properties of a
system, it is important to consider where the media handled in the system, it is important to consider where the media handled in the
clear. For example, if the system is based on an RTP mixer that clear. For example, if the system is based on an RTP mixer that
needs the keys to decrypt the media, process, and repacketize it, needs the keys to decrypt the media, process it, and repacketize
then is the mixer providing the security guarantees expected by it, then is the mixer providing the security guarantees expected
the other parts of the system? Furthermore, it is important to by the other parts of the system? Furthermore, it is important to
consider who has access to the keys, and are the keys stored or consider who has access to the keys. The policies for the
kept somewhere? The policies for the handling of the keys, and handling of the keys, and who can access the keys, need to be
who can access the keys, need to be considered along with the considered along with the confidentiality goals.
confidentiality goals.
As can be seen the actual confidentiality level has likely more to do As can be seen, the actual confidentiality level has likely more to
with the application's usage of centralized nodes, and the details of do with the application's usage of centralized nodes, and the details
the key-management solution chosen, than with the actual choice of of the key management solution chosen, than with the actual choice of
encryption algorithm (although, of course, the encryption algorithm encryption algorithm (although, of course, the encryption algorithm
needs to be chosen appropriately for the desired security level). needs to be chosen appropriately for the desired security level).
4.1.2. Integrity 4.1.2. Integrity
Protection against modification of content by a third party, or due Protection against modification of content by a third party, or due
to errors in the network, is another factor to consider. The first to errors in the network, is another factor to consider. The first
aspect that one consider is what resilience one has against aspect that one assesses is what resilience one has against
modifications to the content. This can affect what cryptographic modifications to the content. Some media types are extremely
algorithm is used, and the length of the integrity tags. However sensitive to network bit errors, whereas others might be able to
equally, important is to consider who is providing the integrity tolerate some degree of data corruption. Equally important is to
assertion, what is the source of the integrity tag, and what are the consider the sensitivity of the content, who is providing the
risks of modifications happening prior to that point where protection integrity assertion, what is the source of the integrity tag, and
is applied? RTP applications that rely on central nodes need to what are the risks of modifications happening prior to that point
consider if hop-by-hop integrity is acceptable, or if true end-to-end where protection is applied. These issues affect what cryptographic
integrity protection is needed? Is it important to be able to tell algorithm is used, the length of the integrity tags, and whether the
if a middlebox has modified the data? There are some uses of RTP entire payload is protected.
that require trusted middleboxes that can modify the data in a way
that doesn't break integrity protection as seen by the receiver, for RTP applications that rely on central nodes need to consider if
example local advertisement insertion in IPTV systems; there are also hop-by-hop integrity is acceptable or if true end-to-end integrity
uses where it is essential that such in-network modification be protection is needed. Is it important to be able to tell if a
detectable. RTP can support both, with appropriate choices of middlebox has modified the data? There are some uses of RTP that
require trusted middleboxes that can modify the data in a way that
doesn't break integrity protection as seen by the receiver, for
example, local advertisement insertion in IPTV systems. There are
also uses where it is essential that such in-network modification be
detectable. RTP can support both with appropriate choices of
security mechanisms. security mechanisms.
Integrity of the data is commonly closely tied to the question of Integrity of the data is commonly closely tied to the question of
source authentication. That is, it becomes important to know who source authentication. That is, it becomes important to know who
makes an integrity assertion for the data. makes an integrity assertion for the data.
4.1.3. Source Authentication 4.1.3. Source Authentication
Source authentication is about determining who sent a particular RTP Source authentication is about determining who sent a particular RTP
or RTCP packet. It is normally closely tied with integrity, since or RTCP packet. It is normally closely tied with integrity, since a
you also want to ensure that what you received is what the claimed receiver generally also wants to ensure that the data received is
source really sent, so source authentication without integrity is not what the source really sent, so source authentication without
particularly useful. In similar way, although not as definitive, is integrity is not particularly useful. Similarly, integrity
that integrity without source authentication is also not particular protection without source authentication is also not particularly
useful: you need to know who claims this packet wasn't changed. useful; a claim that a packet is unchanged that cannot itself be
validated as from the source (or some from other known and trusted
party) is meaningless.
Source authentication can be asserted in several different ways: Source authentication can be asserted in several different ways:
Base level: Using cryptographic mechanisms that give authentication Base level: Using cryptographic mechanisms that give authentication
with some type of key-management provides an implicit method for with some type of key management provide an implicit method for
source authentication. Assuming that the mechanism has sufficient source authentication. Assuming that the mechanism has sufficient
strength to not be circumvented in the time frame when you would strength not to be circumvented in the time frame when you would
accept the packet as valid, it is possible to assert a source accept the packet as valid, it is possible to assert a source-
authenticated statement; this message is highly probably from authenticated statement; this message is likely from a source that
someone that has the cryptographic key(s) to this communication. has the cryptographic key(s) to this communication.
What that assertion actually means is highly dependent on the What that assertion actually means is highly dependent on the
application, and how it handles the keys. In an application where application and how it handles the keys. If only the two peers
the key-handling is limited to two peers, this can form a basis have access to the keys, this can form a basis for a strong trust
for a trust relationship to the level that you can state as the relationship that traffic is authenticated coming from one of the
traffic is authenticated and matching this particular context. peers. However, in a multiparty scenario where security contexts
Thus, it is coming either from me or from my peer (and I trust are shared among participants, most base-level authentication
that neither has shared the key with anyone else). However, in a solutions can't even assert that this packet is from the same
multi-party scenario where security contexts are shared among source as the previous packet.
participants, most base-level authentication solutions can't even
assert that this packet is from the same source as the previous
packet.
Binding the Source: A step up in the assertion that can be done in
base-level systems is to tie the signalling to the key-exchange.
Here, the goal is to be at least be able to assert that the sender
of the packets is the same entity that I have established the
session with. How feasible this is depends on the properties of
the key-management system used, the ability to tie the signalling
to a particular peer, and what trust you place on the different
nodes involved.
For example, consider a point to point communication system that Binding the source and the signaling: A step up in the assertion
use DTLS-SRTP using self-signed certificates for key-management, that can be done in base-level systems is to tie the signaling to
and SIP for signalling. In such a system the end-points for the the key exchange. Here, the goal is to at least be able to assert
DTLS-SRTP handshake have securely established keys that are not that the source of the packets is the same entity with which the
visible to the signalling nodes. However, as the certificates receiver established the session. How feasible this is depends on
used by DTLS is not bound to any PKI they can't be verified. the properties of the key management system, the ability to tie
Instead, hashes over the certificate are sent over the signalling the signaling to a particular source, and the degree of trust the
path. If the signalling can be trusted not to collaborate on receiver places on the different nodes involved.
performing a man in the middle attack by modifying the hashes,
then the end-points can verify that they have established keys
with the peer they are doing signalling with.
Systems where the key-exchange are done using the signalling For example, systems where the key exchange is done using the
systems, such as Security Descriptions [RFC4568] or MIKEY embedded signaling systems, such as security descriptions [RFC4568] enable
in SDP [RFC4567], enables an direct binding between signalling and a direct binding between signaling and key exchange. In such
key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual systems, the actual security depends on the trust one can place in
security depends on the trust one can place in the signalling the signaling system to correctly associate the peer's identifier
system to correctly associate the peer's identity with the key- with the key exchange.
exchange.
Using Identities: If the applications have access to a system that Using identifiers: If the applications have access to a system that
can provide verifiable identities, then the source authentication can provide verifiable identifiers, then the source authentication
can be bound to that identity. For example, in a point-to-point can be bound to that identifier. For example, in a point-to-point
communication even symmetric key crypto, where the key-management communication, even symmetric key crypto, where the key management
can assert that the key has only been exchanged with a particular can assert that the key has only been exchanged with a particular
identity, can provide a strong assertion about who is sending the identifier, can provide a strong assertion about the source of the
traffic. traffic. SIP Identity [RFC4474] provides one example of how this
can be done and could be used to bind DTLS-SRTP certificates used
Note that all levels of the system much have matching capability by an endpoint to the identity provider's public key to
to assert identity. Having the signalling assert that you include authenticate the source of a DTLS-SRTP flow.
a particular identity in a multi-party communication session where
the key-management systems establish keys in a way that one can
assert that only the given identity has gotten the key. Using a
authentication mechanism built on a group key that otherwise can't
provide any assertion who sent the traffic than anyone that got
the key, provides no strong assertion on the media level than:
Someone that has gotten the security context (key) sent this
traffic.
4.1.4. Identity Note that all levels of the system need to have matching
capability to assert identifiers. If the signaling can assert
that only a given entity in a multiparty session has a key, then
the media layer might be able to provide guarantees about the
identifier used by the media sender. However, using a signaling
authentication mechanism built on a group key can limit the media
layer to asserting only group membership.
There exist many different types of identity systems with different 4.1.4. Identifiers and Identity
properties. But in the context of RTP applications the most
important property is the possibility to perform source
authentication and verify such assertions in relation to any claimed
identities. What an identity really are can also vary, but in the
context of communication, one of the most obvious is the identity of
the human user one communicates with. However, the human user can
also have additional identities in a particular role. For example,
the human Alice, can also be a police officer and in some cases her
identity as police officer will be more relevant then that she is
Alice. This is common in contact with organizations, where it is
important to prove the persons right to represent the organization.
Some examples of identity mechanisms that could be used: There exist many different types of systems providing identifiers
with different properties (e.g., SIP Identity [RFC4474]). In the
context of RTP applications, the most important property is the
possibility to perform source authentication and verify such
assertions in relation to any claimed identifiers. What an
identifier really represents can also vary but, in the context of
communication, one of the most obvious is the identifiers
representing the identity of the human user with which one
communicates. However, the human user can also have additional
identifiers in a particular role. For example, the human (Alice) can
also be a police officer, and in some cases, an identifier for her
role as police officer will be more relevant than one that asserts
that she is Alice. This is common in contact with organizations,
where it is important to prove the person's right to represent the
organization. Some examples of identifier/identity mechanisms that
can be used:
Certificate based: A certificate is used to prove the identity, by Certificate based: A certificate is used to assert the identifiers
having access to the private part of the certificate one can used to claim an identity; by having access to the private part of
perform signing to assert ones identity. Any entity interested in the certificate, one can perform signing to assert one's identity.
verifying the assertion then needs the public part of the Any entity interested in verifying the assertion then needs the
certificate. By having the certificate one can verify the signing public part of the certificate. By having the certificate, one
against the certificate. The next step is to determine if one can verify the signature against the certificate. The next step
trusts the certificate's trust chain. Commonly by provisioning is to determine if one trusts the certificate's trust chain.
the verifier with the public part of a root certificate, this Commonly, by provisioning the verifier with the public part of a
enables the verifier to verify a trust chain from the root root certificate, this enables the verifier to verify a trust
certificate down to the identity certificate. However, the trust chain from the root certificate down to the identifier in the
is based on that all steps in the certificate chain are verifiable certificate. However, the trust is based on all steps in the
and can be trusted. Thus provisioning of root certificates, certificate chain being verifiable and trusted. Thus, the
having possibility to revoke compromised certificates are aspects provisioning of root certificates and the ability to revoke
that will require infrastructure. compromised certificates are aspects that will require
infrastructure.
Online Identity Providers: An online identity provider (IdP) can Online identity providers: An online identity provider (IdP) can
authenticate a user's right to use an identity, then perform authenticate a user's right to use an identifier and then perform
assertions on their behalf or provision the requester with short- assertions on their behalf or provision the requester with short-
term credentials to assert their identity. The verifier can then term credentials to assert the identifiers. The verifier can then
contact the IdP to request verification of a particular identity. contact the IdP to request verification of a particular
Here the trust is highly dependent on how much one trusts the IdP. identifier. Here, the trust is highly dependent on how much one
The system also becomes dependent on having access to the relevant trusts the IdP. The system also becomes dependent on having
IdP. access to the relevant IdP.
In all of the above examples, an important part of the security In all of the above examples, an important part of the security
properties are related to the method for authenticating the access to properties is related to the method for authenticating the access to
the identity. the identity.
4.1.5. Privacy 4.1.5. Privacy
RTP applications need to consider what privacy goals they have. As RTP applications need to consider what privacy goals they have. As
RTP applications communicate directly between peers in many cases, RTP applications communicate directly between peers in many cases,
the IP addresses of any communication peer will be available. The the IP addresses of any communication peer will be available. The
main privacy concern with IP addresses is related to geographical main privacy concern with IP addresses is related to geographical
location and the possibility to track a user of an end-point. The location and the possibility to track a user of an endpoint. The
main way of avoid such concerns is the introduction of relay or main way to avoid such concerns is the introduction of relay (e.g., a
centralized media mixers or forwarders that hides the address of a Traversal Using Relay NAT (TURN) server [RFC5766]) or centralized
peer from any other peer. The security and trust placed in these media mixers or forwarders that hide the address of a peer from any
relays obviously needs to be carefully considered. other peer. The security and trust placed in these relays obviously
needs to be carefully considered.
RTP itself can contribute to enabling a particular user to be tracked RTP itself can contribute to enabling a particular user to be tracked
between communication sessions if the CNAME is generated according to between communication sessions if the Canonical Name (CNAME) is
the RTP specification in the form of user@host. Such RTCP CNAMEs are generated according to the RTP specification in the form of
likely long term stable over multiple sessions, allowing tracking of user@host. Such RTCP CNAMEs are likely long-term stable over
users. This can be desirable for long-term fault tracking and multiple sessions, allowing tracking of users. This can be desirable
diagnosis, but clearly has privacy implications. Instead for long-term fault tracking and diagnosis, but it clearly has
cryptographically random ones could be used as defined by Guidelines privacy implications. Instead, cryptographically random ones could
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) be used as defined by "Guidelines for Choosing RTP Control Protocol
[I-D.ietf-avtcore-6222bis]. (RTCP) CNAMEs" [RFC7022].
If there exist privacy goals, these need to be considered, and the If privacy goals exist, they need to be considered and the system
system designed with them in mind. In addition certain RTP features designed with them in mind. In addition, certain RTP features might
might have to be configured to safeguard privacy, or have have to be configured to safeguard privacy or have requirements on
requirements on how the implementation is done. how the implementation is done.
4.2. Application Structure 4.2. Application Structure
When it comes to RTP security, the most appropriate solution is often When it comes to RTP security, the most appropriate solution is often
highly dependent on the topology of the communication session. The highly dependent on the topology of the communication session. The
signalling also impacts what information can be provided, and if this signaling also impacts what information can be provided and if this
can be instance specific, or common for a group. In the end the key- can be instance specific or common for a group. In the end, the key
management system will highly affect the security properties achieved management system will highly affect the security properties achieved
by the application. At the same time, the communication structure of by the application. At the same time, the communication structure of
the application limits what key management methods are applicable. the application limits what key management methods are applicable.
As different key-management have different requirements on underlying As different key management methods have different requirements on
infrastructure it is important to take that aspect into consideration underlying infrastructure, it is important to take that aspect into
early in the design. consideration early in the design.
4.3. Automatic Key Management
The guidelines for Cryptographic Key Management [RFC4107] provide an
overview of why automatic key management is important. They also
provide a strong recommendation on using automatic key management.
Most of the security solutions reviewed in this document provide or
support automatic key management, at least to establish session keys.
In some more long-term use cases, credentials might need to be
manually deployed in certain cases.
For SRTP, an important aspect of automatic key management is to
ensure that two-time pads do not occur, in particular by preventing
multiple endpoints using the same session key and SSRC. In these
cases, automatic key management methods can have strong dependencies
on signaling features to function correctly. If those dependencies
can't be fulfilled, additional constrains on usage, e.g., per-
endpoint session keys, might be needed to avoid the issue.
When selecting security mechanisms for an RTP application, it is
important to consider the properties of the key management. Using
key management that is both automatic and integrated will provide
minimal interruption for the user and is important to ensure that
security can, and will remain, to be on by default.
4.4. End-to-End Security vs. Tunnels
If the security mechanism only provides a secured tunnel, for
example, like some common uses of IPsec (Section 3.3), it is
important to consider the full end-to-end properties of the system.
How does one ensure that the path from the endpoint to the local
tunnel ingress/egress is secure and can be trusted (and similarly for
the other end of the tunnel)? How does one handle the source
authentication of the peer, as the security protocol identifies the
other end of the tunnel? These are some of the issues that arise
when one considers a tunnel-based security protocol rather than an
end-to-end one. Even with clear requirements and knowledge that one
still can achieve the security properties using a tunnel-based
solution, one ought to prefer to use end-to-end mechanisms, as they
are much less likely to violate any assumptions made about
deployment. These assumptions can also be difficult to automatically
verify.
4.5. Plaintext Keys
Key management solutions that use plaintext keys, like SDP security
descriptions (Section 3.1.3), require care to ensure a secure
transport of the signaling messages that contain the plaintext keys.
For plaintext keys, the security properties of the system depend on
how securely the plaintext keys are protected end-to-end between the
sender and receiver(s). Not only does one need to consider what
transport protection is provided for the signaling message, including
the keys, but also the degree to which any intermediaries in the
signaling are trusted. Untrusted intermediaries can perform MITM
attacks on the communication or can log the keys, resulting in the
encryption being compromised significantly after the actual
communication occurred.
4.6. Interoperability
4.3. Interoperability
Few RTP applications exist as independent applications that never Few RTP applications exist as independent applications that never
interoperate with anything else. Rather, they enable communication interoperate with anything else. Rather, they enable communication
with a potentially large number of other systems. To minimize the with a potentially large number of other systems. To minimize the
number of security mechanisms that need to be implemented, it is number of security mechanisms that need to be implemented, it is
important to consider if one can use the same security mechanisms as important to consider if one can use the same security mechanisms as
other applications. This can also reduce the problems of determining other applications. This can also reduce problems with determining
what security level is actually negotiated in a particular session. what security level is actually negotiated in a particular session.
The desire to be interoperable can in some cases be in conflict with The desire to be interoperable can, in some cases, be in conflict
the security requirements determined for an application. To meet the with the security requirements of an application. To meet the
security goals, it might be necessary to sacrifice interoperability. security goals, it might be necessary to sacrifice interoperability.
Alternatively, one can implement multiple security mechanisms, but Alternatively, one can implement multiple security mechanisms; this,
then end up with an issue of ensuring that the user understands what however, introduces the complication of ensuring that the user
it means to use a particular security level. In addition, the understands what it means to use a particular security system. In
application can then become vulnerable to bid-down attack. addition, the application can then become vulnerable to bid-down
attacks.
5. Examples 5. Examples
In the following we describe a number of example security solutions In the following, we describe a number of example security solutions
for RTP using applications, services or frameworks. These examples for applications using RTP services or frameworks. These examples
are provided to show the choices that can be made. They are not are provided to illustrate the choices available. They are not
normative recommendations for security. normative recommendations for security.
5.1. Media Security for SIP-established Sessions using DTLS-SRTP 5.1. Media Security for SIP-Established Sessions Using DTLS-SRTP
The IETF evaluated media security for RTP sessions established using In 2009, the IETF evaluated media security for RTP sessions
point-to-point SIP sessions in 2009. A number of requirements were established using point-to-point SIP sessions. A number of
determined, and based on those, the existing solutions for media requirements were determined, and based on those, the existing
security and especially the keying methods were analysed, and the solutions for media security and especially the keying methods were
resulting requirements and analysis were published in [RFC5479]. analyzed. The resulting requirements and analysis were published in
Based on this analysis, and the working group discussion, DTLS-SRTP [RFC5479]. Based on this analysis and working group discussion,
was determined to be the best solution, and the specifications were DTLS-SRTP was determined to be the best solution.
finalized.
The security solution for SIP using DTLS-SRTP is defined in the The security solution for SIP using DTLS-SRTP is defined in
Framework for Establishing a Secure Real-time Transport Protocol "Framework for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer Security (SRTP) Security Context Using Datagram Transport Layer Security
(DTLS) [RFC5763]. On a high level it uses SIP with SDP offer/answer (DTLS)" [RFC5763]. On a high level, the framework uses SIP with SDP
procedures to exchange the network addresses where the server end- offer/answer procedures to exchange the network addresses where the
point will have a DTLS-SRTP enable server running. The SIP server endpoint will have a DTLS-SRTP-enabled server running. The
signalling is also used to exchange the fingerprints of the SIP signaling is also used to exchange the fingerprints of the
certificate each end-point will use in the DTLS establishment certificate each endpoint will use in the DTLS establishment process.
process. When the signalling is sufficiently completed the DTLS-SRTP When the signaling is sufficiently completed, the DTLS-SRTP client
client performs DTLS handshakes and establishes SRTP session keys. performs DTLS handshakes and establishes SRTP session keys. The
The clients also verify the fingerprints of the certificates to clients also verify the fingerprints of the certificates to verify
verify that no man in the middle has inserted themselves into the that no man in the middle has inserted themselves into the exchange.
exchange.
At the basic level DTLS has a number of good security properties. DTLS has a number of good security properties. For example, to
For example, to enable a man in the middle someone in the signalling enable a MITM, someone in the signaling path needs to perform an
path needs to perform an active action and modify the signalling active action and modify both the signaling message and the DTLS
message. There also exist a solution that enables the fingerprints handshake. Solutions also exist that enable the fingerprints to be
to be bound to identities established by the first proxy for each bound to identities. SIP Identity provides an identity established
user [RFC4916]. That reduces the number of nodes the connecting user by the first proxy for each user [RFC4474]. This reduces the number
User Agent has to trust to the first hop proxy, rather than the full of nodes the connecting User Agent has to trust to include just the
signalling path. first-hop proxy rather than the full signaling path. The biggest
security weakness of this system is its dependency on the signaling.
SIP signaling passes multiple nodes and there is usually no message
security deployed, only hop-by-hop transport security, if any,
between the nodes.
5.2. Media Security for WebRTC Sessions 5.2. Media Security for WebRTC Sessions
Web Real-Time Communication [I-D.ietf-rtcweb-overview] is solution Web Real-Time Communication (WebRTC) [WebRTC] is a solution providing
providing web-application with real-time media directly between JavaScript web applications with real-time media directly between
browsers. The RTP transported real-time media is protected using a browsers. Media is transported using RTP and protected using a
mandatory to use application of SRTP. The default keying of SRTP is mandatory application of SRTP [RFC3711], with keying done using DTLS-
done using DTLS-SRTP. The security configuration is further defined SRTP [RFC5764]. The security configuration is further defined in
in the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. "WebRTC Security Architecture" [WebRTC-SEC].
The peers hash of their certificates are provided to a Javascript A hash of the peer's certificate is provided to the JavaScript web
application that is part of a client server system providing application, allowing that web application to verify identity of the
rendezvous services for the ones a given peer wants to communicate peer. There are several ways in which the certificate hashes can be
with. Thus the handling of the hashes between the peers is not well verified. An approach identified in the WebRTC security architecture
defined. It becomes a matter of trust in the application. But [WebRTC-SEC] is to use an identity provider. In this solution, the
unless the application and its server is intending to compromise the identity provider, which is a third party to the web application,
communication security they can provide a secure and integrity signs the DTLS-SRTP hash combined with a statement on the validity of
protected exchange of the certificate hashes thus preventing any man- the user identity that has been used to sign the hash. The receiver
in-the-middle (MITM) to insert itself in the key-exchange. of such an identity assertion can then independently verify the user
identity to ensure that it is the identity that the receiver intended
to communicate with, and that the cryptographic assertion holds; this
way, a user can be certain that the application also can't perform a
MITM and acquire the keys to the media communication. Other ways of
verifying the certificate hashes exist; for example, they could be
verified against a hash carried in some out-of-band channel (e.g.,
compare with a hash printed on a business card) or using a verbal
short authentication string (e.g., as in ZRTP [RFC6189]) or using
hash continuity.
The web application still have the possibility to insert a MITM. In the development of WebRTC, there has also been attention given to
That unless one uses a Identity provider and the proposed identity privacy considerations. The main RTP-related concerns that have been
solution [I-D.ietf-rtcweb-security-arch]. In this solution the raised are:
Identity Provider which is a third party to the web-application signs
the DTLS-SRTP hash combined with a statement on which user identity
that has been used to sign the hash. The receiver of such a Identity
assertion then independently verifies the user identity to ensure
that it is the identity it intended to communicate and that the
cryptographic assertion holds. That way a user can be certain that
the application also can't perform an MITM and that way acquire the
keys to the media communication.
In the development of WebRTC there has also been high attention on Location disclosure: As Interactive Connectivity Establishment (ICE)
privacy question. The main concerns that has been raised and are at negotiation [RFC5245] provides IP addresses and ports for the
all related to RTP are: browser, this leaks location information in the signaling to the
peer. To prevent this, one can block the usage of any ICE
candidate that isn't a relay candidate, i.e., where the IP and
port provided belong to the service providers media traffic relay.
Location Disclosure: As ICE negotiation provides IP addresses and Prevent tracking between sessions: Static RTP CNAMEs and DTLS-SRTP
ports for the browser, this leaks location information in the certificates provide information that is reused between session
signalling to the peer. To prevent this one can block the usage instances. Thus, to prevent tracking, such information ought not
of any ICE candidate that isn't a relay candidate, i.e. where the be reused between sessions, or the information ought not be sent
IP and port provided belong to the service providers media traffic in the clear. Note that generating new certificates each time
relay. prevents continuity in authentication, however, as WebRTC users
are expected to use multiple devices to access the same
communication service, such continuity can't be expected anyway;
instead, the above-described identity mechanism has to be relied
on.
Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP Note: The above cases are focused on providing privacy from other
certificates is information that could possibly be re-used between parties, not on providing privacy from the web server that provides
session instances. Thus to prevent tracking the same information the WebRTC JavaScript application.
can't be re-used between different communication sessions.
Note: The above cases are focused on providing privacy towards other 5.3. IP Multimedia Subsystem (IMS) Media Security
parties than the web service.
5.3. 3GPP Packet Based Streaming Service (PSS) In IMS, the core network is controlled by a single operator or by
several operators with high trust in each other. Except for some
types of accesses, the operator is in full control, and no packages
are routed over the Internet. Nodes in the core network offer
services such as voice mail, interworking with legacy systems (Public
Switched Telephone Network (PSTN), Global System for Mobile
Communications (GSM), and 3G), and transcoding. Endpoints are
authenticated during the SIP registration using either IMS and
Authentication and Key Agreement (AKA) (using Subscriber Identity
Module (SIM) credentials) or SIP Digest (using a password).
The 3GPP Release 11 PSS specification of the Packet Based Streaming In IMS media security [T3GPP.33.328], end-to-end encryption is,
Service (PSS) [T3GPP.26.234R11] defines in Annex R a set of security therefore, not seen as needed or desired as it would hinder, for
mechanisms. These security mechanisms are centred around protecting example, interworking and transcoding, making calls between
the content from being captured, i.e. Digital Rights Management. If incompatible terminals impossible. Because of this, IMS media
these goals are to be meet with the specified solution there needs to security mostly uses end-to-access-edge security where SRTP is
exist trust in that neither the implementation of the client nor the terminated in the first node in the core network. As the SIP
platform the application runs can be accessed or modified by the signaling is trusted and encrypted (with TLS or IPsec), security
attacker. descriptions [RFC4568] is considered to give good protection against
eavesdropping over the accesses that are not already encrypted (GSM,
3G, and Long Term Evolution (LTE)). Media source authentication is
based on knowledge of the SRTP session key and trust in that the IMS
network will only forward media from the correct endpoint.
PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus For enterprises and government agencies, which might have weaker
an RTSP client whose user wants to access a protected content will trust in the IMS core network and can be assumed to have compatible
request a session description (SDP [RFC4566]) for the protected terminals, end-to-end security can be achieved by deploying their own
content. This SDP will indicate that the media are ISMA Crypt 2.0 key management server.
[ISMACrypt2] protected media encoding application units (AUs). The
key(s) used to protect the media are provided in either of two ways. Work on interworking with WebRTC is currently ongoing; the security
If a single key is used then the client uses some DRM system to will still be end-to-access-edge but using DTLS-SRTP [RFC5763]
retrieve the key as indicated in the SDP. Commonly OMA DRM v2 instead of security descriptions.
5.4. 3GPP Packet-Switched Streaming Service (PSS)
The 3GPP Release 11 PSS specification of the Packet-switched
Streaming Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set
of security mechanisms. These security mechanisms are concerned with
protecting the content from being copied, i.e., Digital Rights
Management (DRM). To meet these goals with the specified solution,
the client implementation and the application platform are trusted to
protect against access and modification by an attacker.
PSS is media controlled by RTSP 1.0 [RFC2326] streaming over RTP.
Thus, an RTSP client whose user wants to access a protected content
will request a session description (SDP [RFC4566]) for the protected
content. This SDP will indicate that the media is protected by
ISMACryp 2.0 [ISMACryp2] encoding application units (AUs). The
key(s) used to protect the media is provided in one of two ways. If
a single key is used, then the client uses some DRM system to
retrieve the key as indicated in the SDP. Commonly, OMA DRM v2
[OMADRMv2] will be used to retrieve the key. If multiple keys are to [OMADRMv2] will be used to retrieve the key. If multiple keys are to
be used, then using RTSP an additional stream for key-updates in be used, then an additional RTSP stream for key updates in parallel
parallel with the media streams are established, where key updates with the media streams is established, where key updates are sent to
are sent to the client using Short Term Key Messages defined by the client using Short Term Key Messages defined in the "Service and
"Service and Content Protection for Mobile Broadcast Services" part Content Protection for Mobile Broadcast Services" part [OMASCP] of
of the OMA Mobile Broadcast Services [OMABCAST]. the OMA Mobile Broadcast Services [OMABCAST].
Worth noting is that this solution doesn't provide any integrity Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header verification method for the RTP header and payload header
information, only the encoded media AU is protected. 3GPP has not information; only the encoded media AU is protected. 3GPP has not
defined any requirement for supporting SRTP or other solution that defined any requirement for supporting any solution that could
could provide that service. Thus, replay or insertion attacks are provide that service. Thus, replay or insertion attacks are
possible. Another property is that the media content can be possible. Another property is that the media content can be
protected by the ones providing the media, so that the operators of protected by the ones providing the media, so that the operators of
the RTSP server has no access to unprotected content. Instead all the RTSP server have no access to unprotected content. Instead, all
that want to access the media is supposed to contact the DRM keying that want to access the media are supposed to contact the DRM keying
server and if the device is acceptable they will be given the key to server, and if the device is acceptable, they will be given the key
decrypt the media. to decrypt the media.
To protect the signalling RTSP 1.0 supports the usage of TLS, this is To protect the signaling, RTSP 1.0 supports the usage of TLS. This
however not explicitly discussed in the PSS specification. Usage of is, however, not explicitly discussed in the PSS specification.
TLS can prevent both modification of the session description Usage of TLS can prevent both modification of the session description
information and help maintain some privacy of what content the user information and help maintain some privacy of what content the user
is watching as all URLs would then be confidentiality protected. is watching as all URLs would then be confidentiality protected.
5.4. RTSP 2.0 5.5. RTSP 2.0
Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] can be The Real-time Streaming Protocol 2.0 [RTSP] offers an interesting
an interesting comparison to the PSS service (Section 5.3) that is comparison to the PSS service (Section 5.4) that is based on RTSP 1.0
based on RTSP 1.0 and service requirements perceived by mobile and service requirements perceived by mobile operators. A major
operators. A major difference between RTSP 1.0 and RTSP 2.0 is that difference between RTSP 1.0 and RTSP 2.0 is that 2.0 is fully defined
2.0 is fully defined under the requirement to have mandatory to under the requirement to have a mandatory-to-implement security
implement security mechanism. As it specifies how one transport mechanism. As it specifies one transport media over RTP, it is also
media over RTP it is also defining security mechanisms for the RTP defining security mechanisms for the RTP-transported media streams.
transported media streams.
The security goals for RTP in RTSP 2.0 is to ensure that there are The security goal for RTP in RTSP 2.0 is to ensure that there is
confidentiality, integrity and source authentication between the RTSP confidentiality, integrity, and source authentication between the
server and the client. This to prevent eavesdropping on what the RTSP server and the client. This to prevent eavesdropping on what
user is watching for privacy reasons and prevent replay or injection the user is watching for privacy reasons and to prevent replay or
attacks on the media stream. To reach these goals also the injection attacks on the media stream. To reach these goals, the
signalling has to be protected, requiring the use of TLS between the signaling also has to be protected, requiring the use of TLS between
client and server. the client and server.
Using TLS protected signalling the client and server agrees on the Using TLS-protected signaling, the client and server agree on the
media transport method when doing the SETUP request and response. media transport method when doing the SETUP request and response.
The secured media transport is SRTP (SAVP/RTP) normally over UDP. The secured media transport is SRTP (SAVP/RTP) normally over UDP.
The key management for SRTP is MIKEY using RSA-R mode. The RSA-R The key management for SRTP is MIKEY using RSA-R mode. The RSA-R
mode is selected as it allows the RTSP Server to select the key, mode is selected as it allows the RTSP server to select the key
despite having the RTSP Client initiate the MIKEY exchange. It also despite having the RTSP client initiate the MIKEY exchange. It also
enables the reuse of the RTSP servers TLS certificate when creating enables the reuse of the RTSP server's TLS certificate when creating
the MIKEY messages thus ensuring a binding between the RTSP server the MIKEY messages, thus ensuring a binding between the RTSP server
and the key-exchange. Assuming the SETUP process works, this will and the key exchange. Assuming the SETUP process works, this will
establish a SRTP crypto context to be used between the RTSP Server establish a SRTP crypto context to be used between the RTSP server
and the Client for the RTP transported media streams. and the client for the RTP-transported media streams.
6. IANA Considerations 6. Security Considerations
This document makes no request of IANA. This entire document is about security. Please read it.
Note to RFC Editor: this section can be removed on publication as an 7. Acknowledgements
RFC.
7. Security Considerations We thank the IESG for their careful review of [RFC7202], which led to
the writing of this memo. John Mattsson has contributed the IMS
Media Security example (Section 5.3).
This entire document is about security. Please read it. The authors wish to thank Christian Correll, Dan Wing, Kevin Gross,
Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen
Farrell, John Mattsson, and Suresh Krishnan for their reviews and
proposals for improvements to the text.
8. Acknowledgements 8. Informative References
We thank the IESG for their careful review of [AES-GCM] McGrew, D. and K. Igoe, "AES-GCM and AES-CCM
[I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this Authenticated Encryption in Secure RTP (SRTP)", Work in
memo. Progress, September 2013.
The authors wished to thank Christian Correll for review and great [ARIA-SRTP] Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
proposals for improvements of the text. ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", Work in Progress, November
2013.
9. Informative References [EKT] McGrew, D. and D. Wing, "Encrypted Key Transport for
Secure RTP", Work in Progress, February 2014.
[I-D.ietf-avt-srtp-not-mandatory] [ISMACryp2] Internet Streaming Media Alliance (ISMA), "ISMA
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Encryption and Authentication Version 2.0", November
Framework: Why RTP Does Not Mandate a Single Media 2007, <http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/
Security Solution", draft-ietf-avt-srtp-not-mandatory-12 isma_easpec2.0.pdf>.
(work in progress), February 2013.
[I-D.ietf-avtcore-6222bis] [OMABCAST] Open Mobile Alliance, "Mobile Broadcast Services Version
Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1.0", February 2009,
"Guidelines for Choosing RTP Control Protocol (RTCP) <http://technical.openmobilealliance.org/Technical/
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-03 release_program/bcast_v1_0.aspx>.
(work in progress), April 2013.
[I-D.ietf-avtcore-aria-srtp] [OMADRMv2] Open Mobile Alliance, "OMA Digital Rights Management
Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The V2.0", July 2008,
ARIA Algorithm and Its Use with the Secure Real-time <http://technical.openmobilealliance.org/
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-01 Technical/release_program/drm_v2_0.aspx>.
(work in progress), December 2012.
[I-D.ietf-avtcore-srtp-aes-gcm] [OMASCP] Open Mobile Alliance, "Service and Content Protection for
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated Mobile Broadcast Services", January 2013,
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- <http://technical.openmobilealliance.org/Technical/
aes-gcm-05 (work in progress), February 2013. release_program/docs/BCAST/V1_0_1-20130109-A/
OMA-TS-BCAST_SvcCntProtection-V1_0_1-20130109-A.pdf>.
[I-D.ietf-avtcore-srtp-ekt] [RFC1112] Deering, S., "Host extensions for IP multicasting", STD
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 5, RFC 1112, August 1989.
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012.
[I-D.ietf-mmusic-rfc2326bis] [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Streaming Protocol (RTSP)", RFC 2326, April 1998.
and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), April 2013.
[I-D.ietf-rtcweb-overview] [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Alvestrand, H., "Overview: Real Time Protocols for Brower- Engineering Task Force Standard Protocols", BCP 61, RFC
based Applications", draft-ietf-rtcweb-overview-06 (work 3365, August 2002.
in progress), February 2013.
[I-D.ietf-rtcweb-security-arch] [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Rescorla, E., "RTCWEB Security Architecture", draft-ietf- Jacobson, "RTP: A Transport Protocol for Real-Time
rtcweb-security-arch-06 (work in progress), January 2013. Applications", STD 64, RFC 3550, July 2003.
[ISMACrypt2] [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer,
, "ISMA Encryption and Authentication, Version 2.0 release D., and P. Gentric, "RTP Payload Format for Transport of
version", November 2007. MPEG-4 Elementary Streams", RFC 3640, November 2003.
[OMABCAST] [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Open Mobile Alliance, "OMA Mobile Broadcast Services Norrman, "The Secure Real-time Transport Protocol
V1.0", February 2009. (SRTP)", RFC 3711, March 2004.
[OMADRMv2] [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Open Mobile Alliance, "OMA Digital Rights Management Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
V2.0", July 2008. August 2004.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
RFC 1112, August 1989. Cryptographic Key Management", BCP 107, RFC 4107, June
2005.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Streaming Protocol (RTSP)", RFC 2326, April 1998. Internet Protocol", RFC 4301, December 2005.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Engineering Task Force Standard Protocols", BCP 61, RFC Stream Loss-Tolerant Authentication (TESLA) in the Secure
3365, August 2002. Real-time Transport Protocol (SRTP)", RFC 4383, February
2006.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Jacobson, "RTP: A Transport Protocol for Real-Time Authenticated Identity Management in the Session
Applications", STD 64, RFC 3550, July 2003. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
and P. Gentric, "RTP Payload Format for Transport of Description Protocol", RFC 4566, July 2006.
MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Carrara, "Key Management Extensions for Session
RFC 3711, March 2004. Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Description Protocol (SDP) Security Descriptions for
August 2004. Media Streams", RFC 4568, July 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
Internet Protocol", RFC 4301, December 2005. and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Stream Loss-Tolerant Authentication (TESLA) in the Secure Transport Layer Security (TLS) Protocol in the Session
Real-time Transport Protocol (SRTP)", RFC 4383, February Description Protocol (SDP)", RFC 4572, July 2006.
2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
Description Protocol", RFC 4566, July 2006. IP", RFC 4607, August 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Carrara, "Key Management Extensions for Session Multimedia Internet KEYing (MIKEY)", RFC 4650, September
Description Protocol (SDP) and Real Time Streaming 2006.
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
Description Protocol (SDP) Security Descriptions for Media RSA-R: An Additional Mode of Key Distribution in
Streams", RFC 4568, July 2006. Multimedia Internet KEYing (MIKEY)", RFC 4738, November
2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
and RTP Control Protocol (RTCP) Packets over Connection- Transform Carrying Roll-Over Counter for the Secure Real-
Oriented Transport", RFC 4571, July 2006. time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
Transport Layer Security (TLS) Protocol in the Session 4949, August 2007.
Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
IP", RFC 4607, August 2006. January 2008.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Multimedia Internet KEYing (MIKEY)", RFC 4650, September Various Multimedia Internet KEYing (MIKEY) Modes and
2006. Extensions", RFC 5197, June 2008.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
RSA-R: An Additional Mode of Key Distribution in (ICE): A Protocol for Network Address Translator (NAT)
Multimedia Internet KEYing (MIKEY)", RFC 4738, November Traversal for Offer/Answer Protocols", RFC 5245, April
2006. 2010.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Transform Carrying Roll-Over Counter for the Secure Real- (TLS) Protocol Version 1.2", RFC 5246, August 2008.
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
Protocol (SIP)", RFC 4916, June 2007. "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
4949, August 2007. SEED Cipher Algorithm and Its Use with the Secure Real-
Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
January 2008. Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
Various Multimedia Internet KEYing (MIKEY) Modes and for Establishing a Secure Real-time Transport Protocol
Extensions", RFC 5197, June 2008. (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
"Requirements and Analysis of Media Security Management Security (DTLS) Extension to Establish Keys for the
Protocols", RFC 5479, April 2009. Secure Real-time Transport Protocol (SRTP)", RFC 5764,
May 2010.
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
SEED Cipher Algorithm and Its Use with the Secure Real- Using Relays around NAT (TURN): Relay Extensions to
Time Transport Protocol (SRTP)", RFC 5669, August 2010. Session Traversal Utilities for NAT (STUN)", RFC 5766,
April 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Protocol (RTCP) Extensions for Single-Source Multicast Modes of Key Distribution in Multimedia Internet KEYing
Sessions with Unicast Feedback", RFC 5760, February 2010. (MIKEY)", RFC 6043, March 2011.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
for Establishing a Secure Real-time Transport Protocol RTP", RFC 6188, March 2011.
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Security (DTLS) Extension to Establish Keys for the Secure Path Key Agreement for Unicast Secure RTP", RFC 6189,
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. April 2011.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based
Modes of Key Distribution in Multimedia Internet KEYing Authenticated Key Exchange (IBAKE) Mode of Key
(MIKEY)", RFC 6043, March 2011. Distribution in Multimedia Internet KEYing (MIKEY)", RFC
6267, June 2011.
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
RTP", RFC 6188, March 2011. Security Version 1.2", RFC 6347, January 2012.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption
Path Key Agreement for Unicast Secure RTP", RFC 6189, in Multimedia Internet KEYing (MIKEY)", RFC 6509,
April 2011. February 2012.
[RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Authenticated Key Exchange (IBAKE) Mode of Key Variable Bit Rate Audio with Secure RTP", RFC 6562, March
Distribution in Multimedia Internet KEYing (MIKEY)", RFC 2012.
6267, June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6904] Lennox, J., "Encryption of Header Extensions in the
Security Version 1.2", RFC 6347, January 2012. Secure Real-time Transport Protocol (SRTP)", RFC 6904,
April 2013.
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
Multimedia Internet KEYing (MIKEY)", RFC 6509, February "Guidelines for Choosing RTP Control Protocol (RTCP)
2012. Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Variable Bit Rate Audio with Secure RTP", RFC 6562, March Framework: Why RTP Does Not Mandate a Single Media
2012. Security Solution", RFC 7202, April 2014.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
Real-time Transport Protocol (SRTP)", RFC 6904, April and M. Stiemerling, "Real Time Streaming Protocol 2.0
2013. (RTSP)", Work in Progress, February 2014.
[T3GPP.26.234R11] [T3GPP.26.234R11]
3GPP, "Technical Specification Group Services and System 3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234 Service (PSS); Protocols and codecs", 3GPP TS 26.234
11.1.0, September 2012. 11.1.0, September 2012,
<http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.234R8] [T3GPP.26.234R8]
3GPP, "Technical Specification Group Services and System 3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234 Service (PSS); Protocols and codecs", 3GPP TS 26.234
8.4.0, September 2009. 8.4.0, September 2009,
<http://www.3gpp.org/DynaReport/26234.htm>.
[T3GPP.26.346] [T3GPP.26.346]
3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013. Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013,
<http://www.3gpp.org/DynaReport/26346.htm>.
[T3GPP.33.246] [T3GPP.33.246]
3GPP, "3G Security; Security of Multimedia Broadcast/ 3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 10.1.0, December Multicast Service (MBMS)", 3GPP TS 33.246 11.1.0,
2012. December 2012,
<http://www.3gpp.org/DynaReport/33246.htm>.
[T3GPP.33.328]
3GPP, "IP Multimedia Subsystem (IMS) media plane
security", 3GPP TS 33.328 12.1.0, December 2012,
<http://www.3gpp.org/DynaReport/33328.htm>.
[WebRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", Work in
Progress, February 2014.
[WebRTC] Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", Work in Progress, February
2014.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com EMail: magnus.westerlund@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org EMail: csp@csperkins.org
URI: http://csperkins.org/
 End of changes. 237 change blocks. 
1033 lines changed or deleted 1215 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/