draft-ietf-perc-private-media-framework-02.txt   draft-ietf-perc-private-media-framework-03.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 4, 2017 C. Groves Expires: September 14, 2017 C. Groves
Huawei Huawei
October 31, 2016 March 13, 2017
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-02 draft-ietf-perc-private-media-framework-03
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
distribution devices are not trusted with the end-to-end media distribution devices are not trusted with the end-to-end media
encryption keys. The solution aims to build upon existing security encryption keys. The solution aims to build upon existing security
mechanisms defined for the real-time transport protocol (RTP). mechanisms defined for the real-time transport protocol (RTP).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://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 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 4 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 4
3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5
3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 5 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 5
3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6
3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . 7 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 7
4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 8 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 8
4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9
4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 9 4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 9
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 . . . . . . 10
4.5.2. Key Exchange during a Conference . . . . . . . . . . 11 4.5.2. Key Exchange during a Conference . . . . . . . . . . 11
5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12
5.2. Certificate Fingerprints in Session Signaling . . . . . . 12 5.2. Certificate Fingerprints in Session Signaling . . . . . . 13
5.3. Conferences Identification . . . . . . . . . . . . . . . 13 5.3. Conferences Identification . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 13 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14
6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14
6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14
6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15
6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 4, line 11 skipping to change at page 4, line 11
Additionally, this solution framework uses the following conventions, Additionally, this solution framework uses the following conventions,
terms and acronyms: terms and acronyms:
End-to-End (E2E): Communications from one endpoint through one or End-to-End (E2E): Communications from one endpoint through one or
more Media Distribution Devices to the endpoint at the other end. more Media Distribution Devices to the endpoint at the other end.
Hop-by-Hop (HBH): Communications between an endpoint and a Media Hop-by-Hop (HBH): Communications between an endpoint and a Media
Distribution Device or between Media Distribution Devices. Distribution Device or between Media Distribution Devices.
Endpoint: An RTP flow terminating entity that has possession of E2E Trusted Endpoint: An RTP flow terminating entity that has possession
media encryption keys and terminates E2E encryption. This may of E2E media encryption keys and terminates E2E encryption. This may
include embedded user conferencing equipment or browsers on include embedded user conferencing equipment or browsers on
computers, media gateways, MCUs, media recording device and more that computers, media gateways, MCUs, media recording device and more that
are in the trusted domain for a given deployment. are in the trusted domain for a given deployment.
Media Distributor (MD): An RTP middlebox that is not allowed to to Media Distributor (MD): An RTP middlebox that is not allowed to to
have access to E2E encryption keys. It operates according to the have access to E2E encryption keys. It operates according to the
Selective Forwarding Middlebox RTP topologies Selective Forwarding Middlebox RTP topologies
[I-D.ietf-avtcore-rtp-topologies-update] per the constraints defined [I-D.ietf-avtcore-rtp-topologies-update] per the constraints defined
by the PERC system, which includes, but not limited to, having no by the PERC system, which includes, but not limited to, having no
access to RTP media unencrypted and having limits on what RTP header access to RTP media unencrypted and having limits on what RTP header
field it can alter. field it can alter.
Key Distributor: An entity that is a logical function which passes Key Distributor: An entity that is a logical function which
keying material and related information to endpoints and Media distributes keying material and related information to trusted
Distributor(s) that is appropriate for each. The Key Distributor endpoints and Media Distributor(s), only that which is appropriate
might be co-resident with another entity trusted with E2E keying for each. The Key Distributor might be co-resident with another
material. entity trusted with E2E keying material.
Conference: Two or more participants communicating via trusted Conference: Two or more participants communicating via trusted
endpoints to exchange RTP flows through one or more Media endpoints to exchange RTP flows through one or more Media
Distributor. Distributor.
Call Processing: All trusted endpoints in the conference connect to
it by a call processing dialog, such as with the Focus defined in the
Framework for Conferencing with SIP [RFC4353].
Third Party: Any entity that is not an Endpoint, Media Distributor, Third Party: Any entity that is not an Endpoint, Media Distributor,
Key Distributor or Call Processing entity as described in this Key Distributor or Call Processing entity as described in this
document. document.
3. PERC Entities and Trust Model 3. PERC Entities and Trust Model
The following figure depicts the trust relationships, direct or The following figure depicts the trust relationships, direct or
indirect, between entities described in the subsequent sub-sections. indirect, between entities described in the subsequent sub-sections.
Note that these entities may be co-located or further divided into Note that these entities may be co-located or further divided into
multiple, separate physical devices. multiple, separate physical devices.
skipping to change at page 6, line 5 skipping to change at page 6, line 11
messaging between the endpoints and the Key Distributor and will messaging between the endpoints and the Key Distributor and will
acquire per-hop key information from the Key Distributor. The actual acquire per-hop key information from the Key Distributor. The actual
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, it is untrusted to have access to the E2E media encryption keys,
which this framework's key exchange mechanisms will prevent. which this framework's key exchange mechanisms will prevent.
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. authorized. Trusted endpoint authorization is described in
[I-D.ietf-roach-perc-webrtc].
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. pre-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.
3.1.2. Call Processing 3.1.2. Call Processing
The call processing function is untrusted in the simple, general The call processing function is untrusted in the simple, general
deployment scenario. When a physical subset of the call processing deployment scenario. When a physical subset of the call processing
skipping to change at page 6, line 51 skipping to change at page 7, line 14
3.2.1. Endpoint 3.2.1. Endpoint
An endpoint is considered trusted and will have access to E2E key An endpoint is considered trusted and will have access to E2E key
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., pre-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 collocated with an endpoint or
exist standalone, is responsible for providing key information to exist standalone, is responsible for providing key information to
endpoints for both end-to-end and hop-by-hop security and for endpoints for both end-to-end and hop-by-hop security and for
providing key information to Media Distributors for the hop-by-hop providing key 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
skipping to change at page 9, line 5 skipping to change at page 9, line 9
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,
endpoints will make use of a common Key Encryption Key (KEK) that is endpoints will make use of a common Key Encryption Key (KEK) that is
known only by the trusted entities in a conference. That KEK, 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 EKTKey, defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKTKey,
will be used to subsequently encrypt SRTP master keys used for E2E will be used to subsequently encrypt SRTP master keys used for E2E
authenticated encryption (E2E Key(i); i={a given endpoint}) of media authenticated encryption (E2E Key(i); i={a given endpoint}) of media
sent by a given endpoint. sent by a given endpoint.
+---------------------+------------+-------+-------+------------+ +----------------------+------------+-------+-------+------------+
| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |
+---------------------+------------+-------+-------+------------+ +----------------------+------------+-------+-------+------------+
| KEK | Yes | No | No | Yes | | KEK | Yes | No | No | Yes |
+---------------------+------------+-------+-------+------------+ +----------------------+------------+-------+-------+------------+
| E2E Key (i) | Yes | No | No | Yes | | E2E Key (i) | Yes | No | No | Yes |
+---------------------+------------+-------+-------+------------+ +----------------------+------------+-------+-------+------------+
| HBH Key (A<=>MD X) | Yes | Yes | No | No | | HBH Key (A<=>MD X) | Yes | Yes | No | No |
+---------------------+------------+-------+-------+------------+ +----------------------+------------+-------+-------+------------+
| HBH Key (B<=>MD Y) | No | No | Yes | Yes | | HBH Key (B<=>MD Y) | No | No | Yes | Yes |
+---------------------+------------+---------------+------------+ +----------------------+------------+---------------+------------+
| HBH Key (MD X<=>MD Y)| No | Yes | Yes | No |
+----------------------+------------+---------------+------------+
Figure 2: Keys per Entity Figure 2: Keys per Entity
4.3. E2E Keys and Endpoint Operations 4.3. E2E Keys and Endpoint Operations
Any given RTP media flow can be identified by its SSRC, and endpoints Any given RTP media flow can be identified by its SSRC, and endpoints
might send more than one at a time and change the mix of media flows might send more than one at a time and change the mix of media flows
transmitted during the life of a conference. transmitted during the life of a conference.
Thus, endpoints MUST maintain a list of SSRCs from received RTP flows Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
skipping to change at page 10, line 29 skipping to change at page 10, line 35
and re-encrypt these encrypted header extensions. and re-encrypt these encrypted header extensions.
4.5. Key Exchange 4.5. Key Exchange
To facilitate key exchange required to establish or generate an E2E 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 key and a HBH key for an endpoint and the same HBH key for the Media
Distributor, this framework utilizes a DTLS-SRTP [RFC5764] Distributor, this framework utilizes a DTLS-SRTP [RFC5764]
association between an endpoint and the Key Distributor. To association between an endpoint and the Key Distributor. To
establish this association, an endpoint will send DTLS-SRTP messages establish this association, an endpoint will send DTLS-SRTP messages
to the Media Distributor which will then forward them to the Key to the Media Distributor which will then forward them to the Key
Distributor as defined in [I-D.jones-perc-dtls-tunnel]. 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 Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key
Distributor over the DTLS association to endpoints via procedures Distributor over the DTLS association to endpoints via procedures
defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet]. defined in PERC EKT [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 HBH keys for transmitting RTP and RTCP Distributor to establish HBH keys 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 HBH keys for use between Media Distributors. facilitate establishing HBH keys for use between Media Distributors.
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 procedures defined in DTLS Tunnel for PERC
[I-D.jones-perc-dtls-tunnel] establish one or more TLS tunnels [I-D.ietf-perc-dtls-tunnel] establish one or more TLS tunnels between
between the Media Distributor and Key Distributor, making it is the Media Distributor and Key Distributor, making it is possible for
possible for the Media Distributor to facilitate the establishment of the Media Distributor to facilitate the establishment of a secure
a secure DTLS association between each endpoint and the Key DTLS association between each endpoint and the Key Distributor as
Distributor as shown the following figure. The DTLS association shown the following figure. The DTLS association between endpoints
between endpoints and the Key Distributor will enable each endpoint and the Key Distributor will enable each endpoint to receive E2E key
to receive E2E key information, Key Encryption Key (KEK) information information, Key Encryption Key (KEK) information (i.e., EKTKey), and
(i.e., EKTKey), and HBH key information. At the same time, the Key HBH key information. At the same time, the Key Distributor can
Distributor can securely provide the HBH key information to the Media securely provide the HBH key information to the Media Distributor.
Distributor. The key information summarized here may include the The key information summarized here may include the SRTP master key,
SRTP master key, SRTP master salt, and the negotiated cryptographic SRTP master salt, and the negotiated cryptographic transform.
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 # | | #-TLS Tunnel
# | | # # | | #
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Endpoint | DTLS | Media | DTLS | Endpoint | | Endpoint | DTLS | Media | DTLS | Endpoint |
skipping to change at page 13, line 10 skipping to change at page 13, line 18
untrusted in the PERC framework. However, there are some deployment untrusted in the PERC framework. However, there are some deployment
scenarios where parts of the session signaling may be assumed scenarios where parts of the session signaling may be assumed
trustworthy for the purposes of exchanging, in a manner that can be trustworthy for the purposes of exchanging, in a manner that can be
authenticated, the fingerprint of an entity's certificate. authenticated, the fingerprint of an entity's certificate.
As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to
convey the fingerprint information per [RFC5763]. An endpoint's SIP convey the fingerprint information per [RFC5763]. An endpoint's SIP
User Agent would send an INVITE message containing SDP for the media User Agent would send an INVITE message containing SDP for the media
session along with the endpoint's certificate fingerprint, which can session along with the endpoint's certificate fingerprint, which can
be signed using the procedures described in [RFC4474] for the benefit be signed using the procedures described in [RFC4474] for the benefit
of forwarding the message to other entities. Other entities can now of forwarding the message to other entities by the Focus [RFC4353].
verify the fingerprints match the certificates found in the DTLS-SRTP Other entities can now verify the fingerprints match the certificates
connections to find the identity of the far end of the DTLS-SRTP found in the DTLS-SRTP connections to find the identity of the far
connection and check that is the authorized entity. end of the DTLS-SRTP connection and check that is the authorized
entity.
Ultimately, if using session signaling, an endpoint's certificate Ultimately, if using session signaling, an endpoint's certificate
fingerprint would need to be securely mapped to a user and conveyed 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 to the Key Distributor so that it can check that that user is
authorized. Similarly, the Key Distributor's certificate fingerprint authorized. Similarly, the Key Distributor's certificate fingerprint
can be conveyed to endpoint in a manner that can be authenticated as can be conveyed to endpoint in a manner that can be authenticated as
being an authorized Key Distributor for this conference. being an authorized Key Distributor for this conference.
5.3. Conferences Identification 5.3. Conferences Identification
The Key Distributor is responsible for knowing what endpoints are The Key Distributor needs to know what endpoints are being added to a
allowed in a given conference. Thus, the Key Distributor and the given conference. Thus, the Key Distributor and the Media
Media Distributor will need to know endpoint-to-conference mappings, Distributor will need to know endpoint-to-conference mappings, which
which is enabled by exchanging a conference-specific unique is enabled by exchanging a conference-specific unique identifier as
identifier as defined in [I-D.jones-perc-dtls-tunnel]. How this defined in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier
unique identifier is assigned is outside the scope of this document. is assigned is outside the scope of this document.
6. Security Considerations 6. Security Considerations
This framework, and the individual protocols defined to support it, This framework, and the individual protocols defined to support it,
must take care to not increase the exposure to Denial of Service must take care to not increase the exposure to Denial of Service
(DoS) attacks by untrusted or third-party entities and should take (DoS) attacks by untrusted or third-party entities and should take
measures to mitigate, where possible, more serious DoS attacks from measures to mitigate, where possible, more serious DoS attacks from
on-path and off-path attackers. on-path and off-path attackers.
The following section enumerates the kind of attacks that will be The following section enumerates the kind of attacks that will be
skipping to change at page 16, line 18 skipping to change at page 16, line 27
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., and A. Roach, "SRTP Double Jennings, C., Jones, P., and A. Roach, "SRTP Double
Encryption Procedures", draft-ietf-perc-double-01 (work in Encryption Procedures", draft-ietf-perc-double-02 (work in
progress), July 2016. progress), October 2016.
[I-D.ietf-perc-dtls-tunnel]
Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
between a Media Distributor and Key Distributor to
Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00
(work in progress), March 2017.
[I-D.ietf-perc-srtp-ekt-diet] [I-D.ietf-perc-srtp-ekt-diet]
Mattsson, J., McGrew, D., Wing, D., and C. Jennings, Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
"Encrypted Key Transport for Secure RTP", draft-ietf-perc- "Encrypted Key Transport for Secure RTP", draft-ietf-perc-
srtp-ekt-diet-01 (work in progress), July 2016. srtp-ekt-diet-02 (work in progress), October 2016.
[I-D.jones-perc-dtls-tunnel]
Jones, P., "A DTLS Tunnel between Media Distributor and
Key Distributor to Facilitate Key Exchange", draft-jones-
perc-dtls-tunnel-03 (work in progress), July 2016.
[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/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://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,
<http://www.rfc-editor.org/info/rfc3711>. <http://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
DOI 10.17487/RFC5764, May 2010, 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://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
DOI 10.17487/RFC6904, April 2013, 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015. July 2015.
[I-D.ietf-roach-perc-webrtc]
Roach, A., "Using Privacy Enhanced Real-time Conferencing
(PERC) in a WebRTC Context", March 2017.
[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-12 (work in progress), June 2016. rtcweb-security-arch-12 (work in progress), June 2016.
[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, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, DOI
10.17487/RFC4353, February 2006,
<http://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/
DOI 10.17487/RFC4474, August 2006, RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>. <http://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, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://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, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://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/
DOI 10.17487/RFC6464, December 2011, RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>. <http://www.rfc-editor.org/info/rfc6464>.
Authors' Addresses Authors' Addresses
Paul E. Jones Paul E. Jones
Cisco Cisco
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
USA USA
 End of changes. 30 change blocks. 
72 lines changed or deleted 89 lines changed or added

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