draft-ietf-perc-srtp-ekt-diet-05.txt   draft-ietf-perc-srtp-ekt-diet-06.txt 
PERC Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Internet-Draft Cisco Systems
Intended status: Standards Track J. Mattsson, Ed. Intended status: Standards Track J. Mattsson
Expires: December 31, 2017 Ericsson Expires: May 3, 2018 Ericsson AB
D. McGrew D. McGrew
D. Wing D. Wing
F. Andreasen F. Andreason
Cisco Cisco Systems
June 29, 2017 October 30, 2017
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-05 draft-ietf-perc-srtp-ekt-diet-06
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 December 31, 2017. This Internet-Draft will expire on May 3, 2018.
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 17 skipping to change at page 2, line 17
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used In This Document . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4
4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4
4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4 4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Processing and State Machine . . . . . . . . . . . 7 4.2. Packet Processing and State Machine . . . . . . . . . . . 7
4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8
4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9
4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10
4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . 12
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.2.1. Negotiating an EKT Cipher . . . . . . . . . . . . . . 16
5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18
5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . 21
7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 21 7.4. TLS Handshake 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 . . . . . . . . . . . . . . . . . . . . . . . 23 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
participant needs to be told the SRTP keys along with the SSRC, participant needs to be told the SRTP keys along with the SSRC,
rollover counter (ROC) and other details of the other SRTP sources. rollover counter (ROC) and other details of the other SRTP sources.
The inability of SRTP to work in the absence of central control was The inability of SRTP to work in the absence of central control was
well understood during the design of the protocol; the omission was well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth considered less important than optimizations such as bandwidth
skipping to change at page 4, line 43 skipping to change at page 4, line 45
EKT defines a new method of providing SRTP master keys to an EKT defines a new method of providing SRTP master keys to an
endpoint. In order to convey the ciphertext corresponding to the endpoint. In order to convey the ciphertext corresponding to the
SRTP master key, and other additional information, an additional EKT SRTP master key, and other additional information, an additional EKT
field is added to SRTP packets. The EKT field appears at the end of field is added to SRTP packets. The EKT field appears at the end of
the SRTP packet. The EKT field appears after the optional the SRTP packet. The EKT field appears after the optional
authentication tag if one is present, otherwise the EKT field appears authentication tag if one is present, otherwise the EKT field appears
after the ciphertext portion of the packet. after the ciphertext portion of the packet.
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
features duplicate some of the functions of EKT. Senders MUST not features duplicate some of the functions of EKT. Senders MUST NOT
include MKI when using EKT. Receivers SHOULD simply ignore any MKI include MKI when using EKT. Receivers SHOULD simply ignore any MKI
field received if EKT is in use. field received if EKT is in use.
4.1. EKT Field Formats 4.1. EKT Field Formats
The EKT Field uses the format defined below for the FullEKTField and The EKT Field uses the format defined below for the FullEKTField and
ShortEKTField. ShortEKTField.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Figure 2: Short EKT Field format Figure 2: Short EKT Field format
The following shows the syntax of the EKTField expressed in ABNF The following shows the syntax of the EKTField expressed in ABNF
[RFC5234]. The EKTField is added to the end of an SRTP or SRTCP [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP
packet. The EKTPlaintext is the concatenation of packet. The EKTPlaintext is the concatenation of
SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The
EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTCiphertext is computed by encrypting the EKTPlaintext using the
EKTKey. Future extensions to the EKTField MUST conform to the syntax EKTKey. Future extensions to the EKTField MUST conform to the syntax
of ExtensionEKTField. of ExtensionEKTField.
BYTE = %x00-FF BYTE = %x00-FF
EKTMsgTypeFull = %x02 EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00 EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF EKTMsgTypeExtension = %x03-FF
EKTMsgLength = 2BYTE; EKTMsgLength = 2BYTE;
SRTPMasterKeyLength = BYTE SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*256BYTE SRTPMasterKey = 1*256BYTE
SSRC = 4BYTE; SSRC from RTP SSRC = 4BYTE; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull
ShortEKTField = EKTMsgTypeShort ShortEKTField = EKTMsgTypeShort
ExtensionData = 1*1024BYTE ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField Syntax Figure 3: EKTField Syntax
These fields and data elements are defined as follows: These fields and data elements are defined as follows:
EKTPlaintext: The data that is input to the EKT encryption EKTPlaintext: The data that is input to the EKT encryption operation.
operation. This data never appears on the wire, and is used only This data never appears on the wire, and is used only in computations
in computations internal to EKT. This is the concatenation of the internal to EKT. This is the concatenation of the SRTP Master Key,
SRTP Master Key, the SSRC, and the ROC. the SSRC, and the ROC.
EKTCiphertext: The data that is output from the EKT encryption EKTCiphertext: The data that is output from the EKT encryption
operation, described in Section 4.4. This field is included in operation, described in Section 4.4. This field is included in SRTP
SRTP packets when EKT is in use. The length of EKTCiphertext can packets when EKT is in use. The length of EKTCiphertext can be
be larger than the length of the EKTPlaintext that was encrypted. larger than the length of the EKTPlaintext that was encrypted.
SRTPMasterKey: On the sender side, the SRTP Master Key associated SRTPMasterKey: On the sender side, the SRTP Master Key associated
with the indicated SSRC. with the indicated SSRC.
SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
depends on the cipher suite negotiated for SRTP using [RFC3264] depends on the cipher suite negotiated for SRTP using SDP Offer/
SDP Offer/Answer for the SRTP. Answer [RFC3264] for the SRTP.
SSRC: On the sender side, this field is the SSRC for this SRTP SSRC: On the sender side, this field is the SSRC for this SRTP
source. The length of this field is 32 bits. source. The length of this field is 32 bits.
Rollover Counter (ROC): On the sender side, this field is set to the Rollover Counter (ROC): On the sender side, this field is set to the
current value of the SRTP rollover counter in the SRTP context current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP or SRTCP packet. The length associated with the SSRC in the SRTP or SRTCP packet. The length of
of this field is 32 bits. this field is 32 bits.
Security Parameter Index (SPI): This field indicates the appropriate Security Parameter Index (SPI): This field indicates the appropriate
EKT Key and other parameters for the receiver to use when EKT Key and other parameters for the receiver to use when processing
processing the packet. The length of this field is 16 bits. The the packet. The length of this field is 16 bits. The parameters
parameters identified by this field are: identified by this field are:
* The EKT cipher used to process the packet. o The EKT cipher used to process the packet.
* The EKT Key used to process the packet. o The EKT Key used to process the packet.
* The SRTP Master Salt associated with any Master Key encrypted o The SRTP Master Salt associated with any Master Key encrypted with
with this EKT Key. The Master Salt is communicated separately, this EKT Key. The Master Salt is communicated separately, via
via signaling, typically along with the EKTKey. signaling, typically along with the EKTKey.
Together, these data elements are called an EKT parameter set. Together, these data elements are called an EKT parameter set. Each
Each distinct EKT parameter set that is used MUST be associated distinct EKT parameter set that is used MUST be associated with a
with a distinct SPI value to avoid ambiguity. distinct SPI value to avoid ambiguity.
EKTMsgLength: All EKT message other that ShortEKTField have a length EKTMsgLength: All EKT message other that ShortEKTField have a length
as second from the last element. This is the length in octets of as second from the last element. This is the length in octets of
either the FullEKTField/ExtensionEKTField including this length either the FullEKTField/ExtensionEKTField including this length field
field and the following message type. and the following message type.
Message Type: The last byte is used to indicate the type of the Message Type: The last byte is used to indicate the type of the
EKTField. This MUST be 2 in the FullEKTField format and 0 in EKTField. This MUST be 2 in the FullEKTField format and 0 in
ShortEKTField format. Values less than 64 are mandatory to ShortEKTField format. Values less than 64 are mandatory to
understand while other values are optional to understand. A understand while other values are optional to understand. A receiver
receiver SHOULD discard the whole EKTField if it contains any SHOULD discard the whole EKTField if it contains any message type
message type value that is less than 64 and that is not value that is less than 64 and that is not understood. Message type
understood. Message type values that are 64 or greater but not values that are 64 or greater but not implemented or understood can
implemented or understood can simply be ignored. simply be ignored.
4.2. Packet Processing and State Machine 4.2. Packet Processing and State Machine
At any given time, each SRTP/SRTCP source has associated with it a At any given time, each SRTP/SRTCP source has associated with it a
single EKT parameter set. This parameter set is used to process all single EKT parameter set. This parameter set is used to process all
outbound packets, and is called the outbound parameter set for that outbound packets, and is called the outbound parameter set for that
SSRC. There may be other EKT parameter sets that are used by other SSRC. There may be other EKT parameter sets that are used by other
SRTP/SRTCP sources in the same session, including other SRTP/SRTCP SRTP/SRTCP sources in the same session, including other SRTP/SRTCP
sources on the same endpoint (e.g., one endpoint with voice and video sources on the same endpoint (e.g., one endpoint with voice and video
might have two EKT parameter sets, or there might be multiple video might have two EKT parameter sets, or there might be multiple video
skipping to change at page 8, line 43 skipping to change at page 8, line 43
3. The EKTCiphertext field is set to the ciphertext created by 3. The EKTCiphertext field is set to the ciphertext created by
encrypting the EKTPlaintext with the EKT cipher, using the EKTKey encrypting the EKTPlaintext with the EKT cipher, using the EKTKey
as the encryption key. The encryption process is detailed in as the encryption key. The encryption process is detailed in
Section 4.4. Section 4.4.
4. Then the FullEKTField is formed using the EKTCiphertext and the 4. Then the FullEKTField is formed using the EKTCiphertext and the
SPI associated with the EKTKey used above. Also appended are the SPI associated with the EKTKey used above. Also appended are the
Length and Message Type using the FullEKTField format. Length and Message Type using the FullEKTField format.
Note: the value of the EKTCiphertext field is identical in * Note: the value of the EKTCiphertext field is identical in
successive packets protected by the same EKTKey and SRTP successive packets protected by the same EKTKey and SRTP
master key. This value MAY be cached by an SRTP sender to master key. This value MAY be cached by an SRTP sender to
minimize computational effort. minimize computational effort.
The computed value of the FullEKTField is written into the The computed value of the FullEKTField is written into the
packet. packet.
When a packet is sent with the Short EKT Field, the ShortEKFField is When a packet is sent with the Short EKT Field, the ShortEKFField is
simply appended to the packet. simply appended to the packet.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
a length of N = M + (M mod 8) + 8 octets. It can be used with key a length of N = M + (M mod 8) + 8 octets. It can be used with key
sizes of L = 16, and L = 32 octets, and its use with those key sizes sizes of L = 16, and L = 32 octets, and its use with those key sizes
is indicated as AESKW128, or AESKW256, respectively. The key size is indicated as AESKW128, or AESKW256, respectively. The key size
determines the length of the AES key used by the Key Wrap algorithm. determines the length of the AES key used by the Key Wrap algorithm.
With this cipher, T=2^48. With this cipher, T=2^48.
+----------+----+------+ +----------+----+------+
| Cipher | L | T | | Cipher | L | T |
+----------+----+------+ +----------+----+------+
| AESKW128 | 16 | 2^48 | | AESKW128 | 16 | 2^48 |
| | | |
| AESKW256 | 32 | 2^48 | | AESKW256 | 32 | 2^48 |
+----------+----+------+ +----------+----+------+
Table 1: EKT Ciphers Table 1: EKT Ciphers
As AES-128 is the mandatory to implement transform in SRTP [RFC3711], As AES-128 is the mandatory to implement transform in SRTP, AESKW128
AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. MUST be implemented for EKT and AESKW256 MAY be implemented.
4.4.2. Defining New EKT Ciphers 4.4.2. Defining New EKT Ciphers
Other specifications may extend this document by defining other Other specifications may extend this document by defining other
EKTCiphers as described in Section 7. This section defines how those EKTCiphers as described in Section 7. This section defines how those
ciphers interact with this specification. ciphers interact with this specification.
An EKTCipher determines how the EKTCiphertext field is written, and An EKTCipher determines how the EKTCiphertext field is written, and
how it is processed when it is read. This field is opaque to the how it is processed when it is read. This field is opaque to the
other aspects of EKT processing. EKT ciphers are free to use this other aspects of EKT processing. EKT ciphers are free to use this
skipping to change at page 13, line 24 skipping to change at page 13, line 19
There are three cases to consider. The first case is a new sender There are three cases to consider. The first case is a new sender
joining a session which needs to communicate its SRTP master key to joining a session which needs to communicate its SRTP master key to
all the receivers. The second case is a sender changing its SRTP all the receivers. The second case is a sender changing its SRTP
master key which needs to be communicated to all the receivers. The master key which needs to be communicated to all the receivers. The
third case is a new receiver joining a session already in progress third case is a new receiver joining a session already in progress
which needs to know the sender's SRTP master key. which needs to know the sender's SRTP master key.
The three cases are: The three cases are:
New sender: A new sender SHOULD send a packet containing the New sender:
FullEKTField as soon as possible, always before or coincident with A new sender SHOULD send a packet containing the FullEKTField as
sending its initial SRTP packet. To accommodate packet loss, it soon as possible, always before or coincident with sending its
is RECOMMENDED that three consecutive packets contain the Full EKT initial SRTP packet. To accommodate packet loss, it is
RECOMMENDED that three consecutive packets contain the Full EKT
Field be transmitted. Field be transmitted.
Rekey: By sending EKT over SRTP, the rekeying event shares fate with Rekey:
the SRTP packets protected with that new SRTP master key. To By sending EKT over SRTP, the rekeying event shares fate with the
SRTP packets protected with that new SRTP master key. To
accommodate packet loss, it is RECOMMENDED that three consecutive accommodate packet loss, it is RECOMMENDED that three consecutive
packets contain the FullEKTField be transmitted. packets contain the FullEKTField be transmitted.
New receiver: When a new receiver joins a session it does not need New receiver:
to communicate its sending SRTP master key (because it is a When a new receiver joins a session it does not need to
communicate its sending SRTP master key (because it is a
receiver). When a new receiver joins a session the sender is receiver). When a new receiver joins a session the sender is
generally unaware of the receiver joining the session. Thus, generally unaware of the receiver joining the session. Thus,
senders SHOULD periodically transmit the FullEKTField. That senders SHOULD periodically transmit the FullEKTField. That
interval depends on how frequently new receivers join the session, interval depends on how frequently new receivers join the session,
the acceptable delay before those receivers can start processing the acceptable delay before those receivers can start processing
SRTP packets, and the acceptable overhead of sending the FullEKT SRTP packets, and the acceptable overhead of sending the FullEKT
Field. If sending audio and video, the RECOMMENDED frequency is Field. If sending audio and video, the RECOMMENDED frequency is
the same as the rate of intra coded video frames. If only sending the same as the rate of intra coded video frames. If only sending
audio, the RECOMMENDED frequency is every 100ms. audio, the RECOMMENDED frequency is every 100ms.
5. Use of EKT with DTLS-SRTP 5. Use of EKT with DTLS-SRTP
This document defines an extension to DTLS-SRTP called SRTP EKT Key This document defines an extension to DTLS-SRTP called SRTP EKT Key
Transport which enables secure transport of EKT keying material from Transport which enables secure transport of EKT keying material from
one DTLS-SRTP peer to another. This allows those peers to process the DTLS-SRTP peer in the server role to the client. This allows
EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP those peers to process EKT keying material in SRTP (or SRTCP) and
keying material. This combination of protocols is valuable because retrieve the embedded SRTP keying material. This combination of
it combines the advantages of DTLS, which has strong authentication protocols is valuable because it combines the advantages of DTLS,
of the endpoint and flexibility, along with allowing secure which has strong authentication of the endpoint and flexibility,
multiparty RTP with loose coordination and efficient communication of along with allowing secure multiparty RTP with loose coordination and
per-source keys. efficient communication of per-source keys.
5.1. DTLS-SRTP Recap 5.1. DTLS-SRTP Recap
DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers
to exchange keying material, algorithms, and parameters for SRTP. to exchange keying material, algorithms, and parameters for SRTP.
The SRTP flow operates over the same transport as the DTLS-SRTP The SRTP flow operates over the same transport as the DTLS-SRTP
exchange (i.e., the same 5-tuple). DTLS-SRTP combines the exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
performance and encryption flexibility benefits of SRTP with the performance and encryption flexibility benefits of SRTP with the
flexibility and convenience of DTLS-integrated key and association flexibility and convenience of DTLS-integrated key and association
management. DTLS-SRTP can be viewed in two equivalent ways: as a new management. DTLS-SRTP can be viewed in two equivalent ways: as a new
key management method for SRTP, and a new RTP-specific data format key management method for SRTP, and a new RTP-specific data format
for DTLS. for DTLS.
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
This document defines a new TLS negotiated extension called This document defines a new TLS negotiated extension
"srtp_ekt_key_transport"and a new TLS content type called EKTMessage. supported_ekt_ciphers and a new TLS handshake message type ekt_key.
The extension negotiates the cipher to be used in encrypting and
decrypting EKTCiphertext values, and the handshake message carries
the corresponding key.
Using the syntax described in DTLS [RFC6347], the following The diagram below shows a message flow of DTLS 1.3 client and server
structures are used: using EKT configured using the DTLS extensions described in this
section. (The initial cookie exchange and other normal DTLS messages
are omitted.)
Client Server
enum { ClientHello
reserved(0), + use_srtp
aeskw_128(1), + supported_ekt_ciphers
aeskw_256(2), -------->
} EKTCipherType;
struct { ServerHello
EKTCipherType ekt_ciphers<1..255>; {EncryptedExtensions}
} SupportedEKTCiphers; + use_srtp
+ supported_ekt_ciphers
{... Finished}
<--------
struct { {... Finished} -------->
EKTCipherType ekt_cipher;
uint ekt_key_value<1..256>;
uint srtp_master_salt<1..256>;
uint16 ekt_spi;
uint24 ekt_ttl;
} EKTkey;
enum { [Ack]
ekt_key(0), <-------- [EKTKey]
ekt_key_ack(1),
ekt_key_error(254),
(255)
} EKTMessageType;
struct { [Ack] -------->
EKTMessageType ekt_message_type;
select (EKTMessage.ekt_message_type) {
case ekt_key:
EKTKey;
} message;
} EKTMessage;
Figure 4: Additional TLS Data Structures |SRTP packets| <-------> |SRTP packets|
+ <EKT tags> + <EKT tags>
If a DTLS client includes "srtp_ekt_key_transport" in its {} Messages protected using DTLS handshake keys
ClientHello, then a DTLS server that supports this extensions will
includes "srtp_ekt_key_transport" in its ServerHello message. If a
DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
does not receive "srtp_ekt_key_transport" in the ServerHello, the
DTLS client MUST NOT send DTLS EKTMessage messages. Also, the
"srtp_ekt_key_transport" in the ServerHello MUST select one and only
one EKTCipherType from the list provided by the client in the
"srtp_ekt_key_transport" in the ClientHello.
When a DTLS client sends the "srtp_ekt_key_transport" in its [] Messages protected using DTLS application traffic keys
ClientHello message, it MUST include the SupportedEKTCiphers as the
extension_data for the extension, listing the EKTCipherTypes the
client is willing to use in preference order, with the most preferred
version first. When the server responds in the
"srtp_ekt_key_transport" in its ServerHello message, it MUST include
a SupportedEKTCiphers list that selects a single EKTCipherType to use
(selected from the list provided by the client) or it returns an
empty list to indicate there is no matching EKTCipherType in the
clients list that the server is also willing to use. The value to be
used in the EKTCipherType for future extensions that define new
ciphers is the value from the "EKT Ciphers Type" IANA registry
defined in Section 7.2.
The figure above defines the contents for a new TLS content type <> Messages protected using the EKTKey and EKT cipher
called EKTMessage which is registered in Section 7.4. The EKTMessage
above is used as the opaque fragment in the TLSPlaintext structure
defined in Section 6.2.1 of [RFC5246] and the "srtp_ekt_message" as
the content type. The "srtp_ekt_message" content type is defined and
registered in Section 7.3.
ekt_ttl: The maximum amount of time, in seconds, that this || Messages protected using the SRTP Master Key sent in
ekt_key_value can be used. The ekt_key_value in this message MUST a Full EKT Tag
NOT be used for encrypting or decrypting information after the TTL
expires.
When the Server wishes to provide a new EKT Key, it can send Figure 4
EKTMessage containing an EKTKey with the new key information. The
client MUST respond with an EKTMessage of type ekt_key_ack, if the
EKTKey was successfully processed and stored or respond with the the
ekt_key_error EKTMessage otherwise.
The diagram below shows a message flow of DTLS client and DTLS server In the context of a multi-party SRTP session in which each endpoint
using the DTLS-SRTP Key Transport extension. performs a DTLS handshake as a client with a central DTLS server, the
extensions defined in this session allow the DTLS server to set a
common EKT key among all participants. Each endpoint can then use
EKT tags encrypted with that common key to inform other endpoint of
the keys it is using to protect SRTP packet. This avoids the need
for many individual DTLS handshakes among the endpoints, at the cost
of preventing endpoints from directly authenticating one another.
Client Server Client A Server Client B
ClientHello + use_srtp + srtp_ekt_key_trans <----DTLS Handshake---->
--------> <--------EKTKey---------
ServerHello+use_srtp+srtp_ekt_key_trans <----DTLS Handshake---->
Certificate* ---------EKTKey-------->
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ekt_key <--------
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 -------------SRTP Packet + EKT Tag------------->
<------------SRTP Packet + EKT Tag--------------
Note that when used in PERC [I-D.ietf-perc-private-media-framework], 5.2.1. Negotiating an EKT Cipher
the Server is actually split between the Media Distrbutor and Key
Distributor. The messages in the above figure that are "SRTP To indicate its support for EKT, a DTLS-SRTP client includes in its
packets" will not got to the Key Distributor but the oter packets ClientHello an extension of type supported_ekt_ciphers listing the
will be relayed by the Media Distributor to the Key Distributor. EKT ciphers the client supports in preference order, with the most
preferred version first. If the server agrees to use EKT, then it
includes a supported_ekt_ciphers extension in its ServerHello
containing a cipher selected from among those advertised by the
client.
The extension_data field of this extension contains an "EKTCipher"
value, encoded using the syntax defined in [RFC5246]:
enum {
reserved(0),
aeskw_128(1),
aeskw_256(2),
} EKTCipherType;
struct {
select (Handshake.msg_type) {
case client_hello:
EKTCipherType supported_ciphers<1..255>;
case server_hello:
EKTCipherType selected_cipher;
};
} EKTCipher;
5.2.2. Establishing an EKT Key
Once a client and server have concluded a handshake that negotiated
an EKT cipher, the server MUST provide to the client a key to be used
when encrypting and decrypting EKTCiphertext values. EKT keys are
sent in encrypted handshake records, using handshake type
ekt_key(TBD). The body of the handshake message contains an EKTKey
structure:
[[ NOTE: RFC Editor, please replace "TBD" above with the code point
assigend by IANA ]]
struct {
opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>;
uint16 ekt_spi;
uint24 ekt_ttl;
} EKTKey;
The contents of the fields in this message are as follows:
ekt_key_value
The EKT Key that the recipient should use when generating
EKTCiphertext values
srtp_master_salt
The SRTP Master Salt to be used with any Master Key encrypted with
this EKT Key
ekt_spi
The SPI value to be used to reference this EKT Key and SRTP Master
Salt in EKT tags (along with the EKT cipher negotiated in the
handshake)
ekt_ttl
The maximum amount of time, in seconds, that this EKT Key can be
used. The ekt_key_value in this message MUST NOT be used for
encrypting or decrypting information after the TTL expires.
If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by either the
client or the server.
When an EKTKey is received and processed successfully, the recipient
MUST respond with an Ack handshake message as described in Section 7
of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be
retransmitted following the rules in Secton 4.2.4 of [RFC6347].
Note: To be clear, EKT can be used with versions of DTLS prior to
1.3. The only difference is that in a pre-1.3 TLS stacks will not
have built-in support for generating and processing Ack messages.
If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert.
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 EKTKey Reliably
The DTLS ekt_key is sent using the retransmissions specified in The DTLS EKTKey message is sent using the retransmissions specified
Section 4.2.4. of DTLS [RFC6347]. in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished
with an Ack message or an alert is received.
6. Security Considerations 6. Security Considerations
EKT inherits the security properties of the DTLS-SRTP (or other) EKT inherits the security properties of the DTLS-SRTP (or other)
keying it uses. keying it uses.
With EKT, each SRTP sender and receiver MUST generate distinct SRTP With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concern over the re- master keys. This property avoids any security concern over the re-
use of keys, by empowering the SRTP layer to create keys on demand. use of keys, by empowering the SRTP layer to create keys on demand.
Note that the inputs of EKT are the same as for SRTP with key- Note that the inputs of EKT are the same as for SRTP with key-
skipping to change at page 19, line 5 skipping to change at page 19, line 18
attempt to consume additional CPU resources of the receiving system attempt to consume additional CPU resources of the receiving system
by causing the receiving system will decrypt the EKT ciphertext and by causing the receiving system will decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the detect an authentication failure. In some cases, caching the
previous values of the Ciphertext as described in Section 4.3 helps previous values of the Ciphertext as described in Section 4.3 helps
mitigate this issue. mitigate this issue.
Each EKT cipher specifies a value T that is the maximum number of Each EKT cipher specifies a value T that is the maximum number of
times a given key can be used. An endpoint MUST NOT encrypt more times a given key can be used. An endpoint MUST NOT encrypt more
than T different Full EKT Field using the same EKTKey. In addition, than T different Full EKT Field using the same EKTKey. In addition,
the EKTKey MUST NOT be used beyond the lifetime provided by the TTL the EKTKey MUST NOT be used beyond the lifetime provided by the TTL
described in Section 5.2. described in Figure 4.
The confidentiality, integrity, and authentication of the EKT cipher The confidentiality, integrity, and authentication of the EKT cipher
MUST be at least as strong as the SRTP cipher and at least as strong MUST be at least as strong as the SRTP cipher and at least as strong
as the DTLS-SRTP ciphers. as the DTLS-SRTP ciphers.
Part of the EKTPlaintext is known, or easily guessable to an Part of the EKTPlaintext is known, or easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does not impose any restrictions on our In practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when choices, since the ciphers in use provide high security even when
much plaintext is known. much plaintext is known.
skipping to change at page 19, line 41 skipping to change at page 20, line 9
7.1. EKT Message Types 7.1. EKT Message Types
IANA is requested to create a new table for "EKT Messages Types" in IANA is requested to create a new table for "EKT Messages Types" in
the "Real-Time Transport Protocol (RTP) Parameters" registry. The the "Real-Time Transport Protocol (RTP) Parameters" registry. The
initial values in this registry are: initial values in this registry are:
+--------------+-------+---------------+ +--------------+-------+---------------+
| Message Type | Value | Specification | | Message Type | Value | Specification |
+--------------+-------+---------------+ +--------------+-------+---------------+
| Short | 0 | RFCAAAA | | Short | 0 | RFCAAAA |
| | | |
| Full | 2 | RFCAAAA | | Full | 2 | RFCAAAA |
| | | |
| Reserved | 63 | RFCAAAA | | Reserved | 63 | RFCAAAA |
| | | |
| Reserved | 255 | RFCAAAA | | Reserved | 255 | RFCAAAA |
+--------------+-------+---------------+ +--------------+-------+---------------+
Table 2: EKT Messages Types Table 2: EKT Messages Types
Note to RFC Editor: Please replace RFCAAAA with the RFC number for Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification. this specification.
New entries to this table can be added via "Specification Required" New entries to this table can be added via "Specification Required"
as defined in [RFC5226]. When requesting a new value, the requestor as defined in [RFC5226]. When requesting a new value, the requestor
skipping to change at page 20, line 30 skipping to change at page 20, line 41
7.2. EKT Ciphers 7.2. EKT Ciphers
IANA is requested to create a new table for "EKT Ciphers" in the IANA is requested to create a new table for "EKT Ciphers" in the
"Real-Time Transport Protocol (RTP) Parameters" registry. The "Real-Time Transport Protocol (RTP) Parameters" registry. The
initial values in this registry are: initial values in this registry are:
+----------+-------+---------------+ +----------+-------+---------------+
| Name | Value | Specification | | Name | Value | Specification |
+----------+-------+---------------+ +----------+-------+---------------+
| AESKW128 | 1 | RFCAAAA | | AESKW128 | 1 | RFCAAAA |
| | | |
| AESKW256 | 2 | RFCAAAA | | AESKW256 | 2 | RFCAAAA |
| | | |
| Reserved | 255 | RFCAAAA | | Reserved | 255 | RFCAAAA |
+----------+-------+---------------+ +----------+-------+---------------+
Table 3: EKT Cipher Types Table 3: EKT Cipher Types
Note to RFC Editor: Please replace RFCAAAA with the RFC number for Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification. this specification.
New entries to this table can be added via "Specification Required" New entries to this table can be added via "Specification Required"
as defined in [RFC5226]. The expert SHOULD ensure the specification as defined in [RFC5226]. The expert SHOULD ensure the specification
defines the values for L and T as required in Section 4.4 of RFCAAA. defines the values for L and T as required in Section 4.4 of RFCAAA.
Allocated values MUST be in the range of 1 to 254. Allocated values MUST be in the range of 1 to 254.
7.3. TLS Extensions 7.3. TLS Extensions
IANA is requested to add "srtp_ekt_key_transport" as an new extension IANA is requested to add supported_ekt_ciphers as a new extension
name to the "ExtensionType Values" table of the "Transport Layer name to the "ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this. Note to RFC specification and allocate a value of TBD to for this.
Editor: TBD will be allocated by IANA.
[[ Note to RFC Editor: TBD will be allocated by IANA. ]]
Considerations for this type of extension are described in Section 5 Considerations for this type of extension are described in Section 5
of [RFC4366] and requires "IETF Consensus". of [RFC4366] and requires "IETF Consensus".
7.4. TLS Content Type 7.4. TLS Handshake Type
IANA is requested to add "srtp_ekt_message" as an new descriptions IANA is requested to add ekt_key as a new entry in the "TLS
name to the "TLS ContentType Registry" table of the "Transport Layer HandshakeType Registry" table of the "Transport Layer Security (TLS)
Security (TLS) Extensions" registry with a reference to this Parameters" registry with a reference to this specification, a DTLS-
specification, a DTLS-OK value of "Y", and allocate a value of TBD to OK value of "Y", and allocate a value of TBD to for this content
for this content type. Note to RFC Editor: TBD will be allocated by type.
IANA.
[[ Note to RFC Editor: TBD will be allocated by IANA. ]]
This registry was defined in Section 12 of [RFC5246] and requires This registry was defined in Section 12 of [RFC5246] and requires
"Standards Action". "Standards Action".
8. Acknowledgements 8. Acknowledgements
Thank you to Russ Housley provided detailed review and significant Thank you to Russ Housley provided detailed review and significant
help with crafting text for this document. Thanks to David Benham, help with crafting text for this document. Thanks to David Benham,
Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul
Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean
Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions,
comments, and contributions to this document. comments, and contributions to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
editor.org/info/rfc3264>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5649>. editor.org/info/rfc5649>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-perc-double] [I-D.ietf-perc-double]
Jennings, C., Jones, P., and A. Roach, "SRTP Double Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Encryption Procedures", draft-ietf-perc-double-02 (work in Double Encryption Procedures", draft-ietf-perc-double-07
progress), October 2016. (work in progress), September 2017.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-02 Conferencing", draft-ietf-perc-private-media-framework-04
(work in progress), October 2016. (work in progress), July 2017.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [I-D.ietf-tls-dtls13]
with Session Description Protocol (SDP)", RFC 3264, Rescorla, E., Tschofenig, H., and N. Modadugu, "The
DOI 10.17487/RFC3264, June 2002, Datagram Transport Layer Security (DTLS) Protocol Version
<http://www.rfc-editor.org/info/rfc3264>. 1.3", draft-ietf-tls-dtls13-02 (work in progress), October
2017.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
editor.org/info/rfc4086>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<http://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Calgary, AB
Canada
Email: fluffy@iii.ca Email: fluffy@iii.ca
John Mattsson (editor) John Mattsson
Ericsson AB Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
David A. McGrew David A. McGrew
Cisco Systems Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
US
Phone: (408) 525 8651
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Dan Wing Dan Wing
Cisco Systems Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
US
Phone: (408) 853 4197
Email: dwing@cisco.com Email: dwing@cisco.com
Flemming Andreason Flemming Andreason
Cisco Systems Cisco Systems
499 Thornall Street
Edison, NJ 08837
US
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 93 change blocks. 
265 lines changed or deleted 284 lines changed or added

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