One document matched: draft-wing-avt-dtls-srtp-key-transport-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-avt-dtls-srtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-dtls-srtp.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY I-D.ietf-mmusic-sdp-capability-negotiation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-capability-negotiation.xml">
<!ENTITY rfc5117 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5117.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY I-D.ietf-msec-gdoi-srtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-msec-gdoi-srtp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-avt-dtls-srtp-key-transport-01"
ipr="full3978">
<front>
<title abbrev="DTLS-SRTP Key Transport">Datagram TLS Secure RTP
(DTLS-SRTP) Key Transport</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date year="2008" />
<workgroup>AVT Working Group</workgroup>
<abstract>
<t>The existing DTLS-SRTP specification allows SRTP keys to be
established between a pair of SRTP endpoints. However, when there are
more than two participants in an RTP session, DTLS-SRTP is unable to
provide a single key for all of the participants. This existing
limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain
scenarios.</t>
<t>This document describes an extension to DTLS-SRTP which transports
SRTP keying material from one DTLS-SRTP peer to another, so the same
SRTP keying material can be used by multiple DTLS-SRTP peers. This
extension reduces (and often eliminates) the need to key each SRTP
session individually, allowing deployment of several DTLS-SRTP
scenarios.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Unique SRTP master keys can be established, in each direction, using
<xref target="I-D.ietf-avt-dtls-srtp">DTLS-SRTP</xref>. Using DTLS, each
peer contributes part of the keying material to generate the eventual
SRTP master key.</t>
<t>In some scenarios after the DTLS handshake has completed, it is
desirable for one peer to change its SRTP key and to transmit SRTP
packets using an SRTP key that was not derived from the DTLS key
exchange. These scenarios are described in <xref
target="sec_scenarios"></xref>.</t>
<t>The extensions described in this document allow transporting an SRTP
master key from one DTLS peer to the other. Thus, DTLS Key Transport
differs from normal DTLS-SRTP in that the SRTP master key is not derived
from the TLS handshake.</t>
</section>
<section title="Notational Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="sec_scenarios" title="Scenarios">
<t>DTLS Key Transport allows mixers and video switchers to avoid having
to encrypt each packet multiple times under multiple SRTP keys. DTLS Key
Transport causes sharing of SRTP keys.</t>
<t>Several SRTP scenarios that benefit from DTLS-SRTP Key Transport are
described in the following sections, using terminology from <xref
target="RFC5117">RTP Topologies</xref>.</t>
<section anchor="section_point_multipoint"
title="Point to Multipoint using the RFC 3550 mixer model">
<t>This RTP scenario is described in Section 3.4 of <xref
target="RFC5117">RTP Topologies</xref>.</t>
<t>With DTLS-SRTP, this topology is computationally expensive for the
video switcher because it has to encrypt the payload uniquely for each
SRTP listener. Additionally, the architecture of a typical mixer
requires each listener's SRTP to be encrypted serially, incurring
additional delay for each successive listener. This is depicted below
in <xref target="multipoint-without-kt"></xref>.</t>
<figure anchor="multipoint-without-kt"
title="Point to Multipoint Mixer, without DTLS Key Transport">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------key=F-------+
| |
V +-------+ +------------+
+----+----+ | +--key=C->+ listener 1 |
| speaker +--key=A-->+ | +------------+
+---------+ | | +------------+
| mixer +--key=D->+ listener 2 |
+---------+ | | +------------+
| speaker +--key=B-->+ | +------------+
+----+----+ | +--key=E->+ listener 3 |
^ +---+---+ +------------+
| |
+-------key=G-------+
]]></artwork>
<postamble></postamble>
</figure>
<t>With DTLS Key Transport, the mixer can maintain one outbound SRTP
cryptographic context, and encrypt the SRTP once for all listeners.
This is depicted below in <xref
target="multipoint-with-kt"></xref>.</t>
<figure anchor="multipoint-with-kt"
title="Point to Multipoint Mixer, with DTLS Key Transport">
<preamble>In the following figure, "=" indicates sessions where
DTLS-SRTP Key Transport is used, and "-" indicates where only
DTLS-SRTP is necessary. In this topology, only the listeners need
support DTLS-SRTP Key Transport so that the switcher and the
listeners can benefit from DTLS-SRTP Key Transport. In this scenario
with DTLS-SRTP Key Transport, the mixer assumes an additional role
-- group's key server -- and provides a common group SRTP key ("C")
to all of the listeners. This group SRTP key is shared between all
of the listeners.</preamble>
<artwork align="center"><![CDATA[
+=======key=C=======+
| |
V +---+---+ +------------+
+---------+ | +==key=C=>+ listener 1 |
| speaker +--key=A-->+ | +------------+
+---------+ | | +------------+
| mixer +==key=C=>+ listener 2 |
+---------+ | | +------------+
| speaker +--key=B-->+ | +------------+
+----+----+ | +==key=C=>+ listener 3 |
^ +---+---+ +------------+
| |
+=======key=C=======+
]]></artwork>
<postamble></postamble>
</figure>
<t>The mixer is aware of listeners leaving or joining, and the mixer
can rekey the remaining active listeners.</t>
</section>
<section title="Point to Multipoint using Multicast">
<t>This RTP topology is described in Section 3.2 of <xref
target="RFC5117">RTP Topologies</xref>.</t>
<t>With DTLS-SRTP, this scenario is not attainable because each
listener has a unique SRTP key. For this reason, <xref
target="I-D.ietf-msec-gdoi-srtp"></xref> was developed by the MSEC
working group.</t>
<t>With DTLS-SRTP Key Transport, this scenario is attainable because the
same key can be provided to multiple listeners, as depicted below
in <xref target="multipoint-multicast-with-kt"></xref>. This compares
favorably with <xref target="I-D.ietf-msec-gdoi-srtp"></xref> when the
group size is small enough that the speaker can perform key server
functions (i.e., perform DTLS-SRTP Key Transport) for all of the
listeners. </t>
<figure anchor="multipoint-multicast-with-kt"
title="Point to Multipoint using Multicast with Key Transport">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------+ +------------+
/ \==key=A===>+ listener 1 |
/ \ +------------+
+---------+ | multicast | +------------+
| speaker +==key=A===>+ network +==key=A==>+ listener 2 |
+---------+ | | +------------+
\ / +------------+
\ /===key=A==>+ listener 3 |
+-------+ +------------+]]></artwork>
<postamble></postamble>
</figure>
<t><list>
<t>[[For future study: could we express, in SDP, alternate DTLS-SRTP
key servers to support large groups for this scenario, so that the
speaker can be offloaded from DTLS-SRTP Key Transport duties? That alternate key server would need authorize new participants. This seems to begin stepping into GDOI territory, but how does a DTLS-SRTP endpoint know when it will join a large group and need GDOI code inside the DTLS-SRTP endpoint? Ideally we would want to split the effort and protocols so that endpoint needs *no* additional code with really large groups.]]</t>
</list></t>
</section>
<section title="Point to Multipoint Using Video Switching MCUs">
<t>This RTP topology is described in Section 3.5 of <xref
target="RFC5117">RTP Topologies</xref>.</t>
<t>With DTLS-SRTP, this topology is computationally expensive for the
video switcher because it has to encrypt the payload uniquely for each
SRTP listener. Additionally, the architecture of a typical video
switcher requires each listener's SRTP to be encrypted serially,
incurring additional delay for each successive listener. This is
depicted below in <xref
target="multipoint-video-without-kt"></xref>.</t>
<figure anchor="multipoint-video-without-kt"
title="Point to Multipoint Video Switching, without DTLS Key Transport">
<preamble>In the following figure, DTLS-SRTP Key Transport is used
on all sessions and depicted by "=". In this scenario, both the
speakers and listeners must support DTLS-SRTP Key Transport so that
the switcher and the listeners can benefit from DTLS-SRTP Key
Transport.</preamble>
<artwork align="center"><![CDATA[
+-------key=F-------+
| |
V +---+------+ +------------+
+---------+ | +==key=C=>+ listener 1 |
| speaker +==key=A==>+selected | +------------+
+---------+ | | +------------+
| switcher +==key=D=>+ listener 2 |
+---------+ | | +------------+
| speaker +==key=B==>+dropped | +------------+
+----+----+ | +==key=E=>+ listener 3 |
^ +---+------+ +------------+
| |
+-------key=G-------+]]></artwork>
<postamble></postamble>
</figure>
<t>With DTLS key transport, this becomes easier; in fact, the video
switcher doesn't need to decrypt the SRTP at all, but just make its
decision (select the stream or drop the stream) and transmit the SRTP
packets to the listeners. This is depicted below in <xref
target="multipoint-video-with-kt"></xref>.</t>
<figure anchor="multipoint-video-with-kt"
title="Point to Multipoint Video Switching, with DTLS Key Transport">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------key=B-------+
| |
V +---+------+ +------------+
+----+----+ | +==key=A=>+ listener 1 |
| speaker +==key=A==>+selected | +------------+
+---------+ | | +------------+
| switcher +==key=A=>+ listener 2 |
+---------+ | | +------------+
| speaker +==key=B==>+prev.spkr | +------------+
+---------+ | +==key=A=>+ listener 3 |
^ +----------+ +------------+
| |
+-------key=A-------+]]></artwork>
<postamble></postamble>
</figure>
<t>The video switcher is aware of listeners leaving or joining. The
protocol described in this document allows the switcher to dictate, to
the speaker, that the speaker use a new encryption key. This allows
the switcher to enforce security, based on the switcher's policy
(<xref target="sec-group-policy"></xref>). This is done by the video
switcher sending a DTLS "your_new_srtp_key" message. The speaker will
respond with a DTLS "new_srtp_key" message which echos the same key.
The "new_srtp_key" message is relayed, by the switcher, to each of the
active listeners.</t>
<t>When there are multiple speakers, as shown in <xref
target="multipoint-video-with-kt"></xref> above, each speaker
transmits with his own SRTP key. That SRTP key is derived from the
DTLS handshake with the switcher. Each speaker uses DTLS-SRTP Key
Transport to signal the SSRC that it will use.</t>
</section>
<section title="Voicemail Storage and Retrieval">
<t>With DTLS-SRTP, voicemail storage servers have to decrypt the SRTP
when the message is recorded. In some voicemail server architectures,
the recorded message is re-encrypted, using a new key to protect the
content while it is on disk. Then, later, the voicemail is retrieved,
which involves encrypting the message using SRTP again. This is
depicted below in <xref target="voicemail-without-kt"></xref>. This
SRTP decryption and encryption can create a significant computational
load on a voicemail storage server.</t>
<figure anchor="voicemail-without-kt"
title="Voicemail Storage and Retrieval without Key Transport">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-----------+
+---------+ | |
| speaker +--key=A-->| voicemail |
+---------+ | storage |
| server | +-----------+
| +--key=B-->+ voicemail |
| (store | | retrieval |
| decrypted | +-----------+
| content) |
+-----------+
]]></artwork>
</figure>
<t>DTLS-SRTP Key Transport removes the need for the voicemail storage
server to decrypt the incoming SRTP and to re-encrypt upon message
retrieval. With DTLS-SRTP Key Transport, the voicemail storage server
can store the speaker's DTLS-SRTP key along with the encrypted message
(including RTP headers), and then use DTLS-SRTP Key Transport to
communicate that key during voicemail retrieval. This is depicted
below in <xref target="voicemail-with-kt"></xref>.</t>
<figure anchor="voicemail-with-kt"
title="Voicemail Storage and Retrieval with Key Transport">
<preamble>In the following figure, DTLS-SRTP Key Transport is used
on all sessions and depicted by "=". In this scenario, only the
device performing the voicemail retrieval needs to implement
DTLS-SRTP Key Transport to help offload SRTP processing from the
voicemail storage server.</preamble>
<artwork align="center"><![CDATA[
+-----------+
+---------+ | |
| speaker +--key=A-->| voicemail |
+---------+ | storage |
| server | +-----------+
| +==key=A==>+ voicemail |
| (store | | retrieval |
| encrypted | +-----------+
| content & |
| SRTP key |
+-----------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec_protocol_description" title="Protocol Description">
<t>This section describes the extension to the DTLS protocol for DTLS-SRTP
key transport, which allows securely communicating the SRTP key to the
DTLS peer.</t>
<section title="key_transport extension">
<t>This document adds a new negotiated extension called
"key_transport", which MUST only be requested in conjunction with the
"use_srtp" extension (Section 3.2 of <xref
target="I-D.ietf-avt-dtls-srtp"></xref>). The DTLS server indicates
its support for key_transport by including key_transport in its
ServerHello message. If a DTLS client includes key_transport in its
ClientHello, but does not receive key_transport in the ServerHello,
the DTLS client MUST NOT send DTLS packets with the srtp_key_transport
content-type.</t>
<t>Support for the DTLS Key Transport extension is indicated in SDP
with the "srtp-kt" attribute. Advertising support for the extension is
necessary in SDP because in some cases it is required to establish an
SRTP call. For example, a mixer may be able to only support SRTP
listeners if those listeners implement DTLS Key Transport (because it
lacks the CPU cycles necessary to encrypt SRTP uniquely for each
listener).</t>
<figure anchor="handshake_message_flow" title="Handshake Message Flow">
<preamble>A message flow showing a DTLS client and DTLS server using
the key_transport extension</preamble>
<artwork align="center"><![CDATA[
Client Server
ClientHello + use_srtp + key_transport
-------->
ServerHello + use_srtp + key_transport
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
]]></artwork>
<postamble></postamble>
</figure>
<t>After successful negotiation of the key_transport extension, the
DTLS client and server MAY exchange SRTP packets, encrypted using the
KDF described in <xref target="I-D.ietf-avt-dtls-srtp"></xref>. This
is normal and expected, even if Key Transport was negotiated by both
sides, as neither side may (yet) have a need to alter the SRTP key.
However, it is also possible that one (or both) peers will immediately
send a new_srtp_key message before sending any SRTP.</t>
</section>
<section title="SRTP Key Transport Protocol">
<t>A new protocol is defined, called the srtp_key_transport protocol
which uses srtp_key_transport content-type which consists of the
following message types:</t>
<t><list style="hanging">
<t hangText="new_srtp_key_request:">request that the DTLS peer
choose a new key. Valid responses are new_srtp_key and
new_srtp_key_error.</t>
<t hangText="your_new_srtp_key:">Dictates a new SRTP key for the
peer to use when the peer transmits its SRTP packets.</t>
<t hangText="new_srtp_key:">contains the new SRTP keying material.
This message is sent by a DTLS endpoint that wants to change its
SRTP key. This does not change any cryptographic parameters (a new
DTLS handshake is necessary for that), but only the DTLS key for
the associated SRTP session. This message includes the SSRC that
will be used for this key, which allows listeners to establish one
SRTP crypto-context per speaker (necessary for the video switching
scenario). The key chosen MUST be cryptographically random <xref
target="RFC4086"></xref>.</t>
<t hangText="new_key_activate:">indicates receiver is prepared to
receive SRTP packets encrypted with the new key.</t>
<t hangText="delete_srtp_key:">indicates the security association
related to this key can be deleted.</t>
<t hangText="new_srtp_key_failure:">indicates a failure.</t>
</list></t>
<t>At any time, the DTLS client or DTLS server MAY send a
key_transport message, as shown in <xref
target="new_key_message_flow"></xref>. The sender of the new_srtp_key
message MAY immediately start transmitting SRTP packets with this new
key. However, to account for loss of the new_srtp_key message it is
RECOMMENDED that the sender wait before changing to the new SRTP key
until it receives the new_key_activate message or it times out waiting
for the new_key_activate_message. The duration of this timeout may
vary depending on the sensitivity of the content (e.g., 1 second or 10
seconds). In any case, the new_srtp_key message is retransmitted until
acknowledged by receipt of a new_key_activate message.</t>
<figure anchor="new_key_message_flow" title="New Key Message Flow">
<preamble></preamble>
<artwork align="center"><![CDATA[Client / Server Server / Client
[new_srtp_key_request] -------->
<-------- new_srtp_key
new_srtp_key_activiate -------->]]></artwork>
<postamble></postamble>
</figure>
<t>The following figure shows the state machine for the protocol.</t>
<figure anchor="state_machine"
title="Key Transport protocol state machine">
<preamble></preamble>
<artwork align="center"><![CDATA[ receive new_srtp_key_request from peer
or decide to choose new SRTP key
|
|
send V
new_srtp_key +---------------+ timeout
+---------| Communicate |--------+
| | Key | |
+-------->| | |
+---------------+ |
| ^ |
receive | | +----------------+
new_key_activate| +---| send SRTP using|
| | new SRTP key |
+----------------+ +----------------+
| send SRTP using|
| new SRTP key |
+----------------+
|
V
done]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="datastructure" title="Data Structures">
<preamble>Using the syntax described in <xref
target="RFC4346">TLS</xref>, the following structures are
used:</preamble>
<artwork align="center"><![CDATA[
enum {
new_srtp_key_request(0),
your_new_srtp_key(1),
new_srtp_key(2),
new_srtp_key_activate(3),
delete_srtp_key(4),
new_srtp_key_failure(128),
(255)
} SRTPKeyTransportType;
struct {
SRTPKeyTransportType keytrans_type;
uint24 length;
uint16 message_seq;
uint24 fragment_offset;
uint24 fragment_length;
select (SRTPKeyTransportType) {
case new_srtp_key_request: NewSRTPKeyRequest;
case your_new_srtp_key: YourNewSRTPKey;
case new_srtp_key: NewSRTPKey;
case new_srtp_key_activate: NewSRTPKeyActivate;
case delete_srtp_key: DeleteSRTPKey;
case new_srtp_key_failure: NewSRTPKeyFailure;
};
} KeyTransport;
struct {
uint random<64>; // additional entropy for peer
} NewSRTPKeyRequest;
struct {
uint32 ssrc; // SSRC used for this key
uint key<16..32>; // The last change_cipher_spec
uint auth_tag<4..10> // decides the length of key
// and auth_tag
uint random<64>; // additional entropy for peer
} NewSRTPKey;
struct {
uint key<16..32>; // The last change_cipher_spec
uint auth_tag<4..10> // decides the length of key
// and auth_tag
} YourNewSRTPKey;
struct {
uint random<64>; // additional entropy for peer
} NewSRTPKeyActivate;
struct {
uint32 ssrc; // SSRC used for this key
} DeleteSRTPKey;
struct { } NewSRTPKeyFailure;]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Key Transport SSRC and RTP SSRC Collisions">
<t>Per <xref target="RFC3550"></xref>, if an RTP source notices an RTP
SSRC collision, it is required to change its SSRC. If it has
negotiated support for DTLS-SRTP Key Transport, it then MUST also send
a new_srtp_key message indicating the new SSRC. As part of this
procedure, it does not need to also change its SRTP key.</t>
<t>The communication of the SSRC used for each key is necessary if
there are multiple speakers in the video switching scenario. However,
because a speaker is not able to determine if their audio or their
video is being switched, a speaker MUST always adhere indicate a
change in SSRC by following the procedure in this section for any SRTP
stream (audio, video, or other).</t>
</section>
<section title="Fragmentation, Reassembly, and Retransmission">
<t>Much like the DTLS handshake itself, this extension also needs to
handle fragmentation and reassembly (to send a large key) and
retransmission (to account for packet loss). Using the same technique
as DTLS's handshake, the message_seq, fragment_offset, fragment_length
are used.</t>
<t>When transmitting the key transport message, the sender divides the
message into a series of N contiguous data ranges. These ranges MUST
NOT be larger than the maximum handshake fragment size and MUST
jointly contain the entire key transport message. The ranges SHOULD
NOT overlap. The sender then creates N key transport messages, all
with the same message_seq value as the original key transport message.
Each new message is labelled with the fragment_offset (the number of
bytes contained in previous fragments) and the fragment_length (the
length of this fragment). The length field in all messages is the same
as the length field of the original message. An unfragmented message
is a degenerate case with fragment_offset=0 and
fragment_length=length.</t>
<t>When a DTLS implementation receives a key transport message
fragment, it MUST buffer it until it has the entire key transport
message. DTLS implementations MUST be able to handle overlapping
fragment ranges. This allows senders to retransmit key transport
messages with smaller fragment sizes during path MTU discovery.</t>
</section>
</section>
<section title="Examples">
<figure anchor="fig_example_simple_offer_kt_required"
title="Simple SDP offer showing Key Transport is required">
<preamble>The following example shows how Key Transport would be
requested in an offer, using "a=dtls-srtp-kt".</preamble>
<artwork><![CDATA[
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 UDP/TLS/RTP/SAVP 0
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=dtls-srtp-kt]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="fig_example_offer_kt_required"
title="Example SDP offer showing Key Transport is required">
<preamble>Using the SDP syntax described in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>, the
following figure shows an offerer that requires DTLS Key Transport in
order to set up this call as an SRTP call, otherwise it can set up
this call as an RTP call. This is indicated by the ",2" on the
"a=pcfg" line. If the answerer does not understand "a=dtls-srtp-kt"
but does understand DTLS-SRTP and <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>, this can
cannot be established using DTLS-SRTP; however, it can be established
using RTP.</preamble>
<artwork><![CDATA[
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0
a=tcap:1 UDP/TLS/RTP/SAVP
a=acap:1 fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=acap:2 dtls-srtp-kt
a=pcfg:1 t=1 a=1,2 ]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="fig_example_offer_kt_optional"
title="Example SDP offer showing Key Transport is optional">
<preamble>Using the SDP syntax described in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>, the
following figure shows an offerer that indicates support for DTLS Key
Transport but does not require DTLS Key Transport in order to set up
this call as an SRTP call. This is indicated by the ",[2]" on the
"a=pcfg" line. If the answerer does not understand "a=dtls-srtp-kt"
but does understand DTLS-SRTP and <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>, this call
can still be established using DTLS-SRTP.</preamble>
<artwork><![CDATA[
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0
a=tcap:1 UDP/TLS/RTP/SAVP
a=acap:1 fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=acap:2 dtls-srtp-kt
a=pcfg:1 t=1 a=1,[2] ]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>In the point-to-multipoint scenario, <xref
target="section_point_multipoint"></xref>, all of the listeners know the
key being used by the mixer. Any of those listeners could create SRTP
packets that are encrypted with this same key, and send those SRTP
packets to other listeners. In order to reduce the vulnerability to this
threat, it is RECOMMENDED that the source transport address of received
SRTP packets be discarded if they do not match the source transport
address of the associated DTLS-SRTP session. Additionally, the network
SHOULD prevent IP address spoofing <xref target="RFC2827"></xref>.</t>
<section anchor="sec-group-policy"
title="Group Policy when Joining/Leaving">
<t>When sharing SRTP keys with several listeners, it is imperative
that the SRTP is changed when a new listener is added or a listener is
removed. This is because a legitimate listener should only be able to
decrypt the SRTP stream while he is listening; he should not be able
to decrypt the SRTP stream prior to joining the conference or after
leaving the conference. Failing to change the key when a listener
joins (or leaves) allows a listener to decrypt SRTP traffic prior to
(or after) they are authorized participants in the conference.</t>
<t>Policies for a specific user's access to a conference may be
different from conference to conference. For example, a
company-internal event announcing promotions might be accessible to
all employees and have no need for re-keying when listeners join or
leave the conference. As another example, a conference where a job
candidate is interviewed should be rekeyed when the job candidate
joins the conference and again when the job candidate leaves the
conference.</t>
<t>The protocol described in this document allows whichever policy is
needed for a particular situation. The protocol itself does not
enforce a certain policy; that is, the protocol itself does not ensure
the SRTP key is changed when a listener leaves (or joins) the
conference.</t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to David McGrew for his improvements to this document and to
the underlying protocol. Thanks to Brian Weis, Sheela Rowles, and Mark
Baugher for suggesting how GDOI-SRTP's key management could be used by
DTLS-SRTP; these suggestions have been incorporated into DTLS-SRTP Key
Transport.</t>
</section>
<section title="IANA Considerations">
<t>[[This section will be completed in a future version of this
document.]]</t>
<t>To do:
<list style="symbols">
<t>Register new SDP attribute "dtls-srtp-kt"</t>
<t>new TLS content-type "key_transport" (26?)</t>
</list> </t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-avt-dtls-srtp;
&rfc2119;
&rfc4346;
&rfc2827;
&I-D.ietf-mmusic-sdp-capability-negotiation;
</references>
<references title="Informational References">
&rfc5117;
&rfc3550;
&rfc4086;
&I-D.ietf-msec-gdoi-srtp;
</references>
<section title="Changes">
<t>[[Note to RFC Editor: Please remove this section prior to publication]]</t>
<section title="Changes from -00 to -01">
<t><list style="symbols">
<t>more closely aligned with <xref target="RFC5117">RTP Topologies</xref></t>
<t>added multicast scenario</t>
<t>added voicemail storage/retrieval scenario</t>
<t>added delete_srtp_key</t>
<t>added your_new_srtp_key</t>
<t>aligned SDP for DTLS-SRTP with draft-ietf-mmusic-sdp-dtls-00</t>
<t>key change rules are now discussed in Security Considerations</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:35:20 |