draft-ietf-perc-private-media-framework-09.txt   draft-ietf-perc-private-media-framework-10.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track D. Benham Intended status: Standards Track D. Benham
Expires: August 23, 2019 C. Groves Expires: November 2, 2019 C. Groves
Independent Independent
February 19, 2019 May 1, 2019
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-09 draft-ietf-perc-private-media-framework-10
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).
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 https://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 August 23, 2019. This Internet-Draft will expire on November 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16
6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17
6.5. Summary of Key Types and Entity Possession . . . . . . . 17 6.5. Summary of Key Types and Entity Possession . . . . . . . 17
7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19
8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20
8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20
8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 21 8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 21
8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21
8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 21 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 22
8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 22 8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
skipping to change at page 4, line 33 skipping to change at page 4, line 33
for purposes of this framework (just as it acts as the endpoint for for purposes of this framework (just as it acts as the endpoint for
DTLS-SRTP [RFC5764] in one-to-one calls). DTLS-SRTP [RFC5764] in one-to-one calls).
Media Distributor (MD): An RTP middlebox that forwards endpoint media Media Distributor (MD): An RTP middlebox that forwards endpoint media
content (e.g., voice or video data) unaltered, either a subset or all content (e.g., voice or video data) unaltered, either a subset or all
of the flows at any given time, and is never allowed to have access of the flows at any given time, and is never allowed to have access
to E2E encryption keys. It operates according to the Selective to E2E encryption keys. It operates according to the Selective
Forwarding Middlebox RTP topologies [RFC7667] per the constraints Forwarding Middlebox RTP topologies [RFC7667] per the constraints
defined by the PERC system, which includes, but not limited to, defined by the PERC system, which includes, but not limited to,
having no access to RTP media unencrypted and having limits on what having no access to RTP media unencrypted and having limits on what
RTP header field it can alter. This header fields that may be RTP header field it can alter. The header fields that may be
modified by a Media Distributor are enumerated in Section 4 of the modified by a Media Distributor are enumerated in Section 4 of the
Double cryptographic transform specification [I-D.ietf-perc-double] Double cryptographic transform specification [I-D.ietf-perc-double]
and chosen with respect to utility and the security considerations and chosen with respect to utility and the security considerations
outlined in this document. outlined in this document.
Key Distributor: An entity that is a logical function which Key Distributor: An entity that is a logical function which
distributes keying material and related information to trusted distributes keying material and related information to trusted
endpoints and Media Distributor(s), only that which is appropriate endpoints and Media Distributor(s), only that which is appropriate
for each. The Key Distributor might be co-resident with another for each. The Key Distributor might be co-resident with another
entity trusted with E2E keying material. entity trusted with E2E keying material.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
endpoints to reconstruct the original RTP header also enables the endpoints to reconstruct the original RTP header also enables the
endpoints to authenticate RTP packets E2E. This design yields endpoints to authenticate RTP packets E2E. This design yields
flexibility to the Media Distributor to change certain RTP header flexibility to the Media Distributor to change certain RTP header
values as packets are forwarded. Which values the Media Distributor values as packets are forwarded. Which values the Media Distributor
can change in the RTP header are defined in [I-D.ietf-perc-double]. can change in the RTP header are defined in [I-D.ietf-perc-double].
RTCP can only be encrypted hop-by-hop, giving the Media Distributor RTCP can only be encrypted hop-by-hop, giving the Media Distributor
the flexibility to forward RTCP content unchanged, transmit compound the flexibility to forward RTCP content unchanged, transmit compound
RTCP packets or to initiate RTCP packets for reporting statistics or RTCP packets or to initiate RTCP packets for reporting statistics or
conveying other information. Performing hop-by-hop authentication conveying other information. Performing hop-by-hop authentication
for all RTP and RTCP packets also helps provide replay protection for all RTP and RTCP packets also helps provide replay protection
(see Section 8). (see Section 8). The use of the replay protection mechanism
specified in Section 3.3.2 of [RFC3711] is REQUIRED at each hop.
If there is a need to encrypt one or more RTP header extensions hop- If there is a need to encrypt one or more RTP header extensions hop-
by-hop, the endpoint derives an encryption key from the HBH SRTP by-hop, the endpoint derives an encryption key from the HBH SRTP
master key to encrypt header extensions as per [RFC6904]. This still master key to encrypt header extensions as per [RFC6904]. This still
gives the Media Distributor visibility into header extensions, such gives the Media Distributor visibility into header extensions, such
as the one used to determine audio level [RFC6464] of conference as 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 need to decrypt and re-encrypt these encrypted header all hops need to decrypt and re-encrypt these encrypted header
extensions. extensions.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
| +- E2E Encrypted Portion E2E Authenticated Portion ---+| | +- E2E Encrypted Portion E2E Authenticated Portion ---+|
| | | |
+--- HBH Encrypted Portion HBH Authenticated Portion ----+ +--- HBH Encrypted Portion HBH Authenticated Portion ----+
Figure 6: Encrypted Media Packet Format Figure 6: Encrypted Media Packet Format
8. Security Considerations 8. Security Considerations
8.1. Third Party Attacks 8.1. Third Party Attacks
Third party attacks are attacks attempted by an adversary that is not
supposed to have access to keying material or is otherwise not an
authorized participant in the conference.
On-path attacks are mitigated by hop-by-hop integrity protection and On-path attacks are mitigated by hop-by-hop integrity protection and
encryption. The integrity protection mitigates packet modification encryption. The integrity protection mitigates packet modification
and encryption makes selective blocking of packets harder, but not and encryption makes selective blocking of packets harder, but not
impossible. impossible.
Off-path attackers could try connecting to different PERC entities Off-path attackers could try connecting to different PERC entities
and send specifically crafted packets. Endpoints and Media and send specifically crafted packets. Endpoints and Media
Distributors mitigate such an attack by performing hop-by-hop Distributors mitigate such an attack by performing hop-by-hop
authentication and discarding packets that fail authentication. authentication and discarding packets that fail authentication.
Another attack vector is a third party claiming to be a Media Another attack vector is a third party claiming to be a Media
Distributor, fooling endpoints into sending packets to the false Distributor, fooling endpoints into sending packets to the false
Media Distributor instead of the correct one. The deceived sending Media Distributor instead of the correct one. The deceived sending
endpoints could incorrectly assume their packets have been delivered endpoints could incorrectly assume their packets have been delivered
to endpoints when they in fact have not. While this attack is to endpoints when they in fact have not. While this attack is
possible, the result is a simple denial of service with no leakage of possible, the result is a simple denial of service with no leakage of
confidential information, since the false Media Distributor would not confidential information, since the false Media Distributor would not
have access to either HBH or E2E encryption keys. have access to either HBH or E2E encryption keys.
If mutual DTLS authentication is not employed, a false Media Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures
Distributor could cascade to another legitimate Media Distributor that a false endpoint or false Media Distributor cannot interact with
that is part of a larger conference. However, this scenario will a legitimate Media Distributor or endpoint. While confidentiality
also produce no positive results for the false Media Distributor would not be compromised by failing to implement mutual
since it would not have access to keying material. authentication, employing it helps mitigate against denial of service
attacks wherein a false entity sends a stream of packets that the
would force a legitimate entity to spend time attempting to decrypt.
A third party could cause a denial-of-service by transmitting many A third party could cause a denial-of-service by transmitting many
bogus or replayed packets toward receiving devices that ultimately bogus or replayed packets toward receiving devices that ultimately
degrade conference or device performance. Therefore, implementations degrade conference or device performance. Therefore, implementations
might wish to devise mechanisms to safeguard against such might wish to devise mechanisms to safeguard against such
illegitimate packets, such as utilizing rate-limiting or performing illegitimate packets, such as utilizing rate-limiting or performing
basic sanity-checks on packets (e.g., looking at packet length or basic sanity-checks on packets (e.g., looking at packet length or
expected sequence number ranges) before performing more expensive expected sequence number ranges) before performing more expensive
decryption operations. decryption operations.
skipping to change at page 21, line 20 skipping to change at page 21, line 25
rate-limiting packets might help reduce the impact of such attacks. rate-limiting packets might help reduce the impact of such attacks.
8.2.2. Replay Attack 8.2.2. Replay Attack
A replay attack is when an already received packet from a previous A replay attack is when an already received packet from a previous
point in the RTP stream is replayed as new packet. This could, for point in the RTP stream is replayed as new packet. This could, for
example, allow a Media Distributor to transmit a sequence of packets example, allow a Media Distributor to transmit a sequence of packets
identified as a user saying "yes", instead of the "no" the user identified as a user saying "yes", instead of the "no" the user
actually said. actually said.
The mitigation for a replay attack is to implement replay protection A replay attack is mitigated by the requirement to implement replay
as described in Section 3.3.2 of [RFC3711]. End-to-end replay protection as described in Section 3.3.2 of [RFC3711]. End-to-end
protection MUST be provided for the whole duration of the conference. replay protection MUST be provided for the duration of the
conference.
8.2.3. Delayed Playout Attack 8.2.3. Delayed Playout Attack
The delayed playout attack is a variant of the replay attack. This A delayed playout attack is one where media is received and held by a
attack is possible even if E2E replay protection is in place. media distributor and then forwarded to endpoints at a later point in
time.
This attack is possible even if E2E replay protection is in place.
However, due to fact that the Media Distributor is allowed to select However, due to fact that the Media Distributor is allowed to select
a subset of streams and not forward the rest to a receiver, such as a subset of streams and not forward the rest to a receiver, such as
in forwarding only the most active speakers, the receiver has to in forwarding only the most active speakers, the receiver has to
accept gaps in the E2E packet sequence. The issue with this is that accept gaps in the E2E packet sequence. The issue with this is that
a Media Distributor can select to not deliver a particular stream for a Media Distributor can select to not deliver a particular stream for
a while. a while.
Within the window from last packet forwarded to the receiver and the Within the window from last packet forwarded to the receiver and the
latest received by the Media Distributor, the Media Distributor can latest received by the Media Distributor, the Media Distributor can
select an arbitrary starting point when resuming forwarding packets. select an arbitrary starting point when resuming forwarding packets.
Thus what the media source said can be substantially delayed at the Thus what the media source said can be substantially delayed at the
receiver with the receiver believing that it is what was said just receiver with the receiver believing that it is what was said just
now, and only delayed due to transport delay. now, and only delayed due to transport delay.
While this attack cannot be eliminated entirely, its effectiveness
can be reduced by re-keying the conference periodically since
significantly-delayed media encrypted with expired keys would not be
decrypted by endpoints.
8.2.4. Splicing Attack 8.2.4. Splicing Attack
A splicing attack is an attack where a Media Distributor receiving A splicing attack is an attack where a Media Distributor receiving
multiple media sources splices one media stream into the other. If multiple media sources splices one media stream into the other. If
the Media Distributor were able to change the SSRC without the the Media Distributor were able to change the SSRC without the
receiver having any method for verifying the original source ID, then receiver having any method for verifying the original source ID, then
the Media Distributor could first deliver stream A and then later the Media Distributor could first deliver stream A and then later
forward stream B under the same SSRC as stream A was previously forward stream B under the same SSRC as stream A was previously
using. By including the SSRC in the integrity check for each packet, using. By including the SSRC in the integrity check for each packet,
both HBH and E2E, PERC prevents splicing attacks. both HBH and E2E, PERC prevents splicing attacks.
skipping to change at page 23, line 24 skipping to change at page 23, line 40
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[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-04 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05
(work in progress), October 2018. (work in progress), April 2019.
[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-18 (work in progress), February 2019. rtcweb-security-arch-18 (work in progress), February 2019.
[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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
 End of changes. 13 change blocks. 
19 lines changed or deleted 35 lines changed or added

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