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/ |