draft-ietf-avtcore-rtp-security-options-06.txt   draft-ietf-avtcore-rtp-security-options-07.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. S. Perkins Intended status: Informational C. Perkins
Expires: March 03, 2014 University of Glasgow Expires: April 10, 2014 University of Glasgow
August 30, 2013 October 07, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-06 draft-ietf-avtcore-rtp-security-options-07
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 March 03, 2014. This Internet-Draft will expire on April 10, 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 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 4 2.1. Point to Point Sessions . . . . . . . . . . . . . . . . . 4
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 10
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11
3.1.3. Key Management for SRTP: Security Descriptions . . . 13 3.1.3. Key Management for SRTP: Security Descriptions . . . 13
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14
3.1.5. Key Management for SRTP: Other systems . . . . . . . 14 3.1.5. Key Management for SRTP: Other systems . . . . . . . 14
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 15 3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 15
3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16 3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Media Content Security/Digital Rights Management . . . . 16 3.6. Media Content Security/Digital Rights Management . . . . 16
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17
4.1. Application Requirements . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 17
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
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 3, line 44 skipping to change at page 3, line 44
It is important that application developers consider the security It is important that application developers consider the security
goals and requirements for their application. The IETF considers it goals and requirements for their application. The IETF considers it
important that protocols implement, and makes available to the user, important that protocols implement, and makes available to the user,
secure modes of operation [RFC3365]. Because of the heterogeneity of secure modes of operation [RFC3365]. Because of the heterogeneity of
RTP applications and use cases, however, a single security solution RTP applications and use cases, however, a single security solution
cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead, cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead,
application developers need to select mechanisms that provide application developers need to select mechanisms that provide
appropriate security for their environment. It is strongly appropriate security for their environment. It is strongly
encouraged that common mechanisms are used by related applications in encouraged that common mechanisms are used by related applications in
common environments. The IETF publishes guidelines for specific common environments. The IETF publishes guidelines for specific
classes of applications, so it worth searching for such guidelines. classes of applications, so it is worth searching for such
guidelines.
The remainder of this document is structured as follows. Section 2 The remainder of this document is structured as follows. Section 2
provides additional background. Section 3 outlines the available provides additional background. Section 3 outlines the available
security mechanisms at the time of this writing, and lists their key security mechanisms at the time of this writing, and lists their key
security properties and constraints. That is followed by guidelines security properties and constraints. 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
skipping to change at page 4, line 25 skipping to change at page 4, line 19
RTP can be used in a wide variety of topologies due to its support RTP can be used in a wide variety of topologies due to its support
for point-to-point sessions, multicast groups, and other topologies for point-to-point sessions, multicast groups, and other topologies
built around different types of RTP middleboxes. In the following we built around different types of RTP middleboxes. In the following we
review the different topologies supported by RTP to understand their review the different topologies supported by RTP to understand their
implications for the security properties and trust relations that can implications for the security properties and trust relations that can
exist in RTP sessions. exist in RTP sessions.
2.1. Point to Point Sessions 2.1. Point to Point Sessions
The most basic use case is two directly connected end-points, shown The most basic use case is two directly connected end-points, shown
in Figure 1, where A has established an RTP session with B. In this in Figure 1, where A has established an RTP session with B. In this
case the RTP security is primarily about ensuring that any third case the RTP security is primarily about ensuring that any third
party can't compromise the confidentiality and integrity of the media party can't compromise the confidentiality and integrity of the media
communication. This requires confidentiality protection of the RTP communication. This requires confidentiality protection of the RTP
session, integrity protection of the RTP/RTCP packets, and source session, integrity protection of the RTP/RTCP packets, and source
authentication of all the packets to ensure no man-in-the-middle authentication of all the packets to ensure no man-in-the-middle
attack is taking place. attack is taking place.
The source authentication can also be tied to a user or an end- The source authentication can also be tied to a user or an end-
point's verifiable identity to ensure that the peer knows who they point's verifiable identity to ensure that the peer knows who they
are communicating with. Here the combination of the security are communicating with. Here the combination of the security
skipping to change at page 10, line 23 skipping to change at page 10, line 15
ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that
supports 128-, 192- and 256- bit keys. It also has three modes, supports 128-, 192- and 256- bit keys. It also has three modes,
Counter mode where combined with HMAC-SHA-1 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 systems. 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-SHA-1 with 80- and 32-bit authentication tags. Thus HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus
providing 192 and 256 bits encryption keys and NSA Suite B providing 192 and 256 bits encryption keys. Defined in [RFC6188].
included cryptographic transforms. Defined in [RFC6188].
AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC) AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC)
authentication for AES-128 and AES-256. This authentication is authentication for AES-128 and AES-256. This authentication is
included in the cipher text which becomes expanded with the length included in the cipher text which becomes expanded with the length
of the authentication tag instead of using the SRTP authentication of the authentication tag instead of using the SRTP authentication
tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. tag. 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
skipping to change at page 11, line 35 skipping to change at page 11, line 25
suites DTLS-SRTP can offer and accept so that the desired security suites DTLS-SRTP can offer and accept so that the desired security
properties are achieved. properties are achieved.
DTLS-SRTP key management can use the signalling protocol in four DTLS-SRTP key management can use the signalling protocol in four
ways. First, to agree on using DTLS-SRTP for media security. ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where Secondly, to determine the network location (address and port) where
each side is running a DTLS listener to let the parts perform the each side is running a DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Thirdly, to exchange hashes of each side's certificates to bind these Thirdly, to exchange hashes of each side's certificates to bind these
to the signalling, and ensure there is no man-in-the-middle attack. to the signalling, and ensure there is no man-in-the-middle attack.
Finally to provide an assertable identity, e.g. [RFC4474] that can Finally to provide an assertable identity, e.g. [RFC4474] that can be
be used to prevent modification of the signalling and the exchange of used to prevent modification of the signalling and the exchange of
certificate hashes. That way enabling binding between the key- certificate hashes. That way enabling binding between the key-
exchange and the signalling. exchange and the signalling.
This usage is well defined for SIP/SDP in [RFC5763], and in most This usage is well defined for SIP/SDP in [RFC5763], and in most
cases can be adopted for use with other bi-directional signalling cases can be adopted for use with other bi-directional signalling
solutions. It is to be noted that there is work underway to revisit solutions. It is to be noted that there is work underway to revisit
the SIP Identity mechanism [RFC4474] in the IETF STIR working group. the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
DTLS-SRTP usage is clearly on the rise. It is mandatory to support DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
skipping to change at page 13, line 23 skipping to change at page 13, line 15
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY.
Based on Identity based Public Key Cryptography and a KMS Based on Identity based Public Key Cryptography and a KMS
infrastructure to establish a shared secret value and certificate infrastructure to establish a shared secret value and certificate
less signatures to provide source authentication. It's features less signatures to provide source authentication. 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 have several different transports. [RFC4567] defines MIKEY messages have several different transports. [RFC4567] defines
how MIKEY messages can be embedded in general SDP for usage with the how MIKEY messages can be embedded in general SDP for usage with the
signalling protocols SIP, SAP and RTSP. There also exist a 3GPP signalling protocols SIP, SAP and RTSP. There also exist a 3GPP
defined usage of MIKEY that sends MIKEY messages directly over UDP to defined usage of MIKEY that sends MIKEY messages directly over UDP
key the receivers of Multimedia Broadcast and Multicast Service [T3GPP.33.246] to key the receivers of Multimedia Broadcast and
(MBMS) [T3GPP.33.246]. Multicast Service (MBMS) [T3GPP.26.346].
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 support MIKEY. The RSA-R mode. There are some SIP end-points that support MIKEY. The
modes they use are unknown to the authors. modes they use are unknown to the authors.
skipping to change at page 14, line 6 skipping to change at page 13, line 47
avoid a "two-time pad" attack - see Section 9 of [RFC3711]). avoid a "two-time pad" attack - see Section 9 of [RFC3711]).
Since keys are transported in plain text in SDP, they can easily be Since keys are transported in plain text in SDP, they can easily be
intercepted unless the SDP carrying protocol provides strong end-to- intercepted unless the SDP carrying protocol provides strong end-to-
end confidentiality and authentication guarantees. This is not end confidentiality and authentication guarantees. This is not
normally the case, where instead hop-by-hop security is provided normally the case, where instead hop-by-hop security is provided
between signalling nodes using TLS. This leaves the keying material between signalling nodes using TLS. This leaves the keying material
sensitive to capture by the traversed signalling nodes. Thus, in sensitive to capture by the traversed signalling nodes. Thus, in
most cases, the security properties of security descriptions are most cases, the security properties of security descriptions are
weak. The usage of security descriptions usually requires additional weak. The usage of security descriptions usually requires additional
security measures, e.g. the signalling nodes be trusted and security measures, e.g. the signalling nodes be trusted and protected
protected by strict access control. Usage of security descriptions by strict access control. Usage of security descriptions requires
requires careful design in order to ensure that the security goals careful design in order to 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 end-points that support for SIP-based end-points, where almost all end-points that support
SRTP also support Security Descriptions. SRTP also support Security Descriptions.
3.1.4. Key Management for SRTP: Encrypted Key Transport 3.1.4. Key Management for SRTP: Encrypted Key Transport
Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
extension that enables group keying despite using a keying mechanism extension that enables group keying despite using a keying mechanism
like DTLS-SRTP that doesn't support group keys. It is designed for like DTLS-SRTP that doesn't support group keys. It is designed for
skipping to change at page 15, line 26 skipping to change at page 15, line 20
direct relation, or in a secured environment where it can be direct relation, or in a secured environment where it can be
controlled who can read 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 meets the security goals. A important of its usage so that it meets the security goals. A important
question is how one ensures the IPsec terminating peer and the question is how one ensures the IPsec terminating peer and the
ultimate destination are the same. ultimate destination are the same. Applications can have issues
using existing APIs with determining if IPsec is being used or not,
and when used who the authenticated peer entity is.
IPsec with RTP is more commonly used as a security solution between IPsec with RTP is more commonly used as a security solution between
infrastructure nodes that exchange many RTP sessions and media infrastructure nodes that exchange many RTP sessions and media
streams. The establishment of a secure tunnel between such nodes streams. The establishment of a secure tunnel between such nodes
minimizes the key-management overhead. minimizes the key-management overhead.
3.4. DTLS for RTP and RTCP 3.4. 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 establish an DTLS to-point security for RTP flows. The two peers establish an DTLS
skipping to change at page 16, line 42 skipping to change at page 16, line 36
Mechanisms have been defined that encrypt only the media content, Mechanisms have been defined that encrypt only the media content,
operating within the RTP payload data and leaving the RTP headers and operating within the RTP payload data and leaving the RTP headers and
RTCP unaffected. There are several reasons why this might be RTCP unaffected. There are several reasons why this might be
appropriate, but a common rationale is to ensure that the content appropriate, but a common rationale is to ensure that the content
stored by RTSP streaming servers has the media content in a protected stored by RTSP streaming servers has the media content in a protected
format that cannot be read by the streaming server (this is mostly format that cannot be read by the streaming server (this is mostly
done in the context of Digital Rights Management). These approaches done in the context of Digital Rights Management). These approaches
then use a key-management solution between the rights provider and then use a key-management solution between the rights provider and
the consuming client to deliver the key used to protect the content the consuming client to deliver the key used to protect the content
and do not include the media server in the security context. Such and do not include the media server in the security context. Such
methods have several security weaknesses such the fact that the same methods have several security weaknesses such as the fact that the
key is handed out to a potentially large group of receiving clients, same key is handed out to a potentially large group of receiving
increasing the risk of a leak. clients, increasing the risk of a leak.
Use of this type of solution can be of interest in environments that Use of this type of solution can be of interest in environments that
allow middleboxes to rewrite the RTP headers and select which streams allow middleboxes to rewrite the RTP headers and select which streams
are delivered to an end-point (e.g., some types of centralised video are delivered to an end-point (e.g., some types of centralised video
conference systems). The advantage of encrypting and possibly conference systems). The advantage of encrypting and possibly
integrity protecting the payload but not the headers is that the integrity protecting the payload but not the headers is that the
middlebox can't eavesdrop on the media content, but can still provide middlebox can't eavesdrop on the media content, but can still provide
stream switching functionality. The downside of such a system is stream switching functionality. The downside of such a system is
that it likely needs two levels of security: the payload level that it likely needs two levels of security: the payload level
solution to provide confidentiality and source authentication, and a solution to provide confidentiality and source authentication, and a
skipping to change at page 22, line 13 skipping to change at page 22, line 26
considered. considered.
RTP itself can contribute to enabling a particular user to be tracked RTP itself can contribute to enabling a particular user to be tracked
between communication sessions if the CNAME is generated according to between communication sessions if the CNAME is generated according to
the RTP specification in the form of user@host. Such RTCP CNAMEs are the RTP specification in the form of user@host. Such RTCP CNAMEs are
likely long term stable over multiple sessions, allowing tracking of likely long term stable over multiple sessions, allowing tracking of
users. This can be desirable for long-term fault tracking and users. This can be desirable for long-term fault tracking and
diagnosis, but clearly has privacy implications. Instead diagnosis, but clearly has privacy implications. Instead
cryptographically random ones could be used as defined by Guidelines cryptographically random ones could be used as defined by Guidelines
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
[I-D.ietf-avtcore-6222bis]. [RFC7022].
If there exist privacy goals, these need to be considered, and the If there exist privacy goals, these need to be considered, and the
system designed with them in mind. In addition certain RTP features system designed with them in mind. In addition certain RTP features
might have to be configured to safeguard privacy, or have might have to be configured to safeguard privacy, or have
requirements on how the implementation is done. requirements on how the implementation is done.
4.2. Application Structure 4.2. Application Structure
When it comes to RTP security, the most appropriate solution is often When it comes to RTP security, the most appropriate solution is often
highly dependent on the topology of the communication session. The highly dependent on the topology of the communication session. The
skipping to change at page 24, line 34 skipping to change at page 24, line 46
as in ZRTP [RFC6189]), or using hash continuity. as in ZRTP [RFC6189]), or using hash continuity.
In the development of WebRTC there has also been attention given to In the development of WebRTC there has also been attention given to
privacy considerations. The main RTP-related concerns that have been privacy considerations. The main RTP-related concerns that have been
raised are: raised are:
Location Disclosure: As ICE negotiation [RFC5245] provides IP Location Disclosure: As ICE negotiation [RFC5245] provides IP
addresses and ports for the browser, this leaks location addresses and ports for the browser, this leaks location
information in the signalling to the peer. To prevent this one information in the signalling to the peer. To prevent this one
can block the usage of any ICE candidate that isn't a relay can block the usage of any ICE candidate that isn't a relay
candidate, i.e. where the IP and port provided belong to the candidate, i.e. where the IP and port provided belong to the
service providers media traffic relay. service providers media traffic relay.
Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP
certificates provide information that is re-used between session certificates provide information that is re-used between session
instances. Thus to prevent tracking, such information is ought instances. Thus to prevent tracking, such information is ought
not be re-used between sessions, or the information ought not sent not be re-used between sessions, or the information ought not sent
in the clear. in the clear.
Note: The above cases are focused on providing privacy from other Note: The above cases are focused on providing privacy from other
parties, not on providing privacy from the web server that provides parties, not on providing privacy from the web server that provides
skipping to change at page 25, line 32 skipping to change at page 25, line 38
retrieve the key as indicated in the SDP. Commonly OMA DRM v2 retrieve the key as indicated in the SDP. Commonly OMA DRM v2
[OMADRMv2] will be used to retrieve the key. If multiple keys are to [OMADRMv2] will be used to retrieve the key. If multiple keys are to
be used, then an additional RTSP stream for key-updates in parallel be used, then an additional RTSP stream for key-updates in parallel
with the media streams is established, where key updates are sent to with the media streams is established, where key updates are sent to
the client using Short Term Key Messages defined in the "Service and the client using Short Term Key Messages defined in the "Service and
Content Protection for Mobile Broadcast Services" section of the OMA Content Protection for Mobile Broadcast Services" section of the OMA
Mobile Broadcast Services [OMABCAST]. Mobile Broadcast Services [OMABCAST].
Worth noting is that this solution doesn't provide any integrity Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header verification method for the RTP header and payload header
information, only the encoded media AU is protected. 3GPP has not information, only the encoded media AU is protected. 3GPP has not
defined any requirement for supporting any solution that could defined any requirement for supporting any solution that could
provide that service. Thus, replay or insertion attacks are provide that service. Thus, replay or insertion attacks are
possible. Another property is that the media content can be possible. Another property is that the media content can be
protected by the ones providing the media, so that the operators of protected by the ones providing the media, so that the operators of
the RTSP server has no access to unprotected content. Instead all the RTSP server has no access to unprotected content. Instead all
that want to access the media is supposed to contact the DRM keying that want to access the media is supposed to contact the DRM keying
server and if the device is acceptable they will be given the key to server and if the device is acceptable they will be given the key to
decrypt the media. decrypt the media.
To protect the signalling, RTSP 1.0 supports the usage of TLS. This To protect the signalling, RTSP 1.0 supports the usage of TLS. This
skipping to change at page 27, line 6 skipping to change at page 27, line 12
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, Dan Wing, Kevin Gross, The authors wished to thank Christian Correll, Dan Wing, Kevin Gross,
Alan Johnston and Ole Jacobsen for review and proposals for Alan Johnston, Michael Peck, and Ole Jacobsen for review and
improvements of the text. proposals for improvements of the text.
9. Informative References 9. Informative References
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", draft-ietf-avt-srtp-not-mandatory-13 Security Solution", draft-ietf-avt-srtp-not-mandatory-13
(work in progress), May 2013. (work in progress), May 2013.
[I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(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-04 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05
(work in progress), August 2013. (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-07 (work in progress), July 2013. aes-gcm-10 (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-37 (work in
progress), April 2013. progress), September 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-07 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), August 2013. in progress), September 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-07 (work in progress), July 2013. rtcweb-security-arch-07 (work in progress), July 2013.
[ISMACrypt2] [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]
skipping to change at page 31, line 25 skipping to change at page 31, line 25
2012. 2012.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March Variable Bit Rate Audio with Secure RTP", RFC 6562, March
2012. 2012.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April Real-time Transport Protocol (SRTP)", RFC 6904, April
2013. 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
[T3GPP.26.234R11] [T3GPP.26.234R11]
3GPP, "Technical Specification Group Services and System 3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234 Service (PSS); Protocols and codecs", 3GPP TS 26.234
11.1.0, September 2012. 11.1.0, September 2012.
[T3GPP.26.234R8] [T3GPP.26.234R8]
3GPP, "Technical Specification Group Services and System 3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234 Service (PSS); Protocols and codecs", 3GPP TS 26.234
 End of changes. 26 change blocks. 
47 lines changed or deleted 46 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/