rfc8871xml2.original.xml   rfc8871.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
or - mmark.nl" --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> submissionType="IETF" category="std" xml:lang="en" consensus="true"
<rfc ipr="trust200902" submissionType="IETF" category="std" xml:lang="en" consen docName="draft-ietf-perc-private-media-framework-12" number="8871" obsolete
sus="yes" docName="draft-ietf-perc-private-media-framework-12"> s="" updates="" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"? <!-- xml2rfc v2v3 conversion 2.46.0 -->
><?rfc subcompact="no"?><?rfc comments="no"?> <front>
<front> <title abbrev="Private Media Framework">A Solution Framework for Private Med
<title abbrev="Private Media Framework">A Solution Framework for Private Media i ia in Privacy-Enhanced RTP Conferencing (PERC)</title>
n Privacy Enhanced RTP Conferencing (PERC)</title><author initials="P." surname=
"Jones" fullname="Paul E. Jones"><organization>Cisco</organization><address><pos
tal><street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<code>27709</code>
<country>USA</country>
<region>North Carolina</region>
</postal><phone>+1 919 476 2048</phone>
<email>paulej@packetizer.com</email>
</address></author>
<author initials="D." surname="Benham" fullname="David Benham"><organization>Ind
ependent</organization><address><postal><street></street>
</postal><email>dabenham@gmail.com</email>
</address></author>
<author initials="C." surname="Groves" fullname="Christian Groves"><organization
>Independent</organization><address><postal><street></street>
<city>Melbourne</city>
<country>Australia</country>
</postal><email>cngroves.std@gmail.com</email>
</address></author>
<date/>
<area>Internet</area><workgroup></workgroup><keyword>PERC</keyword>
<keyword>Private Media Framework</keyword>
<keyword>conferencing</keyword>
<abstract><t>This document describes a solution framework for ensuring that medi <seriesInfo name="RFC" value="8871"/>
a <author initials="P." surname="Jones" fullname="Paul E. Jones">
confidentiality and integrity are maintained end-to-end within the <organization>Cisco</organization>
context of a switched conferencing environment where media <address>
distributors are not trusted with the end-to-end media <postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<region>North Carolina</region>
<code>27709</code>
<country>United States of America</country>
</postal>
<phone>+1 919 476 2048</phone>
<email>paulej@packetizer.com</email>
</address>
</author>
<author initials="D." surname="Benham" fullname="David Benham">
<organization>Independent</organization>
<address>
<postal>
<region>California</region>
<country>United States of America</country>
</postal>
<email>dabenham@gmail.com</email>
</address>
</author>
<author initials="C." surname="Groves" fullname="Christian Groves">
<organization>Independent</organization>
<address>
<postal>
<street/>
<city>Melbourne</city>
<country>Australia</country>
</postal>
<email>cngroves.std@gmail.com</email>
</address>
</author>
<date month="January" year="2021"/>
<keyword>PERC</keyword>
<keyword>Private Media Framework</keyword>
<keyword>conferencing</keyword>
<abstract>
<t>This document describes a solution framework for ensuring that media
confidentiality and integrity are maintained end to end within the
context of a switched conferencing environment where Media
Distributors are not trusted with the end-to-end media
encryption keys. The solution builds upon existing security encryption keys. The solution builds upon existing security
mechanisms defined for the real-time transport protocol (RTP).</t> mechanisms defined for the Real-time Transport Protocol (RTP).</t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>Switched conferencing is an increasingly popular model for multimedia
<section anchor="introduction" title="Introduction">
<t>Switched conferencing is an increasingly popular model for multimedia
conferences with multiple participants using a combination of audio, conferences with multiple participants using a combination of audio,
video, text, and other media types. With this model, real-time media video, text, and other media types. With this model, real-time media
flows from conference participants are not mixed, transcoded, flows from conference participants are not mixed, transcoded,
transrated, recomposed, or otherwise manipulated by a Media translated, recomposed, or otherwise manipulated by a Media
Distributor, as might be the case with a traditional media server or Distributor, as might be the case with a traditional media server or
multipoint control unit (MCU). Instead, media flows transmitted by Multipoint Control Unit (MCU). Instead, media flows transmitted by
conference participants are simply forwarded by Media Distributors conference participants are simply forwarded by Media Distributors
to each of the other participants. Media Distributors often forward only a subs et of to each of the other participants. Media Distributors often forward only a subs et of
flows based on voice activity detection or other criteria. In some flows based on voice activity detection or other criteria. In some
instances, Media Distributors may make limited modifications to instances, Media Distributors may make limited modifications to
RTP <xref target="RFC3550"></xref> headers, for example, but the actual media co ntent RTP headers <xref target="RFC3550" format="default"/>, for example, but the actu al media content
(e.g., voice or video data) is unaltered.</t> (e.g., voice or video data) is unaltered.</t>
<t>An advantage of switched conferencing is that Media Distributors can <t>An advantage of switched conferencing is that Media Distributors can
be more easily deployed on general-purpose computing hardware, be more easily deployed on general-purpose computing hardware,
including virtualized environments in private and public clouds. including virtualized environments in private and public clouds.
Virtualized public cloud environments have been viewed as less Virtualized public cloud environments have been viewed as less
secure since resources are not always physically controlled by secure, since resources are not always physically controlled by
those who use them. This document defines improved security so as to those who use them. This document defines improved security so as to
lower the barrier to taking advantage of those environments.</t> lower the barrier to taking advantage of those environments.</t>
<t>This document defines a solution framework wherein media privacy is <t>This document defines a solution framework wherein media privacy is
ensured by making it impossible for a Media Distributor to ensured by making it impossible for a Media Distributor to
gain access to keys needed to decrypt or authenticate the actual media gain access to keys needed to decrypt or authenticate the actual media
content sent between conference participants. At the same time, the content sent between conference participants. At the same time, the
framework allows for the Media Distributors to modify certain RTP framework allows for the Media Distributors to modify certain RTP
headers; add, remove, encrypt, or decrypt RTP header extensions; and headers; add, remove, encrypt, or decrypt RTP header extensions; and
encrypt and decrypt RTP Control Protocol (RTCP) <xref target="RFC3550"></xref> p ackets. encrypt and decrypt RTP Control Protocol (RTCP) packets <xref target="RFC3550" f ormat="default"/>.
The framework also prevents replay The framework also prevents replay
attacks by authenticating each packet transmitted between a given attacks by authenticating each packet transmitted between a given
participant and the Media Distributor using a unique key per participant and the Media Distributor using a unique key per
Endpoint that is independent from the key for media encryption and endpoint that is independent from the key for media encryption and
authentication.</t> authentication.</t>
<t>This solution framework provides for enhanced privacy <t>This solution framework provides for enhanced privacy
in RTP-based conferencing environments while utilizing existing in RTP-based conferencing environments while utilizing existing
security procedures defined for RTP with minimal enhancements.</t> security procedures defined for RTP with minimal enhancements.</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;, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
&quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMME "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
NDED&quot;, "<bcp14>SHOULD NOT</bcp14>",
&quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this d "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ocument "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xre are to be interpreted as described in BCP&nbsp;14
f target="RFC8174"></xref> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, and only when, they appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<t>Additionally, this solution framework uses the following <t>Additionally, this solution framework uses the following
terms and acronyms:</t> terms and abbreviations:</t>
<t>End-to-End (E2E): Communications from one Endpoint through one or more <dl newline="false" spacing="normal">
Media Distributors to the Endpoint at the other end.</t> <dt>End-to-End (E2E):</dt><dd>Communications from one endpoint through one
<t>Hop-by-Hop (HBH): Communications between an Endpoint and a Media or more
Distributor or between Media Distributors.</t> Media Distributors to the endpoint at the other end.</dd>
<t>Trusted Endpoint (or simply Endpoint): An RTP flow terminating entity that ha <dt>Hop-by-Hop (HBH):</dt><dd>Communications between an endpoint and a Med
s possession ia
Distributor or between Media Distributors.</dd>
<dt>Trusted Endpoint (or simply endpoint):</dt><dd>An RTP flow-terminating
entity that has possession
of E2E media encryption keys and terminates E2E encryption. This may of E2E media encryption keys and terminates E2E encryption. This may
include embedded user conferencing equipment or browsers on computers, include embedded user conferencing equipment or browsers on computers,
media gateways, MCUs, media recording devices and more that are in the media gateways, MCUs, media recording devices, and more, that are in the
trusted domain for a given deployment. In the context of WebRTC trusted domain for a given deployment. In the context of WebRTC
<xref target="W3C.CR-webrtc-20180927"></xref>, where <xref target="W3C.CR-webrtc" format="default"/>, where
control of a session is divided between a JavaScript application and a control of a session is divided between a JavaScript application and a
browser, the browser acts as the Trusted Endpoint for purposes of this browser, the browser acts as the Trusted Endpoint for purposes of this
framework (just as it acts as the endpoint for DTLS-SRTP <xref target="RFC5764"> framework (just as it acts as the endpoint for DTLS-SRTP <xref target="RFC5764"
</xref> in format="default"/> in
one-to-one calls).</t> one-to-one calls).</dd>
<t>Media Distributor (MD): An RTP middlebox that forwards Endpoint media <dt>Media Distributor (MD):</dt><dd>An RTP middlebox that forwards endpoin
content (e.g., voice or video data) unaltered, either a subset or all t media
of the flows at any given time, and is never allowed to have access content (e.g., voice or video data) unaltered -- either a subset or all
of the flows at any given time -- and is never allowed to have access
to E2E encryption keys. It operates according to the to E2E encryption keys. It operates according to the
Selective Forwarding Middlebox RTP topologies <xref target="RFC7667"></xref> per Selective Forwarding Middlebox RTP topologies <xref target="RFC7667" format="def
the ault"/> per the
constraints defined by the PERC system, which includes, but is not limited constraints defined by the Private Media in Privacy-Enhanced RTP
Conferencing (PERC) system, which includes, but is not limited
to, having no access to RTP media plaintext and having limits on what to, having no access to RTP media plaintext and having limits on what
RTP header field it can alter. The header fields that may be RTP header fields it can alter. The header fields that may be
modified by a Media Distributor are enumerated in Section 4 of the Double modified by a Media Distributor are enumerated in <xref target="RFC8723"
cryptographic transform specification <xref target="I-D.ietf-perc-double"></xref sectionFormat="of" section="4">the double cryptographic transform
> and chosen specification</xref> and chosen
with respect to utility and the security considerations outlined in this with respect to utility and the security considerations outlined in this
document.</t> document.</dd>
<t>Key Distributor: An entity that is a logical function which <dt>Key Distributor:</dt><dd>An entity that is a logical function that
distributes keying material and related information to Trusted distributes keying material and related information to Trusted
Endpoints and Media Distributor(s), only that which is appropriate for Endpoints and Media Distributor(s) -- only what is appropriate for
each. The Key Distributor might be co-resident with another entity each. The Key Distributor might be co-resident with another entity
trusted with E2E keying material.</t> trusted with E2E keying material.</dd>
<t>Conference: Two or more participants communicating via Trusted <dt>Conference:</dt><dd>Two or more participants communicating via Trusted
Endpoints to exchange RTP flows through one or more Media Distributor.</t> Endpoints to exchange RTP flows through one or more Media Distributors.</dd>
<t>Call Processing: All Trusted Endpoints in the conference connect to it <dt>Call Processing:</dt><dd>All Trusted Endpoints connect to a
by a call processing dialog, such as with the Focus defined in the conference via a call processing dialog, e.g., with the "focus" as defined in
Framework for Conferencing with SIP <xref target="RFC4353"></xref>.</t> <xref target="RFC4353" format="default">"A Framework for Conferencing with the
<t>Third Party: Any entity that is not an Endpoint, Media Distributor, Session Initiation Protocol (SIP)"</xref>.</dd>
Key Distributor or Call Processing entity as described in this <dt>Third Party:</dt><dd>Any entity that is not an endpoint, Media Distrib
document.</t> utor,
</section> Key Distributor, or call processing entity as described in this
document.</dd>
<section anchor="perc-entities-and-trust-model" title="PERC Entities and Trust M </dl>
odel"> </section>
<t>The following figure depicts the trust relationships, direct or <section anchor="perc-entities-and-trust-model" numbered="true" toc="default
indirect, between entities described in the subsequent sub-sections. ">
<name>PERC Entities and Trust Model</name>
<t><xref target="fig-trust-model"/> depicts the trust relationships, direc
t or
indirect, between entities described in the subsequent subsections.
Note that these entities may be co-located or further divided into Note that these entities may be co-located or further divided into
multiple, separate physical devices.</t> multiple, separate physical devices.</t>
<t>Please note that some entities classified as untrusted in the simple, <t>Please note that some entities classified as untrusted in the simple,
general deployment scenario used most commonly in this document might general deployment scenario used most commonly in this document might
be considered trusted in other deployments. This document does not be considered trusted in other deployments. This document does not
preclude such scenarios, but keeps the definitions and examples preclude such scenarios, but it keeps the definitions and examples
focused by only using the simple, most general deployment focused by only using the simple, most general deployment
scenario.</t> scenario.</t>
<figure anchor="fig-trust-model" align="center" title="Trusted and Untrusted Ent <figure anchor="fig-trust-model">
ities in PERC <name>Trusted and Untrusted Entities in PERC</name>
"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
| |
+----------+ | +-----------------+ +----------+ | +-----------------+
| Endpoint | | | Call Processing | | Endpoint | | | Call Processing |
+----------+ | +-----------------+ +----------+ | +-----------------+
| |
| |
+----------------+ | +--------------------+ +----------------+ | +--------------------+
| Key Distributor| | | Media Distributor | | Key Distributor| | | Media Distributor |
+----------------+ | +--------------------+ +----------------+ | +--------------------+
| |
Trusted | Untrusted Trusted | Untrusted
Entities | Entities Entities | Entities
| |]]></artwork>
</figure>
</artwork> <section anchor="untrusted-entities" numbered="true" toc="default">
</figure> <name>Untrusted Entities</name>
<t>The architecture described in this framework document enables
<section anchor="untrusted-entities" title="Untrusted Entities">
<t>The architecture described in this framework document enables
conferencing infrastructure to be hosted in domains, such as in a conferencing infrastructure to be hosted in domains, such as in a
cloud conferencing provider's facilities, where the trustworthiness is cloud conferencing provider's facilities, where the trustworthiness is
below the level needed to assume the privacy of participant's media below the level needed to assume that the privacy of the participant's media
is not compromised. The conferencing infrastructure in such a is not compromised. The conferencing infrastructure in such a
domain is still trusted with reliably connecting the participants domain is still trusted with reliably connecting the participants
together in a conference, but not trusted with keying material needed together in a conference but is not trusted with keying material needed
to decrypt any of the participant's media. Entities in such lower to decrypt any of the participant's media. Entities in such
trustworthiness domains are referred to as untrusted less-trustworthy domains are referred to as untrusted
entities from this point forward.</t> entities from this point forward.</t>
<t>It is important to understand that untrusted in this document does not <t>It is important to understand that "untrusted" in this document does
mean an entity is not expected to function properly. Rather, it means not
mean that an entity is not expected to function properly. Rather, it means
only that the entity does not have access to the E2E media encryption only that the entity does not have access to the E2E media encryption
keys.</t> keys.</t>
<section anchor="media-distributor" numbered="true" toc="default">
<section anchor="media-distributor" title="Media Distributor"> <name>Media Distributor</name>
<t>A Media Distributor forwards RTP flows between Endpoints in the <t>A Media Distributor forwards RTP flows between endpoints in the
conference while performing per-hop authentication of each RTP packet. conference while performing per-hop authentication of each RTP packet.
The Media Distributor may need access to one or more RTP headers or The Media Distributor may need access to one or more RTP headers or
header extensions, potentially adding or modifying a certain subset. header extensions, potentially adding or modifying a certain subset.
The Media Distributor also relays secured messaging between the The Media Distributor also relays secured messaging between the
Endpoints and the Key Distributor and acquires per-hop key endpoints and the Key Distributor and acquires per-hop key
information from the Key Distributor. The actual media content information from the Key Distributor. The actual media content
must not be decryptable by a Media Distributor, as it is untrusted to must not be decryptable by a Media Distributor, as it is not trusted to
have access to the E2E media encryption keys. The key exchange have access to the E2E media encryption keys. The key exchange
mechanisms specified in this framework prevent the Media Distributor mechanisms specified in this framework prevent the Media Distributor
from gaining access to the E2E media encryption keys.</t> from gaining access to the E2E media encryption keys.</t>
<t>An Endpoint's ability to connect to a conference serviced by a Media <t>An endpoint's ability to connect to a conference serviced by a Medi
Distributor does imply that the Endpoint is authorized to a
have access to the E2E media encryption keys, as the Media Distributor Distributor implies that the endpoint is authorized to
does not have the ability to determine whether an Endpoint is have access to the E2E media encryption keys, although the Media Distributor
does not have the ability to determine whether an endpoint is
authorized. Instead, the Key Distributor is responsible for authorized. Instead, the Key Distributor is responsible for
authenticating the Endpoint (e.g., using WebRTC Identity authenticating the endpoint (e.g., using WebRTC identity assertions
<xref target="I-D.ietf-rtcweb-security-arch"></xref>) and determining its <xref target="RFC8827" format="default"/>) and determining its
authorization to receive E2E and HBH media encryption keys.</t> authorization to receive E2E and HBH media encryption keys.
<t>A Media Distributor must perform its role in properly forwarding </t>
<t>A Media Distributor must perform its role in properly forwarding
media packets while taking measures to mitigate the adverse effects of media packets while taking measures to mitigate the adverse effects of
denial of service attacks (refer to <xref target="attacks"></xref>) to a level e qual denial-of-service attacks (refer to <xref target="attacks" format="default"/>) t o a level equal
to or better than traditional conferencing (non-PERC) to or better than traditional conferencing (non-PERC)
deployments.</t> deployments.</t>
<t>A Media Distributor or associated conferencing infrastructure may also <t>A Media Distributor or associated conferencing infrastructure may a
initiate or terminate various conference control related messaging, lso
which is outside the scope of this framework document.</t> initiate or terminate various messaging techniques related to conference
</section> control. This topic is outside the scope of this framework document.</t>
</section>
<section anchor="call-processing" title="Call Processing"> <section anchor="call-processing" numbered="true" toc="default">
<t>The call processing function is untrusted in the simple, general <name>Call Processing</name>
deployment scenario. When a physical subset of the call processing <t>Call processing is untrusted in the simple, general
function resides in facilities outside the trusted domain, it should deployment scenario. When a physical subset of call processing
resides in facilities outside the trusted domain, it should
not be trusted to have access to E2E key information.</t> not be trusted to have access to E2E key information.</t>
<t>The call processing function may include the processing of call <t>Call processing may include the processing of call
signaling messages, as well as the signing of those messages. It may signaling messages, as well as the signing of those messages. It may
also authenticate the Endpoints for the purpose of call signaling and also authenticate the endpoints for the purpose of call signaling and of
subsequently joining of a conference hosted through one or more Media subsequently joining a conference hosted through one or more Media
Distributors. Call processing may optionally ensure the privacy of Distributors. Call processing may optionally ensure the privacy of
call signaling messages between itself, the Endpoint, and other call signaling messages between itself (call processing), the endpoint, and othe r
entities.</t> entities.</t>
</section> </section>
</section> </section>
<section anchor="trusted-entities" numbered="true" toc="default">
<section anchor="trusted-entities" title="Trusted Entities"> <name>Trusted Entities</name>
<t>From the PERC model system perspective, entities considered trusted <t>From the PERC model system's perspective, entities considered trusted
(refer to <xref target="fig-trust-model"></xref>) can be in possession of the E2 (refer to <xref target="fig-trust-model" format="default"/>) can be in possessio
E media n of the E2E media
encryption keys for one or more conferences.</t> encryption keys for one or more conferences.</t>
<section anchor="endpoint" numbered="true" toc="default">
<section anchor="endpoint" title="Endpoint"> <name>Endpoint</name>
<t>An Endpoint is considered trusted and has access to E2E key <t>An endpoint is considered trusted and has access to E2E key
information. While it is possible for an Endpoint to be compromised, information. While it is possible for an endpoint to be compromised,
subsequently performing in undesired ways, defining Endpoint subsequently performing in undesired ways, defining endpoint
resistance to compromise is outside the scope of this document. resistance to compromise is outside the scope of this document.
Endpoints take measures to mitigate the adverse effects of denial Endpoints take measures to mitigate the adverse effects of denial-of-service att
of service attacks (refer to <xref target="attacks"></xref>) from other entities acks (refer to <xref target="attacks" format="default"/>) from other entities,
, including from other endpoints, to a level equal to or better than
including from other Endpoints, to a level equal to or better than
traditional conference (non-PERC) deployments.</t> traditional conference (non-PERC) deployments.</t>
</section> </section>
<section anchor="key_distributor" numbered="true" toc="default">
<section anchor="key_distributor" title="Key Distributor"> <name>Key Distributor</name>
<t>The Key Distributor, which may be colocated with an Endpoint or exist <t>The Key Distributor, which may be co-located with an endpoint or ex
standalone, is responsible for providing key information to Endpoints ist
for both end-to-end (E2E) and hop-by-hop (HBH) security and for providing key standalone, is responsible for providing key information to endpoints
information to Media Distributors for the hop-by-hop security.</t> for both E2E and HBH security and for providing key
<t>Interaction between the Key Distributor and the call processing information to Media Distributors for HBH security.</t>
function is necessary for proper conference-to-Endpoint <t>Interaction between the Key Distributor and call processing
mappings. This is described in <xref target="conf-id"></xref>.</t> is necessary for proper conference-to-endpoint
<t>The Key Distributor needs to be secured and managed in a way to mappings. This is described in <xref target="conf-id" format="default"/>.</t>
prevent exploitation by an adversary, as any kind of compromise of the <t>The Key Distributor needs to be secured and managed in a way that
prevents exploitation by an adversary, as any kind of compromise of the
Key Distributor puts the security of the conference at risk.</t> Key Distributor puts the security of the conference at risk.</t>
<t>They Key Distributor needs to know which Endpoints and which Media <t>The Key Distributor needs to know which endpoints and which Media
Distributors are authorized to participate in the conference. How the Distributors are authorized to participate in the conference. How the
Key Distributor obtains this information is outside the scope of this Key Distributor obtains this information is outside the scope of this
document. However, Key Distributors MUST reject DTLS associations document. However, Key Distributors <bcp14>MUST</bcp14> reject DTLS association
with any unauthorized Endpoint or Media Distributor.</t> s
</section> with any unauthorized endpoint or Media Distributor.</t>
</section> </section>
</section> </section>
</section>
<section anchor="framework-for-perc" title="Framework for PERC"> <section anchor="framework-for-perc" numbered="true" toc="default">
<t>The purpose for this framework is to define a means through which <name>Framework for PERC</name>
<t>The purpose of this framework is to define a means through which
media privacy is ensured when communicating within a conferencing media privacy is ensured when communicating within a conferencing
environment consisting of one or more Media Distributors that only environment consisting of one or more Media Distributors that only
switch, hence not terminate, media. It does not otherwise attempt to switch, and hence do not terminate, media. It does not otherwise attempt to
hide the fact that a conference between Endpoints is taking place.</t> hide the fact that a conference between endpoints is taking place.</t>
<t>This framework reuses several specified RTP security technologies, <t>This framework reuses several specified RTP security technologies,
including Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"></xr including the Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"
ef>, format="default"/>,
Encrypted Key Transport (EKT) <xref target="I-D.ietf-perc-srtp-ekt-diet"></xref> Encrypted Key Transport (EKT) <xref target="RFC8870" format="default"/>,
,
and DTLS-SRTP.</t> and DTLS-SRTP.</t>
<section anchor="end-to-end-and-hop-by-hop-authenticated-encryption" numbe
<section anchor="end-to-end-and-hop-by-hop-authenticated-encryption" title="End- red="true" toc="default">
to-End and Hop-by-Hop Authenticated Encryption"> <name>E2E-Authenticated and HBH-Authenticated Encryption</name>
<t>This solution framework focuses on the end-to-end privacy and <t>This solution framework focuses on the E2E privacy and
integrity of the participant's media by limiting access to only trusted integrity of the participant's media by limiting access to only trusted
entities to the E2E key used for authenticated end-to-end encryption. entities to the E2E key used for authenticated E2E encryption.
However, this framework does give a Media Distributor access to RTP headers However, this framework does give a Media Distributor access to RTP header
fields and header extensions, as well as the ability to modify a certain fields and header extensions, as well as the ability to modify a certain
subset of the header fields and to add or change header extensions. Packets subset of the header fields and to add or change header extensions. Packets
received by a Media Distributor or an Endpoint are authenticated received by a Media Distributor or an endpoint are authenticated
hop-by-hop.</t> hop by hop.</t>
<t>To enable all of the above, this framework defines the use of two <t>To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys: an &quot;inner&quot; key security contexts and two associated encryption keys: an "inner" key
(an E2E key distinct for each transmitted media flow) for authenticated (a distinct E2E key for each transmitted media flow) for authenticated
encryption of RTP media between Endpoints and an &quot;outer&quot; key (HBH key) encryption of RTP media between endpoints and an "outer" key (a HBH key)
known only to Media Distributor or the adjacent Endpoint known only to a Media Distributor or the adjacent endpoint
for the hop between an Endpoint and a Media Distributor or peer Endpoint. for the hop between an endpoint and a Media Distributor or peer endpoint.
An Endpoint will receive one or more E2E keys from An endpoint will receive one or more E2E keys from
every other Endpoint in the conference that correspond to the media flows every other endpoint in the conference that correspond to the media flows
transmitted by those other Endpoints, while HBH keys are derived from transmitted by those other endpoints, while HBH keys are derived from
the DTLS-SRTP association with the Key Distributor. Two communicating the DTLS-SRTP association with the Key Distributor. Two communicating
Media Distributors use DTLS-SRTP associations directly with each other to Media Distributors use DTLS-SRTP associations directly with each other to
obtain the HBH keys they will use. See <xref target="key_exchange"></xref> for more details obtain the HBH keys they will use. See <xref target="key_exchange" format="defa ult"/> for more details
on key exchange.</t> on key exchange.</t>
<figure anchor="fig-e2e-and-hbh-keys-used" align="center" title="E2E and HBH Key <figure anchor="fig-e2e-and-hbh-keys-used">
s Used for Authenticated Encryption of SRTP <name>E2E and HBH Keys Used for Authenticated Encryption of SRTP Packe
Packets ts</name>
"> <artwork align="center" name="" type="" alt=""><![CDATA[+-------------
<artwork align="center">+-------------+ +-------- + +-------------+
-----+
| |################################| | | |################################| |
| Media |------------------------ *-----&gt;| Media | | Media |------------------------ *----->| Media |
| Distributor |&lt;----------------------*-|------| Distributor | | Distributor |<----------------------*-|------| Distributor |
| X |#####################*#|#|######| Y | | X |#####################*#|#|######| Y |
| | | | | | | | | | | | | |
+-------------+ | | | +-------------+ +-------------+ | | | +-------------+
# ^ | # HBH Key (XY) -+ | | # ^ | # # ^ | # HBH Key (XY) -+ | | # ^ | #
# | | # E2E Key (B) ---+ | # | | # # | | # E2E Key (B) ---+ | # | | #
# | | # E2E Key (A) -----+ # | | # # | | # E2E Key (A) -----+ # | | #
# | | # # | | # # | | # # | | #
# | | # # | | # # | | # # | | #
# | | *---- HBH Key (AX) HBH Key (YB) ----* | | # # | | *---- HBH Key (AX) HBH Key (YB) ----* | | #
# | | # # | | # # | | # # | | #
# *--------- E2E Key (A) E2E Key (A) ---------* # # *--------- E2E Key (A) E2E Key (A) ---------* #
# | *------- E2E Key (B) E2E Key (B) -------* | # # | *------- E2E Key (B) E2E Key (B) -------* | #
# | | # # | | # # | | # # | | #
# | v # # | v # # | v # # | v #
+-------------+ +-------------+ +-------------+ +-------------+
| Endpoint A | | Endpoint B | | Endpoint A | | Endpoint B |
+-------------+ +-------------+ +-------------+ +-------------+]]></artwork>
</artwork> </figure>
</figure> <t>The double transform <xref target="RFC8723" format="default"/> enable
<t>The Double transform <xref target="I-D.ietf-perc-double"></xref> enables Endp s endpoints
oints to perform encryption using both the E2E and HBH contexts while
to perform encryption using both the end-to-end and hop-by-hop contexts while
still preserving the same overall interface as other SRTP still preserving the same overall interface as other SRTP
transforms. The Media Distributor simply uses the corresponding transforms. The Media Distributor simply uses the corresponding
normal (single) AES-GCM transform, keyed with the appropriate HBH normal (single) AES-GCM transform, keyed with the appropriate HBH
keys. See <xref target="keyinventory"></xref> for a description of the keys use keys. See <xref target="keyinventory" format="default"/> for a description of t
d in PERC he keys used in PERC
and <xref target="packetformat"></xref> for diagram of how encrypted RTP packets and <xref target="packetformat" format="default"/> for a diagram of how encrypte
appear on the d RTP packets appear on the
wire.</t> wire.</t>
<t>RTCP is only encrypted hop-by-hop, not end-to-end. This framework <t>RTCP is only encrypted hop by hop -- not end to end. This framework
introduces no additional step for RTCP authenticated encryption, so does not provide an additional step for RTCP-authenticated
the procedures needed are specified in <xref target="RFC3711"></xref> and use th encryption. Rather, implementations utilize the existing procedures
e same specified in <xref target="RFC3711" format="default"/>; those procedures use
outer, hop-by-hop cryptographic context chosen in the Double operation the same outer, HBH cryptographic context chosen in the double transform operati
described above. For this reason, Endpoints MUST NOT send on
described above. For this reason, endpoints <bcp14>MUST NOT</bcp14> send
confidential information via RTCP.</t> confidential information via RTCP.</t>
</section> </section>
<section anchor="e2e-key-confidentiality" numbered="true" toc="default">
<section anchor="e2e-key-confidentiality" title="E2E Key Confidentiality"> <name>E2E Key Confidentiality</name>
<t>To ensure the confidentiality of E2E keys shared between Endpoints, <t>To ensure the confidentiality of E2E keys shared between endpoints,
Endpoints use a common Key Encryption Key (KEK) that is endpoints use a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference. That KEK, defined known only by the trusted entities in a conference. That KEK, defined
in the EKT specification <xref target="I-D.ietf-perc-srtp-ekt-diet"></xref> as t in the EKT specification <xref target="RFC8870" format="default"/> as the EKT Ke
he EKT Key, is y, is
used to subsequently encrypt the SRTP master key used for E2E used to subsequently encrypt the SRTP master key used for E2E-authenticated encr
authenticated encryption of media sent by a given Endpoint. yption of media sent by a given endpoint.
Each Endpoint in the conference creates an SRTP master Each endpoint in the conference creates an SRTP master
key for E2E authenticated encryption and key for E2E-authenticated encryption and
keep track of the E2E keys received via the Full EKT Tag for keeps track of the E2E keys received via the Full EKT Tag for
each distinct synchronization source (SSRC) in the conference so that it each distinct synchronization source (SSRC) in the conference so that it
can properly decrypt received media. An Endpoint may change its E2E key at any can properly decrypt received media. An endpoint may change its E2E key at any
time and advertise that new key to the conference as specified in time and advertise that new key to the conference as specified in
<xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>.</t> <xref target="RFC8870" format="default"/>.</t>
</section> </section>
<section anchor="e2e_keys_ops" numbered="true" toc="default">
<section anchor="e2e_keys_ops" title="E2E Keys and Endpoint Operations"> <name>E2E Keys and Endpoint Operations</name>
<t>Any given RTP media flow is identified by its SSRC, and an Endpoint <t>Any given RTP media flow is identified by its SSRC, and an endpoint
might send more than one at a time and change the mix of media flows might send more than one at a time and change the mix of media flows
transmitted during the life of a conference.</t> transmitted during the lifetime of a conference.</t>
<t>Thus, an Endpoint MUST maintain a list of SSRCs from received RTP <t>Thus, an endpoint <bcp14>MUST</bcp14> maintain a list of SSRCs from r
flows and each SSRC's associated E2E key information. An Endpoint MUST eceived RTP
discard old E2E keys no later than when it leaves the conference flows and each SSRC's associated E2E key information. An endpoint <bcp14>MUST</
(see <xref target="keyexchange"></xref>).</t> bcp14>
<t>If the packet is to contain RTP header extensions, it should be noted discard old E2E keys no later than when it leaves the conference.</t>
that those are only encrypted HBH per <xref target="I-D.ietf-perc-double"></xref <t>If the packet is to contain RTP header extensions, it should be noted
>. For that those extensions are only encrypted hop by hop per <xref target="RFC8723" f
this reason, Endpoints MUST NOT transmit confidential information ormat="default"/>. For
this reason, endpoints <bcp14>MUST NOT</bcp14> transmit confidential information
via RTP header extensions.</t> via RTP header extensions.</t>
</section> </section>
<section anchor="hbh-keys-and-per-hop-operations" numbered="true" toc="def
<section anchor="hbh-keys-and-per-hop-operations" title="HBH Keys and Per-hop Op ault">
erations"> <name>HBH Keys and Per-Hop Operations</name>
<t>To ensure the integrity of transmitted media packets, it is <t>To ensure the integrity of transmitted media packets, it is
REQUIRED that every packet be authenticated hop-by-hop between <bcp14>REQUIRED</bcp14> that every packet be authenticated hop by hop between
an Endpoint and a Media Distributor, as well between Media an endpoint and a Media Distributor, as well as between Media
Distributors. The authentication key used for hop-by-hop Distributors. The authentication key used for HBH
authentication is derived from an SRTP master key shared only on the authentication is derived from an SRTP master key shared only on the
respective hop. Each HBH key is distinct per hop and no two hops ever respective hop. Each HBH key is distinct per hop, and no two hops ever
use the same SRTP master key.</t> use the same SRTP master key.</t>
<t>While Endpoints also perform HBH authentication, the ability of the Endpoints <t>While endpoints also perform HBH authentication, the ability of the e
to reconstruct the original RTP header also enables the Endpoints to ndpoints
authenticate RTP packets E2E. This design yields flexibility to the Media to reconstruct the original RTP header also enables the endpoints to
authenticate RTP packets end to end. This design yields flexibility to the Medi
a
Distributor to change certain RTP header values as packets are Distributor to change certain RTP header values as packets are
forwarded. Which values the Media Distributor can change in the RTP header forwarded. Values that the Media Distributor can change in the RTP header
are defined in are defined in
<xref target="I-D.ietf-perc-double"></xref>. RTCP can only be encrypted hop-by- <xref target="RFC8723" format="default"/>. RTCP can only be encrypted hop by
hop, giving the hop, giving the Media Distributor the flexibility to (1)&nbsp;forward RTCP
Media Distributor the flexibility to forward RTCP content unchanged, content unchanged, (2)&nbsp;transmit compound RTCP packets, (3)&nbsp;initiate
transmit compound RTCP packets or to initiate RTCP packets for RTCP packets for reporting statistics, or (4)&nbsp;convey other information.
reporting statistics or conveying other information. Performing Performing HBH authentication for all RTP and RTCP packets also helps
hop-by-hop authentication for all RTP and RTCP packets also helps provide replay protection (see <xref target="attacks" format="default"/>). The
provide replay protection (see <xref target="attacks"></xref>). The use of the use of the replay
replay protection mechanism specified in <xref target="RFC3711" sectionFormat="of"
protection mechanism specified in Section 3.3.2 of <xref target="RFC3711"></xref section="3.3.2"/> is <bcp14>REQUIRED</bcp14> at each hop.</t>
> is <t>If there is a need to encrypt one or more RTP header extensions
REQUIRED at each hop.</t> hop by hop, the endpoint derives an encryption key from the HBH SRTP
<t>If there is a need to encrypt one or more RTP header extensions master key to encrypt header extensions as per <xref target="RFC6904" format="de
hop-by-hop, the Endpoint derives an encryption key from the HBH SRTP fault"/>. This
master key to encrypt header extensions as per <xref target="RFC6904"></xref>.
This
still gives the Media Distributor visibility into header extensions, still gives the Media Distributor visibility into header extensions,
such as the one used to determine audio level <xref target="RFC6464"></xref> of conference such as the one used to determine the audio level <xref target="RFC6464" format= "default"/> of conference
participants. Note that when RTP header extensions are encrypted, all participants. Note that when RTP header extensions are encrypted, all
hops need to decrypt and hops need to decrypt and
re-encrypt these encrypted header extensions. Please refer to re-encrypt these encrypted header extensions. Please refer to
Sections 5.1 through 5.3 of <xref target="I-D.ietf-perc-double"></xref> for proc Sections&nbsp;<xref target="RFC8723" section="5.1"
edures sectionFormat="bare"/>, <xref target="RFC8723" section="5.2"
sectionFormat="bare"/>, and <xref target="RFC8723" section="5.3" sectionFormat=
"bare"/> of <xref target="RFC8723"/> for procedures
to perform RTP header extension encryption and decryption.</t> to perform RTP header extension encryption and decryption.</t>
</section> </section>
<section anchor="key_exchange" numbered="true" toc="default">
<section anchor="key_exchange" title="Key Exchange"> <name>Key Exchange</name>
<t>In brief, the keys used by any given Endpoints are determined in the <t>In brief, the keys used by any given endpoints are determined as
following way:</t> follows:</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>The HBH keys that the endpoint uses to send and receive SRTP media
<t>The HBH keys that the Endpoint uses to send and receive SRTP media are derived from a DTLS handshake that the endpoint performs with
are derived from a DTLS handshake that the Endpoint performs with the Key Distributor (following normal DTLS-SRTP procedures).</li>
the Key Distributor (following normal DTLS-SRTP procedures).</t> <li>The E2E key that an endpoint uses to send SRTP media can be
<t>The E2E key that an Endpoint uses to send SRTP media can either be either set from the DTLS-SRTP association with the Key Distributor or chosen
set from the DTLS-SRTP association with the Key Distributor or chosen by the endpoint. It is then distributed to other endpoints in a
by the Endpoint. It is then distributed to other Endpoints in a
Full EKT Tag, encrypted under an EKT Key provided to the client by the Full EKT Tag, encrypted under an EKT Key provided to the client by the
Key Distributor within the DTLS channel they negotiated. Note that Key Distributor within the DTLS channel they negotiated. Note that
an Endpoint MAY create a different E2E key per media flow, where a an endpoint <bcp14>MAY</bcp14> create a different E2E key per media flow, where
media flow is identified by its SSRC value.</t> a
<t>Each E2E key that an Endpoint uses to receive SRTP media is set media flow is identified by its SSRC value.</li>
by receiving a Full EKT Tag from another Endpoint.</t> <li>Each E2E key that an endpoint uses to receive SRTP media is set
<t>The HBH keys used between two Media Distributors is derived from by receiving a Full EKT Tag from another endpoint.</li>
DTLS-SRTP procedures employed directly between them.</t> <li>The HBH keys used between two Media Distributors are derived via
</list> DTLS-SRTP procedures employed directly between them.</li>
</t> </ul>
<section anchor="initial-key-exchange-and-key-distributor" numbered="tru
<section anchor="initial-key-exchange-and-key-distributor" title="Initial Key Ex e" toc="default">
change and Key Distributor"> <name>Initial Key Exchange and Key Distributor</name>
<t>The Media Distributor maintains a tunnel with the Key Distributor <t>The Media Distributor maintains a tunnel with the Key Distributor
(e.g., using <xref target="I-D.ietf-perc-dtls-tunnel"></xref>), making it (e.g., using the tunnel protocol defined in <xref target="I-D.ietf-perc-dtls-tun
nel" format="default"/>), making it
possible for the Media Distributor to facilitate the establishment of possible for the Media Distributor to facilitate the establishment of
a secure DTLS association between each Endpoint and the Key a secure DTLS association between each endpoint and the Key
Distributor as shown the following figure. The DTLS association Distributor as shown in <xref target="fig-initial-key-exchange"/>. The DTLS ass
between Endpoints and the Key Distributor enables each Endpoint to ociation
between endpoints and the Key Distributor enables each endpoint to
generate E2E and HBH keys and receive the KEK. generate E2E and HBH keys and receive the KEK.
At the same time, the Key Distributor securely At the same time, the Key Distributor securely
provides the HBH key information to the Media Distributor. The key provides the HBH key information to the Media Distributor. The key
information summarized here may include the SRTP master key, SRTP information summarized here may include the SRTP master key, the SRTP
master salt, and the negotiated cryptographic transform.</t> master salt, and the negotiated cryptographic transform.</t>
<figure anchor="fig-initial-key-exchange" align="center" title="Exchanging Key I <figure anchor="fig-initial-key-exchange">
nformation Between Entities <name>Exchanging Key Information between Entities</name>
"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
+-----------+ +-----------+
KEK info | Key | HBH Key info to KEK info | Key | HBH Key info to
to Endpoints |Distributor| Endpoints &amp; Media Distributor to Endpoints |Distributor| Endpoints & Media Distributor
+-----------+ +-----------+
# ^ ^ # # ^ ^ #
# | | #--- Tunnel # | | #--- Tunnel
# | | # # | | #
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Endpoint | DTLS | Media | DTLS | Endpoint | | Endpoint | DTLS | Media | DTLS | Endpoint |
| KEK |<------------|Distributor|------------&gt;| KEK | | KEK |<------------|Distributor|------------&gt;| KEK |
| HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+]]></artwork>
</figure>
</artwork> <t>In addition to the secure tunnel between the Media Distributor and
</figure> the
<t>In addition to the secure tunnel between the Media Distributor and the
Key Distributor, there are two additional types of security associations Key Distributor, there are two additional types of security associations
utilized as a part of the key exchange as discussed in the following utilized as a part of the key exchange, as discussed in the following
paragraphs. One is a DTLS-SRTP association between an Endpoint and the Key paragraphs. One is a DTLS-SRTP association between an endpoint and the Key
Distributor (with packets passing through the Media Distributor) and the Distributor (with packets passing through the Media Distributor), and the
other is a DTLS-SRTP association between peer Media Distributors.</t> other is a DTLS-SRTP association between peer Media Distributors.</t>
<t>Endpoints establish a DTLS-SRTP association over the RTP session with the <t>Endpoints establish a DTLS-SRTP association over the RTP session wi th the
Media Distributor and its media ports for the purposes of key information Media Distributor and its media ports for the purposes of key information
exchange with the Key Distributor. The Media Distributor does not terminate exchange with the Key Distributor. The Media Distributor does not terminate
the DTLS signaling, but instead forwards DTLS packets received the DTLS signaling but instead forwards DTLS packets received
from an Endpoint on to the Key Distributor (and vice versa) via a from an endpoint on to the Key Distributor (and vice versa) via a
tunnel established between Media Distributor and the Key Distributor.</t> tunnel established between the Media Distributor and the Key Distributor.</t>
<t>In establishing the DTLS association between Endpoints and the <t>When establishing the DTLS association between endpoints and the
Key Distributor, the Endpoint MUST act as the DTLS client and the Key Distributor, the endpoint <bcp14>MUST</bcp14> act as the DTLS client, and th
Key Distributor MUST act as the DTLS server. The KEK e
Key Distributor <bcp14>MUST</bcp14> act as the DTLS server. The KEK
is conveyed by the Key Distributor over the DTLS is conveyed by the Key Distributor over the DTLS
association to Endpoints via procedures defined in EKT association to endpoints via procedures defined in EKT
<xref target="I-D.ietf-perc-srtp-ekt-diet"></xref> via the EKTKey message.</t> <xref target="RFC8870" format="default"/> via the EKTKey message.</t>
<t>The Key Distributor MUST NOT establish DTLS-SRTP associations with <t>The Key Distributor <bcp14>MUST NOT</bcp14> establish DTLS-SRTP ass
Endpoints without first authenticating the Media Distributor tunneling the ociations with
DTLS-SRTP packets from the Endpoint.</t> endpoints without first authenticating the Media Distributor tunneling the
<t>Note that following DTLS-SRTP procedures for the <xref target="I-D.ietf-perc- DTLS-SRTP packets from the endpoint.</t>
double"></xref> <t>Note that following DTLS-SRTP procedures for the cipher defined
cipher, the Endpoint generates both E2E and HBH encryption keys in <xref target="RFC8723" format="default"/>, the endpoint generates both E2E an
and salt values. Endpoints MUST either use the DTLS-SRTP generated E2E key d HBH encryption keys
and salt values. Endpoints <bcp14>MUST</bcp14> either use the DTLS-SRTP-generat
ed E2E key
for transmission or generate a fresh E2E key. In either case, the generated for transmission or generate a fresh E2E key. In either case, the generated
SRTP master salt for E2E encryption MUST be replaced with the salt value SRTP master salt for E2E encryption <bcp14>MUST</bcp14> be replaced with the sal t value
provided by the Key Distributor via the EKTKey message. That is because provided by the Key Distributor via the EKTKey message. That is because
every Endpoint in the conference uses the same SRTP master salt. The every endpoint in the conference uses the same SRTP master salt. The
Endpoint only transmits the SRTP master key (not the salt) used for E2E endpoint only transmits the SRTP master key (not the salt) used for E2E
encryption to other Endpoints in RTP/RTCP packets per encryption to other endpoints in RTP/RTCP packets per
<xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>.</t> <xref target="RFC8870" format="default"/>.</t>
<t>Media Distributors use DTLS-SRTP directly with a peer <t>Media Distributors use DTLS-SRTP directly with a peer
Media Distributor to establish the HBH key for transmitting RTP and RTCP Media Distributor to establish the HBH key for transmitting RTP and RTCP
packets to that peer Media Distributor. The Key Distributor does not packets to that peer Media Distributor. The Key Distributor does not
facilitate establishing a HBH key for use between Media Distributors.</t> facilitate establishing a HBH key for use between Media Distributors.</t>
</section> </section>
<section anchor="keyexchange" numbered="true" toc="default">
<section anchor="keyexchange" title="Key Exchange during a Conference"> <name>Key Exchange during a Conference</name>
<t>Following the initial key information exchange with the Key <t>Following the initial key information exchange with the Key
Distributor, an Endpoint is able to encrypt media end-to-end with Distributor, an endpoint is able to encrypt media end to end with
an E2E key, sending that E2E key to other Endpoints encrypted with the an E2E key, sending that E2E key to other endpoints encrypted with the
KEK, and is able to encrypt and authenticate RTP packets KEK, and is able to encrypt and authenticate RTP packets
using a HBH key. The procedures defined do not allow the Media using a HBH key. This framework does not allow the Media Distributor
Distributor to gain access to the KEK information, preventing it from to gain access to the KEK information, preventing it from
gaining access to any Endpoint's E2E key and subsequently decrypting gaining access to any endpoint's E2E key and subsequently decrypting
media.</t> media.</t>
<t>The KEK may need to change from time-to-time during the <t>The KEK may need to change from time to time during the
life of a conference, such as when a new participant joins or leaves a lifetime of a conference, such as when a new participant joins or leaves a
conference. Dictating if, when or how often a conference is to be conference. Dictating if, when, or how often a conference is to be
re-keyed is outside the scope of this document, but this framework rekeyed is outside the scope of this document, but this framework
does accommodate re-keying during the life of a conference.</t> does accommodate rekeying during the lifetime of a conference.</t>
<t>When a Key Distributor decides to re-key a conference, it transmits a <t>When a Key Distributor decides to rekey a conference, it transmits
a
new EKTKey message containing the new EKT Key new EKTKey message containing the new EKT Key
to each of the conference participants. to each of the conference participants.
Upon receipt of the new EKT Key, the Endpoint MUST create a Upon receipt of the new EKT Key, the endpoint <bcp14>MUST</bcp14> create a
new SRTP master key and prepare to send that key inside a Full EKT new SRTP master key and prepare to send that key inside a FullEKTField using
Field using the new EKT Key as per Section 4.5 of <xref target="I-D.ietf-perc-sr the new EKT Key as per <xref target="RFC8870" sectionFormat="of"
tp-ekt-diet"></xref>. section="4.5"/>. In order to allow time for all endpoints in the conference to r
In order to allow time for all Endpoints in the conference to receive the new eceive the new
keys, the sender should follow the recommendations in Section 4.7 of keys, the sender should follow the recommendations in <xref target="RFC8870"
[I-D.ietf-perc-srtp-ekt-diet]. On receiving a new EKT Key, Endpoints MUST sectionFormat="of" section="4.6"/>. On receiving a new EKT Key, endpoints <bcp14
be prepared to decrypt EKT tags using the new key. The EKT SPI field is >MUST</bcp14>
used to differentiate between tags encrypted with the old and new keys.</t> be prepared to decrypt EKT Tags using the new key. The EKT Security Parameter
<t>After re-keying, an Endpoint SHOULD retain prior SRTP master keys and Index (SPI) field is
EKT Key for a period of time sufficient for the purpose of ensuring it can used to differentiate between EKT Tags encrypted with the old and new keys.</t>
<t>After rekeying, an endpoint <bcp14>SHOULD</bcp14> retain prior SRTP
master keys and
EKT Keys for a period of time sufficient for the purpose of ensuring that it can
decrypt late-arriving or out-of-order packets or packets sent by other decrypt late-arriving or out-of-order packets or packets sent by other
Endpoints that used the prior keys for a period of time after re-keying began. endpoints that used the prior keys for a period of time after rekeying began.
An Endpoint MAY retain old keys until the end of the conference.</t> An endpoint <bcp14>MAY</bcp14> retain old keys until the end of the conference.<
<t>Endpoints MAY follow the procedures in section 5.2 of <xref target="RFC5764"> /t>
</xref> <t>Endpoints <bcp14>MAY</bcp14> follow the procedures in <xref target=
"RFC5764" sectionFormat="of" section="5.2"/>
to renegotiate HBH keys as desired. If new HBH keys are generated, to renegotiate HBH keys as desired. If new HBH keys are generated,
the new keys are also delivered to the Media Distributor following the new keys are also delivered to the Media Distributor following
the procedures defined in <xref target="I-D.ietf-perc-dtls-tunnel"></xref> as on the procedures defined in <xref target="I-D.ietf-perc-dtls-tunnel" format="defau
e possible method.</t> lt"/> as one possible method.</t>
<t>Endpoints MAY change the E2E encryption key used at <t>At any time, endpoints <bcp14>MAY</bcp14> change the E2E
any time. An Endpoint MUST generate a new E2E encryption key encryption key being used. An endpoint <bcp14>MUST</bcp14> generate a new E2E e
ncryption key
whenever it receives a new EKT Key. After switching to a new key, whenever it receives a new EKT Key. After switching to a new key,
the new key is conveyed to other Endpoints in the conference the new key is conveyed to other endpoints in the conference
in RTP/RTCP packets per <xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>.</t> in RTP/RTCP packets per <xref target="RFC8870" format="default"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="authentication" numbered="true" toc="default">
<section anchor="authentication" title="Authentication"> <name>Authentication</name>
<t>It is important to this solution framework that the entities can <t>It is important that entities can
validate the authenticity of other entities, especially the Key validate the authenticity of other entities, especially the Key
Distributor and Endpoints. The details of this are outside the scope Distributor and endpoints. Details on this topic are outside the scope
of specification but a few possibilities are discussed in the of this specification, but a few possibilities are discussed in the
following sections. The critical requirements are that an Endpoint can verify following sections. The critical requirements are that (1)&nbsp;an endpoint
it is connected to the correct Key Distributor for the conference can verify that it is connected to the correct Key Distributor for the
and the Key Distributor can verify the Endpoint is the correct conference and (2)&nbsp;the Key Distributor can verify that the endpoint is
Endpoint for the conference.</t> the correct endpoint for the conference.</t>
<t>Two possible approaches to solve this are Identity Assertions and <t>Two possible approaches to resolve this situation are identity assertio
Certificate Fingerprints.</t> ns and
certificate fingerprints.</t>
<section anchor="identity-assertions" title="Identity Assertions"> <section anchor="identity-assertions" numbered="true" toc="default">
<t>WebRTC Identity assertion <xref target="I-D.ietf-rtcweb-security-arch"></xref <name>Identity Assertions</name>
> is used <t>A WebRTC identity assertion <xref target="RFC8827" format="default"/>
to bind the identity of the user of the Endpoint to the fingerprint of is used
to bind the identity of the user of the endpoint to the fingerprint of
the DTLS-SRTP certificate used for the call. This certificate is the DTLS-SRTP certificate used for the call. This certificate is
unique for a given call and a conference. This allows the Key unique for a given call and a conference.
Distributor to ensure that only authorized users participate in the This certificate is unique for a given call and a conference, allowing the
conference. Similarly the Key Distributor can create a WebRTC Identity Key Distributor to ensure that only authorized users participate in the
conference. Similarly, the Key Distributor can create a WebRTC identity
assertion to bind the fingerprint of the unique certificate used by assertion to bind the fingerprint of the unique certificate used by
the Key Distributor for this conference so that the Endpoint can the Key Distributor for this conference so that the endpoint can
validate it is talking to the correct Key Distributor. Such a setup verify that it is talking to the correct Key Distributor. Such a setup
requires an Identity Provider (Idp) trusted by the Endpoints and the requires an Identity Provider (IdP) trusted by the endpoints and the
Key Distributor.</t> Key Distributor.</t>
</section> </section>
<section anchor="certificate-fingerprints-in-session-signaling" numbered="
<section anchor="certificate-fingerprints-in-session-signaling" title="Certifica true" toc="default">
te Fingerprints in Session Signaling"> <name>Certificate Fingerprints in Session Signaling</name>
<t>Entities managing session signaling are generally assumed to be <t>Entities managing session signaling are generally assumed to be
untrusted in the PERC framework. However, there are some deployment untrusted in the PERC framework. However, there are some deployment
scenarios where parts of the session signaling may be assumed scenarios where parts of the session signaling may be assumed
trustworthy for the purposes of exchanging, in a manner that can be trustworthy for the purposes of exchanging, in a manner that can be
authenticated, the fingerprint of an entity's certificate.</t> authenticated, the fingerprint of an entity's certificate.</t>
<t>As a concrete example, SIP <xref target="RFC3261"></xref> and <t>As a concrete example, SIP <xref target="RFC3261" format="default"/>
Session Description Protocol (SDP) <xref target="RFC4566"></xref> can be used and
to convey the fingerprint information per <xref target="RFC5763"></xref>. An En the Session Description Protocol (SDP) <xref target="RFC4566" format="default"/>
dpoint's can be used
to convey the fingerprint information per <xref target="RFC5763" format="default
"/>. An endpoint's
SIP User Agent would send an INVITE message containing SDP for the SIP User Agent would send an INVITE message containing SDP for the
media session along with the Endpoint's certificate fingerprint, which media session along with the endpoint's certificate fingerprint, which
can be signed using the procedures described in <xref target="RFC8224"></xref> f can be signed using the procedures described in <xref target="RFC8224" format="d
or the efault"/> for the
benefit of forwarding the message to other entities by the Focus benefit of forwarding the message to other entities by the focus
<xref target="RFC4353"></xref>. Other entities can verify the fingerprints matc <xref target="RFC4353" format="default"/>. Other entities can verify that the f
h the ingerprints match the
certificates found in the DTLS-SRTP connections to find the identity certificates found in the DTLS-SRTP connections to find the identity
of the far end of the DTLS-SRTP connection and verify that is the of the far end of the DTLS-SRTP connection and verify that it is the
authorized entity.</t> authorized entity.</t>
<t>Ultimately, if using session signaling, an Endpoint's certificate <t>Ultimately, if using session signaling, an endpoint's certificate
fingerprint would need to be securely mapped to a user and conveyed to fingerprint would need to be securely mapped to a user and conveyed to
the Key Distributor so that it can check that that user is authorized. the Key Distributor so that it can check that the user in question is authorized .
Similarly, the Key Distributor's certificate fingerprint can be Similarly, the Key Distributor's certificate fingerprint can be
conveyed to an Endpoint in a manner that can be authenticated as being an conveyed to an endpoint in a manner that can be authenticated as being an
authorized Key Distributor for this conference.</t> authorized Key Distributor for this conference.</t>
</section> </section>
<section anchor="conf-id" numbered="true" toc="default">
<section anchor="conf-id" title="Conference Identification"> <name>Conference Identification</name>
<t>The Key Distributor needs to know what Endpoints are being added to a <t>The Key Distributor needs to know what endpoints are being added to a
given conference. Thus, the Key Distributor and the Media Distributor given conference. Thus, the Key Distributor and the Media Distributor
need to know Endpoint-to-conference mappings, which is enabled by need to know endpoint-to-conference mappings, which are enabled by
exchanging a conference-specific unique identifier defined in exchanging a conference-specific unique identifier as described in
<xref target="I-D.ietf-perc-dtls-tunnel"></xref>. How this unique identifier is <xref target="I-D.ietf-perc-dtls-tunnel" format="default"/>. How this unique
assigned identifier is assigned is outside the scope of this document.</t>
is outside the scope of this document.</t> </section>
</section> </section>
</section> <section anchor="perc-keys" numbered="true" toc="default">
<name>PERC Keys</name>
<section anchor="perc-keys" title="PERC Keys"> <t>This section describes the various keys employed by PERC.</t>
<t>This section describes the various keys employed by PERC.</t> <section anchor="keyinventory" numbered="true" toc="default">
<name>Key Inventory and Management Considerations</name>
<section anchor="keyinventory" title="Key Inventory and Management Consideration <t>This section summarizes the several different keys used in the PERC f
s"> ramework,
<t>This section summarizes the several different keys used in the PERC framework
,
how they are generated, and what purpose they serve.</t> how they are generated, and what purpose they serve.</t>
<t>The keys are described in the order in which they would typically be <t>The keys are described in the order in which they would typically be
acquired.</t> acquired.</t>
<t>The various keys used in PERC are shown in <t>The various keys used in PERC are shown in
<xref target="key-inventory-table"></xref> below.</t> <xref target="key-inventory-table" format="default"/> below.</t>
<figure anchor="key-inventory-table" align="center" title="Key Inventory
"> <table anchor="key-inventory-table">
<artwork align="center">+-----------+------------------------------------------- <name>Key Inventory</name>
---------+ <thead>
| Key | Description | <tr>
+-----------+----------------------------------------------------+ <th align="center">Key</th>
| HBH Key | SRTP master key used to encrypt media hop-by-hop. | <th align="center">Description</th>
+-----------+----------------------------------------------------+ </tr>
| KEK | Key shared by all Endpoints and used to encrypt | </thead>
| (EKT Key) | each Endpoint's E2E SRTP master key so receiving | <tbody>
| | Endpoints can decrypt media. | <tr>
+-----------+----------------------------------------------------+ <td>HBH Key</td>
| E2E Key | SRTP master key used to encrypt media end-to-end. | <td>SRTP master key used to encrypt media hop by hop.</td>
+-----------+----------------------------------------------------+ </tr>
</artwork> <tr>
</figure> <td>KEK (EKT&nbsp;Key)</td>
<t>While the number of key types is very small, it should be understood that <td>Key shared by all endpoints and used to encrypt each endpoint's E2E
SRTP master key so receiving endpoints can decrypt media.</td>
</tr>
<tr>
<td>E2E Key</td>
<td>SRTP master key used to encrypt media end to end.</td>
</tr>
</tbody>
</table>
<t>While the number of key types is very small, it should be understood
that
the actual number of distinct keys can be large as the conference the actual number of distinct keys can be large as the conference
grows in size.</t> grows in size.</t>
<t>As an example, with 1,000 participants in a conference, there would be at <t>As an example, with 1,000 participants in a conference, there would b e at
least 1,000 distinct SRTP master keys, all of which share the same master salt. least 1,000 distinct SRTP master keys, all of which share the same master salt.
Each of those keys are passed through the KDF defined in <xref target="RFC3711"> </xref> to produce Each of those keys is passed through the Key Derivation Function (KDF) as define d in <xref target="RFC3711" format="default"/> to produce
the actual encryption and authentication keys.</t> the actual encryption and authentication keys.</t>
<t>Complicating key management is the fact that the KEK can change and, when <t>Complicating key management is the fact that the KEK can change and,
it does, the Endpoints generate new SRTP master keys that are associated with when
it does, the endpoints generate new SRTP master keys that are associated with
a new EKT SPI. Endpoints might retain old keys for a period of time to a new EKT SPI. Endpoints might retain old keys for a period of time to
ensure they can properly decrypt late-arriving or out-of-order packets, which ensure that they can properly decrypt late-arriving or out-of-order packets, whi
means the number of keys held during that period of time might substantially ch
more.</t> means that the number of keys held during that period of time might be
<t>A more detailed explanation of each of the keys follows.</t> substantially higher.</t>
</section> <t>A more detailed explanation of each of the keys follows.</t>
</section>
<section anchor="dtls-srtp-exchange-yields-hbh-keys" title="DTLS-SRTP Exchange Y <section anchor="dtls-srtp-exchange-yields-hbh-keys" numbered="true" toc="
ields HBH Keys"> default">
<t>The first set of keys acquired are for hop-by-hop encryption and <name>DTLS-SRTP Exchange Yields HBH Keys</name>
decryption. Per the Double <xref target="I-D.ietf-perc-double"></xref> procedur <t>The first set of keys acquired are for HBH encryption and
es, the decryption. Per the double transform procedures <xref target="RFC8723" format="
Endpoint performs DTLS-SRTP exchange with the Key Distributor default"/>, the
and receives a key that is, in fact, &quot;double&quot; the size that is needed. endpoint performs a DTLS-SRTP exchange with the Key Distributor
The end-to-end part is the first half of the key, so the Endpoint discards and receives a key that is, in fact, "double" the size that is needed.
that information when generating its own key. The second half of the key The E2E part is the first half of the key, so the endpoint discards
material is for hop-by-hop operations, so that half of the key that information when generating its own key. The second half of the keying
material is for HBH operations, so that half of the key
(corresponding to the least significant bits) is assigned internally as (corresponding to the least significant bits) is assigned internally as
the HBH key.</t> the HBH key.</t>
<t>The Key Distributor informs the Media Distributor of the HBH key. Specifical ly, <t>The Key Distributor informs the Media Distributor of the HBH key. Sp ecifically,
the Key Distributor sends the least significant bits corresponding to the the Key Distributor sends the least significant bits corresponding to the
half of the keying material determined through DTLS-SRTP with the Endpoint half of the keying material determined through DTLS-SRTP with the endpoint
to the Media Distributor. A salt value is to the Media Distributor. A salt value is
generated along with the HBH key. The salt is also longer than needed generated along with the HBH key. The salt is also longer than needed
for hop-by-hop operations, thus only the least significant bits of the for HBH operations; thus, only the least significant bits of the
required length (half of the generated salt material) are sent to the required length (half of the generated salt material) are sent to the
Media Distributor. One way to transmit this key and salt information Media Distributor. One way to transmit this key and salt information
is via the tunnel protocol defined in <xref target="I-D.ietf-perc-dtls-tunnel">< is via the tunnel protocol defined in <xref target="I-D.ietf-perc-dtls-tunnel" f
/xref>.</t> ormat="default"/>.</t>
<t>No two Endpoints have the same HBH key, thus the Media Distributor <t>No two endpoints have the same HBH key; thus, the Media Distributor
MUST keep track each distinct HBH key (and the corresponding salt) and <bcp14>MUST</bcp14> keep track of each distinct HBH key (and the corresponding s
alt) and
use it only for the specified hop.</t> use it only for the specified hop.</t>
<t>The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is not <t>The HBH key is also used for HBH encryption of RTCP. RTCP is not
end-to-end encrypted in PERC.</t> E2E-encrypted in PERC.</t>
</section> </section>
<section anchor="the-key-distributor-transmits-the-kek-ekt-key" numbered="
<section anchor="the-key-distributor-transmits-the-kek-ekt-key" title="The Key D true" toc="default">
istributor Transmits the KEK (EKT Key)"> <name>The Key Distributor Transmits the KEK (EKT Key)</name>
<t>Via the aforementioned DTLS-SRTP association, the Key Distributor <t>The Key Distributor sends the KEK (the EKT Key per
sends the Endpoint the KEK (EKT Key per <xref target="RFC8870" format="default"/>) to the endpoint via the aforementione
<xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>). This key is known only to d DTLS-SRTP association. This key is known only to
the Key Distributor and Endpoints. This key is the most important to the Key Distributor and endpoints; it is the most important entity to
protect since having knowledge of this key (and the SRTP master salt protect, since having knowledge of this key (and the SRTP master salt
transmitted as a part of the same message) allows an entity to transmitted as a part of the same message) allows an entity to
decrypt any media packet in the conference.</t> decrypt any media packet in the conference.</t>
<t>Note that the Key Distributor can send any number of EKT Keys to <t>Note that the Key Distributor can send any number of EKT Keys to
Endpoints. This is used to re-key the entire conference. Each endpoints. This information is used to rekey the entire conference. Each
key is identified by a &quot;Security Parameter Index&quot; (SPI) value. key is identified by an SPI value.
Endpoints MUST expect that a conference might be re-keyed Endpoints <bcp14>MUST</bcp14> expect that a conference might be rekeyed
when a new participant joins a conference or when a participant when a new participant joins a conference or when a participant
leaves a conference in order to protect the confidentiality of leaves a conference, in order to protect the confidentiality of
the conversation before and after such events.</t> the conversation before and after such events.</t>
<t>The SRTP master salt to be used by the Endpoint is transmitted along <t>The SRTP master salt to be used by the endpoint is transmitted along
with the EKT Key. All Endpoints in the conference utilize with the EKT Key. All endpoints in the conference utilize
the same SRTP master salt that corresponds with a given EKT Key.</t> the same SRTP master salt that corresponds with a given EKT Key.</t>
<t>The Full EKT Tag in media packets is encrypted using a cipher specified <t>The Full EKT Tag in media packets is encrypted using a cipher specifi ed
via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This
cipher is different than the cipher used to protect media and is only cipher is different than the cipher used to protect media and is only
used to encrypt the Endpoint's SRTP master key (and other EKT Tag data used to encrypt the endpoint's SRTP master key (and other EKT Tag data
as per <xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>).</t> as per <xref target="RFC8870" format="default"/>).</t>
<t>The Media Distributor is not given the KEK.</t> <t>The KEK is not given to the Media Distributor.</t>
</section> </section>
<section anchor="endpoints-fabricate-an-srtp-master-key" numbered="true" t
<section anchor="endpoints-fabricate-an-srtp-master-key" title="Endpoints fabric oc="default">
ate an SRTP Master Key"> <name>Endpoints Fabricate an SRTP Master Key</name>
<t>As stated earlier, the E2E key determined via DTLS-SRTP MAY be <t>As stated earlier, the E2E key determined via DTLS-SRTP <bcp14>MAY</b
discarded in favor of a locally-generated E2E SRTP master key. While the cp14> be
DTLS-SRTP-derived SRTP master key can be used initially, the Endpoint might discarded in favor of a locally generated E2E SRTP master key. While the
choose to change the SRTP master key periodically and MUST change the DTLS-SRTP-derived SRTP master key can be used initially, the endpoint might
SRTP master key as a result of the EKT key changing.</t> choose to change the SRTP master key periodically and <bcp14>MUST</bcp14> change
<t>A locally-generated SRTP master key is used along with the master salt the
transmitted to the Endpoint from the Key Distributor via the EKTKey SRTP master key as a result of the EKT Key changing.</t>
message to encrypt media end-to-end.</t> <t>A locally generated SRTP master key is used along with the master sal
<t>Since the Media Distributor is not involved in E2E functions, it does not t
create this key nor have access to any Endpoint's E2E key. Note, too, transmitted to the endpoint from the Key Distributor via the EKTKey
that even the Key Distributor is unaware of the locally-generated E2E keys message to encrypt media end to end.</t>
used by each Endpoint.</t> <t>Since the Media Distributor is not involved in E2E functions, it does
<t>The Endpoint transmits its E2E key to other Endpoints in the conference not
create this key, nor does it have access to any endpoint's E2E key. Note, too,
that even the Key Distributor is unaware of the locally generated E2E keys
used by each endpoint.</t>
<t>The endpoint transmits its E2E key to other endpoints in the conferen
ce
by periodically including it in SRTP packets in a Full EKT Tag. When by periodically including it in SRTP packets in a Full EKT Tag. When
placed in the Full EKT Tag, it is encrypted using the EKT Key provided placed in the Full EKT Tag, it is encrypted using the EKT Key provided
by the Key Distributor. The master salt is not transmitted, though, by the Key Distributor. The master salt is not transmitted, though,
since all Endpoints receive the same master salt via the EKTKey since all endpoints receive the same master salt via the EKTKey
message from the Key Distributor. The recommended frequency with which an message from the Key Distributor. The recommended frequency with which an
Endpoint transmits its SRTP master key is specified in endpoint transmits its SRTP master key is specified in
<xref target="I-D.ietf-perc-srtp-ekt-diet"></xref>.</t> <xref target="RFC8870" format="default"/>.</t>
</section> </section>
<section anchor="summary-of-key-types-and-entity-possession" numbered="tru
<section anchor="summary-of-key-types-and-entity-possession" title="Summary of K e" toc="default">
ey Types and Entity Possession"> <name>Summary of Key Types and Entity Possession</name>
<t>All Endpoints have knowledge of the KEK.</t> <t>All endpoints have knowledge of the KEK.</t>
<t>Every HBH key is distinct for a given Endpoint, thus Endpoint A and <t>Every HBH key is distinct for a given endpoint; thus, Endpoint A and
Endpoint B do not have knowledge of the other's HBH key. Since HBH keys Endpoint B do not have knowledge of the other's HBH key. Since HBH keys
are derived from a DTLS-SRTP association, there is at most one HBH key are derived from a DTLS-SRTP association, there is at most one HBH key
per Endpoint, (The only exception is where the DTLS-SRTP association might per endpoint. (The only exception is where the DTLS-SRTP association might
be rekeyed per Section 5.2 of <xref target="RFC5764"></xref> and a new key is cr be rekeyed per <xref target="RFC5764" sectionFormat="of" section="5.2"/> and a n
eated to ew key is created to
replace the former key.)</t> replace the former key.)</t>
<t>Each Endpoint generates its own E2E key (SRTP master key), thus <t>Each endpoint generates its own E2E key (SRTP master key); thus,
there is a distinct E2E key per endpoint. This key is transmitted (encrypted) v ia there is a distinct E2E key per endpoint. This key is transmitted (encrypted) v ia
the Full EKT Tag to other Endpoints. Endpoints that receive media from the Full EKT Tag to other endpoints. Endpoints that receive media from
a given transmitting Endpoint gain knowledge of the a given transmitting endpoint gain knowledge of the
transmitter's E2E key via the Full EKT Tag.</t> transmitter's E2E key via the Full EKT Tag.</t>
<t>To summarize the various keys and which entity is in possession <t><xref target="who-has-what-key-table" format="default"/> summarizes
of a given key, refer to <xref target="fig-who-has-what-key"></xref>.</t> the various keys and which entity is in possession of a given key.</t>
<figure anchor="fig-who-has-what-key" align="center" title="Keys Types and Entit
y Possession
">
<artwork align="center">+----------------------+------------+-------+-------+---
---------+
| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |
+----------------------+------------+-------+-------+------------+
| KEK (EKT Key) | Yes | No | No | Yes |
+----------------------+------------+-------+-------+------------+
| E2E Key (A and B) | Yes | No | No | Yes |
+----------------------+------------+-------+-------+------------+
| HBH Key (A&lt;=&gt;MD X) | Yes | Yes | No | No |
+----------------------+------------+-------+-------+------------+
| HBH Key (B&lt;=&gt;MD Y) | No | No | Yes | Yes |
+----------------------+------------+---------------+------------+
| HBH Key (MD X&lt;=&gt;MD Y)| No | Yes | Yes | No |
+----------------------+------------+---------------+------------+
</artwork>
</figure>
</section>
</section>
<section anchor="packetformat" title="Encrypted Media Packet Format"> <table anchor="who-has-what-key-table">
<t><xref target="fig-perc-packet-format"></xref> presents a complete picture of <name>Key Types and Entity Possession</name>
what an encrypted <thead>
<tr>
<th align="center">Key/Entity</th>
<th align="center">Endpoint A</th>
<th align="center">MD X</th>
<th align="center">MD Y</th>
<th align="center">Endpoint B</th>
</tr>
</thead>
<tbody>
<tr>
<td>KEK (EKT Key)</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
</tr>
<tr>
<td>E2E Key (A and B)</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
</tr>
<tr>
<td>HBH Key (A&lt;=&gt;MD X)</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">No</td>
</tr>
<tr>
<td>HBH Key (B&lt;=&gt;MD Y)</td>
<td align="center">No</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
</tr>
<tr>
<td>HBH Key (MD X&lt;=&gt;MD Y)</td>
<td align="center">No</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">No</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="packetformat" numbered="true" toc="default">
<name>Encrypted Media Packet Format</name>
<t><xref target="fig-perc-packet-format" format="default"/> presents a com
plete picture of what an encrypted
media packet per this framework looks like when transmitted over the wire. media packet per this framework looks like when transmitted over the wire.
The packet format shown is encrypted using the Double cryptographic transform The packet format shown in the figure is encrypted using the double cryptographi c transform
with an EKT Tag appended to the end.</t> with an EKT Tag appended to the end.</t>
<figure anchor="fig-perc-packet-format" align="center" title="Encrypted Media Pa <figure anchor="fig-perc-packet-format">
cket Format <name>Encrypted Media Packet Format</name>
"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"> 0 1 2 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++
|V=2|P|X| CC |M| PT | sequence number | IO |V=2|P|X| CC |M| PT | sequence number | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| timestamp | IO | timestamp | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| synchronization source (SSRC) identifier | IO | synchronization source (SSRC) identifier | IO
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO
| contributing source (CSRC) identifiers | IO | contributing source (CSRC) identifiers | IO
| .... | IO | .... | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;+O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
| RTP extension (OPTIONAL) ... | |O | RTP extension (OPTIONAL) ... | |O
+>+&gt;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;+ O +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O I | payload ... | IO O I | payload ... | IO
O I | +-------------------------------+ IO O I | +-------------------------------+ IO
O I | | RTP padding | RTP pad count | IO O I | | RTP padding | RTP pad count | IO
O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;+O O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;+O
O | | E2E authentication tag | |O O | | E2E authentication tag | |O
O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O
O | | OHB ... | |O O | | OHB ... | |O
+&gt;| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+
| | | HBH authentication tag | || | | | HBH authentication tag | ||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| | | EKT Tag ... | R || | | | EKT Tag ... | R ||
| | +-+-+-+-+-+-+-+-+-+ | || | | +-+-+-+-+-+-+-+-+-+ | ||
| | +- Neither encrypted nor authenticated; || | | +- Neither encrypted nor authenticated; ||
| | appended after Double is performed || | | appended after the double transform ||
| | || | | is performed ||
| | || | | ||
| +- E2E Encrypted Portion E2E Authenticated Portion ---+| | +- E2E-Encrypted Portion E2E-Authenticated Portion ---+|
| | | |
+--- HBH Encrypted Portion HBH Authenticated Portion ----+ +--- HBH-Encrypted Portion HBH-Authenticated Portion ----+
I = Inner (E2E) encryption / authentication
O = Outer (HBH) encryption / authentication
</artwork>
</figure>
</section>
<section anchor="attacks" title="Security Considerations">
<section anchor="third-party-attacks" title="Third Party Attacks"> --- <span class="insert">HBH-Encrypted</span> Portion <span class=
<t>Third party attacks are attacks attempted by an adversary that is not "insert">HBH-Authenticated</span> Portion ----+
I = Inner (E2E) encryption/authentication
O = Outer (HBH) encryption/authentication]]></artwork>
</figure>
</section>
<section anchor="attacks" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="third-party-attacks" numbered="true" toc="default">
<name>Third-Party Attacks</name>
<t>Third-party attacks are attacks attempted by an adversary that is not
supposed to have access to keying material or is otherwise not an supposed to have access to keying material or is otherwise not an
authorized participant in the conference.</t> authorized participant in the conference.</t>
<t>On-path attacks are mitigated by hop-by-hop integrity protection and <t>On-path attacks are mitigated by HBH integrity protection and
encryption. The integrity protection mitigates packet modification encryption. The integrity protection mitigates packet modification.
and encryption makes selective blocking of packets harder, but not Encryption makes selective blocking of packets harder, but not
impossible.</t> impossible.</t>
<t>Off-path attackers could try connecting to different PERC entities to <t>Off-path attackers could try connecting to different PERC entities to
send specifically crafted packets with an aim of forcing the receiver to send specifically crafted packets with an aim of forcing the receiver to
forward or render bogus media packets. Endpoints and Media Distributors mitigat e forward or render bogus media packets. Endpoints and Media Distributors mitigat e
such an attack by performing hop-by-hop authentication and discarding packets such an attack by performing HBH authentication and discarding packets
that fail authentication.</t> that fail authentication.</t>
<t>Another attack vector is a third party claiming to be a Media <t>Another attack vector is a third party claiming to be a Media
Distributor, fooling Endpoints into sending packets to the false Distributor, fooling endpoints into sending packets to the false
Media Distributor instead of the correct one. The deceived sending Media Distributor instead of the correct one. The deceived sending
Endpoints could incorrectly assume their packets have been delivered endpoints could incorrectly assume that their packets have been delivered
to Endpoints when they in fact have not. While this attack is possible, to endpoints when they in fact have not. While this attack is possible,
the result is a simple denial of service with no leakage of confidential the result is a simple denial of service with no leakage of confidential
information, since the false Media Distributor would not have access information, since the false Media Distributor would not have access
to either HBH or E2E encryption keys.</t> to either HBH or E2E encryption keys.</t>
<t>A third party could cause a denial-of-service by transmitting many bogus <t>A third party could cause a denial of service by transmitting many bo
or replayed packets toward receiving devices that ultimately degrade gus
or replayed packets toward receiving devices and ultimately degrading
conference or device performance. Therefore, implementations might wish to conference or device performance. Therefore, implementations might wish to
devise mechanisms to safeguard against such illegitimate packets, such as devise mechanisms to safeguard against such illegitimate packets, such as
utilizing rate-limiting or performing basic sanity-checks on packets utilizing rate-limiting or performing basic sanity checks on packets
(e.g., looking at packet length or expected sequence number ranges) before (e.g., looking at packet length or expected sequence number ranges), before
performing more expensive decryption operations.</t> performing decryption operations that are more expensive.</t>
<t>Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps to <t>The use of mutual DTLS authentication (as required by DTLS-SRTP) also
prevent a denial-of-service attack by preventing a false Endpoint or false helps to
prevent a denial-of-service attack by preventing a false endpoint or false
Media Distributor from successfully participating as a perceived valid media Media Distributor from successfully participating as a perceived valid media
sender that could otherwise carry out an on-path attack. When mutual sender that could otherwise carry out an on-path attack. When mutual
authentication fails, a receiving Endpoint would know that it could safely authentication fails, a receiving endpoint would know that it could safely
discard media packets received from the Endpoint without inspection.</t> discard media packets received from the endpoint without inspection.</t>
</section> </section>
<section anchor="media-distributor-attacks" numbered="true" toc="default">
<section anchor="media-distributor-attacks" title="Media Distributor Attacks"> <name>Media Distributor Attacks</name>
<t>A malicious or compromised Media Distributor can attack the session in a <t>A malicious or compromised Media Distributor can attack the session i
number of possible ways.</t> n a
number of possible ways, as discussed below.</t>
<section anchor="denial-of-service" title="Denial of service"> <section anchor="denial-of-service" numbered="true" toc="default">
<t>A simple form of attack is discarding received packets that should be <name>Denial of Service</name>
forwarded. This solution framework does not introduce any mitigation for <t>A simple form of attack is discarding received packets that should
Media Distributors that fail to forward media packets.</t> be
<t>Another form of attack is modifying received packets before forwarding. forwarded. This solution framework does not provide any mitigation
With this solution framework, any modification of the end-to-end mechanisms for Media Distributors that fail to forward media packets.</t>
authenticated data results in the receiving Endpoint getting an integrity <t>Another form of attack is modifying received packets before forward
failure when performing authentication on the received packet.</t> ing.
<t>The Media Distributor can also attempt to perform resource consumption With this solution framework, any modification of the E2E-authenticated data
attacks on the receiving Endpoint. One such attack would be to insert results in the receiving endpoint getting an integrity failure when performing a
random SSRC/CSRC values in any RTP packet along with a Full EKT Tag. uthentication on the received packet.</t>
Since such a message would trigger the receiver to form a new cryptographic <t>The Media Distributor can also attempt to perform resource consumpt
ion
attacks on the receiving endpoint. One such attack would be to insert
random SSRC/CSRC values in any RTP packet along with a Full EKT Tag. &nbsp;Since
such a message would trigger the receiver to form a new cryptographic
context, the Media Distributor can attempt to consume the receiving context, the Media Distributor can attempt to consume the receiving
Endpoint's resources. While E2E authentication would fail and the endpoint's resources. While E2E authentication would fail and the
cryptographic context would be destroyed, the key derivation operation cryptographic context would be destroyed, the key derivation operation
would nonetheless consume some computational resources. While resource would nonetheless consume some computational resources. While resource
consumption attacks cannot be mitigated entirely, rate-limiting packets consumption attacks cannot be mitigated entirely, rate-limiting packets
might help reduce the impact of such attacks.</t> might help reduce the impact of such attacks.</t>
</section> </section>
<section anchor="replay-attack" numbered="true" toc="default">
<section anchor="replay-attack" title="Replay Attack"> <name>Replay Attacks</name>
<t>A replay attack is when an already received packet from a previous <t>A replay attack is an attack where an already-received packet from
point in the RTP stream is replayed as new packet. This could, for a previous
point in the RTP stream is replayed as a new packet. This could, for
example, allow a Media Distributor to transmit a sequence of packets example, allow a Media Distributor to transmit a sequence of packets
identified as a user saying &quot;yes&quot;, instead of the &quot;no&quot; the u ser identified as a user saying "yes", instead of the "no" the user
actually said.</t> actually said.</t>
<t>A replay attack is mitigated by the requirement to implement <t>A replay attack is mitigated by the requirement to implement
replay protection as replay protection as
described in Section 3.3.2 of <xref target="RFC3711"></xref>. described in <xref target="RFC3711" sectionFormat="of" section="3.3.2"/>.
End-to-end replay protection MUST be provided for the E2E replay protection <bcp14>MUST</bcp14> be provided for the
duration of the conference.</t> duration of the conference.</t>
</section> </section>
<section anchor="delayed-playout-attack" numbered="true" toc="default">
<section anchor="delayed-playout-attack" title="Delayed Playout Attack"> <name>Delayed Playout Attacks</name>
<t>A delayed playout attack is one where media is received and held by <t>A delayed playout attack is an attack where media is received and h
a Media Distributor and then forwarded to Endpoints at a later point eld by
a Media Distributor and then forwarded to endpoints at a later point
in time.</t> in time.</t>
<t>This attack is possible even if E2E replay protection is in place. <t>This attack is possible even if E2E replay protection is in place.
Because the Media Distributor is allowed to select a Because the Media Distributor is allowed to select a
subset of streams and not forward the rest to a receiver, such as in subset of streams and not forward the rest to a receiver, such as in
forwarding only the most active speakers, the receiver has to accept forwarding only the most active speakers, the receiver has to accept
gaps in the E2E packet sequence. The issue with this is that a Media gaps in the E2E packet sequence. The problem here is that a Media
Distributor can select to not deliver a particular stream for a while.</t> Distributor can choose to not deliver a particular stream for a while.</t>
<t>While the Media Distributor can purposely stop forwarding media flows, it <t>While the Media Distributor can purposely stop forwarding media flo
ws, it
can also select an arbitrary starting point to resume forwarding those can also select an arbitrary starting point to resume forwarding those
media flow, perhaps forwarding old packets rather than current packets. media flows, perhaps forwarding old packets rather than current packets.
As a consequence, what the media source sent can be substantially delayed As a consequence, what the media source sent can be substantially delayed
at the receiver with the receiver believing that newly arriving packets at the receiver with the receiver believing that newly arriving packets
are delayed only by transport delay when the packets may actually be are delayed only by transport delay when the packets may actually be
minutes or hours old.</t> minutes or hours old.</t>
<t>While this attack cannot be eliminated entirely, its effectiveness <t>While this attack cannot be eliminated entirely, its effectiveness
can be reduced by re-keying the conference periodically since can be reduced by rekeying the conference periodically, since
significantly-delayed media encrypted with expired keys would not be significantly delayed media encrypted with expired keys would not be
decrypted by Endpoints.</t> decrypted by endpoints.</t>
</section> </section>
<section anchor="splicing-attack" numbered="true" toc="default">
<section anchor="splicing-attack" title="Splicing Attack"> <name>Splicing Attacks</name>
<t>A splicing attack is an attack where a Media Distributor receiving <t>A splicing attack is an attack where a Media Distributor receiving
multiple media sources splices one media stream into the other. If multiple media sources splices one media stream into the other. If
the Media Distributor were able to change the SSRC without the receiver the Media Distributor were able to change the SSRC without the receiver
having any method for verifying the original source ID, then the Media having any method for verifying the original source ID, then the Media
Distributor could first deliver stream A and then later forward stream Distributor could first deliver stream A and then later forward stream
B under the same SSRC as stream A was previously using. By including B under the same SSRC that stream A was previously using. By including
the SSRC in the integrity check for each packet, both HBH and E2E, PERC the SSRC in the integrity check for each packet -- both HBH and E2E -- PERC
prevents splicing attacks.</t> prevents splicing attacks.</t>
</section> </section>
<section anchor="rtcp-attacks" numbered="true" toc="default">
<section anchor="rtcp-attacks" title="RTCP Attacks"> <name>RTCP Attacks</name>
<t>PERC does not provide end-to-end protection of RTCP messages. This allows <t>PERC does not provide E2E protection of RTCP messages. This allows
a compromised Media Distributor to impact any message that might be a compromised Media Distributor to impact any message that might be
transmitted via RTCP, including media statistics, picture requests, or loss transmitted via RTCP, including media statistics, picture requests, or loss
indication. It is also possible for a compromised Media Distributor to forge indication. It is also possible for a compromised Media Distributor to forge
requests, such as requests to the Endpoint to send a new picture. Such requests, such as requests to the endpoint to send a new picture. Such
requests can consume significant bandwidth and impair conference performance.</t > requests can consume significant bandwidth and impair conference performance.</t >
</section> </section>
</section> </section>
<section anchor="key-distributor-attacks" numbered="true" toc="default">
<section anchor="key-distributor-attacks" title="Key Distributor Attacks"> <name>Key Distributor Attacks</name>
<t>As stated in <xref target="key_distributor"></xref>, the Key Distributor need <t>As stated in <xref target="key_distributor" format="default"/>, the K
s to be secured ey Distributor needs to be secured,
since exploiting the Key Server can allow an adversary to gain access to since exploiting the Key Server can allow an adversary to gain access to
the keying material for one or more conferences. Having access to that the keying material for one or more conferences. Having access to that
keying material would then allow the adversary to decrypt media sent from keying material would then allow the adversary to decrypt media sent from
any Endpoint in the conference.</t> any endpoint in the conference.</t>
<t>As a first line of defense, the Key Distributor authenticates every <t>As a first line of defense, the Key Distributor authenticates every
security association, both associations with Endpoints and Media security association -- associations with both endpoints and Media
Distributors. The Key Distributor knows which entities are authorized to Distributors. The Key Distributor knows which entities are authorized to
have access to which keys and inspection of certificates will substantially have access to which keys, and inspection of certificates will substantially
reduce the risk of providing keys to an adversary.</t> reduce the risk of providing keys to an adversary.</t>
<t>Both physical and network access to the Key Distributor should be severely <t>Both physical and network access to the Key Distributor should be sev erely
restricted. This may be more difficult to achieve when the Key Distributor restricted. This may be more difficult to achieve when the Key Distributor
is embedded within and Endpoint, for example. Nonetheless, consideration is embedded within, for example, an endpoint. Nonetheless, consideration
should be given to shielding the Key Distributor from unauthorized access should be given to shielding the Key Distributor from unauthorized access
or any access that is not strictly necessary for the support of an or any access that is not strictly necessary for the support of an
ongoing conference.</t> ongoing conference.</t>
<t>Consideration should be given to whether access to the keying material <t>Consideration should be given to whether access to the keying materia l
will be needed beyond the conclusion of a conference. If not needed, will be needed beyond the conclusion of a conference. If not needed,
the Key Distributor's policy should be to destroy the keying material the Key Distributor's policy should be to destroy the keying material
once the conference concludes or when keying material changes during once the conference concludes or when keying material changes during
the course of the conference. If keying material is needed beyond the the course of the conference. If keying material is needed beyond the
lifetime of the conference, further consideration should be given to lifetime of the conference, further consideration should be given to
protecting keying material from future exposure. While it might be protecting keying material from future exposure. While it might seem
obvious, it is worth stating to avoid any doubt that if an adversary were obvious, it is worth making this point, to avoid any doubt that if an adversary
were
to record the media packets transmitted during a conference and then to record the media packets transmitted during a conference and then
gain unauthorized access to the keying material left unsecured on the gain unauthorized access to the keying material left unsecured on the
Key Distributor even years later, the adversary could decrypt the Key Distributor even years later, the adversary could decrypt the
content every packet transmitted during the conference.</t> content of every packet transmitted during the conference.</t>
</section> </section>
<section anchor="endpoint-attacks" numbered="true" toc="default">
<section anchor="endpoint-attacks" title="Endpoint Attacks"> <name>Endpoint Attacks</name>
<t>A Trusted Endpoint is so named because conference confidentiality relies <t>A Trusted Endpoint is so named because conference confidentiality rel
heavily on the security and integrity of the Endpoint. If an adversary ies
successfully exploits a vulnerability in an Endpoint, it might be possible heavily on the security and integrity of the endpoint. If an adversary
successfully exploits a vulnerability in an endpoint, it might be possible
for the adversary to obtain all of the keying material used in the for the adversary to obtain all of the keying material used in the
conference. With that keying material, an adversary could decrypt any conference. With that keying material, an adversary could decrypt any
of the media flows received from any other Endpoint, either in real-time of the media flows received from any other endpoint, either in real time
or at a later point in time (assuming the adversary makes a copy of the or at a later point in time (assuming that the adversary makes a copy of the
media packets).</t> media packets).</t>
<t>Additionally, if an adversary successfully exploits an Endpoint, the <t>Additionally, if an adversary successfully exploits an endpoint, the
adversary could inject media into the conference. One way an adversary adversary could inject media into the conference. For example, an adversary
could do that is by manipulating the RTP or SRTP software to transmit could manipulate the RTP or SRTP software to transmit
whatever media the adversary wishes to send. This could involve whatever media the adversary wishes to send.
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing This could involve the reuse of the compromised endpoint's SSRC or,
endpoint. This is made possible since all conference participants share since all conference participants share the same KEK,
the same KEK. Only a single SRTP cipher suite defined provides source the use of a new SSRC or the SSRC value of another endpoint.
Only a single SRTP cipher suite defined provides source
authentication properties that allow an endpoint to cryptographically authentication properties that allow an endpoint to cryptographically
assert that it sent a particular E2E protected packet (namely, TESLA assert that it sent a particular E2E-protected packet (namely, Timed Efficient
<xref target="RFC4383"></xref>), and its usage is presently not defined for PERC Stream Loss-Tolerant Authentication (TESLA)
. The suite <xref target="RFC4383" format="default"/>), and its usage is presently not
defined in PERC only allows an Endpoint to determine that whoever sent a defined for PERC. The suite
defined in PERC only allows an endpoint to determine that whoever sent a
packet had received the KEK.</t> packet had received the KEK.</t>
<t>However, attacks on the endpoint are not limited to the PERC-specific <t>However, attacks on the endpoint are not limited to the PERC-specific
software within the Endpoint. An attacker could inject media or record software within the endpoint. An attacker could inject media or record
media by manipulating the software that sits between the PERC-enabled media by manipulating the software that sits between the PERC-enabled
application and the hardware microphone of video camera, for example. application and the hardware microphone of a video camera, for example.
Likewise, an attacker could potentially access confidential media by Likewise, an attacker could potentially access confidential media by
accessing memory, cache, disk storage, etc. if the endpoint is no secured.</t> accessing memory, cache, disk storage, etc. if the endpoint is not secured.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<section anchor="iana-considerations" title="IANA Considerations"> <displayreference target="I-D.ietf-perc-dtls-tunnel" to="PERC-DTLS"/>
<t>There are no IANA considerations for this document.</t> <references>
</section> <name>References</name>
<references>
<name>Normative References</name>
<!-- draft-ietf-perc-double (RFC 8723; Published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8723.
xml"/>
<section anchor="acknowledgments" title="Acknowledgments"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.
<t>The authors would like to thank Mo Zanaty, Christian Oien, and Richard Barnes xml"/>
for invaluable input on this document. Also, we would like to acknowledge <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
Nermeen Ismail for serving on the initial versions of this document as xml"/>
a co-author. We would also like to acknowledge John Mattsson, Mats Naslund, <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
and Magnus Westerlund for providing some of the text in the document, xml"/>
including much of the original text in the security considerations section.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</section> xml"/>
</middle> <!-- draft-ietf-perc-srtp-ekt-diet (RFC 8870) -->
<reference anchor="RFC8870" target="https://www.rfc-editor.org/info/rfc8870">
<front>
<title>Encrypted Key Transport for DTLS and Secure RTP</title>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization>company</organization>
</author>
<author initials="J" surname="Mattsson" fullname="John Mattsson">
<organization>company</organization>
</author>
<author initials="D" surname="McGrew" fullname="David A. McGrew">
<organization>company</organization>
</author>
<author initials="D" surname="Wing" fullname="Dan Wing">
<organization>company</organization>
</author>
<author initials="F" surname="Andreasen" fullname="Flemming Andreasen">
<organization>company</organization>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8870"/>
<seriesInfo name="DOI" value="10.17487/RFC8870"/>
</reference>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.
<references title="Normative References"> xml"/>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf </references>
-perc-double.xml"?> <references>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml <name>Informative References</name>
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf
-perc-srtp-ekt-diet.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml
"?>
</references>
<references title="Informative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.CR-w <reference anchor="W3C.CR-webrtc" target="https://www.w3.org/TR/webrtc/">
ebrtc-20180927.xml"?> <front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
"?> <author initials="C." surname="Jennings" fullname="Cullen Jennings">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml <organization/>
"?> </author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4353.xml <author initials="H." surname="Boström" fullname="Henrik Boström">
"?> <organization/>
</author>
<author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
<organization/>
</author>
<date/>
</front>
<refcontent>W3C Proposed Recommendation</refcontent>
</reference>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.
"?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7667.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4353.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
xml"/>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf <!-- draft-ietf-perc-dtls-tunnel (Expired) -->
-perc-dtls-tunnel.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pe
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml rc-dtls-tunnel.xml"/>
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4383.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.
-rtcweb-security-arch.xml"?> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4383.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.
xml"/>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml <!-- draft-ietf-rtcweb-security-arch (RFC 8827) -->
"?> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
</references> <front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
</back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8224.
xml"/>
</references>
</references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Mo Zanaty"/>,
<contact fullname="Christian Oien"/>, and <contact fullname="Richard
Barnes"/> for invaluable input on this document. Also, we would like to
acknowledge <contact fullname="Nermeen Ismail"/> for serving on the
initial draft versions of this document as a coauthor. We would also
like to acknowledge <contact fullname="John Mattsson"/>, <contact
fullname="Mats Naslund"/>, and <contact fullname="Magnus Westerlund"/>
for providing some of the text in the document, including much of the
original text in the Security Considerations section (<xref
target="attacks"/>).</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 179 change blocks. 
787 lines changed or deleted 946 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/