draft-ietf-avtcore-rtp-security-options-03.txt   draft-ietf-avtcore-rtp-security-options-04.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: November 07, 2013 University of Glasgow Expires: January 16, 2014 University of Glasgow
May 06, 2013 July 15, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-03 draft-ietf-avtcore-rtp-security-options-04
Abstract Abstract
The Real-time Transport Protocol (RTP) is used in a large number of The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This heterogeneity different application domains and environments. This heterogeneity
implies that different security mechanisms are needed to provide implies that different security mechanisms are needed to provide
services such as confidentiality, integrity and source authentication services such as confidentiality, integrity and source authentication
of RTP/RTCP packets suitable for the various environments. The range of RTP/RTCP packets suitable for the various environments. The range
of solutions makes it difficult for RTP-based application developers of solutions makes it difficult for RTP-based application developers
to pick the most suitable mechanism. This document provides an to pick the most suitable mechanism. This document provides an
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 07, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . 15 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 20
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Application Structure . . . . . . . . . . . . . . . . . . 22 4.2. Application Structure . . . . . . . . . . . . . . . . . . 22
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Media Security for SIP-established Sessions using DTLS- 5.1. Media Security for SIP-established Sessions using DTLS-
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25
5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . 27 9. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
The remainder of this document is structured as follows. Section 2 The remainder of this document is structured as follows. Section 2
provides additional background. Section 3 outlines the available provides additional background. Section 3 outlines the available
security mechanisms at the time of this writing, and lists their key security mechanisms at the time of this writing, and lists their key
security properties and constraints. That is followed by guidelines security properties and constraints. That is followed by guidelines
and important aspects to consider when securing an RTP application in and important aspects to consider when securing an RTP application in
Section 4. Finally, we give some examples of application domains Section 4. Finally, we give some examples of application domains
where guidelines for security exist in Section 5. where guidelines for security exist in Section 5.
2. Background 2. Background
RTP can be used in a wide variety of topologies, and combinations of RTP can be used in a wide variety of topologies due to it's support
topologies, due to it's support for unicast, multicast groups, and for point-to-point sessions, multicast groups, and other topologies
broadcast topologies, and the existence of different types of RTP built around different types of RTP middleboxes. In the following we
middleboxes. In the following we review the different topologies review the different topologies supported by RTP to understand their
supported by RTP to understand their implications for the security implications for the security properties and trust relations that can
properties and trust relations that can exist in RTP sessions. exist in RTP sessions.
2.1. Point to Point Sessions 2.1. Point to Point Sessions
The most basic use case is two directly connected end-points, shown The most basic use case is two directly connected end-points, shown
in Figure 1, where A has established an RTP session with B. In this in Figure 1, where A has established an RTP session with B. In this
case the RTP security is primarily about ensuring that any third case the RTP security is primarily about ensuring that any third
party can't compromise the confidentiality and integrity of the media party can't compromise the confidentiality and integrity of the media
communication. This requires confidentiality protection of the RTP communication. This requires confidentiality protection of the RTP
session, integrity protection of the RTP/RTCP packets, and source session, integrity protection of the RTP/RTCP packets, and source
authentication of all the packets to ensure no man-in-the-middle authentication of all the packets to ensure no man-in-the-middle
skipping to change at page 4, line 48 skipping to change at page 4, line 48
one can do. one can do.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Topology Figure 1: Point to Point Topology
2.2. Sessions Using an RTP Mixer 2.2. Sessions Using an RTP Mixer
An RTP mixer is an RTP session level middlebox that one can build an An RTP mixer is an RTP session-level middlebox that one can build a
multi-party RTP based conference around. The RTP mixer might multi-party RTP based conference around. The RTP mixer might
actually perform media mixing, like mixing audio or compositing video actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the participant; or it might provide a conceptual stream, for example the
video of the current active speaker. From a security point of view, video of the current active speaker. From a security point of view,
the important features of an RTP mixer is that it generates a new the important features of an RTP mixer is that it generates a new
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 example, participants A through D each send
traffic between themselves and the RTP mixer, and receive a RTP unicast RTP traffic to the RTP mixer, and receive an RTP stream from
stream from the mixer, comprising a mixture of the streams from the the mixer, comprising a mixture of the streams from the other
other participants. participants.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 2: Example RTP Mixer topology Figure 2: Example RTP Mixer topology
A consequence of an RTP mixer having its own source identifier, and A consequence of an RTP mixer having its own source identifier, and
acting as an active participant towards the other end-points, is that acting as an active participant towards the other 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
source authenticate each peer. The mixer then ensures that one source authenticate each peer. The mixer then ensures that one
participant cannot impersonate another. participant cannot impersonate another.
2.3. Sessions Using an RTP Translator 2.3. Sessions Using an RTP Translator
skipping to change at page 8, line 21 skipping to change at page 8, line 21
feedback part of the SSM RTP session using unicast feedback [RFC5760] feedback part of the SSM RTP session using unicast feedback [RFC5760]
from a number of receivers R1..Rn that sends feedback to a Feedback from a number of receivers R1..Rn that sends feedback to a Feedback
Target (FT) and eventually aggregated and distributed to the group. Target (FT) and eventually aggregated and distributed to the group.
The use of SSM makes it more difficult to inject traffic into the The use of SSM makes it more difficult to inject traffic into the
multicast group, but not impossible. Source authentication multicast group, but not impossible. Source authentication
requirements apply for SSM sessions too, and a non-symmetric requirements apply for SSM sessions too, and a non-symmetric
verification of who sent the RTP and RTCP packets is needed. verification of who sent the RTP and RTCP packets is needed.
The SSM communication channel needs to be securely established and The SSM communication channel needs to be securely established and
keyed. In addition one also have the individual unicast feedback keyed. In addition one also has the individual unicast RTCP feedback
that also needs to be secured. that needs to be secured.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm | | MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
^ ^ ^ ^ ^ ^
| | | | | |
V V V V V V
+---------------------------------+ +---------------------------------+
| Distribution Source | | Distribution Source |
+--------+ | +--------+ |
skipping to change at page 9, line 9 skipping to change at page 9, line 9
: /. \ / .\ : : /. \ / .\ :
: 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 security requirements, and the
security mechanisms that can be used with RTP. This section will use current RTP security mechanisms that implement those requirements.
a number of different security related terms, if they are unknown to This cannot be a complete survey, since new security mechanisms are
the reader, please consult the "Internet Security Glossary, Version defined regularly. The goal is to help applications designer by
2" [RFC4949]. giving reviewing the types of solution that are available. This
section will use a number of different security related terms,
Part of this discussion will be indication of known deployments or at described in the Internet Security Glossary, Version 2 [RFC4949].
least requirements in specification to support particular security
solutions. This will most certainly not be a complete picture and
also become obsolete as time progress since the time of writing this
document. The goal with including such information is to help the
designer, given multiple potential solutions that meets the security
design goals one can consider values such as interoperability,
maturity of implementations or experiences with solution components.
3.1. Secure RTP 3.1. Secure RTP
The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly
used mechanisms to provide confidentiality, integrity protection, used mechanisms to provide confidentiality, integrity protection,
source authentication and replay protection for RTP. SRTP was source authentication and replay protection for RTP. SRTP was
developed with RTP header compression and third party monitors in developed with RTP header compression and third party monitors in
mind. Thus the RTP header is not encrypted in RTP data packets, and mind. Thus the RTP header is not encrypted in RTP data packets, and
the first 8 bytes of the first RTCP packet header in each compound the first 8 bytes of the first RTCP packet header in each compound
RTCP packet are not encrypted. The entirety of RTP packets and RTCP packet are not encrypted. The entirety of RTP packets and
compound RTCP packets are integrity protected. This allows RTP compound RTCP packets are integrity protected. This allows RTP
header compression to work, and lets third party monitors determine header compression to work, and lets third party monitors determine
what RTP traffic flows exist based on the SSRC fields, but protects what RTP traffic flows exist based on the SSRC fields, but protects
the sensitive content. the sensitive content.
The source authentication guarantees provided by SRTP are highly The source authentication guarantees provided by SRTP depend on the
dependent on the cryptographic transform and key-management scheme cryptographic transform and key-management used. Some transforms,
used. In some cases all a receiver can determine is whether the e.g., those using TESLA [RFC4383], give strong source authentication
packets come from someone in the group security context, and not what even in multiparty sessions; others give weaker guarantees and can
group member send the packets. Thus, the source authentication authenticate group membership by not sources.
guarantees depend also on the session topology. Some cryptographic
transform have stronger authentication properties which can guarantee
a given source, even over a multi-party session, e.g. those based on
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-SHA-1 using 80- or 32-bits
authentication tags are the default cryptographic transform which authentication tags. This is the default cryptographic transform
need to be supported. Defined in SRTP [RFC3711]. that needs to be supported. Defined in SRTP [RFC3711].
AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128 bits keys AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128-bits keys
combined with keyed HMAC-SHA1 using 80 or 32 bits authentication. combined with keyed HMAC-SHA-1 using 80- or 32-bit authentication.
Defined in SRTP [RFC3711]. Defined in SRTP [RFC3711].
TESLA: As a complement to the regular symmetric keyed authentication TESLA: As a complement to the regular symmetric keyed authentication
transforms, like HMAC-SHA1. The TESLA based authentication scheme transforms, like HMAC-SHA-1. The TESLA based authentication
can provide per-source authentication in some group communication scheme can provide per-source authentication in some group
scenarios. The downside is need for buffering the packets for a communication scenarios. The downside is need for buffering the
while before authenticity can be verified. The TESLA transform packets for a while before authenticity can be verified. The
for SRTP is defined in [RFC4383]. TESLA transform for SRTP is defined in [RFC4383].
SEED: An Korean national standard cryptographic transform that is SEED: A Korean national standard cryptographic transform that is
defined to be used with SRTP in [RFC5669]. It has three modes, defined to be used with SRTP in [RFC5669]. It has three modes,
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: A 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- bit keys. It also has three modes,
Counter mode where combined with HMAC-SHA1 with 80 or 32 bits Counter mode where combined with HMAC-SHA-1 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 systems.
AES-192 and AES-256: cryptographic transforms for SRTP based on AES-192 and AES-256: cryptographic transforms for SRTP based on
AES-192 and AES-256 counter mode encryption and 160-bit keyed AES-192 and AES-256 counter mode encryption and 160-bit keyed
HMAC-SHA1 with 80 and 32 bits authentication tags for HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus
authentication. Thus providing 192 and 256 bits encryption keys providing 192 and 256 bits encryption keys and NSA Suite B
and NSA Suite B included cryptographic transforms. Defined in included cryptographic transforms. Defined in [RFC6188].
[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 normally carried in the clear and only
integrity protected in SRTP. This can be problematic in some cases, integrity protected in SRTP. This can be problematic in some cases,
so [RFC6904] defines an extension to also encrypt selected header so [RFC6904] defines an extension to also encrypt selected header
extensions. extensions.
SRTP is specified and deployed in a number of RTP usage contexts; SRTP is specified and deployed in a number of RTP usage contexts;
Significant support in SIP established VoIP clients including IMS; Significant support in SIP-established VoIP clients including IMS;
RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming.
Thus SRTP in general is widely deployed. When it comes to Thus SRTP in general is widely deployed. When it comes to
cryptographic transforms the default (AES CM and HMAC-SHA1) is the cryptographic transforms the default (AES CM and HMAC-SHA-1) is the
most common used. 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, enabling perfect forward secrecy and exchange between two peers, enabling perfect forward secrecy and
binding strong identity verification to an end-point. The default binding strong identity verification to an end-point. The default
key generation will generate a key that contains material contributed key generation will generate a key that contains material contributed
by both peers. The key-exchange happens in the media plane directly by both peers. The key-exchange happens in the media plane directly
between the peers. The common key-exchange procedures will take two between the peers. The common key-exchange procedures will take two
round trips assuming no losses. TLS resumption can be used when round trips assuming no losses. TLS resumption can be used when
establishing additional media streams with the same peer, used establishing additional media streams with the same peer, and reduces
reducing the set-up time to one RTT. the set-up time to one RTT for these streams (see [RFC5764] for a
discussion of TLS resumption in this context).
The actual security properties of an established SRTP session using The actual security properties of an established SRTP session using
DTLS will depend on the cipher suits offered and used. For example DTLS will depend on the cipher suits offered and used. For example
some provides perfect forward secrecy (PFS), while other do not. some provide perfect forward secrecy (PFS), while other do not. When
When using DTLS the application designer needs to select which cipher using DTLS, the application designer needs to select which cipher
suits that DTLS-SRTP can offer and accept so that the desired suites DTLS-SRTP can offer and accept so that the desired security
security properties are achieved. 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 a DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Finally, to exchange hashes of each sides certificates to enable each Finally, to exchange hashes of each side's certificates to verify
side to verify that they have connected to the by signalling their identity, and ensure there is no man-in-the-middle attack.
indicated port and not a man in the middle. That way enabling some That way enabling some binding between the key-exchange and the
binding between the key-exchange and the signalling. This usage is signalling. This usage is well defined for SIP/SDP in [RFC5763], and
well defined for SIP/SDP in [RFC5763], and in most cases can be in most cases can be adopted for use with other bi-directions
adopted for use with other bi-directions signalling solutions. signalling solutions.
DTLS-SRTP usage and inclusion in specification are clearly on the DTLS-SRTP usage is clearly on the rise. It is mandatory to support
rise. It is mandatory to support in WebRTC. It has a growing in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
support among SIP end-points, which is good considering that DTLS- was developed in IETF primarily to meet security requirements for
SRTP was primarily developed in IETF to meet security requirements SIP.
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 useable in scenarios where one
where one entity generates the key and needs to distribute the key to entity generates the key and needs to distribute the key to a number
a number of participants. The different modes and the resulting of participants. The different modes and the resulting properties
properties are highly dependent on the cryptographic method used to are highly dependent on the cryptographic method used to establish
establish the Traffic Generation Key (TGK) that is used to derive the the Traffic Generation Key (TGK) that is used to derive the keys
keys actually used by the security protocol, like SRTP. actually used by the security protocol, like SRTP.
MIKEY has the following modes of operation: MIKEY has the following modes of operation:
Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto
used to secure a keying message carrying the already generated used to secure a keying message carrying the already generated
TGK. This system is the most efficient from the perspective of TGK. This system is the most efficient from the perspective of
having small messages and processing demands. The downside is having small messages and processing demands. The downside is
scalability, where usually the effort for the provisioning of pre- scalability, where usually the effort for the provisioning of pre-
shared keys is only manageable, if the number of endpoints is shared keys is only manageable if the number of endpoints is
small. 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 intensive 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 high
increased resource consumption in bandwidth and processing. This resource consumption in bandwidth and processing during the MIKEY
method can't be used to establish group keys as each pair of peers exchange. This method can't be used to establish group keys as
performing the MIKEY exchange will establish different keys. each pair of peers performing the MIKEY exchange will establish
different keys.
HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of
the Diffie-Hellman exchange that uses a pre-shared key in a keyed the Diffie-Hellman exchange that uses a pre-shared key in a keyed
HMAC to verify authenticity of the keying material instead of a HMAC to verify authenticity of the keying material instead of a
digital signature as in the previous method. This method is still digital signature as in the previous method. This method is still
restricted to point-to-point usage. restricted to point-to-point usage.
RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the
public key method which doesn't rely on the initiator of the key- public key method which doesn't rely on the initiator of the key-
exchange knowing the responders certificate. This methods lets exchange knowing the responder's certificate. This method lets
both the initiator and the responder to specify the TGK material both the initiator and the responder 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) infrastructure IBAKE: [RFC6267] uses a key management services (KMS) infrastructure
but with lower demand on the KMS. Claims to provides both perfect but with lower demand on the KMS. Claims to provides both perfect
forward and backwards secrecy, the exact meaning is unclear (See forward and backwards secrecy, the exact meaning is unclear (See
Perfect Forward Secrecy in [RFC4949]). Perfect Forward Secrecy in [RFC4949]).
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY.
Based on Identity based Public Key Cryptography and a KMS Based on Identity based Public Key Cryptography and a KMS
infrastructure to establish a shared secret value and certificate infrastructure to establish a shared secret value and certificate
less signatures to provide source authentication. It features less signatures to provide source authentication. It's features
include simplex transmission, scalability, low-latency call set- include simplex transmission, scalability, low-latency call set-
up, and support for secure deferred delivery. up, and support for secure deferred delivery.
MIKEY messages has several different defined transports. [RFC4567] MIKEY messages have several different transports. [RFC4567] defines
defines how MIKEY messages can be embedded in general SDP for usage how MIKEY messages can be embedded in general SDP for usage with the
with the signalling protocols SIP, SAP and RTSP. There also exist an signalling protocols SIP, SAP and RTSP. There also exist a 3GPP
3GPP defined usage of MIKEY that sends MIKEY messages directly over defined usage of MIKEY that sends MIKEY messages directly over UDP to
UDP to key the receivers of Multimedia Broadcast and Multicast key the receivers of Multimedia Broadcast and Multicast Service
Service (MBMS) [T3GPP.33.246]. (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]. 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 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 RSA-R mode. There are some SIP end-points that support MIKEY. The
which mode they use are unknown by the authors. modes they use are unknown to the authors.
3.1.3. Key Management for SRTP: Security Descriptions 3.1.3. Key Management for SRTP: Security Descriptions
[RFC4568] provides a keying solution based on sending plain text keys [RFC4568] provides a keying solution based on sending plain text keys
in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/ in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/
Answer, and is well-defined in point to point sessions where each Answer model, and is well-defined in point-to-point sessions where
side declares its own unique key. Using Security Descriptions to each side declares its own unique key. Using Security Descriptions
establish group keys is less well defined, and can have security to establish group keys is less well defined, and can have security
issues as the SSRC uniqueness property can't be guaranteed. issues since it's difficult to guarantee unique SSRCs (as needed to
avoid a "two-time pad" attack - see Section 9 of [RFC3711]).
Since keys are transported in plain text in SDP, they can easily be Since keys are transported in 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
common use of security descriptions with SIP, where instead hop by normally the case, where instead hop-by-hop security is provided
hop security is provided between signalling nodes using TLS. This between signalling nodes using TLS. This leaves the keying material
still leaves the keying material sensitive to capture by the sensitive to capture by the traversed signalling nodes. Thus, in
traversed signalling nodes. Thus in most cases the security most cases, the security properties of security descriptions are
properties of security descriptions are weak. The usage of security weak. The usage of security descriptions usually requires additional
descriptions usually requires additional security measures, e.g. the security measures, e.g. the signalling nodes be trusted and
signalling nodes be trusted and protected by strict access control. protected by strict access control. Usage of security descriptions
Usage of security descriptions requires careful design in order to requires careful design in order to ensure that the security goals
ensure that the security goals can be met. can be met.
Security Descriptions is the most commonly deployed keying solution Security Descriptions is the most commonly deployed keying solution
for SIP-based end-points, where almost all that supports SRTP also for SIP-based end-points, where almost all end-points that support
supports Security Descriptions. SRTP also support 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 like DTLS-SRTP that doesn't support group keys. 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 end-
end-points connect to a conference bridge or a gateway, and need to points connect to a conference bridge or a gateway, and need to be
be provisioned with the keys each participant on the bridge or provisioned with the keys each participant on the bridge or gateway
gateway uses to avoid decryption encryption cycles on the bridge or uses to avoid decryption and encryption cycles on the bridge or
gateway. This can enable interworking between DTLS-SRTP and for gateway. This can enable interworking between DTLS-SRTP and for
example security descriptions or other keying systems where either example security descriptions or other keying systems where either
part can set the key. 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 is only sent occasionally or
periodically depending on use cases depending on what requirements periodically depending on use cases and depending on what
exist for timely delivery or notification on when the key is needed requirements exist for timely delivery or notification.
by someone.
The only known deployment of EKT so far are in some Cisco Video The only known deployment of EKT so far are in some Cisco video
Conferencing products. conferencing products.
3.1.5. Key Management for SRTP: Other systems 3.1.5. Key Management for SRTP: Other systems
The ZRTP [RFC6189] key-management system for SRTP was proposed as an The ZRTP [RFC6189] key-management system for SRTP was proposed as an
alternative to DTLS-SRTP. It wasn't adopted as an IETF standards alternative to DTLS-SRTP. It wasn't adopted as an IETF standards
track protocol, but was instead published as an informational RFC. track protocol, but was instead published as an informational RFC.
Commercial implementations exist.
Additional proprietary solutions are also known to exist. Additional proprietary solutions are also known to exist.
3.2. RTP Legacy Confidentiality 3.2. RTP Legacy Confidentiality
Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based Section 9 of the RTP standard [RFC3550] defines a 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 can provide confidentiality but, as discussed in Section 9 of
properties and is not to be used. [RFC3550], it has extremely weak security properties and is not to be
used.
3.3. IPsec 3.3. IPsec
IPsec [RFC4301] can be used independent of mode to protect RTP and IPsec [RFC4301] can be used in either tunnel or transport mode to
RTCP packets in transit from one network interface to another. This protect RTP and RTCP packets in transit from one network interface to
can be sufficient when the network interfaces have a direct relation, another. This can be sufficient when the network interfaces have a
or in a secured environment where it can be controlled who can read direct relation, or in a secured environment where it can be
the packets from those interfaces. controlled who can read the packets from those interfaces.
The main concern with using IPsec to protect RTP traffic is that in The main concern with using IPsec to protect RTP traffic is that in
most cases using a VPN approach that terminates the security most cases using a VPN approach that terminates the security
association at some node prior to the RTP end-point leaves the association at some node prior to the RTP end-point leaves the
traffic vulnerable to attack between the VPN termination node and the traffic vulnerable to attack between the VPN termination node and the
end-point. Thus usage of IPsec requires careful thought and design end-point. Thus usage of IPsec requires careful thought and design
of its usage so that it really meets the security goals. A important of its usage so that it meets the security goals. A important
question is how one ensure the IPsec terminating peer and the question is how one ensures the IPsec terminating peer and the
ultimate destination is the same. ultimate destination are the same.
IPsec with RTP is more commonly used as security solution between IPsec with RTP is more commonly used as a security solution between
central nodes in an infrastructure that exchanges many RTP sessions infrastructure nodes that exchange many RTP sessions and media
and media streams between the peers. The establishment of a secure streams. The establishment of a secure tunnel between such nodes
tunnel between these peers minimizes the key-management overhead minimizes the key-management overhead.
between these two boxes.
3.4. DTLS 3.4. DTLS for RTP and RTCP
Datagram Transport Layer Security (DTLS) [RFC6347] can provide point Datagram Transport Layer Security (DTLS) [RFC6347] can provide point-
to point security for RTP flows. The two peers would establish an to-point security for RTP flows. The two peers establish an DTLS
DTLS association between each other, including the possibility to do association between each other, including the possibility to do
certificate-based source authentication when establishing the certificate-based source authentication when establishing the
association. All RTP and RTCP packets flowing will be protected by association. All RTP and RTCP packets flowing will be protected by
this DTLS association. this DTLS association.
Note: using DTLS is different to using DTLS-SRTP key management. Note that using DTLS for RTP flows is different to using DTLS-SRTP
DTLS-SRTP has the core key-management steps in common with DTLS, but key management. DTLS-SRTP uses the same key-management steps as
DTLS-SRTP uses SRTP for the per packet security operations, while DTLS, but uses SRTP for the per packet security operations. Using
DTLS uses the normal datagram TLS data protection. When using DTLS, DTLS for RTP flows uses the normal datagram TLS data protection,
wrapping complete RTP packets. When using DTLS for RTP flows, the
RTP and RTCP packets are completely encrypted with no headers in the RTP and RTCP packets are completely encrypted with no headers in the
clear, while DTLS-SRTP leaves the headers in the clear. clear; when using DTLS-SRTP, the RTP headers are in the clear and
only the payload data is encrypted.
DTLS can use similar techniques to those available for DTLS-SRTP to DTLS can use similar techniques to those available for DTLS-SRTP to
bind a signalling side agreement to communicate to the certificates bind a signalling-side agreement to communicate to the certificates
used by the end-point when doing the DTLS handshake. This enables used by the end-point when doing the DTLS handshake. This enables
use without having a certificate based trust chain to a trusted use without having a certificate-based trust chain to a trusted
certificate root. certificate root.
There appear to be no significant usage of RTP over DTLS. There does not appear to be 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 the 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 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 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 are sent over. It appears that RTP over TLS/TCP is also used in some
proprietary solutions that uses TLS to bypass firewalls. 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 by RTSP streaming servers has
streaming servers has the media content in a protected format that the media content in a protected format that cannot be read by the
cannot be read by the streaming server (this is mostly done in the streaming server (this is mostly done in the context of Digital
context of Digital Rights Management). These approaches then uses a Rights Management). These approaches then use a key-management
key-management solution between the rights provider and the consuming solution between the rights provider and the consuming client to
client to deliver the key used to protect the content, usually after deliver the key used to protect the content and do not include the
the appropriate method for charging has happened, and do not include media server in the security context. Such methods have several
the media server in the security context. Such methods have several
security weaknesses such the fact that the same key is handed out to security weaknesses such the fact that the same key is handed out to
a potentially large group of receiving clients, increasing the risk a potentially large group of receiving clients, increasing the risk
of a leak. of a leak.
Use of this type of solution can be of interest in environments that Use of this type of solution can be of interest in environments that
allow middleboxes to rewrite the RTP headers and select what streams allow middleboxes to rewrite the RTP headers and select which streams
that are delivered to an end-point (e.g., some types of centralised are delivered to an end-point (e.g., some types of centralised video
video conference systems). The advantage of encrypting and possibly conference systems). The advantage of encrypting and possibly
integrity protecting the payload but not the headers is that the integrity protecting the payload but not the headers is that the
middlebox can't eavesdrop on the media content, but can still provide middlebox can't eavesdrop on the media content, but can still provide
stream switching functionality. The downside of such a system is stream switching functionality. The downside of such a system is
that it likely needs two levels of security: the payload level that it likely needs two levels of security: the payload level
solution to provide confidentiality and source authentication, and a solution to provide confidentiality and source authentication, and a
second layer with additional transport security ensuring source second layer with additional transport security ensuring source
authentication and integrity of the RTP headers associated with the authentication and integrity of the RTP headers associated with the
encrypted payloads. This can also results in the need to have two encrypted payloads. This can also results in the need to have two
different key-management systems as the entity protecting the packets different key-management systems as the entity protecting the packets
and payloads are different with different set of keys. and payloads are different with different set of keys.
skipping to change at page 18, line 4 skipping to change at page 17, line 51
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. National or other regulations might provided to remain confidential. National or other regulations might
additional requirements on a particular usage of an RTP. From provided additional requirements on a particular usage of an RTP.
that, one can determine what encryption algorithms are to be used From that, one can determine which encryption algorithms are to be
from the set of available transforms. used from the set of available transforms.
Potential for other leakage: RTP based security in most of its forms Potential for other leakage: RTP based security in most of its forms
simply wraps RTP and RTCP packets into cryptographic containers. simply wraps RTP and RTCP packets into cryptographic containers.
This commonly means that the size of the original RTP payload, and This commonly means that the size of the original RTP payload is
details of the RTP and RTCP headers, are visible to observers of visible to observers of the protected packet flow. This can
the protected packet flow. This can provide information to those provide information to those observers. A well-documented case is
observers. A well documented case is the risk with variable bit- the risk with variable bit-rate speech codecs that produce
rate speech codecs that produce different sized packets based on different sized packets based on the speech input [RFC6562].
the speech input [RFC6562]. Potential threats such as these need Potential threats such as these need to be considered and, if they
to be considered and, if they are significant, then restrictions are significant, then restrictions will be needed on mode choices
will be needed on mode choices in the codec, or additional padding in the codec, or additional padding will need to be added to make
will need to be added to make all packets equal size and remove all packets equal size and remove the informational leakage.
the informational leakage.
Another case is RTP header extensions. If SRTP is used, header Another case is RTP header extensions. If SRTP is used, header
extensions are normally not protected by the security mechanism extensions are normally not protected by the security mechanism
protecting the RTP payload. If the header extension carries protecting the RTP payload. If the header extension carries
information that is considered sensitive, then the application information that is considered sensitive, then the application
needs to be modified to ensure that mechanisms used to protect needs to be modified to ensure that mechanisms used to protect
against such information leakage are employed. against such information leakage are employed.
Who has access: When considering the confidentiality properties of a Who has access: When considering the confidentiality properties of a
system, it is important to consider where the media handled in the system, it is important to consider where the media handled in the
clear. For example, if the system is based on an RTP mixer that clear. For example, if the system is based on an RTP mixer that
needs the keys to decrypt the media, process, and repacketize it, needs the keys to decrypt the media, process, and repacketize it,
then is the mixer providing the security guarantees expected by then is the mixer providing the security guarantees expected by
the other parts of the system? Furthermore, it is important to the other parts of the system? Furthermore, it is important to
consider who has access to the keys, and are the keys stored or consider who has access to the keys. The policies for the
kept somewhere? The policies for the handling of the keys, and handling of the keys, and who can access the keys, need to be
who can access the keys, need to be considered along with the considered along with the confidentiality goals.
confidentiality goals.
As can be seen the actual confidentiality level has likely more to do As can be seen the actual confidentiality level has likely more to do
with the application's usage of centralized nodes, and the details of with the application's usage of centralized nodes, and the details of
the key-management solution chosen, than with the actual choice of the key-management solution chosen, than with the actual choice of
encryption algorithm (although, of course, the encryption algorithm encryption algorithm (although, of course, the encryption algorithm
needs to be chosen appropriately for the desired security level). needs to be chosen appropriately for the desired security level).
4.1.2. Integrity 4.1.2. Integrity
Protection against modification of content by a third party, or due Protection against modification of content by a third party, or due
to errors in the network, is another factor to consider. The first to errors in the network, is another factor to consider. The first
aspect that one consider is what resilience one has against aspect that one considers is what resilience one has against
modifications to the content. This can affect what cryptographic modifications to the content. This can affect what cryptographic
algorithm is used, and the length of the integrity tags. However algorithm is used, and the length of the integrity tags. However
equally, important is to consider who is providing the integrity equally, important is to consider who is providing the integrity
assertion, what is the source of the integrity tag, and what are the assertion, what is the source of the integrity tag, and what are the
risks of modifications happening prior to that point where protection risks of modifications happening prior to that point where protection
is applied? RTP applications that rely on central nodes need to is applied? RTP applications that rely on central nodes need to
consider if hop-by-hop integrity is acceptable, or if true end-to-end consider if hop-by-hop integrity is acceptable, or if true end-to-end
integrity protection is needed? Is it important to be able to tell integrity protection is needed? Is it important to be able to tell
if a middlebox has modified the data? There are some uses of RTP if a middlebox has modified the data? There are some uses of RTP
that require trusted middleboxes that can modify the data in a way that require trusted middleboxes that can modify the data in a way
skipping to change at page 19, line 29 skipping to change at page 19, line 26
Integrity of the data is commonly closely tied to the question of Integrity of the data is commonly closely tied to the question of
source authentication. That is, it becomes important to know who source authentication. That is, it becomes important to know who
makes an integrity assertion for the data. makes an integrity assertion for the data.
4.1.3. Source Authentication 4.1.3. Source Authentication
Source authentication is about determining who sent a particular RTP Source authentication is about determining who sent a particular RTP
or RTCP packet. It is normally closely tied with integrity, since or RTCP packet. It is normally closely tied with integrity, since
you also want to ensure that what you received is what the claimed you also want to ensure that what you received is what the claimed
source really sent, so source authentication without integrity is not source really sent, so source authentication without integrity is not
particularly useful. In similar way, although not as definitive, is particularly useful. Similarly, integrity without source
that integrity without source authentication is also not particular authentication is also not particular useful; you need to know who
useful: you need to know who claims this packet wasn't changed. 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 to assert a source accept the packet as valid, it is possible to assert a source-
authenticated statement; this message is highly probably from authenticated statement; this message is likely from someone that
someone that has the cryptographic key(s) to this communication. has the cryptographic key(s) to this communication.
What that assertion actually means is highly dependent on the What that assertion actually means is highly dependent on the
application, and how it handles the keys. In an application where application and how it handles the keys. If only the two peers
the key-handling is limited to two peers, this can form a basis have access to the keys, this can form a basis for a strong trust
for a trust relationship to the level that you can state as the relationship that traffic is authenticated coming from one of the
traffic is authenticated and matching this particular context. peers. However, in a multi-party scenario where security contexts
Thus, it is coming either from me or from my peer (and I trust are shared among participants, most base-level authentication
that neither has shared the key with anyone else). However, in a solutions can't even assert that this packet is from the same
multi-party scenario where security contexts are shared among source as the previous packet.
participants, most base-level authentication solutions can't even
assert that this packet is from the same source as the previous
packet.
Binding the Source: A step up in the assertion that can be done in 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 at least be able to assert that the sender of
of the packets is the same entity that I have established the the packets is the same entity that I have established the session
session with. How feasible this is depends on the properties of with. How feasible this is depends on the properties of the key-
the key-management system used, the ability to tie the signalling management system used, the ability to tie the signalling to a
to a particular peer, and what trust you place on the different particular peer, and what trust you place on the different nodes
nodes involved. 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, uses 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 are not bound to any PKI they can't be verified.
Instead, hashes over the certificate are sent over the signalling Instead, hashes of 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 established keys then the end-points can verify that they have established keys
with the peer they are doing signalling with. with the peer they are doing signalling with.
Systems where the key-exchange are done using the signalling Systems where the key-exchange is done using the signalling
systems, such as Security Descriptions [RFC4568] or MIKEY embedded systems, such as Security Descriptions [RFC4568] or MIKEY embedded
in SDP [RFC4567], enables an direct binding between signalling and in SDP [RFC4567], enable a direct binding between signalling and
key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual
security depends on the trust one can place in the signalling security depends on the trust one can place in the signalling
system to correctly associate the peer's identity with the key- system to correctly associate the peer's identity with the key-
exchange. 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. If the signalling can assert that only a
a particular identity in a multi-party communication session where given entity in a multiparty session has a key, then the media
the key-management systems establish keys in a way that one can layer might be able to provide guarantees about the identity of
assert that only the given identity has gotten the key. Using a the media sender. However, using an signalling authentication
authentication mechanism built on a group key that otherwise can't mechanism built on a group key can limit the media layer to
provide any assertion who sent the traffic than anyone that got asserting only group membership.
the key, provides no strong assertion on the media level than:
Someone that has gotten the security context (key) sent this
traffic.
4.1.4. Identity 4.1.4. Identity
There exist many different types of identity systems with different There exist many different types of identity systems with different
properties. But in the context of RTP applications the most properties. But in the context of RTP applications, the most
important property is the possibility to perform source important property is the possibility to perform source
authentication and verify such assertions in relation to any claimed authentication and verify such assertions in relation to any claimed
identities. What an identity really are can also vary, but in the identities. What an identity really is can also vary but, in the
context of communication, one of the most obvious is the identity of context of communication, one of the most obvious is the identity of
the human user one communicates with. However, the human user can the human user one communicates with. However, the human user can
also have additional identities in a particular role. For example, also have additional identities in a particular role. For example,
the human Alice, can also be a police officer and in some cases her 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 identity as police officer will be more relevant then that she is
Alice. This is common in contact with organizations, where it is Alice. This is common in contact with organizations, where it is
important to prove the persons right to represent the organization. important to prove the persons right to represent the organization.
Some examples of identity mechanisms that could be used: Some examples of identity mechanisms that can be used:
Certificate based: A certificate is used to prove the identity, by Certificate based: A certificate is used to prove the identity, by
having access to the private part of the certificate one can having access to the private part of the certificate one can
perform signing to assert ones identity. Any entity interested in perform signing to assert ones identity. Any entity interested in
verifying the assertion then needs the public part of the verifying the assertion then needs the public part of the
certificate. By having the certificate one can verify the signing certificate. By having the certificate, one can verify the
against the certificate. The next step is to determine if one signature against the certificate. The next step is to determine
trusts the certificate's trust chain. Commonly by provisioning if one trusts the certificate's trust chain. Commonly by
the verifier with the public part of a root certificate, this provisioning the verifier with the public part of a root
enables the verifier to verify a trust chain from the root certificate, this enables the verifier to verify a trust chain
certificate down to the identity certificate. However, the trust from the root certificate down to the identity certificate.
is based on that all steps in the certificate chain are verifiable However, the trust is based on all steps in the certificate chain
and can be trusted. Thus provisioning of root certificates, being verifiable and trusted. Thus provisioning of root
having possibility to revoke compromised certificates are aspects certificates and the ability to revoke compromised certificates
that will require infrastructure. are aspects that will require infrastructure.
Online Identity Providers: An online identity provider (IdP) can Online Identity Providers: An online identity provider (IdP) can
authenticate a user's right to use an identity, then perform authenticate a user's right to use an identity, then perform
assertions on their behalf or provision the requester with short- assertions on their behalf or provision the requester with short-
term credentials to assert their identity. The verifier can then term credentials to assert their identity. The verifier can then
contact the IdP to request verification of a particular identity. contact the IdP to request verification of a particular identity.
Here the trust is highly dependent on how much one trusts the IdP. Here the trust is highly dependent on how much one trusts the IdP.
The system also becomes dependent on having access to the relevant The system also becomes dependent on having access to the relevant
IdP. IdP.
skipping to change at page 23, line 4 skipping to change at page 22, line 36
signalling also impacts what information can be provided, and if this signalling also impacts what information can be provided, and if this
can be instance specific, or common for a group. In the end the key- can be instance specific, or common for a group. In the end the key-
management system will highly affect the security properties achieved management system will highly affect the security properties achieved
by the application. At the same time, the communication structure of by the application. At the same time, the communication structure of
the application limits what key management methods are applicable. the application limits what key management methods are applicable.
As different key-management have different requirements on underlying As different key-management have different requirements on underlying
infrastructure it is important to take that aspect into consideration infrastructure it is important to take that aspect into consideration
early in the design. early in the design.
4.3. Interoperability 4.3. Interoperability
Few RTP applications exist as independent applications that never Few RTP applications exist as independent applications that never
interoperate with anything else. Rather, they enable communication interoperate with anything else. Rather, they enable communication
with a potentially large number of other systems. To minimize the with a potentially large number of other systems. To minimize the
number of security mechanisms that need to be implemented, it is number of security mechanisms that need to be implemented, it is
important to consider if one can use the same security mechanisms as important to consider if one can use the same security mechanisms as
other applications. This can also reduce the problems of determining other applications. This can also reduce problems of determining
what security level is actually negotiated in a particular session. what security level is actually negotiated in a particular session.
The desire to be interoperable can in some cases be in conflict with The desire to be interoperable can, in some cases, be in conflict
the security requirements determined for an application. To meet the with the security requirements of an application. To meet the
security goals, it might be necessary to sacrifice interoperability. security goals, it might be necessary to sacrifice interoperability.
Alternatively, one can implement multiple security mechanisms, but Alternatively, one can implement multiple security mechanisms, this
then end up with an issue of ensuring that the user understands what however introduces the complication of ensuring that the user
it means to use a particular security level. In addition, the understands what it means to use a particular security system. In
application can then become vulnerable to bid-down attack. addition, the application can then become vulnerable to bid-down
attack.
5. Examples 5. Examples
In the following we describe a number of example security solutions In the following we describe a number of example security solutions
for RTP using applications, services or frameworks. These examples for applications using RTP services or frameworks. These examples
are provided to show the choices that can be made. They are not are provided to illustrate the choices available. They are not
normative recommendations for security. normative recommendations for security.
5.1. Media Security for SIP-established Sessions using DTLS-SRTP 5.1. Media Security for SIP-established Sessions using DTLS-SRTP
The IETF evaluated media security for RTP sessions established using The IETF evaluated media security for RTP sessions established using
point-to-point SIP sessions in 2009. A number of requirements were point-to-point SIP sessions in 2009. A number of requirements were
determined, and based on those, the existing solutions for media determined, and based on those, the existing solutions for media
security and especially the keying methods were analysed, and the security and especially the keying methods were analysed. The
resulting requirements and analysis were published in [RFC5479]. resulting requirements and analysis were published in [RFC5479].
Based on this analysis, and the working group discussion, DTLS-SRTP Based on this analysis and working group discussion, DTLS-SRTP was
was determined to be the best solution, and the specifications were determined to be the best solution.
finalized.
The security solution for SIP using DTLS-SRTP is defined in the The security solution for SIP using DTLS-SRTP is defined in the
Framework for Establishing a Secure Real-time Transport Protocol Framework for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer Security (SRTP) Security Context Using Datagram Transport Layer Security
(DTLS) [RFC5763]. On a high level it uses SIP with SDP offer/answer (DTLS) [RFC5763]. On a high level the framework uses SIP with SDP
procedures to exchange the network addresses where the server end- offer/answer procedures to exchange the network addresses where the
point will have a DTLS-SRTP enable server running. The SIP server end-point will have a DTLS-SRTP enable server running. The
signalling is also used to exchange the fingerprints of the SIP signalling is also used to exchange the fingerprints of the
certificate each end-point will use in the DTLS establishment certificate each end-point will use in the DTLS establishment
process. When the signalling is sufficiently completed the DTLS-SRTP process. When the signalling is sufficiently completed, the DTLS-
client performs DTLS handshakes and establishes SRTP session keys. SRTP client performs DTLS handshakes and establishes SRTP session
The clients also verify the fingerprints of the certificates to keys. The clients also verify the fingerprints of the certificates
verify that no man in the middle has inserted themselves into the to 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 exists 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]. This reduces the number of nodes the connecting user
User Agent has to trust to the first hop proxy, rather than the full User Agent has to trust to include just the first hop proxy, rather
signalling path. than the full 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 a solution
providing web-application with real-time media directly between providing web applications 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 default keying of SRTP is mandatory application of SRTP. The default keying of SRTP is done
done using DTLS-SRTP. The security configuration is further defined using DTLS-SRTP. The security configuration is further defined in
in the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. 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) from inserting itself in the key-exchange.
The web application still have the possibility to insert a MITM. Unless one uses a Identity provider and the proposed identity
That unless one uses a Identity provider and the proposed identity solution [I-D.ietf-rtcweb-security-arch], the web application still
solution [I-D.ietf-rtcweb-security-arch]. In this solution the has the possibility to insert a MITM. In this solution the Identity
Identity Provider which is a third party to the web-application signs Provider which is a third party to the web application signs the
the DTLS-SRTP hash combined with a statement on which user identity DTLS-SRTP hash combined with a statement on which user identity that
that has been used to sign the hash. The receiver of such a Identity 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. This 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 a MITM and acquire the keys to the
keys to the media communication. media communication.
In the development of WebRTC there has also been high attention on In the development of WebRTC there has also been attention given to
privacy question. The main concerns that has been raised and are at privacy considerations. The main RTP-related concerns that have been
all related to RTP are: raised are:
Location Disclosure: As ICE negotiation provides IP addresses and Location Disclosure: As ICE negotiation [RFC5245] provides IP
ports for the browser, this leaks location information in the addresses and ports for the browser, this leaks location
signalling to the peer. To prevent this one can block the usage information in the signalling to the peer. To prevent this one
of any ICE candidate that isn't a relay candidate, i.e. where the can block the usage of any ICE candidate that isn't a relay
IP and port provided belong to the service providers media traffic candidate, i.e. where the IP and port provided belong to the
relay. service providers media traffic 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 provide information that could possibly be re-used
session instances. Thus to prevent tracking the same information between session instances. Thus to prevent tracking, the same
can't be re-used between different communication sessions. information 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 from other
parties than the web service. parties, not on providing privacy from the web server that provides
the WebRTC Javascript application.
5.3. 3GPP Packet Based Streaming Service (PSS) 5.3. 3GPP Packet Based Streaming Service (PSS)
The 3GPP Release 11 PSS specification of the Packet Based Streaming The 3GPP Release 11 PSS specification of the Packet Based Streaming
Service (PSS) [T3GPP.26.234R11] defines in Annex R a set of security Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of
mechanisms. These security mechanisms are centred around protecting security mechanisms. These security mechanisms are concerned with
the content from being captured, i.e. Digital Rights Management. If protecting the content from being captured, i.e. Digital Rights
these goals are to be meet with the specified solution there needs to Management. If these goals are to be meet with the specified
exist trust in that neither the implementation of the client nor the solution there needs to exist trust in that neither the
platform the application runs can be accessed or modified by the implementation of the client nor the platform the application runs
attacker. can be accessed or modified by the attacker.
PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus
an RTSP client whose user wants to access a protected content will an RTSP client whose user wants to access a protected content will
request a session description (SDP [RFC4566]) for the protected request a session description (SDP [RFC4566]) for the protected
content. This SDP will indicate that the media are ISMA Crypt 2.0 content. This SDP will indicate that the media is ISMA Crypt 2.0
[ISMACrypt2] protected media encoding application units (AUs). The [ISMACrypt2] protected media encoding application units (AUs). The
key(s) used to protect the media are provided in either of two ways. key(s) used to protect the media are provided in either of two ways.
If a single key is used then the client uses some DRM system to If a single key is used then the client uses some DRM system to
retrieve the key as indicated in the SDP. Commonly OMA DRM v2 retrieve the key as indicated in the SDP. Commonly OMA DRM v2
[OMADRMv2] will be used to retrieve the key. If multiple keys are to [OMADRMv2] will be used to retrieve the key. If multiple keys are to
be used, then using RTSP an additional stream for key-updates in be used, then an additional RTSP stream for key-updates in parallel
parallel with the media streams are established, where key updates with the media streams is established, where key updates are sent to
are sent to the client using Short Term Key Messages defined by the client using Short Term Key Messages defined in the "Service and
"Service and Content Protection for Mobile Broadcast Services" part Content Protection for Mobile Broadcast Services" section of the OMA
of the OMA Mobile Broadcast Services [OMABCAST]. Mobile Broadcast Services [OMABCAST].
Worth noting is that this solution doesn't provide any integrity Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header verification method for the RTP header and payload header
information, only the encoded media AU is protected. 3GPP has not information, only the encoded media AU is protected. 3GPP has not
defined any requirement for supporting SRTP or other solution that defined any requirement for supporting any solution that could
could provide that service. Thus, replay or insertion attacks are provide that service. Thus, replay or insertion attacks are
possible. Another property is that the media content can be possible. Another property is that the media content can be
protected by the ones providing the media, so that the operators of protected by the ones providing the media, so that the operators of
the RTSP server has no access to unprotected content. Instead all the RTSP server has no access to unprotected content. Instead all
that want to access the media is supposed to contact the DRM keying that want to access the media is supposed to contact the DRM keying
server and if the device is acceptable they will be given the key to server and if the device is acceptable they will be given the key to
decrypt the media. decrypt the media.
To protect the signalling RTSP 1.0 supports the usage of TLS, this is To protect the signalling, RTSP 1.0 supports the usage of TLS. This
however not explicitly discussed in the PSS specification. Usage of is, however, not explicitly discussed in the PSS specification.
TLS can prevent both modification of the session description Usage of TLS can prevent both modification of the session description
information and help maintain some privacy of what content the user information and help maintain some privacy of what content the user
is watching as all URLs would then be confidentiality protected. is watching as all URLs would then be confidentiality protected.
5.4. RTSP 2.0 5.4. RTSP 2.0
Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] can be Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] offers
an interesting comparison to the PSS service (Section 5.3) that is an interesting comparison to the PSS service (Section 5.3) that is
based on RTSP 1.0 and service requirements perceived by mobile based on RTSP 1.0 and service requirements perceived by mobile
operators. A major difference between RTSP 1.0 and RTSP 2.0 is that operators. A major difference between RTSP 1.0 and RTSP 2.0 is that
2.0 is fully defined under the requirement to have mandatory to 2.0 is fully defined under the requirement to have mandatory to
implement security mechanism. As it specifies how one transport implement security mechanism. As it specifies how one transport
media over RTP it is also defining security mechanisms for the RTP media over RTP it is also defining security mechanisms for the RTP
transported media streams. transported media streams.
The security goals for RTP in RTSP 2.0 is to ensure that there are The security goals for RTP in RTSP 2.0 is to ensure that there is
confidentiality, integrity and source authentication between the RTSP confidentiality, integrity and source authentication between the RTSP
server and the client. This to prevent eavesdropping on what the server and the client. This to prevent eavesdropping on what the
user is watching for privacy reasons and prevent replay or injection user is watching for privacy reasons and to prevent replay or
attacks on the media stream. To reach these goals also the injection attacks on the media stream. To reach these goals, the
signalling has to be protected, requiring the use of TLS between the signalling also has to be protected, requiring the use of TLS between
client and server. the client and server.
Using TLS protected signalling the client and server agrees on the Using TLS-protected signalling the client and server agree on the
media transport method when doing the SETUP request and response. media transport method when doing the SETUP request and response.
The secured media transport is SRTP (SAVP/RTP) normally over UDP. The secured media transport is SRTP (SAVP/RTP) normally over UDP.
The key management for SRTP is MIKEY using RSA-R mode. The RSA-R The key management for SRTP is MIKEY using RSA-R mode. The RSA-R
mode is selected as it allows the RTSP Server to select the key, mode is selected as it allows the RTSP Server to select the key
despite having the RTSP Client initiate the MIKEY exchange. It also despite having the RTSP Client initiate the MIKEY exchange. It also
enables the reuse of the RTSP servers TLS certificate when creating enables the reuse of the RTSP servers TLS certificate when creating
the MIKEY messages thus ensuring a binding between the RTSP server the MIKEY messages thus ensuring a binding between the RTSP server
and the key-exchange. Assuming the SETUP process works, this will and the key exchange. Assuming the SETUP process works, this will
establish a SRTP crypto context to be used between the RTSP Server establish a SRTP crypto context to be used between the RTSP Server
and the Client for the RTP transported media streams. and the Client for the RTP transported media streams.
6. IANA Considerations 6. 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.
The authors wished to thank Christian Correll for review and great The authors wished to thank Christian Correll, Dan Wing, and Kevin
proposals for improvements of the text. Gross for review and proposals for improvements of the text.
9. Informative References 9. Informative References
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", draft-ietf-avt-srtp-not-mandatory-12 Security Solution", draft-ietf-avt-srtp-not-mandatory-13
(work in progress), February 2013. (work in progress), May 2013.
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-03 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), April 2013. (work in progress), July 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-03
(work in progress), December 2012. (work in progress), June 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-05 (work in progress), February 2013. aes-gcm-07 (work in progress), July 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), April 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", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-06 (work in progress), January 2013. rtcweb-security-arch-07 (work in progress), July 2013.
[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] [OMABCAST]
Open Mobile Alliance, "OMA Mobile Broadcast Services Open Mobile Alliance, "OMA Mobile Broadcast Services
V1.0", February 2009. V1.0", February 2009.
[OMADRMv2] [OMADRMv2]
skipping to change at page 30, line 12 skipping to change at page 29, line 51
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009. Protocols", RFC 5479, April 2009.
[RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The
SEED Cipher Algorithm and Its Use with the Secure Real- SEED Cipher Algorithm and Its Use with the Secure Real-
Time Transport Protocol (SRTP)", RFC 5669, August 2010. Time Transport Protocol (SRTP)", RFC 5669, August 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
 End of changes. 120 change blocks. 
349 lines changed or deleted 338 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/