One document matched: draft-ietf-avtcore-rtp-security-options-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-avtcore-rtp-security-options-03"
ipr="trust200902">
<front>
<title abbrev="Options for Securing RTP Sessions">Options for Securing RTP
Sessions</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Colin Perkins" initials="C. " surname="Perkins">
<organization>University of Glasgow</organization>
<address>
<postal>
<street>School of Computing Science</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
</address>
</author>
<date day="6" month="May" year="2013"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This heterogeneity
implies that different security mechanisms are needed to provide
services such as confidentiality, integrity and source authentication of
RTP/RTCP packets suitable for the various environments. The range of
solutions makes it difficult for RTP-based application developers to
pick the most suitable mechanism. This document provides an overview of
a number of security solutions for RTP, and gives guidance for
developers on how to choose the appropriate security mechanism.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC3550">Real-time Transport Protocol (RTP)</xref> is
widely used in a large variety of multimedia applications, including
Voice over IP (VoIP), centralized multimedia conferencing, sensor data
transport, and Internet television (IPTV) services. These applications
can range from point-to-point phone calls, through centralised group
teleconferences, to large-scale television distribution services. The
types of media can vary significantly, as can the signalling methods
used to establish the RTP sessions.</t>
<t>This multi-dimensional heterogeneity has so far prevented development
of a single security solution that meets the needs of the different
applications. Instead significant number of different solutions have
been developed to meet different sets of security goals. This makes it
difficult for application developers to know what solutions exist, and
whether their properties are appropriate. This memo gives an overview of
the available RTP solutions, and provides guidance on their
applicability for different application domains. It also attempts to
provide indication of actual and intended usage at time of writing as
additional input to help with considerations such as interoperability,
availability of implementations etc. The guidance provided is not
exhaustive, and this memo does not provide normative
recommendations.</t>
<t>It is important that application developers consider the security
goals and requirements for their application. The IETF considers it
important that protocols implement, and makes available to the user,
secure modes of operation <xref target="RFC3365"/>. Because of the
heterogeneity of RTP applications and use cases, however, a single
security solution cannot be mandated. Instead, application developers
need to select mechanisms that provide appropriate security for their
environment. It is strongly encouraged that common mechanisms are used
by related applications in common environments. The IETF publishes
guidelines for specific classes of applications, so it worth searching
for such guidelines.</t>
<t>The remainder of this document is structured as follows. <xref
target="sec-background"/> provides additional background. <xref
target="sec-options"/> outlines the available security mechanisms at the
time of this writing, and lists their key security properties and
constraints. That is followed by guidelines and important aspects to
consider when securing an RTP application in <xref
target="sec-applications"/>. Finally, we give some examples of
application domains where guidelines for security exist in <xref
target="sec-examples"/>.</t>
</section>
<section anchor="sec-background" title="Background">
<t>RTP can be used in a wide variety of topologies, and combinations of
topologies, due to it's support for unicast, multicast groups, and
broadcast topologies, and the existence of different types of RTP
middleboxes. In the following we review the different topologies
supported by RTP to understand their implications for the security
properties and trust relations that can exist in RTP sessions.</t>
<section title="Point to Point Sessions">
<t>The most basic use case is two directly connected end-points, shown
in <xref target="fig-p2p"/>, where A has established an RTP session
with B. In this case the RTP security is primarily about ensuring that
any third party can't compromise the confidentiality and integrity of
the media communication. This requires confidentiality protection of
the RTP session, integrity protection of the RTP/RTCP packets, and
source authentication of all the packets to ensure no
man-in-the-middle attack is taking place.</t>
<t>The source authentication can also be tied to a user or an
end-points verifiable identity to ensure that the peer knows who they
are communicating with. Here the combination of the security protocol
protecting the RTP session and its RTP and RTCP traffic and the
key-management protocol becomes important in which security statements
one can do.</t>
<figure align="center" anchor="fig-p2p"
title="Point to Point Topology">
<artwork><![CDATA[+---+ +---+
| A |<------->| B |
+---+ +---+
]]></artwork>
</figure>
<t/>
</section>
<section title="Sessions Using an RTP Mixer">
<t>An RTP mixer is an RTP session level middlebox that one can build
an multi-party RTP based conference around. The RTP mixer might
actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the
video of the current active speaker. From a security point of view,
the important features of an RTP mixer is that it generates a new
media stream, and has its own source identifier, and does not simply
forward the original media.</t>
<t>An RTP session using a mixer might have a topology like that in
<xref target="fig-mixer"/>. In this examples, participants A-D each
send unicast RTP traffic between themselves and the RTP mixer, and
receive a RTP stream from the mixer, comprising a mixture of the
streams from the other participants.</t>
<figure align="center" anchor="fig-mixer"
title="Example RTP Mixer topology">
<artwork><![CDATA[+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
]]></artwork>
</figure>
<t>A consequence of an RTP mixer having its own source identifier, and
acting as an active participant towards the other end-points, is that
the RTP mixer needs to be a trusted device that is part of the
security context(s) established. The RTP mixer can also become a
security enforcing entity. For example, a common approach to secure
the topology in <xref target="fig-mixer"/> is to establish a security
context between the mixer and each participant independently, and have
the mixer source authenticate each peer. The mixer then ensures that
one participant cannot impersonate another.</t>
</section>
<section title="Sessions Using an RTP Translator">
<t>RTP translators are middleboxes that provide various levels of
in-network media translation and transcoding. Their security
properties vary widely, depending on which type of operations they
attempt to perform. We identify three different categories of RTP
translator: transport translators, gateways, and media transcoders. We
discuss each in turn.</t>
<section title="Transport Translator (Relay)">
<t>A transport translator <xref target="RFC5117"/> operates on a
level below RTP and RTCP. It relays the RTP/RTCP traffic from one
end-point to one or more other addresses. This can be done based
only on IP addresses and transport protocol ports, with each receive
port on the translator can have a very basic list of where to
forward traffic. Transport translators also need to implement
ingress filtering to prevent random traffic from being forwarded
that isn't coming from a participant in the conference.</t>
<t><xref target="fig-relay"/> shows an example transport translator,
where traffic from any one of the four participants will be
forwarded to the other three participants unchanged. The resulting
topology is very similar to Any source Multicast (ASM) session (as
discussed in <xref target="sec-asm"/>), but implemented at the
application layer.</t>
<figure align="center" anchor="fig-relay"
title="RTP relay translator topology">
<artwork><![CDATA[+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | Relay | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+]]></artwork>
</figure>
<t>A transport translator can often operate without needing to be in
the security context, as long as the security mechanism does not
provide protection over the transport-layer information. A transport
translator does, however, make the group communication visible, and
so can complicate keying and source authentication mechanisms. This
is further discussed in <xref target="sec-asm"/>.</t>
</section>
<section anchor="sec-gateway" title="Gateway">
<t>Gateways are deployed when the endpoints are not fully
compatible. <xref target="fig-gateway"/> shows an example topology.
The functions a gateway provides can be diverse, and range from
transport layer relaying between two domains not allowing direct
communication, via transport or media protocol function initiation
or termination, to protocol or media encoding translation. The
supported security protocol might even be one of the reasons a
gateway is needed.</t>
<figure align="center" anchor="fig-gateway"
title="RTP Gateway Topology">
<artwork><![CDATA[
+---+ +-----------+ +---+
| A |<---->| Gateway |<---->| B |
+---+ +-----------+ +---+
]]></artwork>
</figure>
<t>The choice of security protocol and the details of the gateway
function will determine if the gateway needs to be a trusted part of
the application security context or not. Many gateways need to be
trusted by all peers to perform the translation; in other cases some
or all peers might not be aware of the presence of the gateway. The
security protocols have different properties depending on the degree
of trust and visibility needed. Ensuring communication is possible
without trusting the gateway can be strong incentive for accepting
different security properties. Some security solutions will be able
to detect the gateways as manipulating the media stream, unless the
gateway is a trusted device.</t>
</section>
<section anchor="sec-transcode" title="Media Transcoder">
<t>A Media transcoder is a special type of gateway device that
changes the encoding of the media being transported by RTP. The
discussion in <xref target="sec-gateway"/> applies. A media
transcoder alters the media data, and thus needs to be trusted
device that is part of the security context.</t>
</section>
</section>
<section anchor="sec-asm" title="Any Source Multicast">
<t><xref target="RFC1112">Any Source Multicast</xref> is the original
multicast model where any multicast group participant can send to the
multicast group, and get their packets delivered to all group members
(see <xref target="fig-asm"/>). This form of communication has
interesting security properties, due to the many-to-many nature of the
group. Source authentication is important, but all participants in the
group security context will have access to the necessary secrets to
decrypt and verify integrity of the traffic. Thus use of any symmetric
security functions fails if the goal is to separate individual sources
within the security context; alternate solutions are needed.</t>
<figure align="center" anchor="fig-asm"
title="Any Source Multicast Group">
<artwork><![CDATA[
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / Multi- \ +---+
+ Cast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+]]></artwork>
</figure>
<t>In addition the potential large size of multicast groups creates
some considerations for the scalability of the solution and how the
key-management is handled.</t>
</section>
<section title="Source-Specific Multicast">
<t><xref target="RFC4607">Source Specific Multicast</xref> allows only
a specific end-point to send traffic to the multicast group. That
end-point is labelled the Distribution Source in <xref
target="fig-ssm-session"/>. It distributes traffic from a number of
RTP media sources, MS1 to MSm. <xref target="fig-ssm-session"/> also
depicts the feedback part of the SSM <xref target="RFC5760">RTP
session using unicast feedback</xref> from a number of receivers
R1..Rn that sends feedback to a Feedback Target (FT) and eventually
aggregated and distributed to the group.</t>
<t>The use of SSM makes it more difficult to inject traffic into the
multicast group, but not impossible. Source authentication
requirements apply for SSM sessions too, and a non-symmetric
verification of who sent the RTP and RTCP packets is needed.</t>
<t>The SSM communication channel needs to be securely established and
keyed. In addition one also have the individual unicast feedback that
also needs to be secured.</t>
<figure align="center" anchor="fig-ssm-session"
title="SSM-based RTP session with Unicast Feedback">
<artwork><![CDATA[
+-----+ +-----+ +-----+
| MS1 | | MS2 | .... | MSm |
+-----+ +-----+ +-----+
^ ^ ^
| | |
V V V
+---------------------------------+
| Distribution Source |
+--------+ |
| FT Agg | |
+--------+------------------------+
^ ^ |
: . |
: +...................+
: | .
: / \ .
+------+ / \ +-----+
| FT1 |<----+ +----->| FT2 |
+------+ / \ +-----+
^ ^ / \ ^ ^
: : / \ : :
: : / \ : :
: : / \ : :
: ./\ /\. :
: /. \ / .\ :
: V . V V . V :
+----+ +----+ +----+ +----+
| R1 | | R2 | ... |Rn-1| | Rn |
+----+ +----+ +----+ +----+]]></artwork>
</figure>
<t/>
</section>
</section>
<section anchor="sec-options" title="Security Options">
<t>This section provides an overview of a number of currently defined
security mechanisms that can be used with RTP. This section will use a
number of different security related terms, if they are unknown to the
reader, please consult the <xref target="RFC4949">"Internet Security
Glossary, Version 2"</xref>.</t>
<t>Part of this discussion will be indication of known deployments or at
least requirements in specification to support particular security
solutions. This will most certainly not be a complete picture and also
become obsolete as time progress since the time of writing this
document. The goal with including such information is to help the
designer, given multiple potential solutions that meets the security
design goals one can consider values such as interoperability, maturity
of implementations or experiences with solution components.</t>
<section title="Secure RTP">
<t>The <xref target="RFC3711">Secure RTP (SRTP) protocol</xref> is one
of the most commonly used mechanisms to provide confidentiality,
integrity protection, source authentication and replay protection for
RTP. SRTP was developed with RTP header compression and third party
monitors in mind. Thus the RTP header is not encrypted in RTP data
packets, and the first 8 bytes of the first RTCP packet header in each
compound RTCP packet are not encrypted. The entirety of RTP packets
and compound RTCP packets are integrity protected. This allows RTP
header compression to work, and lets third party monitors determine
what RTP traffic flows exist based on the SSRC fields, but protects
the sensitive content.</t>
<t>The source authentication guarantees provided by SRTP are highly
dependent on the cryptographic transform and key-management scheme
used. In some cases all a receiver can determine is whether the
packets come from someone in the group security context, and not what
group member send the packets. Thus, the source authentication
guarantees depend also on the session topology. Some cryptographic
transform have stronger authentication properties which can guarantee
a given source, even over a multi-party session, e.g. those based on
TESLA <xref target="RFC4383"/>.</t>
<t>SRTP can easily be extended with additional cryptographic
transforms. At the time of this writing, the following transforms are
defined or under definition:<list style="hanging">
<t hangText="AES CM and HMAC-SHA-1:">AES Counter Mode encryption
with 128 bits keys combined with 128 bits keyed HMAC-SHA1 using 80
or 32 bits authentication tags are the default cryptographic
transform which need to be supported. Defined in <xref
target="RFC3711">SRTP</xref>.</t>
<t hangText="AES-f8 and HMAC-SHA-1:">AES f8 mode encryption with
128 bits keys combined with keyed HMAC-SHA1 using 80 or 32 bits
authentication. Defined in <xref target="RFC3711">SRTP</xref>.</t>
<t hangText="TESLA:">As a complement to the regular symmetric
keyed authentication transforms, like HMAC-SHA1. The TESLA based
authentication scheme can provide per-source authentication in
some group communication scenarios. The downside is need for
buffering the packets for a while before authenticity can be
verified. The TESLA transform for SRTP is defined in <xref
target="RFC4383"/>.</t>
<t hangText="SEED:">An Korean national standard cryptographic
transform that is defined to be used with SRTP in <xref
target="RFC5669"/>. It has three modes, one using SHA-1
authentication, one using Counter with CBC-MAC, and finally one
using Galois Counter mode.</t>
<t hangText="ARIA:">An <xref
target="I-D.ietf-avtcore-aria-srtp">Korean block cipher</xref>,
that supports 128, 192 and 256 bits keys. It also has three modes,
Counter mode where combined with HMAC-SHA1 with 80 or 32 bits
authentication tags, Counter mode with CBC-MAC and Galois Counter
mode. It also defines a different key derivation function than the
AES based.</t>
<t hangText="AES-192 and AES-256:">cryptographic transforms for
SRTP based on AES-192 and AES-256 counter mode encryption and
160-bit keyed HMAC-SHA1 with 80 and 32 bits authentication tags
for authentication. Thus providing 192 and 256 bits encryption
keys and NSA Suite B included cryptographic transforms. Defined in
<xref target="RFC6188"/>.</t>
<t hangText="AES-GCM:">There is also ongoing work to define
AES-GCM (Galois Counter Mode) and AES-CCM (Counter with CBC)
authentication for AES-128 and AES-256. This authentication is
included in the cipher text which becomes expanded with the length
of the authentication tag instead of using the SRTP authentication
tag. This is defined in <xref
target="I-D.ietf-avtcore-srtp-aes-gcm"/>.</t>
</list></t>
<t><xref target="RFC4771"/> defines a variant of the authentication
tag that enables a receiver to obtain the Roll over Counter for the
RTP sequence number that is part of the Initialization vector (IV) for
many cryptographic transforms. This enables quicker and easier options
for joining a long lived secure RTP group, for example a broadcast
session.</t>
<t>RTP header extensions are in normally carried in the clear and only
integrity protected in SRTP. This can be problematic in some cases, so
<xref target="RFC6904"/> defines an extension to also encrypt selected
header extensions.</t>
<t>SRTP is specified and deployed in a number of RTP usage contexts;
Significant support in SIP established VoIP clients including IMS;
<xref target="I-D.ietf-mmusic-rfc2326bis">RTSP</xref> and RTP based
media streaming. Thus SRTP in general is widely deployed. When it
comes to cryptographic transforms the default (AES CM and HMAC-SHA1)
is the most common used.</t>
<t>SRTP does not contain an integrated key-management solution, and
instead relies on an external key management protocol. There are
several protocols that can be used. The following sections outline
some popular schemes.</t>
<section title="Key Management for SRTP: DTLS-SRTP">
<t>A Datagram Transport Layer Security extension exists for
establishing SRTP keys <xref target="RFC5763"/><xref
target="RFC5764"/>. This extension provides secure key-exchange
between two peers, enabling perfect forward secrecy and binding
strong identity verification to an end-point. The default key
generation will generate a key that contains material contributed by
both peers. The key-exchange happens in the media plane directly
between the peers. The common key-exchange procedures will take two
round trips assuming no losses. TLS resumption can be used when
establishing additional media streams with the same peer, used
reducing the set-up time to one RTT.</t>
<t>The actual security properties of an established SRTP session
using DTLS will depend on the cipher suits offered and used. For
example some provides perfect forward secrecy (PFS), while other do
not. When using DTLS the application designer needs to select which
cipher suits that DTLS-SRTP can offer and accept so that the desired
security properties are achieved.</t>
<t>DTLS-SRTP key management can use the signalling protocol in three
ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where
each side is running an DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP.
Finally, to exchange hashes of each sides certificates to enable
each side to verify that they have connected to the by signalling
indicated port and not a man in the middle. That way enabling some
binding between the key-exchange and the signalling. This usage is
well defined for SIP/SDP in <xref target="RFC5763"/>, and in most
cases can be adopted for use with other bi-directions signalling
solutions.</t>
<t>DTLS-SRTP usage and inclusion in specification are clearly on the
rise. It is mandatory to support in WebRTC. It has a growing support
among SIP end-points, which is good considering that DTLS-SRTP was
primarily developed in IETF to meet security requirements from
SIP.</t>
</section>
<section title="Key Management for SRTP: MIKEY">
<t><xref target="RFC3830">Multimedia Internet Keying (MIKEY)</xref>
is a keying protocol that has several modes with different
properties. MIKEY can be used in point-to-point applications using
SIP and RTSP (e.g., VoIP calls), but is also suitable for use in
broadcast and multicast applications, and centralized group
communications.</t>
<t>MIKEY can establish multiple security contexts or cryptographic
sessions with a single message. It is possible to use in scenarios
where one entity generates the key and needs to distribute the key
to a number of participants. The different modes and the resulting
properties are highly dependent on the cryptographic method used to
establish the Traffic Generation Key (TGK) that is used to derive
the keys actually used by the security protocol, like SRTP.</t>
<t>MIKEY has the following modes of operation:<list style="hanging">
<t hangText="Pre-Shared Key:">Uses a pre-shared secret for
symmetric key crypto used to secure a keying message carrying
the already generated TGK. This system is the most efficient
from the perspective of having small messages and processing
demands. The downside is scalability, where usually the effort
for the provisioning of pre-shared keys is only manageable, if
the number of endpoints is small.</t>
<t hangText="Public Key encryption:">Uses a public key crypto to
secure a keying message carrying the already generated TGK. This
is more resource consuming but enables scalable systems. It does
require a public key infrastructure to enable verification.</t>
<t hangText="Diffie-Hellman:">Uses Diffie-Hellman key-agreement
to generate the TGK, thus providing perfect forward secrecy. The
downside is increased resource consumption in bandwidth and
processing. This method can't be used to establish group keys as
each pair of peers performing the MIKEY exchange will establish
different keys.</t>
<t hangText="HMAC-Authenticated Diffie-Hellman:"><xref
target="RFC4650"/> defines a variant of the Diffie-Hellman
exchange that uses a pre-shared key in a keyed HMAC to verify
authenticity of the keying material instead of a digital
signature as in the previous method. This method is still
restricted to point-to-point usage.</t>
<t hangText="RSA-R:"><xref target="RFC4738">MIKEY-RSA in Reverse
mode</xref> is a variant of the public key method which doesn't
rely on the initiator of the key-exchange knowing the responders
certificate. This methods lets both the initiator and the
responder to specify the TGK material depending on use case.
Usage of this mode requires one round trip time.</t>
<t hangText="TICKET:"><xref target="RFC6043"/> is a MIKEY
extension using trusted centralized key management service and
tickets, like Kerberos.</t>
<t hangText="IBAKE:"><xref target="RFC6267"/> uses a key
management services (KMS) infrastructure but with lower demand
on the KMS. Claims to provides both perfect forward and
backwards secrecy, the exact meaning is unclear (See <xref
target="RFC4949">Perfect Forward Secrecy in</xref>).</t>
<t hangText="SAKKE:"><xref target="RFC6509"/> provides
Sakai-Kasahara Key Encryption in MIKEY. Based on Identity based
Public Key Cryptography and a KMS infrastructure to establish a
shared secret value and certificate less signatures to provide
source authentication. It features include simplex transmission,
scalability, low-latency call set-up, and support for secure
deferred delivery.</t>
</list></t>
<t>MIKEY messages has several different defined transports. <xref
target="RFC4567"/> defines how MIKEY messages can be embedded in
general SDP for usage with the signalling protocols SIP, SAP and
RTSP. There also exist an 3GPP defined usage of MIKEY that sends
MIKEY messages directly over UDP to key the receivers of <xref
target="T3GPP.33.246">Multimedia Broadcast and Multicast Service
(MBMS)</xref>.</t>
<t>Based on the many choices it is important to consider the
properties needed in ones solution and based on that evaluate which
modes that are candidates for ones usage. More information on the
applicability of the different MIKEY modes can be found in <xref
target="RFC5197"/>.</t>
<t>MIKEY with pre-shared keys are used by <xref
target="T3GPP.33.246">3GPP MBMS</xref>. While <xref
target="I-D.ietf-mmusic-rfc2326bis">RTSP 2.0</xref> specifies use of
the RSA-R mode. There are some SIP end-points that supports MIKEY
and which mode they use are unknown by the authors.</t>
</section>
<section title="Key Management for SRTP: Security Descriptions">
<t><xref target="RFC4568"/> provides a keying solution based on
sending plain text keys in <xref target="RFC4566">SDP</xref>. It is
primarily used with SIP and SDP Offer/Answer, and is well-defined in
point to point sessions where each side declares its own unique key.
Using Security Descriptions to establish group keys is less well
defined, and can have security issues as the SSRC uniqueness
property can't be guaranteed.</t>
<t>Since keys are transported in plain text in SDP, they can easily
be intercepted unless the SDP carrying protocol provides strong
end-to-end confidentiality and authentication guarantees. This is
not the common use of security descriptions with SIP, where instead
hop by hop security is provided between signalling nodes using TLS.
This still leaves the keying material sensitive to capture by the
traversed signalling nodes. Thus in most cases the security
properties of security descriptions are weak. The usage of security
descriptions usually requires additional security measures, e.g. the
signalling nodes be trusted and protected by strict access control.
Usage of security descriptions requires careful design in order to
ensure that the security goals can be met.</t>
<t>Security Descriptions is the most commonly deployed keying
solution for SIP-based end-points, where almost all that supports
SRTP also supports Security Descriptions.</t>
</section>
<section title="Key Management for SRTP: Encrypted Key Transport">
<t><xref target="I-D.ietf-avtcore-srtp-ekt">Encrypted Key Transport
(EKT)</xref> is an SRTP extension that enables group keying despite
using a keying mechanism that can't support group keys, like
DTLS-SRTP. It is designed for centralized conferencing, but can also
be used in sessions where an end-points connect to a conference
bridge or a gateway, and need to be provisioned with the keys each
participant on the bridge or gateway uses to avoid decryption
encryption cycles on the bridge or gateway. This can enable
interworking between DTLS-SRTP and for example security descriptions
or other keying systems where either part can set the key.</t>
<t>The mechanism is based on establishing an additional EKT key
which everyone uses to protect their actual session key. The actual
session key is sent in a expanded authentication tag to the other
session participants. This key are only sent occasionally or
periodically depending on use cases depending on what requirements
exist for timely delivery or notification on when the key is needed
by someone.</t>
<t>The only known deployment of EKT so far are in some Cisco Video
Conferencing products.</t>
</section>
<section title="Key Management for SRTP: Other systems">
<t>The <xref target="RFC6189">ZRTP</xref> key-management system for
SRTP was proposed as an alternative to DTLS-SRTP. It wasn't adopted
as an IETF standards track protocol, but was instead published as an
informational RFC.</t>
<t>Additional proprietary solutions are also known to exist.</t>
<!-- Dan Wing suggested mentioning Microsoft's MS-SSRTP here
http://msdn.microsoft.com/en-us/library/cc431506%28v=office.12%29.aspx
but I don't think that's a sufficiently stable reference. [csp] -->
</section>
</section>
<section title="RTP Legacy Confidentiality">
<t>Section 9 of the RTP standard <xref target="RFC3550"/> defines a
DES or 3DES based encryption of RTP and RTCP packets. This mechanism
is keyed using plain text keys in <xref target="RFC4566">SDP</xref>
using the "k=" SDP field. This method of providing confidentiality has
extremely weak security properties and is not to be used.</t>
</section>
<section title="IPsec">
<t><xref target="RFC4301">IPsec</xref> can be used independent of mode
to protect RTP and RTCP packets in transit from one network interface
to another. This can be sufficient when the network interfaces have a
direct relation, or in a secured environment where it can be
controlled who can read the packets from those interfaces.</t>
<t>The main concern with using IPsec to protect RTP traffic is that in
most cases using a VPN approach that terminates the security
association at some node prior to the RTP end-point leaves the traffic
vulnerable to attack between the VPN termination node and the
end-point. Thus usage of IPsec requires careful thought and design of
its usage so that it really meets the security goals. A important
question is how one ensure the IPsec terminating peer and the ultimate
destination is the same.</t>
<t>IPsec with RTP is more commonly used as security solution between
central nodes in an infrastructure that exchanges many RTP sessions
and media streams between the peers. The establishment of a secure
tunnel between these peers minimizes the key-management overhead
between these two boxes.</t>
</section>
<section title="DTLS">
<t><xref target="RFC6347">Datagram Transport Layer Security (DTLS)
</xref> can provide point to point security for RTP flows. The two
peers would establish an DTLS association between each other,
including the possibility to do certificate-based source
authentication when establishing the association. All RTP and RTCP
packets flowing will be protected by this DTLS association.</t>
<t>Note: using DTLS is different to using DTLS-SRTP key management.
DTLS-SRTP has the core key-management steps in common with DTLS, but
DTLS-SRTP uses SRTP for the per packet security operations, while DTLS
uses the normal datagram TLS data protection. When using DTLS, RTP and
RTCP packets are completely encrypted with no headers in the clear,
while DTLS-SRTP leaves the headers in the clear.</t>
<t>DTLS can use similar techniques to those available for DTLS-SRTP to
bind a signalling side agreement to communicate to the certificates
used by the end-point when doing the DTLS handshake. This enables use
without having a certificate based trust chain to a trusted
certificate root.</t>
<t>There appear to be no significant usage of RTP over DTLS.</t>
</section>
<section title="TLS over TCP">
<t>When RTP is sent over <xref target="RFC4571">TCP</xref> it can also
be sent over <xref target="RFC4572">TLS over TCP</xref>, using TLS to
provide point to point security services. The security properties TLS
provides are confidentiality, integrity protection and possible source
authentication if the client or server certificates are verified and
provide a usable identity. When used in multi-party scenarios using a
central node for media distribution, the security provide is only
between then central node and the peers, so the security properties
for the whole session are dependent on what trust one can place in the
central node.</t>
<t><xref target="RFC2326">RTSP 1.0</xref> and <xref
target="I-D.ietf-mmusic-rfc2326bis">2.0</xref> specifies the usage of
RTP over the same TLS/TCP connection that the RTSP messages are sent
over. It appears that RTP over TLS is also used in some proprietary
solutions that uses TLS to bypass firewalls.</t>
</section>
<section title="Payload-only Security Mechanisms">
<t>Mechanisms have been defined that encrypt only the payload of the
RTP packets, and leave the RTP headers and RTCP in the clear. There
are several reasons why this might be appropriate, but a common
rationale is to ensure that the content stored in RTP hint tracks in
RTSP streaming servers has the media content in a protected format
that cannot be read by the streaming server (this is mostly done in
the context of Digital Rights Management). These approaches then uses
a key-management solution between the rights provider and the
consuming client to deliver the key used to protect the content,
usually after the appropriate method for charging has happened, and do
not include the media server in the security context. Such methods
have several security weaknesses such the fact that the same key is
handed out to a potentially large group of receiving clients,
increasing the risk of a leak.</t>
<t>Use of this type of solution can be of interest in environments
that allow middleboxes to rewrite the RTP headers and select what
streams that are delivered to an end-point (e.g., some types of
centralised video conference systems). The advantage of encrypting and
possibly integrity protecting the payload but not the headers is that
the middlebox can't eavesdrop on the media content, but can still
provide stream switching functionality. The downside of such a system
is that it likely needs two levels of security: the payload level
solution to provide confidentiality and source authentication, and a
second layer with additional transport security ensuring source
authentication and integrity of the RTP headers associated with the
encrypted payloads. This can also results in the need to have two
different key-management systems as the entity protecting the packets
and payloads are different with different set of keys.</t>
<t>The aspect of two tiers of security are present in ISMAcryp (see
<xref target="sec-isma"/>) and the deprecated <xref
target="T3GPP.26.234R8">3GPP Packet Based Streaming Service
Annex.K</xref> solution.</t>
<section anchor="sec-isma" title="ISMA Encryption and Authentication">
<t>The Internet Streaming Media Alliance (ISMA) has defined <xref
target="ISMACrypt2">ISMA Encryption and Authentication 2.0</xref>.
This specification defines how one encrypts and packetizes the
encrypted application data units (ADUs) in an RTP payload using the
<xref target="RFC3640">MPEG-4 Generic payload format</xref>. The ADU
types that are allowed are those that can be stored as elementary
streams in an ISO Media File format based file. ISMAcryp uses SRTP
for packet level integrity and source authentication from a
streaming server to the receiver.</t>
<t>Key-management for a ISMACryp based system can be achieved
through <xref target="OMADRMv2">Open Mobile Alliance (OMA) Digital
Rights Management 2.0</xref>, for example.</t>
</section>
</section>
</section>
<section anchor="sec-applications" title="Securing RTP Applications">
<t>In the following we provide guidelines for how to choose appropriate
security mechanisms for RTP applications.</t>
<section title="Application Requirements">
<t>This section discusses a number of application requirements that
need be considered. An application designer choosing security
solutions requires a good understanding of what level of security is
needed and what behaviour they strive to achieve.</t>
<section title="Confidentiality">
<t>When it comes to confidentiality of an RTP session there are
several aspects to consider:<list style="hanging">
<t hangText="Probability of compromise:">When using encryption
to provide media confidentiality, it is necessary to have some
rough understanding of the security goal and how long one expect
the protected content remain confidential. National or other
regulations might provided additional requirements on a
particular usage of an RTP. From that, one can determine what
encryption algorithms are to be used from the set of available
transforms.</t>
<t hangText="Potential for other leakage:">RTP based security in
most of its forms simply wraps RTP and RTCP packets into
cryptographic containers. This commonly means that the size of
the original RTP payload, and details of the RTP and RTCP
headers, are visible to observers of the protected packet flow.
This can provide information to those observers. A well
documented case is the risk with variable bit-rate speech codecs
that produce different sized packets based on the speech input
<xref target="RFC6562"/>. Potential threats such as these need
to be considered and, if they are significant, then restrictions
will be needed on mode choices in the codec, or additional
padding will need to be added to make all packets equal size and
remove the informational leakage.</t>
<t hangText="">Another case is RTP header extensions. If SRTP is
used, header extensions are normally not protected by the
security mechanism protecting the RTP payload. If the header
extension carries information that is considered sensitive, then
the application needs to be modified to ensure that mechanisms
used to protect against such information leakage are
employed.</t>
<t hangText="Who has access:">When considering the
confidentiality properties of a system, it is important to
consider where the media handled in the clear. For example, if
the system is based on an RTP mixer that needs the keys to
decrypt the media, process, and repacketize it, then is the
mixer providing the security guarantees expected by the other
parts of the system? Furthermore, it is important to consider
who has access to the keys, and are the keys stored or kept
somewhere? The policies for the handling of the keys, and who
can access the keys, need to be considered along with the
confidentiality goals.</t>
</list></t>
<t>As can be seen the actual confidentiality level has likely more
to do with the application's usage of centralized nodes, and the
details of the key-management solution chosen, than with the actual
choice of encryption algorithm (although, of course, the encryption
algorithm needs to be chosen appropriately for the desired security
level).</t>
</section>
<section title="Integrity">
<t>Protection against modification of content by a third party, or
due to errors in the network, is another factor to consider. The
first aspect that one consider is what resilience one has against
modifications to the content. This can affect what cryptographic
algorithm is used, and the length of the integrity tags. However
equally, important is to consider who is providing the integrity
assertion, what is the source of the integrity tag, and what are the
risks of modifications happening prior to that point where
protection is applied? 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 uses where it is essential that such in-network
modification be detectable. RTP can support both, with appropriate
choices of security mechanisms.</t>
<t>Integrity of the data is commonly closely tied to the question of
source authentication. That is, it becomes important to know who
makes an integrity assertion for the data.</t>
</section>
<section title="Source Authentication">
<t>Source authentication is about determining who sent a particular
RTP or RTCP packet. It is normally closely tied with integrity,
since you also want to ensure that what you received is what the
claimed source really sent, so source authentication without
integrity is not particularly useful. In similar way, although not
as definitive, is that integrity without source authentication is
also not particular useful: you need to know who claims this packet
wasn't changed.</t>
<t>Source authentication can be asserted in several different ways:
<list style="hanging">
<t hangText="Base level:">Using cryptographic mechanisms that
give authentication with some type of key-management provides an
implicit method for source authentication. Assuming that the
mechanism has sufficient strength to not be circumvented in the
time frame when you would accept the packet as valid, it is
possible to assert a source authenticated statement; this
message is highly probably from someone that has the
cryptographic key(s) to this communication.</t>
<t hangText="">What that assertion actually means is highly
dependent on the application, and how it handles the keys. In an
application where the key-handling is limited to two peers, this
can form a basis for a trust relationship to the level that you
can state as the traffic is authenticated and matching this
particular context. Thus, it is coming either from me or from my
peer (and I trust that neither has shared the key with anyone
else). However, in a multi-party scenario where security
contexts are shared among participants, most base-level
authentication solutions can't even assert that this packet is
from the same source as the previous packet.</t>
<t hangText="Binding the Source:">A step up in the assertion
that can be done in base-level systems is to tie the signalling
to the key-exchange. Here, the goal is to be at least be able to
assert that the sender of the packets is the same entity that I
have established the session with. How feasible this is depends
on the properties of the key-management system used, the ability
to tie the signalling to a particular peer, and what trust you
place on the different nodes involved.</t>
<t hangText="">For example, consider a point to point
communication system that use DTLS-SRTP using self-signed
certificates for key-management, and SIP for signalling. In such
a system the end-points for the DTLS-SRTP handshake have
securely established keys that are not visible to the signalling
nodes. However, as the certificates used by DTLS is not bound to
any PKI they can't be verified. Instead, hashes over 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.</t>
<t hangText="">Systems where the key-exchange are done using the
signalling systems, such as <xref target="RFC4568">Security
Descriptions</xref> or <xref target="RFC4567">MIKEY embedded in
SDP</xref>, enables an 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.</t>
<t hangText="Using Identities:">If the applications have access
to a system that can provide verifiable identities, then the
source authentication can be bound to that identity. For
example, in a point-to-point communication even symmetric key
crypto, where the key-management can assert that the key has
only been exchanged with a particular identity, can provide a
strong assertion about who is sending the traffic.</t>
<t hangText="">Note that all levels of the system much have
matching capability to assert identity. Having the signalling
assert that you include a particular identity in a multi-party
communication session where the key-management systems establish
keys in a way that one can assert that only the given identity
has gotten the key. Using a authentication mechanism built on a
group key that otherwise can't provide any assertion who sent
the traffic than anyone that got the key, provides no strong
assertion on the media level than: Someone that has gotten the
security context (key) sent this traffic.</t>
</list></t>
<t/>
</section>
<section title="Identity">
<t>There exist many different types of identity systems with
different properties. But in the context of RTP applications the
most important property is the possibility to perform source
authentication and verify such assertions in relation to any claimed
identities. What an identity really are can also vary, but in the
context of communication, one of the most obvious is the identity of
the human user one communicates with. However, the human user can
also have additional identities in a particular role. For example,
the human Alice, can also be a police officer and in some cases her
identity as police officer will be more relevant then that she is
Alice. This is common in contact with organizations, where it is
important to prove the persons right to represent the
organization.</t>
<t>Some examples of identity mechanisms that could be used:<list
style="hanging">
<t hangText="Certificate based:">A certificate is used to prove
the identity, by having access to the private part of the
certificate one can perform signing to assert ones identity. Any
entity interested in verifying the assertion then needs the
public part of the certificate. By having the certificate one
can verify the signing against the certificate. The next step is
to determine if one trusts the certificate's trust chain.
Commonly by provisioning the verifier with the public part of a
root certificate, this enables the verifier to verify a trust
chain from the root certificate down to the identity
certificate. However, the trust is based on that all steps in
the certificate chain are verifiable and can be trusted. Thus
provisioning of root certificates, having possibility to revoke
compromised certificates are aspects that will require
infrastructure.</t>
<t hangText="Online Identity Providers:">An online identity
provider (IdP) can authenticate a user's right to use an
identity, then perform assertions on their behalf or provision
the requester with short-term credentials to assert their
identity. The verifier can then contact the IdP to request
verification of a particular identity. Here the trust is highly
dependent on how much one trusts the IdP. The system also
becomes dependent on having access to the relevant IdP.</t>
</list></t>
<t>In all of the above examples, an important part of the security
properties are related to the method for authenticating the access
to the identity.</t>
</section>
<section title="Privacy">
<t>RTP applications need to consider what privacy goals they have.
As RTP applications communicate directly between peers in many
cases, the IP addresses of any communication peer will be available.
The main privacy concern with IP addresses is related to
geographical 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 centralized media mixers or forwarders that hides the
address of a peer from any other peer. The security and trust placed
in these relays obviously needs to be carefully considered.</t>
<t>RTP itself can contribute to enabling a particular user to be
tracked between communication sessions if the CNAME is generated
according to the RTP specification in the form of user@host. Such
RTCP CNAMEs are likely long term stable over multiple sessions,
allowing tracking of users. This can be desirable for long-term
fault tracking and diagnosis, but clearly has privacy implications.
Instead cryptographically random ones could be used as defined by
<xref target="I-D.ietf-avtcore-6222bis">Guidelines for Choosing RTP
Control Protocol (RTCP) Canonical Names (CNAMEs)</xref>.</t>
<t>If there exist privacy goals, these need to be considered, and
the system designed with them in mind. In addition certain RTP
features might have to be configured to safeguard privacy, or have
requirements on how the implementation is done.</t>
</section>
</section>
<section title="Application Structure">
<t>When it comes to RTP security, the most appropriate solution is
often highly dependent on the topology of the communication session.
The 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-management system will highly affect the security properties
achieved by the application. At the same time, the communication
structure of the application limits what key management methods are
applicable. As different key-management have different requirements on
underlying infrastructure it is important to take that aspect into
consideration early in the design.</t>
</section>
<section title="Interoperability">
<t>Few RTP applications exist as independent applications that never
interoperate with anything else. Rather, they enable communication
with a potentially large number of other systems. To minimize the
number of security mechanisms that need to be implemented, it is
important to consider if one can use the same security mechanisms as
other applications. This can also reduce the problems of determining
what security level is actually negotiated in a particular
session.</t>
<t>The desire to be interoperable can in some cases be in conflict
with the security requirements determined for an application. To meet
the security goals, it might be necessary to sacrifice
interoperability. Alternatively, one can implement multiple security
mechanisms, but then end up with an issue of ensuring that the user
understands what it means to use a particular security level. In
addition, the application can then become vulnerable to bid-down
attack.</t>
</section>
</section>
<section anchor="sec-examples" title="Examples">
<t>In the following we describe a number of example security solutions
for RTP using applications, services or frameworks. These examples are
provided to show the choices that can be made. They are not normative
recommendations for security.</t>
<section title="Media Security for SIP-established Sessions using DTLS-SRTP">
<t>The IETF evaluated media security for RTP sessions established
using point-to-point SIP sessions in 2009. A number of requirements
were determined, and based on those, the existing solutions for media
security and especially the keying methods were analysed, and the
resulting requirements and analysis were published in <xref
target="RFC5479"/>. Based on this analysis, and the working group
discussion, DTLS-SRTP was determined to be the best solution, and the
specifications were finalized.</t>
<t>The security solution for SIP using DTLS-SRTP is defined in the
<xref target="RFC5763">Framework for Establishing a Secure Real-time
Transport Protocol (SRTP) Security Context Using Datagram Transport
Layer Security (DTLS)</xref>. On a high level it uses SIP with SDP
offer/answer procedures to exchange the network addresses where the
server end-point will have a DTLS-SRTP enable server running. The SIP
signalling is also used to exchange the fingerprints of the
certificate each end-point will use in the DTLS establishment process.
When the signalling is sufficiently completed the DTLS-SRTP client
performs DTLS handshakes and establishes SRTP session keys. The
clients also verify the fingerprints of the certificates to verify
that no man in the middle has inserted themselves into the
exchange.</t>
<t>At the basic level DTLS has a number of good security properties.
For example, to enable a man in the middle someone in the signalling
path needs to perform an active action and modify the signalling
message. There also exist a solution that enables the fingerprints to
be bound to identities established by the first proxy for each user
<xref target="RFC4916"> </xref>. That reduces the number of nodes the
connecting user User Agent has to trust to the first hop proxy, rather
than the full signalling path.</t>
</section>
<section title="Media Security for WebRTC Sessions">
<t><xref target="I-D.ietf-rtcweb-overview">Web Real-Time
Communication</xref> is solution providing web-application with
real-time media directly between browsers. The RTP transported
real-time media is protected using a mandatory to use application of
SRTP. The default keying of SRTP is done using DTLS-SRTP. The security
configuration is further defined in the <xref
target="I-D.ietf-rtcweb-security-arch">WebRTC Security
Architecture</xref>.</t>
<t>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) to insert itself in the key-exchange.</t>
<t>The web application still have the possibility to insert a MITM.
That unless one uses a Identity provider and the proposed <xref
target="I-D.ietf-rtcweb-security-arch">identity solution</xref>. In
this solution the Identity Provider which is a third party to the
web-application signs the DTLS-SRTP hash combined with a statement on
which user identity that has been used to sign the hash. The receiver
of such a Identity assertion then independently verifies the user
identity to ensure that it is the identity it intended to communicate
and that the cryptographic assertion holds. That way a user can be
certain that the application also can't perform an MITM and that way
acquire the keys to the media communication.</t>
<t>In the development of WebRTC there has also been high attention on
privacy question. The main concerns that has been raised and are at
all related to RTP are:<list style="hanging">
<t hangText="Location Disclosure:">As ICE negotiation provides IP
addresses and ports for the browser, this leaks location
information in the signalling to the peer. To prevent this one 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 service
providers media traffic relay.</t>
<t hangText="Prevent tracking between sessions:">RTP CNAMEs and
DTLS-SRTP certificates is information that could possibly be
re-used between session instances. Thus to prevent tracking the
same information can't be re-used between different communication
sessions.</t>
</list></t>
<t>Note: The above cases are focused on providing privacy towards
other parties than the web service.</t>
</section>
<section anchor="sec-examples-pss"
title="3GPP Packet Based Streaming Service (PSS) ">
<t>The 3GPP Release 11 PSS specification of the Packet Based Streaming
Service <xref target="T3GPP.26.234R11">(PSS)</xref> defines in Annex R
a set of security mechanisms. These security mechanisms are centred
around protecting the content from being captured, i.e. Digital Rights
Management. If these goals are to be meet with the specified solution
there needs to exist trust in that neither the implementation of the
client nor the platform the application runs can be accessed or
modified by the attacker.</t>
<t>PSS is <xref target="RFC2326">RTSP 1.0</xref> controlled media
streaming over RTP. Thus an RTSP client whose user wants to access a
protected content will request a session description (<xref
target="RFC4566">SDP</xref>) for the protected content. This SDP will
indicate that the media are <xref target="ISMACrypt2">ISMA Crypt
2.0</xref> protected media encoding application units (AUs). The
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
retrieve the key as indicated in the SDP. Commonly <xref
target="OMADRMv2">OMA DRM v2</xref> will be used to retrieve the key.
If multiple keys are to be used, then using RTSP an additional stream
for key-updates in parallel with the media streams are established,
where key updates are sent to the client using Short Term Key Messages
defined by "Service and Content Protection for Mobile Broadcast
Services" part of the <xref target="OMABCAST">OMA Mobile Broadcast
Services</xref>.</t>
<t>Worth noting is that this solution doesn't provide any integrity
verification method for the RTP header and payload header information,
only the encoded media AU is protected. 3GPP has not defined any
requirement for supporting SRTP or other solution that could provide
that service. Thus, replay or insertion attacks are possible. Another
property is that the media content can be protected by the ones
providing the media, so that the operators of the RTSP server has no
access to unprotected content. Instead all 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 decrypt the media.</t>
<t>To protect the signalling RTSP 1.0 supports the usage of TLS, this
is however not explicitly discussed in the PSS specification. Usage of
TLS can prevent both modification of the session description
information and help maintain some privacy of what content the user is
watching as all URLs would then be confidentiality protected.</t>
</section>
<section title="RTSP 2.0">
<t><xref target="I-D.ietf-mmusic-rfc2326bis">Real-time Streaming
Protocol 2.0</xref> can be an interesting comparison to the <xref
target="sec-examples-pss">PSS service</xref> that is based on RTSP 1.0
and service requirements perceived by mobile operators. A major
difference between RTSP 1.0 and RTSP 2.0 is that 2.0 is fully defined
under the requirement to have mandatory to implement security
mechanism. As it specifies how one transport media over RTP it is also
defining security mechanisms for the RTP transported media
streams.</t>
<t>The security goals for RTP in RTSP 2.0 is to ensure that there are
confidentiality, integrity and source authentication between the RTSP
server and the client. This to prevent eavesdropping on what the user
is watching for privacy reasons and prevent replay or injection
attacks on the media stream. To reach these goals also the signalling
has to be protected, requiring the use of TLS between the client and
server.</t>
<t>Using TLS protected signalling the client and server agrees on the
media transport method when doing the SETUP request and response. The
secured media transport is SRTP (SAVP/RTP) normally over UDP. The key
management for SRTP is MIKEY using RSA-R mode. The RSA-R mode is
selected as it allows the RTSP Server to select the key, despite
having the RTSP Client initiate the MIKEY exchange. It also enables
the reuse of the RTSP servers TLS certificate when creating the MIKEY
messages thus ensuring a binding between the RTSP server and the
key-exchange. Assuming the SETUP process works, this will establish a
SRTP crypto context to be used between the RTSP Server and the Client
for the RTP transported media streams.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section can be removed on publication as an
RFC.</t>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>This entire document is about security. Please read it.</t>
</section>
<section anchor="sec-ack" title="Acknowledgements">
<t>We thank the IESG for their careful review of <xref
target="I-D.ietf-avt-srtp-not-mandatory"/> which led to the writing of
this memo.</t>
<t>The authors wished to thank Christian Correll for review and great
proposals for improvements of the text.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.1112'?>
<?rfc include='reference.RFC.2326'?>
<?rfc include='reference.RFC.3365'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3640'?>
<?rfc include='reference.RFC.3711'?>
<?rfc include='reference.RFC.3830'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.4383'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4567'?>
<?rfc include='reference.RFC.4568'?>
<?rfc include='reference.RFC.4571'?>
<?rfc include='reference.RFC.4572'?>
<?rfc include='reference.RFC.4607'?>
<?rfc include='reference.RFC.4650'?>
<?rfc include='reference.RFC.4738'?>
<?rfc include='reference.RFC.4771'?>
<?rfc include='reference.RFC.4916'?>
<?rfc include='reference.RFC.4949'?>
<?rfc include='reference.RFC.5117'?>
<?rfc include='reference.RFC.5197'?>
<?rfc include='reference.RFC.5479'?>
<?rfc include='reference.RFC.5669'?>
<?rfc include='reference.RFC.5760'?>
<?rfc include='reference.RFC.5763'?>
<?rfc include='reference.RFC.5764'?>
<?rfc include='reference.RFC.6043'?>
<?rfc include='reference.RFC.6188'?>
<?rfc include='reference.RFC.6189'?>
<?rfc include='reference.RFC.6267'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.RFC.6509'?>
<?rfc include='reference.RFC.6562'?>
<?rfc include='reference.RFC.6904'?>
<?rfc include='reference.I-D.ietf-avt-srtp-not-mandatory'?>
<?rfc include='reference.I-D.ietf-avtcore-aria-srtp'?>
<?rfc include='reference.I-D.ietf-avtcore-srtp-aes-gcm'?>
<?rfc include='reference.I-D.ietf-avtcore-srtp-ekt'?>
<?rfc include='reference.I-D.ietf-mmusic-rfc2326bis'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
<?rfc include='reference.I-D.ietf-avtcore-6222bis'?>
<reference anchor="ISMACrypt2">
<front>
<title>ISMA Encryption and Authentication, Version 2.0 release
version</title>
<author fullname="Internet Streaming Media Alliance (ISMA)">
<organization/>
</author>
<date month="November" year="2007"/>
</front>
<format target="http://www.mpegif.org/m4if/bod/ISMA/ISMA_E%26Aspec2.0.pdf"
type="PDF"/>
</reference>
<reference anchor="OMADRMv2">
<front>
<title>OMA Digital Rights Management V2.0</title>
<author fullname="Open Mobile Alliance">
<organization>Open Mobile Alliance</organization>
</author>
<date day="23" month="July" year="2008"/>
</front>
<format target="http://www.openmobilealliance.org/technical/release_program/drm_v2_0.aspx"
type="HTML"/>
</reference>
<reference anchor="OMABCAST">
<front>
<title>OMA Mobile Broadcast Services V1.0</title>
<author fullname="Open Mobile Alliance">
<organization>Open Mobile Alliance</organization>
</author>
<date day="1" month="February" year="2009"/>
</front>
<format target="http://technical.openmobilealliance.org/Technical/release_program/bcast_v1_0.aspx"
type="HTML"/>
</reference>
<reference anchor="T3GPP.26.234R8">
<front>
<title>Technical Specification Group Services and System Aspects;
Transparent end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs</title>
<author fullname="3GPP">
<organization>3GPP</organization>
</author>
<date month="September" year="2009"/>
</front>
<seriesInfo name="3GPP TS" value="26.234 8.4.0"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/23234.htm"
type="HTML"/>
</reference>
<reference anchor="T3GPP.26.234R11">
<front>
<title>Technical Specification Group Services and System Aspects;
Transparent end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs</title>
<author fullname="3GPP">
<organization>3GPP</organization>
</author>
<date month="September" year="2012"/>
</front>
<seriesInfo name="3GPP TS" value="26.234 11.1.0"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/23234.htm"
type="HTML"/>
</reference>
<reference anchor="T3GPP.26.346">
<front>
<title>Multimedia Broadcast/Multicast Service (MBMS); Protocols and
codecs</title>
<author>
<organization>3GPP</organization>
</author>
<date day="20" month="March" year="2013"/>
</front>
<seriesInfo name="3GPP TS" value="26.346 10.7.0"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/26346.htm"
type="HTML"/>
</reference>
<reference anchor="T3GPP.33.246">
<front>
<title>3G Security; Security of Multimedia Broadcast/Multicast
Service (MBMS)</title>
<author>
<organization>3GPP</organization>
</author>
<date day="21" month="December" year="2012"/>
</front>
<seriesInfo name="3GPP TS" value="33.246 10.1.0"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/33246.htm"
type="HTML"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:12 |