draft-ietf-perc-srtp-ekt-diet-03.txt   draft-ietf-perc-srtp-ekt-diet-04.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: September 14, 2017 Ericsson Expires: October 30, 2017 Ericsson
D. McGrew D. McGrew
D. Wing D. Wing
F. Andreasen F. Andreasen
Cisco Cisco
March 13, 2017 April 28, 2017
Encrypted Key Transport for Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-03 draft-ietf-perc-srtp-ekt-diet-04
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to Secure Real-time Encrypted Key Transport (EKT) is an extension to DTLS and Secure
Transport Protocol (SRTP) that provides for the secure transport of Real-time Transport Protocol (SRTP) that provides for the secure
SRTP master keys, rollover counters, and other information within transport of SRTP master keys, rollover counters, and other
SRTP. This facility enables SRTP for decentralized conferences by information within SRTP. This facility enables SRTP for
distributing a common key to all of the conference endpoints. decentralized conferences by distributing a common key to all of the
conference endpoints.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 14, 2017. This Internet-Draft will expire on October 30, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used In This Document . . . . . . . . . . . . . . 4
2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4
2.2. Packet Processing and State Machine . . . . . . . . . . . 6 4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 7 4.2. Packet Processing and State Machine . . . . . . . . . . . 7
2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 8 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8
2.3. Implementation Notes . . . . . . . . . . . . . . . . . . 9 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9
2.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10
2.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 11 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 11 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12
2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12
2.7. Timing and Reliability Consideration . . . . . . . . . . 11 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 12 4.7. Timing and Reliability Consideration . . . . . . . . . . 13
3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 13
3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 13 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14
3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 15 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14
3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 15 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19
5.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 18 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 3, line 33 skipping to change at page 3, line 35
fit, and to start up new SRTP sources with new SRTP master keys (see fit, and to start up new SRTP sources with new SRTP master keys (see
Section 2.2) within a session without coordinating with other Section 2.2) within a session without coordinating with other
entities via external signaling or other external means. entities via external signaling or other external means.
EKT provides a way for an SRTP session participant, either a sender EKT provides a way for an SRTP session participant, either a sender
or receiver, to securely transport its SRTP master key and current or receiver, to securely transport its SRTP master key and current
SRTP rollover counter to the other participants in the session. This SRTP rollover counter to the other participants in the session. This
data furnishes the information needed by the receiver to instantiate data furnishes the information needed by the receiver to instantiate
an SRTP/SRTCP receiver context. an SRTP/SRTCP receiver context.
EKT can be used in conferences where the central media distributor or
conference bridge can not decrypt the media, such as the type defined
for [I-D.ietf-perc-private-media-framework]. It can also be used for
large scale conferences where the conference bridge or media
distributor can decrypt all the media but wishes to encrypt the media
it is sending just once then send the same encrypted media to a large
number of participants. This reduces the amount of CPU time needed
for encryption and can be used for some optimization to media sending
that use source specific multicast.
EKT does not control the manner in which the SSRC is generated; it is EKT does not control the manner in which the SSRC is generated; it is
only concerned with their secure transport. only concerned with their secure transport.
EKT is not intended to replace external key establishment mechanisms. EKT is not intended to replace external key establishment mechanisms.
Instead, it is used in conjunction with those methods, and it Instead, it is used in conjunction with those methods, and it
relieves those methods of the burden to deliver the context for each relieves those methods of the burden to deliver the context for each
SRTP source to every SRTP participant. SRTP source to every SRTP participant.
1.1. Conventions Used In This Document 2. Overview
This specification defines a way for the server in a DTLS-SRTP
negotiation to provide an ekt_key to the client during the DTLS
handshake. This ekt_key can be used to encrypt the SRTP master key
used to encrypt the media the endpoint sends. This specification
also defines a way to send the encrypted SRTP master key along with
the SRTP packet. Endpoints that receive this and know the ekt_key
can use the ekt_key to decrypt the SRTP master key then use the SRTP
master key to decrypt the SRTP packet.
One way to use this is used is described in the architecture defined
by [I-D.ietf-perc-private-media-framework]. Each participants in the
conference call forms a DTLS-SRTP connection to a common key
distributor that gives all the endpoints the same ekt_key. Then each
endpoint picks there own SRTP master key for the media they send.
When sending media, the endpoint also includes the SRTP master key
encrypted with the ekt_key. This allows all the endpoints to decrypt
the media.
3. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Encrypted Key Transport 4. Encrypted Key Transport
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.
2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: EKT Ciphertext : : EKT Ciphertext :
: : : :
skipping to change at page 5, line 42 skipping to change at page 6, line 42
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. This data never appears on the wire, and is used only operation. This data never appears on the wire, and is used only
in computations internal to EKT. This is the concatenation of the in computations internal to EKT. This is the concatenation of the
SRTP Master Key, the SSRC, and the ROC. SRTP Master Key, 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 2.4. This field is included in operation, described in Section 4.4. This field is included in
SRTP packets when EKT is in use. The length of EKTCiphertext can SRTP packets when EKT is in use. The length of EKTCiphertext can
be larger than the length of the EKTPlaintext that was encrypted. be 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 [RFC3264]
SDP Offer/Answer for the SRTP. SDP Offer/Answer for the SRTP.
skipping to change at page 6, line 44 skipping to change at page 7, line 44
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 SHOULD discard the whole EKTField if it contains any receiver SHOULD discard the whole EKTField if it contains any
message type value that is less than 64 and that is not message type value that is less than 64 and that is not
understood. Message type values that are 64 or greater but not understood. Message type values that are 64 or greater but not
implemented or understood can simply be ignored. implemented or understood can simply be ignored.
2.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
sources on an endpoint each with their own EKT parameter set). All sources on an endpoint each with their own EKT parameter set). All
of the received EKT parameter sets SHOULD be stored by all of the of the received EKT parameter sets SHOULD be stored by all of the
participants in an SRTP session, for use in processing inbound SRTP participants in an SRTP session, for use in processing inbound SRTP
and SRTCP traffic. and SRTCP traffic.
Either the FullEKTField or ShortEKTField is appended at the tail end Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets. The decision on which to send is specified in of all SRTP packets. The decision on which to send is specified in
Section 2.7. Section 4.7.
2.2.1. Outbound Processing 4.2.1. Outbound Processing
See Section 2.7 which describes when to send an SRTP packet with a See Section 4.7 which describes when to send an SRTP packet with a
FullEKTField. If a FullEKTField is not being sent, then a FullEKTField. If a FullEKTField is not being sent, then a
ShortEKTField is sent so the receiver can correctly determine how to ShortEKTField is sent so the receiver can correctly determine how to
process the packet. process the packet.
When an SRTP packet is sent with a FullEKTField, the EKTField for When an SRTP packet is sent with a FullEKTField, the EKTField for
that packet is created as follows, or uses an equivalent set of that packet is created as follows, or uses an equivalent set of
steps. The creation of the EKTField MUST precede the normal SRTP steps. The creation of the EKTField MUST precede the normal SRTP
packet processing. packet processing.
1. The Security Parameter Index (SPI) field is set to the value of 1. The Security Parameter Index (SPI) field is set to the value of
the Security Parameter Index that is associated with the outbound the Security Parameter Index that is associated with the outbound
parameter set. parameter set.
2. The EKTPlaintext field is computed from the SRTP Master Key, 2. The EKTPlaintext field is computed from the SRTP Master Key,
SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP
Master Key, and SSRC used in EKT processing SHOULD be the same as Master Key, and SSRC used in EKT processing SHOULD be the same as
the one used in the SRTP processing. the one used in the SRTP processing.
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 2.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.
2.2.2. Inbound Processing 4.2.2. Inbound Processing
When receiving a packet on a RTP stream, the following steps are When receiving a packet on a RTP stream, the following steps are
applied for each received packet. applied for each received packet.
1. The final byte is checked to determine which EKT format is in 1. The final byte is checked to determine which EKT format is in
use. When an SRTP or SRTCP packet contains a ShortEKTField, the use. When an SRTP or SRTCP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP or ShortEKTField is removed from the packet then normal SRTP or
SRTCP processing occurs. If the packet contains a FullEKTField, SRTCP processing occurs. If the packet contains a FullEKTField,
then processing continues as described below. The reason for then processing continues as described below. The reason for
using the last byte of the packet to indicate the type is that using the last byte of the packet to indicate the type is that
skipping to change at page 8, line 35 skipping to change at page 9, line 35
packet. packet.
2. The Security Parameter Index (SPI) field is used to find which 2. The Security Parameter Index (SPI) field is used to find which
EKT parameter set to be used when processing the packet. If EKT parameter set to be used when processing the packet. If
there is no matching SPI, then the verification function MUST there is no matching SPI, then the verification function MUST
return an indication of authentication failure, and the steps return an indication of authentication failure, and the steps
described below are not performed. The EKT parameter set described below are not performed. The EKT parameter set
contains the EKTKey, EKTCipher, and SRTP Master Salt. contains the EKTKey, EKTCipher, and SRTP Master Salt.
3. The EKTCiphertext authentication is checked and it is decrypted, 3. The EKTCiphertext authentication is checked and it is decrypted,
as described in Section 2.4, using the EKTKey and EKTCipher found as described in Section 4.4, using the EKTKey and EKTCipher found
in the previous step. If the EKT decryption operation returns an in the previous step. If the EKT decryption operation returns an
authentication failure, then the packet processing stops. authentication failure, then the packet processing stops.
4. The resulting EKTPlaintext is parsed as described in Section 2.1, 4. The resulting EKTPlaintext is parsed as described in Section 4.1,
to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP
Master Salt that is associated with the EKTKey is also retrieved. Master Salt that is associated with the EKTKey is also retrieved.
If the value of the srtp_master_salt sent as part of the EKTkey If the value of the srtp_master_salt sent as part of the EKTkey
is longer than needed by SRTP, then it is truncated by taking the is longer than needed by SRTP, then it is truncated by taking the
first N bytes from the srtp_master_salt field. first N bytes from the srtp_master_salt field.
5. If the SSRC in the EKTPlaintext does not match the SSRC of the 5. If the SSRC in the EKTPlaintext does not match the SSRC of the
SRTP packet, then all the information from this EKTPlaintext MUST SRTP packet, then all the information from this EKTPlaintext MUST
be discarded and the following steps in this list are not done. be discarded and the following steps in this list are not done.
6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
step are saved in a map indexed by the SSRC found in the step are saved in a map indexed by the SSRC found in the
EKTPlaintext and can be used for any future crypto operations on EKTPlaintext and can be used for any future crypto operations on
the inbound packets with that SSRC. Outbound packets SHOULD the inbound packets with that SSRC. If the SRTP Master Key
continue to use the old SRTP Master Key for 250 ms after sending recovered from the EKTPlaintext is longer than needed by SRTP
any new key. This gives all the receivers in the system time to transform in use, the first bytes are used. If the SRTP Master
get the new key before they start receiving media encrypted with Key recovered from the EKTPlaintext is shorter than needed by
the new key. SRTP transform in use, then the bytes received replace the first
bytes in the existing key but the other bytes after that remain
the same as the old key. This allows for replacing just half the
key for transforms such as [I-D.ietf-perc-double]. Outbound
packets SHOULD continue to use the old SRTP Master Key for 250 ms
after sending any new key. This gives all the receivers in the
system time to get the new key before they start receiving media
encrypted with the new key.
7. At this point, EKT processing has successfully completed, and the 7. At this point, EKT processing has successfully completed, and the
normal SRTP or SRTCP processing takes place including replay normal SRTP or SRTCP processing takes place including replay
protection. protection.
2.3. Implementation Notes 4.3. Implementation Notes
The value of the EKTCiphertext field is identical in successive The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP packets protected by the same EKT parameter set and the same SRTP
master key, and ROC. This ciphertext value MAY be cached by an SRTP master key, and ROC. This ciphertext value MAY be cached by an SRTP
receiver to minimize computational effort by noting when the SRTP receiver to minimize computational effort by noting when the SRTP
master key is unchanged and avoiding repeating the above steps. master key is unchanged and avoiding repeating the above steps.
The receiver may want to have a sliding window to retain old SRTP The receiver may want to have a sliding window to retain old SRTP
master keys (and related context) for some brief period of time, so master keys (and related context) for some brief period of time, so
that out of order packets can be processed as well as packets sent that out of order packets can be processed as well as packets sent
skipping to change at page 9, line 39 skipping to change at page 10, line 46
need to create a counter that keeps track of how many times the keys need to create a counter that keeps track of how many times the keys
has been used to encrypt data to ensure it does not exceed the T has been used to encrypt data to ensure it does not exceed the T
value for that cipher. If either of these limits are exceeded, the value for that cipher. If either of these limits are exceeded, the
key can no longer be used for encryption. At this point key can no longer be used for encryption. At this point
implementation need to either use the call signaling to renegotiation implementation need to either use the call signaling to renegotiation
a new session or need to terminate the existing session. Terminating a new session or need to terminate the existing session. Terminating
the session is a reasonable implementation choice because these the session is a reasonable implementation choice because these
limits should not be exceeded except under an attack or error limits should not be exceeded except under an attack or error
condition. condition.
2.4. Ciphers 4.4. Ciphers
EKT uses an authenticated cipher to encrypt and authenticate the EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext. This specification defines the interface to the EKTPlaintext. This specification defines the interface to the
cipher, in order to abstract the interface away from the details of cipher, in order to abstract the interface away from the details of
that function. This specification also defines the default cipher that function. This specification also defines the default cipher
that is used in EKT. The default cipher described in Section 2.4.1 that is used in EKT. The default cipher described in Section 4.4.1
MUST be implemented, but another cipher that conforms to this MUST be implemented, but another cipher that conforms to this
interface MAY be used. interface MAY be used.
An EKTCipher consists of an encryption function and a decryption An EKTCipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following function. The encryption function E(K, P) takes the following
inputs: inputs:
o a secret key K with a length of L bytes, and o a secret key K with a length of L bytes, and
o a plaintext value P with a length of M bytes. o a plaintext value P with a length of M bytes.
skipping to change at page 10, line 29 skipping to change at page 11, line 36
because the ciphertext was invalid (i.e. it was not generated by the because the ciphertext was invalid (i.e. it was not generated by the
encryption of plaintext with the key K). encryption of plaintext with the key K).
These functions have the property that D(K, E(K, P)) = P for all These functions have the property that D(K, E(K, P)) = P for all
values of K and P. Each cipher also has a limit T on the number of values of K and P. Each cipher also has a limit T on the number of
times that it can be used with any fixed key value. The EKTKey MUST times that it can be used with any fixed key value. The EKTKey MUST
NOT be used for encryption more that T times. Note that if the same NOT be used for encryption more that T times. Note that if the same
FullEKTField is retransmitted 3 times, that only counts as 1 FullEKTField is retransmitted 3 times, that only counts as 1
encryption. encryption.
Security requirements for EKT ciphers are discussed in Section 4. Security requirements for EKT ciphers are discussed in Section 6.
2.4.1. Ciphers 4.4.1. Ciphers
The default EKT Cipher is the Advanced Encryption Standard (AES) Key The default EKT Cipher is the Advanced Encryption Standard (AES) Key
Wrap with Padding [RFC5649] algorithm. It requires a plaintext Wrap with Padding [RFC5649] algorithm. It requires a plaintext
length M that is at least one octet, and it returns a ciphertext with length M that is at least one octet, and it returns a ciphertext with
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.
skipping to change at page 11, line 8 skipping to change at page 12, line 18
| 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 [RFC3711],
AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented.
2.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 5. 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
field in any way, but they SHOULD NOT use other EKT or SRTP fields as field in any way, but they SHOULD NOT use other EKT or SRTP fields as
an input. The values of the parameters L, and T MUST be defined by an input. The values of the parameters L, and T MUST be defined by
each EKTCipher. The cipher MUST provide integrity protection. each EKTCipher. The cipher MUST provide integrity protection.
2.5. Synchronizing Operation 4.5. Synchronizing Operation
If a source has its EKTKey changed by the key management, it MUST If a source has its EKTKey changed by the key management, it MUST
also change its SRTP master key, which will cause it to send out a also change its SRTP master key, which will cause it to send out a
new FullEKTField. This ensures that if key management thought the new FullEKTField. This ensures that if key management thought the
EKTKey needs changing (due to a participant leaving or joining) and EKTKey needs changing (due to a participant leaving or joining) and
communicated that to a source, the source will also change its SRTP communicated that to a source, the source will also change its SRTP
master key, so that traffic can be decrypted only by those who know master key, so that traffic can be decrypted only by those who know
the current EKTKey. the current EKTKey.
2.6. Transport 4.6. Transport
EKT SHOULD be used over SRTP, and other specification MAY define how EKT SHOULD be used over SRTP, and other specification MAY define how
to use it over SRTCP. SRTP is preferred because it shares fate with to use it over SRTCP. SRTP is preferred because it shares fate with
transmitted media, because SRTP rekeying can occur without concern transmitted media, because SRTP rekeying can occur without concern
for RTCP transmission limits, and to avoid SRTCP compound packets for RTCP transmission limits, and to avoid SRTCP compound packets
with RTP translators and mixers. with RTP translators and mixers.
2.7. Timing and Reliability Consideration 4.7. Timing and Reliability Consideration
A system using EKT learns the SRTP master keys distributed with A system using EKT learns the SRTP master keys distributed with
FullEKTFields sent with the SRTP, rather than with call signaling. A FullEKTFields sent with the SRTP, rather than with call signaling. A
receiver can immediately decrypt an SRTP packet, provided the SRTP receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a Full EKT Field. packet contains a Full EKT Field.
This section describes how to reliably and expediently deliver new This section describes how to reliably and expediently deliver new
SRTP master keys to receivers. SRTP master keys to receivers.
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
skipping to change at page 12, line 32 skipping to change at page 13, line 47
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.
3. 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 one DTLS-SRTP peer to another. This allows those peers to process
EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP
keying material. This combination of protocols is valuable because keying material. This combination of protocols is valuable because
it combines the advantages of DTLS, which has strong authentication it combines the advantages of DTLS, which has strong authentication
of the endpoint and flexibility, along with allowing secure of the endpoint and flexibility, along with allowing secure
multiparty RTP with loose coordination and efficient communication of multiparty RTP with loose coordination and efficient communication of
per-source keys. per-source keys.
3.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.
3.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 called
"srtp_ekt_key_transport"and a new TLS content type called EKTMessage. "srtp_ekt_key_transport"and a new TLS content type called EKTMessage.
Using the syntax described in DTLS [RFC6347], the following Using the syntax described in DTLS [RFC6347], the following
structures are used: structures are used:
enum { enum {
reserved(0), reserved(0),
aeskw_128(1), aeskw_128(1),
skipping to change at page 14, line 27 skipping to change at page 16, line 19
extension_data for the extension, listing the EKTCipherTypes the extension_data for the extension, listing the EKTCipherTypes the
client is willing to use in preference order, with the most preferred client is willing to use in preference order, with the most preferred
version first. When the server responds in the version first. When the server responds in the
"srtp_ekt_key_transport" in its ServerHello message, it MUST include "srtp_ekt_key_transport" in its ServerHello message, it MUST include
a SupportedEKTCiphers list that selects a single EKTCipherType to use a SupportedEKTCiphers list that selects a single EKTCipherType to use
(selected from the list provided by the client) or it returns an (selected from the list provided by the client) or it returns an
empty list to indicate there is no matching EKTCipherType in the 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 clients list that the server is also willing to use. The value to be
used in the EKTCipherType for future extensions that define new used in the EKTCipherType for future extensions that define new
ciphers is the value from the "EKT Ciphers Type" IANA registry ciphers is the value from the "EKT Ciphers Type" IANA registry
defined in Section 5.2. defined in Section 7.2.
The figure above defines the contents for a new TLS content type The figure above defines the contents for a new TLS content type
called EKTMessage which is registered in Section 5.4. The EKTMessage called EKTMessage which is registered in Section 7.4. The EKTMessage
above is used as the opaque fragment in the TLSPlaintext structure 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 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 the content type. The "srtp_ekt_message" content type is defined and
registered in Section 5.3. registered in Section 7.3.
ekt_ttl: The maximum amount of time, in seconds, that this ekt_ttl: The maximum amount of time, in seconds, that this
ekt_key_value can be used. The ekt_key_value in this message MUST ekt_key_value can be used. The ekt_key_value in this message MUST
NOT be used for encrypting or decrypting information after the TTL NOT be used for encrypting or decrypting information after the TTL
expires. expires.
When the Server wishes to provide a new EKT Key, it can send When the Server wishes to provide a new EKT Key, it can send
EKTMessage containing an EKTKey with the new key information. The EKTMessage containing an EKTKey with the new key information. The
client MUST respond with an EKTMessage of type ekt_key_ack, if 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 EKTKey was successfully processed and stored or respond with the the
skipping to change at page 15, 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
3.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.
3.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].
4. 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-
sharing: a single key is provided to protect an entire SRTP session. sharing: a single key is provided to protect an entire SRTP session.
However, EKT remains secure even when SSRC values collide. However, EKT remains secure even when SSRC values collide.
skipping to change at page 16, line 37 skipping to change at page 18, line 37
decrypt the SRTP payload, would be wrong and the SRTP integrity check decrypt the SRTP payload, would be wrong and the SRTP integrity check
would fail. Note that the FullEKTField only changes the decryption would fail. Note that the FullEKTField only changes the decryption
key and does not change the encryption key. None of these are key and does not change the encryption key. None of these are
considered significant attacks as any attacker that can modify the considered significant attacks as any attacker that can modify the
packets in transit and cause the integrity check to fail. packets in transit and cause the integrity check to fail.
An attacker could send packets containing a Full EKT Field, in an An attacker could send packets containing a Full EKT Field, in an
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 2.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 3.2. described in Section 5.2.
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
skipping to change at page 17, line 21 skipping to change at page 19, line 21
both the encryption and decryption functions adaptively. both the encryption and decryption functions adaptively.
In some systems, when a member of a conference leaves the In some systems, when a member of a conference leaves the
conferences, the conferences is rekeyed so that member no longer has conferences, the conferences is rekeyed so that member no longer has
the key. When changing to a new EKTKey, it is possible that the the key. When changing to a new EKTKey, it is possible that the
attacker could block the EKTKey message getting to a particular attacker could block the EKTKey message getting to a particular
endpoint and that endpoint would keep sending media encrypted using endpoint and that endpoint would keep sending media encrypted using
the old key. To mitigate that risk, the lifetime of the EKTKey the old key. To mitigate that risk, the lifetime of the EKTKey
SHOULD be limited using the ekt_ttl. SHOULD be limited using the ekt_ttl.
5. IANA Considerations 7. IANA Considerations
5.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 |
| | | | | | | |
skipping to change at page 18, line 10 skipping to change at page 20, line 10
needs to indicate if it is mandatory to understand or not. If it is needs to indicate if it is mandatory to understand or not. If it is
mandatory to understand, IANA needs to allocate a value less than 64, mandatory to understand, IANA needs to allocate a value less than 64,
if it is not mandatory to understand, a value greater than or equal if it is not mandatory to understand, a value greater than or equal
to 64 needs to be allocated. IANA SHOULD prefer allocation of even to 64 needs to be allocated. IANA SHOULD prefer allocation of even
values over odd ones until the even code points are consumed to avoid values over odd ones until the even code points are consumed to avoid
conflicts with pre standard versions of EKT that have been deployed. conflicts with pre standard versions of EKT that have been deployed.
All new EKT messages MUST be defined to have a length as second from All new EKT messages MUST be defined to have a length as second from
the last element. the last element.
5.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 |
| | | | | | | |
skipping to change at page 18, line 33 skipping to change at page 20, line 33
| 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 2.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.
5.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 "srtp_ekt_key_transport" as an 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. Note to RFC
Editor: TBD will be allocated by IANA. 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".
5.4. TLS Content Type 7.4. TLS Content Type
IANA is requested to add "srtp_ekt_message" as an new descriptions IANA is requested to add "srtp_ekt_message" as an new descriptions
name to the "TLS ContentType Registry" table of the "Transport Layer name to the "TLS ContentType Registry" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this Security (TLS) Extensions" registry with a reference to this
specification, a DTLS-OK value of "Y", and allocate a value of TBD to specification, a DTLS-OK value of "Y", and allocate a value of TBD to
for this content type. Note to RFC Editor: TBD will be allocated by for this content type. Note to RFC Editor: TBD will be allocated by
IANA. 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".
6. 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.
7. References 9. References
7.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>. <http://www.rfc-editor.org/info/rfc3711>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <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", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-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, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-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, DOI (AES) Key Wrap with Padding Algorithm", RFC 5649,
10.17487/RFC5649, September 2009, DOI 10.17487/RFC5649, September 2009,
<http://www.rfc-editor.org/info/rfc5649>. <http://www.rfc-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, DOI Real-time Transport Protocol (SRTP)", RFC 5764,
10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://www.rfc-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, <http://www.rfc-editor.org/info/rfc6347>.
7.2. Informative References 9.2. Informative References
[I-D.ietf-perc-double]
Jennings, C., Jones, P., and A. Roach, "SRTP Double
Encryption Procedures", draft-ietf-perc-double-02 (work in
progress), October 2016.
[I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-02
(work in progress), October 2016.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, DOI with Session Description Protocol (SDP)", RFC 3264,
10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
[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>. <http://www.rfc-editor.org/info/rfc4366>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Calgary, AB Calgary, AB
Canada Canada
Email: fluffy@iii.ca Email: fluffy@iii.ca
John Mattsson (editor) John Mattsson (editor)
Ericsson AB Ericsson AB
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Phone: +46 10 71 43 501 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
 End of changes. 60 change blocks. 
101 lines changed or deleted 151 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/