idnits 2.17.1 draft-murillo-perc-lite-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2020) is 1439 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-avtext-framemarking' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC3711' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC5764' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC6904' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC7714' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-perc-private-media-framework' is defined on line 235, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-avtext-framemarking-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-avtext-framemarking (ref. 'I-D.ietf-avtext-framemarking') Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Garcia Murillo, Ed. 3 Internet-Draft A. Gouaillard, Ed. 4 Expires: November 13, 2020 CoSMo Software Consulting, Pte Ltd 5 May 12, 2020 7 End to End Media Encryption Procedures 8 draft-murillo-perc-lite-01 10 Abstract 12 In some conferencing scenarios, it is desirable for an intermediary 13 to be able to manipulate some RTP parameters, while still providing 14 strong end-to-end security guarantees. This document defines a 15 procedure to perform end to end media authenticated encryption. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 13, 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Procedures at the Media Sender . . . . . . . . . . . . . . . 3 55 5. Procedures at the Media Distributor . . . . . . . . . . . . . 4 56 6. Procedures at the Media Receiver . . . . . . . . . . . . . . 4 57 7. Payload Encryption Header . . . . . . . . . . . . . . . . . . 4 58 8. RTX/RED/FEC procedures . . . . . . . . . . . . . . . . . . . 5 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 9.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 63 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 RTP-based real-time multi-party interactive media conferencing is in 69 widespread use today. Many of the deployments use one or more 70 centrally located media distribution devices that perform selective 71 forwarding of mixed-media streams received from the participating 72 endpoints. 74 These conferences require security to ensure that the RTP media and 75 related metadata of the conference is kept private and only available 76 to the set of invited participants and other devices trusted by those 77 participants with their media. At the same time, multi-party media 78 conferences need source authentication and integrity checks to 79 protect against modifications, insertions, and replay attacks. 81 To date, deployment models for these multi-party media distribution 82 devices do not enable the devices to perform their functions without 83 having keys to decrypt the participants' media. This trust model has 84 limitations and prevents or hampers deployment of secure RTP 85 conferencing in a multitude of cases, including outsourcing, legal 86 requirements on confidentiality, and utilization of virtualized 87 servers. 89 This specification defines an End to End Media Encryption procedure, 90 so the media distribution devices can perform their media 91 distribution function but without having access to the participant 92 media, while focusing on introducing the minimun amount of changes on 93 both the endpoints and the media distributor. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14, RFC 2119 100 [RFC2119]. 102 3. Overview 104 In order to prevent the Media Distributor (MD) to access the contents 105 of the media passing through the system, the RTP media payload will 106 be encrypted using SRTP, that will provide encryption, message 107 authentication and integrity, and replay protection. The RECOMMENDED 108 cipher to be used is AES-GCM. 110 All the participants on the conference will share a media encryption/ 111 decryption key. How to distribute the shared key to all the 112 participants of the conference is out of scope of this draft. 114 The encrypted media payload will be self-contained, so it can be 115 decrypted by the media receiver side, regardless any RTP 116 transformation done by the intermediary hosts. 118 4. Procedures at the Media Sender 120 The Media Sender will encode the media streams and packetize the 121 encoded stream into RTP packets according to the codec specific 122 specifications. Once done, the RTP payload will be replaced with an 123 encrypted version of the media payload, prepending the required 124 information for decrypting it. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | RTP Header | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Payload Encryption Header | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Payload Encryption Header (cont) | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 135 | Payload Encrypted media data | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 RTP packet with E2E encrypted Media pPyload 140 As the payload will be encrypted, the sender MUST add a Frame Marking 141 header extension with the appropriate values so any intermediate MD 142 can perform the routing/SFU logic on the RTP stream. 144 Note that the SRTP encryption may also add trailing data (MKI and 145 authentication tag) to the encrypted media, so the size overhead of 146 this end to end media protection will vary. 148 Once the RTP packet payload is replaced, the media sender will be 149 able to continue the RTP processing normally, like RTX, RED/FEC 150 generation and SRTP/DTLS encryption. 152 5. Procedures at the Media Distributor 154 As the media payload of the RTP packets is encrypted, the MD MUST use 155 the Frame Marking extension information to check for I frames, start/ 156 end of frame marks or SVC layer indexes instead of looking into the 157 media data. 159 No other actions are required in the MD and it will be able to freely 160 modify any RTP header information, like sequence number rewriting, 161 add or remove RTP header extensions without affecting the encrypted 162 media data. 164 6. Procedures at the Media Receiver 166 The process at the receiver is the reverse one used at the sender. 167 Once an RTP packet has been received, the media receiver will create 168 a new auxiliary RTP packet from the RTP packet payload, prepped the 169 first byte of the RTP header with the default values v=2, x=0 and p=0 170 (0x80), and perform the SRTP decryption. If the decryption is 171 successful, it will replace the payload of the original RTP packet 172 with the decrypted payload of the auxiliary RTP packet. 174 7. Payload Encryption Header 176 The PEH payload will continue all the required information to decode 177 the packet, and it will be very similar to an RTP header: 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |M| PT | sequence number | timestamp | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | timestamp | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Payload Encryption Header 188 The values of the M, PT, sequence number and timestamp are the values 189 from the original RTP header packet. 191 8. RTX/RED/FEC procedures 193 The procedures for NACK/RTX and RED/FEC are not affected by the end 194 to end media encryption procedure as they will be applied after the 195 media has been encrypted on the sender side, and before the end to 196 end media encryption on the receiver side. 198 9. References 200 9.1. Normative References 202 [I-D.ietf-avtext-framemarking] 203 Zanaty, M., Berger, E., and S. Nandakumar, "Frame Marking 204 RTP Header Extension", draft-ietf-avtext-framemarking-10 205 (work in progress), November 2019. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 213 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 214 RFC 3711, DOI 10.17487/RFC3711, March 2004, 215 . 217 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 218 Security (DTLS) Extension to Establish Keys for the Secure 219 Real-time Transport Protocol (SRTP)", RFC 5764, 220 DOI 10.17487/RFC5764, May 2010, 221 . 223 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 224 Real-time Transport Protocol (SRTP)", RFC 6904, 225 DOI 10.17487/RFC6904, April 2013, 226 . 228 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 229 in the Secure Real-time Transport Protocol (SRTP)", 230 RFC 7714, DOI 10.17487/RFC7714, December 2015, 231 . 233 9.2. Informative References 235 [I-D.ietf-perc-private-media-framework] 236 Jones, P., Benham, D., and C. Groves, "A Solution 237 Framework for Private Media in Privacy Enhanced RTP 238 Conferencing (PERC)", draft-ietf-perc-private-media- 239 framework-12 (work in progress), June 2019. 241 Appendix A. Change Log 243 Note to RFC Editor: if this document does not obsolete an existing 244 RFC, please remove this appendix before publication as an RFC. 246 Appendix B. Open Issues 248 Note to RFC Editor: please remove this appendix before publication as 249 an RFC. 251 Authors' Addresses 253 Sergio Garcia Murillo (editor) 254 CoSMo Software Consulting, Pte Ltd 256 EMail: sergio.garcia.murillo@cosmosoftware.io 258 Alexandre Gouaillard (editor) 259 CoSMo Software Consulting, Pte Ltd 261 EMail: Alex.GOUAILLARD@cosmosoftware.io