Internet DRAFT - draft-murillo-perc-lite
draft-murillo-perc-lite
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]
