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

Commentary: Update mostly moving all To DO notes to the end , correct / update references and some editorial only fixes to the intro and definition of terms .
Paragraph (version A):
some instances, the switching MDDs may make limited modifications to
RTP RFC3550 headers, for example, but the actual media content (e.g.,
voice or video data) is unaltered.
Paragraph (version A):
An advantage of switched conferencing is that MDDs can be deployed on
general-purpose computing hardware.  This, in turn, means that it is
possible to deploy switching MDDs in virtualized environments,
including private and public clouds.  Deploying conference resources
in a cloud environment might introduce a higher security risk.
Whereas traditional conference resources were usually deployed in
private networks that were protected, cloud-based conference
resources might be viewed as less secure since they are not always
physically controlled by those who use the hardware.  Additionally,
there are usually several ports open to the public in cloud
deployments, such as for remote administration, and so on.
Paragraph (version A):
This document defines a solution framework wherein privacy is ensured
by making it impossible for an MDD to gain access to keys needed to
decrypt or authenticate the actual media content sent between
conference participants.  At the same time, the framework allows for
the switching MDD to modify certain RTP headers; add, remove,
encrypt, or decrypt RTP header extensions; and encrypt and decrypt
RTCP packets.  The framework also prevents replay attacks by
authenticating each packet transmitted between a given participant
and the switching MDD by using a key that is independent from the
media encryption and authentication key(s) and is unique to the
participating endpoint and the switching MDD.
Paragraph (version B):
some instances, the MDDs may make limited modifications to RTP
RFC3550 headers, for example, but the actual media content (e.g.,
voice or video data) is unaltered.
Paragraph (version B):
An advantage of switched conferencing is that media distribution
devices can be more easily deployed on general-purpose computing
hardware, including virtualized environments in private and public
clouds.  Deploying conference resources in a public cloud environment
might introduce a higher security risk.  Whereas traditional
conference resources were usually deployed in private networks that
were protected, cloud-based conference resources might be viewed as
less secure since they are not always physically controlled by those
who use them.  Additionally, there are usually several ports open to
the public in cloud deployments, such as for remote administration,
and so on.
Paragraph (version B):
This document defines a solution framework wherein media privacy is
ensured by making it impossible for an media distribution device to
gain access to keys needed to decrypt or authenticate the actual
media content sent between conference participants.  At the same
time, the framework allows for the media distribution device to
modify certain RTP headers; add, remove, encrypt, or decrypt RTP
header extensions; and encrypt and decrypt RTCP packets.  The
framework also prevents replay attacks by authenticating each packet
transmitted between a given participant and the media distribution
device using a key that is independent from the media encryption and
authentication key(s) and is unique to each participating endpoint.
Paragraph (version A):
E2E (End-to-End): Communications from one endpoint through one or
more MDDs to the endpoint at the other end.
Paragraph (version A):
HBH (Hop-by-Hop): Communications between an endpoint and an MDD or
between MDDs.
Paragraph (version A):
Endpoint: An RTP flow terminating entity that has possession of E2E
media encryption keys and terminates end-to-end (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.
Paragraph (version B):
E2E (End-to-End): Communications from one endpoint through one or
more Media Distribution Devices to the endpoint at the other end.
Paragraph (version B):
HBH (Hop-by-Hop): Communications between an endpoint and an Media
Distribution Device or between Media Distribution Devices.
Paragraph (version B):
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.
Paragraph (version A):
MDD (Media Distribution Device): An RTP middlebox that is not allowed
to to have access to E2E encryption keys.  It may operate according
to any of the RTP topologies I-D.ietf-avtcore-rtp-topologies-update
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.
Paragraph (version A):
KMF (Key Management Function): An entity that is a logical function
which passes keying material and related information to endpoints and
MDDs that is appropriate for each.  The KMF might be co-resident with
another entity trusted with E2E keying material.
Paragraph (version A):
Conference: Two or more participants communicating via trusted
endpoints to exchange RTP flows through one or more MDDs.
Paragraph (version B):
MDD (Media Distribution Device): An RTP middlebox that is not allowed
to to have access to E2E encryption keys.  It may operate according
to any of the RTP topologies I-D.ietf-avtcore-rtp-topologies-update
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.  This entity may also
be called "Media Distributor" or "Distributor" throughoout this or
other PERC documents.
Paragraph (version B):
KMF (Key Management Function): An entity that is a logical function
which passes keying material and related information to endpoints and
Media Distribution Devices that is appropriate for each.  The KMF
might be co-resident with another entity trusted with E2E keying
material.
Paragraph (version B):
Conference: Two or more participants communicating via trusted
endpoints to exchange RTP flows through one or more Media
Distribution Devices.
Paragraph (version A):
An MDD forwards RTP flows between endpoints in the conference while
performing per-hop authentication of each RTP packet.  The MDD may
need access to one or more RTP headers or header extensions,
potentially adding or modifying a certain subset.  The MDD will also
relay secured messaging between the endpoints and the key management
function and will acquire per-hop key information from the KMF.  The
actual media content MUST NOT not be decryptable by an MDD, so it is
untrusted to have access to the E2E media encryption keys, which this
framework's key exchange mechanisms will prevent.
Paragraph (version B):
A Media Distribution Device (MDD) forwards RTP flows between
endpoints in the conference while performing per-hop authentication
of each RTP packet.  The MDD may need access to one or more RTP
headers or header extensions, potentially adding or modifying a
certain subset.  The MDD will also relay secured messaging between
the endpoints and the key management function and will acquire per-
hop key information from the KMF.  The actual media content MUST NOT
not be decryptable by an MDD, so it is untrusted to have access to
the E2E media encryption keys, which this framework's key exchange
mechanisms will prevent.
Paragraph (version A):
An MDD MUST perform its role in properly forwarding media packets
while taking measures to mitigate the adverse effects of denial of
service attacks (refer to Section attacks), etc, to a level equal to
or better than traditional conferencing (i.e. pre-PERC) deployments.
Paragraph (version B):
An MDD 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), etc, to a level equal to or
better than traditional conferencing (i.e. pre-PERC) deployments.
Paragraph (version A):
Obviously, the KMF needs to be closely managed to prevent
exploitation by an adversary, as any kind of security compromise of
the KMF puts the security of the conference at risk.
Paragraph (version B):
Interaction between the KMF and the call processing function may be
necessary to for proper conference-to-endpoint mappings, which may or
may not be satisfied by getting information directly from the
endpoints or via some other means.  See dolist for a related item in
the To Do list.
Paragraph (version B):
The KMF needs to be secured and managed in a way to prevent
exploitation by an adversary, as any kind of compromise of the KMF
puts the security of the conference at risk.
Paragraph (version A):
This framework reuses several specified RTP security technologies,
including SRTP RFC3711, PERC EKT I-D.jennings-perc-srtp-ekt-diet, and
DTLS-SRTP RFC5764.
Paragraph (version B):
This framework reuses several specified RTP security technologies,
including SRTP RFC3711, PERC EKT I-D.ietf-perc-srtp-ekt-diet, and
DTLS-SRTP RFC5764.
Paragraph (version A):
The PERC Double draft specification I-D.jennings-perc-double uses
standard SRTP keying material and recommended cryptographic
transform(s) to first form the inner, end-to-end SRTP cryptographic
context.  That end-to-end SRTP cryptographic context MAY be used to
encrypt some RTP header extensions along with RTP media content.  The
output of this is treated like an RTP packet and encrypted again
using the outer hop-by-hop cryptographic context.  The endpoint
executes the entire Double operation while the MDD just performs the
outer, hop-by-hop operation.
Paragraph (version B):
The PERC Double draft specification I-D.ietf-perc-double uses
standard SRTP keying material and recommended cryptographic
transform(s) to first form the inner, end-to-end SRTP cryptographic
context.  That end-to-end SRTP cryptographic context MAY be used to
encrypt some RTP header extensions along with RTP media content.  The
output of this is treated like an RTP packet and encrypted again
using the outer hop-by-hop cryptographic context.  The endpoint
executes the entire Double operation while the MDD just performs the
outer, hop-by-hop operation.
Paragraph (version A):
To ensure the confidentiality of E2E keys shared between endpoints,
endpoints will make use of a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference.  That KEK,
defined in the PERC EKT I-D.jennings-perc-srtp-ekt-diet as the EKT
Key, will be used to subsequently encrypt SRTP master keys used for
E2E authenticated encryption (E2E Key(i); i={a given endpoint}) of
media sent by a given endpoint.
Paragraph (version B):
To ensure the confidentiality of E2E keys shared between endpoints,
endpoints will make use of a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference.  That KEK,
defined in the PERC EKT I-D.ietf-perc-srtp-ekt-diet as the EKT Key,
will be used to subsequently encrypt SRTP master keys used for E2E
authenticated encryption (E2E Key(i); i={a given endpoint}) of media
sent by a given endpoint.
Paragraph (version A):
Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
and each SSRC's associated E2E Key(i) information.  Following a
change of the KEK (i.e., EKT Key), prior E2E Key(i) information
SHOULD be retained just long enough to ensure that late-arriving or
out-of-order packets can be successfully decrypted and rendered.
[NOTE: Perhaps a separate best practices document can recommend
durations after some real world testing?]  The endpoint SHOULD
discard the E2E Key(i) and KEK information when it leaves the
conference.
Paragraph (version B):
Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
and each SSRC's associated E2E Key(i) information.  Following a
change of the KEK (i.e., EKT Key), prior E2E Key(i) information
SHOULD be retained for a period long enough to ensure that late-
arriving or out-of-order packets from other endpoints can be
successfully decrypted.  The endpoint MUST discard the E2E Key(i) and
KEK information no later than when it leaves the conference.
Paragraph (version B):
If there is a need to encrypt one or more RTP header extensions end-
to-end, an encryption key is derived from the end-to-end SRTP master
key to encrypt header extensions as per RFC6904.  The MDD will not be
able use the information contained in those header extensions
encrypted with E2E keys.  See dolist for a related item in the To Do
list.
Paragraph (version A):
Using hop-by-hop authentication gives the MDD the ability to change
certain RTP header values.  Which values the MDD can change in the
RTP header are defined in I-D.jennings-perc-double.  RTCP can only be
encrtpted, giving the MDD the flexibility to forward RTCP content
unchanged, transmit compound RTCP packets or to initiate RTCP packets
for reporting statistics or conveying other information.  Performing
hop-by-hop authentication for all RTP and RTCP packets also helps
provide replay protection (see attacks).
Paragraph (version B):
Using hop-by-hop authentication gives the MDD the ability to change
certain RTP header values.  Which values the MDD can change in the
RTP header are defined in I-D.ietf-perc-double.  RTCP can only be
encrtpted, giving the MDD the flexibility to forward RTCP content
unchanged, transmit compound RTCP packets or to initiate RTCP packets
for reporting statistics or conveying other information.  Performing
hop-by-hop authentication for all RTP and RTCP packets also helps
provide replay protection (see attacks).
Paragraph (version A):
To facilitate key exchange required to establish or generate an E2E
key and a HBH key for an endpoint and the same HBH key for the MDD,
this framework utilizes a DTLS-SRTP RFC5764 association between an
endpoint and the KMF.  To establish this association, an endpoint
will send DTLS-SRTP messages to the MDD which will then forward them
to the MDD as defined in DTLS Tunnel for PERC I-D.jones-perc-dtls-
tunnel.  The KEK (i.e., EKT Key) is also conveyed by the KMF over the
DTLS association to endpoints via procedures defined in PERC EKT [I-
D.jennings-perc-srtp-ekt-diet].
Paragraph (version B):
To facilitate key exchange required to establish or generate an E2E
key and a HBH key for an endpoint and the same HBH key for the MDD,
this framework utilizes a DTLS-SRTP RFC5764 association between an
endpoint and the KMF.  To establish this association, an endpoint
will send DTLS-SRTP messages to the MDD which will then forward them
to the MDD as defined in the DTLS Tunnel for PERC I-D.jones-perc-
dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKT Key) is also
conveyed by the KMF over the DTLS association to endpoints via
procedures defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet].
Paragraph (version B):
When a KMF decides to rekey a conference, it transmits a specific
message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of
the conference participants.  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. Since it may take some time for all of the endpoints
in conference to finish re-keying, senders MUST delay a short period
of time before sending media encrypted with the new master key, but
it MUST be prepared to make use of the information from a new inbound
EKT Key immediately.  See Section 2.2.2 of I-D.ietf-perc-srtp-ekt-
diet.
Paragraph (version A):
WebRTC (EDIT: add reference) Identity assertion can be 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 unique
for a given call and a conference.  This allows the KMF to ensure
that only authorized users participate in the conference.  Similarly
the KMF can create a WeBRTC Identity assertion bound the fingerprint
of the unique certificate used by the KMF for this conference so that
the endpoint can validate it is talking to the correct KMF.
Paragraph (version B):
WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be
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 unique for a given call and a conference.  This allows
the KMF to ensure that only authorized users participate in the
conference.  Similarly the KMF can create a WeBRTC Identity assertion
bound the fingerprint of the unique certificate used by the KMF for
this conference so that the endpoint can validate it is talking to
the correct KMF.
Paragraph (version B):
Another potential attack is a third party claiming to be an MDD,
fooling endpoints in to sending packets to the false MDD instead of
the correct one.  The deceived sending endpoints could incorrectly
assuming their packets have been delivered to endpoints when they in
fact have not.  Further, the false MDD may cascade to another
legitimate MDD creating a false version of the real conference.
Paragraph (version B):
This attack can be mitigated by the false MDD not being authenticated
by the KMF during PERC Tunnel establishment.  Without the tunnel in
place, endpoints will not establish secure associations with the KMF
and receive the KEK, causing the conference to not proceed.