--- 1/draft-ietf-perc-srtp-ekt-diet-04.txt	2017-06-29 13:13:23.903773609 -0700
+++ 2/draft-ietf-perc-srtp-ekt-diet-05.txt	2017-06-29 13:13:23.955774863 -0700
@@ -1,23 +1,23 @@
 
 PERC Working Group                                           C. Jennings
 Internet-Draft                                                     Cisco
 Intended status: Standards Track                        J. Mattsson, Ed.
-Expires: October 30, 2017                                       Ericsson
+Expires: December 31, 2017                                      Ericsson
                                                                D. McGrew
                                                                  D. Wing
                                                             F. Andreasen
                                                                    Cisco
-                                                          April 28, 2017
+                                                           June 29, 2017
 
             Encrypted Key Transport for DTLS and Secure RTP
-                    draft-ietf-perc-srtp-ekt-diet-04
+                    draft-ietf-perc-srtp-ekt-diet-05
 
 Abstract
 
    Encrypted Key Transport (EKT) is an extension to DTLS and 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.
 
@@ -29,21 +29,21 @@
    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 October 30, 2017.
+   This Internet-Draft will expire on December 31, 2017.
 
 Copyright Notice
 
    Copyright (c) 2017 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
@@ -68,31 +68,31 @@
        4.4.1.  Ciphers . . . . . . . . . . . . . . . . . . . . . . .  11
        4.4.2.  Defining New EKT Ciphers  . . . . . . . . . . . . . .  12
      4.5.  Synchronizing Operation . . . . . . . . . . . . . . . . .  12
      4.6.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  12
      4.7.  Timing and Reliability Consideration  . . . . . . . . . .  13
    5.  Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . .  13
      5.1.  DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . .  14
      5.2.  SRTP EKT Key Transport Extensions to DTLS-SRTP  . . . . .  14
      5.3.  Offer/Answer Considerations . . . . . . . . . . . . . . .  17
      5.4.  Sending the DTLS EKT_Key Reliably . . . . . . . . . . . .  17
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
      7.1.  EKT Message Types . . . . . . . . . . . . . . . . . . . .  19
      7.2.  EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . .  20
      7.3.  TLS Extensions  . . . . . . . . . . . . . . . . . . . . .  20
-     7.4.  TLS Content Type  . . . . . . . . . . . . . . . . . . . .  20
+     7.4.  TLS Content Type  . . . . . . . . . . . . . . . . . . . .  21
    8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
      9.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
      9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
 
 1.  Introduction
 
    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
@@ -721,20 +721,26 @@
    ekt_key_ack                  -------->
    SRTP packets                 <------->      SRTP packets
    SRTP packets                 <------->      SRTP packets
    ekt_key (rekey)              <-------
    ekt_key_ack                  -------->
    SRTP packets                 <------->      SRTP packets
    SRTP packets                 <------->      SRTP packets
 
                      Figure 5: DTLS/SRTP Message Flow
 
+   Note that when used in PERC [I-D.ietf-perc-private-media-framework],
+   the Server is actually split between the Media Distrbutor and Key
+   Distributor.  The messages in the above figure that are "SRTP
+   packets" will not got to the Key Distributor but the oter packets
+   will be relayed by the Media Distributor to the Key Distributor.
+
 5.3.  Offer/Answer Considerations
 
    When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
    the DTLS handshake level and does not change the [RFC3264] Offer /
    Answer messaging.
 
 5.4.  Sending the DTLS EKT_Key Reliably
 
    The DTLS ekt_key is sent using the retransmissions specified in
    Section 4.2.4. of DTLS [RFC6347].