draft-ietf-avtcore-rtp-security-options-09.txt   draft-ietf-avtcore-rtp-security-options-10.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: May 16, 2014 University of Glasgow Expires: July 19, 2014 University of Glasgow
November 12, 2013 January 15, 2014
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-09 draft-ietf-avtcore-rtp-security-options-10
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 May 16, 2014. This Internet-Draft will expire on July 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4
2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5
2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5
2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 13
3.1.3. Key Management for SRTP: Security Descriptions . . . 14 3.1.3. Key Management for SRTP: Security Descriptions . . . 14
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15
3.1.5. Key Management for SRTP: Other systems . . . . . . . 15 3.1.5. Key Management for SRTP: ZRTP and Other Solutions . . 15
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 16 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 16
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 17 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 17
3.6. Media Content Security/Digital Rights Management . . . . 17 3.6. Media Content Security/Digital Rights Management . . . . 17
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18
4.1. Application Requirements . . . . . . . . . . . . . . . . 18 4.1. Application Requirements . . . . . . . . . . . . . . . . 19
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 19 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 19
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22 4.1.4. Identifiers and Identity . . . . . . . . . . . . . . 22
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Application Structure . . . . . . . . . . . . . . . . . . 23 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23
4.3. Automatic Key Management . . . . . . . . . . . . . . . . 23 4.3. Automatic Key Management . . . . . . . . . . . . . . . . 24
4.4. End-to-End Security vs Tunnels . . . . . . . . . . . . . 24 4.4. End-to-End Security vs Tunnels . . . . . . . . . . . . . 24
4.5. Plain Text Keys . . . . . . . . . . . . . . . . . . . . . 24 4.5. Plain Text Keys . . . . . . . . . . . . . . . . . . . . . 24
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 25 4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 25
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Media Security for SIP-established Sessions using DTLS- 5.1. Media Security for SIP-established Sessions using DTLS-
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 26 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 26
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 27 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 27
5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 28 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 28
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 3, line 40 skipping to change at page 3, line 40
overview of the available RTP solutions, and provides guidance on overview of the available RTP solutions, and provides guidance on
their applicability for different application domains. It also their applicability for different application domains. It also
attempts to provide indication of actual and intended usage at time attempts to provide indication of actual and intended usage at time
of writing as additional input to help with considerations such as of writing as additional input to help with considerations such as
interoperability, availability of implementations etc. The guidance interoperability, availability of implementations etc. The guidance
provided is not exhaustive, and this memo does not provide normative provided is not exhaustive, and this memo does not provide normative
recommendations. recommendations.
It is important that application developers consider the security It is important that application developers consider the security
goals and requirements for their application. The IETF considers it goals and requirements for their application. The IETF considers it
important that protocols implement, and makes available to the user, important that protocols implement secure modes of operation and
secure modes of operation [RFC3365]. Because of the heterogeneity of makes them available to users [RFC3365]. Because of the
RTP applications and use cases, however, a single security solution heterogeneity of RTP applications and use cases, however, a single
cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead, security solution cannot be mandated
application developers need to select mechanisms that provide [I-D.ietf-avt-srtp-not-mandatory]. Instead, application developers
appropriate security for their environment. It is strongly need to select mechanisms that provide appropriate security for their
encouraged that common mechanisms are used by related applications in environment. It is strongly encouraged that common mechanisms are
common environments. The IETF publishes guidelines for specific used by related applications in common environments. The IETF
classes of applications, so it is worth searching for such publishes guidelines for specific classes of applications, so it is
guidelines. 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 36 skipping to change at page 4, line 36
case the RTP security is primarily about ensuring that any third case the RTP security is primarily about ensuring that any third
party can't compromise the confidentiality and integrity of the media party can't compromise the confidentiality and integrity of the media
communication. This requires confidentiality protection of the RTP communication. This requires confidentiality protection of the RTP
session, integrity protection of the RTP/RTCP packets, and source session, integrity protection of the RTP/RTCP packets, and source
authentication of all the packets to ensure no man-in-the-middle authentication of all the packets to ensure no man-in-the-middle
attack is taking place. attack is taking place.
The source authentication can also be tied to a user or an end- The source authentication can also be tied to a user or an end-
point's verifiable identity to ensure that the peer knows who they point's verifiable identity to ensure that the peer knows who they
are communicating with. Here the combination of the security are communicating with. Here the combination of the security
protocol protecting the RTP session and its RTP and RTCP traffic and protocol protecting the RTP session (and hence the RTP and RTCP
the key-management protocol becomes important in which security traffic) and the key-management protocol becomes important to
statements one can do. determine what security claims can be made.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point-to-point topology Figure 1: Point-to-point topology
2.2. Sessions Using an RTP Mixer 2.2. Sessions Using an RTP Mixer
An RTP mixer is an RTP session-level middlebox that one can build a An RTP mixer is an RTP session-level middlebox that one can build a
multi-party RTP based conference around. The RTP mixer might multi-party RTP based conference around. The RTP mixer might
actually perform media mixing, like mixing audio or compositing video actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the participant; or it might provide a conceptual stream, for example the
skipping to change at page 5, line 15 skipping to change at page 5, line 15
the important features of an RTP mixer is that it generates a new the important features of an RTP mixer is that it generates a new
media stream, and has its own source identifier, and does not simply media stream, and has its own source identifier, and does not simply
forward the original media. forward the original media.
An RTP session using a mixer might have a topology like that in An RTP session using a mixer might have a topology like that in
Figure 2. In this example, participants A through D each send Figure 2. In this example, participants A through D each send
unicast RTP traffic to the RTP mixer, and receive an RTP stream from unicast RTP traffic to the RTP mixer, and receive an RTP stream from
the mixer, comprising a mixture of the streams from the other the mixer, comprising a mixture of the streams from the 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 has access to the the RTP mixer needs to be a trusted device that has access to the
security context(s) established. The RTP mixer can also become a security context(s) established. The RTP mixer can also become a
security enforcing entity. For example, a common approach to secure security enforcing entity. For example, a common approach to secure
the topology in Figure 2 is to establish a security context between the topology in Figure 2 is to establish a security context between
the mixer and each participant independently, and have the mixer the mixer and each participant independently, and have the mixer
skipping to change at page 6, line 13 skipping to change at page 6, line 13
Transport translators also need to implement ingress filtering to Transport translators also need to implement ingress filtering to
prevent random traffic from being forwarded that isn't coming from a prevent random traffic from being forwarded that isn't coming from a
participant in the conference. participant in the conference.
Figure 3 shows an example transport translator, where traffic from Figure 3 shows an example transport translator, where traffic from
any one of the four participants will be forwarded to the other three any one of the four participants will be forwarded to the other three
participants unchanged. The resulting topology is very similar to participants unchanged. The resulting topology is very similar to
Any Source Multicast (ASM) session (as discussed in Section 2.4), but Any Source Multicast (ASM) session (as discussed in Section 2.4), but
implemented at the application layer. implemented at the application layer.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | Relay | +---+ +---+ | Relay | +---+
| Translator | | Translator |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 3: RTP relay translator topology Figure 3: RTP relay translator topology
A transport translator can often operate without needing access to A transport translator can often operate without needing access to
the security context, as long as the security mechanism does not the security context, as long as the security mechanism does not
provide protection over the transport-layer information. A transport provide protection over the transport-layer information. A transport
translator does, however, make the group communication visible, and translator does, however, make the group communication visible, and
so can complicate keying and source authentication mechanisms. This so can complicate keying and source authentication mechanisms. This
is further discussed in Section 2.4. is further discussed in Section 2.4.
2.3.2. Gateway 2.3.2. Gateway
Gateways are deployed when the endpoints are not fully compatible. Gateways are deployed when the endpoints are not fully compatible.
Figure 4 shows an example topology. The functions a gateway provides Figure 4 shows an example topology. The functions a gateway provides
can be diverse, and range from transport layer relaying between two can be diverse, and range from transport layer relaying between two
domains not allowing direct communication, via transport or media domains not allowing direct communication, via transport or media
protocol function initiation or termination, to protocol or media protocol function initiation or termination, to protocol or media
encoding translation. The supported security protocol might even be encoding translation. The supported security protocol might even be
one of the reasons a gateway is needed. one of the reasons a gateway is needed.
+---+ +-----------+ +---+ +---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B | | A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+ +---+ +-----------+ +---+
Figure 4: RTP gateway topology Figure 4: RTP gateway topology
The choice of security protocol, and the details of the gateway The choice of security protocol, and the details of the gateway
function, will determine if the gateway needs to be trusted with function, will determine if the gateway needs to be trusted with
access to the application security context. Many gateways need to be access to the application security context. Many gateways need to be
trusted by all peers to perform the translation; in other cases some trusted by all peers to perform the translation; in other cases some
or all peers might not be aware of the presence of the gateway. The or all peers might not be aware of the presence of the gateway. The
security protocols have different properties depending on the degree security protocols have different properties depending on the degree
of trust and visibility needed. Ensuring communication is possible of trust and visibility needed. Ensuring communication is possible
skipping to change at page 7, line 30 skipping to change at page 7, line 30
any multicast group participant can send to the multicast group, and any multicast group participant can send to the multicast group, and
get their packets delivered to all group members (see Figure 5). get their packets delivered to all group members (see Figure 5).
This form of communication has interesting security properties, due This form of communication has interesting security properties, due
to the many-to-many nature of the group. Source authentication is to the many-to-many nature of the group. Source authentication is
important, but all participants with access to group security context important, but all participants with access to group security context
will have the necessary secrets to decrypt and verify integrity of will have the necessary secrets to decrypt and verify integrity of
the traffic. Thus use of any group security context fails if the the traffic. Thus use of any group security context fails if the
goal is to separate individual sources; alternate solutions are goal is to separate individual sources; alternate solutions are
needed. needed.
+-----+ +-----+
+---+ / \ +---+ +---+ / \ +---+
| A |----/ \---| B | | A |----/ \---| B |
+---+ / Multi- \ +---+ +---+ / Multi- \ +---+
+ Cast + + Cast +
+---+ \ Network / +---+ +---+ \ Network / +---+
| C |----\ /---| D | | C |----\ /---| D |
+---+ \ / +---+ +---+ \ / +---+
+-----+ +-----+
Figure 5: Any source multicast (ASM) group Figure 5: Any source multicast (ASM) group
In addition the potential large size of multicast groups creates some In addition the potential large size of multicast groups creates some
considerations for the scalability of the solution and how the key- considerations for the scalability of the solution and how the key-
management is handled. management is handled.
2.5. Source-Specific Multicast 2.5. Source-Specific Multicast
Source-Specific Multicast [RFC4607] allows only a specific end-point Source-Specific Multicast [RFC4607] allows only a specific end-point
skipping to change at page 8, line 18 skipping to change at page 8, line 18
and the Feedback Targets, FT1...FTn. RTCP reception quality feedback and the Feedback Targets, FT1...FTn. RTCP reception quality feedback
is sent unicast from each receiver to one of the Feedback Targets. is sent unicast from each receiver to one of the Feedback Targets.
The feedback targets aggregate reception quality feedback and forward The feedback targets aggregate reception quality feedback and forward
it upstream towards the distribution source. The distribution source it upstream towards the distribution source. The distribution source
forwards (possibly aggregated and summarised) reception feedback to forwards (possibly aggregated and summarised) reception feedback to
the SSM group, and back to the original media sources. The feedback the SSM group, and back to the original media sources. The feedback
targets are also members of the SSM group and receive the media data, targets are also members of the SSM group and receive the media data,
so they can send unicast repair data to the receivers in response to so they can send unicast repair data to the receivers in response to
feedback if appropriate. feedback if appropriate.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm | | MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
^ ^ ^ ^ ^ ^
| | | | | |
V V V V V V
+---------------------------------+ +---------------------------------+
| Distribution Source | | Distribution Source |
+--------+ | +--------+ |
| FT Agg | | | FT Agg | |
+--------+------------------------+ +--------+------------------------+
^ ^ | ^ ^ |
: . | : . |
: +...................+ : +...................+
: | . : | .
: / \ . : / \ .
+------+ / \ +-----+ +------+ / \ +-----+
| FT1 |<----+ +----->| FT2 | | FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+ +------+ / \ +-----+
^ ^ / \ ^ ^ ^ ^ / \ ^ ^
: : / \ : : : : / \ : :
: : / \ : : : : / \ : :
: : / \ : : : : / \ : :
: ./\ /\. : : ./\ /\. :
: /. \ / .\ : : /. \ / .\ :
: V . V V . V : : V . V V . V :
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn | | R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 6: Example SSM-based RTP session with two feedback targets Figure 6: Example SSM-based RTP session with two feedback targets
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 an individual requirements apply for SSM sessions too, and an individual
verification of who sent the RTP and RTCP packets is needed. An RTP verification of who sent the RTP and RTCP packets is needed. An RTP
session using SSM will have a group security context that includes session using SSM will have a group security context that includes
the media sources, distribution source, feedback targets, and the the media sources, distribution source, feedback targets, and the
receivers. Each has a different role and will be trusted to perform receivers. Each has a different role and will be trusted to perform
skipping to change at page 11, line 44 skipping to change at page 11, line 44
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 (PFS)
binding strong identity verification to an end-point. The default and binding strong identity verification to an end-point. Perfect
key generation will generate a key that contains material contributed Forward Secrecy is a property of the key-agreement protocol that
by both peers. The key-exchange happens in the media plane directly ensures that a session key derived from a set of long-term keys will
between the peers. The common key-exchange procedures will take two not be compromised if one of the long-term keys is compromised in the
round trips assuming no losses. TLS resumption can be used when future. The default key generation will generate a key that contains
establishing additional media streams with the same peer, and reduces material contributed by both peers. The key-exchange happens in the
the set-up time to one RTT for these streams (see [RFC5764] for a media plane directly between the peers. The common key-exchange
discussion of TLS resumption in this context). procedures will take two round trips assuming no losses. TLS
resumption can be used when establishing additional media streams
with the same peer, and reduces 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 suites offered and used, as well as DTLS will depend on the cipher suites offered and used, as well as
the mechanism for identifying the end-points of the hand-shake. For the mechanism for identifying the end-points of the hand-shake. For
example some cipher suits provide perfect forward secrecy (PFS), example some cipher suits provide PFS , while other do not. When
while other do not. When using DTLS, the application designer needs using DTLS, the application designer needs to select which cipher
to select which cipher suites DTLS-SRTP can offer and accept so that suites DTLS-SRTP can offer and accept so that the desired security
the desired security properties are achieved. The next choice is how properties are achieved. The next choice is how to verify the
to verify the identity of the peer end-point. One choice can be to identity of the peer end-point. One choice can be to rely on the
rely on the certificates and use a PKI to verify them to make an certificates and use a PKI to verify them to make an identity
identity assertion. However, this is not the most common way, assertion. However, this is not the most common way, instead self-
instead self-signed certificate are common to use, and instead signed certificate are common to use, and instead establish trust
establish trust through signalling or other third party solutions. through signalling or other third party solutions.
DTLS-SRTP key management can use the signalling protocol in four DTLS-SRTP key management can use the signalling protocol in four
ways. First, to agree on using DTLS-SRTP for media security. ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where Secondly, to determine the network location (address and port) where
each side is running a DTLS listener to let the parts perform the each side is running a DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Thirdly, to exchange hashes of each side's certificates to bind these Thirdly, to exchange hashes of each side's certificates to bind these
to the signalling, and ensure there is no man-in-the-middle attack. to the signalling, and ensure there is no man-in-the-middle attack.
This assumes that one can trust the signalling solution to be This assumes that one can trust the signalling solution to be
resistant to modification, and not be in collaboration with an resistant to modification, and not be in collaboration with an
skipping to change at page 12, line 44 skipping to change at page 12, line 48
solutions. It is to be noted that there is work underway to revisit solutions. It is to be noted that there is work underway to revisit
the SIP Identity mechanism [RFC4474] in the IETF STIR working group. the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
The main question regarding DTLS-SRTP's security properties is how The main question regarding DTLS-SRTP's security properties is how
one verifies any peer identity or at least prevents man-in-the-middle one verifies any peer identity or at least prevents man-in-the-middle
attacks. This do requires trust in some DTLS-SRTP external party, attacks. This do requires trust in some DTLS-SRTP external party,
either a PKI, a signalling system or some identity provider. either a PKI, a signalling system or some identity provider.
DTLS-SRTP usage is clearly on the rise. It is mandatory to support DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
was developed in IETF primarily to meet security requirements for was developed in IETF primarily to meet security requirements for RTP
SIP. based media established using SIP. The requirements considered can
be reviewed in "Requirements and Analysis of Media Security
Management Protocols." [RFC5479].
3.1.2. Key Management for SRTP: MIKEY 3.1.2. Key Management for SRTP: MIKEY
Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol
that has several modes with different properties. MIKEY can be used that has several modes with different properties. MIKEY can be used
in point-to-point applications using SIP and RTSP (e.g., VoIP calls), in point-to-point applications using SIP and RTSP (e.g., VoIP calls),
but is also suitable for use in broadcast and multicast applications, but is also suitable for use in broadcast and multicast applications,
and centralized group communications. and centralized group communications.
MIKEY can establish multiple security contexts or cryptographic MIKEY can establish multiple security contexts or cryptographic
sessions with a single message. It is useable in scenarios where one sessions with a single message. It is useable in scenarios where one
entity generates the key and needs to distribute the key to a number entity generates the key and needs to distribute the key to a number
of participants. The different modes and the resulting properties of participants. The different modes and the resulting properties
skipping to change at page 14, line 12 skipping to change at page 14, line 14
material depending on use case. Usage of this mode requires one material depending on use case. Usage of this mode requires one
round-trip time. round-trip time.
TICKET: [RFC6043] is a MIKEY extension using a trusted centralized TICKET: [RFC6043] is a MIKEY extension using a trusted centralized
key management service (KMS). The Initiator and Responder do not key management service (KMS). The Initiator and Responder do not
share any credentials; instead, they trust a third party, the KMS, share any credentials; instead, they trust a third party, the KMS,
with which they both have or can establish shared credentials. with which they both have or can establish shared credentials.
IBAKE: [RFC6267] uses a key management services (KMS) infrastructure IBAKE: [RFC6267] uses a key management services (KMS) infrastructure
but with lower demand on the KMS. Claims to provides both perfect but with lower demand on the KMS. Claims to provides both perfect
forward and backwards secrecy, the exact meaning is unclear (See forward and backwards secrecy.
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. Its features less signatures to provide source authentication. Its features
include simplex transmission, scalability, low-latency call set- include simplex transmission, scalability, low-latency call set-
up, and support for secure deferred delivery. up, and support for secure deferred delivery.
MIKEY messages have several different transports. [RFC4567] defines MIKEY messages have several different transports. [RFC4567] defines
how MIKEY messages can be embedded in general SDP for usage with the how MIKEY messages can be embedded in general SDP for usage with the
skipping to change at page 15, line 45 skipping to change at page 15, line 47
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 is only sent occasionally or session participants. This key is only sent occasionally or
periodically depending on use cases and depending on what periodically depending on use cases and depending on what
requirements exist for timely delivery or notification. requirements exist for timely delivery or notification.
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: ZRTP and Other Solutions
The ZRTP [RFC6189] key-management system for SRTP was proposed as an The ZRTP [RFC6189] key-management system for SRTP was proposed as an
alternative to DTLS-SRTP. ZRTP provides best effort encryption alternative to DTLS-SRTP. ZRTP provides best effort encryption
independent of the signalling protocol and utilizes key continuity, independent of the signalling protocol and utilizes key continuity,
Short Authentication Strings, or a PKI for authentication. ZRTP Short Authentication Strings, or a PKI for authentication. ZRTP
wasn't adopted as an IETF standards track protocol, but was instead wasn't adopted as an IETF standards track protocol, but was instead
published as an informational RFC. Commercial implementations exist. published as an informational RFC. Commercial implementations exist.
Additional proprietary solutions are also known to exist. Additional proprietary solutions are also known to exist.
skipping to change at page 21, line 32 skipping to change at page 21, line 39
depends on the properties of the key-management system, the depends on the properties of the key-management system, the
ability to tie the signalling to a particular source, and the ability to tie the signalling to a particular source, and the
degree of trust the receiver places on the different nodes degree of trust the receiver places on the different nodes
involved. involved.
For example, systems where the key-exchange is done using the For example, systems where the key-exchange is done using the
signalling systems, such as Security Descriptions [RFC4568], signalling systems, such as Security Descriptions [RFC4568],
enable a direct binding between signalling and key-exchange. In enable a direct binding between signalling and key-exchange. In
such systems, the actual security depends on the trust one can such systems, the actual security depends on the trust one can
place in the signalling system to correctly associate the peer's place in the signalling system to correctly associate the peer's
identity with the key-exchange. identifier with the key-exchange.
Using Identities: If the applications have access to a system that Using Identifiers: If the applications have access to a system that
can provide verifiable identities, then the source authentication can provide verifiable identifiers, then the source authentication
can be bound to that identity. For example, in a point-to-point can be bound to that identifier. For example, in a point-to-point
communication even symmetric key crypto, where the key-management communication even symmetric key crypto, where the key-management
can assert that the key has only been exchanged with a particular can assert that the key has only been exchanged with a particular
identity, can provide a strong assertion about the source of the identifier, can provide a strong assertion about the source of the
traffic. SIP identity [RFC4474] provides one example of how this traffic. SIP identity [RFC4474] provides one example of how this
can be done, and could be used to bind DTLS-SRTP certificates to can be done, and could be used to bind DTLS-SRTP certificates used
the identity provider's public key to authenticate the source of a by an end-point to the identity provider's public key to
DTLS-SRTP flow. authenticate the source of a DTLS-SRTP flow.
Note that all levels of the system need to have matching Note that all levels of the system need to have matching
capability to assert identity. If the signalling can assert that capability to assert identifiers. If the signalling can assert
only a given entity in a multiparty session has a key, then the that only a given entity in a multiparty session has a key, then
media layer might be able to provide guarantees about the identity the media layer might be able to provide guarantees about the
of the media sender. However, using an signalling authentication identifier used by the media sender. However, using an signalling
mechanism built on a group key can limit the media layer to authentication mechanism built on a group key can limit the media
asserting only group membership. layer to asserting only group membership.
4.1.4. Identity 4.1.4. Identifiers and Identity
There exist many different types of identity systems with different There exist many different types of systems providing identifiers
properties (e.g., SIP identity [RFC4474]). In the context of RTP with different properties (e.g., SIP identity [RFC4474]). In the
applications, the most important property is the possibility to context of RTP applications, the most important property is the
perform source authentication and verify such assertions in relation possibility to perform source authentication and verify such
to any claimed identities. What an identity really is can also vary assertions in relation to any claimed identifiers. What an
but, in the context of communication, one of the most obvious is the identifier really represent can also vary but, in the context of
identity of the human user one communicates with. However, the human communication, one of the most obvious is the identifiers
user can also have additional identities in a particular role. For representing the identity of the human user one communicates with.
example, the human Alice, can also be a police officer and in some However, the human user can also have additional identifiers in a
cases her identity as police officer will be more relevant then that particular role. For example, the human Alice, can also be a police
she is Alice. This is common in contact with organizations, where it officer and in some cases a identifier for her role as police officer
is important to prove the persons right to represent the will be more relevant than one that assert that she is Alice. This
organization. Some examples of identity mechanisms that can be used: is common in contact with organizations, where it is important to
prove the persons right to represent the organization. Some examples
of identifier/Identity mechanisms that can be used:
Certificate based: A certificate is used to prove the identity, by Certificate based: A certificate is used to assert the identifiers
having access to the private part of the certificate one can used to claim an identity, by having access to the private part of
perform signing to assert ones identity. Any entity interested in the certificate one can perform signing to assert ones identity.
verifying the assertion then needs the public part of the Any entity interested in verifying the assertion then needs the
certificate. By having the certificate, one can verify the public part of the certificate. By having the certificate, one
signature against the certificate. The next step is to determine can verify the signature against the certificate. The next step
if one trusts the certificate's trust chain. Commonly by is to determine if one trusts the certificate's trust chain.
provisioning the verifier with the public part of a root Commonly by provisioning the verifier with the public part of a
certificate, this enables the verifier to verify a trust chain root certificate, this enables the verifier to verify a trust
from the root certificate down to the identity certificate. chain from the root certificate down to the identifier in the
However, the trust is based on all steps in the certificate chain certificate. However, the trust is based on all steps in the
being verifiable and trusted. Thus provisioning of root certificate chain being verifiable and trusted. Thus provisioning
certificates and the ability to revoke compromised certificates of root certificates and the ability to revoke compromised
are aspects that will require infrastructure. certificates are aspects that will require infrastructure.
Online Identity Providers: An online identity provider (IdP) can Online Identity Providers: An online identity provider (IdP) can
authenticate a user's right to use an identity, then perform authenticate a user's right to use an identifier, then perform
assertions on their behalf or provision the requester with short- assertions on their behalf or provision the requester with short-
term credentials to assert their identity. The verifier can then term credentials to assert the identifiers. The verifier can then
contact the IdP to request verification of a particular identity. contact the IdP to request verification of a particular
Here the trust is highly dependent on how much one trusts the IdP. identifier. Here the trust is highly dependent on how much one
The system also becomes dependent on having access to the relevant trusts the IdP. The system also becomes dependent on having
IdP. access to the relevant IdP.
In all of the above examples, an important part of the security In all of the above examples, an important part of the security
properties are related to the method for authenticating the access to properties are related to the method for authenticating the access to
the identity. the identity.
4.1.5. Privacy 4.1.5. Privacy
RTP applications need to consider what privacy goals they have. As RTP applications need to consider what privacy goals they have. As
RTP applications communicate directly between peers in many cases, RTP applications communicate directly between peers in many cases,
the IP addresses of any communication peer will be available. The the IP addresses of any communication peer will be available. The
skipping to change at page 24, line 22 skipping to change at page 24, line 32
When selecting security mechanisms for an RTP application it is When selecting security mechanisms for an RTP application it is
important to consider the properties of the key management. Using important to consider the properties of the key management. Using
key management that is both automatic and integrated will provide key management that is both automatic and integrated will provide
minimal interruption for the user, and is important to ensure that minimal interruption for the user, and is important to ensure that
security can, and will remain, to be on by default. security can, and will remain, to be on by default.
4.4. End-to-End Security vs Tunnels 4.4. End-to-End Security vs Tunnels
If the security mechanism only provides a secured tunnel, for example If the security mechanism only provides a secured tunnel, for example
like some common uses of IPSec Section 3.3, it is important to like some common uses of IPsec (Section 3.3), it is important to
consider the full end-to-end properties of the system. How does one consider the full end-to-end properties of the system. How does one
ensure that the path from the endpoint to the local tunnel ingress/ ensure that the path from the endpoint to the local tunnel ingress/
egress is secure and can be trusted (and similarly for the other end egress is secure and can be trusted (and similarly for the other end
of the tunnel)? How does one handle the source authentication of the of the tunnel)? How does one handle the source authentication of the
peer, as the security protocol identifies the other end of the peer, as the security protocol identifies the other end of the
tunnel. These are some of the issues that arise when one considers a tunnel. These are some of the issues that arise when one considers a
tunnel based security protocol rather than an end-to-end. Even with tunnel based security protocol rather than an end-to-end. Even with
clear requirements and knowledge that one still can achieve the clear requirements and knowledge that one still can achieve the
security properties using a tunnel based solution, one ought to security properties using a tunnel based solution, one ought to
prefer to use end-to-end mechanisms, as they are much less likely to prefer to use end-to-end mechanisms, as they are much less likely to
skipping to change at page 30, line 20 skipping to change at page 30, line 17
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. John Mattsson has contributed the IMS Media Security example memo. John Mattsson has contributed the IMS Media Security example
(Section 5.3). (Section 5.3).
The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, The authors wished to thank Christian Correll, Dan Wing, Kevin Gross,
Alan Johnston, Michael Peck, Ole Jacobsen, and John Mattsson for Alan Johnston, Michael Peck, Ole Jacobsen, Spencer Dawkins, Stephen
review and proposals for improvements of the text. Farrell, John Mattsson, and Suresh Krishnan 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-14 Security Solution", draft-ietf-avt-srtp-not-mandatory-14
(work in progress), October 2013. (work in progress), October 2013.
[I-D.ietf-avtcore-aria-srtp] [I-D.ietf-avtcore-aria-srtp]
Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
ARIA Algorithm and Its Use with the Secure Real-time ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-06
(work in progress), September 2013. (work in progress), November 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-10 (work in progress), September 2013. aes-gcm-10 (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D. and D. Wing, "Encrypted Key Transport for McGrew, D. and D. Wing, "Encrypted Key Transport for
Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in
progress), October 2013. progress), October 2013.
 End of changes. 36 change blocks. 
158 lines changed or deleted 167 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/