--- 1/draft-ietf-perc-private-media-framework-06.txt 2018-09-03 22:13:26.845449050 -0700 +++ 2/draft-ietf-perc-private-media-framework-07.txt 2018-09-03 22:13:26.897450312 -0700 @@ -1,21 +1,21 @@ Network Working Group P. Jones -Internet-Draft D. Benham -Intended status: Standards Track Cisco -Expires: September 6, 2018 C. Groves +Internet-Draft Cisco +Intended status: Standards Track D. Benham +Expires: March 8, 2019 C. Groves Independent - March 5, 2018 + September 4, 2018 A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing - draft-ietf-perc-private-media-framework-06 + draft-ietf-perc-private-media-framework-07 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 September 6, 2018. + This Internet-Draft will expire on March 8, 2019. Copyright Notice Copyright (c) 2018 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 @@ -78,21 +78,21 @@ 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 16 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 9.2. Informative References . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 19 A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 20 A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20 A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21 A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21 Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction @@ -364,21 +364,22 @@ # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # # | | # # | | # # *--------- E2E Key (A) E2E Key (A) ---------* # # | *------- E2E Key (B) E2E Key (B) -------* | # # | | # # | | # # | v # # | v # +-------------+ +-------------+ | Endpoint A | | Endpoint B | +-------------+ +-------------+ - E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets + Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP + Packets The PERC Double transform [I-D.ietf-perc-double] enables endpoints to perform encryption using both the E2E and HBH contexts while still preserving the same overall interface as other SRTP transforms. The Media Distributor simply uses the corresponding normal (single) AES- GCM transform, keyed with the appropriate HBH keys. See Appendix A for a description of the keys used in PERC and Appendix B for an overview of how the packet appears on the wire. RTCP can only be encrypted hop-by-hop, not end-to-end. This @@ -490,21 +491,21 @@ +-----------+ # ^ ^ # # | | #--- Tunnel # | | # +-----------+ +-----------+ +-----------+ | Endpoint | DTLS | Media | DTLS | Endpoint | | KEK |<------------|Distributor|------------>| KEK | | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | +-----------+ +-----------+ +-----------+ - Figure 2: Exchanging Key Information Between Entities + Figure 3: Exchanging Key Information Between Entities Endpoints will establish a DTLS-SRTP [RFC5764] association over the RTP session's media ports for the purposes of key information exchange with the Key Distributor. The Media Distributor will not terminate the DTLS signaling, but will instead forward DTLS packets received from an endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. This tunnel is used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key information from the Key Distributor to the Media @@ -758,73 +759,67 @@ invaluable input on this document. Also, we would like to acknowledge Nermeen Ismail for serving on the initial versions of this document as a co-author. 9. References 9.1. Normative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP - Double Encryption Procedures", draft-ietf-perc-double-08 - (work in progress), March 2018. + Double Encryption Procedures", draft-ietf-perc-double-09 + (work in progress), May 2018. [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-02 - (work in progress), October 2017. + Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-03 + (work in progress), April 2018. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure - RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress), - March 2018. + RTP", draft-ietf-perc-srtp-ekt-diet-08 (work in progress), + July 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer - Security (DTLS) Extension to Establish Keys for the Secure - Real-time Transport Protocol (SRTP)", RFC 5764, - DOI 10.17487/RFC5764, May 2010, - . - [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . 9.2. Informative References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-13 (work in progress), October 2017. + rtcweb-security-arch-15 (work in progress), July 2018. [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, . + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . + [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, . @@ -832,55 +827,61 @@ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + . + [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Appendix A. PERC Key Inventory PERC specifies the use of a number of different keys and, understandably, it looks complicated or confusing on the surface. This section summarizes the various keys used in the system, how they are generated, and what purpose they serve. The keys are described in the order in which they would typically be acquired. - The various keys used in PERC are shown in Figure 3 below. + The various keys used in PERC are shown in Figure 4 below. +-----------+----------------------------------------------------+ | Key | Description | +-----------+----------------------------------------------------+ | KEK | Key shared by all endpoints and used to encrypt | | (EKT Key) | each endpoint's SRTP master key so receiving | | | endpoints can decrypt media. | +-----------+----------------------------------------------------+ | HBH Key | Key used to encrypt media hop-by-hop. | +-----------+----------------------------------------------------+ | E2E Key | Key used to encrypt media end-to-end. | +-----------+----------------------------------------------------+ - Figure 3: Key Inventory + Figure 4: Key Inventory As you can see, the number key types is very small. However, what can be challenging is keeping track of all of the distinct E2E keys as the conference grows in size. With 1,000 participants in a conference, there will be 1,000 distinct SRTP master keys, all of which share the same master salt. Each of those keys are passed through the KDF defined in [RFC3711] to produce the actual encryption and authentication keys. Complicating key management is the fact that the KEK can change and, when it does, the endpoints generate new SRTP master keys. And, of course, there is a new SRTP master salt to @@ -994,41 +995,41 @@ Every HBH key is distinct for a given endpoint, thus Endpoint A and endpoint B do not have knowledge of the other's HBH key. Each endpoint generates its own E2E Key (SRTP master key), thus the key distinct per endpoint. This key is transmitted (encrypted) via the EKT Field to other endpoints. Endpoints that receive media from a given transmitting endpoint will therefore have knowledge of the transmitter's E2E key. To summarize the various keys and which entity is in possession of a - given key, refer to Figure 4. + given key, refer to Figure 5. +----------------------+------------+-------+-------+------------+ | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | +----------------------+------------+-------+-------+------------+ | KEK | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | E2E Key (A and B) | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | HBH Key (A<=>MD X) | Yes | Yes | No | No | +----------------------+------------+-------+-------+------------+ | HBH Key (B<=>MD Y) | No | No | Yes | Yes | +----------------------+------------+---------------+------------+ | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | +----------------------+------------+---------------+------------+ - Figure 4: Keys per Entity + Figure 5: Keys per Entity Appendix B. PERC Packet Format - Figure 5 presents a complete picture of what a PERC packet looks like + Figure 6 presents a complete picture of what a PERC packet looks like when transmitted over the wire. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | synchronization source (SSRC) identifier | @@ -1046,36 +1047,33 @@ R : : R : EKT Field : R : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C = Ciphertext (encrypted and authenticated) A = Associated Data (authenticated only) R = neither encrypted nor authenticated, added after Authenticated Encryption completed - Figure 5: PERC Packet Format + Figure 6: PERC Packet Format Authors' Addresses Paul E. Jones Cisco 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com - David Benham - Cisco - 170 West Tasman Drive - San Jose, California 95134 - USA - Email: dbenham@cisco.com + David Benham + Independent + Email: dabenham@gmail.com Christian Groves Independent Melbourne Australia Email: Christian.Groves@nteczone.com