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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |