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