Network Working Group                             S. Garcia Murillo, Ed.
Internet-Draft                                        A. Gouaillard, Ed.
Expires: November 13, 2020            CoSMo Software Consulting, Pte Ltd
                                                            May 12, 2020


                 End to End Media Encryption Procedures
                       draft-murillo-perc-lite-01

Abstract

   In some conferencing scenarios, it is desirable for an intermediary
   to be able to manipulate some RTP parameters, while still providing
   strong end-to-end security guarantees.  This document defines a
   procedure to perform end to end media authenticated encryption.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 November 13, 2020.

Copyright Notice

   Copyright (c) 2020 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Garcia Murillo & GouaillExpires November 13, 2020               [Page 1]


Internet-Draft                  PERC-Lite                       May 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Procedures at the Media Sender  . . . . . . . . . . . . . . .   3
   5.  Procedures at the Media Distributor . . . . . . . . . . . . .   4
   6.  Procedures at the Media Receiver  . . . . . . . . . . . . . .   4
   7.  Payload Encryption Header . . . . . . . . . . . . . . . . . .   4
   8.  RTX/RED/FEC procedures  . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   7
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   RTP-based real-time multi-party interactive media conferencing is in
   widespread use today.  Many of the deployments use one or more
   centrally located media distribution devices that perform selective
   forwarding of mixed-media streams received from the participating
   endpoints.

   These conferences require security to ensure that the RTP media and
   related metadata of the conference is kept private and only available
   to the set of invited participants and other devices trusted by those
   participants with their media.  At the same time, multi-party media
   conferences need source authentication and integrity checks to
   protect against modifications, insertions, and replay attacks.

   To date, deployment models for these multi-party media distribution
   devices do not enable the devices to perform their functions without
   having keys to decrypt the participants' media.  This trust model has
   limitations and prevents or hampers deployment of secure RTP
   conferencing in a multitude of cases, including outsourcing, legal
   requirements on confidentiality, and utilization of virtualized
   servers.

   This specification defines an End to End Media Encryption procedure,
   so the media distribution devices can perform their media
   distribution function but without having access to the participant
   media, while focusing on introducing the minimun amount of changes on
   both the endpoints and the media distributor.






Garcia Murillo & GouaillExpires November 13, 2020               [Page 2]


Internet-Draft                  PERC-Lite                       May 2020


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Overview

   In order to prevent the Media Distributor (MD) to access the contents
   of the media passing through the system, the RTP media payload will
   be encrypted using SRTP, that will provide encryption, message
   authentication and integrity, and replay protection.  The RECOMMENDED
   cipher to be used is AES-GCM.

   All the participants on the conference will share a media encryption/
   decryption key.  How to distribute the shared key to all the
   participants of the conference is out of scope of this draft.

   The encrypted media payload will be self-contained, so it can be
   decrypted by the media receiver side, regardless any RTP
   transformation done by the intermediary hosts.

4.  Procedures at the Media Sender

   The Media Sender will encode the media streams and packetize the
   encoded stream into RTP packets according to the codec specific
   specifications.  Once done, the RTP payload will be replaced with an
   encrypted version of the media payload, prepending the required
   information for decrypting it.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         RTP Header                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Payload Encryption Header                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Payload Encryption Header (cont)            |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
      |           Payload Encrypted media data                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RTP packet with E2E encrypted Media pPyload






Garcia Murillo & GouaillExpires November 13, 2020               [Page 3]


Internet-Draft                  PERC-Lite                       May 2020


   As the payload will be encrypted, the sender MUST add a Frame Marking
   header extension with the appropriate values so any intermediate MD
   can perform the routing/SFU logic on the RTP stream.

   Note that the SRTP encryption may also add trailing data (MKI and
   authentication tag) to the encrypted media, so the size overhead of
   this end to end media protection will vary.

   Once the RTP packet payload is replaced, the media sender will be
   able to continue the RTP processing normally, like RTX, RED/FEC
   generation and SRTP/DTLS encryption.

5.  Procedures at the Media Distributor

   As the media payload of the RTP packets is encrypted, the MD MUST use
   the Frame Marking extension information to check for I frames, start/
   end of frame marks or SVC layer indexes instead of looking into the
   media data.

   No other actions are required in the MD and it will be able to freely
   modify any RTP header information, like sequence number rewriting,
   add or remove RTP header extensions without affecting the encrypted
   media data.

6.  Procedures at the Media Receiver

   The process at the receiver is the reverse one used at the sender.
   Once an RTP packet has been received, the media receiver will create
   a new auxiliary RTP packet from the RTP packet payload, prepped the
   first byte of the RTP header with the default values v=2, x=0 and p=0
   (0x80), and perform the SRTP decryption.  If the decryption is
   successful, it will replace the payload of the original RTP packet
   with the decrypted payload of the auxiliary RTP packet.

7.  Payload Encryption Header

   The PEH payload will continue all the required information to decode
   the packet, and it will be very similar to an RTP header:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|     PT      |       sequence number         |  timestamp    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  timestamp                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Payload Encryption Header



Garcia Murillo & GouaillExpires November 13, 2020               [Page 4]


Internet-Draft                  PERC-Lite                       May 2020


   The values of the M, PT, sequence number and timestamp are the values
   from the original RTP header packet.

8.  RTX/RED/FEC procedures

   The procedures for NACK/RTX and RED/FEC are not affected by the end
   to end media encryption procedure as they will be applied after the
   media has been encrypted on the sender side, and before the end to
   end media encryption on the receiver side.

9.  References

9.1.  Normative References

   [I-D.ietf-avtext-framemarking]
              Zanaty, M., Berger, E., and S. Nandakumar, "Frame Marking
              RTP Header Extension", draft-ietf-avtext-framemarking-10
              (work in progress), November 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3711>.

   [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,
              <https://www.rfc-editor.org/info/rfc5764>.

   [RFC6904]  Lennox, J., "Encryption of Header Extensions in the Secure
              Real-time Transport Protocol (SRTP)", RFC 6904,
              DOI 10.17487/RFC6904, April 2013,
              <https://www.rfc-editor.org/info/rfc6904>.

   [RFC7714]  McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
              in the Secure Real-time Transport Protocol (SRTP)",
              RFC 7714, DOI 10.17487/RFC7714, December 2015,
              <https://www.rfc-editor.org/info/rfc7714>.







Garcia Murillo & GouaillExpires November 13, 2020               [Page 5]


Internet-Draft                  PERC-Lite                       May 2020


9.2.  Informative References

   [I-D.ietf-perc-private-media-framework]
              Jones, P., Benham, D., and C. Groves, "A Solution
              Framework for Private Media in Privacy Enhanced RTP
              Conferencing (PERC)", draft-ietf-perc-private-media-
              framework-12 (work in progress), June 2019.












































Garcia Murillo & GouaillExpires November 13, 2020               [Page 6]


Internet-Draft                  PERC-Lite                       May 2020


Appendix A.  Change Log

   Note to RFC Editor: if this document does not obsolete an existing
   RFC, please remove this appendix before publication as an RFC.

Appendix B.  Open Issues

   Note to RFC Editor: please remove this appendix before publication as
   an RFC.

Authors' Addresses

   Sergio Garcia Murillo (editor)
   CoSMo Software Consulting, Pte Ltd

   EMail: sergio.garcia.murillo@cosmosoftware.io


   Alexandre Gouaillard (editor)
   CoSMo Software Consulting, Pte Ltd

   EMail: Alex.GOUAILLARD@cosmosoftware.io





























Garcia Murillo & GouaillExpires November 13, 2020               [Page 7]