draft-ietf-avtcore-rtp-security-options-05.txt   draft-ietf-avtcore-rtp-security-options-06.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. S. Perkins Intended status: Informational C. S. Perkins
Expires: March 02, 2014 University of Glasgow Expires: March 03, 2014 University of Glasgow
August 29, 2013 August 30, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-05 draft-ietf-avtcore-rtp-security-options-06
Abstract Abstract
The Real-time Transport Protocol (RTP) is used in a large number of The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This heterogeneity different application domains and environments. This heterogeneity
implies that different security mechanisms are needed to provide implies that different security mechanisms are needed to provide
services such as confidentiality, integrity and source authentication services such as confidentiality, integrity and source authentication
of RTP/RTCP packets suitable for the various environments. The range of RTP/RTCP packets suitable for the various environments. The range
of solutions makes it difficult for RTP-based application developers of solutions makes it difficult for RTP-based application developers
to pick the most suitable mechanism. This document provides an to pick the most suitable mechanism. This document provides an
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 02, 2014. This Internet-Draft will expire on March 03, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7
2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7
2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 8
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11
3.1.3. Key Management for SRTP: Security Descriptions . . . 13 3.1.3. Key Management for SRTP: Security Descriptions . . . 13
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14
3.1.5. Key Management for SRTP: Other systems . . . . . . . 14 3.1.5. Key Management for SRTP: Other systems . . . . . . . 14
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 15 3.4. DTLS for RTP and RTCP . . . . . . . . . . . . . . . . . . 15
3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16 3.5. TLS over TCP . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Media Content Security/Digital Rights Management . . . . 16 3.6. Media Content Security/Digital Rights Management . . . . 16
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17
4.1. Application Requirements . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 17
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 20
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Application Structure . . . . . . . . . . . . . . . . . . 22 4.2. Application Structure . . . . . . . . . . . . . . . . . . 22
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 22
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Media Security for SIP-established Sessions using DTLS- 5.1. Media Security for SIP-established Sessions using DTLS-
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 24 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 23
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25
5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . 27 9. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
skipping to change at page 11, line 28 skipping to change at page 11, line 28
the set-up time to one RTT for these streams (see [RFC5764] for a the set-up time to one RTT for these streams (see [RFC5764] for a
discussion of TLS resumption in this context). 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. For example DTLS will depend on the cipher suites offered and used. For example
some provide perfect forward secrecy (PFS), while other do not. When some provide perfect forward secrecy (PFS), while other do not. When
using DTLS, the application designer needs to select which cipher using DTLS, the application designer needs to select which cipher
suites DTLS-SRTP can offer and accept so that the desired security suites DTLS-SRTP can offer and accept so that the desired security
properties are achieved. properties are achieved.
DTLS-SRTP key management can use the signalling protocol in three 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.
Finally, to exchange hashes of each side's certificates to verify Thirdly, to exchange hashes of each side's certificates to bind these
their identity, and ensure there is no man-in-the-middle attack. to the signalling, and ensure there is no man-in-the-middle attack.
That way enabling some binding between the key-exchange and the Finally to provide an assertable identity, e.g. [RFC4474] that can
signalling. This usage is well defined for SIP/SDP in [RFC5763], and be used to prevent modification of the signalling and the exchange of
in most cases can be adopted for use with other bi-directions certificate hashes. That way enabling binding between the key-
signalling solutions. exchange and the signalling.
This usage is well defined for SIP/SDP in [RFC5763], and in most
cases can be adopted for use with other bi-directional signalling
solutions. It is to be noted that there is work underway to revisit
the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
DTLS-SRTP usage is clearly on the rise. It is mandatory to support DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
was developed in IETF primarily to meet security requirements for was developed in IETF primarily to meet security requirements for
SIP. SIP.
3.1.2. Key Management for SRTP: MIKEY 3.1.2. Key Management for SRTP: MIKEY
Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol
that has several modes with different properties. MIKEY can be used that has several modes with different properties. MIKEY can be used
in point-to-point applications using SIP and RTSP (e.g., VoIP calls), in point-to-point applications using SIP and RTSP (e.g., VoIP calls),
but is also suitable for use in broadcast and multicast applications, but is also suitable for use in broadcast and multicast applications,
and centralized group communications. and centralized group communications.
MIKEY can establish multiple security contexts or cryptographic MIKEY can establish multiple security contexts or cryptographic
sessions with a single message. It is 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 23, line 48 skipping to change at page 23, line 39
certificate each end-point will use in the DTLS establishment certificate each end-point will use in the DTLS establishment
process. When the signalling is sufficiently completed, the DTLS- process. When the signalling is sufficiently completed, the DTLS-
SRTP client performs DTLS handshakes and establishes SRTP session SRTP client performs DTLS handshakes and establishes SRTP session
keys. The clients also verify the fingerprints of the certificates keys. The clients also verify the fingerprints of the certificates
to verify that no man in the middle has inserted themselves into the to verify that no man in the middle has inserted themselves into the
exchange. exchange.
DTLS has a number of good security properties. For example, to DTLS has a number of good security properties. For example, to
enable a man in the middle someone in the signalling path needs to enable a man in the middle someone in the signalling path needs to
perform an active action and modify both the signalling message and perform an active action and modify both the signalling message and
the DTLS handshake. There also exists a solution that enables the the DTLS handshake. There also exists solutions that enables the
fingerprints to be bound to identities established by the first proxy fingerprints to be bound to identities. SIP Identity provides an
for each user [RFC4474]. This reduces the number of nodes the identity established by the first proxy for each user [RFC4474].
connecting user User Agent has to trust to include just the first hop This reduces the number of nodes the connecting user User Agent has
proxy, rather than the full signalling path. to trust to include just the first hop proxy, rather than the full
signalling path.
5.2. Media Security for WebRTC Sessions 5.2. Media Security for WebRTC Sessions
Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a
solution providing JavaScript web applications with real-time media solution providing JavaScript web applications with real-time media
directly between browsers. Media is transported using RTP protected directly between browsers. Media is transported using RTP protected
using a mandatory application of SRTP [RFC3711], with keying done using a mandatory application of SRTP [RFC3711], with keying done
using DTLS-SRTP [RFC5764]. The security configuration is further using DTLS-SRTP [RFC5764]. The security configuration is further
defined in the WebRTC Security Architecture defined in the WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
skipping to change at page 27, line 6 skipping to change at page 27, line 6
This entire document is about security. Please read it. This entire document is about security. Please read it.
8. Acknowledgements 8. Acknowledgements
We thank the IESG for their careful review of We thank the IESG for their careful review of
[I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this
memo. memo.
The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, The authors wished to thank Christian Correll, Dan Wing, Kevin Gross,
and Ole Jacobsen for review and proposals for improvements of the Alan Johnston and Ole Jacobsen for review and proposals for
text. improvements of the text.
9. Informative References 9. Informative References
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", draft-ietf-avt-srtp-not-mandatory-13 Security Solution", draft-ietf-avt-srtp-not-mandatory-13
(work in progress), May 2013. (work in progress), May 2013.
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
 End of changes. 12 change blocks. 
23 lines changed or deleted 28 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/