--- 1/draft-ietf-perc-private-media-framework-09.txt 2019-04-30 22:13:11.906402826 -0700 +++ 2/draft-ietf-perc-private-media-framework-10.txt 2019-04-30 22:13:11.962404246 -0700 @@ -1,21 +1,21 @@ Network Working Group P. Jones Internet-Draft Cisco Intended status: Standards Track D. Benham -Expires: August 23, 2019 C. Groves +Expires: November 2, 2019 C. Groves Independent - February 19, 2019 + May 1, 2019 A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing - draft-ietf-perc-private-media-framework-09 + draft-ietf-perc-private-media-framework-10 Abstract This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distributors are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -80,21 +80,21 @@ 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17 6.5. Summary of Key Types and Entity Possession . . . . . . . 17 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20 8.2.2. Replay 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 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction @@ -165,21 +165,21 @@ for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP [RFC5764] in one-to-one calls). Media Distributor (MD): An RTP middlebox that forwards endpoint media 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 to E2E encryption keys. It operates according to the Selective Forwarding Middlebox RTP topologies [RFC7667] per the constraints defined by the PERC system, which includes, but not limited to, having no access to RTP media unencrypted and having limits on what - RTP header field it can alter. 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 Double cryptographic transform specification [I-D.ietf-perc-double] and chosen with respect to utility and the security considerations outlined in this document. Key Distributor: An entity that is a logical function which distributes keying material and related information to trusted endpoints and Media Distributor(s), only that which is appropriate for each. The Key Distributor might be co-resident with another entity trusted with E2E keying material. @@ -442,21 +442,22 @@ endpoints to reconstruct the original RTP header also enables the endpoints to authenticate RTP packets E2E. This design yields flexibility to the Media Distributor to change certain RTP header values as packets are forwarded. Which values the Media Distributor 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 the flexibility to forward RTCP content unchanged, transmit compound RTCP packets or to initiate RTCP packets for reporting statistics or conveying other information. Performing hop-by-hop authentication for all RTP and RTCP packets also helps provide replay protection - (see 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- by-hop, the endpoint derives an encryption key from the HBH SRTP master key to encrypt header extensions as per [RFC6904]. This still gives the Media Distributor visibility into header extensions, such as the one used to determine audio level [RFC6464] of conference participants. Note that when RTP header extensions are encrypted, all hops need to decrypt and re-encrypt these encrypted header extensions. @@ -866,44 +867,50 @@ | +- E2E Encrypted Portion E2E Authenticated Portion ---+| | | +--- HBH Encrypted Portion HBH Authenticated Portion ----+ Figure 6: Encrypted Media Packet Format 8. Security Considerations 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 encryption. The integrity protection mitigates packet modification and encryption makes selective blocking of packets harder, but not impossible. Off-path attackers could try connecting to different PERC entities and send specifically crafted packets. Endpoints and Media Distributors mitigate such an attack by performing hop-by-hop authentication and discarding packets that fail authentication. Another attack vector is a third party claiming to be a Media Distributor, fooling endpoints into sending packets to the false Media Distributor instead of the correct one. The deceived sending endpoints could incorrectly assume their packets have been delivered 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 confidential information, since the false Media Distributor would not have access to either HBH or E2E encryption keys. - If mutual DTLS authentication is not employed, a false Media - Distributor could cascade to another legitimate Media Distributor - that is part of a larger conference. However, this scenario will - also produce no positive results for the false Media Distributor - since it would not have access to keying material. + Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures + that a false endpoint or false Media Distributor cannot interact with + a legitimate Media Distributor or endpoint. While confidentiality + would not be compromised by failing to implement mutual + 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 bogus or replayed packets toward receiving devices that ultimately degrade conference or device performance. Therefore, implementations might wish to devise mechanisms to safeguard against such illegitimate packets, such as utilizing rate-limiting or performing basic sanity-checks on packets (e.g., looking at packet length or expected sequence number ranges) before performing more expensive decryption operations. @@ -937,42 +944,51 @@ rate-limiting packets might help reduce the impact of such attacks. 8.2.2. Replay Attack 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 example, allow a Media Distributor to transmit a sequence of packets identified as a user saying "yes", instead of the "no" the user actually said. - The mitigation for a replay attack is to implement replay protection - as described in Section 3.3.2 of [RFC3711]. End-to-end replay - protection MUST be provided for the whole duration of the conference. + A replay attack is mitigated by the requirement to implement replay + protection as described in Section 3.3.2 of [RFC3711]. End-to-end + replay protection MUST be provided for the duration of the + conference. 8.2.3. Delayed Playout Attack - The delayed playout attack is a variant of the replay attack. This - attack is possible even if E2E replay protection is in place. + A delayed playout attack is one where media is received and held by a + 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 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 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 while. Within the window from last packet forwarded to the receiver and the latest received by the Media Distributor, the Media Distributor can select an arbitrary starting point when resuming forwarding packets. Thus what the media source said can be substantially delayed at the receiver with the receiver believing that it is what was said just 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 A splicing attack is an attack where a Media Distributor receiving multiple media sources splices one media stream into the other. If the Media Distributor were able to change the SSRC without the receiver having any method for verifying the original source ID, then the Media Distributor could first deliver stream A and then later forward stream B under the same SSRC as stream A was previously using. By including the SSRC in the integrity check for each packet, both HBH and E2E, PERC prevents splicing attacks. @@ -1038,22 +1054,22 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [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-04 - (work in progress), October 2018. + Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 + (work in progress), April 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, .