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. With
Show full document text