draft-ietf-avtcore-rtp-security-options-04.txt   draft-ietf-avtcore-rtp-security-options-05.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. S. Perkins
Expires: January 16, 2014 University of Glasgow Expires: March 02, 2014 University of Glasgow
July 15, 2013 August 29, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-04 draft-ietf-avtcore-rtp-security-options-05
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 January 16, 2014. This Internet-Draft will expire on March 02, 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 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 12 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 11
3.1.3. Key Management for SRTP: Security Descriptions . . . 13 3.1.3. Key Management for SRTP: Security Descriptions . . . 13
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 14
3.1.5. Key Management for SRTP: Other systems . . . . . . . 14 3.1.5. Key Management for SRTP: Other systems . . . . . . . 14
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 14 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15
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. Payload-only Security Mechanisms . . . . . . . . . . . . 16 3.6. Media Content Security/Digital Rights Management . . . . 16
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 17
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 17
4.1. Application Requirements . . . . . . . . . . . . . . . . 17 4.1. Application Requirements . . . . . . . . . . . . . . . . 17
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 17
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 19
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 20 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 21
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 24
5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25 5.3. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 25
5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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, and makes available to the user,
secure modes of operation [RFC3365]. Because of the heterogeneity of secure modes of operation [RFC3365]. Because of the heterogeneity of
RTP applications and use cases, however, a single security solution RTP applications and use cases, however, a single security solution
cannot be mandated. Instead, application developers need to select cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead,
mechanisms that provide appropriate security for their environment. application developers need to select mechanisms that provide
It is strongly encouraged that common mechanisms are used by related appropriate security for their environment. It is strongly
applications in common environments. The IETF publishes guidelines encouraged that common mechanisms are used by related applications in
for specific classes of applications, so it worth searching for such common environments. The IETF publishes guidelines for specific
guidelines. classes of applications, so it 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
RTP can be used in a wide variety of topologies due to it's support RTP can be used in a wide variety of topologies due to its support
for point-to-point sessions, multicast groups, and other topologies for point-to-point sessions, multicast groups, and other topologies
built around different types of RTP middleboxes. In the following we built around different types of RTP middleboxes. In the following we
review the different topologies supported by RTP to understand their review the different topologies supported by RTP to understand their
implications for the security properties and trust relations that can implications for the security properties and trust relations that can
exist in RTP sessions. exist in RTP sessions.
2.1. Point to Point Sessions 2.1. Point to Point Sessions
The most basic use case is two directly connected end-points, shown The most basic use case is two directly connected end-points, shown
in Figure 1, where A has established an RTP session with B. In this in Figure 1, where A has established an RTP session with B. In this
case the RTP security is primarily about ensuring that any third case the RTP security is primarily about ensuring that any third
party can't compromise the confidentiality and integrity of the media party can't compromise the confidentiality and integrity of the media
communication. This requires confidentiality protection of the RTP communication. This requires confidentiality protection of the RTP
session, integrity protection of the RTP/RTCP packets, and source session, integrity protection of the RTP/RTCP packets, and source
authentication of all the packets to ensure no man-in-the-middle authentication of all the packets to ensure no man-in-the-middle
attack is taking place. attack is taking place.
The source authentication can also be tied to a user or an end-points The source authentication can also be tied to a user or an end-
verifiable identity to ensure that the peer knows who they are point's verifiable identity to ensure that the peer knows who they
communicating with. Here the combination of the security protocol are communicating with. Here the combination of the security
protecting the RTP session and its RTP and RTCP traffic and the key- protocol protecting the RTP session and its RTP and RTCP traffic and
management protocol becomes important in which security statements the key-management protocol becomes important in which security
one can do. statements one can do.
+---+ +---+ +---+ +---+
| 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
skipping to change at page 10, line 26 skipping to change at page 10, line 26
authentication tags, Counter mode with CBC-MAC and Galois Counter authentication tags, Counter mode with CBC-MAC and Galois Counter
mode. It also defines a different key derivation function than mode. It also defines a different key derivation function than
the AES based systems. the AES based systems.
AES-192 and AES-256: cryptographic transforms for SRTP based on AES-192 and AES-256: cryptographic transforms for SRTP based on
AES-192 and AES-256 counter mode encryption and 160-bit keyed AES-192 and AES-256 counter mode encryption and 160-bit keyed
HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus
providing 192 and 256 bits encryption keys and NSA Suite B providing 192 and 256 bits encryption keys and NSA Suite B
included cryptographic transforms. Defined in [RFC6188]. included cryptographic transforms. Defined in [RFC6188].
AES-GCM: There is also ongoing work to define AES-GCM (Galois AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC)
Counter Mode) and AES-CCM (Counter with CBC) authentication for authentication for AES-128 and AES-256. This authentication is
AES-128 and AES-256. This authentication is included in the included in the cipher text which becomes expanded with the length
cipher text which becomes expanded with the length of the of the authentication tag instead of using the SRTP authentication
authentication tag instead of using the SRTP authentication tag. tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm].
This is defined in [I-D.ietf-avtcore-srtp-aes-gcm].
[RFC4771] defines a variant of the authentication tag that enables a [RFC4771] defines a variant of the authentication tag that enables a
receiver to obtain the Roll over Counter for the RTP sequence number receiver to obtain the Roll over Counter for the RTP sequence number
that is part of the Initialization vector (IV) for many cryptographic that is part of the Initialization vector (IV) for many cryptographic
transforms. This enables quicker and easier options for joining a transforms. This enables quicker and easier options for joining a
long lived secure RTP group, for example a broadcast session. long lived secure RTP group, for example a broadcast session.
RTP header extensions are normally carried in the clear and only RTP header extensions are normally carried in the clear and only
integrity protected in SRTP. This can be problematic in some cases, integrity protected in SRTP. This can be problematic in some cases,
so [RFC6904] defines an extension to also encrypt selected header so [RFC6904] defines an extension to also encrypt selected header
skipping to change at page 11, line 25 skipping to change at page 11, line 22
binding strong identity verification to an end-point. The default binding strong identity verification to an end-point. The default
key generation will generate a key that contains material contributed key generation will generate a key that contains material contributed
by both peers. The key-exchange happens in the media plane directly by both peers. The key-exchange happens in the media plane directly
between the peers. The common key-exchange procedures will take two between the peers. The common key-exchange procedures will take two
round trips assuming no losses. TLS resumption can be used when round trips assuming no losses. TLS resumption can be used when
establishing additional media streams with the same peer, and reduces establishing additional media streams with the same peer, and reduces
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 suits 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 three
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.
skipping to change at page 14, line 27 skipping to change at page 14, line 31
3.1.4. Key Management for SRTP: Encrypted Key Transport 3.1.4. Key Management for SRTP: Encrypted Key Transport
Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
extension that enables group keying despite using a keying mechanism extension that enables group keying despite using a keying mechanism
like DTLS-SRTP that doesn't support group keys. It is designed for like DTLS-SRTP that doesn't support group keys. It is designed for
centralized conferencing, but can also be used in sessions where end- centralized conferencing, but can also be used in sessions where end-
points connect to a conference bridge or a gateway, and need to be points connect to a conference bridge or a gateway, and need to be
provisioned with the keys each participant on the bridge or gateway provisioned with the keys each participant on the bridge or gateway
uses to avoid decryption and encryption cycles on the bridge or uses to avoid decryption and encryption cycles on the bridge or
gateway. This can enable interworking between DTLS-SRTP and for gateway. This can enable interworking between DTLS-SRTP and other
example security descriptions or other keying systems where either keying systems where either party can set the key (e.g., interworking
part can set the key. with security descriptions).
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: Other systems
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. It wasn't adopted as an IETF standards alternative to DTLS-SRTP. ZRTP provides best effort encryption
track protocol, but was instead published as an informational RFC. independent of the signalling protocol and utilizes key continuity,
Commercial implementations exist. Short Authentication Strings, or a PKI for authentication. ZRTP
wasn't adopted as an IETF standards track protocol, but was instead
published as an informational RFC. Commercial implementations exist.
Additional proprietary solutions are also known to exist. Additional proprietary solutions are also known to exist.
3.2. RTP Legacy Confidentiality 3.2. RTP Legacy Confidentiality
Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based
encryption of RTP and RTCP packets. This mechanism is keyed using encryption of RTP and RTCP packets. This mechanism is keyed using
plain text keys in SDP [RFC4566] using the "k=" SDP field. This plain text keys in SDP [RFC4566] using the "k=" SDP field. This
method can provide confidentiality but, as discussed in Section 9 of method can provide confidentiality but, as discussed in Section 9 of
[RFC3550], it has extremely weak security properties and is not to be [RFC3550], it has extremely weak security properties and is not to be
used. used.
3.3. IPsec 3.3. IPsec
IPsec [RFC4301] can be used in either tunnel or transport mode to IPsec [RFC4301] can be used in either tunnel or transport mode to
skipping to change at page 16, line 11 skipping to change at page 16, line 13
RTP and RTCP packets are completely encrypted with no headers in the RTP and RTCP packets are completely encrypted with no headers in the
clear; when using DTLS-SRTP, the RTP headers are in the clear and clear; when using DTLS-SRTP, the RTP headers are in the clear and
only the payload data is encrypted. only the payload data is encrypted.
DTLS can use similar techniques to those available for DTLS-SRTP to DTLS can use similar techniques to those available for DTLS-SRTP to
bind a signalling-side agreement to communicate to the certificates bind a signalling-side agreement to communicate to the certificates
used by the end-point when doing the DTLS handshake. This enables used by the end-point when doing the DTLS handshake. This enables
use without having a certificate-based trust chain to a trusted use without having a certificate-based trust chain to a trusted
certificate root. certificate root.
There does not appear to be significant usage of RTP over DTLS. There does not appear to be significant usage of DTLS for RTP.
3.5. TLS over TCP 3.5. TLS over TCP
When RTP is sent over TCP [RFC4571] it can also be sent over TLS over When RTP is sent over TCP [RFC4571] it can also be sent over TLS over
TCP [RFC4572], using TLS to provide point to point security services. TCP [RFC4572], using TLS to provide point to point security services.
The security properties TLS provides are confidentiality, integrity The security properties TLS provides are confidentiality, integrity
protection and possible source authentication if the client or server protection and possible source authentication if the client or server
certificates are verified and provide a usable identity. When used certificates are verified and provide a usable identity. When used
in multi-party scenarios using a central node for media distribution, in multi-party scenarios using a central node for media distribution,
the security provide is only between the central node and the peers, the security provide is only between the central node and the peers,
so the security properties for the whole session are dependent on so the security properties for the whole session are dependent on
what trust one can place in the central node. what trust one can place in the central node.
RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the
usage of RTP over the same TLS/TCP connection that the RTSP messages usage of RTP over the same TLS/TCP connection that the RTSP messages
are sent over. It appears that RTP over TLS/TCP is also used in some are sent over. It appears that RTP over TLS/TCP is also used in some
proprietary solutions that uses TLS to bypass firewalls. proprietary solutions that uses TLS to bypass firewalls.
3.6. Payload-only Security Mechanisms 3.6. Media Content Security/Digital Rights Management
Mechanisms have been defined that encrypt only the payload of the RTP Mechanisms have been defined that encrypt only the media content,
packets, and leave the RTP headers and RTCP in the clear. There are operating within the RTP payload data and leaving the RTP headers and
several reasons why this might be appropriate, but a common rationale RTCP unaffected. There are several reasons why this might be
is to ensure that the content stored by RTSP streaming servers has appropriate, but a common rationale is to ensure that the content
the media content in a protected format that cannot be read by the stored by RTSP streaming servers has the media content in a protected
streaming server (this is mostly done in the context of Digital format that cannot be read by the streaming server (this is mostly
Rights Management). These approaches then use a key-management done in the context of Digital Rights Management). These approaches
solution between the rights provider and the consuming client to then use a key-management solution between the rights provider and
deliver the key used to protect the content and do not include the the consuming client to deliver the key used to protect the content
media server in the security context. Such methods have several and do not include the media server in the security context. Such
security weaknesses such the fact that the same key is handed out to methods have several security weaknesses such the fact that the same
a potentially large group of receiving clients, increasing the risk key is handed out to a potentially large group of receiving clients,
of a leak. increasing the risk of a leak.
Use of this type of solution can be of interest in environments that Use of this type of solution can be of interest in environments that
allow middleboxes to rewrite the RTP headers and select which streams allow middleboxes to rewrite the RTP headers and select which streams
are delivered to an end-point (e.g., some types of centralised video are delivered to an end-point (e.g., some types of centralised video
conference systems). The advantage of encrypting and possibly conference systems). The advantage of encrypting and possibly
integrity protecting the payload but not the headers is that the integrity protecting the payload but not the headers is that the
middlebox can't eavesdrop on the media content, but can still provide middlebox can't eavesdrop on the media content, but can still provide
stream switching functionality. The downside of such a system is stream switching functionality. The downside of such a system is
that it likely needs two levels of security: the payload level that it likely needs two levels of security: the payload level
solution to provide confidentiality and source authentication, and a solution to provide confidentiality and source authentication, and a
skipping to change at page 18, line 4 skipping to change at page 18, line 9
4.1.1. Confidentiality 4.1.1. Confidentiality
When it comes to confidentiality of an RTP session there are several When it comes to confidentiality of an RTP session there are several
aspects to consider: aspects to consider:
Probability of compromise: When using encryption to provide media Probability of compromise: When using encryption to provide media
confidentiality, it is necessary to have some rough understanding confidentiality, it is necessary to have some rough understanding
of the security goal and how long one expect the protected content of the security goal and how long one expect the protected content
to remain confidential. National or other regulations might to remain confidential. National or other regulations might
provided additional requirements on a particular usage of an RTP. provide additional requirements on a particular usage of an RTP.
From that, one can determine which encryption algorithms are to be From that, one can determine which encryption algorithms are to be
used from the set of available transforms. used from the set of available transforms.
Potential for other leakage: RTP based security in most of its forms Potential for other leakage: RTP based security in most of its forms
simply wraps RTP and RTCP packets into cryptographic containers. simply wraps RTP and RTCP packets into cryptographic containers.
This commonly means that the size of the original RTP payload is This commonly means that the size of the original RTP payload is
visible to observers of the protected packet flow. This can visible to observers of the protected packet flow. This can
provide information to those observers. A well-documented case is provide information to those observers. A well-documented case is
the risk with variable bit-rate speech codecs that produce the risk with variable bit-rate speech codecs that produce
different sized packets based on the speech input [RFC6562]. different sized packets based on the speech input [RFC6562].
skipping to change at page 18, line 48 skipping to change at page 19, line 10
with the application's usage of centralized nodes, and the details of with the application's usage of centralized nodes, and the details of
the key-management solution chosen, than with the actual choice of the key-management solution chosen, than with the actual choice of
encryption algorithm (although, of course, the encryption algorithm encryption algorithm (although, of course, the encryption algorithm
needs to be chosen appropriately for the desired security level). needs to be chosen appropriately for the desired security level).
4.1.2. Integrity 4.1.2. Integrity
Protection against modification of content by a third party, or due Protection against modification of content by a third party, or due
to errors in the network, is another factor to consider. The first to errors in the network, is another factor to consider. The first
aspect that one considers is what resilience one has against aspect that one considers is what resilience one has against
modifications to the content. This can affect what cryptographic modifications to the content. Some media types are extremely
algorithm is used, and the length of the integrity tags. However sensitive to network bit errors, whereas others might be able to
equally, important is to consider who is providing the integrity tolerate some degree of data corruption. Equally important is to
assertion, what is the source of the integrity tag, and what are the consider the sensitivity of the content, who is providing the
risks of modifications happening prior to that point where protection integrity assertion, what is the source of the integrity tag, and
is applied? RTP applications that rely on central nodes need to what are the risks of modifications happening prior to that point
consider if hop-by-hop integrity is acceptable, or if true end-to-end where protection is applied? These issues affect what cryptographic
integrity protection is needed? Is it important to be able to tell algorithm is used, and the length of the integrity tags, and whether
if a middlebox has modified the data? There are some uses of RTP the entire payload is protected.
that require trusted middleboxes that can modify the data in a way
that doesn't break integrity protection as seen by the receiver, for RTP applications that rely on central nodes need to consider if hop-
by-hop integrity is acceptable, or if true end-to-end integrity
protection is needed? Is it important to be able to tell if a
middlebox has modified the data? There are some uses of RTP that
require trusted middleboxes that can modify the data in a way that
doesn't break integrity protection as seen by the receiver, for
example local advertisement insertion in IPTV systems; there are also example local advertisement insertion in IPTV systems; there are also
uses where it is essential that such in-network modification be uses where it is essential that such in-network modification be
detectable. RTP can support both, with appropriate choices of detectable. RTP can support both, with appropriate choices of
security mechanisms. security mechanisms.
Integrity of the data is commonly closely tied to the question of Integrity of the data is commonly closely tied to the question of
source authentication. That is, it becomes important to know who source authentication. That is, it becomes important to know who
makes an integrity assertion for the data. makes an integrity assertion for the data.
4.1.3. Source Authentication 4.1.3. Source Authentication
Source authentication is about determining who sent a particular RTP Source authentication is about determining who sent a particular RTP
or RTCP packet. It is normally closely tied with integrity, since or RTCP packet. It is normally closely tied with integrity, since a
you also want to ensure that what you received is what the claimed receiver generally also wants to ensure that the data received is
source really sent, so source authentication without integrity is not what the source really sent, so source authentication without
particularly useful. Similarly, integrity without source integrity is not particularly useful. Similarly, integrity
authentication is also not particular useful; you need to know who protection without source authentication is also not particularly
claims this packet wasn't changed. useful; a claim that a packet is unchanged that cannot itself be
validated as from the source (or some from other known and trusted
party) is meaningless.
Source authentication can be asserted in several different ways: Source authentication can be asserted in several different ways:
Base level: Using cryptographic mechanisms that give authentication Base level: Using cryptographic mechanisms that give authentication
with some type of key-management provides an implicit method for with some type of key-management provide an implicit method for
source authentication. Assuming that the mechanism has sufficient source authentication. Assuming that the mechanism has sufficient
strength to not be circumvented in the time frame when you would strength to not be circumvented in the time frame when you would
accept the packet as valid, it is possible to assert a source- accept the packet as valid, it is possible to assert a source-
authenticated statement; this message is likely from someone that authenticated statement; this message is likely from a source that
has the cryptographic key(s) to this communication. has the cryptographic key(s) to this communication.
What that assertion actually means is highly dependent on the What that assertion actually means is highly dependent on the
application and how it handles the keys. If only the two peers application and how it handles the keys. If only the two peers
have access to the keys, this can form a basis for a strong trust have access to the keys, this can form a basis for a strong trust
relationship that traffic is authenticated coming from one of the relationship that traffic is authenticated coming from one of the
peers. However, in a multi-party scenario where security contexts peers. However, in a multi-party scenario where security contexts
are shared among participants, most base-level authentication are shared among participants, most base-level authentication
solutions can't even assert that this packet is from the same solutions can't even assert that this packet is from the same
source as the previous packet. source as the previous packet.
Binding the Source: A step up in the assertion that can be done in Binding the source and the signalling: A step up in the assertion
base-level systems is to tie the signalling to the key-exchange. that can be done in base-level systems is to tie the signalling to
Here, the goal is to at least be able to assert that the sender of the key-exchange. Here, the goal is to at least be able to assert
the packets is the same entity that I have established the session that the source of the packets is the same entity that the
with. How feasible this is depends on the properties of the key- receiver established the session with. How feasible this is
management system used, the ability to tie the signalling to a depends on the properties of the key-management system, the
particular peer, and what trust you place on the different nodes ability to tie the signalling to a particular source, and the
degree of trust the receiver places on the different nodes
involved. involved.
For example, consider a point-to-point communication system that For example, systems where the key-exchange is done using the
uses DTLS-SRTP using self-signed certificates for key management, signalling systems, such as Security Descriptions [RFC4568],
and SIP for signalling. In such a system the end-points for the enable a direct binding between signalling and key-exchange. In
DTLS-SRTP handshake have securely-established keys that are not such systems, the actual security depends on the trust one can
visible to the signalling nodes. However, as the certificates place in the signalling system to correctly associate the peer's
used by DTLS are not bound to any PKI they can't be verified. identity with the key-exchange.
Instead, hashes of the certificate are sent over the signalling
path. If the signalling can be trusted not to collaborate on
performing a man-in-the-middle attack by modifying the hashes,
then the end-points can verify that they have established keys
with the peer they are doing signalling with.
Systems where the key-exchange is done using the signalling
systems, such as Security Descriptions [RFC4568] or MIKEY embedded
in SDP [RFC4567], enable a direct binding between signalling and
key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual
security depends on the trust one can place in the signalling
system to correctly associate the peer's identity with the key-
exchange.
Using Identities: If the applications have access to a system that Using Identities: If the applications have access to a system that
can provide verifiable identities, then the source authentication can provide verifiable identities, then the source authentication
can be bound to that identity. For example, in a point-to-point can be bound to that identity. 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 who is sending the identity, can provide a strong assertion about the source of the
traffic. traffic. SIP identity [RFC4474] provides one example of how this
can be done, and could be used to bind DTLS-SRTP certificates to
the identity provider's public key to authenticate the source of a
DTLS-SRTP flow.
Note that all levels of the system much have matching capability Note that all levels of the system need to have matching
to assert identity. If the signalling can assert that only a capability to assert identity. If the signalling can assert that
given entity in a multiparty session has a key, then the media only a given entity in a multiparty session has a key, then the
layer might be able to provide guarantees about the identity of media layer might be able to provide guarantees about the identity
the media sender. However, using an signalling authentication of the media sender. However, using an signalling authentication
mechanism built on a group key can limit the media layer to mechanism built on a group key can limit the media layer to
asserting only group membership. asserting only group membership.
4.1.4. Identity 4.1.4. Identity
There exist many different types of identity systems with different There exist many different types of identity systems with different
properties. But in the context of RTP applications, the most properties (e.g., SIP identity [RFC4474]). In the context of RTP
important property is the possibility to perform source applications, the most important property is the possibility to
authentication and verify such assertions in relation to any claimed perform source authentication and verify such assertions in relation
identities. What an identity really is can also vary but, in the to any claimed identities. What an identity really is can also vary
context of communication, one of the most obvious is the identity of but, in the context of communication, one of the most obvious is the
the human user one communicates with. However, the human user can identity of the human user one communicates with. However, the human
also have additional identities in a particular role. For example, user can also have additional identities in a particular role. For
the human Alice, can also be a police officer and in some cases her example, the human Alice, can also be a police officer and in some
identity as police officer will be more relevant then that she is cases her identity as police officer will be more relevant then that
Alice. This is common in contact with organizations, where it is she is Alice. This is common in contact with organizations, where it
important to prove the persons right to represent the organization. is important to prove the persons right to represent the
organization. Some examples of identity mechanisms that can be used:
Some examples of identity mechanisms that can be used:
Certificate based: A certificate is used to prove the identity, by Certificate based: A certificate is used to prove the identity, by
having access to the private part of the certificate one can having access to the private part of the certificate one can
perform signing to assert ones identity. Any entity interested in perform signing to assert ones identity. Any entity interested in
verifying the assertion then needs the public part of the verifying the assertion then needs the public part of the
certificate. By having the certificate, one can verify the certificate. By having the certificate, one can verify the
signature against the certificate. The next step is to determine signature against the certificate. The next step is to determine
if one trusts the certificate's trust chain. Commonly by if one trusts the certificate's trust chain. Commonly by
provisioning the verifier with the public part of a root provisioning the verifier with the public part of a root
certificate, this enables the verifier to verify a trust chain certificate, this enables the verifier to verify a trust chain
skipping to change at page 21, line 50 skipping to change at page 22, line 7
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
main privacy concern with IP addresses is related to geographical main privacy concern with IP addresses is related to geographical
location and the possibility to track a user of an end-point. The location and the possibility to track a user of an end-point. The
main way of avoid such concerns is the introduction of relay or main way of avoid such concerns is the introduction of relay (e.g., a
centralized media mixers or forwarders that hides the address of a TURN server [RFC5766]) or centralized media mixers or forwarders that
peer from any other peer. The security and trust placed in these hides the address of a peer from any other peer. The security and
relays obviously needs to be carefully considered. trust placed in these 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. Instead diagnosis, but clearly has privacy implications. Instead
cryptographically random ones could be used as defined by Guidelines cryptographically random ones could be used as defined by Guidelines
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
[I-D.ietf-avtcore-6222bis]. [I-D.ietf-avtcore-6222bis].
skipping to change at page 23, line 45 skipping to change at page 23, line 45
offer/answer procedures to exchange the network addresses where the offer/answer procedures to exchange the network addresses where the
server end-point will have a DTLS-SRTP enable server running. The server end-point will have a DTLS-SRTP enable server running. The
SIP signalling is also used to exchange the fingerprints of the SIP signalling is also used to exchange the fingerprints of the
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.
At the basic level DTLS has a number of good security properties. DTLS has a number of good security properties. For example, to
For example, to enable a man in the middle someone in the signalling enable a man in the middle someone in the signalling path needs to
path needs to perform an active action and modify the signalling perform an active action and modify both the signalling message and
message. There also exists a solution that enables the fingerprints the DTLS handshake. There also exists a solution that enables the
to be bound to identities established by the first proxy for each fingerprints to be bound to identities established by the first proxy
user [RFC4916]. This reduces the number of nodes the connecting user for each user [RFC4474]. This reduces the number of nodes the
User Agent has to trust to include just the first hop proxy, rather connecting user User Agent has to trust to include just the first hop
than the full signalling path. 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 [I-D.ietf-rtcweb-overview] is a solution Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a
providing web applications with real-time media directly between solution providing JavaScript web applications with real-time media
browsers. The RTP-transported real-time media is protected using a directly between browsers. Media is transported using RTP protected
mandatory application of SRTP. The default keying of SRTP is done using a mandatory application of SRTP [RFC3711], with keying done
using DTLS-SRTP. The security configuration is further defined in using DTLS-SRTP [RFC5764]. The security configuration is further
the WebRTC Security Architecture [I-D.ietf-rtcweb-security-arch]. defined in the WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch].
The peers' hash of their certificates are provided to a Javascript
application that is part of a client-server system providing
rendezvous services for the ones a given peer wants to communicate
with. Thus, the handling of the hashes between the peers is not well
defined; it becomes a matter of trust in the application. But,
unless the application and its server is intending to compromise the
communication security, they can provide a secure and integrity-
protected exchange of the certificate hashes thus preventing any man-
in-the-middle (MITM) from inserting itself in the key-exchange.
Unless one uses a Identity provider and the proposed identity A hash of the peer's certificate is provided to the JavaScript web
solution [I-D.ietf-rtcweb-security-arch], the web application still application, allowing that web application to verify identity of the
has the possibility to insert a MITM. In this solution the Identity peer. There are several ways in which the certificate hashes can be
Provider which is a third party to the web application signs the verified. An approach identified in the WebRTC security architecture
DTLS-SRTP hash combined with a statement on which user identity that [I-D.ietf-rtcweb-security-arch] is to use an identity provider. In
has been used to sign the hash. The receiver of such a Identity this solution the Identity Provider, which is a third party to the
assertion then independently verifies the user identity to ensure web application, signs the DTLS-SRTP hash combined with a statement
that it is the identity it intended to communicate and that the on the validity of the user identity that has been used to sign the
cryptographic assertion holds. This way a user can be certain that hash. The receiver of such an identity assertion can then
independently verify the user identity to ensure that it is the
identity that the receiver intended to communicate with, and that the
cryptographic assertion holds; this way a user can be certain that
the application also can't perform a MITM and acquire the keys to the the application also can't perform a MITM and acquire the keys to the
media communication. media communication. Other ways of verifying the certificate hashes
exist, for example they could be verified against a hash carried in
some out of band channel (e.g., compare with a hash printed on a
business card), or using a verbal short authentication string (e.g.,
as in ZRTP [RFC6189]), or using hash continuity.
In the development of WebRTC there has also been attention given to In the development of WebRTC there has also been attention given to
privacy considerations. The main RTP-related concerns that have been privacy considerations. The main RTP-related concerns that have been
raised are: raised are:
Location Disclosure: As ICE negotiation [RFC5245] provides IP Location Disclosure: As ICE negotiation [RFC5245] provides IP
addresses and ports for the browser, this leaks location addresses and ports for the browser, this leaks location
information in the signalling to the peer. To prevent this one information in the signalling to the peer. To prevent this one
can block the usage of any ICE candidate that isn't a relay can block the usage of any ICE candidate that isn't a relay
candidate, i.e. where the IP and port provided belong to the candidate, i.e. where the IP and port provided belong to the
service providers media traffic relay. service providers media traffic relay.
Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP
certificates provide information that could possibly be re-used certificates provide information that is re-used between session
between session instances. Thus to prevent tracking, the same instances. Thus to prevent tracking, such information is ought
information can't be re-used between different communication not be re-used between sessions, or the information ought not sent
sessions. in the clear.
Note: The above cases are focused on providing privacy from other Note: The above cases are focused on providing privacy from other
parties, not on providing privacy from the web server that provides parties, not on providing privacy from the web server that provides
the WebRTC Javascript application. the WebRTC Javascript application.
5.3. 3GPP Packet Based Streaming Service (PSS) 5.3. 3GPP Packet Based Streaming Service (PSS)
The 3GPP Release 11 PSS specification of the Packet Based Streaming The 3GPP Release 11 PSS specification of the Packet Based Streaming
Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of
security mechanisms. These security mechanisms are concerned with security mechanisms. These security mechanisms are concerned with
protecting the content from being captured, i.e. Digital Rights protecting the content from being captured, i.e. Digital Rights
Management. If these goals are to be meet with the specified Management. To meet these goals with the specified solution, the
solution there needs to exist trust in that neither the client implementation and the application platform are trusted to
implementation of the client nor the platform the application runs protect against access and modification by an attacker.
can be accessed or modified by the attacker.
PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus
an RTSP client whose user wants to access a protected content will an RTSP client whose user wants to access a protected content will
request a session description (SDP [RFC4566]) for the protected request a session description (SDP [RFC4566]) for the protected
content. This SDP will indicate that the media is ISMA Crypt 2.0 content. This SDP will indicate that the media is ISMA Crypt 2.0
[ISMACrypt2] protected media encoding application units (AUs). The [ISMACrypt2] protected media encoding application units (AUs). The
key(s) used to protect the media are provided in either of two ways. key(s) used to protect the media are provided in either of two ways.
If a single key is used then the client uses some DRM system to If a single key is used then the client uses some DRM system to
retrieve the key as indicated in the SDP. Commonly OMA DRM v2 retrieve the key as indicated in the SDP. Commonly OMA DRM v2
[OMADRMv2] will be used to retrieve the key. If multiple keys are to [OMADRMv2] will be used to retrieve the key. If multiple keys are to
skipping to change at page 27, line 5 skipping to change at page 27, line 5
7. Security Considerations 7. Security Considerations
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, and Kevin The authors wished to thank Christian Correll, Dan Wing, Kevin Gross,
Gross for review and proposals for improvements of the text. and Ole Jacobsen 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-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]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-avtcore-aria-srtp] [I-D.ietf-avtcore-aria-srtp]
Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
ARIA Algorithm and Its Use with the Secure Real-time ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-03 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-04
(work in progress), June 2013. (work in progress), August 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-07 (work in progress), July 2013. aes-gcm-07 (work in progress), July 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), April 2013. progress), April 2013.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-06 (work based Applications", draft-ietf-rtcweb-overview-07 (work
in progress), February 2013. in progress), August 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-07 (work in progress), July 2013. rtcweb-security-arch-07 (work in progress), July 2013.
[ISMACrypt2] [ISMACrypt2]
, "ISMA Encryption and Authentication, Version 2.0 release , "ISMA Encryption and Authentication, Version 2.0 release
version", November 2007. version", November 2007.
[OMABCAST] [OMABCAST]
skipping to change at page 28, line 51 skipping to change at page 29, line 5
August 2004. August 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February Real-time Transport Protocol (SRTP)", RFC 4383, February
2006. 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
skipping to change at page 29, line 38 skipping to change at page 29, line 45
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, November Multimedia Internet KEYing (MIKEY)", RFC 4738, November
2006. 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real- Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007. time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008. Extensions", RFC 5197, June 2008.
skipping to change at page 30, line 28 skipping to change at page 30, line 35
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Modes of Key Distribution in Multimedia Internet KEYing Modes of Key Distribution in Multimedia Internet KEYing
(MIKEY)", RFC 6043, March 2011. (MIKEY)", RFC 6043, March 2011.
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
RTP", RFC 6188, March 2011. RTP", RFC 6188, March 2011.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189, Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011. April 2011.
 End of changes. 42 change blocks. 
173 lines changed or deleted 176 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/