Encrypted Key Transport for Secure RTP
draft-jennings-perc-srtp-ekt-diet-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2016-03-21
Replaced by draft-ietf-perc-srtp-ekt-diet
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
PERC Working Group                                      J. Mattsson, Ed.
Internet-Draft                                                  Ericsson
Intended status: Standards Track                               D. McGrew
Expires: September 20, 2016                                      D. Wing
                                                            F. Andreasen
                                                             C. Jennings
                                                                   Cisco
                                                          March 19, 2016

                 Encrypted Key Transport for Secure RTP
                  draft-jennings-perc-srtp-ekt-diet-00

Abstract

   IMPORTANT: This draft is just a cut down version of draft-ietf-
   avtcore-srtp-ekt-03 to help discussion about the key parts of EKT for
   the PERC WG.  Any changes decided here would need to be synchronized
   with the draft-ietf-avtcore-srtp-ekt draft.  Nearly all the text here
   came from draft-ietf-avtcore-srtp-ekt and the authors of that draft.

   Encrypted Key Transport (EKT) is an extension to 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 to work for decentralized
   conferences with minimal control by allowing a common key to be used
   across multiple endpoints.

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 http://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 September 20, 2016.

Mattsson, et al.       Expires September 20, 2016               [Page 1]
Internet-Draft                  EKT SRTP                      March 2016

Copyright Notice

   Copyright (c) 2016 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
   (http://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.

1.  Introduction

   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 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 told the SRTP keys (and SSRC,
   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 most of the
   central control needed by SRTP.  However, there are several cases in
   which conventional signaling systems cannot easily provide all of the
   coordination required.  It is also desirable to eliminate the layer
   violations that occur when signaling systems coordinate certain SRTP
   parameters, such as SSRC values and ROCs.

   This document defines Encrypted Key Transport (EKT) for SRTP and
   reduces the amount of external signaling control that is needed in a
   SRTP session that is shared with multiple receivers.  EKT securely
   distributes the SRTP master key and other information for each SRTP
   source.  With this method, SRTP entities are free to choose SSRC
   values as they see fit, and to start up new SRTP sources (SSRC) with
   new SRTP master keys (see Section 2.2) within a session without
   coordinating with other entities via external signaling or other
   external means.

Mattsson, et al.       Expires September 20, 2016               [Page 2]
Internet-Draft                  EKT SRTP                      March 2016

   EKT provides a way for an SRTP session participant, either a sender
Show full document text