Draft: draft-ietf-perc-private-media-framework

Commentary: A number of comments from Vincent , Barry ,  ,  , ...
Paragraph (version A):
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 aims to build upon existing security mechanisms
defined for the real-time transport protocol (RTP).
Paragraph (version B):
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 mechanisms defined
for the real-time transport protocol (RTP).
Paragraph (version A):
An advantage of switched conferencing is that Media Distributors can
be more easily deployed on general-purpose computing hardware,
including virtualized environments in private and public clouds.
Virtualized public cloud environments have been viewed as less secure
since resources are not always physically controlled by those who use
them and since there are usually several ports open to the public.
This document aims to improve security so as to lower the barrier to
taking advantage of those environments.
Paragraph (version A):
A goal of this document is to define a framework for enhanced privacy
in RTP-based conferencing environments while utilizing existing
security procedures defined for RTP with minimal enhancements.
Paragraph (version B):
An advantage of switched conferencing is that Media Distributors can
be more easily deployed on general-purpose computing hardware,
including virtualized environments in private and public clouds.
Virtualized public cloud environments have been viewed as less secure
since resources are not always physically controlled by those who use
them.  This document defines improved security so as to lower the
barrier to taking advantage of those environments.
Paragraph (version B):
This solution framework provides for enhanced privacy in RTP-based
conferencing environments while utilizing existing security
procedures defined for RTP with minimal enhancements.
Paragraph (version A):
Trusted Endpoint: An RTP flow terminating entity that has possession
of E2E media encryption keys and terminates E2E encryption.  This may
include embedded user conferencing equipment or browsers on
computers, media gateways, MCUs, media recording device and more that
are in the trusted domain for a given deployment.  In the context of
WebRTC, where control of a session is divided between a JavaScript
application and a browser, the browser acts as the Trusted Endpoint
for purposes of this framework (just as it acts as the endpoint for
DTLS-SRTP RFC5764 in one-to-one calls).
Paragraph (version A):
Media Distributor (MD): An RTP middlebox that forwards endpoint media
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 Selective
Forwarding Middlebox RTP topologies RFC7667 per the constraints
defined by the PERC system, which includes, but not limited to,
having no access to RTP media unencrypted and having limits on what
RTP header field it can alter.  The header fields that may be
modified by a Media Distributor are enumerated in Section 4 of the
Double cryptographic transform specification I-D.ietf-perc-double and
chosen with respect to utility and the security considerations
outlined in this document.
Paragraph (version B):
Trusted Endpoint (or simply Endpoint): An RTP flow terminating entity
that has possession of E2E media encryption keys and terminates E2E
encryption.  This may include embedded user conferencing equipment or
browsers on computers, media gateways, MCUs, media recording devices
and more that are in the trusted domain for a given deployment.  In
the context of WebRTC W3C.CR-webrtc-20180927, where control of a
session is divided between a JavaScript application and a browser,
the browser acts as the Trusted Endpoint for purposes of this
framework (just as it acts as the endpoint for DTLS-SRTP RFC5764 in
one-to-one calls).
Paragraph (version B):
Media Distributor (MD): An RTP middlebox that forwards Endpoint media
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 Selective
Forwarding Middlebox RTP topologies RFC7667 per the constraints
defined by the PERC system, which includes, but is not limited 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 modified by
a Media Distributor are enumerated in Section 4 of the Double
cryptographic transform specification I-D.ietf-perc-double and chosen
with respect to utility and the security considerations outlined in
this document.
Paragraph (version A):
Please note that some entities classified as untrusted in the simple,
general deployment scenario used most commonly in this document might
be considered trusted in other deployments.  This document does not
preclude such scenarios, but keeps the definitions and examples
focused by only using the the simple, most general deployment
scenario.
Paragraph (version B):
Please note that some entities classified as untrusted in the simple,
general deployment scenario used most commonly in this document might
be considered trusted in other deployments.  This document does not
preclude such scenarios, but keeps the definitions and examples
focused by only using the simple, most general deployment scenario.
Paragraph (version A):
A Media Distributor forwards RTP flows between endpoints in the
conference while performing per-hop authentication of each RTP
packet.  The Media Distributor may need access to one or more RTP
headers or header extensions, potentially adding or modifying a
certain subset.  The Media Distributor also relays secured messaging
between the endpoints and the Key Distributor and acquires per-hop
key information from the Key Distributor.  The actual media content
must not be decryptable by a Media Distributor, as it is untrusted to
have access to the E2E media encryption keys.  The key exchange
mechanisms specified in this framework prevents the Media Distributor
from gaining access to the E2E media encryption keys.
Paragraph (version A):
A Media Distributor must perform its role in properly forwarding
media packets while taking measures to mitigate the adverse effects
of denial of service attacks (refer to attacks) to a level equal to
or better than traditional conferencing (i.e. non-PERC) deployments.
Paragraph (version B):
A Media Distributor forwards RTP flows between Endpoints in the
conference while performing per-hop authentication of each RTP
packet.  The Media Distributor may need access to one or more RTP
headers or header extensions, potentially adding or modifying a
certain subset.  The Media Distributor also relays secured messaging
between the Endpoints and the Key Distributor and acquires per-hop
key information from the Key Distributor.  The actual media content
must not be decryptable by a Media Distributor, as it is untrusted to
have access to the E2E media encryption keys.  The key exchange
mechanisms specified in this framework prevent the Media Distributor
from gaining access to the E2E media encryption keys.
Paragraph (version B):
A Media Distributor must perform its role in properly forwarding
media packets while taking measures to mitigate the adverse effects
of denial of service attacks (refer to attacks) to a level equal to
or better than traditional conferencing (non-PERC) deployments.
Paragraph (version A):
An endpoint is considered trusted and has access to E2E key
information.  While it is possible for an endpoint to be compromised,
subsequently performing in undesired ways, defining endpoint
resistance to compromise is outside the scope of this document.
Endpoints take measures to mitigate the adverse effects of denial of
service attacks (refer to attacks) from other entities, including
from other endpoints, to a level equal to or better than traditional
conference (i.e., non-PERC) deployments.
Paragraph (version A):
This framework reuses several specified RTP security technologies,
including Secure Real-time Transport Protocol (SRTP) RFC3711,
Encrypted Key Transport (EKT) I-D.ietf-perc-srtp-ekt-diet, and DTLS-
SRTP RFC5764.
Paragraph (version B):
An Endpoint is considered trusted and has access to E2E key
information.  While it is possible for an Endpoint to be compromised,
subsequently performing in undesired ways, defining Endpoint
resistance to compromise is outside the scope of this document.
Endpoints take measures to mitigate the adverse effects of denial of
service attacks (refer to attacks) from other entities, including
from other Endpoints, to a level equal to or better than traditional
conference (non-PERC) deployments.
Paragraph (version B):
They Key Distributor needs to know which Endpoints and which Media
Distributors are authorized to participate in the conference.  How
the Key Distributor obtains this information is outside the scope of
this document.  However, Key Distributors MUST reject DTLS
associations with any unauthorized Endpoint or Media Distributor.
Paragraph (version B):
This framework reuses several specified RTP security technologies,
including Secure Real-time Transport Protocol (SRTP) RFC3711,
Encrypted Key Transport (EKT) I-D.ietf-perc-srtp-ekt-diet, and DTLS-
SRTP.
Paragraph (version A):
This solution framework focuses on the end-to-end privacy and
integrity of the participant's media by limiting access to only
trusted entities to the E2E key used for authenticated end-to-end
encryption.  However, this framework does give a Media Distributor
access to RTP headers and all or most header extensions, as well as
the ability to modify a certain subset of those headers and to add
header extensions.  Packets received by a Media Distributor or an
endpoint are authenticated hop-by-hop.
Paragraph (version A):
To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys: an "inner" key
(an E2E key distinct for each transmitted media flow) for
authenticated encryption of RTP media between endpoints and an
"outer" key (HBH key) known only to Media Distributor and the
adjacent endpoint) for the hop between an endpoint and a Media
Distributor or between Media Distributor.
Paragraph (version B):
This solution framework focuses on the end-to-end privacy and
integrity of the participant's media by limiting access to only
trusted entities to the E2E key used for authenticated end-to-end
encryption.  However, this framework does give a Media Distributor
access to RTP headers 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 received by a Media Distributor or
an Endpoint are authenticated hop-by-hop.
Paragraph (version B):
To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys: an "inner" key
(an E2E key distinct for each transmitted media flow) for
authenticated encryption of RTP media between Endpoints and an
"outer" key (HBH key) known only to Media Distributor or the adjacent
Endpoint for the hop between an Endpoint and a Media Distributor or
peer Endpoint.  An Endpoint will receive one or more E2E keys from
every other Endpoint in the conference that correspond to the media
flows transmitted by those other Endpoints, while HBH keys are
derived from the DTLS-SRTP association with the Key Distributor.  Two
communicating Media Distributors use DTLS-SRTP associations directly
with each other to obtain the HBH keys they will use.  See
key_exchange for more details on key exchange.
Paragraph (version A):
RTCP is only encrypted hop-by-hop, not end-to-end.  This framework
introduces no additional step for RTCP authenticated encryption, so
the procedures needed are specified in RFC3711 and use the same
outer, hop-by-hop cryptographic context chosen in the Double
operation described above.
Paragraph (version A):
To ensure the confidentiality of E2E keys shared between endpoints,
endpoints use a common Key Encryption Key (KEK) that is known only by
the trusted entities in a conference.  That KEK, defined in the EKT
I-D.ietf-perc-srtp-ekt-diet specification as the EKT Key, is used to
subsequently encrypt the SRTP master key used for E2E authenticated
encryption of media sent by a given endpoint.  Each endpoint in the
conference creates an SRTP master key for E2E authenticated
encryption and keep track of the E2E keys received via the Full EKT
Tag for 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 time and advertise that new key to the
conference as specified in I-D.ietf-perc-srtp-ekt-diet.
Paragraph (version A):
If there is a need to encrypt one or more RTP header extensions end-
to-end, the endpoint derives an encryption key from the E2E SRTP
master key to encrypt header extensions as per RFC6904.  The Media
Distributor is unable use the information contained in those header
extensions encrypted with an E2E key.
Paragraph (version B):
RTCP is only encrypted hop-by-hop, not end-to-end.  This framework
introduces no additional step for RTCP authenticated encryption, so
the procedures needed are specified in RFC3711 and use the same
outer, hop-by-hop cryptographic context chosen in the Double
operation described above.  For this reason, Endpoints MUST NOT send
confidential information via RTCP.
Paragraph (version B):
To ensure the confidentiality of E2E keys shared between Endpoints,
Endpoints use a common Key Encryption Key (KEK) that is known only by
the trusted entities in a conference.  That KEK, defined in the EKT
specification I-D.ietf-perc-srtp-ekt-diet as the EKT Key, is used to
subsequently encrypt the SRTP master key used for E2E authenticated
encryption of media sent by a given Endpoint.  Each Endpoint in the
conference creates an SRTP master key for E2E authenticated
encryption and keep track of the E2E keys received via the Full EKT
Tag for 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 time and advertise that new key to the
conference as specified in I-D.ietf-perc-srtp-ekt-diet.
Paragraph (version B):
If the packet is to contain RTP header extensions, it should be noted
that those are only encrypted HBH per I-D.ietf-perc-double.  For this
reason, Endpoints MUST NOT transmit confidential information via RTP
header extensions.
Paragraph (version A):
If there is a need to encrypt one or more RTP header extensions hop-
by-hop, the endpoint derives an encryption key from the HBH SRTP
master key to encrypt header extensions as per RFC6904.  This still
gives the Media Distributor visibility into header extensions, such
as the one used to determine audio level RFC6464 of conference
participants.  Note that when RTP header extensions are encrypted,
all hops need to decrypt and re-encrypt these encrypted header
extensions.
Paragraph (version B):
If there is a need to encrypt one or more RTP header extensions hop-
by-hop, the Endpoint derives an encryption key from the HBH SRTP
master key to encrypt header extensions as per RFC6904.  This still
gives the Media Distributor visibility into header extensions, such
as the one used to determine audio level RFC6464 of conference
participants.  Note that when RTP header extensions are encrypted,
all hops need to decrypt and re-encrypt these encrypted header
extensions.  Please refer to Sections 5.1 through 5.3 of I-D.ietf-
perc-double for procedures to perform RTP header extension encryption
and decryption.
Paragraph (version A):
The Media Distributor maintains a tunnel with the Key Distributor
(e.g., using I-D.ietf-perc-dtls-tunnel), making it possible for the
Media Distributor to facilitate the establishment of a secure DTLS
association between each endpoint and the Key Distributor as shown
the following figure.  The DTLS association between endpoints and the
Key Distributor enables each endpoint to generate E2E and HBH keys
and receive the Key Encryption Key (KEK) (i.e., EKT Key).  At the
same time, the Key Distributor securely provides the HBH key
information to the Media Distributor.  The key information summarized
here may include the SRTP master key, SRTP master salt, and the
negotiated cryptographic transform.
Paragraph (version A):
Endpoints establish a DTLS-SRTP RFC5764 association over the RTP
session's media ports for the purposes of key information exchange
with the Key Distributor.  The Media Distributor does not terminate
the DTLS signaling, but instead forwards DTLS packets received from
an endpoint on to the Key Distributor (and vice versa) via a tunnel
established between Media Distributor and the Key Distributor.
Paragraph (version A):
In establishing the DTLS association between endpoints and the Key
Distributor, the endpoint MUST act as the DTLS client and the Key
Distributor MUST act as the DTLS server.  The Key Encryption Key
(KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the
DTLS association to endpoints via procedures defined in EKT I-D.ietf-
perc-srtp-ekt-diet via the EKTKey message.
Paragraph (version A):
Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media
Distributor to establish the HBH key for transmitting RTP and RTCP
packets to that peer Media Distributor.  The Key Distributor does not
facilitate establishing a HBH key for use between Media Distributors.
Paragraph (version B):
The Media Distributor maintains a tunnel with the Key Distributor
(e.g., using I-D.ietf-perc-dtls-tunnel), making it possible for the
Media Distributor to facilitate the establishment of a secure DTLS
association between each Endpoint and the Key Distributor as shown
the following figure.  The DTLS association between Endpoints and the
Key Distributor enables each Endpoint to generate E2E and HBH keys
and receive the KEK.  At the same time, the Key Distributor securely
provides the HBH key information to the Media Distributor.  The key
information summarized here may include the SRTP master key, SRTP
master salt, and the negotiated cryptographic transform.
Paragraph (version B):
Endpoints establish a DTLS-SRTP association over the RTP session with
the Media Distributor and its media ports for the purposes of key
information exchange with the Key Distributor.  The Media Distributor
does not terminate the DTLS signaling, but instead forwards DTLS
packets received from an Endpoint on to the Key Distributor (and vice
versa) via a tunnel established between Media Distributor and the Key
Distributor.
Paragraph (version B):
In establishing the DTLS association between Endpoints and the Key
Distributor, the Endpoint MUST act as the DTLS client and the Key
Distributor MUST act as the DTLS server.  The KEK is conveyed by the
Key Distributor over the DTLS association to Endpoints via procedures
defined in EKT I-D.ietf-perc-srtp-ekt-diet via the EKTKey message.
Paragraph (version B):
Media Distributors use DTLS-SRTP directly with a peer Media
Distributor to establish the HBH key for transmitting RTP and RTCP
packets to that peer Media Distributor.  The Key Distributor does not
facilitate establishing a HBH key for use between Media Distributors.
Paragraph (version A):
The KEK (i.e., EKT Key) may need to change from time-to-time during
the life 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 re-keyed is outside the scope of this document, but this
framework does accommodate re-keying during the life of a conference.
Paragraph (version A):
When a Key Distributor decides to re-key a conference, it transmits a
new EKTKey message containing the new EKT Key I-D.ietf-perc-srtp-ekt-
diet to each of the conference participants.  Upon receipt of the new
EKT Key, the endpoint MUST create a new SRTP master key and prepare
to send that key inside a Full EKT Field using the new EKT Key as per
Section 4.5 of I-D.ietf-perc-srtp-ekt-diet.  In order to allow time
for all endpoints in the conference to receive the new keys, the
sender should follow the recommendations in Section 4.7 of [I-D.ietf-
perc-srtp-ekt-diet].  On receiving a new EKT Key, endpoints MUST be
prepared to decrypt EKT tags using the new key.  The EKT SPI field is
used to differentiate between tags encrypted with the old and new
keys.
Paragraph (version B):
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
conference.  Dictating if, when or how often a conference is to be
re-keyed is outside the scope of this document, but this framework
does accommodate re-keying during the life of a conference.
Paragraph (version B):
When a Key Distributor decides to re-key a conference, it transmits a
new EKTKey message containing the new EKT Key to each of the
conference participants.  Upon receipt of the new EKT Key, the
Endpoint MUST create a new SRTP master key and prepare to send that
key inside a Full EKT Field using the new EKT Key as per Section 4.5
of I-D.ietf-perc-srtp-ekt-diet.  In order to allow time for all
Endpoints in the conference to receive the new keys, the sender
should follow the recommendations in Section 4.7 of [I-D.ietf-perc-
srtp-ekt-diet].  On receiving a new EKT Key, Endpoints MUST be
prepared to decrypt EKT tags using the new key.  The EKT SPI field is
used to differentiate between tags encrypted with the old and new
keys.
Paragraph (version A):
Endpoints MAY change the E2E encryption key used at any time.
Endpoints MUST generate a new E2E encryption 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 in RTP/RTCP packets per I-
D.ietf-perc-srtp-ekt-diet.
Paragraph (version A):
It is important to this solution framework that the entities can
validate the authenticity of other entities, especially the Key
Distributor and endpoints.  The details of this are outside the scope
of specification but a few possibilities are discussed in the
following sections.  The key requirements are that an endpoint can
verify it is connected to the correct Key Distributor for the
conference and the Key Distributor can verify the endpoint is the
correct endpoint for the conference.
Paragraph (version B):
Endpoints MAY change the E2E encryption key used at any time.  An
Endpoint MUST generate a new E2E encryption 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 in RTP/RTCP packets per I-
D.ietf-perc-srtp-ekt-diet.
Paragraph (version B):
It is important to this solution framework that the entities can
validate the authenticity of other entities, especially the Key
Distributor and Endpoints.  The details of this are outside the scope
of specification but a few possibilities are discussed in the
following sections.  The critical requirements are that an Endpoint
can verify it is connected to the correct Key Distributor for the
conference and the Key Distributor can verify the Endpoint is the
correct Endpoint for the conference.
Paragraph (version A):
Ultimately, if using session signaling, an endpoint's certificate
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.  Similarly, the Key Distributor's certificate fingerprint
can be conveyed to endpoint in a manner that can be authenticated as
being an authorized Key Distributor for this conference.
Paragraph (version B):
Ultimately, if using session signaling, an Endpoint's certificate
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.  Similarly, the Key Distributor's certificate fingerprint
can be conveyed to an Endpoint in a manner that can be authenticated
as being an authorized Key Distributor for this conference.
Paragraph (version A):
Complicating key management is the fact that the KEK can change and,
when it does, the endpoints generate new SRTP master keys that are
associated with a new EKT SPI.  Endpoints have to retain old keys for
a period of time to ensure they can properly decrypt late-arriving or
out-of-order packets.
Paragraph (version B):
Complicating key management is the fact that the KEK can change and,
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 ensure they can properly decrypt late-arriving or
out-of-order packets, which means the number of keys held during that
period of time might substantially more.
Paragraph (version A):
The Key Distributor informs the Media Distributor of the HBH key.
Specifically, the Key Distributor sends the least significant bits
corresponding to the half of the keying material determined through
DTLS-SRTP with the endpoint to the Media Distributor.  A salt value
is 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 required length (i.e., half of the generated salt
material) are sent to the Media Distributor.  One way to transmit
this key and salt information is via the tunnel protocol defined in
I-D.ietf-perc-dtls-tunnel.
Paragraph (version B):
The Key Distributor informs the Media Distributor of the HBH key.
Specifically, the Key Distributor sends the least significant bits
corresponding to the half of the keying material determined through
DTLS-SRTP with the Endpoint to the Media Distributor.  A salt value
is 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 required length (half of the generated salt material) are
sent to the Media Distributor.  One way to transmit this key and salt
information is via the tunnel protocol defined in I-D.ietf-perc-dtls-
tunnel.
Paragraph (version A):
Via the aforementioned DTLS-SRTP association, the Key Distributor
sends the endpoint the KEK (i.e., EKT Key per I-D.ietf-perc-srtp-ekt-
diet).  This key is known only to the Key Distributor and endpoints.
This key is the most important to protect since having knowledge of
this key (and the SRTP master salt transmitted as a part of the same
message) allows an entity to decrypt any media packet in the
conference.
Paragraph (version A):
The media distributor is not given the KEK (i.e., EKT Key).
Paragraph (version A):
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.
Paragraph (version A):
Each endpoint generates its own E2E Key (SRTP master key), thus
distinct per endpoint.  This key is transmitted (encrypted) via the
Full EKT Tag to other endpoints.  Endpoints that receive media from a
given transmitting endpoint gains knowledge of the transmitter's E2E
key via the Full EKT Tag.
Paragraph (version B):
Via the aforementioned DTLS-SRTP association, the Key Distributor
sends the Endpoint the KEK (EKT Key per I-D.ietf-perc-srtp-ekt-diet).
This key is known only to the Key Distributor and Endpoints.  This
key is the most important to protect since having knowledge of this
key (and the SRTP master salt transmitted as a part of the same
message) allows an entity to decrypt any media packet in the
conference.
Paragraph (version B):
The Media Distributor is not given the KEK.
Paragraph (version B):
Each Endpoint generates its own E2E key (SRTP master key), thus there
is a distinct E2E key per endpoint.  This key is transmitted
(encrypted) via the Full EKT Tag to other Endpoints.  Endpoints that
receive media from a given transmitting Endpoint gain knowledge of
the transmitter's E2E key via the Full EKT Tag.
Paragraph (version A):
Off-path attackers could try connecting to different PERC entities
and send specifically crafted packets.  Endpoints and Media
Distributors mitigate such an attack by performing hop-by-hop
authentication and discarding packets that fail authentication.
Paragraph (version A):
Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures
that a false endpoint or false Media Distributor cannot interact with
a legitimate Media Distributor or endpoint.  While confidentiality
would not be compromised by failing to implement mutual
authentication, employing it helps mitigate against denial of service
attacks wherein a false entity sends a stream of packets that the
would force a legitimate entity to spend time attempting to decrypt.
Paragraph (version B):
Off-path attackers could try connecting to different PERC entities to
send specifically crafted packets with an aim of forcing the receiver
to forward or render bogus media packets.  Endpoints and Media
Distributors mitigate such an attack by performing hop-by-hop
authentication and discarding packets that fail authentication.
Paragraph (version B):
Use of mutual DTLS authentication (as required by DTLS-SRTP) also
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 sender that could otherwise carry out an
on-path attack.  When mutual authentication fails, a receiving
Endpoint would know that it could safely discard media packets
received from the Endpoint without inspection.
Paragraph (version A):
The Media Distributor can also attempt to perform resource
consumption attacks on the receiving endpoint.  One such attack would
be to insert random SSRC/CSRC values in any RTP packet with an inband
key-distribution message attached (i.e., Full EKT Tag).  Since such a
message would trigger the receiver to form a new cryptographic
context, the Media Distributor can attempt to consume the receiving
endpoints resources.  While E2E authentication would fail and the
cryptographic context would be destroyed, the key derivation
operation would nonetheless consume some computational resources.
While resource consumption attacks cannot be mitigated entirely,
rate-limiting packets might help reduce the impact of such attacks.
Paragraph (version B):
The Media Distributor can also attempt to perform resource
consumption 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.  Since such a message would trigger the receiver to
form a new cryptographic context, the Media Distributor can attempt
to consume the receiving Endpoint's resources.  While E2E
authentication would fail and the cryptographic context would be
destroyed, the key derivation operation would nonetheless consume
some computational resources.  While resource consumption attacks
cannot be mitigated entirely, rate-limiting packets might help reduce
the impact of such attacks.
Paragraph (version A):
This attack is possible even if E2E replay protection is in place.
However, due to fact that the Media Distributor is allowed to select
a 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 gaps in the E2E packet sequence.  The issue with this is that
a Media Distributor can select to not deliver a particular stream for
a while.
Paragraph (version A):
Within the window from last packet forwarded to the receiver and the
latest received by the Media Distributor, the Media Distributor can
select an arbitrary starting point when resuming forwarding packets.
Thus what the media source said can be substantially delayed at the
receiver with the receiver believing that it is what was said just
now, and only delayed due to transport delay.
Paragraph (version B):
This attack is possible even if E2E replay protection is in place.
Because the Media Distributor is allowed to select a 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 gaps in the
E2E packet sequence.  The issue with this is that a Media Distributor
can select to not deliver a particular stream for a while.
Paragraph (version B):
While the Media Distributor can purposely stop forwarding media
flows, it can also select an arbitrary starting point to resume
forwarding those media flow, perhaps forwarding old packets rather
than current packets.  As a consequence, what the media source sent
can be substantially delayed at the receiver with the receiver
believing that newly arriving packets are delayed only by transport
delay when the packets may actually be minutes or hours old.
Paragraph (version B):
As stated in key_distributor, the Key Distributor needs to be secured
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 keying material would then allow the adversary to decrypt media
sent from any Endpoint in the conference.
Paragraph (version B):
As a first line of defense, the Key Distributor authenticates every
security association, both associations with Endpoints and Media
Distributors.  The Key Distributor knows which entities are
authorized to have access to which keys and inspection of
certificates will substantially reduce the risk of providing keys to
an adversary.
Paragraph (version B):
Both physical and network access to the Key Distributor should be
severely restricted.  This may be more difficult to achieve when the
Key Distributor is embedded within and Endpoint, for example.
Nonetheless, consideration should be given to shielding the Key
Distributor from unauthorized access or any access that is not
strictly necessary for the support of an ongoing conference.
Paragraph (version B):
Consideration should be given to whether access to the keying
material will be needed beyond the conclusion of a conference.  If
not needed, the Key Distributor's policy should be to destroy the
keying material once the conference concludes or when keying material
changes during the course of the conference.  If keying material is
needed beyond the lifetime of the conference, further consideration
should be given to protecting keying material from future exposure.
While it might be obvious, it is worth stating to avoid any doubt
that if an adversary were to record the media packets transmitted
during a conference and then gain unauthorized access to the keying
material left unsecured on the Key Distributor even years later, the
adversary could decrypt the content every packet transmitted during
the conference.
Paragraph (version B):
A Trusted Endpoint is so named because conference confidentiality
relies 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 conference.  With that keying material, an
adversary could decrypt any 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 media packets).
Paragraph (version B):
Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference.  One way an
adversary could do that is by manipulating the RTP or SRTP software
to transmit whatever media the adversary wishes to send.  This could
involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value
of an existing endpoint.  This is made possible since all conference
participants share the same KEK.  Only a single SRTP cipher suite
defined provides source authentication properties that allow an
endpoint to cryptographically assert that it sent a particular E2E
protected packet (namely, TESLA RFC4383), and its usage is presently
not defined for PERC.  The suite defined in PERC only allows an
Endpoint to determine that whoever sent a packet had received the
KEK.
Paragraph (version B):
However, attacks on the endpoint are not limited to the PERC-specific
software within the Endpoint.  An attacker could inject media or
record media by manipulating the software that sits between the PERC-
enabled application and the hardware microphone of video camera, for
example.  Likewise, an attacker could potentially access confidential
media by accessing memory, cache, disk storage, etc. if the endpoint
is no secured.