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

Commentary: This is the first pass at responding to the emails from those named in the subject .
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.
Virutalized 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 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 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):
This document defines a solution framework wherein media privacy is
ensured by making it impossible for a media distributor 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 Distributors 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 distributor using a unique key per endpoint
that is independent from the key for media encryption and
authentication.
Paragraph (version B):
This document defines a solution framework wherein media privacy is
ensured by making it impossible for a media distributor 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 Distributors to modify certain RTP
headers; add, remove, encrypt, or decrypt RTP header extensions; and
encrypt and decrypt RTP Control Protocol (RTCP) RFC3550 packets.  The
framework also prevents replay attacks by authenticating each packet
transmitted between a given participant and the media distributor
using a unique key per endpoint that is independent from the key for
media encryption and authentication.
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 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.  This 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):
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.  This 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):
Interaction between the Key Distributor and the call processing
function is necessary to for proper conference-to-endpoint mappings.
This is described in conf-id.
Paragraph (version B):
Interaction between the Key Distributor and the call processing
function is necessary for proper conference-to-endpoint mappings.
This is described in conf-id.
Paragraph (version A):
This framework reuses several specified RTP security technologies,
including SRTP RFC3711, EKT I-D.ietf-perc-srtp-ekt-diet, and DTLS-
SRTP RFC5764.
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 RFC5764.
Paragraph (version A):
As a concrete example, SIP RFC3261 and SDP RFC4566 can be used to
convey the fingerprint information per RFC5763.  An endpoint's SIP
User Agent would send an INVITE message containing SDP for the media
session along with the endpoint's certificate fingerprint, which can
be signed using the procedures described in RFC8224 for the benefit
of forwarding the message to other entities by the Focus RFC4353.
Other entities can verify the fingerprints match the 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 authorized
entity.
Paragraph (version B):
As a concrete example, SIP RFC3261 and Session Description Protocol
(SDP) RFC4566 can be used to convey the fingerprint information per
RFC5763.  An endpoint's SIP User Agent would send an INVITE message
containing SDP for the media session along with the endpoint's
certificate fingerprint, which can be signed using the procedures
described in RFC8224 for the benefit of forwarding the message to
other entities by the Focus RFC4353.  Other entities can verify the
fingerprints match the 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 authorized entity.
Paragraph (version A):
This section describes the various keys employed by PERC, how they
are derived, conveyed, and so forth.
Paragraph (version B):
This section describes the various keys employed by PERC.
Paragraph (version A):
As stated earlier, the E2E key determined via DTLS-SRTP MAY be
discarded in favor of a locally-generated SRTP master key.  While the
DTLS-SRTP-derived SRTP master key can be used initially, the endpoint
might choose to change the SRTP master key periodically and MUST
change the SRTP master key as a result of the EKT key changing.
Paragraph (version B):
As stated earlier, the E2E key determined via DTLS-SRTP MAY be
discarded in favor of a locally-generated E2E SRTP master key.  While
the DTLS-SRTP-derived SRTP master key can be used initially, the
endpoint might choose to change the SRTP master key periodically and
MUST change the SRTP master key as a result of the EKT key changing.
Paragraph (version A):
Off-path attackers may try connecting to different PERC entities and
send specifically crafted packets.  A successful attacker might be
able to get the Media Distributor to forward such packets.  The Media
Distributor mitigates such an attack by performing hop-by-hop
authentication and discarding packets that fail authentication.
Paragraph (version A):
Another potential attack is a third party claiming to be a Media
Distributor, fooling endpoints in to sending packets to the false
Media Distributor 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 Media Distributor may cascade to another legitimate Media
Distributor creating a false version of the real conference.
Paragraph (version A):
This attack is be mitigated by the false Media Distributor not being
authenticated by the Key Distributor.  They Key Distributor will fail
to establish the secure association with the endpoint if the Media
Distributor cannot be authenticated.
Paragraph (version A):
The Media Distributor can attack the session in a number of possible
ways.
Paragraph (version B):
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 B):
Another attack vector is a third party claiming to be a Media
Distributor, fooling endpoints into sending packets to the false
Media Distributor instead of the correct one.  The deceived sending
endpoints could incorrectly assume their packets have been delivered
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 information, since the false Media Distributor would not
have access to either HBH or E2E encryption keys.
Paragraph (version B):
If mutual DTLS authentication is not employed, a false Media
Distributor could cascade to another legitimate Media Distributor
that is part of a larger conference.  However, this scenario will
also produce no positive results for the false Media Distributor
since it would not have access to keying material.
Paragraph (version B):
A third party could cause a denial-of-service by transmitting many
bogus or replayed packets toward receiving devices that ultimately
degrade conference or device performance.  Therefore, implementations
might wish to devise mechanisms to safeguard against such
illegitimate packets, such as utilizing rate-limiting or performing
basic sanity-checks on packets (e.g., looking at packet length or
expected sequence number ranges) before performing more expensive
decryption operations.
Paragraph (version B):
A malicious or compromised Media Distributor can attack the session
in a number of possible ways.
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.
Paragraph (version A):
A replay attack is when an already received packets from a previous
point in the RTP stream is replayed as new packet.  This could, for
example, allow a Media Distributor to transmit a sequence of packets
identified as a user saying "yes", instead of the "no" the user
actually said.
Paragraph (version A):
The mitigation for a replay attack is to prevent old packets beyond a
small-to-modest jitter and network re-ordering sized window to be
rejected.  End-to-end replay protection MUST be provided for the
whole duration of the conference.
Paragraph (version A):
The delayed playout attack is a variant of the replay attack.  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 sub-set 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):
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):
A replay attack is when an already received packet from a previous
point in the RTP stream is replayed as new packet.  This could, for
example, allow a Media Distributor to transmit a sequence of packets
identified as a user saying "yes", instead of the "no" the user
actually said.
Paragraph (version B):
The mitigation for a replay attack is to implement replay protection
as described in Section 3.3.2 of RFC3711.  End-to-end replay
protection MUST be provided for the whole duration of the conference.
Paragraph (version B):
The delayed playout attack is a variant of the replay attack.  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):
The splicing attack is an attack where a Media Distributor receiving
multiple media sources splices one media stream into the other.  If
the Media Distributor is able to change the SSRC without the receiver
having any method for verifying the original source ID, then the
Media Distributor could first deliver stream A and then later forward
stream B under the same SSRC as stream A was previously using.  By
not allowing the Media Distributor to change the SSRC, PERC mitigates
this attack.
Paragraph (version B):
A splicing attack is an attack where a Media Distributor receiving
multiple media sources splices one media stream into the other.  If
the Media Distributor were able to change the SSRC without the
receiver having any method for verifying the original source ID, then
the Media Distributor could first deliver stream A and then later
forward stream B under the same SSRC as stream A was previously
using.  By including the SSRC in the integrity check for each packet,
both HBH and E2E, PERC prevents splicing attacks.
Paragraph (version B):
PERC does not provide end-to-end protection of RTCP messages.  This
allows a compromised Media Distributor to impact any message that
might be transmitted via RTCP, including media statistics, picture
requests, or loss 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 can consume significant
bandwidth and impair conference performance.