draft-ietf-avtcore-rtp-security-options-02.txt   draft-ietf-avtcore-rtp-security-options-03.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. Perkins
Expires: August 29, 2013 University of Glasgow Expires: November 07, 2013 University of Glasgow
February 25, 2013 May 06, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-02 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 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
overview of a number of security solutions for RTP, and gives overview of a number of security solutions for RTP, and gives
guidance for developers on how to choose the appropriate security guidance for developers on how to choose the appropriate security
mechanism. mechanism.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 29, 2013. This Internet-Draft will expire on November 07, 2013.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 5 2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 4
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 5 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . . 6 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . . 6 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . . 8 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . . 8 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . . 11 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . . 12 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 . . . 13
3.1.4. Key Management for SRTP: Encrypted Key Transport . . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14
3.1.5. Key Management for SRTP: Other systems . . . . . . . . 14 3.1.5. Key Management for SRTP: Other systems . . . . . . . 14
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . . 14 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Payload-only Security Mechanisms . . . . . . . . . . . . . 16 3.6. Payload-only Security Mechanisms . . . . . . . . . . . . 16
3.6.1. ISMA Encryption and Authentication . . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17
4.1. Application Requirements . . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 17
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Application Structure . . . . . . . . . . . . . . . . . . 21 4.2. Application Structure . . . . . . . . . . . . . . . . . . 22
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 21 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Media Security for SIP-established Sessions using 5.1. Media Security for SIP-established Sessions using DTLS-
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 22 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . . 22 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 23 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25
5.4. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. Informative References . . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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
methods used to establish the RTP sessions. methods used to establish the RTP sessions.
This multi-dimensional heterogeneity has so far prevented development This multi-dimensional heterogeneity has so far 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 significant number of different solutions have
been developed to meet different sets of security goals. This makes been developed to meet different sets of security goals. This makes
it difficult for application developers to know what solutions exist, it difficult for application developers to know what solutions exist,
and whether their properties are appropriate. This memo gives an and whether their properties are appropriate. This memo gives an
overview of the available RTP solutions, and provides guidance on overview of the available RTP solutions, and provides guidance on
their applicability for different application domains. The guidance their applicability for different application domains. It also
attempts to provide indication of actual and intended usage at time
of writing as additional input to help with considerations such as
interoperability, availability of implementations etc. The guidance
provided is not exhaustive, and this memo does not provide normative provided is not exhaustive, and this memo does not provide normative
recommendations. 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, and makes available to the user,
secure modes of operation [RFC3365]. Because of the heterogeneity of secure modes of operation [RFC3365]. Because of the heterogeneity of
RTP applications and use cases, however, a single security solution RTP applications and use cases, however, a single security solution
cannot be mandated. Instead, application developers need to select cannot be mandated. Instead, application developers need to select
mechanisms that provide appropriate security for their environment. mechanisms that provide appropriate security for their environment.
skipping to change at page 5, line 11 skipping to change at page 4, line 25
RTP can be used in a wide variety of topologies, and combinations of RTP can be used in a wide variety of topologies, and combinations of
topologies, due to it's support for unicast, multicast groups, and topologies, due to it's support for unicast, multicast groups, and
broadcast topologies, and the existence of different types of RTP broadcast topologies, and the existence of different types of RTP
middleboxes. In the following we review the different topologies middleboxes. In the following we review the different topologies
supported by RTP to understand their implications for the security supported by RTP to understand their implications for the security
properties and trust relations that can exist in RTP sessions. properties and trust relations 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 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-points The source authentication can also be tied to a user or an end-points
verifiable identity to ensure that the peer knows who they are verifiable identity to ensure that the peer knows who they are
communicating with. Here the combination of the security protocol communicating with. Here the combination of the security protocol
skipping to change at page 6, line 5 skipping to change at page 5, line 15
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
media stream, and has its own source identifier, and does not simply media stream, and 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 examples, participants A-D each send unicast RTP
traffic between themselves and the RTP mixer, and receive a RTP traffic between themselves and the RTP mixer, and receive a RTP
stream from the mixer, comprising a mixture of the streams from the stream from the mixer, comprising a mixture of the streams from the
other participants. other 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 is part of 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
skipping to change at page 7, line 5 skipping to change at page 6, line 13
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 to be in the
security context, as long as the security mechanism does not provide security context, as long as the security mechanism does not provide
protection over the transport-layer information. A transport 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.
skipping to change at page 8, line 10 skipping to change at page 7, line 15
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 so almost certainly needs to be trusted device that is part of and thus needs to be trusted device that is part of the security
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 in the group security context will
have access to the necessary secrets to decrypt and verify integrity have access to the necessary secrets to decrypt and verify integrity
of the traffic. Thus use of any symmetric security functions fails of the traffic. Thus use of any symmetric security functions fails
if the goal is to separate individual sources within the security if the goal is to separate individual sources within the security
context; alternate solutions are needed. context; alternate solutions are 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 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
skipping to change at page 9, line 47 skipping to change at page 9, line 10
: 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: SSM-based RTP session with Unicast Feedback
3. Security Options 3. Security Options
This section provides an overview of a number of currently defined This section provides an overview of a number of currently defined
security mechanisms that can be used with RTP. security mechanisms that can be used with RTP. This section will use
a number of different security related terms, if they are unknown to
the reader, please consult the "Internet Security Glossary, Version
2" [RFC4949].
Part of this discussion will be indication of known deployments or at
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 RTP (SRTP) protocol [RFC3711] is one of the most commonly
used mechanisms to provide confidentiality, integrity protection and used mechanisms to provide confidentiality, integrity protection,
source authentication for RTP. SRTP was developed with RTP header source authentication and replay protection for RTP. SRTP was
compression and third party monitors in mind. Thus the RTP header is developed with RTP header compression and third party monitors in
not encrypted in RTP data packets, and the first 8 bytes of the first mind. Thus the RTP header is not encrypted in RTP data packets, and
RTCP packet header in each compound RTCP packet are not encrypted. the first 8 bytes of the first RTCP packet header in each compound
The entirety of RTP packets and compound RTCP packets are integrity RTCP packet are not encrypted. The entirety of RTP packets and
protected. This allows RTP header compression to work, and lets compound RTCP packets are integrity protected. This allows RTP
third party monitors determine what RTP traffic flows exist based on header compression to work, and lets third party monitors determine
the SSRC fields, but protects the sensitive content. what RTP traffic flows exist based on the SSRC fields, but protects
the sensitive content.
The source authentication guarantees provided by SRTP are highly The source authentication guarantees provided by SRTP are highly
dependent on the cryptographic transform and key-management scheme dependent on the cryptographic transform and key-management scheme
used. In some cases all a receiver can determine is whether the used. In some cases all a receiver can determine is whether the
packets come from someone in the group security context, and not what packets come from someone in the group security context, and not what
group member send the packets. Thus, the source authentication group member send the packets. Thus, the source authentication
guarantees depend also on the session topology. Some cryptographic guarantees depend also on the session topology. Some cryptographic
transform have stronger authentication properties which can guarantee transform have stronger authentication properties which can guarantee
a given source, even over a multi-party session, e.g. those based on a given source, even over a multi-party session, e.g. those based on
TESLA [RFC4383]. TESLA [RFC4383].
SRTP can easily be extended with additional cryptographic transforms. SRTP can easily be extended with additional cryptographic transforms.
At the time of this writing, the following transforms are defined or At the time of this writing, the following transforms are defined or
under definition: under definition:
AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits AES CM and HMAC-SHA-1: AES Counter Mode encryption with 128 bits
keys combined with 128 bits keyed HMAC-SHA1 using 80 or 32 bits keys combined with 128 bits keyed HMAC-SHA1 using 80 or 32 bits
authentication tags are the default cryptographic transform which authentication tags are the default cryptographic transform which
need to be supported. Defined in SRTP [RFC3711]. need to be supported. Defined in SRTP [RFC3711].
skipping to change at page 11, line 12 skipping to change at page 10, line 33
one using SHA-1 authentication, one using Counter with CBC-MAC, one using SHA-1 authentication, one using Counter with CBC-MAC,
and finally one using Galois Counter mode. and finally one using Galois Counter mode.
ARIA: An Korean block cipher [I-D.ietf-avtcore-aria-srtp], that ARIA: An Korean block cipher [I-D.ietf-avtcore-aria-srtp], that
supports 128, 192 and 256 bits keys. It also has three modes, supports 128, 192 and 256 bits keys. It also has three modes,
Counter mode where combined with HMAC-SHA1 with 80 or 32 bits Counter mode where combined with HMAC-SHA1 with 80 or 32 bits
authentication tags, Counter mode with CBC-MAC and Galois Counter authentication tags, Counter mode with CBC-MAC and Galois Counter
mode. It also defines a different key derivation function than mode. It also defines a different key derivation function than
the AES based. the AES based.
AES-192 and AES-256: cryptographic transforms for SRTP based on AES- AES-192 and AES-256: cryptographic transforms for SRTP based on
192 and AES-256 counter mode encryption and 160-bit keyed HMAC- AES-192 and AES-256 counter mode encryption and 160-bit keyed
SHA1 with 80 and 32 bits authentication tags for authentication. HMAC-SHA1 with 80 and 32 bits authentication tags for
Thus providing 192 and 256 bits encryption keys and NSA Suite B authentication. Thus providing 192 and 256 bits encryption keys
included cryptographic transforms. Defined in [RFC6188]. and NSA Suite B included cryptographic transforms. Defined in
[RFC6188].
AES-GCM: There is also ongoing work to define AES-GCM (Galois AES-GCM: There is also ongoing work to define AES-GCM (Galois
Counter Mode) and AES-CCM (Counter with CBC) authentication for Counter Mode) and AES-CCM (Counter with CBC) authentication for
AES-128 and AES-256. This authentication is included in the AES-128 and AES-256. This authentication is included in the
cipher text which becomes expanded with the length of the cipher text which becomes expanded with the length of the
authentication tag instead of using the SRTP authentication tag. authentication tag instead of using the SRTP authentication tag.
This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm].
[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 in normally carried in the clear and only RTP header extensions are in 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 [I-D.ietf-avtcore-srtp-encrypted-header-ext] defines an extension so [RFC6904] defines an extension to also encrypt selected header
to also encrypt selected header extensions. extensions.
SRTP is specified and deployed in a number of RTP usage contexts;
Significant support in SIP established VoIP clients including IMS;
RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming.
Thus SRTP in general is widely deployed. When it comes to
cryptographic transforms the default (AES CM and HMAC-SHA1) is the
most common used.
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-
exchange between two peers, including perfect forward secrecy and exchange between two peers, enabling perfect forward secrecy and
enabling binding strong identity verification to an end-point. The binding strong identity verification to an end-point. The default
default key generation will generate a key that contains material key generation will generate a key that contains material contributed
contributed by both peers. The key-exchange happens in the media by both peers. The key-exchange happens in the media plane directly
plane directly between the peers. The common key-exchange procedures between the peers. The common key-exchange procedures will take two
will take two round trips assuming no losses. TLS resumption can be round trips assuming no losses. TLS resumption can be used when
used when establishing additional media streams with the same peer, establishing additional media streams with the same peer, used
used reducing the set-up time to one RTT. reducing the set-up time to one RTT.
The actual security properties of an established SRTP session using
DTLS will depend on the cipher suits offered and used. For example
some provides perfect forward secrecy (PFS), while other do not.
When using DTLS the application designer needs to select which cipher
suits that DTLS-SRTP can offer and accept so that the desired
security properties are achieved.
DTLS-SRTP key management can use the signalling protocol in three DTLS-SRTP key management can use the signalling protocol in three
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 an DTLS listener to let the parts perform the each side is running an 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.
Finally, to exchange hashes of each sides certificates to enable each Finally, to exchange hashes of each sides certificates to enable each
side to verify that they have connected to the by signalling side to verify that they have connected to the by signalling
indicated port and not a man in the middle. That way enabling some indicated port and not a man in the middle. That way enabling some
binding between the key-exchange and the signalling. This usage is binding between the key-exchange and the signalling. This usage is
well defined for SIP/SDP in [RFC5763], and in most cases can be well defined for SIP/SDP in [RFC5763], and in most cases can be
adopted for use with other bi-directions signalling solutions. adopted for use with other bi-directions signalling solutions.
DTLS-SRTP usage and inclusion in specification are clearly on the
rise. It is mandatory to support in WebRTC. It has a growing
support among SIP end-points, which is good considering that DTLS-
SRTP was primarily developed in IETF to meet security requirements
from 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 possible to use in scenarios sessions with a single message. It is possible to use in scenarios
skipping to change at page 12, line 38 skipping to change at page 12, line 32
a number of participants. The different modes and the resulting a number of participants. The different modes and the resulting
properties are highly dependent on the cryptographic method used to properties are highly dependent on the cryptographic method used to
establish the Traffic Generation Key (TGK) that is used to derive the establish the Traffic Generation Key (TGK) that is used to derive the
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 TGK. This system is the most efficient from the perspective of
having small messages and processing demands. having small messages and processing demands. The downside is
scalability, where usually the effort for the provisioning of pre-
shared keys is only manageable, if the number 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 TGK. This is more resource
consuming but enables scalable systems. It does require a public consuming but enables scalable systems. It does require a public
key infrastructure to enable verification. 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 TGK, thus providing perfect forward secrecy. The downside is
increased resource consumption in bandwidth and processing. This increased resource consumption in bandwidth and processing. This
method can't be used to establish group keys as each pair of peers method can't be used to establish group keys as each pair of peers
skipping to change at page 13, line 21 skipping to change at page 13, line 15
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 responders certificate. This methods lets
both the initiator and the responder to specify the TGK material both the initiator and the responder to specify the TGK material
depending on use case. Usage of this mode requires one round trip depending on use case. Usage of this mode requires one round trip
time. time.
TICKET: [RFC6043] is a MIKEY extension using trusted centralized key TICKET: [RFC6043] is a MIKEY extension using trusted centralized key
management service and tickets, like Kerberos. management service and tickets, like Kerberos.
IBAKE: [RFC6267] uses a key management services (KMS) but with lower IBAKE: [RFC6267] uses a key management services (KMS) infrastructure
demand on the KMS. If provides both perfect forward and backwards but with lower demand on the KMS. Claims to provides both perfect
secrecy. forward and backwards secrecy, the exact meaning is unclear (See
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 to establish a Based on Identity based Public Key Cryptography and a KMS
shared secret value and certificate less signatures to provide infrastructure to establish a shared secret value and certificate
source authentication. It features include simplex transmission, less signatures to provide source authentication. It features
scalability, low-latency call set-up, and support for secure include simplex transmission, scalability, low-latency call set-
deferred delivery. up, and support for secure deferred delivery.
MIKEY messages has several different defined transports. [RFC4567] MIKEY messages has several different defined transports. [RFC4567]
defines how MIKEY messages can be embedded in general SDP for usage defines how MIKEY messages can be embedded in general SDP for usage
with the signalling protocols SIP, SAP and RTSP. There also exist an with the signalling protocols SIP, SAP and RTSP. There also exist an
3GPP defined usage of MIKEY that sends MIKEY messages directly over 3GPP defined usage of MIKEY that sends MIKEY messages directly over
UDP to key the receivers of Multimedia Broadcast and Multicast UDP to key the receivers of Multimedia Broadcast and Multicast
Service (MBMS) [3GPP.33.246]. Service (MBMS) [T3GPP.33.246].
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].
While RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies use of the
RSA-R mode. There are some SIP end-points that supports MIKEY and
which mode they use are unknown by 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 SDP Offer/ in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/
Answer, and is well-defined in point to point sessions where each Answer, and is well-defined in point to point sessions where each
side declares its own unique key. Using Security Descriptions to side declares its own unique key. Using Security Descriptions to
establish group keys is less well defined, and can have security establish group keys is less well defined, and can have security
issues as the SSRC uniqueness property can't be guaranteed. issues as the SSRC uniqueness property can't be guaranteed.
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 the end confidentiality and authentication guarantees. This is not the
common use of security descriptions with SIP, where instead hop by common use of security descriptions with SIP, where instead hop by
hop security is provided between signalling nodes using TLS. This hop security is provided between signalling nodes using TLS. This
still leaves the keying material sensitive to capture by the still leaves the keying material sensitive to capture by the
traversed signalling nodes. Thus in most cases the security traversed signalling nodes. Thus in most cases the security
properties of security description are weak. properties of security descriptions are weak. The usage of security
descriptions usually requires additional security measures, e.g. the
signalling nodes be trusted and protected by strict access control.
Usage of security descriptions requires careful design in order to
ensure that the security goals can be met.
Security Descriptions is the most commonly deployed keying solution
for SIP-based end-points, where almost all that supports SRTP also
supports Security Descriptions.
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
that can't support group keys, like DTLS-SRTP. It is designed for that can't support group keys, like DTLS-SRTP. It is designed for
centralized conferencing, but can also be used in sessions where an centralized conferencing, but can also be used in sessions where an
end-points connect to a conference bridge or a gateway, and need to end-points connect to a conference bridge or a gateway, and need to
be provisioned with the keys each participant on the bridge or be provisioned with the keys each participant on the bridge or
gateway uses to avoid decryption encryption cycles on the bridge or gateway uses to avoid decryption encryption cycles on the bridge or
gateway. gateway. This can enable interworking between DTLS-SRTP and for
example security descriptions or other keying systems where either
part can set the key.
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 a expanded authentication tag to the other
session participants. This key are only sent occasionally or session participants. This key are only sent occasionally or
periodically depending on use cases depending on what requirements periodically depending on use cases depending on what requirements
exist for timely delivery or notification on when the key is needed exist for timely delivery or notification on when the key is needed
by someone. by someone.
The only known deployment of EKT so far are in some Cisco Video
Conferencing products.
3.1.5. Key Management for SRTP: Other systems 3.1.5. Key Management for SRTP: Other systems
There exist at least one additional SRTP key-management system, The ZRTP [RFC6189] key-management system for SRTP was proposed as an
namely ZRTP [RFC6189]. This was a candidate for IETF standardization alternative to DTLS-SRTP. It wasn't adopted as an IETF standards
that wasn't chosen, and was published for information instead. Its track protocol, but was instead published as an informational RFC.
properties are somewhat similar to DTLS.
There might exist additional non-IETF defined solutions. 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 DES or 3DES based
encryption of RTP and RTCP packets. This mechanism is keyed using encryption of RTP and RTCP packets. This mechanism is keyed using
plain text keys in SDP [RFC4566] using the "k=" SDP field. This plain text keys in SDP [RFC4566] using the "k=" SDP field. This
method of providing confidentiality has extremely weak security method of providing confidentiality has extremely weak security
properties and is not to be used. properties and is not to be used.
3.3. IPsec 3.3. IPsec
skipping to change at page 16, line 5 skipping to change at page 16, line 11
DTLS uses the normal datagram TLS data protection. When using DTLS, DTLS uses the normal datagram TLS data protection. When using DTLS,
RTP and RTCP packets are completely encrypted with no headers in the RTP and RTCP packets are completely encrypted with no headers in the
clear, while DTLS-SRTP leaves the headers in the clear. clear, while DTLS-SRTP leaves the headers in the clear.
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 appear to be no significant usage of RTP over DTLS.
3.5. TLS over TCP 3.5. TLS over TCP
When RTP is sent over TCP [RFC4571] it can also be sent over TLS over 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. TCP [RFC4572], using TLS to provide point to point security services.
The security properties TLS provides are confidentiality, integrity The security properties TLS provides are confidentiality, integrity
protection and possible source authentication if the client or server protection and possible source authentication if the client or server
certificates are verified and provide a usable identity. When used certificates are verified and provide a usable identity. When used
in multi-party scenarios using a central node for media distribution, in multi-party scenarios using a central node for media distribution,
the security provide is only between then central node and the peers, the security provide is only between then central node and the peers,
so the security properties for the whole session are dependent on so the security properties for the whole session are dependent on
what trust one can place in the central node. 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 is also used in some
proprietary solutions that uses TLS to bypass firewalls.
3.6. Payload-only Security Mechanisms 3.6. Payload-only Security Mechanisms
Mechanisms have been defined that encrypt only the payload of the RTP Mechanisms have been defined that encrypt only the payload of the RTP
packets, and leave the RTP headers and RTCP in the clear. There are packets, and leave the RTP headers and RTCP in the clear. There are
several reasons why this might be appropriate, but a common rationale several reasons why this might be appropriate, but a common rationale
is to ensure that the content stored in RTP hint tracks in RTSP is to ensure that the content stored in RTP hint tracks in RTSP
streaming servers has the media content in a protected format that streaming servers has the media content in a protected format that
cannot be read by the streaming server (this is mostly done in the cannot be read by the streaming server (this is mostly done in the
context of Digital Rights Management). These approaches then uses a context of Digital Rights Management). These approaches then uses a
key-management solution between the rights provider and the consuming key-management solution between the rights provider and the consuming
skipping to change at page 16, line 51 skipping to change at page 17, line 15
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 [3GPP.23.234] 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 [ISMACrypt2]. 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
skipping to change at page 17, line 40 skipping to change at page 18, line 4
what behaviour they strive to achieve. what behaviour 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 expect the protected content
remain confidential. From that, one can determine what encryption remain confidential. National or other regulations might provided
algorithm is to be used from the set of available transforms. additional requirements on a particular usage of an RTP. From
that, one can determine what encryption algorithms are 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, and
details of the RTP and RTCP headers, are visible to observers of details of the RTP and RTCP headers, are visible to observers of
the protected packet flow. This can provide information to those the protected packet flow. This can provide information to those
observers. A well documented case is the risk with variable bit- observers. A well documented case is the risk with variable bit-
rate speech codecs that produce different sized packets based on rate speech codecs that produce different sized packets based on
the speech input [RFC6562]. Potential threats such as these need the speech input [RFC6562]. Potential threats such as these need
to be considered and, if they are significant, then restrictions to be considered and, if they are significant, then restrictions
skipping to change at page 19, line 25 skipping to change at page 19, line 39
particularly useful. In similar way, although not as definitive, is particularly useful. In similar way, although not as definitive, is
that integrity without source authentication is also not particular that integrity without source authentication is also not particular
useful: you need to know who claims this packet wasn't changed. useful: you need to know who claims this packet wasn't changed.
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 provides 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 to not be circumvented in the time frame when you would
accept the packet as valid, it is possible that assert the source accept the packet as valid, it is possible to assert a source
authenticated statement that this message is most probably from authenticated statement; this message is highly probably from
someone that has the cryptographic key to this communication. someone that 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. In an application where
the key-handling is limited to two peers, this can form a basis the key-handling is limited to two peers, this can form a basis
for a trust relationship to the level that you can state as the for a trust relationship to the level that you can state as the
traffic is authenticated and matching this particular context, it traffic is authenticated and matching this particular context.
is coming either from me or from my peer (and I trust that neither Thus, it is coming either from me or from my peer (and I trust
has shared the key with anyone else). However, in a multi-party that neither has shared the key with anyone else). However, in a
scenario where security contexts are shared among participants, multi-party scenario where security contexts are shared among
most base-level authentication solution can't even assert that participants, most base-level authentication solutions can't even
this packet is from the same source as the previous packet. 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 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. 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 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 of the packets is the same entity that I have established the
session with. How feasible this is depends on the properties of session with. How feasible this is depends on the properties of
the key-management system used, the ability to tie the signalling the key-management system used, the ability to tie the signalling
to a particular peer, and what trust you place on the different to a particular peer, and what trust you place on the different
nodes involved. nodes involved.
For example, consider a point to point communication system that For example, consider a point to point communication system that
use DTLS-SRTP using self-signed certificates for key-management, use DTLS-SRTP using self-signed certificates for key-management,
and SIP for signalling. In such a system the end-points for the and SIP for signalling. In such a system the end-points for the
DTLS-SRTP handshake have securely established keys that are not DTLS-SRTP handshake have securely established keys that are not
visible to the signalling nodes. However, as the certificates visible to the signalling nodes. However, as the certificates
used by DTLS is not bound to any PKI they can't be verified. used by DTLS is not bound to any PKI they can't be verified.
Instead, hashes over the certificate are sent over the signalling Instead, hashes over the certificate are sent over the signalling
path. If the signalling can be trusted not to collaborate on path. If the signalling can be trusted not to collaborate on
performing a man in the middle attack by modifying the hashes, performing a man in the middle attack by modifying the hashes,
then the end-points can verify that they have reached the peer then the end-points can verify that they have established keys
they are doing signalling with. with the peer they are doing signalling with.
Systems where the key-exchange are done using the signalling
systems, such as Security Descriptions [RFC4568] or MIKEY embedded
in SDP [RFC4567], enables an direct binding between signalling and
key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual
security depends on the trust one can place in the signalling
system to correctly associate the peer's identity with the key-
exchange.
Using Identities: If the applications have access to a system that Using Identities: If the applications have access to a system that
can provide verifiable identities, then the source authentication can provide verifiable identities, then the source authentication
can be bound to that identity. For example, in a point-to-point can be bound to that identity. 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 identity, can provide a strong assertion about who is sending the
traffic. traffic.
Note that all levels of the system much have matching capability Note that all levels of the system much have matching capability
to assert identity. Having the signalling assert that you include to assert identity. Having the signalling assert that you include
a particular identity in a multi-party communication session where a particular identity in a multi-party communication session where
the key-management systems establish keys in a way that one can the key-management systems establish keys in a way that one can
assert that only the given identity has gotten the key. Using a assert that only the given identity has gotten the key. Using a
authentication mechanism build on a group key and otherwise can't authentication mechanism built on a group key that otherwise can't
provide any assertion who sent the traffic than anyone that got provide any assertion who sent the traffic than anyone that got
the key provides no strong assertion on the media level than: the key, provides no strong assertion on the media level than:
Someone that has gotten the security context (key) sent this Someone that has gotten the security context (key) sent this
traffic. traffic.
4.1.4. Identity 4.1.4. Identity
As seen in the previous section, having an identity provider system There exist many different types of identity systems with different
can benefit the applications by enabling them to do strong assertion properties. But in the context of RTP applications the most
between identity and the actual media source. Therefore, the need important property is the possibility to perform source
for identity needs to be considered. However, having identity authentication and verify such assertions in relation to any claimed
systems might not be suitable for all types of application, since identities. What an identity really are can also vary, but in the
they require trusted infrastructure. 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:
Certificate based: A certificate is used to prove the identity, by
having access to the private part of the certificate one can
perform signing to assert ones identity. Any entity interested in
verifying the assertion then needs the public part of the
certificate. By having the certificate one can verify the signing
against the certificate. The next step is to determine if one
trusts the certificate's trust chain. Commonly by provisioning
the verifier with the public part of a root certificate, this
enables the verifier to verify a trust chain from the root
certificate down to the identity certificate. However, the trust
is based on that all steps in the certificate chain are verifiable
and can be trusted. Thus provisioning of root certificates,
having possibility to revoke compromised certificates are aspects
that will require infrastructure.
Online Identity Providers: An online identity provider (IdP) can
authenticate a user's right to use an identity, then perform
assertions on their behalf or provision the requester with short-
term credentials to assert their identity. The verifier can then
contact the IdP to request verification of a particular identity.
Here the trust is highly dependent on how much one trusts the IdP.
The system also becomes dependent on having access to the relevant
IdP.
In all of the above examples, an important part of the security
properties are related to the method for authenticating the access to
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 end-point. The
main way of avoid such concerns is the introduction of relay or main way of avoid such concerns is the introduction of relay or
centralized media mixers or forwarders that hides the address of a centralized media mixers or forwarders that hides the address of a
peer from any other peer. The security and trust placed in these peer from any other peer. The security and trust placed in these
relays obviously needs to be carefully considered. 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 CNAME is generated according to
the RTP specification in the form of user@host. Such RTCP CNAMEs are the RTP specification in the form of user@host. Such RTCP CNAMEs are
likely long term stable over multiple sessions, allowing tracking of likely long term stable over multiple sessions, allowing tracking of
users. This can be desirable for long-term fault tracking and users. This can be desirable for long-term fault tracking and
diagnosis, but clearly has privacy implications. Instead diagnosis, but clearly has privacy implications. Instead
cryptographically random ones could be used as defined by Random cryptographically random ones could be used as defined by Guidelines
algorithm for RTP CNAME generation for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
[I-D.rescorla-avtcore-random-cname]. [I-D.ietf-avtcore-6222bis].
If there exist privacy goals, these need to be considered, and the If there exist privacy goals, these need to be considered, and the
system designed with them in mind. In addition certain RTP features system designed with them in mind. In addition certain RTP features
might have to be configured to safeguard privacy, or have might have to be configured to safeguard privacy, or have
requirements on how the implementation is done. requirements on 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
skipping to change at page 22, line 43 skipping to change at page 24, line 11
The clients also verify the fingerprints of the certificates to The clients also verify the fingerprints of the certificates to
verify that no man in the middle has inserted themselves into the verify 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. At the basic level DTLS has a number of good security properties.
For example, to enable a man in the middle someone in the signalling For example, to enable a man in the middle someone in the signalling
path needs to perform an active action and modify the signalling path needs to perform an active action and modify the signalling
message. There also exist a solution that enables the fingerprints message. There also exist a solution that enables the fingerprints
to be bound to identities established by the first proxy for each to be bound to identities established by the first proxy for each
user [RFC4916]. That reduces the number of nodes the connecting user user [RFC4916]. That reduces the number of nodes the connecting user
UA has to trust to the first hop proxy, rather than the full User Agent has to trust to the first hop proxy, rather than the full
signalling path. signalling path.
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 [I-D.ietf-rtcweb-overview] is solution
providing web-application with real-time media directly between providing web-application with real-time media directly between
browsers. The RTP transported real-time media is protected using a browsers. The RTP transported real-time media is protected using a
mandatory to use application of SRTP. The keying of SRTP is done mandatory to use application of SRTP. The default keying of SRTP is
using DTLS-SRTP. The security configuration is further defined in done using DTLS-SRTP. The security configuration is further defined
the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. in the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch].
The peers hash of their certificates are provided to a Javascript The peers hash of their certificates are provided to a Javascript
application that is part of a client server system providing application that is part of a client server system providing
rendezvous services for the ones a given peer wants to communicate rendezvous services for the ones a given peer wants to communicate
with. Thus the handling of the hashes between the peers is not well with. Thus the handling of the hashes between the peers is not well
defined. It becomes a matter of trust in the application. But defined. It becomes a matter of trust in the application. But
unless the application and its server is intending to compromise the unless the application and its server is intending to compromise the
communication security they can provide a secure and integrity communication security they can provide a secure and integrity
protected exchange of the certificate hashes thus preventing any man- protected exchange of the certificate hashes thus preventing any man-
in-the-middle (MITM) to insert itself in the key-exchange. in-the-middle (MITM) to insert itself in the key-exchange.
The web application still have the possibility to insert a MITM. The web application still have the possibility to insert a MITM.
That unless one uses a Identity provider and the proposed identity That unless one uses a Identity provider and the proposed identity
solution [I-D.rescorla-rtcweb-generic-idp]. In this solution the solution [I-D.ietf-rtcweb-security-arch]. In this solution the
Identity Provider which is a third party to the web-application signs Identity Provider which is a third party to the web-application signs
the DTLS-SRTP hash combined with a statement on which user identity 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 that has been used to sign the hash. The receiver of such a Identity
assertion then independently verifies the user identity to ensure assertion then independently verifies the user identity to ensure
that it is the identity it intended to communicate and that the that it is the identity it intended to communicate and that the
cryptographic assertion holds. That way a user can be certain that cryptographic assertion holds. That way a user can be certain that
the application also can't perform an MITM and that way acquire the the application also can't perform an MITM and that way acquire the
keys to the media communication. keys to the media communication.
In the development of WebRTC there has also been high attention on In the development of WebRTC there has also been high attention on
privacy question. The main concerns that has been raised and are at privacy question. The main concerns that has been raised and are at
all related to RTP are: all related to RTP are:
Location Disclosure: As ICE negotiation provides IP addresses and Location Disclosure: As ICE negotiation provides IP addresses and
ports for the browser, this leaks location information in the ports for the browser, this leaks location information in the
signalling to the peer. To prevent this one can block the usage signalling 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 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 IP and port provided belong to the service providers media traffic
relay. relay.
Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP
certificates is information that could possibly be re-used between certificates is information that could possibly be re-used between
session instances. Thus to prevent tracking the same information session instances. Thus to prevent tracking the same information
can't be re-used between different communication sessions. can't be re-used between different communication sessions.
Note: The above cases are focused on providing privacy towards other Note: The above cases are focused on providing privacy towards other
parties than the web service. parties than the web service.
5.3. 3GPP Packet Based Streaming Service (PSS) 5.3. 3GPP Packet Based Streaming Service (PSS)
To be written: The 3GPP Release 11 PSS specification of the Packet Based Streaming
Service (PSS) [T3GPP.26.234R11] defines in Annex R a set of security
mechanisms. These security mechanisms are centred around protecting
the content from being captured, i.e. Digital Rights Management. If
these goals are to be meet with the specified solution there needs to
exist trust in that neither the implementation of the client nor the
platform the application runs can be accessed or modified by the
attacker.
5.4. IPTV PSS is RTSP 1.0 [RFC2326] controlled media 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 are ISMA Crypt 2.0
[ISMACrypt2] protected media encoding application units (AUs). The
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
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
be used, then using RTSP an additional stream for key-updates in
parallel with the media streams are established, where key updates
are sent to the client using Short Term Key Messages defined by
"Service and Content Protection for Mobile Broadcast Services" part
of the OMA Mobile Broadcast Services [OMABCAST].
To be written: Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header
information, only the encoded media AU is protected. 3GPP has not
defined any requirement for supporting SRTP or other solution that
could provide that service. Thus, replay or insertion attacks are
possible. Another property is that the media content can be
protected by the ones providing the media, so that the operators of
the RTSP server has no access to unprotected content. Instead all
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
decrypt the media.
To protect the signalling RTSP 1.0 supports the usage of TLS, this is
however not explicitly discussed in the PSS specification. Usage of
TLS can prevent both modification of the session description
information and help maintain some privacy of what content the user
is watching as all URLs would then be confidentiality protected.
5.4. RTSP 2.0
Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] can be
an interesting comparison to the PSS service (Section 5.3) that is
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
2.0 is fully defined under the requirement to have mandatory to
implement security mechanism. As it specifies how one transport
media over RTP it is also defining security mechanisms for the RTP
transported media streams.
The security goals for RTP in RTSP 2.0 is to ensure that there are
confidentiality, integrity and source authentication between the RTSP
server and the client. This to prevent eavesdropping on what the
user is watching for privacy reasons and prevent replay or injection
attacks on the media stream. To reach these goals also the
signalling has to be protected, requiring the use of TLS between the
client and server.
Using TLS protected signalling the client and server agrees on the
media transport method when doing the SETUP request and response.
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
mode is selected as it allows the RTSP Server to select the key,
despite having the RTSP Client initiate the MIKEY exchange. It also
enables the reuse of the RTSP servers TLS certificate when creating
the MIKEY messages thus ensuring a binding between the RTSP server
and the key-exchange. Assuming the SETUP process works, this will
establish a SRTP crypto context to be used between the RTSP Server
and the Client for the RTP transported media streams.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section can be removed on publication as an Note to RFC Editor: this section can be removed on publication as an
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.
9. Informative References The authors wished to thank Christian Correll for review and great
proposals for improvements of the text.
[3GPP.23.234]
3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
8.4.0, September 2009.
[3GPP.33.246] 9. Informative References
3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 10.1.0,
December 2012.
[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-11 Security Solution", draft-ietf-avt-srtp-not-mandatory-12
(work in progress), November 2012. (work in progress), February 2013.
[I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-03
(work in progress), April 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-01 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-01
(work in progress), December 2012. (work in progress), December 2012.
[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)", Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
draft-ietf-avtcore-srtp-aes-gcm-05 (work in progress), aes-gcm-05 (work in progress), February 2013.
February 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-avtcore-srtp-encrypted-header-ext] [I-D.ietf-mmusic-rfc2326bis]
Lennox, J., "Encryption of Header Extensions in the Secure Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
Real-Time Transport Protocol (SRTP)", and M. Stiemerling, "Real Time Streaming Protocol 2.0
draft-ietf-avtcore-srtp-encrypted-header-ext-05 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), February 2013. progress), April 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-06 (work based Applications", draft-ietf-rtcweb-overview-06 (work
in progress), February 2013. in progress), February 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture", draft-ietf-
draft-ietf-rtcweb-security-arch-06 (work in progress), rtcweb-security-arch-06 (work in progress), January 2013.
January 2013.
[I-D.rescorla-avtcore-random-cname]
Rescorla, E., "Random algorithm for RTP CNAME generation",
draft-rescorla-avtcore-random-cname-00 (work in progress),
July 2012.
[I-D.rescorla-rtcweb-generic-idp]
Rescorla, E., "RTCWEB Generic Identity Provider
Interface", draft-rescorla-rtcweb-generic-idp-01 (work in
progress), March 2012.
[ISMACrypt2] [ISMACrypt2]
"ISMA Encryption and Authentication, Version 2.0 release , "ISMA Encryption and Authentication, Version 2.0 release
version", November 2007. version", November 2007.
[OMABCAST]
Open Mobile Alliance, "OMA Mobile Broadcast Services
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,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, Engineering Task Force Standard Protocols", BCP 61, RFC
RFC 3365, August 2002. 3365, August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
and P. Gentric, "RTP Payload Format for Transport of and P. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", RFC 3640, November 2003. MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
skipping to change at page 26, line 31 skipping to change at page 29, line 7
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, Real-time Transport Protocol (SRTP)", RFC 4383, February
February 2006. 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
skipping to change at page 27, line 10 skipping to change at page 29, line 34
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, Multimedia Internet KEYing (MIKEY)", RFC 4650, September
September 2006. 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, Multimedia Internet KEYing (MIKEY)", RFC 4738, November
November 2006. 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real- Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007. time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[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.
[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.
skipping to change at page 28, line 18 skipping to change at page 30, line 46
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
RTP", RFC 6188, March 2011. RTP", RFC 6188, March 2011.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189, Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011. April 2011.
[RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based
Authenticated Key Exchange (IBAKE) Mode of Key Authenticated Key Exchange (IBAKE) Mode of Key
Distribution in Multimedia Internet KEYing (MIKEY)", Distribution in Multimedia Internet KEYing (MIKEY)", RFC
RFC 6267, June 2011. 6267, June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in
Multimedia Internet KEYing (MIKEY)", RFC 6509, Multimedia Internet KEYing (MIKEY)", RFC 6509, February
February 2012. 2012.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, Variable Bit Rate Audio with Secure RTP", RFC 6562, March
March 2012. 2012.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April
2013.
[T3GPP.26.234R11]
3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
11.1.0, September 2012.
[T3GPP.26.234R8]
3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
8.4.0, September 2009.
[T3GPP.26.346]
3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013.
[T3GPP.33.246]
3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 10.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
 End of changes. 63 change blocks. 
201 lines changed or deleted 402 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/