draft-ietf-perc-srtp-ekt-diet-04.txt   draft-ietf-perc-srtp-ekt-diet-05.txt 
PERC Working Group C. Jennings PERC Working Group C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Mattsson, Ed. Intended status: Standards Track J. Mattsson, Ed.
Expires: October 30, 2017 Ericsson Expires: December 31, 2017 Ericsson
D. McGrew D. McGrew
D. Wing D. Wing
F. Andreasen F. Andreasen
Cisco Cisco
April 28, 2017 June 29, 2017
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-04 draft-ietf-perc-srtp-ekt-diet-05
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS and Secure Encrypted Key Transport (EKT) is an extension to DTLS and Secure
Real-time Transport Protocol (SRTP) that provides for the secure Real-time Transport Protocol (SRTP) that provides for the secure
transport of SRTP master keys, rollover counters, and other transport of SRTP master keys, rollover counters, and other
information within SRTP. This facility enables SRTP for information within SRTP. This facility enables SRTP for
decentralized conferences by distributing a common key to all of the decentralized conferences by distributing a common key to all of the
conference endpoints. conference endpoints.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12
4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12
4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Timing and Reliability Consideration . . . . . . . . . . 13 4.7. Timing and Reliability Consideration . . . . . . . . . . 13
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 13 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 13
5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17
5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17 5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19
7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 20 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 20
7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 20 7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) is designed to allow decentralized Real-time Transport Protocol (RTP) is designed to allow decentralized
groups with minimal control to establish sessions, such as for groups with minimal control to establish sessions, such as for
multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711]) multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711])
cannot be used in many minimal-control scenarios, because it requires cannot be used in many minimal-control scenarios, because it requires
that synchronization source (SSRC) values and other data be that synchronization source (SSRC) values and other data be
coordinated among all of the participants in a session. For example, coordinated among all of the participants in a session. For example,
if a participant joins a session that is already in progress, that if a participant joins a session that is already in progress, that
skipping to change at page 17, line 32 skipping to change at page 17, line 32
ekt_key_ack --------> ekt_key_ack -------->
SRTP packets <-------> SRTP packets SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets SRTP packets <-------> SRTP packets
ekt_key (rekey) <------- ekt_key (rekey) <-------
ekt_key_ack --------> ekt_key_ack -------->
SRTP packets <-------> SRTP packets SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets SRTP packets <-------> SRTP packets
Figure 5: DTLS/SRTP Message Flow 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 5.3. Offer/Answer Considerations
When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 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 / the DTLS handshake level and does not change the [RFC3264] Offer /
Answer messaging. Answer messaging.
5.4. Sending the DTLS EKT_Key Reliably 5.4. Sending the DTLS EKT_Key Reliably
The DTLS ekt_key is sent using the retransmissions specified in The DTLS ekt_key is sent using the retransmissions specified in
Section 4.2.4. of DTLS [RFC6347]. Section 4.2.4. of DTLS [RFC6347].
 End of changes. 8 change blocks. 
7 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/