draft-ietf-perc-srtp-ekt-diet-09.txt   draft-ietf-perc-srtp-ekt-diet-10.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Mattsson Intended status: Standards Track J. Mattsson
Expires: April 20, 2019 Ericsson AB Expires: January 9, 2020 Ericsson AB
D. McGrew D. McGrew
Cisco Systems Cisco Systems
D. Wing D. Wing
F. Andreason F. Andreason
Cisco Systems Cisco Systems
October 17, 2018 July 8, 2019
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-09 draft-ietf-perc-srtp-ekt-diet-10
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
Transport Layer Security) and Secure Real-time Transport Protocol Transport Layer Security) and Secure Real-time Transport Protocol
(SRTP) that provides for the secure transport of SRTP master keys, (SRTP) that provides for the secure transport of SRTP master keys,
rollover counters, and other information within SRTP. This facility rollover counters, and other information within SRTP. This facility
enables SRTP for decentralized conferences by distributing a common enables SRTP for decentralized conferences by distributing a common
key to all of the conference endpoints. key to all of the conference endpoints.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 20, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Processing and State Machine . . . . . . . . . . . 7 4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8
4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 4.3. Packet Processing and State Machine . . . . . . . . . . . 8
4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 8
4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10
4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12
4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13
4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13
4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Timing and Reliability Consideration . . . . . . . . . . 13
4.7. Timing and Reliability Consideration . . . . . . . . . . 13
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14
5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15
5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 16 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17
5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19
5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 20 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21
7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 22
7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
conservation. Additionally, in many situations SRTP is used in conservation. Additionally, in many situations SRTP is used in
conjunction with a signaling system that can provide the central conjunction with a signaling system that can provide the central
control needed by SRTP. However, there are several cases in which control needed by SRTP. However, there are several cases in which
conventional signaling systems cannot easily provide all of the conventional signaling systems cannot easily provide all of the
coordination required. It is also desirable to eliminate the layer coordination required.
violations that occur when signaling systems coordinate certain SRTP
parameters, such as SSRC values and ROCs.
This document defines Encrypted Key Transport (EKT) for SRTP and This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a reduces the amount of external signaling control that is needed in a
SRTP session with multiple receivers. EKT securely distributes the SRTP session with multiple receivers. EKT securely distributes the
SRTP master key and other information for each SRTP source. With SRTP master key and other information for each SRTP source. With
this method, SRTP entities are free to choose SSRC values as they see this method, SRTP entities are free to choose SSRC values as they see
fit, and to start up new SRTP sources with new SRTP master keys fit, and to start up new SRTP sources with new SRTP master keys
within a session without coordinating with other entities via within a session without coordinating with other entities via
external signaling or other external means. external signaling or other external means.
EKT provides a way for an SRTP session participant, to securely EKT extends DTLS and SRTP to enable a common key encryption key
transport its SRTP master key and current SRTP rollover counter to (called an EKTKey) to be distributed to all endpoints, so that each
the other participants in the session. This data furnishes the endpoint can securely send its SRTP master key and current SRTP
information needed by the receiver to instantiate an SRTP/SRTCP rollover counter to the other participants in the session. This data
receiver context. furnishes the information needed by the receiver to instantiate an
SRTP/SRTCP receiver context.
EKT can be used in conferences where the central media distributor or EKT can be used in conferences where the central media distributor or
conference bridge cannot decrypt the media, such as the type defined conference bridge cannot decrypt the media, such as the type defined
for [I-D.ietf-perc-private-media-framework]. It can also be used for for [I-D.ietf-perc-private-media-framework]. It can also be used for
large scale conferences where the conference bridge or media large scale conferences where the conference bridge or media
distributor can decrypt all the media but wishes to encrypt the media distributor can decrypt all the media but wishes to encrypt the media
it is sending just once and then send the same encrypted media to a it is sending just once and then send the same encrypted media to a
large number of participants. This reduces the amount of CPU time large number of participants. This reduces the amount of CPU time
needed for encryption and can be used for some optimization to media needed for encryption and can be used for some optimization to media
sending that use source specific multicast. 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
only concerned with their secure transport. is only concerned with distributing the security parameters that an
endpoint needs to associate with a given SSRC in order to decrypt
SRTP packets from that sender.
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. This document defines how EKT
works with the DTLS-SRTP approach to key establishment, by using keys
derived from the DTLS-SRTP handshake to encipher the EKTKey in
addition to the SRTP media.
2. Overview 2. Overview
This specification defines a way for the server in a DTLS-SRTP This specification defines a way for the server in a DTLS-SRTP
negotiation, see Section 5, to provide an EKTKey to the client during negotiation, see Section 5, to provide an EKTKey to the client during
the DTLS handshake. The EKTKey thus obtained can be used to encrypt the DTLS handshake. The EKTKey thus obtained can be used to encrypt
the SRTP master key that is used to encrypt the media sent by the the SRTP master key that is used to encrypt the media sent by the
endpoint. This specification also defines a way to send the endpoint. This specification also defines a way to send the
encrypted SRTP master key (with the EKTKey) along with the SRTP encrypted SRTP master key (with the EKTKey) along with the SRTP
packet, see Section 4. Endpoints that receive this and know the packet, see Section 4. Endpoints that receive this and know the
skipping to change at page 5, line 11 skipping to change at page 5, line 14
appears at the end of the SRTP packet. It appears after the optional appears at the end of the SRTP packet. It appears after the optional
authentication tag if one is present, otherwise the EKTField appears authentication tag if one is present, otherwise the EKTField 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.
This document defines the use of EKT with SRTP. Its use with SRTCP
would be similar, but is reserved for a future specification. SRTP
is preferred for transmitting key material because it shares fate
with the transmitted media, because SRTP rekeying can occur without
concern for RTCP transmission limits, and because it avoids the need
for SRTCP compound packets with RTP translators and mixers.
4.1. EKTField Formats 4.1. EKTField Formats
The EKTField uses the format defined in Figure 1 for the FullEKTField The EKTField uses the format defined in Figure 1 for the FullEKTField
and ShortEKTField. and 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 6, line 14 skipping to change at page 6, line 16
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)
Epoch = 2BYTE
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull FullEKTField = EKTCiphertext SPI Epoch 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 operation. EKTPlaintext: The data that is input to the EKT encryption operation.
This data never appears on the wire, and is used only in computations This data never appears on the wire, and is used only in computations
skipping to change at page 7, line 6 skipping to change at page 7, line 10
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 SDP Offer/ depends on the cipher suite negotiated for SRTP using SDP Offer/
Answer [RFC3264] for the SRTP. Answer [RFC3264] for the SRTP.
SSRC: On the sender side, this is the SSRC for this SRTP source. The SSRC: On the sender side, this is the SSRC for this SRTP source. The
length of this field is 32 bits. length of this field is 32 bits. The SSRC value in the EKT tag MUST
be the same as the one in the header of the SRTP packet to which the
tag is appended.
Rollover Counter (ROC): On the sender side, this is set to the Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP/SRTCP context current value of the SRTP rollover counter in the SRTP/SRTCP context
associated with the SSRC in the SRTP or SRTCP packet. The length of associated with the SSRC in the SRTP or SRTCP packet. The length 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
EKTKey and other parameters for the receiver to use when processing EKTKey and other parameters for the receiver to use when processing
the packet. The length of this field is 16 bits. The parameters the packet, within a given conference. The length of this field is
identified by this field are: 16 bits, representing a two-byte integer in network byte order. The
parameters identified by this field are:
o The EKT cipher used to process the packet. o The EKT cipher used to process the packet.
o The EKTKey used to process the packet. o The EKTKey used to process the packet.
o The SRTP Master Salt associated with any master key encrypted with o The SRTP Master Salt associated with any master key encrypted with
this EKT Key. The master salt is communicated separately, via this EKT Key. The master salt is communicated separately, via
signaling, typically along with the EKTKey. signaling, typically along with the EKTKey. (Recall that the SRTP
master salt is used in the formation of IVs / nonces.)
Epoch: This field indicates how many SRTP keys have been sent for
this SSRC under the current EKTKey, prior to the current key, as a
two-byte integer in network byte order. It starts at zero at the
beginning of a session and resets to zero whenever the EKTKey is
changed (i.e., when a new SPI appears). The epoch for an SSRC
increments by one every time the sender transmits a new key. The
recipient of a FullEKTField MUST reject any future FullEKTField for
this SPI and SSRC that has an equal or lower epoch value to an epoch
already seen.
Together, these data elements are called an EKT parameter set. Each Together, these data elements are called an EKT parameter set. Each
distinct EKT parameter set that is used MUST be associated with a distinct EKT parameter set that is used MUST be associated with a
distinct SPI value to avoid ambiguity. distinct SPI value to avoid ambiguity.
EKTMsgLength: All EKT messages types other than the ShortEKTField EKTMsgLength: All EKT messages types other than the ShortEKTField
have a length as second from the last element. This is the length in have a length as second from the last element. This is the length in
octets of either the FullEKTField/ExtensionEKTField including this octets (in network byte order) of either the FullEKTField/
length field and the following EKT Message Type. ExtensionEKTField including this length field and the following EKT
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 for the FullEKTField format and 0 in EKTField. This MUST be 2 for the FullEKTField format and 0 in
ShortEKTField format. Values less than 64 are mandatory to ShortEKTField format. If a received EKT tag has an unknown message
understand while other values are optional to understand. A receiver type, then the receiver MUST discard the whole EKT tag.
SHOULD discard the whole EKTField if it contains any message type
value that is less than 64 and that is not understood. Message type
values that are 64 or greater but not implemented or understood can
simply be ignored.
4.2. Packet Processing and State Machine 4.2. SPIs and EKT Parameter Sets
The SPI field identifies the parameters for how the EKT tag should be
processed:
o The EKTKey and EKT cipher used to process the packet.
o The SRTP Master Salt associated with any master key encrypted with
this EKT Key. The master salt is communicated separately, via
signaling, typically along with the EKTKey.
Together, these data elements are called an "EKT parameter set".
Each distinct EKT parameter set that is used MUST be associated with
a distinct SPI value to avoid ambiguity. The association of a given
parameter set with a given SPI value is configured by some other
protocol, e.g., the DTLS-SRTP extension defined in Section 5.
4.3. 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. If a participant deletes an EKT parameter set
(e.g., because of space limitations, then it will be unable to
process Full EKT Tags containing updated media keys, and thus unable
to receive media from a particpant that has changed its media key.
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 when is specified of all SRTP packets. The decision on which to send when is specified
in Section 4.7. in Section 4.6.
4.2.1. Outbound Processing 4.3.1. Outbound Processing
See Section 4.7 which describes when to send an SRTP packet with a See Section 4.6 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 4.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 MUST 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 EKTCipher using the EKTKey encrypting the EKTPlaintext with the EKTCipher 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 SRTP The computed value of the FullEKTField is appended to the end of the
packet. SRTP packet, after the encrypted payload.
When a packet is sent with the ShortEKTField, the ShortEKFField is When a packet is sent with the ShortEKTField, the ShortEKFField is
simply appended to the packet. simply appended to the packet.
Outbound packets SHOULD continue to use the old SRTP Master Key for 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 250 ms after sending any new key in a FullEKTField value. This gives
the system time to get the new key before they start receiving media all the receivers in the system time to get the new key before they
encrypted with the new key. start receiving media encrypted with the new key. (The specific
value of 250ms is chosen to represent a reasonable upper bound on the
amount of latency and jitter that is tolerable in a real-time
context.)
4.2.2. Inbound Processing 4.3.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 SRTP received packet. applied for each SRTP 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 10, line 33 skipping to change at page 11, line 23
specifies that this length is acceptable, then the SRTP Master specifies that this length is acceptable, then the SRTP Master
Key value is used to replace the first bytes in the existing Key value is used to replace the first bytes in the existing
master key. The other bytes remain the same as in the old master key. The other bytes remain the same as in the old
key. For example, the Double GCM transform key. For example, the Double GCM transform
[I-D.ietf-perc-double] allows replacement of the first, "end [I-D.ietf-perc-double] allows replacement of the first, "end
to end" half of the master key. to end" half of the master 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. normal SRTP or SRTCP processing takes place.
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. SRTP senders and receivers MAY cache an master key, and ROC. SRTP senders and receivers MAY cache an
EKTCiphertext value to optimize processing in cases where the master EKTCiphertext value to optimize processing in cases where the master
key hasn't changed. Instead of encrypting and decrypting, senders key hasn't changed. Instead of encrypting and decrypting, senders
can simply copy the pre-computed value and receivers can compare a can simply copy the pre-computed value and receivers can compare a
received EKTCiphertext to the known value. received EKTCiphertext to the known value.
Section 4.2.1 recommends that SRTP senders continue using an old key Section 4.3.1 recommends that SRTP senders continue using an old key
for some time after sending a new key in an EKT tag. Receivers that for some time after sending a new key in an EKT tag. Receivers that
wish to avoid packet loss due to decryption failures MAY perform wish to avoid packet loss due to decryption failures MAY perform
trial decryption with both the old key and the new key, keeping the trial decryption with both the old key and the new key, keeping the
result of whichever decryption succeeds. Note that this approach is result of whichever decryption succeeds. Note that this approach is
only compatible with SRTP transforms that include integrity only compatible with SRTP transforms that include integrity
protection. protection.
When receiving a new EKTKey, implementations need to use the ekt_ttl When receiving a new EKTKey, implementations need to use the ekt_ttl
field (see Section 5.2.2) to create a time after which this key field (see Section 5.2.2) to create a time after which this key
cannot be used and they also need to create a counter that keeps cannot be used and they also need to create a counter that keeps
track of how many times the key has been used to encrypt data to track of how many times the key has been used to encrypt data to
ensure it does not exceed the T value for that cipher (see ). If ensure it does not exceed the T value for that cipher (see
either of these limits are exceeded, the key can no longer be used Section 4.4). If either of these limits are exceeded, the key can no
for encryption. At this point implementation need to either use the longer be used for encryption. At this point implementation need to
call signaling to renegotiate a new session or need to terminate the either use the call signaling to renegotiate a new session or need to
existing session. Terminating the session is a reasonable terminate the existing session. Terminating the session is a
implementation choice because these limits should not be exceeded reasonable implementation choice because these limits should not be
except under an attack or error condition. exceeded except under an attack or error condition.
4.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 4.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. The cipher used for a given EKTCiphertext
value is negotiated using the supported_ekt_ciphers and indicated
with the SPI value in the FullEKTField.
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.
The encryption function returns a ciphertext value C whose length is The encryption function returns a ciphertext value C whose length is
skipping to change at page 12, line 7 skipping to change at page 12, line 47
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 6. Security requirements for EKT ciphers are discussed in Section 6.
4.4.1. Ciphers 4.4.1. AES Key Wrap
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. 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 It can be used with key sizes of L = 16, and L = 32 octets, and its
use with those key sizes is indicated as AESKW128, or AESKW256, use with those key sizes is indicated as AESKW128, or AESKW256,
respectively. The key size determines the length of the AES key used respectively. The key size determines the length of the AES key used
by the Key Wrap algorithm. With this cipher, T=2^48. by the Key Wrap algorithm. 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 |
skipping to change at page 13, line 5 skipping to change at page 13, line 45
4.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.
4.6. Transport 4.6. Timing and Reliability Consideration
This document defines the use of EKT with SRTP. Its use with SRTCP
would be similar, but is reserved for a future specification. SRTP
is preferred for transmitting key material because it shares fate
with the transmitted media, because SRTP rekeying can occur without
concern for RTCP transmission limits, and because it avoids the need
for SRTCP compound packets with RTP translators and mixers.
4.7. Timing and Reliability Consideration
A system using EKT learns the SRTP master keys distributed with the A system using EKT learns the SRTP master keys distributed with the
FullEKTField sent with the SRTP, rather than with call signaling. A FullEKTField 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 FullEKTField. packet contains a FullEKTField.
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 13, line 41 skipping to change at page 14, line 25
The three cases are: The three cases are:
New sender: New sender:
A new sender SHOULD send a packet containing the FullEKTField as A new sender SHOULD send a packet containing the FullEKTField as
soon as possible, always before or coincident with sending its soon as possible, always before or coincident with sending its
initial SRTP packet. To accommodate packet loss, it is initial SRTP packet. To accommodate packet loss, it is
RECOMMENDED that three consecutive packets contain the RECOMMENDED that three consecutive packets contain the
FullEKTField be transmitted. If the sender does not send a FullEKTField be transmitted. If the sender does not send a
FullEKTField in its initial packets and receivers have not FullEKTField in its initial packets and receivers have not
otherwise been provisioned with a decryption key, then decryption otherwise been provisioned with a decryption key, then decryption
will fail and SRTP packets will be dropped until the the receives will fail and SRTP packets will be dropped until the receiver
a FullEKTField from the sender. receives a FullEKTField from the sender.
Rekey: Rekey:
By sending EKT tag over SRTP, the rekeying event shares fate with By sending EKT tag over SRTP, the rekeying event shares fate with
the SRTP packets protected with that new SRTP master key. To 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: New receiver:
When a new receiver joins a session it does not need to When a new receiver joins a session it does not need to
communicate its sending SRTP master key (because it is a communicate its sending SRTP master key (because it is a
skipping to change at page 14, line 26 skipping to change at page 15, line 10
This document defines an extension to DTLS-SRTP called SRTP EKTKey This document defines an extension to DTLS-SRTP called SRTP EKTKey
Transport which enables secure transport of EKT keying material from Transport which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client. This allows the DTLS-SRTP peer in the server role to the client. This allows
those peers to process EKT keying material in SRTP (or SRTCP) and those peers to process EKT keying material in SRTP (or SRTCP) and
retrieve the embedded SRTP keying material. This combination of retrieve the embedded SRTP keying material. This combination of
protocols is valuable because it combines the advantages of DTLS, protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility, which has strong authentication of the endpoint and flexibility,
along with allowing secure multiparty RTP with loose coordination and along with allowing secure multiparty RTP with loose coordination and
efficient communication of per-source keys. efficient communication of per-source keys.
In cases where the DTLS termination point is more trusted than the
media relay, the protection that DTLS affords to EKT key material can
allow EKT keys to be tunneled through an untrusted relay such as a
centralized conference bridge. For more details, see
[I-D.ietf-perc-private-media-framework].
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
skipping to change at page 15, line 4 skipping to change at page 15, line 39
This document defines a new TLS negotiated extension This document defines a new TLS negotiated extension
supported_ekt_ciphers and a new TLS handshake message type ekt_key. supported_ekt_ciphers and a new TLS handshake message type ekt_key.
The extension negotiates the cipher to be used in encrypting and The extension negotiates the cipher to be used in encrypting and
decrypting EKTCiphertext values, and the handshake message carries decrypting EKTCiphertext values, and the handshake message carries
the corresponding key. the corresponding key.
Figure 4 shows a message flow of DTLS 1.3 client and server using EKT Figure 4 shows a message flow of DTLS 1.3 client and server using EKT
configured using the DTLS extensions described in this section. (The configured using the DTLS extensions described in this section. (The
initial cookie exchange and other normal DTLS messages are omitted.) initial cookie exchange and other normal DTLS messages are omitted.)
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.
Client Server Client Server
ClientHello ClientHello
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
+ use_srtp + use_srtp
skipping to change at page 16, line 26 skipping to change at page 17, line 26
To indicate its support for EKT, a DTLS-SRTP client includes in its To indicate its support for EKT, a DTLS-SRTP client includes in its
ClientHello an extension of type supported_ekt_ciphers listing the ClientHello an extension of type supported_ekt_ciphers listing the
ciphers used for EKT by the client supports in preference order, with ciphers used for EKT by the client supports in preference order, with
the most preferred version first. If the server agrees to use EKT, the most preferred version first. If the server agrees to use EKT,
then it includes a supported_ekt_ciphers extension in its ServerHello then it includes a supported_ekt_ciphers extension in its ServerHello
containing a cipher selected from among those advertised by the containing a cipher selected from among those advertised by the
client. client.
The extension_data field of this extension contains an "EKTCipher" The extension_data field of this extension contains an "EKTCipher"
value, encoded using the syntax defined in [RFC5246]: value, encoded using the syntax defined in [RFC8446]:
enum { enum {
reserved(0), reserved(0),
aeskw_128(1), aeskw_128(1),
aeskw_256(2), aeskw_256(2),
} EKTCipherType; } EKTCipherType;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
skipping to change at page 17, line 44 skipping to change at page 18, line 44
If the server did not provide a supported_ekt_ciphers extension in If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by the client its ServerHello, then EKTKey messages MUST NOT be sent by the client
or the server. or the server.
When an EKTKey is received and processed successfully, the recipient When an EKTKey is received and processed successfully, the recipient
MUST respond with an Ack handshake message as described in Section 7 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 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be
retransmitted following the rules in Section 4.2.4 of [RFC6347]. retransmitted following the rules in Section 4.2.4 of [RFC6347].
Note: To be clear, EKT can be used with versions of DTLS prior to EKT MAY be used with versions of DTLS prior to 1.3. In such cases,
1.3. The only difference is that in a pre-1.3 TLS stacks will not the Ack message is still used to provide reliability. Thus, DTLS
have built-in support for generating and processing Ack messages. implementations supporting EKT with DTLS pre-1.3 will need to have
explicit affordances for sending the Ack message in response to an
EKTKey message, and for verifying that an Ack message was received.
The retransmission rules for both sides are the same as in DTLS 1.3.
If an EKTKey message is received that cannot be processed, then the If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert. 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.
skipping to change at page 18, line 42 skipping to change at page 19, line 42
NOT be re-used for any other purpose, and SRTP master keys MUST NOT NOT be re-used for any other purpose, and SRTP master keys MUST NOT
be derived from other SRTP master keys. be derived from other SRTP master keys.
The EKT Cipher includes its own authentication/integrity check. For The EKT Cipher includes its own authentication/integrity check. For
an attacker to successfully forge a FullEKTField, it would need to an attacker to successfully forge a FullEKTField, it would need to
defeat the authentication mechanisms of the EKT Cipher authentication defeat the authentication mechanisms of the EKT Cipher authentication
mechanism. mechanism.
The presence of the SSRC in the EKTPlaintext ensures that an attacker The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream. SRTP stream. This mitigates the impact of the cut-and-paste attacks
that arise due to the lack of a cryptographic binding between the EKT
An attacker who tampers with the bits in FullEKTField can prevent the tag and the rest of the SRTP packet. SRTP tags can only be cut-and-
intended receiver of that packet from being able to decrypt it. This pasted within the stream of packets sent by a given RTP endpoint; an
is a minor denial of service vulnerability. Similarly the attacker attacker cannot "cross the streams" and use an EKT tag from one SSRC
could take an old FullEKTField from the same session and attach it to to reset the key for another SSRC. The epoch field in the
the packet. The FullEKTField would correctly decode and pass FullEKTField also prevents an attacker from rolling back to a
integrity checks. However, the key extracted from the FullEKTField , previous key.
when used to decrypt the SRTP payload, would be wrong and the SRTP
integrity check would fail. Note that the FullEKTField only changes
the decryption key and does not change the encryption key. None of
these are considered significant attacks as any attacker that can
modify the packets in transit and cause the integrity check to fail.
An attacker could send packets containing a FullEKTField, in an An attacker could send packets containing a FullEKTField, 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 to decrypt the EKT ciphertext and by causing the receiving system to 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.2 helps
mitigate this issue. mitigate this issue.
In a similar vein, EKT has no replay protection, so an attacker could In a similar vein, EKT has no replay protection, so an attacker could
implant improper keys in receivers by capturing EKTCiphertext values implant improper keys in receivers by capturing EKTCiphertext values
encrypted with a given EKTKey and replaying them in a different encrypted with a given EKTKey and replaying them in a different
context, e.g., from a different sender. When the underlying SRTP context, e.g., from a different sender. When the underlying SRTP
transform provides integrity protection, this attack will just result transform provides integrity protection, this attack will just result
in packet loss. If it does not, then it will result in random data in packet loss. If it does not, then it will result in random data
being fed to RTP payload processing. An attacker that is in a being fed to RTP payload processing. An attacker that is in a
position to mount these attacks, however, could achieve the same position to mount these attacks, however, could achieve the same
effects more easily without attacking EKT. effects more easily without attacking EKT.
The key encryption keys distributed with EKTKey messages are group
shared symmetric keys, which means they do not provide protection
within the group. Group members can impersonate each other; for
example, any group member can generate an EKT tag for any SSRC. The
entity that distributes EKTKeys can decrypt any keys distributed
using EKT, and thus any media protected with those keys.
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 FullEKTField values using the same EKTKey. In than T different FullEKTField values using the same EKTKey. In
addition, the EKTKey MUST NOT be used beyond the lifetime provided by addition, the EKTKey MUST NOT be used beyond the lifetime provided by
the TTL described in Section 5.2. the TTL 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.
skipping to change at page 20, line 18 skipping to change at page 21, line 20
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 | | Unallocated | 3-254 | 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 [RFC8126]. When requesting a new value, the requestor as defined in [RFC8126]. IANA SHOULD prefer allocation of even
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,
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
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.
Allocated values MUST be in the range of 0 to 254.
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, as specified.
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 | 0 | RFCAAAA |
| AESKW256 | 2 | RFCAAAA | | AESKW256 | 1 | RFCAAAA |
| Reserved | 255 | RFCAAAA | | Unallocated | 2-254 | |
+----------+-------+---------------+ | 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 [RFC8126]. The expert SHOULD ensure the specification as defined in [RFC8126]. The expert SHOULD ensure the specification
defines the values for L and T as required in Section 4.4 of RFCAAAA. defines the values for L and T as required in Section 4.4 of RFCAAAA.
Allocated values MUST be in the range of 1 to 254. Allocated values MUST be in the range of 0 to 254.
7.3. TLS Extensions 7.3. TLS Extensions
IANA is requested to add supported_ekt_ciphers as a new extension IANA is requested to add supported_ekt_ciphers as a new extension
name to the "TLS ExtensionType Values" table of the "Transport Layer name to the "TLS ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this Security (TLS) Extensions" registry:
specification and allocate a value of TBD to for this.
Value: [TBD-at-Registration]
Extension Name: supported\_ekt\_ciphers
TLS 1.3: CH, SH
Recommended: Y
Reference: RFCAAAA
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
7.4. TLS Handshake Type 7.4. TLS Handshake Type
IANA is requested to add ekt_key as a new entry in the "TLS IANA is requested to add ekt_key as a new entry in the "TLS
HandshakeType Registry" table of the "Transport Layer Security (TLS) HandshakeType Registry" table of the "Transport Layer Security (TLS)
Parameters" registry with a reference to this specification, a DTLS- Parameters" registry:
OK value of "Y", and allocate a value of TBD to for this content
type. Value: [TBD-at-Registration]
Description: ekt\_key
DTLS-OK: Y
Reference: RFCAAAA
Comment:
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
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,
skipping to change at page 22, line 29 skipping to change at page 23, line 38
[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,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[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-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://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, (AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009, DOI 10.17487/RFC5649, September 2009,
<https://www.rfc-editor.org/info/rfc5649>. <https://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, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
skipping to change at page 23, line 9 skipping to change at page 24, line 14
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-perc-double] [I-D.ietf-perc-double]
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Double Encryption Procedures", draft-ietf-perc-double-09 Double Encryption Procedures", draft-ietf-perc-double-10
(work in progress), May 2018. (work in progress), October 2018.
[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-07 Conferencing (PERC)", draft-ietf-perc-private-media-
(work in progress), September 2018. framework-12 (work in progress), June 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-28 (work in progress), July 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
2018. 2019.
[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,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
 End of changes. 58 change blocks. 
144 lines changed or deleted 202 lines changed or added

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