draft-ietf-avtcore-rtp-security-options-08.txt   draft-ietf-avtcore-rtp-security-options-09.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. Perkins
Expires: April 24, 2014 University of Glasgow Expires: May 16, 2014 University of Glasgow
October 21, 2013 November 12, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-08 draft-ietf-avtcore-rtp-security-options-09
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 April 24, 2014. This Internet-Draft will expire on May 16, 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 . . . . . . . . . . . . . . . . 7 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7
3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11
3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12
3.1.3. Key Management for SRTP: Security Descriptions . . . 14 3.1.3. Key Management for SRTP: Security Descriptions . . . 14
3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15
3.1.5. Key Management for SRTP: Other systems . . . . . . . 15 3.1.5. Key Management for SRTP: Other systems . . . . . . . 15
3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 16
3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16
3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 16 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 17
3.6. Media Content Security/Digital Rights Management . . . . 17 3.6. Media Content Security/Digital Rights Management . . . . 17
3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18
4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18
4.1. Application Requirements . . . . . . . . . . . . . . . . 18 4.1. Application Requirements . . . . . . . . . . . . . . . . 18
4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 18 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 19
4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20
4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22
4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Application Structure . . . . . . . . . . . . . . . . . . 23 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 23 4.3. Automatic Key Management . . . . . . . . . . . . . . . . 23
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4. End-to-End Security vs Tunnels . . . . . . . . . . . . . 24
4.5. Plain Text Keys . . . . . . . . . . . . . . . . . . . . . 24
4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 25
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Media Security for SIP-established Sessions using DTLS- 5.1. Media Security for SIP-established Sessions using DTLS-
SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 25 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 26
5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 26 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 27
5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 26 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 28
5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 27 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 9. Informative References . . . . . . . . . . . . . . . . . . . 30
9. Informative References . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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
(VoIP), centralized multimedia conferencing, sensor data transport, (VoIP), centralized multimedia conferencing, sensor data transport,
and Internet television (IPTV) services. These applications can and Internet television (IPTV) services. These applications can
range from point-to-point phone calls, through centralised group range from point-to-point phone calls, through centralised group
teleconferences, to large-scale television distribution services. teleconferences, to large-scale television distribution services.
The types of media can vary significantly, as can the signalling The types of media can vary significantly, as can the signalling
skipping to change at page 4, line 20 skipping to change at page 4, line 25
RTP can be used in a wide variety of topologies due to its 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- The source authentication can also be tied to a user or an end-
point's verifiable identity to ensure that the peer knows who they point's verifiable identity to ensure that the peer knows who they
are communicating with. Here the combination of the security are communicating with. Here the combination of the security
skipping to change at page 7, line 46 skipping to change at page 7, line 51
In addition the potential large size of multicast groups creates some In addition the potential large size of multicast groups creates some
considerations for the scalability of the solution and how the key- considerations for the scalability of the solution and how the key-
management is handled. management is handled.
2.5. Source-Specific Multicast 2.5. Source-Specific Multicast
Source-Specific Multicast [RFC4607] allows only a specific end-point Source-Specific Multicast [RFC4607] allows only a specific end-point
to send traffic to the multicast group, irrespective of the number of to send traffic to the multicast group, irrespective of the number of
RTP media sources. The end-point is known as the media Distribution RTP media sources. The end-point is known as the media Distribution
Source. Figure 6 shows a sample SSM-based RTP session where several Source. For RTP session to function correctly with RTCP over an SSM
media sources, MS1...MSm, all send media to a Distribution Source, session extensions have been defined in [RFC5760]. Figure 6 shows a
which then forwards the media data to the SSM group for delivery to sample SSM-based RTP session where several media sources, MS1...MSm,
the receivers, R1...Rn, and the Feedback Targets, FT1...FTn. RTCP all send media to a Distribution Source, which then forwards the
reception quality feedback is sent unicast from each receiver to one media data to the SSM group for delivery to the receivers, R1...Rn,
of the Feedback Targets. The feedback targets aggregate reception and the Feedback Targets, FT1...FTn. RTCP reception quality feedback
quality feedback and forward it upstream towards the distribution is sent unicast from each receiver to one of the Feedback Targets.
source. The distribution source forwards (possibly aggregated and The feedback targets aggregate reception quality feedback and forward
summarised) reception feedback to the SSM group, and back to the it upstream towards the distribution source. The distribution source
original media sources. The feedback targets are also members of the forwards (possibly aggregated and summarised) reception feedback to
SSM group and receive the media data, so they can send unicast repair the SSM group, and back to the original media sources. The feedback
data to the receivers in response to feedback if appropriate. targets are also members of the SSM group and receive the media data,
so they can send unicast repair data to the receivers in response to
feedback if appropriate.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm | | MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
^ ^ ^ ^ ^ ^
| | | | | |
V V V V V V
+---------------------------------+ +---------------------------------+
| Distribution Source | | Distribution Source |
+--------+ | +--------+ |
skipping to change at page 12, line 17 skipping to change at page 12, line 27
DTLS-SRTP key management can use the signalling protocol in four DTLS-SRTP key management can use the signalling protocol in four
ways. First, to agree on using DTLS-SRTP for media security. ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where Secondly, to determine the network location (address and port) where
each side is running a DTLS listener to let the parts perform the each side is running a DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Thirdly, to exchange hashes of each side's certificates to bind these Thirdly, to exchange hashes of each side's certificates to bind these
to the signalling, and ensure there is no man-in-the-middle attack. to the signalling, and ensure there is no man-in-the-middle attack.
This assumes that one can trust the signalling solution to be This assumes that one can trust the signalling solution to be
resistant to modification, and not be in collaboration with an resistant to modification, and not be in collaboration with an
attacker. Finally to provide an assertable identity, e.g. [RFC4474] attacker. Finally to provide an assertable identity, e.g. [RFC4474]
that can be used to prevent modification of the signalling and the that can be used to prevent modification of the signalling and the
exchange of certificate hashes. That way enabling binding between exchange of certificate hashes. That way enabling binding between
the key-exchange and the signalling. the key-exchange and the signalling.
This usage is well defined for SIP/SDP in [RFC5763], and in most This usage is well defined for SIP/SDP in [RFC5763], and in most
cases can be adopted for use with other bi-directional signalling cases can be adopted for use with other bi-directional signalling
solutions. It is to be noted that there is work underway to revisit solutions. It is to be noted that there is work underway to revisit
the SIP Identity mechanism [RFC4474] in the IETF STIR working group. the SIP Identity mechanism [RFC4474] in the IETF STIR working group.
The main question regarding DTLS-SRTP's security properties is how The main question regarding DTLS-SRTP's security properties is how
skipping to change at page 14, line 47 skipping to change at page 15, line 13
avoid a "two-time pad" attack - see Section 9 of [RFC3711]). avoid a "two-time pad" attack - see Section 9 of [RFC3711]).
Since keys are transported in plain text in SDP, they can easily be Since keys are transported in plain text in SDP, they can easily be
intercepted unless the SDP carrying protocol provides strong end-to- intercepted unless the SDP carrying protocol provides strong end-to-
end confidentiality and authentication guarantees. This is not end confidentiality and authentication guarantees. This is not
normally the case, where instead hop-by-hop security is provided normally the case, where instead hop-by-hop security is provided
between signalling nodes using TLS. This leaves the keying material between signalling nodes using TLS. This leaves the keying material
sensitive to capture by the traversed signalling nodes. Thus, in sensitive to capture by the traversed signalling nodes. Thus, in
most cases, the security properties of security descriptions are most cases, the security properties of security descriptions are
weak. The usage of security descriptions usually requires additional weak. The usage of security descriptions usually requires additional
security measures, e.g. the signalling nodes be trusted and security measures, e.g. the signalling nodes be trusted and protected
protected by strict access control. Usage of security descriptions by strict access control. Usage of security descriptions requires
requires careful design in order to ensure that the security goals careful design in order to ensure that the security goals can be met.
can be met.
Security Descriptions is the most commonly deployed keying solution Security Descriptions is the most commonly deployed keying solution
for SIP-based end-points, where almost all end-points that support for SIP-based end-points, where almost all end-points that support
SRTP also support Security Descriptions. It is also used for access SRTP also support Security Descriptions. It is also used for access
protection in IMS Media Security [T3GPP.33.328]. protection in IMS Media Security [T3GPP.33.328].
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
skipping to change at page 23, line 41 skipping to change at page 23, line 41
highly dependent on the topology of the communication session. The highly dependent on the topology of the communication session. The
signalling also impacts what information can be provided, and if this signalling also impacts what information can be provided, and if this
can be instance specific, or common for a group. In the end the key- can be instance specific, or common for a group. In the end the key-
management system will highly affect the security properties achieved management system will highly affect the security properties achieved
by the application. At the same time, the communication structure of by the application. At the same time, the communication structure of
the application limits what key management methods are applicable. the application limits what key management methods are applicable.
As different key-management have different requirements on underlying As different key-management have different requirements on underlying
infrastructure it is important to take that aspect into consideration infrastructure it is important to take that aspect into consideration
early in the design. early in the design.
4.3. Interoperability 4.3. Automatic Key Management
The Guidelines for Cryptographic Key Management [RFC4107] provide an
overview of why automatic key management is important. They also
provide a strong recommendation on using automatic key management.
Most of the security solutions reviewed in this document provide or
support automatic key management, at least to establish session keys.
In some more long term use cases, credentials might in certain cases
need to be be manually deployed.
For SRTP an important aspect of automatic key management is to ensure
that two time pads do not occur, in particular by preventing multiple
end points using the same session key and SSRC. In these cases
automatic key management methods can have strong dependencies on
signalling features to function correctly. If those dependencies
can't be fulfilled, additional constrains on usage, e.g., per-end
point session keys, might be needed to avoid the issue.
When selecting security mechanisms for an RTP application it is
important to consider the properties of the key management. Using
key management that is both automatic and integrated will provide
minimal interruption for the user, and is important to ensure that
security can, and will remain, to be on by default.
4.4. End-to-End Security vs Tunnels
If the security mechanism only provides a secured tunnel, for example
like some common uses of IPSec Section 3.3, it is important to
consider the full end-to-end properties of the system. How does one
ensure that the path from the endpoint to the local tunnel ingress/
egress is secure and can be trusted (and similarly for the other end
of the tunnel)? How does one handle the source authentication of the
peer, as the security protocol identifies the other end of the
tunnel. These are some of the issues that arise when one considers a
tunnel based security protocol rather than an end-to-end. Even with
clear requirements and knowledge that one still can achieve the
security properties using a tunnel based solution, one ought to
prefer to use end-to-end mechanisms, as they are much less likely to
violate any assumptions made about deployment. These assumptions can
also be difficult to automatically verify.
4.5. Plain Text Keys
Key management solutions that use plain text keys, like SDP Security
Descriptions (Section 3.1.3), require care to ensure a secure
transport of the signalling messages that contain the plain text
keys. For plain text keys the security properties of the system
depend on how securely the plain text keys are protected end-to-end
between the sender and receiver(s). Not only does one need to
consider what transport protection is provided for the signalling
message including the keys, but also the degree to which any
intermediaries in the signalling are trusted. Untrusted
intermediaries can perform man in the middle attacks on the
communication, or can log the keys with the result in encryption
being compromised significantly after the actual communication
occurred.
4.6. Interoperability
Few RTP applications exist as independent applications that never Few RTP applications exist as independent applications that never
interoperate with anything else. Rather, they enable communication interoperate with anything else. Rather, they enable communication
with a potentially large number of other systems. To minimize the with a potentially large number of other systems. To minimize the
number of security mechanisms that need to be implemented, it is number of security mechanisms that need to be implemented, it is
important to consider if one can use the same security mechanisms as important to consider if one can use the same security mechanisms as
other applications. This can also reduce problems of determining other applications. This can also reduce problems of determining
what security level is actually negotiated in a particular session. what security level is actually negotiated in a particular session.
The desire to be interoperable can, in some cases, be in conflict The desire to be interoperable can, in some cases, be in conflict
skipping to change at page 25, line 46 skipping to change at page 27, line 20
as in ZRTP [RFC6189]), or using hash continuity. 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: static RTP CNAMEs and DTLS-SRTP Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP
certificates provide information that is re-used between session certificates provide information that is re-used between session
instances. Thus to prevent tracking, such information is ought instances. Thus to prevent tracking, such information is ought
not be re-used between sessions, or the information ought not sent not be re-used between sessions, or the information ought not sent
in the clear. Note, that generating new certificates each time in the clear. Note, that generating new certificates each time
prevents continuity in authentication, however, as WebRTC users prevents continuity in authentication, however, as WebRTC users
are expected to use multiple devices to access the same are expected to use multiple devices to access the same
communication service, such continuity can't be expected anyway, communication service, such continuity can't be expected anyway,
skipping to change at page 27, line 4 skipping to change at page 28, line 24
For enterprises and government agencies, which might have weaker For enterprises and government agencies, which might have weaker
trust in the IMS core network and can be assumed to have compatible trust in the IMS core network and can be assumed to have compatible
terminals, end-to-end security can be achieved by deploying their own terminals, end-to-end security can be achieved by deploying their own
key management server. key management server.
Work on Interworking with WebRTC is currently ongoing; the security Work on Interworking with WebRTC is currently ongoing; the security
will still be end-to-access-edge, but using DTLS-SRTP [RFC5763] will still be end-to-access-edge, but using DTLS-SRTP [RFC5763]
instead of security descriptions. instead of security descriptions.
5.4. 3GPP Packet Based Streaming Service (PSS) 5.4. 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 copied, i.e. Digital Rights protecting the content from being copied, i.e. Digital Rights
Management. To meet these goals with the specified solution, the Management. To meet these goals with the specified solution, the
client implementation and the application platform are trusted to client implementation and the application platform are trusted to
protect against access and modification by an attacker. protect against access and modification by an 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 ISMACryp 2.0 content. This SDP will indicate that the media is ISMACryp 2.0
[ISMACryp2] protected media encoding application units (AUs). The [ISMACryp2] 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.
skipping to change at page 27, line 29 skipping to change at page 28, line 50
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
be used, then an additional RTSP stream for key-updates in parallel be used, then an additional RTSP stream for key-updates in parallel
with the media streams is established, where key updates are sent to with the media streams is established, where key updates are sent to
the client using Short Term Key Messages defined in the "Service and the client using Short Term Key Messages defined in the "Service and
Content Protection for Mobile Broadcast Services" section of the OMA Content Protection for Mobile Broadcast Services" section of the OMA
Mobile Broadcast Services [OMABCAST]. Mobile Broadcast Services [OMABCAST].
Worth noting is that this solution doesn't provide any integrity Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header verification method for the RTP header and payload header
information, only the encoded media AU is protected. 3GPP has not information, only the encoded media AU is protected. 3GPP has not
defined any requirement for supporting any solution that could defined any requirement for supporting any solution that could
provide that service. Thus, replay or insertion attacks are provide that service. Thus, replay or insertion attacks are
possible. Another property is that the media content can be possible. Another property is that the media content can be
protected by the ones providing the media, so that the operators of protected by the ones providing the media, so that the operators of
the RTSP server has no access to unprotected content. Instead all the RTSP server has no access to unprotected content. Instead all
that want to access the media is supposed to contact the DRM keying that want to access the media is supposed to contact the DRM keying
server and if the device is acceptable they will be given the key to server and if the device is acceptable they will be given the key to
decrypt the media. decrypt the media.
To protect the signalling, RTSP 1.0 supports the usage of TLS. This To protect the signalling, RTSP 1.0 supports the usage of TLS. This
skipping to change at page 29, line 23 skipping to change at page 30, line 43
ARIA Algorithm and Its Use with the Secure Real-time ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05
(work in progress), September 2013. (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
aes-gcm-10 (work in progress), September 2013. aes-gcm-10 (work in progress), September 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D. and D. Wing, "Encrypted Key Transport for
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in
(work in progress), July 2012. progress), October 2013.
[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-38 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in
progress), October 2013. progress), October 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-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
skipping to change at page 30, line 33 skipping to change at page 32, line 5
MPEG-4 Elementary Streams", RFC 3640, November 2003. MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[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 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
 End of changes. 19 change blocks. 
46 lines changed or deleted 110 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/