draft-ietf-avtcore-rtp-security-options-00.txt   draft-ietf-avtcore-rtp-security-options-01.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: January 10, 2013 University of Glasgow Expires: April 25, 2013 University of Glasgow
July 9, 2012 October 22, 2012
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-00 draft-ietf-avtcore-rtp-security-options-01
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 hetrogeneity different application domains and environments. This hetrogeneity
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 January 10, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 39 skipping to change at page 3, line 39
3.6.1. ISMA Encryption and Authentication . . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . . 17
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17
4.1. Application Requirements . . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . . 17
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Application Structure . . . . . . . . . . . . . . . . . . 21 4.2. Application Structure . . . . . . . . . . . . . . . . . . 21
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 21 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 21
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Media Security for SIP-established Sessions using 5.1. Media Security for SIP-established Sessions using
DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 22 DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . . 22 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . . 22
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 23 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 23
5.4. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. Informative References . . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) [RFC3550] is widely used in a Real-time Transport Protocol (RTP) [RFC3550] is widely used in a
large variety of multimedia applications, including Voice over IP large variety of multimedia applications, including Voice over IP
skipping to change at page 5, line 45 skipping to change at page 5, line 45
actually perform media mixing, like mixing audio or compositing video actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the participant; or it might provide a conceptual stream, for example the
video of the current active speaker. From a security point of view, video of the current active speaker. From a security point of view,
the important featurs of an RTP mixer is that it generates a new the important featurs of an RTP mixer is that it generates a new
media stream, and has its own source identifier, and does not simply media stream, and has its own source identifier, and does not simply
forward the original media. forward the original media.
An RTP session using a mixer might have a topology like that in An RTP session using a mixer might have a topology like that in
Figure 2. In this examples, participants A-D each send unicast RTP Figure 2. In this examples, participants A-D each send unicast RTP
traffic between themselves and the RTP mixer, and receive a single traffic between themselves and the RTP mixer, and receive a RTP
RTP stream from the mixer, comprising a mixture of the streams from stream from the mixer, comprising a mixture of the streams from the
the other participants. other participants.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 2: Example RTP Mixer topology Figure 2: Example RTP Mixer topology
skipping to change at page 6, line 41 skipping to change at page 6, line 41
transport translators, gateways, and media transcoders. We discuss transport translators, gateways, and media transcoders. We discuss
each in turn. each in turn.
2.3.1. Transport Translator (Relay) 2.3.1. Transport Translator (Relay)
A transport translator [RFC5117] operates on a level below RTP and A transport translator [RFC5117] operates on a level below RTP and
RTCP. It relays the RTP/RTCP traffic from one end-point to one or RTCP. It relays the RTP/RTCP traffic from one end-point to one or
more other addresses. This can be done based only on IP addresses more other addresses. This can be done based only on IP addresses
and transport protocol ports, with each receive port on the and transport protocol ports, with each receive port on the
translator can have a very basic list of where to forward traffic. translator can have a very basic list of where to forward traffic.
Transport translators also implement ingress filtering to prevent Transport translators should also implement ingress filtering to
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 |
skipping to change at page 21, line 10 skipping to change at page 21, line 10
main way of avoid such concerns is the introduction of relay or main way of avoid such concerns is the introduction of relay or
centralized media mixers or forwarders that hides the address of a centralized media mixers or forwarders that hides the address of a
peer from any other peer. The security and trust placed in these peer from any other peer. The security and trust placed in these
relays obviously needs to be carefully considered. relays obviously needs to be carefully considered.
RTP itself can contribute to enabling a particular user to be tracked RTP itself can contribute to enabling a particular user to be tracked
between communication sessions if the CNAME is generated according to between communication sessions if the CNAME is generated according to
the RTP specification in the form of user@host. Such RTCP CNAMEs are the RTP specification in the form of user@host. Such RTCP CNAMEs are
likely long term stable over multiple sessions, allowing tracking of likely long term stable over multiple sessions, allowing tracking of
users. This can be desirable for long-term fault tracking and users. This can be desirable for long-term fault tracking and
diagnosis, but clearly has privacy implications. diagnosis, but clearly has privacy implications. Instead
cryptographically random ones could be used as defined by Random
algorithm for RTP CNAME generation
[I-D.rescorla-avtcore-random-cname].
If there exist privacy goals, these need to be considered, and the If there exist privacy goals, these need to be considered, and the
system designed with them in mind. In addition certain RTP features system designed with them in mind. In addition certain RTP features
might have to be configured to safeguard privacy, or have might have to be configured to safeguard privacy, or have
requirements on how the implementation is done. requirements on how the implementation is done.
4.2. Application Structure 4.2. Application Structure
When it comes to RTP security, the most appropriate solution is often When it comes to RTP security, the most appropriate solution is often
highly dependent on the topology of the communication session. The highly dependent on the topology of the communication session. The
skipping to change at page 22, line 21 skipping to change at page 22, line 26
determined, and based on those, the existing solutions for media determined, and based on those, the existing solutions for media
security and especially the keying methods were analysed, and the security and especially the keying methods were analysed, and the
resulting requirements and analysis were published in [RFC5479]. resulting requirements and analysis were published in [RFC5479].
Based on this analysis, and the working group discussion, DTLS-SRTP Based on this analysis, and the working group discussion, DTLS-SRTP
was determined to be the best solution, and the specifications were was determined to be the best solution, and the specifications were
finalized. finalized.
The security solution for SIP using DTLS-SRTP is defined in the The security solution for SIP using DTLS-SRTP is defined in the
Framework for Establishing a Secure Real-time Transport Protocol Framework for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer Security (SRTP) Security Context Using Datagram Transport Layer Security
(DTLS). On a high level it uses SIP with SDP offer/answer procedures (DTLS) [RFC5763]. On a high level it uses SIP with SDP offer/answer
to exchange the network addresses where the server end-point will procedures to exchange the network addresses where the server end-
have a DTLS-SRTP enable server running. The SIP signalling is also point will have a DTLS-SRTP enable server running. The SIP
used to exchange the fingerprints of the certificate each end-point signalling is also used to exchange the fingerprints of the
will use in the DTLS establishment process. When the signalling is certificate each end-point will use in the DTLS establishment
sufficiently completed the DTLS-SRTP client performs DTLS handshakes process. When the signalling is sufficiently completed the DTLS-SRTP
and establishes SRTP session keys. The clients also verify the client performs DTLS handshakes and establishes SRTP session keys.
fingerprints of the certificates to verify that no man in the middle The clients also verify the fingerprints of the certificates to
has inserted themselves into the exchange. verify that no man in the middle has inserted themselves into the
exchange.
At the basic level DTLS has a number of good security properties. At the basic level DTLS has a number of good security properties.
For example, to enable a man in the middle someone in the signalling For example, to enable a man in the middle someone in the signalling
path needs to perform an active action and modify the signalling path needs to perform an active action and modify the signalling
message. There also exist a solution that enables the fingerprints message. There also exist a solution that enables the fingerprints
to be bound to identities established by the first proxy for each to be bound to identities established by the first proxy for each
user[RFC4916]. That reduces the number of nodes the connecting user user [RFC4916]. That reduces the number of nodes the connecting user
UA has to trust to the first hop proxy, rather than the full UA has to trust to the first hop proxy, rather than the full
signalling path. signalling path.
5.2. Media Security for WebRTC Sessions 5.2. Media Security for WebRTC Sessions
Web Real-Time Communication [I-D.ietf-rtcweb-overview] is solution Web Real-Time Communication [I-D.ietf-rtcweb-overview] is solution
providing web-application with real-time media directly between providing web-application with real-time media directly between
browsers. The RTP transported real-time media is protected using a browsers. The RTP transported real-time media is protected using a
mandatory to use application of SRTP. The keying of SRTP is done mandatory to use application of SRTP. The keying of SRTP is done
using DTLS-SRTP. The security configuration is further defined in using DTLS-SRTP. The security configuration is further defined in
skipping to change at page 24, line 38 skipping to change at page 24, line 42
8.4.0, September 2009. 8.4.0, September 2009.
[3GPP.33.246] [3GPP.33.246]
3GPP, "3G Security; Security of Multimedia Broadcast/ 3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 10.0.0, Multicast Service (MBMS)", 3GPP TS 33.246 10.0.0,
December 2010. December 2010.
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a
Single Security Mechanism", Single Security Mechanism",
draft-ietf-avt-srtp-not-mandatory-08 (work in progress), draft-ietf-avt-srtp-not-mandatory-10 (work in progress),
October 2011. July 2012.
[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-00 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-00
(work in progress), May 2012. (work in progress), May 2012.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", Encryption in Secure RTP (SRTP)",
draft-ietf-avtcore-srtp-aes-gcm-01 (work in progress), draft-ietf-avtcore-srtp-aes-gcm-03 (work in progress),
June 2012. September 2012.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Andresason, F., Wing, D., and K. Fischer, McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
"Encrypted Key Transport for Secure RTP", Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
draft-ietf-avtcore-srtp-ekt-00 (work in progress), (work in progress), July 2012.
July 2012.
[I-D.ietf-avtcore-srtp-encrypted-header-ext] [I-D.ietf-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", Real-Time Transport Protocol (SRTP)",
draft-ietf-avtcore-srtp-encrypted-header-ext-01 (work in draft-ietf-avtcore-srtp-encrypted-header-ext-02 (work in
progress), October 2011. progress), July 2012.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-04 (work based Applications", draft-ietf-rtcweb-overview-04 (work
in progress), June 2012. in progress), June 2012.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture",
draft-ietf-rtcweb-security-arch-02 (work in progress), draft-ietf-rtcweb-security-arch-03 (work in progress),
June 2012. July 2012.
[I-D.rescorla-avtcore-random-cname]
Rescorla, E., "Random algorithm for RTP CNAME generation",
draft-rescorla-avtcore-random-cname-00 (work in progress),
July 2012.
[I-D.rescorla-rtcweb-generic-idp] [I-D.rescorla-rtcweb-generic-idp]
Rescorla, E., "RTCWEB Generic Identity Provider Rescorla, E., "RTCWEB Generic Identity Provider
Interface", draft-rescorla-rtcweb-generic-idp-01 (work in Interface", draft-rescorla-rtcweb-generic-idp-01 (work in
progress), March 2012. progress), March 2012.
[ISMACrypt2] [ISMACrypt2]
"ISMA Encryption and Authentication, Version 2.0 release "ISMA Encryption and Authentication, Version 2.0 release
version", November 2007. version", November 2007.
 End of changes. 15 change blocks. 
34 lines changed or deleted 42 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/