rfc8870xml2.original.xml   rfc8870.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-ietf-perc-srtp-ekt-diet-13"
>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="EKT SRTP">Encrypted Key Transport for DTLS and Secure RTP</title>
<author initials="C." surname="Jennings" fullname="Cullen Jennings"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>fluffy@iii.ca</email>
<uri></uri>
</address>
</author>
<author initials="J." surname="Mattsson" fullname="John Mattsson">
<organization>Ericsson AB</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>john.mattsson@ericsson.com</email>
<uri></uri>
</address>
</author>
<author initials="D.A.M." surname="McGrew" fullname="David A. McGrew">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>mcgrew@cisco.com</email>
<uri></uri>
</address>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Citrix Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>dwing-ietf@fuggles.com</email>
<uri></uri>
</address>
</author>
<author initials="F.A." surname="Andreason" fullname="Flemming Andreason">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>fandreas@cisco.com</email>
<uri></uri>
</address>
</author>
<date year="2020" month="June" day="23"/>
<area>Internet</area> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
<workgroup></workgroup> ="IETF" category="std" consensus="true" docName="draft-ietf-perc-srtp-ekt-diet-1
<keyword>PERC</keyword> 3" number="8870" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs
<keyword>SRTP</keyword> ="true" sortRefs="true" version="3">
<keyword>RTP</keyword>
<keyword>conferencing</keyword>
<keyword>encryption</keyword>
<abstract> <!-- xml2rfc v2v3 conversion 2.46.0 -->
<t>Encrypted Key Transport (EKT) is an extension to DTLS <front>
(Datagram Transport Layer Security) and Secure Real-time <title abbrev="EKT SRTP">Encrypted Key Transport for DTLS and Secure RTP</ti
tle>
<seriesInfo name="RFC" value="8870"/>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization>Cisco Systems</organization>
<address>
<email>fluffy@iii.ca</email>
</address>
</author>
<author initials="J." surname="Mattsson" fullname="John Mattsson">
<organization>Ericsson AB</organization>
<address>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<author initials="D." surname="McGrew" fullname="David A. McGrew">
<organization>Cisco Systems</organization>
<address>
<email>mcgrew@cisco.com</email>
</address>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address>
<email>dwing-ietf@fuggles.com</email>
</address>
</author>
<author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
<organization>Cisco Systems</organization>
<address>
<email>fandreas@cisco.com</email>
</address>
</author>
<date year="2021" month="January" />
<keyword>PERC</keyword>
<keyword>SRTP</keyword>
<keyword>RTP</keyword>
<keyword>conferencing</keyword>
<keyword>encryption</keyword>
<abstract>
<t>Encrypted Key Transport (EKT) is an extension to DTLS
(Datagram Transport Layer Security) and the Secure Real-time
Transport Protocol (SRTP) that provides for the secure Transport Protocol (SRTP) that provides for the secure
transport of SRTP master keys, rollover counters, and other transport of SRTP master keys, rollover counters, and other
information within SRTP. This facility enables SRTP for decentralized information within SRTP. This facility enables SRTP for decentralized
conferences by distributing a common key to all of the conference conferences by distributing a common key to all of the conference
endpoints. endpoints.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>The Real-time Transport Protocol (RTP) is designed to allow decentraliz
<section anchor="introduction" title="Introduction"> ed
<t>Real-time Transport Protocol (RTP) is designed to allow decentralized
groups with minimal control to establish sessions, such as for groups with minimal control to establish sessions, such as for
multimedia conferences. Unfortunately, Secure RTP (SRTP <xref target="RFC3711"/ >) multimedia conferences. Unfortunately, Secure RTP (SRTP) <xref target="RFC3711" format="default"/>
cannot be used in many minimal-control scenarios, because it requires cannot be used in many minimal-control scenarios, because it requires
that synchronization source (SSRC) values and other data be that synchronization source (SSRC) values and other data be
coordinated among all of the participants in a session. For example, coordinated among all of the participants in a session. For example,
if a participant joins a session that is already in progress, that if a participant joins a session that is already in progress, that
participant needs to be told the SRTP keys along with the SSRC, participant needs to be informed of the SRTP keys along with the SSRC,
rollover counter (ROC) and other details of the other SRTP sources. rollover counter (ROC), and other details of the other SRTP sources.
</t> </t>
<t>The inability of SRTP to work in the absence of central control was <t>The inability of SRTP to work in the absence of central control was
well understood during the design of the protocol; the omission was well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth considered less important than optimizations such as bandwidth
conservation. Additionally, in many situations SRTP is used in conservation. Additionally, in many situations, SRTP is used in
conjunction with a signaling system that can provide the central conjunction with a signaling system that can provide the central
control needed by SRTP. However, there are several cases in which control needed by SRTP. However, there are several cases in which
conventional signaling systems cannot easily provide all of the conventional signaling systems cannot easily provide all of the
coordination required. coordination required.
</t> </t>
<t>This document defines Encrypted Key Transport (EKT) for SRTP and <t>This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a reduces the amount of external signaling control that is needed in an
SRTP session with multiple receivers. EKT securely distributes the SRTP session with multiple receivers. EKT securely distributes the
SRTP master key and other information for each SRTP source. With this SRTP master key and other information for each SRTP source. With this
method, SRTP entities are free to choose SSRC values as they see fit, method, SRTP entities are free to choose SSRC values as they see fit
and to start up new SRTP sources with new SRTP master keys within a and to start up new SRTP sources with new SRTP master keys within a
session without coordinating with other entities via external signaling session without coordinating with other entities via external signaling
or other external means. or other external means.
</t> </t>
<t>EKT extends DTLS and SRTP to enable a common key encryption key <t>EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each (called an "EKTKey") to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP endpoint can securely send its SRTP master key and current SRTP
rollover counter to the other participants in the session. This data ROC to the other participants in the session. This data
furnishes the information needed by the receiver to instantiate an furnishes the information needed by the receiver to instantiate an
SRTP receiver context. SRTP receiver context.
</t> </t>
<t>EKT can be used in conferences where the central media distributor or <t>EKT can be used in conferences where the central Media Distributor or
conference bridge cannot decrypt the media, such as the type defined conference bridge cannot decrypt the media, such as the type defined
for <xref target="I-D.ietf-perc-private-media-framework"/>. It can also be used in <xref target="RFC8871" format="default"/>. It can also be used for
for large-scale conferences where the conference bridge or Media
large scale conferences where the conference bridge or media Distributor can decrypt all the media but wishes to encrypt the media
distributor can decrypt all the media but wishes to encrypt the media
it is sending just once and then send the same encrypted media to a large it is sending just once and then send the same encrypted media to a large
number of participants. This reduces the amount of CPU time needed for number of participants. This reduces encryption CPU time
encryption and can be used for some optimization to media sending that in general and is necessary when sending multicast media.
use source specific multicast.
</t> </t>
<t>EKT does not control the manner in which the SSRC is generated. It <t>EKT does not control the manner in which the SSRC is generated. It
is only concerned with distributing the security parameters that an is only concerned with distributing the security parameters that an
endpoint needs to associate with a given SSRC in order to decrypt endpoint needs to associate with a given SSRC in order to decrypt
SRTP packets from that sender. SRTP packets from that sender.
</t> </t>
<t>EKT is not intended to replace external key establishment <t>EKT is not intended to replace external key establishment
mechanisms. Instead, it is used in conjunction with those methods, and mechanisms. Instead, it is used in conjunction with those methods, and
it relieves those methods of the burden to deliver the context for it relieves those methods of the burden of delivering the context for
each SRTP source to every SRTP participant. This document defines each SRTP source to every SRTP participant. This document defines
how EKT works with the DTLS-SRTP approach to key establishment, by how EKT works with the DTLS-SRTP approach to key establishment, by
using keys derived from the DTLS-SRTP handshake to encipher the using keys derived from the DTLS-SRTP handshake to encipher the
EKTKey in addition to the SRTP media. EKTKey in addition to the SRTP media.
</t> </t>
</section> </section>
<section anchor="overview" numbered="true" toc="default">
<section anchor="overview" title="Overview"> <name>Overview</name>
<t>This specification defines a way for the server in a DTLS-SRTP <t>This specification defines a way for the server in a DTLS-SRTP
negotiation, see <xref target="dtls-srtp-kt"/>, to provide an EKTKey to the clie negotiation (see <xref target="dtls-srtp-kt" format="default"/>) to provide an E
nt KTKey to the client
during the DTLS handshake. The EKTKey thus obtained can be used to during the DTLS handshake. The EKTKey thus obtained can be used to
encrypt the SRTP master key that is used to encrypt the media sent by encrypt the SRTP master key that is used to encrypt the media sent by
the endpoint. This specification also defines a way to send the the endpoint. This specification also defines a way to send the
encrypted SRTP master key (with the EKTKey) along with the SRTP packet, encrypted SRTP master key (with the EKTKey) along with the SRTP packet
see <xref target="srtp_ekt"/>. Endpoints that receive this and know the EKTKey c (see <xref target="srtp_ekt" format="default"/>). Endpoints that receive this pa
an use cket and know the EKTKey can use
the EKTKey to decrypt the SRTP master key which can then be used to decrypt the EKTKey to decrypt the SRTP master key, which can then be used to decrypt
the SRTP packet. the SRTP packet.
</t> </t>
<t>One way to use this is described in the architecture defined <t>One way to use this specification is described in the architecture defi
by <xref target="I-D.ietf-perc-private-media-framework"/>. Each participant in t ned
he by <xref target="RFC8871" format="default"/>. Each participant in the
conference forms a DTLS-SRTP connection to a common key conference forms a DTLS-SRTP connection to a common Key Distributor
distributor that distributes the same EKTKey to all the endpoints. that distributes the same EKTKey to all the endpoints.
Then each endpoint picks its own SRTP master key for the media Then, each endpoint picks its own SRTP master key for the media
they send. When sending media, the endpoint also includes the it sends. When sending media, the endpoint may also include the
SRTP master key encrypted with the EKTKey in the SRTP packet. SRTP master key encrypted with the EKTKey in the SRTP packet.
This allows all the endpoints to decrypt the media. This allows all the endpoints to decrypt the media.
</t> </t>
</section> </section>
<section anchor="conventions-used-in-this-document" numbered="true" toc="def
<section anchor="conventions-used-in-this-document" title="Conventions Used In T ault">
his Document"> <name>Conventions Used in This Document</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&qu "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
ot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
&quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP "<bcp14>SHOULD NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they a "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ppear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14
</section> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<section anchor="srtp_ekt" title="Encrypted Key Transport"> </section>
<t>EKT defines a new method of providing SRTP master keys to an <section anchor="srtp_ekt" numbered="true" toc="default">
<name>Encrypted Key Transport</name>
<t>EKT defines a new method of providing SRTP master keys to an
endpoint. In order to convey the ciphertext corresponding to the SRTP endpoint. In order to convey the ciphertext corresponding to the SRTP
master key, and other additional information, an additional field, master key, and other additional information, an additional field,
called EKTField, is added to the SRTP packets. The EKTField appears called the "EKTField", is added to the SRTP packets. The EKTField appears
at the end of the SRTP packet. It appears after the optional at the end of the SRTP packet. It appears after the optional
authentication tag if one is present, otherwise the EKTField authentication tag, if one is present; otherwise, the EKTField
appears after the ciphertext portion of the packet. appears after the ciphertext portion of the packet.
</t> </t>
<t>EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key <t>EKT <bcp14>MUST NOT</bcp14> be used in conjunction with SRTP's MKI (Mas
Identifier) or with SRTP's &lt;From, To&gt; <xref target="RFC3711"/>, as those S ter Key
RTP Identifier) or with SRTP's &lt;From, To&gt; <xref target="RFC3711" format="defau
features duplicate some of the functions of EKT. Senders MUST NOT lt"/>, as those SRTP
include MKI when using EKT. Receivers SHOULD simply ignore any MKI features duplicate some of the functions of EKT. Senders <bcp14>MUST NOT</bcp14>
include the MKI when using EKT. Receivers <bcp14>SHOULD</bcp14> simply ignore an
y MKI
field received if EKT is in use. field received if EKT is in use.
</t> </t>
<t>This document defines the use of EKT with SRTP. Its use with SRTCP <t>This document defines the use of EKT with SRTP. Its use with the
would be similar, but is reserved for a future specification. SRTP Secure Real-time Transport Control Protocol (SRTCP)
is preferred for transmitting key material because it shares fate would be similar, but that topic is left for a future specification. SRTP
with the transmitted media, because SRTP rekeying can occur without is preferred for transmitting keying material because (1)&nbsp;it shares fate
concern for RTCP transmission limits, and because it avoids the need with the transmitted media, (2)&nbsp;SRTP rekeying can occur without
concern for RTCP transmission limits, and (3)&nbsp;it avoids the need
for SRTCP compound packets with RTP translators and mixers. for SRTCP compound packets with RTP translators and mixers.
</t> </t>
<section anchor="EKT" numbered="true" toc="default">
<section anchor="EKT" title="EKTField Formats"> <name>EKTField Formats</name>
<t>The EKTField uses the format defined in <xref target="tag-format-base"/> for <t>The EKTField uses the formats defined in Figures&nbsp;<xref
the target="tag-format-base" format="counter"/> and <xref
target="tag-format-abbreviated" format="counter"/> for the
FullEKTField and ShortEKTField. The EKTField appended to an SRTP FullEKTField and ShortEKTField. The EKTField appended to an SRTP
packet can be referred to as an &quot;EKT tag&quot;. packet can be referred to as an "EKT Tag".
</t> </t>
<figure anchor="tag-format-base">
<figure anchor="tag-format-base" align="center" title="FullEKTField format <name>FullEKTField Format</name>
"><artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: EKT Ciphertext : : EKT Ciphertext :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Epoch | | Security Parameter Index | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |0 0 0 0 0 0 1 0| | Length |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork></figure> </figure>
<figure anchor="tag-format-abbreviated">
<figure anchor="tag-format-abbreviated" align="center" title="ShortEKTField form <name>ShortEKTField Format</name>
at <artwork align="center" name="" type="" alt=""><![CDATA[
"><artwork align="center">
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</artwork></figure> </figure>
<t>The following shows the syntax of the EKTField expressed in ABNF <t><xref target="tag-formats"/> shows the syntax of the EKTField, expres
<xref target="RFC5234"/>. The EKTField is added to the end of an SRTP sed in ABNF
<xref target="RFC5234" format="default"/>. The EKTField is added to the end of
an SRTP
packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength, packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength,
SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext is
computed by encrypting the EKTPlaintext using the EKTKey. Future computed by encrypting the EKTPlaintext using the EKTKey. Future
extensions to the EKTField MUST conform to the syntax of extensions to the EKTField <bcp14>MUST</bcp14> conform to the syntax of the
ExtensionEKTField. ExtensionEKTField.
</t> </t>
<figure anchor="tag-formats">
<figure anchor="tag-formats" align="center" title="EKTField Syntax <name>EKTField Syntax</name>
"><artwork align="center"> <sourcecode name="" type="abnf"><![CDATA[
BYTE = %x00-FF BYTE = %x00-FF
EKTMsgTypeFull = %x02 EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00 EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available
; usage by legacy implementations. ; for assignment due to its usage by
; legacy implementations.
EKTMsgLength = 2BYTE; EKTMsgLength = 2BYTE
SRTPMasterKeyLength = BYTE SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*242BYTE SRTPMasterKey = 1*242BYTE
SSRC = 4BYTE; SSRC from RTP SSRC = 4BYTE ; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC ROC = 4BYTE ; ROC from SRTP for the given SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE Epoch = 2BYTE
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
ShortEKTField = EKTMsgTypeShort ShortEKTField = EKTMsgTypeShort
ExtensionData = 1*1024BYTE ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField EKTField = FullEKTField / ShortEKTField / ExtensionEKTField]]></sourcecode>
</artwork></figure> </figure>
<t>These fields and data elements are defined as follows: <t>These fields and data elements are defined as follows:
</t>
<t>EKTPlaintext: The data that is input to the EKT encryption
operation. This data never appears on the wire, and is used only in
computations internal to EKT. This is the concatenation of the SRTP
Master Key and its length, the SSRC, and the ROC.
</t>
<t>EKTCiphertext: The data that is output from the EKT encryption
operation, described in <xref target="cipher"/>. This field is included in SRTP
packets when EKT is in use. The length of EKTCiphertext can be larger
than the length of the EKTPlaintext that was encrypted.
</t>
<t>SRTPMasterKey: On the sender side, the SRTP Master Key associated with
the indicated SSRC.
</t>
<t>SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
depends on the cipher suite negotiated for SRTP using SDP Offer/Answer
<xref target="RFC3264"/> for the SRTP.
</t>
<t>SSRC: On the sender side, this is the SSRC for this SRTP
source. The length of this field is 32 bits. The SSRC value in the
EKT tag MUST be the same as the one in the header of the SRTP packet
to which the tag is appended.
</t>
<t>Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP packet. The length of
this field is 32 bits.
</t>
<t>Security Parameter Index (SPI): This field indicates the appropriate
EKTKey and other parameters for the receiver to use when processing
the packet, within a given conference. The length of this field is
16 bits, representing a two-byte integer in network byte order. The
parameters identified by this field are:
</t>
<t>
<list style="symbols">
<t>The EKT cipher used to process the packet.</t>
<t>The EKTKey used to process the packet.</t>
<t>The SRTP Master Salt associated with any master key encrypted with
this EKT Key. The master salt is communicated separately, via
signaling, typically along with the EKTKey. (Recall that the SRTP
master salt is used in the formation of IVs / nonces.)</t>
</list>
</t>
<t>Epoch: This field indicates how many SRTP keys have been sent for this
SSRC under the current EKTKey, prior to the current key, as a two-byte
integer in network byte order. It starts at zero at the beginning
of a session and resets to zero whenever the EKTKey is changed
(i.e., when a new SPI appears). The epoch for an SSRC increments by
one every time the sender transmits a new key. The recipient of a
FullEKTField MUST reject any future FullEKTField for this SPI and
SSRC that has an equal or lower epoch value to an epoch already
seen.
</t>
<t>Together, these data elements are called an EKT parameter set. Each
distinct EKT parameter set that is used MUST be associated with a
distinct SPI value to avoid ambiguity.
</t>
<t>EKTMsgLength: All EKT messages types other than the ShortEKTField
have a length as second from the last element. This is the length
in octets (in network byte order) of either the
FullEKTField/ExtensionEKTField including this length field and the
following EKT Message Type.
</t>
<t>Message Type: The last byte is used to indicate the type of the
EKTField. This MUST be 2 for the FullEKTField format and 0 in
ShortEKTField format. If a received EKT tag has an unknown message
type, then the receiver MUST discard the whole EKT tag.
</t> </t>
</section> <dl newline="true" spacing="normal">
<dt>EKTPlaintext:</dt>
<dd>This is the data that is input to the EKT encryption operation. This data
never
appears on the wire; it is used only in computations internal to EKT. This
is the concatenation of the SRTP master key and its length, the SSRC, and
the ROC.</dd>
<dt>EKTCiphertext:</dt>
<dd>This is the data that is output from the EKT encryption operation
(see <xref target="cipher" format="default"/>). This field is included in SRTP
packets when EKT is in use. The length of the EKTCiphertext can be larger tha
n
the length of the EKTPlaintext that was encrypted.</dd>
<dt>SRTPMasterKey:</dt>
<dd>On the sender side, this is the SRTP master key associated with the indica
ted
SSRC.</dd>
<dt>SRTPMasterKeyLength:</dt>
<dd>This is the length of the SRTPMasterKey in bytes. This depends on the ciph
er
suite negotiated for SRTP using Session Description Protocol (SDP) Offer/Answe
r <xref target="RFC3264"
format="default"/>.
</dd>
<dt>SSRC:</dt>
<dd>On the sender side, this is the SSRC for this SRTP source. The length of
this field is 32 bits. The SSRC value in the EKT Tag <bcp14>MUST</bcp14> be
the same as the one in the header of the SRTP packet to which the tag is
appended.</dd>
<dt>Rollover Counter (ROC):</dt>
<dd>On the sender side, this is set to the current value of the SRTP
ROC in the SRTP context associated with the SSRC in the SRTP
packet. The length of this field is 32 bits.</dd>
<section anchor="spis-and-ekt-parameter-sets" title="SPIs and EKT Parameter Sets <dt>Security Parameter Index (SPI):</dt>
"> <dd><t>This field indicates the appropriate EKTKey and other parameters for th
<t>The SPI field identifies the parameters for how the EKT tag should e
be processed: receiver to use when processing the packet, within a given conference. The
length of this field is 16 bits, representing a two-byte integer in network
byte order. The parameters identified by this field are as follows:</t>
<ul spacing="normal">
<li>The EKT Cipher used to process the packet.</li>
<li>The EKTKey used to process the packet.</li>
<li>The SRTP master salt associated with any master key encrypted
with this EKT Key. &nbsp;The master salt is communicated separately, v
ia
signaling, typically along with the EKTKey. (Recall that the SRTP
master salt is used in the formation of Initialization Vectors
(IVs) / nonces.)</li>
</ul>
</dd>
<dt>Epoch:</dt>
<dd>This field indicates how many SRTP keys have been sent for this SSRC
under the current EKTKey, prior to the current key, as a two&nbhy;byte intege
r
in network byte order. It starts at zero at the beginning of a session and
resets to zero whenever the EKTKey is changed (i.e., when a new SPI
appears). The epoch for an SSRC increments by one every time the sender
transmits a new key. The recipient of a FullEKTField <bcp14>MUST</bcp14>
reject any future FullEKTField for this SPI and SSRC that has an epoch
value equal to or lower than an epoch already seen.</dd>
</dl>
<t>Together, these data elements are called an "EKT parameter set". To
avoid ambiguity, each distinct EKT parameter set that is used
<bcp14>MUST</bcp14> be associated with a distinct SPI value.
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="symbols"> <dt>EKTMsgLength:</dt>
<t>The EKTKey and EKT cipher used to process the packet.</t> <dd>All EKT Message Types other than the ShortEKTField include a length
<t>The SRTP Master Salt associated with any master key encrypted with in octets (in network byte
this EKT Key. The master salt is communicated separately, via order) of either the FullEKTField or the ExtensionEKTField, including this le
signaling, typically along with the EKTKey.</t> ngth
</list> field and the EKT Message Type (as defined in the next paragraph).</dd>
<dt>Message Type:</dt>
<dd>The last byte is used to indicate the type of the EKTField. This
<bcp14>MUST</bcp14> be 2 for the FullEKTField format and 0 for the ShortEKTFi
eld
format. If a received EKT Tag has an unknown Message Type, then the
receiver <bcp14>MUST</bcp14> discard the whole EKT Tag.</dd>
</dl>
</section>
<section anchor="spis-and-ekt-parameter-sets" numbered="true" toc="default
">
<name>SPIs and EKT Parameter Sets</name>
<t>The SPI identifies the parameters for how the EKT Tag should
be processed:
</t> </t>
<t>Together, these data elements are called an &quot;EKT parameter set&quot;. Ea <ul spacing="normal">
ch <li>The EKTKey and EKT Cipher used to process the packet.</li>
distinct EKT parameter set that is used MUST be associated with a <li>The SRTP master salt associated with any master key encrypted
distinct SPI value to avoid ambiguity. The association of a given with this EKT Key. &nbsp;The master salt is communicated separately, v
ia
signaling, typically along with the EKTKey.</li>
</ul>
<t>Together, these data elements are called an "EKT parameter set". To
avoid ambiguity, each distinct EKT parameter set that is used
<bcp14>MUST</bcp14> be associated with a distinct SPI value. The associ
ation of a given
parameter set with a given SPI value is configured by some other parameter set with a given SPI value is configured by some other
protocol, e.g., the DTLS-SRTP extension defined in protocol, e.g., the DTLS-SRTP extension defined in
<xref target="dtls-srtp-kt"/>. <xref target="dtls-srtp-kt" format="default"/>.
</t> </t>
</section> </section>
<section anchor="pkt_proc" numbered="true" toc="default">
<section anchor="pkt_proc" title="Packet Processing and State Machine"> <name>Packet Processing and State Machine</name>
<t>At any given time, each SRTP source has associated with it a <t>At any given time, the SSRC for each SRTP source has associated with
single EKT parameter set. This parameter set is used to process all it a single EKT parameter set. This parameter set is used to
outbound packets, and is called the outbound parameter set for that process all outbound packets and is called the "outbound parameter
SSRC. There may be other EKT parameter sets that are used by other set" for that SSRC. There may be other EKT parameter sets that are used
by other
SRTP sources in the same session, including other SRTP SRTP sources in the same session, including other SRTP
sources on the same endpoint (e.g., one endpoint with voice and video sources on the same endpoint (e.g., one endpoint with voice and video
might have two EKT parameter sets, or there might be multiple video might have two EKT parameter sets, or there might be multiple video
sources on an endpoint each with their own EKT parameter set). All of sources on an endpoint, each with their own EKT parameter set). All of
the received EKT parameter sets SHOULD be stored by all of the the received EKT parameter sets <bcp14>SHOULD</bcp14> be stored by all of the
participants in an SRTP session, for use in processing inbound SRTP participants in an SRTP session, for use in processing inbound SRTP
traffic. If a participant deletes an EKT parameter set traffic. If a participant deletes an EKT parameter set
(e.g., because of space limitations, then it will be unable to (e.g., because of space limitations), then it will be unable to
process Full EKT Tags containing updated media keys, and thus unable process Full EKT Tags containing updated media keys and thus will be unable
to receive media from a particpant that has changed its media key. to receive media from a participant that has changed its media key.
</t> </t>
<t>Either the FullEKTField or ShortEKTField is appended at the tail end <t>Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets. The decision on which to send when is specified of all SRTP packets. The decision regarding which parameter to send and when
in <xref target="timing"/>. is specified in <xref target="timing" format="default"/>.
</t> </t>
<section anchor="outbound-processing" numbered="true" toc="default">
<section anchor="outbound-processing" title="Outbound Processing"> <name>Outbound Processing</name>
<t>See <xref target="timing"/> which describes when to send an SRTP packet with <t>See <xref target="timing" format="default"/>, which describes when
a to send an SRTP packet with a
FullEKTField. If a FullEKTField is not being sent, then a FullEKTField. If a FullEKTField is not being sent, then a
ShortEKTField is sent so the receiver can correctly determine how to ShortEKTField is sent so the receiver can correctly determine how to
process the packet. process the packet.
</t> </t>
<t>When an SRTP packet is sent with a FullEKTField, the EKTField for that <t>When an SRTP packet is sent with a FullEKTField, the EKTField for t
packet is created as follows, or uses an equivalent set of steps. hat
packet is created per either the steps below or an equivalent set of steps.
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>The Security Parameter Index (SPI) field is set to the value of
<t>The Security Parameter Index (SPI) field is set to the value of the the
Security Parameter Index that is associated with the outbound SPI that is associated with the outbound
parameter set.</t> parameter set.</li>
<t>The EKTPlaintext field is computed from the SRTP Master Key, SSRC, <li>The EKTPlaintext field is computed from the SRTP master key, SSR
and ROC fields, as shown in <xref target="EKT"/>. The ROC, SRTP Master Key, and C,
SSRC used in EKT processing MUST be the same as the one used in and ROC fields, as shown in <xref target="EKT" format="default"/>. The ROC, SRTP
the SRTP processing.</t> master key, and
<t>The EKTCiphertext field is set to the ciphertext created by SSRC used in EKT processing <bcp14>MUST</bcp14> be the same as the one used in
SRTP processing.</li>
<li>The EKTCiphertext field is set to the ciphertext created by
encrypting the EKTPlaintext with the EKTCipher using the EKTKey encrypting the EKTPlaintext with the EKTCipher using the EKTKey
as the encryption key. The encryption process is detailed in as the encryption key. The encryption process is detailed in
<xref target="cipher"/>.</t> <xref target="cipher" format="default"/>.</li>
<t>Then the FullEKTField is formed using the EKTCiphertext and the SPI <li>
associated with the EKTKey used above. Also appended are the Length <t>Then, the FullEKTField is formed using the EKTCiphertext and th
e SPI
associated with the EKTKey used above. Also appended are the length
and Message Type using the FullEKTField format. and Message Type using the FullEKTField format.
<list style="symbols">
<t>Note: the value of the EKTCiphertext field is identical in successive
packets protected by the same EKTKey and SRTP master key. This value MAY
be cached by an SRTP sender to minimize computational effort.</t>
</list></t>
</list>
</t>
<t>The computed value of the FullEKTField is appended to the end of the
SRTP packet, after the encrypted payload.
</t> </t>
<t>When a packet is sent with the ShortEKTField, the ShortEKFField is </li>
simply appended to the packet. </ol>
</t> <aside><t>Note: The value of the EKTCiphertext field is identical in successi
<t>Outbound packets SHOULD continue to use the old SRTP Master Key for ve
packets protected by the same EKTKey and SRTP master key. This value <bcp14>MAY<
/bcp14>
be cached by an SRTP sender to minimize computational effort.</t></aside>
<t>The computed value of the FullEKTField is appended to the end of
the SRTP packet, after the encrypted payload.</t>
<t>When a packet is sent with the ShortEKTField, the ShortEKTField
is simply appended to the packet.</t>
<t>Outbound packets <bcp14>SHOULD</bcp14> continue to use the old SRTP
master key for
250 ms after sending any new key in a FullEKTField value. This gives 250 ms after sending any new key in a FullEKTField value. This gives
all the receivers in the system time to get the new key before they all the receivers in the system time to get the new key before they
start receiving media encrypted with the new key. (The specific start receiving media encrypted with the new key. (The specific
value of 250ms is chosen to represent a reasonable upper bound on value of 250 ms is chosen to represent a reasonable upper bound on
the amount of latency and jitter that is tolerable in a real-time the amount of latency and jitter that is tolerable in a real-time
context.) context.)
</t> </t>
</section> </section>
<section anchor="inbound-processing" numbered="true" toc="default">
<section anchor="inbound-processing" title="Inbound Processing"> <name>Inbound Processing</name>
<t>When receiving a packet on a RTP stream, the following steps are <t>When receiving a packet on an RTP stream, the following steps are
applied for each SRTP received packet. applied for each received SRTP packet.
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>The final byte is checked to determine which EKT format is in
<t>The final byte is checked to determine which EKT format is in
use. When an SRTP packet contains a ShortEKTField, the use. When an SRTP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP ShortEKTField is removed from the packet and then normal SRTP
processing occurs. If the packet contains a FullEKTField, then processing occurs. If the packet contains a FullEKTField, then
processing continues as described below. The reason for using the processing continues as described below. The reason for using the
last byte of the packet to indicate the type is that the length of last byte of the packet to indicate the type is that the length of
the SRTP part is not known until the decryption has the SRTP part is not known until the decryption has
occurred. At this point in the processing, there is no easy way to occurred. At this point in the processing, there is no easy way to
know where the EKTField would start. However, the whole UDP packet know where the EKTField would start. However, the whole SRTP packet
has been received, so instead of the starting at the front of the has been received, so instead of starting at the front of the
packet, the parsing works backwards at the end of the packet and packet, the parsing works backwards at the end of the packet, and
thus the type is placed at the very end of the packet.</t> thus the type is placed at the very end of the packet.</li>
<t>The Security Parameter Index (SPI) field is used to find the <li>The Security Parameter Index (SPI) field is used to find the
right EKT parameter set to be used for processing the packet. right EKT parameter set to be used for processing the packet.
If there is no matching SPI, then the verification function If there is no matching SPI, then the verification function
MUST return an indication of authentication failure, and <bcp14>MUST</bcp14> return an indication of authentication failure, and
the steps described below are not performed. The EKT parameter the steps described below are not performed. The EKT parameter
set contains the EKTKey, EKTCipher, and the SRTP Master Salt.</t> set contains the EKTKey, the EKTCipher, and the SRTP master salt.</li>
<t>The EKTCiphertext is authenticated and decrypted, as <li>The EKTCiphertext is authenticated and decrypted, as
described in <xref target="cipher"/>, using the EKTKey and EKTCipher found in th described in <xref target="cipher" format="default"/>, using the EKTKey and EKTC
e ipher found in the
previous step. If the EKT decryption operation returns an previous step. If the EKT decryption operation returns an
authentication failure, then EKT processing MUST be aborted. The authentication failure, then EKT processing <bcp14>MUST</bcp14> be aborted. The
receiver SHOULD discard the whole UDP packet.</t> receiver <bcp14>SHOULD</bcp14> discard the whole SRTP packet.</li>
<t>The resulting EKTPlaintext is parsed as described in <xref target="EKT"/>, to <li>The resulting EKTPlaintext is parsed as described in <xref targe
recover the SRTP Master Key, SSRC, and ROC fields. The SRTP Master t="EKT" format="default"/>, to
Salt that is associated with the EKTKey is also retrieved. If the recover the SRTP master key, SSRC, and ROC fields. The SRTP master
value of the srtp_master_salt sent as part of the EKTkey is salt that is associated with the EKTKey is also retrieved. If the
value of the srtp_master_salt (see <xref target="ekt_key"/>) sent as part of the
EKTKey is
longer than needed by SRTP, then it is truncated by taking the longer than needed by SRTP, then it is truncated by taking the
first N bytes from the srtp_master_salt field.</t> first N bytes from the srtp_master_salt field.</li>
<t>If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet <li>If the SSRC in the EKTPlaintext does not match the SSRC of the S
received, then this FullEKTField MUST be discarded and the following steps in RTP packet
received, then this FullEKTField <bcp14>MUST</bcp14> be discarded and the
subsequent steps in
this list skipped. After stripping the FullEKTField, the remainder of this list skipped. After stripping the FullEKTField, the remainder of
the SRTP packet MAY be processed as normal.</t> the SRTP packet <bcp14>MAY</bcp14> be processed as normal.</li>
<t>The SRTP Master Key, ROC, and SRTP Master Salt from the previous <li>
<t>The SRTP master key, ROC, and SRTP master salt from the previou
s
steps are saved in a map indexed by the SSRC found in the steps are saved in a map indexed by the SSRC found in the
EKTPlaintext and can be used for any future crypto operations on EKTPlaintext and can be used for any future crypto operations on
the inbound packets with that SSRC. the inbound packets with that SSRC.
<list style="symbols"> </t>
<t>Unless the transform specifies other acceptable key lengths, <ul spacing="normal">
the length of the SRTP Master Key MUST be the same as the <li>Unless the transform specifies other acceptable key lengths,
the length of the SRTP master key <bcp14>MUST</bcp14> be the same as the
master key length for the SRTP transform in use. If this is master key length for the SRTP transform in use. If this is
not the case, then the receiver MUST abort EKT processing and not the case, then the receiver <bcp14>MUST</bcp14> abort EKT processing and
SHOULD discared the whole UDP packet.</t> <bcp14>SHOULD</bcp14> discard the whole SRTP packet.</li>
<t>If the length of the SRTP Master Key is less than the master <li>If the length of the SRTP master key is less than the master
key length for the SRTP transform in use, and the transform key length for the SRTP transform in use and the transform
specifies that this length is acceptable, then the SRTP Master specifies that this length is acceptable, then the SRTP master
Key value is used to replace the first bytes in the existing key value is used to replace the first bytes in the existing
master key. The other bytes remain the same as in the old key. master key. The other bytes remain the same as in the old key.
For example, the Double GCM transform <xref target="I-D.ietf-perc-double"/> For example, the double GCM transform <xref target="RFC8723" format="default"/>
allows replacement of the first, &quot;end to end&quot; half of the allows replacement of the first ("end-to-end") half of the
master key.</t> master key.</li>
</list></t> </ul>
<t>At this point, EKT processing has successfully completed, and the </li>
normal SRTP processing takes place.</t> <li>At this point, EKT processing has successfully completed, and th
</list> e
</t> normal SRTP processing takes place.</li>
<t>The value of the EKTCiphertext field is identical in successive </ol>
packets protected by the same EKT parameter set and the same SRTP <t>The value of the EKTCiphertext field is identical in successive
master key, and ROC. SRTP senders and receivers MAY cache an packets protected by the same EKT parameter set, SRTP
master key, and ROC.
SRTP senders and receivers <bcp14>MAY</bcp14> cache an
EKTCiphertext value to optimize processing in cases where the master EKTCiphertext value to optimize processing in cases where the master
key hasn't changed. Instead of encrypting and decrypting, senders key hasn't changed. Instead of encrypting and decrypting, senders
can simply copy the pre-computed value and receivers can compare a can simply copy the precomputed value and receivers can compare a
received EKTCiphertext to the known value. received EKTCiphertext to the known value.
</t> </t>
<t><xref target="outbound-processing"/> recommends that SRTP senders continue us <t><xref target="outbound-processing" format="default"/> recommends th
ing at SRTP senders continue using
an old key for some time after sending a new key in an EKT tag. an old key for some time after sending a new key in an EKT Tag.
Receivers that wish to avoid packet loss due to decryption failures Receivers that wish to avoid packet loss due to decryption failures
MAY perform trial decryption with both the old key and the new key, <bcp14>MAY</bcp14> perform trial decryption with both the old key and the new ke y,
keeping the result of whichever decryption succeeds. Note that this keeping the result of whichever decryption succeeds. Note that this
approach is only compatible with SRTP transforms that include approach is only compatible with SRTP transforms that include
integrity protection. integrity protection.
</t> </t>
<t>When receiving a new EKTKey, implementations need to use the <t>When receiving a new EKTKey, implementations need to use the
ekt_ttl field (see <xref target="ekt_key"/>) ekt_ttl field (see <xref target="ekt_key" format="default"/>)
to create a time after which this key cannot be used and they also to create a time after which this key cannot be used, and they also
need to create a counter that keeps track of how many times the key need to create a counter that keeps track of how many times the key
has been used to encrypt data to ensure it does not exceed the T value has been used to encrypt data, to ensure that it does not exceed the T value
for that cipher (see <xref target="cipher"/>). If either of these limits are exc for that cipher (see <xref target="cipher" format="default"/>). If either of
eeded, these limits is exceeded,
the key can no longer be used for encryption. At this point implementation the key can no longer be used for encryption. At this point, implementations
need to either use the call signaling to renegotiate a new session need to either use call signaling to renegotiate a new session
or need to terminate the existing session. Terminating the session is a or terminate the existing session. Terminating the session is a
reasonable implementation choice because these limits should not be reasonable implementation choice because these limits should not be
exceeded except under an attack or error condition. exceeded, except under an attack or error condition.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cipher" numbered="true" toc="default">
<section anchor="cipher" title="Ciphers"> <name>Ciphers</name>
<t>EKT uses an authenticated cipher to encrypt and authenticate the <t>EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext. This specification defines the interface to the cipher, EKTPlaintext. This specification defines the interface to the cipher,
in order to abstract the interface away from the details of that in order to abstract the interface away from the details of that
function. This specification also defines the default cipher that is function. This specification also defines the default cipher that is
used in EKT. The default cipher described in <xref target="DefaultCipher"/> MUST used in EKT. The default cipher described in <xref target="DefaultCipher" format ="default"/> <bcp14>MUST</bcp14>
be implemented, but another cipher that conforms to this interface be implemented, but another cipher that conforms to this interface
MAY be used. The cipher used for a given EKTCiphertext value is <bcp14>MAY</bcp14> be used. The cipher used for a given EKTCiphertext value is
negotiated using the supported_ekt_ciphers and indicated with the negotiated using the supported_ekt_ciphers extension (see <xref target="dtls-srt
p-extensions"/>) and indicated with the
SPI value in the FullEKTField. SPI value in the FullEKTField.
</t> </t>
<t>An EKTCipher consists of an encryption function and a decryption <t>An EKTCipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following inputs: function. The encryption function E(K, P) takes the following inputs:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>a secret key K with a length of L bytes, and</li>
<t>a secret key K with a length of L bytes, and</t> <li>a plaintext value P with a length of M bytes.</li>
<t>a plaintext value P with a length of M bytes.</t> </ul>
</list> <t>The encryption function returns a ciphertext value C whose length is
</t> N
<t>The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. The decryption function D(K,&nbsp;C)
bytes, where N may be larger than M. The decryption function D(K, C)
takes the following inputs: takes the following inputs:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>a secret key K with a length of L bytes, and</li>
<t>a secret key K with a length of L bytes, and</t> <li>a ciphertext value C with a length of N bytes.</li>
<t>a ciphertext value C with a length of N bytes.</t> </ul>
</list> <t>The decryption function returns a plaintext value P that is M bytes
</t> long, or it returns an indication that the decryption operation failed
<t>The decryption function returns a plaintext value P that is M bytes because the ciphertext was invalid (i.e., it was not generated by the
long, or returns an indication that the decryption operation failed
because the ciphertext was invalid (i.e. it was not generated by the
encryption of plaintext with the key K). encryption of plaintext with the key K).
</t> </t>
<t>These functions have the property that D(K, E(K, P)) = P for all <t>These functions have the property that D(K, E(K, P)) = P for all
values of K and P. Each cipher also has a limit T on the number of values of K and P. Each cipher also has a limit T on the number of
times that it can be used with any fixed key value. The EKTKey MUST times that it can be used with any fixed key value. The EKTKey <bcp14>MUST
NOT be used for encryption more that T times. Note that if the same NOT</bcp14> be used for encryption more than T times. Note that if the same
FullEKTField is retransmitted 3 times, that only counts as 1 FullEKTField is retransmitted three times, that only counts as one
encryption. encryption.
</t> </t>
<t>Security requirements for EKT ciphers are discussed in <xref target="sec"/>. <t>Security requirements for EKT Ciphers are discussed in <xref
</t> target="sec" format="default"/>.</t>
<section anchor="DefaultCipher" numbered="true" toc="default">
<section anchor="DefaultCipher" title="AES Key Wrap"> <name>AES Key Wrap</name>
<t>The default EKT Cipher is the Advanced Encryption Standard (AES) Key <t>The default EKT Cipher is the Advanced Encryption Standard (AES)
Wrap with Padding <xref target="RFC5649"/> algorithm. It requires a plaintext Key Wrap with Padding algorithm <xref target="RFC5649" format="default
length M that is at least one octet, and it returns a ciphertext with "/>. It requires a plaintext length M that is at least one
a length of N = M + (M mod 8) + 8 octets. octet, and it returns a ciphertext with a length of N = M + (M mod
<vspace/> 8) + 8 octets. It can be used with key sizes of L = 16 octets or L = 3
It can be used with key sizes of L = 16, and L = 32 octets, and 2
its use with those key sizes is indicated as AESKW128, or AESKW256, octets, and its use with those key sizes is indicated as AESKW128
respectively. The key size determines the length of the AES key used by the or AESKW256, respectively.
Key Wrap algorithm. With this cipher, T=2^48. The key size determines the length of the
</t> AES key used by the Key Wrap algorithm. With this cipher,
<texttable anchor="CipherTable" title="EKT Ciphers T=2<sup>48</sup>.</t>
"> <table anchor="CipherTable" align="center">
<ttcol align="left">Cipher</ttcol> <name>EKT Ciphers</name>
<ttcol align="right">L</ttcol> <thead>
<ttcol align="right">T</ttcol> <tr>
<th align="left">Cipher</th>
<c>AESKW128</c><c>16</c><c>2^48</c> <th align="right">L</th>
<c>AESKW256</c><c>32</c><c>2^48</c> <th align="right">T</th>
</texttable> </tr>
<t>As AES-128 is the mandatory to implement transform in SRTP, AESKW128 </thead>
MUST be implemented for EKT and AESKW256 MAY be implemented. <tbody>
<tr>
<td align="left">AESKW128</td>
<td align="right">16</td>
<td align="right">2<sup>48</sup></td>
</tr>
<tr>
<td align="left">AESKW256</td>
<td align="right">32</td>
<td align="right">2<sup>48</sup></td>
</tr>
</tbody>
</table>
<t>As AES-128 is the mandatory-to-implement transform in SRTP, AESKW12
8
<bcp14>MUST</bcp14> be implemented for EKT. AESKW256 <bcp14>MAY</bcp14> be imple
mented.
</t> </t>
</section> </section>
<section anchor="defining-new-ekt-ciphers" numbered="true" toc="default"
<section anchor="defining-new-ekt-ciphers" title="Defining New EKT Ciphers"> >
<t>Other specifications may extend this document by defining other <name>Defining New EKT Ciphers</name>
EKTCiphers as described in <xref target="iana"/>. This section defines how those <t>Other specifications may extend this document by defining other
EKTCiphers, as described in <xref target="iana" format="default"/>. This section
defines how those
ciphers interact with this specification. ciphers interact with this specification.
</t> </t>
<t>An EKTCipher determines how the EKTCiphertext field is written, and <t>An EKTCipher determines how the EKTCiphertext field is written and
how it is processed when it is read. This field is opaque to the other how it is processed when it is read. This field is opaque to the other
aspects of EKT processing. EKT ciphers are free to use this field in aspects of EKT processing. EKT Ciphers are free to use this field in
any way, but they SHOULD NOT use other EKT or SRTP fields as an any way, but they <bcp14>SHOULD NOT</bcp14> use other EKT or SRTP fields as an
input. The values of the parameters L, and T MUST be defined by each input. The values of the parameters L and T <bcp14>MUST</bcp14> be defined by ea
EKTCipher. The cipher MUST provide integrity protection. ch
EKTCipher.
The cipher <bcp14>MUST</bcp14> provide integrity protection.
</t> </t>
</section> </section>
</section> </section>
<section anchor="SynchronizingOperation" numbered="true" toc="default">
<section anchor="SynchronizingOperation" title="Synchronizing Operation"> <name>Synchronizing Operation</name>
<t>If a source has its EKTKey changed by the key management, it MUST also <t>If a source has its EKTKey changed by key management, it <bcp14>MUST<
/bcp14> also
change its SRTP master key, which will cause it to send out a new change its SRTP master key, which will cause it to send out a new
FullEKTField and eventually begin encrypting with it, as defined in FullEKTField and eventually begin encrypting with it, as described in
<xref target="outbound-processing"/>. <xref target="outbound-processing" format="default"/>.
This ensures that if key management thought the EKTKey This ensures that if key management thought the EKTKey
needs changing (due to a participant leaving or joining) and needs changing (due to a participant leaving or joining) and
communicated that to a source, the source will also change its SRTP communicated that to a source, the source will also change its SRTP
master key, so that traffic can be decrypted only by those who know master key, so that traffic can be decrypted only by those who know
the current EKTKey. the current EKTKey.
</t> </t>
</section> </section>
<section anchor="timing" numbered="true" toc="default">
<section anchor="timing" title="Timing and Reliability Consideration"> <name>Timing and Reliability Considerations</name>
<t>A system using EKT learns the SRTP master keys distributed with <t>A system using EKT learns the SRTP master keys distributed with
the FullEKTField sent with the SRTP, rather than with call signaling. A the FullEKTField sent with SRTP, rather than with call signaling.
A
receiver can immediately decrypt an SRTP packet, provided the SRTP receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a FullEKTField. packet contains a FullEKTField.
</t> </t>
<t>This section describes how to reliably and expediently deliver new <t>This section describes how to reliably and expediently deliver new
SRTP master keys to receivers. SRTP master keys to receivers.
</t> </t>
<t>There are three cases to consider. The first case is a new sender <t>There are three cases to consider. In the first case, a new
joining a session, which needs to communicate its SRTP master key to sender joins a session and needs to communicate its SRTP
all the receivers. The second case is a sender changing its SRTP master key to all the receivers. In the second case, a sender
master key which needs to be communicated to all the receivers. The changes its SRTP master key, which needs to be communicated to all
third case is a new receiver joining a session already in progress the receivers. In the third case, a new receiver joins a session
which needs to know the sender's SRTP master key. already in progress and needs to know the sender's SRTP
</t> master key.
<t>The three cases are:
</t> </t>
<t> <t>The three cases are as follows:</t>
<list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="New sender:"> <dt>New sender:</dt>
<vspace /> <dd>
A new sender SHOULD send a packet containing the A new sender <bcp14>SHOULD</bcp14> send a packet containing the
FullEKTField as soon as possible, always before or coincident with FullEKTField as soon as possible, ideally in its initial SRTP packet. To accomm
sending its initial SRTP packet. To accommodate packet loss, it is odate packet loss, it is
RECOMMENDED that the FullEKTField be transmitted in three consecutive packets. <bcp14>RECOMMENDED</bcp14> that the FullEKTField be transmitted in three consecu
tive packets.
If the sender does not send a FullEKTField in its If the sender does not send a FullEKTField in its
initial packets and receivers have not otherwise been provisioned initial packets and receivers have not otherwise been provisioned
with a decryption key, then decryption will fail and SRTP packets with a decryption key, then decryption will fail and SRTP packets
will be dropped until the receiver receives a FullEKTField from the will be dropped until the receiver receives a FullEKTField from the
sender.</t> sender.</dd>
<t hangText="Rekey:"> <dt>Rekey:</dt>
<vspace /> <dd>
By sending EKT tag over SRTP, the rekeying event shares fate with the By sending an EKT Tag over SRTP, the rekeying event shares fate with the
SRTP packets protected with that new SRTP master key. To accommodate SRTP packets protected with that new SRTP master key. To accommodate
packet loss, it is RECOMMENDED that three consecutive packets contain packet loss, it is <bcp14>RECOMMENDED</bcp14> that three consecutive packets
the FullEKTField be transmitted.</t> containing the FullEKTField be transmitted.</dd>
<t hangText="New receiver:"> <dt>New receiver:</dt>
<vspace /> <dd>
When a new receiver joins a session it does not need to communicate When a new receiver joins a session, it does not need to communicate
its sending SRTP master key (because it is a receiver). When a new its sending SRTP master key (because it is a receiver). Also, when a new
receiver joins a session, the sender is generally unaware of the receiver joins a session, the sender is generally unaware of the
receiver joining the session. Thus, senders SHOULD periodically receiver joining the session; thus, senders <bcp14>SHOULD</bcp14> periodically
transmit the FullEKTField. That interval depends on how frequently new transmit the FullEKTField. That interval depends on how frequently new
receivers join the session, the acceptable delay before those receivers join the session, the acceptable delay before those
receivers can start processing SRTP packets, and the acceptable receivers can start processing SRTP packets, and the acceptable
overhead of sending the FullEKTField. If sending audio and video, the overhead of sending the FullEKTField. If sending audio and video, the
RECOMMENDED frequency is the same as the rate of intra coded video <bcp14>RECOMMENDED</bcp14> frequency is the same as the rate of intra-coded vide
frames. If only sending audio, the RECOMMENDED frequency is every o
100ms.</t> frames. If only sending audio, the <bcp14>RECOMMENDED</bcp14> frequency is every
</list> 100&nbsp;ms.</dd>
</t> </dl>
<t>In general, sending EKT tags less frequently will consume less bandwidth, but <t>If none of the above three cases apply, a ShortEKTField <bcp14>SHOULD
increase the time it takes for a join or rekey to take effect. Applications </bcp14> be sent.
should schedule the sending of EKT tags in a way that makes sense for their </t>
bandwidth and latency requirements.
</t>
</section>
</section>
<section anchor="dtls-srtp-kt" title="Use of EKT with DTLS-SRTP"> <t>
<t>This document defines an extension to DTLS-SRTP called SRTP EKTKey In general, sending FullEKTField tags less frequently will consume less
Transport which enables secure transport of EKT keying material from bandwidth but will increase the time it takes for a join or rekey to
take effect. Applications should schedule the sending of FullEKTField tags in
a way that makes sense for their bandwidth and latency requirements.
</t>
</section>
</section>
<section anchor="dtls-srtp-kt" numbered="true" toc="default">
<name>Use of EKT with DTLS-SRTP</name>
<t>This document defines an extension to DTLS-SRTP called "SRTP EKTKey
Transport", which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client. This allows the DTLS-SRTP peer in the server role to the client. This allows
those peers to process EKT keying material in SRTP and such a peer to process EKT keying material in SRTP and
retrieve the embedded SRTP keying material. This combination of retrieve the embedded SRTP keying material.
This combination of
protocols is valuable because it combines the advantages of DTLS, protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility, which has strong authentication of the endpoint and flexibility,
along with allowing secure multiparty RTP with loose coordination along with allowing secure multi-party RTP with loose coordination
and efficient communication of per-source keys. and efficient communication of per-source keys.
</t> </t>
<t>In cases where the DTLS termination point is more trusted than the <t>In cases where the DTLS termination point is more trusted than the
media relay, the protection that DTLS affords to EKT key material media relay, the protection that DTLS affords to EKT keying material
can allow EKT keys to be tunneled through an untrusted relay such as can allow EKT Keys to be tunneled through an untrusted relay such as
a centralized conference bridge. For more details, see a centralized conference bridge. For more details, see
<xref target="I-D.ietf-perc-private-media-framework"/>. <xref target="RFC8871" format="default"/>.
</t> </t>
<section anchor="dtlssrtp-recap" numbered="true" toc="default">
<section anchor="dtlssrtp-recap" title="DTLS-SRTP Recap"> <name>DTLS-SRTP Recap</name>
<t>DTLS-SRTP <xref target="RFC5764"/> uses an extended DTLS exchange between two <t>DTLS-SRTP <xref target="RFC5764" format="default"/> uses an extended
DTLS exchange between two
peers to exchange keying material, algorithms, and parameters for peers to exchange keying material, algorithms, and parameters for
SRTP. The SRTP flow operates over the same transport as the SRTP. The SRTP flow operates over the same transport as the
DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
performance and encryption flexibility benefits of SRTP with the performance and encryption flexibility benefits of SRTP with the
flexibility and convenience of DTLS-integrated key and association flexibility and convenience of DTLS-integrated key and association
management. DTLS-SRTP can be viewed in two equivalent ways: as a new management. DTLS-SRTP can be viewed in two equivalent ways: as a new
key management method for SRTP, and a new RTP-specific data format key management method for SRTP and as a new RTP-specific data format
for DTLS. for DTLS.
</t> </t>
</section> </section>
<section anchor="dtls-srtp-extensions" numbered="true" toc="default">
<section anchor="dtls-srtp-extensions" title="SRTP EKT Key Transport Extensions <name>SRTP EKT Key Transport Extensions to DTLS-SRTP</name>
to DTLS-SRTP"> <t>This document defines a new TLS negotiated extension
<t>This document defines a new TLS negotiated extension called "supported_ekt_ciphers" and a new TLS handshake message type called
supported_ekt_ciphers and a new TLS handshake message type "ekt_key". The extension negotiates the cipher to be used in
ekt_key. The extension negotiates the cipher to be used in
encrypting and decrypting EKTCiphertext values, and the handshake encrypting and decrypting EKTCiphertext values, and the handshake
message carries the corresponding key. message carries the corresponding key.
</t> </t>
<t><xref target="dtls-srtp-flow"/> shows a message flow of DTLS 1.3 client and s <t><xref target="dtls-srtp-flow" format="default"/> shows a message
erver flow between a DTLS 1.3 client and server
using EKT configured using the DTLS extensions described in this using EKT configured using the DTLS extensions described in this
section. (The initial cookie exchange and other normal DTLS section. (The initial cookie exchange and other normal DTLS
messages are omitted.) To be clear, EKT can be used with versions messages are omitted.) To be clear, EKT can be used with versions
of DTLS prior to 1.3. The only difference is that in a pre-1.3 TLS of DTLS prior to 1.3. The only difference is that in pre-1.3 TLS,
stacks will not have built-in support for generating and processing stacks will not have built-in support for generating and processing
ACK messages. ACK messages.
</t> </t>
<figure anchor="dtls-srtp-flow">
<figure anchor="dtls-srtp-flow" align="center"><artwork align="center"> <name>DTLS 1.3 Message Flow</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
Client Server Client Server
ClientHello ClientHello
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
--------&gt; -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
{... Finished} {... Finished}
&lt;-------- <--------
{... Finished} --------&gt; {... Finished} -------->
[ACK] [ACK]
&lt;-------- [EKTKey] <-------- [EKTKey]
[ACK] --------&gt; [ACK] -------->
|SRTP packets| &lt;-------&gt; |SRTP packets| |SRTP packets| <-------> |SRTP packets|
+ &lt;EKT tags&gt; + &lt;EKT tags&gt; + <EKT Tags> + <EKT Tags>
<span class="insert">&lt;EKT Tags&gt;</span> + <span class="insert">&lt;EKT Tags&gt;</span>
{} Messages protected using DTLS handshake keys {} Messages protected using DTLS handshake keys
[] Messages protected using DTLS application traffic keys [] Messages protected using DTLS application traffic keys
<&gt; Messages protected using the EKTKey and EKT cipher <> Messages protected using the EKTKey and EKT Cipher
|| Messages protected using the SRTP Master Key sent in || Messages protected using the SRTP master key sent in
a Full EKT Tag a Full EKT Tag]]></artwork>
</artwork></figure> </figure>
<t>In the context of a multi-party SRTP session in which each endpoint <t>In the context of a multi-party SRTP session in which each endpoint
performs a DTLS handshake as a client with a central DTLS server, performs a DTLS handshake as a client with a central DTLS server,
the extensions defined in this document allow the DTLS server to set the extensions defined in this document allow the DTLS server to set
a common EKTKey for all participants. Each endpoint can then use a common EKTKey for all participants. Each endpoint can then use
EKT tags encrypted with that common key to inform other endpoint of EKT Tags encrypted with that common key to inform other endpoints of
the keys it uses to protect SRTP packets. This avoids the need the keys it uses to protect SRTP packets. This avoids the need
for many individual DTLS handshakes among the endpoints, at the cost for many individual DTLS handshakes among the endpoints, at the cost
of preventing endpoints from directly authenticating one another. of preventing endpoints from directly authenticating one another.
</t> </t>
<artwork align="center" name="" type="" alt=""><![CDATA[
<figure align="center"><artwork align="center">
Client A Server Client B Client A Server Client B
&lt;----DTLS Handshake----&gt; <----DTLS Handshake---->
&lt;--------EKTKey--------- <--------EKTKey---------
&lt;----DTLS Handshake----&gt; <----DTLS Handshake---->
---------EKTKey--------&gt; ---------EKTKey-------->
-------------SRTP Packet + EKT Tag-------------&gt;
&lt;------------SRTP Packet + EKT Tag--------------
</artwork></figure>
<section anchor="negotiating-an-ektcipher" title="Negotiating an EKTCipher"> -------------SRTP Packet + EKT Tag------------->
<t>To indicate its support for EKT, a DTLS-SRTP client includes in its <------------SRTP Packet + EKT Tag--------------]]></artwork>
<section anchor="negotiating-an-ektcipher" numbered="true" toc="default"
>
<name>Negotiating an EKTCipher</name>
<t>To indicate its support for EKT, a DTLS-SRTP client includes in its
ClientHello an extension of type supported_ekt_ciphers listing the ClientHello an extension of type supported_ekt_ciphers listing the
ciphers used for EKT by the client supports in preference order, with ciphers used for EKT by the client, in preference order, with
the most preferred version first. If the server agrees to use EKT, the most preferred version first. If the server agrees to use EKT,
then it includes a supported_ekt_ciphers extension in its ServerHello then it includes a supported_ekt_ciphers extension in its
EncryptedExtensions (or ServerHello for DTLS 1.2)
containing a cipher selected from among those advertised by the containing a cipher selected from among those advertised by the
client. client.
</t> </t>
<t>The extension_data field of this extension contains an &quot;EKTCipher&quot; <t>The extension_data field of this extension contains an "EKTCipher"
value, value,
encoded using the syntax defined in <xref target="RFC8446"/>: encoded using the syntax defined in <xref target="RFC8446" format="default"/>:
</t> </t>
<sourcecode name="" type="tls-presentation"><![CDATA[
enum {
reserved(0),
aeskw_128(1),
aeskw_256(2),
} EKTCipherType;
<figure align="center"><artwork align="center"> struct {
enum { select (Handshake.msg_type) {
reserved(0), case client_hello:
aeskw_128(1), EKTCipherType supported_ciphers<1..255>;
aeskw_256(2),
} EKTCipherType;
struct { case server_hello:
select (Handshake.msg_type) { EKTCipherType selected_cipher;
case client_hello:
EKTCipherType supported_ciphers&lt;1..255&gt;;
case server_hello: case encrypted_extensions:
EKTCipherType selected_cipher; EKTCipherType selected_cipher;
};
} EKTCipher;
</artwork></figure>
</section>
<section anchor="ekt_key" title="Establishing an EKT Key"> };
<t>Once a client and server have concluded a handshake that negotiated } EKTCipher;]]></sourcecode>
an EKTCipher, the server MUST provide to the client a key to be </section>
<section anchor="ekt_key" numbered="true" toc="default">
<name>Establishing an EKT Key</name>
<t>Once a client and server have concluded a handshake that negotiated
an EKTCipher, the server <bcp14>MUST</bcp14> provide to the client a key to be
used when encrypting and decrypting EKTCiphertext values. EKTKeys used when encrypting and decrypting EKTCiphertext values. EKTKeys
are sent in encrypted handshake records, using handshake type are sent in encrypted handshake records, using handshake type
ekt_key(TBD). The body of the handshake message contains an ekt_key(26). The body of the handshake message contains an
EKTKey structure: EKTKey structure as follows:
</t>
<t>[[ NOTE: RFC Editor, please replace &quot;TBD&quot; above with the code point
assigned by IANA ]]
</t> </t>
<figure align="center"><artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
struct { struct {
opaque ekt_key_value&lt;1..256&gt;; opaque ekt_key_value<1..256>;
opaque srtp_master_salt&lt;1..256&gt;; opaque srtp_master_salt<1..256>;
uint16 ekt_spi; uint16 ekt_spi;
uint24 ekt_ttl; uint24 ekt_ttl;
} EKTKey; } EKTKey;]]></artwork>
</artwork></figure> <t>The contents of the fields in this message are as follows:
<t>The contents of the fields in this message are as follows:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>ekt_key_value</dt>
<t hangText="ekt_key_value"> <dd>
<vspace />
The EKTKey that the recipient should use when generating EKTCiphertext The EKTKey that the recipient should use when generating EKTCiphertext
values</t> values</dd>
<t hangText="srtp_master_salt"> <dt>srtp_master_salt</dt>
<vspace /> <dd>
The SRTP Master Salt to be used with any Master Key encrypted with this EKT The SRTP master salt to be used with any master key encrypted with this EKT
Key</t> Key</dd>
<t hangText="ekt_spi"> <dt>ekt_spi</dt>
<vspace /> <dd>
The SPI value to be used to reference this EKTKey and SRTP Master Salt in The SPI value to be used to reference this EKTKey and SRTP master salt in
EKT tags (along with the EKT cipher negotiated in the handshake)</t> EKT Tags (along with the EKT Cipher negotiated in the handshake)</dd>
<t hangText="ekt_ttl"> <dt>ekt_ttl</dt>
<vspace /> <dd>
The maximum amount of time, in seconds, that this EKTKey can be used. The The maximum amount of time, in seconds, that this EKTKey can be used. The
ekt_key_value in this message MUST NOT be used for encrypting or decrypting ekt_key_value in this message <bcp14>MUST NOT</bcp14> be used for encrypting or
information after the TTL expires.</t> decrypting
</list> information after the TTL expires.</dd>
</t> </dl>
<t>If the server did not provide a supported_ekt_ciphers extension in <t>If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by the client its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey messages <bcp
14>MUST NOT</bcp14> be sent by the client
or the server. or the server.
</t> </t>
<t>When an EKTKey is received and processed successfully, the recipient <t>When an EKTKey is received and processed successfully, the
MUST respond with an ACK message as described in Section 7 recipient <bcp14>MUST</bcp14> respond with an ACK message as
of <xref target="I-D.ietf-tls-dtls13"/>. The EKTKey message and ACK MUST be described in <xref target="I-D.ietf-tls-dtls13" sectionFormat="of"
retransmitted following the rules of the negotiated version of DTLS. section="7"/>. The EKTKey message and ACK <bcp14>MUST</bcp14> be
</t> retransmitted following the rules of the negotiated version of
<t>EKT MAY be used with versions of DTLS prior to 1.3. In such cases, DTLS.</t>
the ACK message is still used to provide reliability. Thus, DTLS <t>EKT <bcp14>MAY</bcp14> be used with versions of DTLS prior to
implementations supporting EKT with DTLS pre-1.3 will need to have 1.3. In such cases, to provide reliability, the ACK message is still
used. Thus, DTLS
implementations supporting EKT with pre-1.3 versions of DTLS will need to have
explicit affordances for sending the ACK message in response to an explicit affordances for sending the ACK message in response to an
EKTKey message, and for verifying that an ACK message was received. EKTKey message and for verifying that an ACK message was received.
The retransmission rules for both sides are otherwise defined by the The retransmission rules for both sides are otherwise defined by the
negotiated version of DTLS. negotiated version of DTLS.
</t> </t>
<t>If an EKTKey message is received that cannot be processed, then the <t>If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert. recipient <bcp14>MUST</bcp14> respond with an appropriate DTLS alert.
</t>
</section>
</section>
<section anchor="offeranswer-considerations" title="Offer/Answer Considerations"
>
<t>When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
the DTLS handshake level and does not change the <xref target="RFC3264"/> Offer
/
Answer messaging.
</t>
</section>
<section anchor="sending-the-dtls-ektkey-reliably" title="Sending the DTLS EKTKe
y Reliably">
<t>The DTLS EKTKey message is sent using the retransmissions
specified in Section 4.2.4. of DTLS <xref target="RFC6347"/>. Retransmission i
s
finished with an ACK message or an alert is received.
</t> </t>
</section> </section>
</section> </section>
<section anchor="offeranswer-considerations" numbered="true" toc="default"
<section anchor="sec" title="Security Considerations"> >
<t>EKT inherits the security properties of the the key management <name>Offer/Answer Considerations</name>
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP <t>When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
extension defined in this document. the DTLS handshake level and does not change the SDP Offer&wj;/Answer messaging
<xref target="RFC3264" format="default"/>.
</t> </t>
<t>With EKT, each SRTP sender and receiver MUST generate distinct SRTP </section>
master keys. This property avoids any security concern over the re-use <section anchor="sending-the-dtls-ektkey-reliably" numbered="true" toc="de
fault">
<name>Sending the DTLS EKTKey Reliably</name>
<t>The DTLS EKTKey message is sent using the retransmissions specified
in <xref target="RFC6347" sectionFormat="of" section="4.2.4">DTLS</xref>
.
Retransmission is finished with an ACK message, or an alert is
received.</t>
</section>
</section>
<section anchor="sec" numbered="true" toc="default">
<name>Security Considerations</name>
<t>EKT inherits the security properties of the key management
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP
extension defined in this document.</t>
<t>With EKT, each SRTP sender and receiver <bcp14>MUST</bcp14> generate di
stinct SRTP
master keys. This property avoids any security concerns over the reuse
of keys, by empowering the SRTP layer to create keys on demand. Note of keys, by empowering the SRTP layer to create keys on demand. Note
that the inputs of EKT are the same as for SRTP with key-sharing: a that the inputs of EKT are the same as for SRTP with key-sharing: a
single key is provided to protect an entire SRTP session. However, EKT single key is provided to protect an entire SRTP session. However, EKT
remains secure even when SSRC values collide. remains secure even when SSRC values collide.
</t> </t>
<t>SRTP master keys MUST be randomly generated, and <xref target="RFC4086"/> off <t>SRTP master keys <bcp14>MUST</bcp14> be randomly generated, and <xref t
ers arget="RFC4086" format="default"/> offers
some guidance about random number generation. SRTP master keys MUST some guidance about random number generation. SRTP master keys <bcp14>MUST
NOT be re-used for any other purpose, and SRTP master keys MUST NOT be NOT</bcp14> be reused for any other purpose, and SRTP master keys <bcp14>MUST NO
T</bcp14> be
derived from other SRTP master keys. derived from other SRTP master keys.
</t> </t>
<t>The EKT Cipher includes its own authentication/integrity check. For an <t>The EKT Cipher includes its own authentication/integrity check.
attacker to successfully forge a FullEKTField, it would need to defeat
the authentication mechanisms of the EKT Cipher authentication
mechanism.
</t> </t>
<t>The presence of the SSRC in the EKTPlaintext ensures that an attacker <t>The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream. This mitigates the impact of the cut-and-paste attacks SRTP stream. This mitigates the impact of cut-and-paste attacks
that arise due to the lack of a cryptographic binding between the that arise due to the lack of a cryptographic binding between the
EKT tag and the rest of the SRTP packet. SRTP tags can only be EKT Tag and the rest of the SRTP packet. SRTP tags can only be
cut-and-pasted within the stream of packets sent by a given RTP cut-and-pasted within the stream of packets sent by a given RTP
endpoint; an attacker cannot &quot;cross the streams&quot; and use an EKT tag endpoint; an attacker cannot "cross the streams" and use an EKT Tag
from one SSRC to reset the key for another SSRC. The epoch field from one SSRC to reset the key for another SSRC. The Epoch field
in the FullEKTField also prevents an attacker from rolling back to a in the FullEKTField also prevents an attacker from rolling back to a
previous key. previous key.
</t> </t>
<t>An attacker could send packets containing a FullEKTField, in an <t>An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system by attempt to consume additional CPU resources of the receiving system by
causing the receiving system to decrypt the EKT ciphertext and causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the previous detect an authentication failure. In some cases, caching the previous
values of the Ciphertext as described in <xref target="inbound-processing"/> hel ps values of the ciphertext as described in <xref target="inbound-processing" forma t="default"/> helps
mitigate this issue. mitigate this issue.
</t> </t>
<t>In a similar vein, EKT has no replay protection, so an attacker <t>In a similar vein, EKT has no replay protection, so an attacker
could implant improper keys in receivers by capturing EKTCiphertext could implant improper keys in receivers by capturing EKTCiphertext
values encrypted with a given EKTKey and replaying them in a values encrypted with a given EKTKey and replaying them in a
different context, e.g., from a different sender. When the different context, e.g., from a different sender. When the
underlying SRTP transform provides integrity protection, this attack underlying SRTP transform provides integrity protection, this attack
will just result in packet loss. If it does not, then it will will just result in packet loss. If it does not, then it will
result in random data being fed to RTP payload processing. An result in random data being fed to RTP payload processing. An
attacker that is in a position to mount these attacks, however, attacker that is in a position to mount these attacks, however,
could achieve the same effects more easily without attacking EKT. could achieve the same effects more easily without attacking EKT.
</t> </t>
<t>The key encryption keys distributed with EKTKey messages are group <t>The key encryption keys distributed with EKTKey messages are group
shared symmetric keys, which means they do not provide protection shared symmetric keys, which means they do not provide protection
within the group. Group members can impersonate each other; for within the group. Group members can impersonate each other; for
example, any group member can generate an EKT tag for any SSRC. The example, any group member can generate an EKT Tag for any SSRC. The
entity that distributes EKTKeys can decrypt any keys distributed entity that distributes EKTKeys can decrypt any keys distributed
using EKT, and thus any media protected with those keys. using EKT and thus any media protected with those keys.
</t> </t>
<t>Each EKT cipher specifies a value T that is the maximum number of <t>Each EKT Cipher specifies a value T that is the maximum number of
times a given key can be used. An endpoint MUST NOT encrypt more than times a given key can be used. An endpoint <bcp14>MUST NOT</bcp14> encrypt more
than
T different FullEKTField values using the same EKTKey. In addition, the T different FullEKTField values using the same EKTKey. In addition, the
EKTKey MUST NOT be used beyond the lifetime provided by the TTL EKTKey <bcp14>MUST NOT</bcp14> be used beyond the lifetime provided by the TTL
described in <xref target="dtls-srtp-extensions"/>. described in <xref target="dtls-srtp-extensions" format="default"/>.
</t> </t>
<t>The confidentiality, integrity, and authentication of the EKT cipher <t>The key length of the EKT Cipher
MUST be at least as strong as the SRTP cipher and at least as strong <bcp14>MUST</bcp14> be at least as long as the SRTP cipher and at least as long
as the DTLS-SRTP ciphers. as the DTLS-SRTP ciphers.
</t> </t>
<t>Part of the EKTPlaintext is known, or easily guessable to an <t>Part of the EKTPlaintext is known or is easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. In attacker. Thus, the EKT Cipher <bcp14>MUST</bcp14> resist known plaintext attack
s. In
practice, this requirement does not impose any restrictions on our practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when much choices, since the ciphers in use provide high security even when much
plaintext is known. plaintext is known.
</t> </t>
<t>An EKT cipher MUST resist attacks in which both ciphertexts and <t>An EKT Cipher <bcp14>MUST</bcp14> resist attacks in which both cipherte
plaintexts can be adaptively chosen and adversaries that can query xts and
both the encryption and decryption functions adaptively. plaintexts can be adaptively chosen by an attacker querying both
the encryption and decryption functions.
</t> </t>
<t>In some systems, when a member of a conference leaves the conferences, <t>In some systems, when a member of a conference leaves the conference,
the conferences is rekeyed so that member no longer has the key. When that conference is rekeyed so that the member who left the conference no longer
has the key. When
changing to a new EKTKey, it is possible that the attacker could block changing to a new EKTKey, it is possible that the attacker could block
the EKTKey message getting to a particular endpoint and that endpoint the EKTKey message getting to a particular endpoint and that endpoint
would keep sending media encrypted using the old key. To mitigate that would keep sending media encrypted using the old key. To mitigate that
risk, the lifetime of the EKTKey MUST be limited using the ekt_ttl. risk, the lifetime of the EKTKey <bcp14>MUST</bcp14> be limited by using the ekt
</t> _ttl.
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="iana-ekt-msg-types" title="EKT Message Types">
<t>IANA is requested to create a new table for &quot;EKT Messages Types&quot; in
the &quot;Real-Time Transport Protocol (RTP) Parameters&quot; registry. The
initial values in this registry are:
</t> </t>
<texttable anchor="EKTMsgTypeTable" title="EKT Messages Types </section>
"> <section anchor="iana" numbered="true" toc="default">
<ttcol align="left">Message Type</ttcol> <name>IANA Considerations</name>
<ttcol align="right">Value</ttcol> <section anchor="iana-ekt-msg-types" numbered="true" toc="default">
<ttcol align="left">Specification</ttcol> <name>EKT Message Types</name>
<c>Short</c><c>0</c><c>RFCAAAA</c> <t>IANA has created a new table for "EKT Message Types" in
<c>Full</c><c>2</c><c>RFCAAAA</c> the "Real-Time Transport Protocol (RTP) Parameters" registry. The
<c>Unallocated</c><c>3-254</c><c>RFCAAAA</c> initial values in this registry are as follows:
<c>Reserved</c><c>255</c><c>RFCAAAA</c>
</texttable>
<t>Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification.
</t>
<t>New entries to this table can be added via &quot;Specification Required&quot;
as
defined in <xref target="RFC8126"/>. IANA SHOULD prefer allocation of even valu
es
over odd ones until the even code points are consumed to avoid
conflicts with pre standard versions of EKT that have been deployed.
Allocated values MUST be in the range of 0 to 254.
</t> </t>
<t>All new EKT messages MUST be defined to have a length as second from <table anchor="EKTMsgTypeTable" align="center">
the last element, as specified. <name>EKT Message Types</name>
<thead>
<tr>
<th align="left">Message Type</th>
<th align="right">Value</th>
<th align="left">Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Short</td>
<td align="right">0</td>
<td align="left">RFC 8870</td>
</tr>
<tr>
<td align="left">Unassigned</td>
<td align="right">1</td>
<td align="left"></td>
</tr>
<tr>
<td align="left">Full</td>
<td align="right">2</td>
<td align="left">RFC 8870</td>
</tr>
<tr>
<td align="left">Unassigned</td>
<td align="right">3-254</td>
<td align="left"></td>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="right">255</td>
<td align="left">RFC 8870</td>
</tr>
</tbody>
</table>
<t>New entries in this table can be added via "Specification Required" a
s
defined in <xref target="RFC8126" format="default"/>. To avoid conflicts with
pre-standard versions of EKT that have been deployed, IANA
<bcp14>SHOULD</bcp14> give preference to the allocation of even values over odd
values until
the even code points are consumed. Allocated values <bcp14>MUST</bcp14> be in th
e range of 0 to 254.
</t> </t>
</section> <t>All new EKT messages <bcp14>MUST</bcp14> be defined to include a leng
th parameter, as specified in <xref target="EKT"/>.
<section anchor="iana-ciphers" title="EKT Ciphers">
<t>IANA is requested to create a new table for &quot;EKT Ciphers&quot; in the
&quot;Real-Time Transport Protocol (RTP) Parameters&quot; registry. The initial
values in this registry are:
</t> </t>
<texttable anchor="EKTCipherTable" title="EKT Cipher Types </section>
"> <section anchor="iana-ciphers" numbered="true" toc="default">
<ttcol align="left">Name</ttcol> <name>EKT Ciphers</name>
<ttcol align="right">Value</ttcol>
<ttcol align="left">Specification</ttcol>
<c>AESKW128</c><c>0</c><c>RFCAAAA</c> <t>IANA has created a new table for "EKT Ciphers" in the
<c>AESKW256</c><c>1</c><c>RFCAAAA</c> "Real-Time Transport Protocol (RTP) Parameters" registry. The initial
<c>Unallocated</c><c>2-254</c><c></c> values in this registry are as follows:
<c>Reserved</c><c>255</c><c>RFCAAAA</c>
</texttable>
<t>Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification.
</t> </t>
<t>New entries to this table can be added via &quot;Specification Required&quot; <table anchor="EKTCipherTable" align="center">
as <name>EKT Cipher Types</name>
defined in <xref target="RFC8126"/>. The expert SHOULD ensure the specification <thead>
defines the values for L and T as required in <xref target="cipher"/> of <tr>
RFCAAAA. Allocated values MUST be in the range of 0 to 254. <th align="left">Name</th>
<th align="right">Value</th>
<th align="left">Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">AESKW128</td>
<td align="right">0</td>
<td align="left">RFC 8870</td>
</tr>
<tr>
<td align="left">AESKW256</td>
<td align="right">1</td>
<td align="left">RFC 8870</td>
</tr>
<tr>
<td align="left">Unassigned</td>
<td align="right">2-254</td>
<td align="left"/>
</tr>
<tr>
<td align="left">Reserved</td>
<td align="right">255</td>
<td align="left">RFC 8870</td>
</tr>
</tbody>
</table>
<t>New entries in this table can be added via "Specification Required" a
s
defined in <xref target="RFC8126" format="default"/>. The expert
<bcp14>SHOULD</bcp14> ensure that the specification
defines the values for L and T as required in <xref target="cipher"
format="default"/> of this document. Allocated values <bcp14>MUST</bcp14> be in
the range of 0 to 254.
</t> </t>
</section> </section>
<section anchor="tls-extensions" numbered="true" toc="default">
<name>TLS Extensions</name>
<section anchor="tls-extensions" title="TLS Extensions"> <t>IANA has added supported_ekt_ciphers as a new extension
<t>IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer
name to the &quot;TLS ExtensionType Values&quot; table of the &quot;Transport La Security (TLS) Extensions" registry:
yer
Security (TLS) Extensions&quot; registry:
</t> </t>
<dl newline="false" spacing="normal">
<dt>Value:</dt>
<dd>39</dd>
<dt>Extension Name:</dt>
<dd>supported_ekt_ciphers</dd>
<dt>TLS 1.3:</dt>
<dd>CH, EE</dd>
<dt>Recommended:</dt>
<dd>Y</dd>
<dt>Reference:</dt>
<dd>RFC 8870</dd>
</dl>
</section>
<section anchor="tls-handshake-type" numbered="true" toc="default">
<name>TLS Handshake Type</name>
<figure align="center"><artwork align="center"> <t>IANA has added ekt_key as a new entry in the "TLS
Value: [TBD-at-Registration] HandshakeType" table of the "Transport Layer Security (TLS)
Extension Name: supported_ekt_ciphers Parameters" registry:
TLS 1.3: CH, SH </t>
Recommended: Y <dl newline="false" spacing="normal">
Reference: RFCAAAA <dt>Value:</dt>
</artwork></figure> <dd>26</dd>
<t>[[ Note to RFC Editor: TBD will be allocated by IANA. ]] <dt>Description:</dt>
</t> <dd>ekt_key</dd>
</section> <dt>DTLS-OK:</dt>
<dd>Y</dd>
<dt>Reference:</dt>
<dd>RFC 8870</dd>
<dt>Comment:</dt>
<dd></dd>
</dl>
</section>
</section>
</middle>
<back>
<section anchor="tls-handshake-type" title="TLS Handshake Type"> <displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
<t>IANA is requested to add ekt_key as a new entry in the &quot;TLS
HandshakeType Registry&quot; table of the &quot;Transport Layer Security (TLS)
Parameters&quot; registry:
</t>
<figure align="center"><artwork align="center"> <references>
Value: [TBD-at-Registration] <name>References</name>
Description: ekt_key <references>
DTLS-OK: Y <name>Normative References</name>
Reference: RFCAAAA <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Comment: FC.2119.xml"/>
</artwork></figure> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>[[ Note to RFC Editor: TBD will be allocated by IANA. ]] FC.3264.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.3711.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5649.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5764.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
</references>
<references>
<name>Informative References</name>
<section anchor="acknowledgements" title="Acknowledgements"> <!-- draft-ietf-perc-double (RFC 8723 / Published) -->
<t>Thank you to Russ Housley provided detailed review and significant
help with crafting text for this document. Thanks to David Benham, Yi
Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Jones,
Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner,
Magnus Westerlund, and Felix Wyss for fruitful discussions, comments,
and contributions to this document.
</t>
</section>
</middle> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<back> FC.8723.xml"/>
<references title="Normative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.32
64.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.37
11.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
34.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.56
49.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.57
64.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.63
47.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"?>
</references>
<references title="Informative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-perc-double.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-perc-private-media-framework.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-tls-dtls13.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.40
86.xml"?>
</references>
</back> <!-- draft-ietf-perc-private-media-framework (RFC 8871) -->
<reference anchor='RFC8871' target="https://www.rfc-editor.org/info/rfc8871">
<front>
<title>A Solution Framework for Private Media in Privacy-Enhanced RTP Conferenci
ng (PERC)</title>
<author initials='P' surname='Jones' fullname='Paul Jones'>
<organization />
</author>
<author initials='D' surname='Benham' fullname='David Benham'>
<organization />
</author>
<author initials='C' surname='Groves' fullname='Christian Groves'>
<organization />
</author>
<date month='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8871"/>
<seriesInfo name="DOI" value="10.17487/RFC8871"/>
</reference>
<!-- draft-ietf-tls-dtls13 (AD Eval/Revised I-D needed) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.draft-ietf-tls-dtls13-39.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4086.xml"/>
</references>
</references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thank you to <contact fullname="Russ Housley"/>, who provided a detaile
d
review and significant help with crafting text for this document. Thanks
to <contact fullname="David Benham"/>, <contact fullname="Yi Cheng"/>,
<contact fullname="Lakshminath Dondeti"/>, <contact fullname="Kai
Fischer"/>, <contact fullname="Nermeen Ismail"/>, <contact
fullname="Paul Jones"/>, <contact fullname="Eddy Lem"/>, <contact
fullname="Jonathan Lennox"/>, <contact fullname="Michael Peck"/>,
<contact fullname="Rob Raymond"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Magnus Westerlund"/>, and <contact fullname="Felix
Wyss"/> for fruitful discussions, comments, and contributions to this
document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 174 change blocks. 
828 lines changed or deleted 931 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/