< draft-ietf-avtcore-rtp-security-options-07.txt   draft-ietf-avtcore-rtp-security-options-08.txt >
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. Perkins Intended status: Informational C. S. Perkins
Expires: April 10, 2014 University of Glasgow Expires: April 24, 2014 University of Glasgow
October 07, 2013 October 21, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-07 draft-ietf-avtcore-rtp-security-options-08
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 authentication
of RTP/RTCP packets suitable for the various environments. The range of RTP/RTCP packets suitable for the various environments. The range
of solutions makes it difficult for RTP-based application developers of solutions makes it difficult for RTP-based application developers
to pick the most suitable mechanism. This document provides an to pick the most suitable mechanism. This document provides an
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 4 2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 4
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 8 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 10 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12
3.1.3. Key Management for SRTP: Security Descriptions . . . 13 3.1.3. Key Management for SRTP: Security Descriptions . . . 14
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15
3.1.5. Key Management for SRTP: Other systems . . . . . . . 14 3.1.5. Key Management for SRTP: Other systems . . . . . . . 15
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 15 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16
3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 16
3.6. Media Content Security/Digital Rights Management . . . . 16 3.6. Media Content Security/Digital Rights Management . . . . 17
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18
4.1. Application Requirements . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 18
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 18
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Application Structure . . . . . . . . . . . . . . . . . . 22 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 23
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Media Security for SIP-established Sessions using DTLS- 5.1. Media Security for SIP-established Sessions using DTLS-
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 25
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 26
5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Informative References . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) [RFC3550] is widely used in a 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 centralised 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 signalling
skipping to change at page 4, line 16 skipping to change at page 4, line 17
2. Background 2. Background
RTP can be used in a wide variety of topologies due to its support RTP can be used in a wide variety of topologies due to its support
for point-to-point sessions, multicast groups, and other topologies for point-to-point sessions, multicast groups, and other topologies
built around different types of RTP middleboxes. In the following we built around different types of RTP middleboxes. In the following we
review the different topologies supported by RTP to understand their review the different topologies supported by RTP to understand their
implications for the security properties and trust relations that can implications for the security properties and trust relations that can
exist in RTP sessions. 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 end-points, shown
in Figure 1, where A has established an RTP session with B. In this in 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 can't compromise the confidentiality and integrity of the media
communication. This requires confidentiality protection of the RTP communication. This requires confidentiality protection of the RTP
session, integrity protection of the RTP/RTCP packets, and source session, integrity protection of the RTP/RTCP packets, and source
authentication of all the packets to ensure no man-in-the-middle authentication of all the packets to ensure no man-in-the-middle
attack is taking place. attack is taking place.
The source authentication can also be tied to a user or an end- The source authentication can also be tied to a user or an end-
point's verifiable identity to ensure that the peer knows who they point's verifiable identity to ensure that the peer knows who they
are communicating with. Here the combination of the security are communicating with. Here the combination of the security
protocol protecting the RTP session and its RTP and RTCP traffic and protocol protecting the RTP session and its RTP and RTCP traffic and
the key-management protocol becomes important in which security the key-management protocol becomes important in which security
statements one can do. statements one can do.
+---+ +---+ +---+ +---+
| 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 a An RTP mixer is an RTP session-level middlebox that one can build a
multi-party RTP based conference around. The RTP mixer might multi-party RTP based conference around. 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 the
video of the current active speaker. From a security point of view, video of the current active speaker. From a security point of view,
the important features of an RTP mixer is that it generates a new the important features of an RTP mixer is that it generates a new
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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 end-points 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 in-
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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, with each receive port on the
translator can have a very basic list of where to forward traffic. translator can have a very basic list of where to forward traffic.
Transport translators also need to implement ingress filtering to Transport translators also need to implement ingress filtering to
prevent random traffic from being forwarded that isn't coming from a prevent 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
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. 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 so can complicate keying and source authentication mechanisms. This
is further discussed in Section 2.4. 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 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 the many-to-many nature of the group. Source authentication is to 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 group security context
have access to the necessary secrets to decrypt and verify integrity will have the necessary secrets to decrypt and verify integrity of
of the traffic. Thus use of any symmetric security functions fails the traffic. Thus use of any group security context fails if the
if the goal is to separate individual sources within the security goal is to separate individual sources; alternate solutions are
context; alternate solutions are needed. needed.
+-----+ +-----+
+---+ / \ +---+ +---+ / \ +---+
| A |----/ \---| B | | A |----/ \---| B |
+---+ / Multi- \ +---+ +---+ / Multi- \ +---+
+ Cast + + Cast +
+---+ \ 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 some
considerations for the scalability of the solution and how the key- considerations for the scalability of the solution and how the key-
management is handled. 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 [RFC4607] allows only a specific end-point
to send traffic to the multicast group. That end-point is labelled to send traffic to the multicast group, irrespective of the number of
the Distribution Source in Figure 6. It distributes traffic from a RTP media sources. The end-point is known as the media Distribution
number of RTP media sources, MS1 to MSm. Figure 6 also depicts the Source. Figure 6 shows a sample SSM-based RTP session where several
feedback part of the SSM RTP session using unicast feedback [RFC5760] media sources, MS1...MSm, all send media to a Distribution Source,
from a number of receivers R1..Rn that sends feedback to a Feedback which then forwards the media data to the SSM group for delivery to
Target (FT) and eventually aggregated and distributed to the group. the receivers, R1...Rn, and the Feedback Targets, FT1...FTn. RTCP
reception quality feedback is sent unicast from each receiver to one
The use of SSM makes it more difficult to inject traffic into the of the Feedback Targets. The feedback targets aggregate reception
multicast group, but not impossible. Source authentication quality feedback and forward it upstream towards the distribution
requirements apply for SSM sessions too, and a non-symmetric source. The distribution source forwards (possibly aggregated and
verification of who sent the RTP and RTCP packets is needed. summarised) reception feedback to the SSM group, and back to the
original media sources. The feedback targets are also members of the
The SSM communication channel needs to be securely established and SSM group and receive the media data, so they can send unicast repair
keyed. In addition one also has the individual unicast RTCP feedback data to the receivers in response to feedback if appropriate.
that needs to be secured.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm | | MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
^ ^ ^ ^ ^ ^
| | | | | |
V V V V V V
+---------------------------------+ +---------------------------------+
| Distribution Source | | Distribution Source |
+--------+ | +--------+ |
skipping to change at page 8, line 44 skipping to change at page 8, line 40
: : / \ : : : : / \ : :
: : / \ : : : : / \ : :
: : / \ : : : : / \ : :
: ./\ /\. : : ./\ /\. :
: /. \ / .\ : : /. \ / .\ :
: V . V V . V : : V . V V . V :
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn | | R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 6: SSM-based RTP session with Unicast Feedback Figure 6: Example SSM-based RTP session with two feedback targets
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, and 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 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 security requirements, and the This section provides an overview of security requirements, and the
current RTP security mechanisms that implement those requirements. current RTP security mechanisms that implement those requirements.
This cannot be a complete survey, since new security mechanisms are This cannot be a complete survey, since new security mechanisms are
defined regularly. The goal is to help applications designer by defined regularly. The goal is to help applications designer by
giving reviewing the types of solution that are available. This reviewing the types of solution that are available. This section
section will use a number of different security related terms, will use a number of different security related terms, described in
described in the Internet Security Glossary, Version 2 [RFC4949]. the Internet Security Glossary, Version 2 [RFC4949].
3.1. Secure RTP 3.1. Secure RTP
The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly
used mechanisms to provide confidentiality, integrity protection, used mechanisms to provide confidentiality, integrity protection,
source authentication and replay protection for RTP. SRTP was source authentication and replay protection for RTP. SRTP was
developed with RTP header compression and third party monitors in developed with RTP header compression and third party monitors in
mind. Thus the RTP header is not encrypted in RTP data packets, and mind. Thus the RTP header is not encrypted in RTP data packets, and
the first 8 bytes of the first RTCP packet header in each compound the first 8 bytes of the first RTCP packet header in each compound
RTCP packet are not encrypted. The entirety of RTP packets and RTCP packet are not encrypted. The entirety of RTP packets and
compound RTCP packets are integrity protected. This allows RTP compound RTCP packets are integrity protected. This allows RTP
header compression to work, and lets third party monitors determine header compression to work, and lets third party monitors determine
what RTP traffic flows exist based on the SSRC fields, but protects what RTP traffic flows exist based on the SSRC fields, but protects
the sensitive content. the sensitive content.
The source authentication guarantees provided by SRTP depend on the SRTP works with transforms where different combinations of encryption
cryptographic transform and key-management used. Some transforms, algorithm, authentication algorithm, and pseudo-random function can
e.g., those using TESLA [RFC4383], give strong source authentication be used, and the authentication tag length can be set to any value.
even in multiparty sessions; others give weaker guarantees and can SRTP can also be easily extended with additional cryptographic
authenticate group membership by not sources. transforms. This gives flexibility, but requires more security
knowledge by the application developer. To simplify things, SDP
SRTP can easily be extended with additional cryptographic transforms. Security Descriptions (see Section 3.1.3) and DTLS-SRTP (see
At the time of this writing, the following transforms are defined or Section 3.1.1) use pre-defined combinations of transforms, known as
under definition: SRTP crypto suites and SRTP protection profiles, that bundle together
transforms and other parameters, making them easier to use but
AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits reducing flexibility. The MIKEY protocol (see Section 3.1.2)
keys combined with 128 bits keyed HMAC-SHA-1 using 80- or 32-bits provides flexibility to negotiate the full selection of transforms.
authentication tags. This is the default cryptographic transform At the time of this writing, the following transforms, SRTP crypto
that needs to be supported. Defined in SRTP [RFC3711]. suites, and SRTP protection profiles are defined or under definition:
AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128-bits keys AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys
combined with keyed HMAC-SHA-1 using 80- or 32-bit authentication. combined with 160-bit keyed HMAC-SHA-1 with 80-bit authentication
Defined in SRTP [RFC3711]. 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 in [RFC4568] and SRTP protection
profile in [RFC5764].
TESLA: As a complement to the regular symmetric keyed authentication AES-f8 and HMAC-SHA-1: AES f8 mode encryption using 128-bit keys
transforms, like HMAC-SHA-1. The TESLA based authentication combined with keyed HMAC-SHA-1 using 80-bit authentication. The
scheme can provide per-source authentication in some group transforms are defined in [RFC3711], with the corresponding SRTP
communication scenarios. The downside is need for buffering the crypto suite in [RFC4568]. The corresponding SRTP protection
packets for a while before authenticity can be verified. The profile is not defined.
TESLA transform for SRTP is defined in [RFC4383].
SEED: A Korean national standard cryptographic transform that is SEED: A Korean national standard cryptographic transform that is
defined to be used with SRTP in [RFC5669]. It has three modes, defined to be used with SRTP in [RFC5669]. Three options are
one using SHA-1 authentication, one using Counter with CBC-MAC, defined, one using SHA-1 authentication, one using Counter mode
and finally one using Galois Counter mode. with CBC-MAC, and finally one using Galois Counter mode.
ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that
supports 128-, 192- and 256- bit keys. It also has three modes, supports 128-, 192- and 256- bit keys. It also defines three
Counter mode where combined with HMAC-SHA-1 with 80 or 32 bits options, Counter mode where combined with HMAC-SHA-1 with 80 or 32
authentication tags, Counter mode with CBC-MAC and Galois Counter bits authentication tags, Counter mode with CBC-MAC and Galois
mode. It also defines a different key derivation function than Counter mode. It also defines a different key derivation function
the AES based systems. than the AES based systems.
AES-192 and AES-256: cryptographic transforms for SRTP based on AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based
AES-192 and AES-256 counter mode encryption and 160-bit keyed on AES-192 and AES-256 counter mode encryption and 160-bit keyed
HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide
providing 192 and 256 bits encryption keys. Defined in [RFC6188]. 192- and 256-bit encryption keys, but otherwise match the default
128-bit AES-CM transform. The transforms are defined in [RFC3711]
and [RFC6188], with the SRTP crypto suites in [RFC6188].
AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC) AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter with
authentication for AES-128 and AES-256. This authentication is CBC MAC for AES-128 and AES-256. This authentication is included
included in the cipher text which becomes expanded with the length in the cipher text which becomes expanded with the length of the
of the authentication tag instead of using the SRTP authentication authentication tag instead of using the SRTP authentication tag.
tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm].
NULL: SRTP [RFC3711] also provides a NULL cipher that can be used
when no confidentiality for RTP/RTCP is requested. The
corresponding SRTP protection profile is defined in [RFC5764].
The source authentication guarantees provided by SRTP depend on the
cryptographic transform and key-management used. Some transforms
give strong source authentication even in multiparty sessions; others
give weaker guarantees and can authenticate group membership but not
sources. TESLA [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 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 secure RTP group, for example a broadcast session.
RTP header extensions are normally carried in the clear and only RTP header extensions are normally carried in the clear and 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 in SIP-established VoIP clients including IMS;
RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming.
Thus SRTP in general is widely deployed. When it comes to Thus SRTP in general is widely deployed. When it comes to
cryptographic transforms the default (AES CM and HMAC-SHA-1) is the cryptographic transforms the default (AES-CM and HMAC-SHA-1) is the
most common used. 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, and
instead relies on an external key management protocol. There are instead relies on an external key management protocol. There are
several protocols that can be used. The following sections outline several protocols that can be used. The following sections outline
some popular schemes. some 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 extension exists for establishing
SRTP keys [RFC5763][RFC5764]. This extension provides secure key- SRTP keys [RFC5763][RFC5764]. This extension provides secure key-
skipping to change at page 11, line 12 skipping to change at page 11, line 45
binding strong identity verification to an end-point. The default binding strong identity verification to an end-point. The default
key generation will generate a key that contains material contributed key generation will generate a key that contains material contributed
by both peers. The key-exchange happens in the media plane directly by both peers. The key-exchange happens in the media plane directly
between the peers. The common key-exchange procedures will take two between the peers. The common key-exchange procedures will take two
round trips assuming no losses. TLS resumption can be used when round trips assuming no losses. TLS resumption can be used when
establishing additional media streams with the same peer, and reduces establishing additional media streams with the same peer, and reduces
the set-up time to one RTT for these streams (see [RFC5764] for a the set-up time to one RTT for these streams (see [RFC5764] for a
discussion of TLS resumption in this context). 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 suites offered and used. For example DTLS will depend on the cipher suites offered and used, as well as
some provide perfect forward secrecy (PFS), while other do not. When the mechanism for identifying the end-points of the hand-shake. For
using DTLS, the application designer needs to select which cipher example some cipher suits provide perfect forward secrecy (PFS),
suites DTLS-SRTP can offer and accept so that the desired security while other do not. When using DTLS, the application designer needs
properties are achieved. to select which cipher 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 end-point. 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 certificate are common to use, and instead
establish trust through signalling or other third party solutions.
DTLS-SRTP key management can use the signalling protocol in four DTLS-SRTP key management can use the signalling protocol in four
ways. First, to agree on using DTLS-SRTP for media security. ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where Secondly, to determine the network location (address and port) where
each side is running a DTLS listener to let the parts perform the each side is running a DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Thirdly, to exchange hashes of each side's certificates to bind these Thirdly, to exchange hashes of each side's certificates to bind these
to the signalling, and ensure there is no man-in-the-middle attack. to the signalling, and ensure there is no man-in-the-middle attack.
Finally to provide an assertable identity, e.g. [RFC4474] that can be This assumes that one can trust the signalling solution to be
used to prevent modification of the signalling and the exchange of resistant to modification, and not be in collaboration with an
certificate hashes. That way enabling binding between the key- attacker. Finally to provide an assertable identity, e.g. [RFC4474]
exchange and the signalling. that can be used to prevent modification of the signalling and the
exchange of certificate hashes. That way enabling binding between
the key-exchange and the signalling.
This usage is well defined for SIP/SDP in [RFC5763], and in most This usage is well defined for SIP/SDP in [RFC5763], and in most
cases can be adopted for use with other bi-directional signalling cases can be adopted for use with other bi-directional signalling
solutions. It is to be noted that there is work underway to revisit solutions. It is to be noted that there is work underway to revisit
the SIP Identity mechanism [RFC4474] in the IETF STIR working group. the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
The main question regarding DTLS-SRTP's security properties is how
one verifies any peer identity or at least prevents man-in-the-middle
attacks. This do requires trust in some DTLS-SRTP external party,
either a PKI, a signalling system or some identity provider.
DTLS-SRTP usage is clearly on the rise. It is mandatory to support DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
was developed in IETF primarily to meet security requirements for was developed in IETF primarily to meet security requirements for
SIP. SIP.
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 useable in scenarios where one sessions with a single message. It is useable in scenarios where one
entity generates the key and needs to distribute the key to a number entity generates the key and needs to distribute the key to a number
of participants. The different modes and the resulting properties of participants. The different modes and the resulting properties
are highly dependent on the cryptographic method used to establish are highly dependent on the cryptographic method used to establish
the Traffic Generation Key (TGK) that is used to derive the keys the session keys actually used by the security protocol, like SRTP.
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
intensive 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 high session key, thus providing perfect forward secrecy. The downside
resource consumption in bandwidth and processing during the MIKEY is high resource consumption in bandwidth and processing during
exchange. This method can't be used to establish group keys as the MIKEY exchange. This method can't be used to establish group
each pair of peers performing the MIKEY exchange will establish keys as each pair of peers performing the MIKEY exchange will
different keys. 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 HMAC to verify authenticity of the keying material instead of a
digital signature as in the previous method. This method is still digital signature as in the previous method. This method is still
restricted to point-to-point usage. 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 responder's certificate. This method 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 to specify the session keying
depending on use case. Usage of this mode requires one round-trip material depending on use case. Usage of this mode requires one
time. round-trip time.
TICKET: [RFC6043] is a MIKEY extension using trusted centralized key TICKET: [RFC6043] is a MIKEY extension using a trusted centralized
management service and tickets, like Kerberos. 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: [RFC6267] uses a key management services (KMS) infrastructure
but with lower demand on the KMS. Claims to provides both perfect but with lower demand on the KMS. Claims to provides both perfect
forward and backwards secrecy, the exact meaning is unclear (See forward and backwards secrecy, the exact meaning is unclear (See
Perfect Forward Secrecy in [RFC4949]). Perfect Forward Secrecy in [RFC4949]).
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY.
Based on Identity based Public Key Cryptography and a KMS Based on Identity based Public Key Cryptography and a KMS
infrastructure to establish a shared secret value and certificate infrastructure to establish a shared secret value and certificate
less signatures to provide source authentication. It's features less signatures to provide source authentication. Its features
include simplex transmission, scalability, low-latency call set- include simplex transmission, scalability, low-latency call set-
up, and support for secure deferred delivery. up, and support for secure deferred delivery.
MIKEY messages have several different transports. [RFC4567] defines MIKEY messages have several different transports. [RFC4567] defines
how MIKEY messages can be embedded in general SDP for usage with the how MIKEY messages can be embedded in general SDP for usage with the
signalling protocols SIP, SAP and RTSP. There also exist a 3GPP signalling protocols SIP, SAP and RTSP. There also exist a 3GPP
defined usage of MIKEY that sends MIKEY messages directly over UDP defined usage of MIKEY that sends MIKEY messages directly over UDP
[T3GPP.33.246] to key the receivers of Multimedia Broadcast and [T3GPP.33.246] to key the receivers of Multimedia Broadcast and
Multicast Service (MBMS) [T3GPP.26.346]. 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 ones solution and based on that evaluate which modes that
are candidates for ones usage. More information on the applicability are candidates for ones usage. More information on the applicability
of the different MIKEY modes can be found in [RFC5197]. of the 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 are 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 support MIKEY. The mode transported over SIP and HTTP. RTSP 2.0
modes they use are unknown to the authors. [I-D.ietf-mmusic-rfc2326bis] specifies use of the RSA-R mode. There
are some SIP end-points 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 plain text keys
in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/
Answer model, and is well-defined in point-to-point sessions where Answer model, and is well-defined in point-to-point sessions where
each side declares its own unique key. Using Security Descriptions each side declares its own unique key. Using Security Descriptions
to establish group keys is less well defined, and can have security to establish group keys is less well defined, and can have security
issues since it's difficult to guarantee unique SSRCs (as needed to issues since it's difficult to guarantee unique SSRCs (as needed to
avoid a "two-time pad" attack - see Section 9 of [RFC3711]). 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 plain text 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-to-
end confidentiality and authentication guarantees. This is not end confidentiality and authentication guarantees. This is not
normally the case, where instead hop-by-hop security is provided normally the case, where instead hop-by-hop security is provided
between signalling nodes using TLS. This leaves the keying material between signalling nodes using TLS. This leaves the keying material
sensitive to capture by the traversed signalling nodes. Thus, in sensitive to capture by the traversed signalling nodes. Thus, in
most cases, the security properties of security descriptions are most cases, the security properties of security descriptions are
weak. The usage of security descriptions usually requires additional weak. The usage of security descriptions usually requires additional
security measures, e.g. the signalling nodes be trusted and protected security measures, e.g. the signalling nodes be trusted and
by strict access control. Usage of security descriptions requires protected by strict access control. Usage of security descriptions
careful design in order to ensure that the security goals can be met. requires careful design in order to ensure that the security goals
can be met.
Security Descriptions is the most commonly deployed keying solution Security Descriptions is the most commonly deployed keying solution
for SIP-based end-points, where almost all end-points that support for SIP-based end-points, where almost all end-points that support
SRTP also support Security Descriptions. SRTP 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) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
extension that enables group keying despite using a keying mechanism extension that enables group keying despite using a keying mechanism
like DTLS-SRTP that doesn't support group keys. It is designed for like DTLS-SRTP that doesn't support group keys. It is designed for
centralized conferencing, but can also be used in sessions where end- centralized conferencing, but can also be used in sessions where end-
points connect to a conference bridge or a gateway, and need to be points connect to a conference bridge or a gateway, and need to be
provisioned with the keys each participant on the bridge or gateway provisioned with the keys each participant on the bridge or gateway
uses to avoid decryption and encryption cycles on the bridge or uses to avoid decryption and encryption cycles on the bridge or
skipping to change at page 15, line 29 skipping to change at page 16, line 29
question is how one ensures the IPsec terminating peer and the question is how one ensures the IPsec terminating peer and the
ultimate destination are the same. Applications can have issues ultimate destination are the same. Applications can have issues
using existing APIs with determining if IPsec is being used or not, using existing APIs with determining if IPsec is being used or not,
and when used who the authenticated peer entity is. and when used who the authenticated peer entity is.
IPsec with RTP is more commonly used as a security solution between IPsec with RTP is more commonly used as a security solution between
infrastructure nodes that exchange many RTP sessions and media infrastructure nodes that exchange many RTP sessions and media
streams. The establishment of a secure tunnel between such nodes streams. The establishment of a secure tunnel between such nodes
minimizes the key-management overhead. minimizes the key-management overhead.
3.4. DTLS for RTP and RTCP 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 establish an DTLS TLS over TCP [RFC4572], using TLS to provide point-to-point security
services. The security properties TLS provides are confidentiality,
integrity protection and possible source authentication if the client
or server certificates are verified and provide a usable identity.
When used in multi-party scenarios using a central node for media
distribution, the security provide 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.
RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the
usage of RTP over the same TLS/TCP connection that the RTSP messages
are sent over. It appears that RTP over TLS/TCP is also used in some
proprietary solutions that uses TLS to bypass firewalls.
3.5. RTP over Datagram TLS (DTLS)
Datagram Transport Layer Security (DTLS) [RFC6347] is a based on TLS
[RFC5246], but designed to work over a 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 an
datagram transport such as UDP. The two peers establish an DTLS
association between each other, including the possibility to do association between each other, including the possibility to do
certificate-based source authentication when establishing the certificate-based source authentication when establishing the
association. All RTP and RTCP packets flowing will be protected by association. All RTP and RTCP packets flowing will be protected by
this DTLS association. this DTLS association.
Note that using DTLS for RTP flows is different to using DTLS-SRTP Note that using DTLS for RTP flows is different to using DTLS-SRTP
key management. DTLS-SRTP uses the same key-management steps as key management. DTLS-SRTP uses the same key-management steps as
DTLS, but uses SRTP for the per packet security operations. Using DTLS, but uses SRTP for the per packet security operations. Using
DTLS for RTP flows uses the normal datagram TLS data protection, DTLS for RTP flows uses the normal datagram TLS data protection,
wrapping complete RTP packets. When using DTLS for RTP flows, the wrapping complete RTP packets. When using DTLS for RTP flows, the
skipping to change at page 16, line 7 skipping to change at page 17, line 27
only the payload data is encrypted. only the payload data is encrypted.
DTLS can use similar techniques to those available for DTLS-SRTP to DTLS can use similar techniques to those available for DTLS-SRTP to
bind a signalling-side agreement to communicate to the certificates bind a signalling-side agreement to communicate to the certificates
used by the end-point when doing the DTLS handshake. This enables used by the end-point when doing the DTLS handshake. This enables
use without having a certificate-based trust chain to a trusted use without having a certificate-based trust chain to a trusted
certificate root. certificate root.
There does not appear to be significant usage of DTLS for RTP. There does not appear to be significant usage of DTLS for RTP.
3.5. TLS over TCP
When RTP is sent over TCP [RFC4571] it can also be sent over TLS over
TCP [RFC4572], using TLS to provide point to point security services.
The security properties TLS provides are confidentiality, integrity
protection and possible source authentication if the client or server
certificates are verified and provide a usable identity. When used
in multi-party scenarios using a central node for media distribution,
the security provide 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.
RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the
usage of RTP over the same TLS/TCP connection that the RTSP messages
are sent over. It appears that RTP over TLS/TCP is also used in some
proprietary solutions that uses TLS to bypass firewalls.
3.6. Media Content Security/Digital Rights Management 3.6. Media Content Security/Digital Rights Management
Mechanisms have been defined that encrypt only the media content, Mechanisms have been defined that encrypt only the media content,
operating within the RTP payload data and leaving the RTP headers and operating within the RTP payload data and leaving the RTP headers and
RTCP unaffected. There are several reasons why this might be RTCP unaffected. There are several reasons why this might be
appropriate, but a common rationale is to ensure that the content appropriate, but a common rationale is to ensure that the content
stored by RTSP streaming servers has the media content in a protected stored by RTSP streaming servers has the media content in a protected
format that cannot be read by the streaming server (this is mostly format that cannot be read by the streaming server (this is mostly
done in the context of Digital Rights Management). These approaches done in the context of Digital Rights Management). These approaches
then use a key-management solution between the rights provider and then use a key-management solution between the rights provider and
the consuming client to deliver the key used to protect the content the consuming client to deliver the key used to protect the content
and do not include the media server in the security context. Such and do not give the media server access to the security context.
methods have several security weaknesses such as the fact that the Such methods have several security weaknesses such as the fact that
same key is handed out to a potentially large group of receiving the same key is handed out to a potentially large group of receiving
clients, increasing the risk of a leak. clients, increasing the risk 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 which streams allow middleboxes to rewrite the RTP headers and select which streams
are delivered to an end-point (e.g., some types of centralised video are delivered to an end-point (e.g., some types of centralised 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 can still provide
stream switching functionality. The downside of such a system is stream switching functionality. The downside of such a system is
that it likely needs two levels of security: the payload level that it likely needs two levels of security: the payload level
solution to provide confidentiality and source authentication, and a solution to provide confidentiality and source authentication, and a
second layer with additional transport security ensuring source 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 results 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 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 Based Streaming Service
Annex.K [T3GPP.26.234R8] solution. Annex.K [T3GPP.26.234R8] solution.
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 a 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.
skipping to change at page 24, line 7 skipping to change at page 25, line 4
exchange. exchange.
DTLS has a number of good security properties. For example, to DTLS has a number of good security properties. For example, to
enable a man in the middle someone in the signalling path needs to enable a man in the middle someone in the signalling path needs to
perform an active action and modify both the signalling message and perform an active action and modify both the signalling message and
the DTLS handshake. There also exists solutions that enables the the DTLS handshake. There also exists solutions that enables the
fingerprints to be bound to identities. SIP Identity provides an fingerprints to be bound to identities. SIP Identity provides an
identity established by the first proxy for each user [RFC4474]. identity established by the first proxy for each user [RFC4474].
This reduces the number of nodes the connecting user User Agent has This reduces the number of nodes the connecting user User Agent has
to trust to include just the first hop proxy, rather than the full to trust to include just the first hop proxy, rather than the full
signalling path. signalling path. The biggest security weakness of this system is its
dependency on the signalling. SIP signalling 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 (WebRTC) [I-D.ietf-rtcweb-overview] is a Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a
solution providing JavaScript web applications with real-time media solution providing JavaScript web applications with real-time media
directly between browsers. Media is transported using RTP protected directly between browsers. Media is transported using RTP protected
using a mandatory application of SRTP [RFC3711], with keying done using a mandatory application of SRTP [RFC3711], with keying done
using DTLS-SRTP [RFC5764]. The security configuration is further using DTLS-SRTP [RFC5764]. The security configuration is further
defined in the WebRTC Security Architecture defined in the WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
skipping to change at page 24, line 46 skipping to change at page 25, line 46
as in ZRTP [RFC6189]), or using hash continuity. as in ZRTP [RFC6189]), or using hash continuity.
In the development of WebRTC there has also been attention given to In the development of WebRTC there has also been attention given to
privacy considerations. The main RTP-related concerns that have been privacy considerations. The main RTP-related concerns that have been
raised are: raised are:
Location Disclosure: As ICE negotiation [RFC5245] provides IP Location Disclosure: As ICE negotiation [RFC5245] provides IP
addresses and ports for the browser, this leaks location addresses and ports for the browser, this leaks location
information in the signalling to the peer. To prevent this one information in the signalling to the peer. To prevent this one
can block the usage of any ICE candidate that isn't a relay 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 candidate, i.e. where the IP and port provided belong to the
service providers media traffic relay. service providers media traffic relay.
Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP
certificates provide information that is re-used between session certificates provide information that is re-used between session
instances. Thus to prevent tracking, such information is ought instances. Thus to prevent tracking, such information is ought
not be re-used between sessions, or the information ought not sent not be re-used between sessions, or the information ought not sent
in the clear. in the clear. Note, that generating new certificates each time
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.
Note: The above cases are focused on providing privacy from other Note: The above cases are focused on providing privacy from other
parties, not on providing privacy from the web server that provides parties, not on providing privacy from the web server that provides
the WebRTC Javascript application. the WebRTC Javascript application.
5.3. 3GPP Packet Based Streaming Service (PSS) 5.3. IP Multimedia Subsystem (IMS) Media Security
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 (PSTN,
GSM, and 3G), and transcoding. End-points are authenticated during
the SIP registration using either IMS-AKA (using SIM credentials) or
SIP Digest (using password).
In IMS media security [T3GPP.33.328], end-to-end encryption is
therefore not seen as needed or desired as it would hinder for
example interworking and transcoding, making calls between
incompatible terminals impossible. Because of this IMS media
security mostly uses end-to-access-edge security where SRTP is
terminated in the first node in the core network. As the SIP
signaling is trusted and encrypted (with TLS or IPsec), security
descriptions [RFC4568] is considered to give good protection against
eavesdropping over the accesses that are not already encrypted (GSM,
3G, 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 end-point.
For enterprises and government agencies, which might have weaker
trust in the IMS core network and can be assumed to have compatible
terminals, end-to-end security can be achieved by deploying their own
key management server.
Work on Interworking with WebRTC is currently ongoing; the security
will still be end-to-access-edge, but using DTLS-SRTP [RFC5763]
instead of security descriptions.
5.4. 3GPP Packet Based Streaming Service (PSS)
The 3GPP Release 11 PSS specification of the Packet Based Streaming The 3GPP Release 11 PSS specification of the Packet Based Streaming
Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of
security mechanisms. These security mechanisms are concerned with security mechanisms. These security mechanisms are concerned with
protecting the content from being captured, i.e. Digital Rights protecting the content from being copied, i.e. Digital Rights
Management. To meet these goals with the specified solution, the Management. To meet these goals with the specified solution, the
client implementation and the application platform are trusted to client implementation and the application platform are trusted to
protect against access and modification by an attacker. protect against access and modification by an attacker.
PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus
an RTSP client whose user wants to access a protected content will an RTSP client whose user wants to access a protected content will
request a session description (SDP [RFC4566]) for the protected request a session description (SDP [RFC4566]) for the protected
content. This SDP will indicate that the media is ISMA Crypt 2.0 content. This SDP will indicate that the media is ISMACryp 2.0
[ISMACrypt2] protected media encoding application units (AUs). The [ISMACryp2] protected media encoding application units (AUs). The
key(s) used to protect the media are provided in either of two ways. key(s) used to protect the media are provided in either of two ways.
If a single key is used then the client uses some DRM system to 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 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 an additional RTSP stream for key-updates in parallel be used, then an additional RTSP stream for key-updates in parallel
with the media streams is established, where key updates are sent to with the media streams is established, where key updates are sent to
the client using Short Term Key Messages defined in the "Service and the client using Short Term Key Messages defined in the "Service and
Content Protection for Mobile Broadcast Services" section of the OMA Content Protection for Mobile Broadcast Services" section of the OMA
Mobile Broadcast Services [OMABCAST]. 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 any solution that could defined any requirement for supporting any solution that 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 has 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 is 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 to
decrypt the media. decrypt the media.
To protect the signalling, RTSP 1.0 supports the usage of TLS. This To protect the signalling, RTSP 1.0 supports the usage of TLS. This
is, however, not explicitly discussed in the PSS specification. is, however, not explicitly discussed in the PSS specification.
Usage of 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] offers Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] offers
an interesting comparison to the PSS service (Section 5.3) that is an interesting comparison to the PSS service (Section 5.4) that is
based on RTSP 1.0 and service requirements perceived by mobile based on RTSP 1.0 and service requirements perceived by mobile
operators. A major difference between RTSP 1.0 and RTSP 2.0 is that operators. A major difference between RTSP 1.0 and RTSP 2.0 is that
2.0 is fully defined under the requirement to have mandatory to 2.0 is fully defined under the requirement to have mandatory to
implement security mechanism. As it specifies how one transport implement security mechanism. As it specifies how one transport
media over RTP it is also defining security mechanisms for the RTP media over RTP it is also 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 is The security goals 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 RTSP
server and the client. This to prevent eavesdropping on what the server and the client. This to prevent eavesdropping on what the
skipping to change at page 27, line 9 skipping to change at page 28, line 43
RFC. RFC.
7. Security Considerations 7. Security Considerations
This entire document is about security. Please read it. This entire document is about security. Please read it.
8. Acknowledgements 8. Acknowledgements
We thank the IESG for their careful review of We thank the IESG for their careful review of
[I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this
memo. memo. John Mattsson has contributed the IMS Media Security example
(Section 5.3).
The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, The authors wished to thank Christian Correll, Dan Wing, Kevin Gross,
Alan Johnston, Michael Peck, and Ole Jacobsen for review and Alan Johnston, Michael Peck, Ole Jacobsen, and John Mattsson for
proposals for improvements of the text. review and proposals for improvements of the text.
9. Informative References 9. Informative References
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", draft-ietf-avt-srtp-not-mandatory-13 Security Solution", draft-ietf-avt-srtp-not-mandatory-14
(work in progress), May 2013. (work in progress), October 2013.
[I-D.ietf-avtcore-aria-srtp] [I-D.ietf-avtcore-aria-srtp]
Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
ARIA Algorithm and Its Use with the Secure Real-time ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05
(work in progress), September 2013. (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-10 (work in progress), September 2013. aes-gcm-10 (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-37 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in
progress), September 2013. progress), October 2013.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), September 2013. in progress), September 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-07 (work in progress), July 2013. rtcweb-security-arch-07 (work in progress), July 2013.
[ISMACrypt2] [ISMACryp2]
, "ISMA Encryption and Authentication, Version 2.0 release Internet Streaming Media Alliance (ISMA), "ISMA Encryption
version", November 2007. and Authentication, Version 2.0 release version", November
2007.
[OMABCAST] [OMABCAST]
Open Mobile Alliance, "OMA Mobile Broadcast Services Open Mobile Alliance, "OMA Mobile Broadcast Services
V1.0", February 2009. V1.0", February 2009.
[OMADRMv2] [OMADRMv2]
Open Mobile Alliance, "OMA Digital Rights Management Open Mobile Alliance, "OMA Digital Rights Management
V2.0", July 2008. V2.0", July 2008.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
skipping to change at page 30, line 14 skipping to change at page 31, line 48
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008. Extensions", RFC 5197, June 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009. Protocols", RFC 5479, April 2009.
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
SEED Cipher Algorithm and Its Use with the Secure Real- SEED Cipher Algorithm and Its Use with the Secure Real-
Time Transport Protocol (SRTP)", RFC 5669, August 2010. Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
skipping to change at page 31, line 47 skipping to change at page 33, line 35
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.
[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.
[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 12.1.0, December
2012. 2012.
[T3GPP.33.328]
3GPP, "IP Multimedia Subsystem (IMS) media plane
security", 3GPP TS 33.328 12.1.0, December 2012.
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. 73 change blocks. 
206 lines changed or deleted 315 lines changed or added

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