draft-ietf-perc-private-media-framework-05.txt   draft-ietf-perc-private-media-framework-06.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft D. Benham Internet-Draft D. Benham
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 3, 2018 C. Groves Expires: September 6, 2018 C. Groves
Huawei Independent
October 30, 2017 March 5, 2018
A Solution Framework for Private Media in Privacy Enhanced RTP A Solution Framework for Private Media in Privacy Enhanced RTP
Conferencing Conferencing
draft-ietf-perc-private-media-framework-05 draft-ietf-perc-private-media-framework-06
Abstract Abstract
This document describes a solution framework for ensuring that media This document describes a solution framework for ensuring that media
confidentiality and integrity are maintained end-to-end within the confidentiality and integrity are maintained end-to-end within the
context of a switched conferencing environment where media context of a switched conferencing environment where media
distributors are not trusted with the end-to-end media encryption distributors are not trusted with the end-to-end media encryption
keys. The solution aims to build upon existing security mechanisms keys. The solution aims to build upon existing security mechanisms
defined for the real-time transport protocol (RTP). defined for the real-time transport protocol (RTP).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6
3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7
4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7
4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8
4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9
4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9
4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 10 4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 10
4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10
4.5.1. Initial Key Exchange and Key Distributor . . . . . . 10 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11
4.5.2. Key Exchange during a Conference . . . . . . . . . . 12 4.5.2. Key Exchange during a Conference . . . . . . . . . . 12
5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 13 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 13
5.2. Certificate Fingerprints in Session Signaling . . . . . . 13 5.2. Certificate Fingerprints in Session Signaling . . . . . . 13
5.3. Conferences Identification . . . . . . . . . . . . . . . 14 5.3. Conferences Identification . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14
6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15
6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15
6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 16
6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16
6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 18 Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 19
A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 19 A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 20
A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20 A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20
A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21 A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21
A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21 A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21
Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22 Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Switched conferencing is an increasingly popular model for multimedia 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,
skipping to change at page 6, line 26 skipping to change at page 6, line 26
media content MUST NOT not be decryptable by a Media Distributor, so 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 it is untrusted to have access to the E2E media encryption keys. The
key exchange mechanisms specified in this framework will prevent the key exchange mechanisms specified in this framework will prevent the
Media Distributor from gaining access to the E2E media encryption Media Distributor from gaining access to the E2E media encryption
keys. keys.
An endpoint's ability to join a conference hosted by a Media An endpoint's ability to join a conference hosted by a Media
Distributor MUST NOT alone be interpreted as being authorized to have Distributor MUST NOT alone be interpreted as being authorized to have
access to the E2E media encryption keys, as the Media Distributor access to the E2E media encryption keys, as the Media Distributor
does not have the ability to determine whether an endpoint is does not have the ability to determine whether an endpoint is
authorized. Trusted endpoint authorization is described in authorized. Instead, the Key Distributor is responsible for
[I-D.roach-perc-webrtc]. authenticating endpoints (e.g., using WebRTC Identity
[I-D.ietf-rtcweb-security-arch]) and determining their authorization
to receive E2E media encryption keys.
A Media Distributor MUST perform its role in properly forwarding A Media Distributor MUST perform its role in properly forwarding
media packets while taking measures to mitigate the adverse effects media packets while taking measures to mitigate the adverse effects
of denial of service attacks (refer to Section 6), etc, to a level of denial of service attacks (refer to Section 6), etc, to a level
equal to or better than traditional conferencing (i.e. non-PERC) equal to or better than traditional conferencing (i.e. non-PERC)
deployments. deployments.
A Media Distributor or associated conferencing infrastructure may A Media Distributor or associated conferencing infrastructure may
also initiate or terminate various conference control related also initiate or terminate various conference control related
messaging, which is outside the scope of this framework document. messaging, which is outside the scope of this framework document.
skipping to change at page 7, line 30 skipping to change at page 7, line 31
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 will take measures to mitigate the adverse effects of Endpoints will take measures to mitigate the adverse effects of
denial of service attacks (refer to Section 6) from other entities, denial of service attacks (refer to Section 6) 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 (i.e., non-PERC) deployments. traditional conference (i.e., non-PERC) deployments.
3.2.2. Key Distributor 3.2.2. Key Distributor
The Key Distributor, which may be collocated with an endpoint or The Key Distributor, which may be colocated with an endpoint or exist
exist standalone, is responsible for providing key information to standalone, is responsible for providing key information to endpoints
endpoints for both end-to-end and hop-by-hop security and for for both end-to-end and hop-by-hop security and for providing key
providing key information to Media Distributors for the hop-by-hop information to Media Distributors for the hop-by-hop security.
security.
Interaction between the Key Distributor and the call processing Interaction between the Key Distributor and the call processing
function is necessary to for proper conference-to-endpoint mappings. function is necessary to for proper conference-to-endpoint mappings.
This is described in Section 5.3. This is described in Section 5.3.
The Key Distributor needs to be secured and managed in a way to The Key Distributor needs to be secured and managed in a way to
prevent exploitation by an adversary, as any kind of compromise of prevent exploitation by an adversary, as any kind of compromise of
the Key Distributor puts the security of the conference at risk. the Key Distributor puts the security of the conference at risk.
4. Framework for PERC 4. Framework for PERC
skipping to change at page 8, line 25 skipping to change at page 8, line 25
header extensions, as well as the ability to modify a certain subset header extensions, as well as the ability to modify a certain subset
of those headers and to add header extensions. Packets received by a of those headers and to add header extensions. Packets received by a
Media Distributor or an endpoint are authenticated hop-by-hop. Media Distributor or an endpoint are authenticated hop-by-hop.
To enable all of the above, this framework defines the use of two To enable all of the above, this framework defines the use of two
security contexts and two associated encryption keys: an "inner" key security contexts and two associated encryption keys: an "inner" key
(an E2E key distinct for each transmitted media flow) for (an E2E key distinct for each transmitted media flow) for
authenticated encryption of RTP media between endpoints and an authenticated encryption of RTP media between endpoints and an
"outer" key (HBH key) known only to media distributor and the "outer" key (HBH key) known only to media distributor and the
adjacent endpoint) for the hop between an endpoint and a Media adjacent endpoint) for the hop between an endpoint and a Media
Distributor or between Media Distributor. Reference the following Distributor or between Media Distributor.
figure.
+-------------+ +-------------+ +-------------+ +-------------+
| |################################| | | |################################| |
| Media |------------------------------->| Media | | Media |------------------------ *----->| Media |
| Distributor |<-------------------------------| Distributor | | Distributor |<----------------------*-|------| Distributor |
| X |################################| Y | | X |#####################*#|#|######| Y |
| | HBH Key (XY) | | | | | | | | |
+-------------+ +-------------+ +-------------+ | | | +-------------+
# ^ | # # ^ | # # ^ | # HBH Key (XY) -+ | | # ^ | #
# | | # HBH HBH # | | # # | | # E2E Key (B) ---+ | # | | #
# | | # <== Key(AX) Key(YB) ==> # | | # # | | # E2E Key (A) -----+ # | | #
# | | # # | | # # | | # # | | #
# |<+--#---- E2E Key (A) E2E Key (B) ---#->| | # # | | # # | | #
# | | *---- HBH Key (AX) HBH Key (YB) ----* | | #
# | | # # | | #
# *--------- E2E Key (A) E2E Key (A) ---------* #
# | *------- E2E Key (B) E2E Key (B) -------* | #
# | | # # | | # # | | # # | | #
# | v # # | v # # | v # # | v #
+-------------+ +-------------+ +-------------+ +-------------+
| Endpoint A | | Endpoint B | | Endpoint A | | Endpoint B |
+-------------+ +-------------+ +-------------+ +-------------+
E2E and HBH Keys Used for Authenticated Encryption E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets
The PERC Double specification [I-D.ietf-perc-double] uses standard The PERC Double transform [I-D.ietf-perc-double] enables endpoints to
SRTP keying material and recommended cryptographic transform(s) to perform encryption using both the E2E and HBH contexts while still
first form the inner, end-to-end SRTP cryptographic context. That preserving the same overall interface as other SRTP transforms. The
end-to-end SRTP cryptographic context MAY be used to encrypt some RTP Media Distributor simply uses the corresponding normal (single) AES-
header extensions along with RTP media content. The output of this GCM transform, keyed with the appropriate HBH keys. See Appendix A
is treated like an RTP packet and encrypted again using the outer for a description of the keys used in PERC and Appendix B for an
hop-by-hop cryptographic context. The endpoint executes the entire overview of how the packet appears on the wire.
Double operation while the Media Distributor just performs the outer,
hop-by-hop operation. (See Appendix A for a description of the keys
used in PERC and Appendix B for an overview of how the packet appears
on the wire.)
RTCP can only be encrypted hop-by-hop, not end-to-end. This RTCP can only be encrypted hop-by-hop, not end-to-end. This
framework introduces no additional step for RTCP authenticated framework introduces no additional step for RTCP authenticated
encryption, so the procedures needed are specified in [RFC3711] and encryption, so the procedures needed are specified in [RFC3711] and
use the same outer, hop-by-hop cryptographic context chosen in the use the same outer, hop-by-hop cryptographic context chosen in the
Double operation described above. Double operation described above.
4.2. E2E Key Confidentiality 4.2. E2E Key Confidentiality
To ensure the confidentiality of E2E keys shared between endpoints, To ensure the confidentiality of E2E keys shared between endpoints,
skipping to change at page 10, line 13 skipping to change at page 10, line 13
header extensions encrypted with an E2E key. header extensions encrypted with an E2E key.
4.4. HBH Keys and Hop Operations 4.4. HBH Keys and Hop Operations
To ensure the integrity of transmitted media packets, this framework To ensure the integrity of transmitted media packets, this framework
requires that every packet be authenticated hop-by-hop (HBH) between requires that every packet be authenticated hop-by-hop (HBH) between
an endpoint and a Media Distributor, as well between Media an endpoint and a Media Distributor, as well between Media
Distributors. The authentication key used for hop-by-hop Distributors. The authentication key used for hop-by-hop
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 respective hop. Each HBH key is distinct per hop and no two hops
ever intentionally use the same SRTP master key. ever use the same SRTP master key.
Using hop-by-hop authentication gives the Media Distributor the Using hop-by-hop authentication gives the Media Distributor the
ability to change certain RTP header values. Which values the Media ability to change certain RTP header values. Which values the Media
Distributor can change in the RTP header are defined in Distributor can change in the RTP header are defined in
[I-D.ietf-perc-double]. RTCP can only be encrypted HBH, giving the [I-D.ietf-perc-double]. RTCP can only be encrypted HBH, giving the
Media Distributor the flexibility to forward RTCP content unchanged, Media Distributor the flexibility to forward RTCP content unchanged,
transmit compound RTCP packets or to initiate RTCP packets for transmit compound RTCP packets or to initiate RTCP packets for
reporting statistics or conveying other information. Performing hop- reporting statistics or conveying other information. Performing hop-
by-hop authentication for all RTP and RTCP packets also helps provide by-hop authentication for all RTP and RTCP packets also helps provide
replay protection (see Section 6). replay protection (see Section 6).
skipping to change at page 10, line 36 skipping to change at page 10, line 36
by-hop, an encryption key is derived from the hop-by-hop SRTP master by-hop, an encryption key is derived from the hop-by-hop SRTP master
key to encrypt header extensions as per [RFC6904]. This will still key to encrypt header extensions as per [RFC6904]. This will still
give the Media Distributor visibility into header extensions, such as give the Media Distributor visibility into header extensions, such as
the one used to determine audio level [RFC6464] of conference the one used to determine audio level [RFC6464] of conference
participants. Note that when RTP header extensions are encrypted, participants. Note that when RTP header extensions are encrypted,
all hops - in the untrusted domain at least - will need to decrypt all hops - in the untrusted domain at least - will need to decrypt
and re-encrypt these encrypted header extensions. and re-encrypt these encrypted header extensions.
4.5. Key Exchange 4.5. Key Exchange
In brief, the keys used by any given endpoints are determined in the
following way:
o The HBH keys that the endpoint uses to send and receive SRTP media
are derived from a DTLS handshake that the endpoint performs with
the Key Distributor (following normal DTLS-SRTP procedures).
o The E2E key that an endpoint uses to send SRTP media can either be
set from DTLS or chosen by the endpoint. It is then distributed
to other endpoints in a Full EKT Field, encrypted under an EKTKey
provided to the client by the Key Distributor within the DTLS
channel they negotiated.
o Each E2E key that an endpoint uses to receive SRTP media is set by
receiving a Full EKT Field from another endpoint.
4.5.1. Initial Key Exchange and Key Distributor 4.5.1. Initial Key Exchange and Key Distributor
The procedures defined in DTLS Tunnel for PERC The Media Distributor maintains a tunnel with the Key Distrubutor
[I-D.ietf-perc-dtls-tunnel] establish one or more TLS tunnels between (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the
the Media Distributor and Key Distributor, making it is possible for Media Distributor to facilitate the establishment of a secure DTLS
the Media Distributor to facilitate the establishment of a secure association between each endpoint and the Key Distributor as shown
DTLS association between each endpoint and the Key Distributor as the following figure. The DTLS association between endpoints and the
shown the following figure. The DTLS association between endpoints Key Distributor will enable each endpoint to generate E2E and HBH
and the Key Distributor will enable each endpoint to generate E2E and keys and receive the Key Encryption Key (KEK) (i.e., EKT Key). At
HBH keys and receive the Key Encryption Key (KEK) (i.e., EKT Key). the same time, the Key Distributor can securely provide the HBH key
At the same time, the Key Distributor can securely provide the HBH information to the Media Distributor. The key information summarized
key information to the Media Distributor. The key information here may include the SRTP master key, SRTP master salt, and the
summarized here may include the SRTP master key, SRTP master salt, negotiated cryptographic transform.
and the negotiated cryptographic transform.
+-----------+ +-----------+
KEK info | Key | HBH Key info to KEK info | Key | HBH Key info to
to Endpoints |Distributor| Endpoints & Media Distributor to Endpoints |Distributor| Endpoints & Media Distributor
+-----------+ +-----------+
# ^ ^ # # ^ ^ #
# | | #-TLS Tunnel # | | #--- Tunnel
# | | # # | | #
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Endpoint | DTLS | Media | DTLS | Endpoint | | Endpoint | DTLS | Media | DTLS | Endpoint |
| KEK |<------------|Distributor|------------>| KEK | | KEK |<------------|Distributor|------------>| 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 |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
Figure 2: Exchanging Key Information Between Entities Figure 2: Exchanging Key Information Between Entities
Endpoints will establish a DTLS-SRTP [RFC5764] association over the Endpoints will establish a DTLS-SRTP [RFC5764] association over the
skipping to change at page 11, line 32 skipping to change at page 11, line 46
exchange with the Key Distributor. The Media Distributor will not exchange with the Key Distributor. The Media Distributor will not
terminate the DTLS signaling, but will instead forward DTLS packets terminate the DTLS signaling, but will instead forward DTLS packets
received from an endpoint on to the Key Distributor (and vice versa) received from an endpoint on to the Key Distributor (and vice versa)
via a tunnel established between Media Distributor and the Key via a tunnel established between Media Distributor and the Key
Distributor. This tunnel is used to encapsulate the DTLS-SRTP Distributor. This tunnel is used to encapsulate the DTLS-SRTP
signaling between the Key Distributor and endpoints will also be used signaling between the Key Distributor and endpoints will also be used
to convey HBH key information from the Key Distributor to the Media to convey HBH key information from the Key Distributor to the Media
Distributor, so no additional protocol or interface is required. Distributor, so no additional protocol or interface is required.
In establishing the DTLS association between endpoints and the Key In establishing the DTLS association between endpoints and the Key
Distributor, the endpoint acts as the DTLS client and the Key Distributor, the endpoint MUST act as the DTLS client and the Key
Distributor acts as the DTLS server. The Key Encryption Key (KEK) Distributor MUST act as the DTLS server. The Key Encryption Key
(i.e., EKT Key) is conveyed by the Key Distributor over the DTLS (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the
association to endpoints via procedures defined in PERC EKT DTLS association to endpoints via procedures defined in PERC EKT
[I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message.
Note that following DTLS-SRTP procedures for the Note that following DTLS-SRTP procedures for the
[I-D.ietf-perc-double] cipher, the endpoint will generate both E2E [I-D.ietf-perc-double] cipher, the endpoint will generate both E2E
and HBH encryption keys and salt values. Endpoints MAY use the DTLS- and HBH encryption keys and salt values. Endpoints MAY use the DTLS-
SRTP generated E2E key or MAY generate different E2E keys. In either SRTP generated E2E key for transmission or MAY generate a fresh E2E
case, the generated SRTP master salt for E2E encryption MUST be key. In either case, the generated SRTP master salt for E2E
replaced with the salt value provided by the Key Distributor via the encryption MUST be replaced with the salt value provided by the Key
EKTKey message. That is because every endpoint in the conference Distributor via the EKTKey message. That is because every endpoint
uses the same SRTP master salt. The endpoint only transmits the SRTP in the conference uses the same SRTP master salt. The endpoint only
master key (not the salt) used for E2E encryption to other endpoints transmits the SRTP master key (not the salt) used for E2E encryption
in RTP/RTCP packets per [I-D.ietf-perc-srtp-ekt-diet]. to other endpoints in RTP/RTCP packets per
[I-D.ietf-perc-srtp-ekt-diet].
Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media
Distributor to establish the HBH key for transmitting RTP and RTCP 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. facilitate establishing a HBH key for use between Media Distributors.
4.5.2. Key Exchange during a Conference 4.5.2. Key Exchange during a Conference
Following the initial key information exchange with the Key Following the initial key information exchange with the Key
Distributor, an endpoint will be able to encrypt media end-to-end Distributor, an endpoint will be able to encrypt media end-to-end
skipping to change at page 12, line 46 skipping to change at page 13, line 13
re-negotiate HBH keys as desired. If new HBH keys are generated, the re-negotiate 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 [I-D.ietf-perc-dtls-tunnel]. procedures defined in [I-D.ietf-perc-dtls-tunnel].
Endpoints are at liberty to change the E2E encryption key used at any Endpoints are at liberty to change the E2E encryption key used at any
time. Endpoints MUST generate a new E2E encryption key whenever it 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 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 will be conveyed to other endpoints in the conference in RTP/RTCP
packets per [I-D.ietf-perc-srtp-ekt-diet]. packets per [I-D.ietf-perc-srtp-ekt-diet].
5. Entity Trust 5. Authentication
It is important to this solution framework that the entities can It is important to this solution framework that the entities can
trust and validate the authenticity of other entities, especially the validate the authenticity of other entities, especially the Key
Key Distributor and endpoints. The details of this are outside the Distributor and endpoints. The details of this are outside the scope
scope of specification but a few possibilities are discussed in the of specification but a few possibilities are discussed in the
following sections. The key requirements is that endpoints can following sections. The key requirements is that endpoints can
verify they are connected to the correct Key Distributor for the verify they are connected to the correct Key Distributor for the
conference and the Key Distributor can verify the endpoints are the conference and the Key Distributor can verify the endpoints are the
correct endpoints for the conference. correct endpoints for the conference.
Two possible approaches to solve this are Identity Assertions and Two possible approaches to solve this are Identity Assertions and
Certificate Fingerprints. Certificate Fingerprints.
5.1. Identity Assertions 5.1. Identity Assertions
skipping to change at page 16, line 51 skipping to change at page 17, line 18
invaluable input on this document. Also, we would like to invaluable input on this document. Also, we would like to
acknowledge Nermeen Ismail for serving on the initial versions of acknowledge Nermeen Ismail for serving on the initial versions of
this document as a co-author. this document as a co-author.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-perc-double] [I-D.ietf-perc-double]
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Double Encryption Procedures", draft-ietf-perc-double-07 Double Encryption Procedures", draft-ietf-perc-double-08
(work in progress), September 2017. (work in progress), March 2018.
[I-D.ietf-perc-dtls-tunnel] [I-D.ietf-perc-dtls-tunnel]
Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
between a Media Distributor and Key Distributor to between a Media Distributor and Key Distributor to
Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-01 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-02
(work in progress), April 2017. (work in progress), October 2017.
[I-D.ietf-perc-srtp-ekt-diet] [I-D.ietf-perc-srtp-ekt-diet]
Jennings, C., Mattsson, J., McGrew, D., and D. Wing, Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
"Encrypted Key Transport for DTLS and Secure RTP", draft- Andreasen, "Encrypted Key Transport for DTLS and Secure
ietf-perc-srtp-ekt-diet-05 (work in progress), June 2017. RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress),
March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, <https://www.rfc- DOI 10.17487/RFC5764, May 2010,
editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, <https://www.rfc- DOI 10.17487/RFC6904, April 2013,
editor.org/info/rfc6904>. <https://www.rfc-editor.org/info/rfc6904>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-13 (work in progress), October 2017. rtcweb-security-arch-13 (work in progress), October 2017.
[I-D.roach-perc-webrtc]
Roach, A., "Using Privacy Enhanced Real-time Conferencing
(PERC) in a WebRTC Context", draft-roach-perc-webrtc-00
(work in progress), March 2017.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006, <https://www.rfc- DOI 10.17487/RFC4353, February 2006,
editor.org/info/rfc4353>. <https://www.rfc-editor.org/info/rfc4353>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, <https://www.rfc- DOI 10.17487/RFC4474, August 2006,
editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011, <https://www.rfc- DOI 10.17487/RFC6464, December 2011,
editor.org/info/rfc6464>. <https://www.rfc-editor.org/info/rfc6464>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015, <https://www.rfc- DOI 10.17487/RFC7667, November 2015,
editor.org/info/rfc7667>. <https://www.rfc-editor.org/info/rfc7667>.
Appendix A. PERC Key Inventory Appendix A. PERC Key Inventory
PERC specifies the use of a number of different keys and, PERC specifies the use of a number of different keys and,
understandably, it looks complicated or confusing on the surface. understandably, it looks complicated or confusing on the surface.
This section summarizes the various keys used in the system, how they This section summarizes the various keys used in the system, how they
are generated, and what purpose they serve. are generated, and what purpose they serve.
The keys are described in the order in which they would typically be The keys are described in the order in which they would typically be
acquired. acquired.
skipping to change at page 24, line 13 skipping to change at page 24, line 13
Email: paulej@packetizer.com Email: paulej@packetizer.com
David Benham David Benham
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: dbenham@cisco.com Email: dbenham@cisco.com
Christian Groves Christian Groves
Huawei Independent
Melbourne Melbourne
Australia Australia
Email: Christian.Groves@nteczone.com Email: Christian.Groves@nteczone.com
 End of changes. 38 change blocks. 
105 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/