Encrypted Key Transport for DTLS and Secure RTP
RFC 8870
Document | Type | RFC - Proposed Standard (January 2021; No errata) | |
---|---|---|---|
Authors | Cullen Jennings , John Preuß Mattsson , David McGrew , Dan Wing , Flemming Andreasen | ||
Last updated | 2021-01-18 | ||
Replaces | draft-jennings-perc-srtp-ekt-diet | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication (wg milestone: Dec 2017 - Submit encrypted key... ) | |
Document shepherd | Suhas Nandakumar | ||
Shepherd write-up | Show (last changed 2018-07-15) | ||
IESG | IESG state | RFC 8870 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Murray Kucherawy | ||
Send notices to | Suhas Nandakumar <suhasietf@gmail.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) C. Jennings Request for Comments: 8870 Cisco Systems Category: Standards Track J. Mattsson ISSN: 2070-1721 Ericsson AB D. McGrew Cisco Systems D. Wing Citrix F. Andreasen Cisco Systems January 2021 Encrypted Key Transport for DTLS and Secure RTP Abstract Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8870. Copyright Notice Copyright (c) 2021 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. Table of Contents 1. Introduction 2. Overview 3. Conventions Used in This Document 4. Encrypted Key Transport 4.1. EKTField Formats 4.2. SPIs and EKT Parameter Sets 4.3. Packet Processing and State Machine 4.3.1. Outbound Processing 4.3.2. Inbound Processing 4.4. Ciphers 4.4.1. AES Key Wrap 4.4.2. Defining New EKT Ciphers 4.5. Synchronizing Operation 4.6. Timing and Reliability Considerations 5. Use of EKT with DTLS-SRTP 5.1. DTLS-SRTP Recap 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 5.2.1. Negotiating an EKTCipher 5.2.2. Establishing an EKT Key 5.3. Offer/Answer Considerations 5.4. Sending the DTLS EKTKey Reliably 6. Security Considerations 7. IANA Considerations 7.1. EKT Message Types 7.2. EKT Ciphers 7.3. TLS Extensions 7.4. TLS Handshake Type 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Authors' Addresses 1. Introduction The Real-time Transport Protocol (RTP) is designed to allow decentralized groups with minimal control to establish sessions, such as for multimedia conferences. Unfortunately, Secure RTP (SRTP) [RFC3711] cannot be used in many minimal-control scenarios, because it requires that synchronization source (SSRC) values and other data be coordinated among all of the participants in a session. For example, if a participant joins a session that is already in progress, that participant needs to be informed of the SRTP keys along with the SSRC, rollover counter (ROC), and other details of the other SRTP sources. The inability of SRTP to work in the absence of central control was well understood during the design of the protocol; the omission was considered less important than optimizations such as bandwidth conservation. Additionally, in many situations, SRTP is used in conjunction with a signaling system that can provide the central control needed by SRTP. However, there are several cases in which conventional signaling systems cannot easily provide all of the coordination required. This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of external signaling control that is needed in an SRTP session with multiple receivers. EKT securely distributes the SRTP master key and other information for each SRTP source. WithShow full document text