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

Commentary: Changes to the framework and tunnel draft ( latter just a minor edit )
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
distribution devices 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 aims to build upon existing security mechanisms
defined for the real-time transport protocol (RTP).
Paragraph (version A):
This document defines a solution framework wherein media privacy is
ensured by making it impossible for a 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 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 distribution device 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 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 A):
End-to-End (E2E): Communications from one endpoint through one or
more Media Distribution Devices to the endpoint at the other end.
Paragraph (version A):
Hop-by-Hop (HBH): Communications between an endpoint and a Media
Distribution Device or between Media Distribution Devices.
Paragraph (version B):
End-to-End (E2E): Communications from one endpoint through one or
more Media Distributors to the endpoint at the other end.
Paragraph (version B):
Hop-by-Hop (HBH): Communications between an endpoint and a Media
Distributor or between Media Distributors.
Paragraph (version A):
Media Distributor (MD): An RTP middlebox that is not allowed to to
have access to E2E encryption keys.  It operates according to the
Selective Forwarding Middlebox 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 B):
Media Distributor (MD): An RTP middlebox that is not allowed to 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.
Paragraph (version A):
The architecture described in this framework document enables
conferencing infrastructure to be hosted in domains, such as in a
cloud conferencing provider's facilities, where the trustworthiness
is below the level needed to assume the privacy of participant's
media will not be compromised.  The conferencing infrastructure in
such a domain is still trusted with reliably connecting the
participants together in a conference, but not trusted with keying
material needed to decrypt any of the participant's media.  Entities
in such lower trustworthiness domains will simply be referred to as
untrusted entities from this point forward.  This does not mean that
they are completely untrusted as they may be trusted with most non-
media related aspects of hosting a conference.
Paragraph (version B):
The architecture described in this framework document enables
conferencing infrastructure to be hosted in domains, such as in a
cloud conferencing provider's facilities, where the trustworthiness
is below the level needed to assume the privacy of participant's
media will not be compromised.  The conferencing infrastructure in
such a domain is still trusted with reliably connecting the
participants together in a conference, but not trusted with keying
material needed to decrypt any of the participant's media.  Entities
in such lower trustworthiness domains will simply be referred to as
untrusted entities from this point forward.
Paragraph (version B):
It is important to understand that untrusted in this document does
not mean an entity is not expected to function properly.  Rather, it
means only that the entity does not have access to the E2E media
encryption keys.
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 will also relay secured
messaging between the endpoints and the Key Distributor and will
acquire per-hop key information from the Key Distributor.  The actual
media content MUST NOT not be decryptable by a Media Distributor, 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 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 will also relay secured
messaging between the endpoints and the Key Distributor and will
acquire per-hop key information from the Key Distributor.  The actual
media content MUST NOT not be decryptable by a Media Distributor, so
it is untrusted to have access to the E2E media encryption keys.  The
key exchange mechanisms specified in this framework will prevent the
Media Distributor from gaining access to the E2E media encryption
keys.
Paragraph (version A):
From the PERC model system perspective, entities considered trusted
(refer to fig-trust-model) can be in possession of the E2E media
encryption key(s) for one or more conferences.
Paragraph (version B):
From the PERC model system perspective, entities considered trusted
(refer to fig-trust-model) can be in possession of the E2E media
encryption keys for one or more conferences.
Paragraph (version A):
Using hop-by-hop authentication gives the Media Distributor the
ability to change certain RTP header values.  Which values the Media
Distributor can change in the RTP header are defined in I-D.ietf-
perc-double.  RTCP can only be encrypted, giving the Media
Distributor 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 Media Distributor the
ability to change certain RTP header values.  Which values the Media
Distributor can change in the RTP header are defined in I-D.ietf-
perc-double.  RTCP can only be encrypted HBH, giving the Media
Distributor 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 Media
Distributor, this framework utilizes a DTLS-SRTP RFC5764 association
between an endpoint and the Key Distributor.  To establish this
association, an endpoint will send DTLS-SRTP messages to the Media
Distributor which will then forward them to the Key Distributor as
defined in I-D.ietf-perc-dtls-tunnel.  The Key Encryption Key (KEK)
(i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS
association to endpoints via procedures defined in PERC EKT [I-
D.ietf-perc-srtp-ekt-diet].
Paragraph (version A):
The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls-
tunnel establish one or more TLS tunnels between the Media
Distributor and Key Distributor, making it is 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 will enable each endpoint to receive E2E key
information, Key Encryption Key (KEK) information (i.e., EKT Key),
and HBH key information.  At the same time, the Key Distributor can
securely provide 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 will establish a DTLS-SRTP association over the RTP
session's media ports for the purposes of key information exchange
with the Key Distributor.  The Media Distributor will not terminate
the DTLS signaling, but will instead forward 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.
This tunnel is used to encapsulate the DTLS-SRTP signaling between
the Key Distributor and endpoints will also be used to convey HBH key
information from the Key Distributor to the Media Distributor, so no
additional protocol or interface is required.
Paragraph (version B):
The procedures defined in DTLS Tunnel for PERC I-D.ietf-perc-dtls-
tunnel establish one or more TLS tunnels between the Media
Distributor and Key Distributor, making it is 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 will enable 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 can securely provide 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 will 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 will not terminate
the DTLS signaling, but will instead forward 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.
This tunnel is used to encapsulate the DTLS-SRTP signaling between
the Key Distributor and endpoints will also be used to convey HBH key
information from the Key Distributor to the Media Distributor, so no
additional protocol or interface is required.
Paragraph (version A):
Following the initial key information exchange with the Key
Distributor, an endpoints will be able to encrypt media end-to-end
with an E2E key, sending that E2E key to other endpoints encrypted
with the KEK, and will be able to encrypt and authenticate RTP
packets using a HBH key.  The procedures defined do not allow the
Media Distributor to gain access to the KEK information, preventing
it from gaining access to any endpoint's E2E key and subsequently
decrypting media.
Paragraph (version B):
In establishing the DTLS association between endpoints and the Key
Distributor, the endpoint acts as the DTLS client and the Key
Distributor acts 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 PERC EKT I-D.ietf-
perc-srtp-ekt-diet via the EKTKey message.
Paragraph (version B):
Note that following DTLS-SRTP procedures for the I-D.ietf-perc-double
cipher, the endpoint will generate both E2E and HBH encryption keys
and salt values.  Endpoints MAY use the DTLS-SRTP generated E2E key
or MAY generate different E2E keys.  In either case, the generated
SRTP master salt for E2E encryption MUST be replaced with the salt
value provided by the Key Distributor via the EKTKey message.  That
is because 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 encryption to other endpoints in RTP/RTCP packets per I-
D.ietf-perc-srtp-ekt-diet.
Paragraph (version B):
Following the initial key information exchange with the Key
Distributor, an endpoint will be able to encrypt media end-to-end
with an E2E key, sending that E2E key to other endpoints encrypted
with the KEK, and will be able to encrypt and authenticate RTP
packets using a HBH key.  The procedures defined do not allow the
Media Distributor to gain access to the KEK information, preventing
it from gaining access to any endpoint's E2E key and subsequently
decrypting media.
Paragraph (version A):
When a Key Distributor decides to re-key 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 EKTKey.  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 B):
When a Key Distributor decides to re-key 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 EKTKey.  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 B):
Endpoints MAY follow the procedures in section 5.2 of RFC5764 to re-
negotiate HBH keys as desired.  If new HBH keys are generated, the
new keys are also delivered to the Media Distributor following the
procedures defined in I-D.ietf-perc-dtls-tunnel.
Paragraph (version B):
Endpoints are at liberty to 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
will be conveyed to other endpoints in the conference in RTP/RTCP
packets per I-D.ietf-perc-srtp-ekt-diet.