draft-ietf-perc-srtp-ekt-diet-13.txt   rfc8870.txt 
Network Working Group C. Jennings Internet Engineering Task Force (IETF) C. Jennings
Internet-Draft Cisco Systems Request for Comments: 8870 Cisco Systems
Intended status: Standards Track J. Mattsson Category: Standards Track J. Mattsson
Expires: December 25, 2020 Ericsson AB ISSN: 2070-1721 Ericsson AB
D. McGrew D. McGrew
Cisco Systems Cisco Systems
D. Wing D. Wing
Citrix Systems, Inc. Citrix
F. Andreason F. Andreasen
Cisco Systems Cisco Systems
June 23, 2020 January 2021
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-13
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 the 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 25, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8870.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview
3. Conventions Used In This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document
4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4. Encrypted Key Transport
4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 4.1. EKTField Formats
4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8 4.2. SPIs and EKT Parameter Sets
4.3. Packet Processing and State Machine . . . . . . . . . . . 8 4.3. Packet Processing and State Machine
4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 9 4.3.1. Outbound Processing
4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10 4.3.2. Inbound Processing
4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Ciphers
4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12 4.4.1. AES Key Wrap
4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13 4.4.2. Defining New EKT Ciphers
4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 4.5. Synchronizing Operation
4.6. Timing and Reliability Consideration . . . . . . . . . . 13 4.6. Timing and Reliability Considerations
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 15 5. Use of EKT with DTLS-SRTP
5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15 5.1. DTLS-SRTP Recap
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17 5.2.1. Negotiating an EKTCipher
5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17 5.2.2. Establishing an EKT Key
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 5.3. Offer/Answer Considerations
5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19 5.4. Sending the DTLS EKTKey Reliably
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21 7.1. EKT Message Types
7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. EKT Ciphers
7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 22 7.3. TLS Extensions
7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 22 7.4. TLS Handshake Type
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 24 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) is designed to allow decentralized The Real-time Transport Protocol (RTP) is designed to allow
groups with minimal control to establish sessions, such as for decentralized groups with minimal control to establish sessions, such
multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) as for multimedia conferences. Unfortunately, Secure RTP (SRTP)
cannot be used in many minimal-control scenarios, because it requires [RFC3711] cannot be used in many minimal-control scenarios, because
that synchronization source (SSRC) values and other data be it requires that synchronization source (SSRC) values and other data
coordinated among all of the participants in a session. For example, be coordinated among all of the participants in a session. For
if a participant joins a session that is already in progress, that example, if a participant joins a session that is already in
participant needs to be told the SRTP keys along with the SSRC, progress, that participant needs to be informed of the SRTP keys
rollover counter (ROC) and other details of the other SRTP sources. along with the SSRC, 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. coordination required.
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 an
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
within a session without coordinating with other entities via a session without coordinating with other entities via external
external signaling or other external means. signaling or other external means.
EKT extends DTLS and SRTP to enable a common key encryption key EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each (called an "EKTKey") to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP endpoint can securely send its SRTP master key and current SRTP ROC
rollover counter to the other participants in the session. This data to the other participants in the session. This data furnishes the
furnishes the information needed by the receiver to instantiate an information needed by the receiver to instantiate an SRTP receiver
SRTP receiver context. 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 in [RFC8871]. It can also be used for large-scale conferences where
large scale conferences where the conference bridge or media the conference bridge or Media Distributor can decrypt all the media
distributor can decrypt all the media but wishes to encrypt the media but wishes to encrypt the media it is sending just once and then send
it is sending just once and then send the same encrypted media to a the same encrypted media to a large number of participants. This
large number of participants. This reduces the amount of CPU time reduces encryption CPU time in general and is necessary when sending
needed for encryption and can be used for some optimization to media multicast media.
sending that use source specific multicast.
EKT does not control the manner in which the SSRC is generated. It EKT does not control the manner in which the SSRC is generated. It
is only concerned with distributing the security parameters that an is only concerned with distributing the security parameters that an
endpoint needs to associate with a given SSRC in order to decrypt endpoint needs to associate with a given SSRC in order to decrypt
SRTP packets from that sender. 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 of delivering the context for
SRTP source to every SRTP participant. This document defines how EKT each SRTP source to every SRTP participant. This document defines
works with the DTLS-SRTP approach to key establishment, by using keys how EKT works with the DTLS-SRTP approach to key establishment, by
derived from the DTLS-SRTP handshake to encipher the EKTKey in using keys derived from the DTLS-SRTP handshake to encipher the
addition to the SRTP media. 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 packet and know
EKTKey can use the EKTKey to decrypt the SRTP master key which can the EKTKey can use the EKTKey to decrypt the SRTP master key, which
then be used to decrypt the SRTP packet. can then be used to decrypt the SRTP packet.
One way to use this is described in the architecture defined by One way to use this specification is described in the architecture
[I-D.ietf-perc-private-media-framework]. Each participant in the defined by [RFC8871]. Each participant in the conference forms a
conference forms a DTLS-SRTP connection to a common key distributor DTLS-SRTP connection to a common Key Distributor that distributes the
that distributes the same EKTKey to all the endpoints. Then each same EKTKey to all the endpoints. Then, each endpoint picks its own
endpoint picks its own SRTP master key for the media they send. When SRTP master key for the media it sends. When sending media, the
sending media, the endpoint also includes the SRTP master key endpoint may also include the SRTP master key encrypted with the
encrypted with the EKTKey in the SRTP packet. This allows all the EKTKey in the SRTP packet. This allows all the endpoints to decrypt
endpoints to decrypt the media. the media.
3. Conventions Used In This Document 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. 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 SRTP master key, and other additional information, an additional
field, called EKTField, is added to the SRTP packets. The EKTField field, called the "EKTField", is added to the SRTP packets. The
appears at the end of the SRTP packet. It appears after the optional EKTField appears at the end of the SRTP packet. It appears after the
authentication tag if one is present, otherwise the EKTField appears optional authentication tag, if one is present; otherwise, the
after the ciphertext portion of the packet. EKTField appears 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 the MKI when using EKT. Receivers SHOULD simply ignore any
field received if EKT is in use. MKI field received if EKT is in use.
This document defines the use of EKT with SRTP. Its use with SRTCP This document defines the use of EKT with SRTP. Its use with the
would be similar, but is reserved for a future specification. SRTP Secure Real-time Transport Control Protocol (SRTCP) would be similar,
is preferred for transmitting key material because it shares fate but that topic is left for a future specification. SRTP is preferred
with the transmitted media, because SRTP rekeying can occur without for transmitting keying material because (1) it shares fate with the
concern for RTCP transmission limits, and because it avoids the need transmitted media, (2) SRTP rekeying can occur without concern for
for SRTCP compound packets with RTP translators and mixers. RTCP transmission limits, and (3) 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 formats defined in Figures 1 and 2 for the
and ShortEKTField. The EKTField appended to an SRTP packet can be FullEKTField and ShortEKTField. The EKTField appended to an SRTP
referred to as an "EKT tag". packet can be referred to as an "EKT Tag".
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 :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Epoch | | Security Parameter Index | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |0 0 0 0 0 0 1 0| | Length |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FullEKTField format Figure 1: FullEKTField Format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: ShortEKTField format Figure 2: ShortEKTField Format
The following shows the syntax of the EKTField expressed in ABNF Figure 3 shows the syntax of the EKTField, expressed in ABNF
[RFC5234]. The EKTField is added to the end of an SRTP packet. The [RFC5234]. The EKTField is added to the end of an SRTP packet. The
EKTPlaintext is the concatenation of SRTPMasterKeyLength, EKTPlaintext is the concatenation of SRTPMasterKeyLength,
SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext is
computed by encrypting the EKTPlaintext using the EKTKey. Future computed by encrypting the EKTPlaintext using the EKTKey. Future
extensions to the EKTField MUST conform to the syntax of extensions to the EKTField MUST conform to the syntax of the
ExtensionEKTField. ExtensionEKTField.
BYTE = %x00-FF BYTE = %x00-FF
EKTMsgTypeFull = %x02 EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00 EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available
; usage by legacy implementations. ; for assignment due to its usage by
; legacy implementations.
EKTMsgLength = 2BYTE; EKTMsgLength = 2BYTE
SRTPMasterKeyLength = BYTE SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*242BYTE SRTPMasterKey = 1*242BYTE
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*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE Epoch = 2BYTE
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch 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:
This data never appears on the wire, and is used only in computations This is the data that is input to the EKT encryption operation.
internal to EKT. This is the concatenation of the SRTP Master Key This data never appears on the wire; it is used only in
and its length, the SSRC, and the ROC. computations internal to EKT. This is the concatenation of the
SRTP master key and its length, the SSRC, and the ROC.
EKTCiphertext: The data that is output from the EKT encryption EKTCiphertext:
operation, described in Section 4.4. This field is included in SRTP This is the data that is output from the EKT encryption operation
packets when EKT is in use. The length of EKTCiphertext can be (see Section 4.4). This field is included in SRTP packets when
larger than the length of the EKTPlaintext that was encrypted. EKT is in use. The length of the EKTCiphertext can be larger than
the length of the EKTPlaintext that was encrypted.
SRTPMasterKey: On the sender side, the SRTP Master Key associated SRTPMasterKey:
with the indicated SSRC. On the sender side, this is the SRTP master key associated with
the indicated SSRC.
SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This SRTPMasterKeyLength:
depends on the cipher suite negotiated for SRTP using SDP Offer/ This is the length of the SRTPMasterKey in bytes. This depends on
Answer [RFC3264] for the SRTP. the cipher suite negotiated for SRTP using Session Description
Protocol (SDP) Offer/Answer [RFC3264].
SSRC: On the sender side, this is the SSRC for this SRTP source. The SSRC:
length of this field is 32 bits. The SSRC value in the EKT tag MUST On the sender side, this is the SSRC for this SRTP source. The
be the same as the one in the header of the SRTP packet to which the length of this field is 32 bits. The SSRC value in the EKT Tag
tag is appended. 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):
current value of the SRTP rollover counter in the SRTP context On the sender side, this is set to the current value of the SRTP
associated with the SSRC in the SRTP packet. The length of this ROC in the SRTP context associated with the SSRC in the SRTP
field is 32 bits. packet. The length of this field is 32 bits.
Security Parameter Index (SPI): This field indicates the appropriate Security Parameter Index (SPI):
EKTKey and other parameters for the receiver to use when processing This field indicates the appropriate EKTKey and other parameters
the packet, within a given conference. The length of this field is for the receiver to use when processing the packet, within a given
16 bits, representing a two-byte integer in network byte order. The conference. The length of this field is 16 bits, representing a
parameters identified by this field are: two-byte integer in network byte order. The parameters identified
by this field are as follows:
o The EKT cipher used to process the packet. * The EKT Cipher used to process the packet.
o The EKTKey used to process the packet. * The EKTKey used to process the packet.
o The SRTP Master Salt associated with any master key encrypted with * The SRTP master salt associated with any master key encrypted
this EKT Key. The master salt is communicated separately, via with this EKT Key. The master salt is communicated separately,
signaling, typically along with the EKTKey. (Recall that the SRTP via signaling, typically along with the EKTKey. (Recall that
master salt is used in the formation of IVs / nonces.) the SRTP master salt is used in the formation of Initialization
Vectors (IVs) / nonces.)
Epoch: This field indicates how many SRTP keys have been sent for Epoch:
this SSRC under the current EKTKey, prior to the current key, as a This field indicates how many SRTP keys have been sent for this
two-byte integer in network byte order. It starts at zero at the SSRC under the current EKTKey, prior to the current key, as a
beginning of a session and resets to zero whenever the EKTKey is two-byte integer in network byte order. It starts at zero at the
changed (i.e., when a new SPI appears). The epoch for an SSRC beginning of a session and resets to zero whenever the EKTKey is
increments by one every time the sender transmits a new key. The changed (i.e., when a new SPI appears). The epoch for an SSRC
recipient of a FullEKTField MUST reject any future FullEKTField for increments by one every time the sender transmits a new key. The
this SPI and SSRC that has an equal or lower epoch value to an epoch recipient of a FullEKTField MUST reject any future FullEKTField
already seen. for this SPI and SSRC that has an epoch value equal to or lower
than 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". To
distinct EKT parameter set that is used MUST be associated with a avoid ambiguity, each distinct EKT parameter set that is used MUST be
distinct SPI value to avoid ambiguity. associated with a distinct SPI value.
EKTMsgLength: All EKT messages types other than the ShortEKTField EKTMsgLength:
have a length as second from the last element. This is the length in All EKT Message Types other than the ShortEKTField include a
octets (in network byte order) of either the FullEKTField/ length in octets (in network byte order) of either the
ExtensionEKTField including this length field and the following EKT FullEKTField or the ExtensionEKTField, including this length field
Message Type. and the EKT Message Type (as defined in the next paragraph).
Message Type: The last byte is used to indicate the type of the Message Type:
EKTField. This MUST be 2 for the FullEKTField format and 0 in The last byte is used to indicate the type of the EKTField. This
ShortEKTField format. If a received EKT tag has an unknown message MUST be 2 for the FullEKTField format and 0 for the ShortEKTField
type, then the receiver MUST discard the whole EKT tag. format. If a received EKT Tag has an unknown Message Type, then
the receiver MUST discard the whole EKT Tag.
4.2. SPIs and EKT Parameter Sets 4.2. SPIs and EKT Parameter Sets
The SPI field identifies the parameters for how the EKT tag should be The SPI identifies the parameters for how the EKT Tag should be
processed: processed:
o The EKTKey and EKT cipher used to process the packet. * The EKTKey and EKT Cipher used to process the packet.
o The SRTP Master Salt associated with any master key encrypted with * 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.
Together, these data elements are called an "EKT parameter set". Together, these data elements are called an "EKT parameter set". To
Each distinct EKT parameter set that is used MUST be associated with avoid ambiguity, each distinct EKT parameter set that is used MUST be
a distinct SPI value to avoid ambiguity. The association of a given associated with a distinct SPI value. The association of a given
parameter set with a given SPI value is configured by some other parameter set with a given SPI value is configured by some other
protocol, e.g., the DTLS-SRTP extension defined in Section 5. protocol, e.g., the DTLS-SRTP extension defined in Section 5.
4.3. Packet Processing and State Machine 4.3. Packet Processing and State Machine
At any given time, each SRTP source has associated with it a single At any given time, the SSRC for each SRTP source has associated with
EKT parameter set. This parameter set is used to process all it a single EKT parameter set. This parameter set is used to process
outbound packets, and is called the outbound parameter set for that all outbound packets and is called the "outbound parameter set" for
SSRC. There may be other EKT parameter sets that are used by other that SSRC. There may be other EKT parameter sets that are used by
SRTP sources in the same session, including other SRTP sources on the other SRTP sources in the same session, including other SRTP sources
same endpoint (e.g., one endpoint with voice and video might have two on the same endpoint (e.g., one endpoint with voice and video might
EKT parameter sets, or there might be multiple video sources on an have two EKT parameter sets, or there might be multiple video sources
endpoint each with their own EKT parameter set). All of the received on an endpoint, each with their own EKT parameter set). All of the
EKT parameter sets SHOULD be stored by all of the participants in an received EKT parameter sets SHOULD be stored by all of the
SRTP session, for use in processing inbound SRTP traffic. If a participants in an SRTP session, for use in processing inbound SRTP
participant deletes an EKT parameter set (e.g., because of space traffic. If a participant deletes an EKT parameter set (e.g.,
limitations, then it will be unable to process Full EKT Tags because of space limitations), then it will be unable to process Full
containing updated media keys, and thus unable to receive media from EKT Tags containing updated media keys and thus will be unable to
a particpant that has changed its media key. receive media from a participant 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 regarding which parameter to send
in Section 4.6. and when is specified in Section 4.6.
4.3.1. Outbound Processing 4.3.1. Outbound Processing
See Section 4.6 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 per either the steps below or an equivalent
steps. set of steps.
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 SPI 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 MUST 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 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
master key. This value MAY be cached by an SRTP sender to | key. This value MAY be cached by an SRTP sender to minimize
minimize computational effort. | computational effort.
The computed value of the FullEKTField is appended to the end of the The computed value of the FullEKTField is appended to the end of the
SRTP packet, after the encrypted payload. 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 ShortEKTField 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 in a FullEKTField value. This gives 250 ms after sending any new key in a FullEKTField value. This gives
all the receivers in the system time to get the new key before they all the receivers in the system time to get the new key before they
start receiving media encrypted with the new key. (The specific start receiving media encrypted with the new key. (The specific
value of 250ms is chosen to represent a reasonable upper bound on the value of 250 ms is chosen to represent a reasonable upper bound on
amount of latency and jitter that is tolerable in a real-time the amount of latency and jitter that is tolerable in a real-time
context.) context.)
4.3.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 an RTP stream, the following steps are
applied for each SRTP received packet. applied for each received SRTP 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 packet contains a ShortEKTField, the use. When an SRTP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP ShortEKTField is removed from the packet and then normal SRTP
processing occurs. If the packet contains a FullEKTField, then processing occurs. If the packet contains a FullEKTField, then
processing continues as described below. The reason for using processing continues as described below. The reason for using
the last byte of the packet to indicate the type is that the the last byte of the packet to indicate the type is that the
length of the SRTP part is not known until the decryption has length of the SRTP part is not known until the decryption has
occurred. At this point in the processing, there is no easy way occurred. At this point in the processing, there is no easy way
to know where the EKTField would start. However, the whole UDP to know where the EKTField would start. However, the whole SRTP
packet has been received, so instead of the starting at the front packet has been received, so instead of starting at the front of
of the packet, the parsing works backwards at the end of the the packet, the parsing works backwards at the end of the packet,
packet and thus the type is placed at the very end of the packet. and thus the type is placed at the very end of the packet.
2. The Security Parameter Index (SPI) field is used to find the 2. The Security Parameter Index (SPI) field is used to find the
right EKT parameter set to be used for processing the packet. If right EKT parameter set to be used for 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 the SRTP Master Salt. contains the EKTKey, the EKTCipher, and the SRTP master salt.
3. The EKTCiphertext is authenticated and decrypted, as described in 3. The EKTCiphertext is authenticated and decrypted, as described in
Section 4.4, using the EKTKey and EKTCipher found in the previous Section 4.4, using the EKTKey and EKTCipher found in the previous
step. If the EKT decryption operation returns an authentication step. If the EKT decryption operation returns an authentication
failure, then EKT processing MUST be aborted. The receiver failure, then EKT processing MUST be aborted. The receiver
SHOULD discard the whole UDP packet. SHOULD discard the whole SRTP packet.
4. The resulting EKTPlaintext is parsed as described in Section 4.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 (see Section 5.2.2) sent as
is longer than needed by SRTP, then it is truncated by taking the part of the EKTKey is longer than needed by SRTP, then it is
first N bytes from the srtp_master_salt field. truncated by taking the 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 received, then this FullEKTField MUST be discarded SRTP packet received, then this FullEKTField MUST be discarded
and the following steps in this list skipped. After stripping and the subsequent steps in this list skipped. After stripping
the FullEKTField, the remainder of the SRTP packet MAY be the FullEKTField, the remainder of the SRTP packet MAY be
processed as normal. processed as normal.
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
steps are saved in a map indexed by the SSRC found in the steps 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. the inbound packets with that SSRC.
* Unless the transform specifies other acceptable key lengths, * Unless the transform specifies other acceptable key lengths,
the length of the SRTP Master Key MUST be the same as the the length of the SRTP master key MUST be the same as the
master key length for the SRTP transform in use. If this is master key length for the SRTP transform in use. If this is
not the case, then the receiver MUST abort EKT processing and not the case, then the receiver MUST abort EKT processing and
SHOULD discared the whole UDP packet. SHOULD discard the whole SRTP packet.
* If the length of the SRTP Master Key is less than the master * If the length of the SRTP master key is less than the master
key length for the SRTP transform in use, and the transform key length for the SRTP transform in use and the transform
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 [RFC8723] allows
[I-D.ietf-perc-double] allows replacement of the first, "end replacement of the first ("end-to-end") half of the master
to end" half of the master key. 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 processing takes place. normal SRTP processing takes place.
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, SRTP master key, and
master key, and ROC. SRTP senders and receivers MAY cache an ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to
EKTCiphertext value to optimize processing in cases where the master optimize processing in cases where the master key hasn't changed.
key hasn't changed. Instead of encrypting and decrypting, senders Instead of encrypting and decrypting, senders can simply copy the
can simply copy the pre-computed value and receivers can compare a precomputed value and receivers can compare a received EKTCiphertext
received EKTCiphertext to the known value. to the known value.
Section 4.3.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 ensure that it does not exceed the T value for that cipher (see
Section 4.4). If either of these limits are exceeded, the key can no Section 4.4). If either of these limits is exceeded, the key can no
longer be used for encryption. At this point implementation need to longer be used for encryption. At this point, implementations need
either use the call signaling to renegotiate a new session or need to to either use call signaling to renegotiate a new session or
terminate the existing session. Terminating the session is a terminate the existing session. Terminating the session is a
reasonable implementation choice because these limits should not be reasonable implementation choice because these limits should not be
exceeded 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. The cipher used for a given EKTCiphertext interface MAY be used. The cipher used for a given EKTCiphertext
value is negotiated using the supported_ekt_ciphers and indicated value is negotiated using the supported_ekt_ciphers extension (see
with the SPI value in the FullEKTField. Section 5.2) 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 * a secret key K with a length of L bytes, and
o a plaintext value P with a length of M bytes. * 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
N bytes, where N may be larger than M. The decryption function D(K, N bytes, where N may be larger than M. The decryption function
C) takes the following inputs: D(K, C) takes the following inputs:
o a secret key K with a length of L bytes, and * a secret key K with a length of L bytes, and
o a ciphertext value C with a length of N bytes. * a ciphertext value C with a length of N bytes.
The decryption function returns a plaintext value P that is M bytes The decryption function returns a plaintext value P that is M bytes
long, or returns an indication that the decryption operation failed long, or it returns an indication that the decryption operation
because the ciphertext was invalid (i.e. it was not generated by the failed because the ciphertext was invalid (i.e., it was not generated
encryption of plaintext with the key K). by the 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 than T times. Note that if the same
FullEKTField is retransmitted 3 times, that only counts as 1 FullEKTField is retransmitted three times, that only counts as one
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. AES Key Wrap 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 algorithm [RFC5649]. 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 octets or L = 32 octets, and its use with those key
It can be used with key sizes of L = 16, and L = 32 octets, and its sizes is indicated as AESKW128 or AESKW256, respectively. The key
use with those key sizes is indicated as AESKW128, or AESKW256, size determines the length of the AES key used by the Key Wrap
respectively. The key size determines the length of the AES key used 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) |
+----------+----+--------+
Table 1: EKT Ciphers Table 1: EKT Ciphers
As AES-128 is the mandatory to implement transform in SRTP, AESKW128 As AES-128 is the mandatory-to-implement transform in SRTP, AESKW128
MUST be implemented for EKT and AESKW256 MAY be implemented. MUST be implemented for EKT. AESKW256 MAY be implemented.
4.4.2. Defining New EKT Ciphers 4.4.2. Defining New EKT Ciphers
Other specifications may extend this document by defining other Other specifications may extend this document by defining other
EKTCiphers as described in Section 7. This section defines how those EKTCiphers, as described in Section 7. This section defines how
ciphers interact with this specification. those 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.
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 key management, it MUST also
also change its SRTP master key, which will cause it to send out a change its SRTP master key, which will cause it to send out a new
new FullEKTField and eventually begin encrypting with it, as defined FullEKTField and eventually begin encrypting with it, as described in
in Section 4.3.1. This ensures that if key management thought the Section 4.3.1. 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. Timing and Reliability Consideration 4.6. Timing and Reliability Considerations
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 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. In the first case, a new sender
joining a session, which needs to communicate its SRTP master key to joins a session and needs to communicate its SRTP master key to all
all the receivers. The second case is a sender changing its SRTP the receivers. In the second case, a sender changes its SRTP master
master key which needs to be communicated to all the receivers. The key, which needs to be communicated to all the receivers. In the
third case is a new receiver joining a session already in progress third case, a new receiver joins a session already in progress and
which needs to know the sender's SRTP master key. needs to know the sender's SRTP master key.
The three cases are: The three cases are as follows:
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, ideally in its initial SRTP packet. To
initial SRTP packet. To accommodate packet loss, it is accommodate packet loss, it is RECOMMENDED that the FullEKTField
RECOMMENDED that the FullEKTField be transmitted in three be transmitted in three consecutive packets. If the sender does
consecutive packets. If the sender does not send a FullEKTField not send a FullEKTField in its initial packets and receivers have
in its initial packets and receivers have not otherwise been not otherwise been provisioned with a decryption key, then
provisioned with a decryption key, then decryption will fail and decryption will fail and SRTP packets will be dropped until the
SRTP packets will be dropped until the receiver receives a receiver receives a FullEKTField from the sender.
FullEKTField from the sender.
Rekey: Rekey:
By sending EKT tag over SRTP, the rekeying event shares fate with By sending an EKT Tag over SRTP, the rekeying event shares fate
the SRTP packets protected with that new SRTP master key. To with the SRTP packets protected with that new SRTP master key. To
accommodate packet loss, it is RECOMMENDED that three consecutive accommodate packet loss, it is RECOMMENDED that three consecutive
packets contain the FullEKTField be transmitted. packets containing 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
receiver). When a new receiver joins a session, the sender is receiver). Also, when a new receiver joins a session, the sender
generally unaware of the receiver joining the session. Thus, is 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 SRTP packets, and the acceptable overhead of sending the
FullEKTField. If sending audio and video, the RECOMMENDED FullEKTField. If sending audio and video, the RECOMMENDED
frequency is the same as the rate of intra coded video frames. If frequency is the same as the rate of intra-coded video frames. If
only sending audio, the RECOMMENDED frequency is every 100ms. only sending audio, the RECOMMENDED frequency is every 100 ms.
In general, sending EKT tags less frequently will consume less If none of the above three cases apply, a ShortEKTField SHOULD be
bandwidth, but increase the time it takes for a join or rekey to take sent.
effect. Applications should schedule the sending of EKT tags in a
way that makes sense for their bandwidth and latency requirements. In general, sending FullEKTField tags less frequently will consume
less bandwidth but will increase the time it takes for a join or
rekey to take effect. Applications should schedule the sending of
FullEKTField tags in a way that makes sense for their bandwidth and
latency requirements.
5. Use of EKT with DTLS-SRTP 5. Use of EKT with DTLS-SRTP
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
the DTLS-SRTP peer in the server role to the client. This allows from the DTLS-SRTP peer in the server role to the client. This
those peers to process EKT keying material in SRTP and retrieve the allows such a peer to process EKT keying material in SRTP and
embedded SRTP keying material. This combination of protocols is retrieve the embedded SRTP keying material. This combination of
valuable because it combines the advantages of DTLS, which has strong protocols is valuable because it combines the advantages of DTLS,
authentication of the endpoint and flexibility, along with allowing which has strong authentication of the endpoint and flexibility,
secure multiparty RTP with loose coordination and efficient along with allowing secure multi-party RTP with loose coordination
communication of per-source keys. and efficient communication of per-source keys.
In cases where the DTLS termination point is more trusted than the In cases where the DTLS termination point is more trusted than the
media relay, the protection that DTLS affords to EKT key material can media relay, the protection that DTLS affords to EKT keying material
allow EKT keys to be tunneled through an untrusted relay such as a can allow EKT Keys to be tunneled through an untrusted relay such as
centralized conference bridge. For more details, see a centralized conference bridge. For more details, see [RFC8871].
[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 as a new RTP-specific data format
for DTLS. for DTLS.
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
This document defines a new TLS negotiated extension This document defines a new TLS negotiated extension called
supported_ekt_ciphers and a new TLS handshake message type ekt_key. "supported_ekt_ciphers" and a new TLS handshake message type called
The extension negotiates the cipher to be used in encrypting and "ekt_key". The extension negotiates the cipher to be used in
decrypting EKTCiphertext values, and the handshake message carries encrypting and decrypting EKTCiphertext values, and the handshake
the corresponding key. message carries the corresponding key.
Figure 4 shows a message flow of DTLS 1.3 client and server using EKT Figure 4 shows a message flow between a DTLS 1.3 client and server
configured using the DTLS extensions described in this section. (The using EKT configured using the DTLS extensions described in this
initial cookie exchange and other normal DTLS messages are omitted.) section. (The initial cookie exchange and other normal DTLS messages
To be clear, EKT can be used with versions of DTLS prior to 1.3. The are omitted.) To be clear, EKT can be used with versions of DTLS
only difference is that in a pre-1.3 TLS stacks will not have built- prior to 1.3. The only difference is that in pre-1.3 TLS, stacks
in support for generating and processing ACK messages. 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}
skipping to change at page 16, line 27 skipping to change at line 742
<-------- <--------
{... Finished} --------> {... Finished} -------->
[ACK] [ACK]
<-------- [EKTKey] <-------- [EKTKey]
[ACK] --------> [ACK] -------->
|SRTP packets| <-------> |SRTP packets| |SRTP packets| <-------> |SRTP packets|
+ <EKT tags> + <EKT tags> + <EKT Tags> + <EKT Tags>
{} Messages protected using DTLS handshake keys {} Messages protected using DTLS handshake keys
[] Messages protected using DTLS application traffic keys [] Messages protected using DTLS application traffic keys
<> Messages protected using the EKTKey and EKT cipher <> Messages protected using the EKTKey and EKT Cipher
|| Messages protected using the SRTP Master Key sent in || Messages protected using the SRTP master key sent in
a Full EKT Tag a Full EKT Tag
Figure 4 Figure 4: DTLS 1.3 Message Flow
In the context of a multi-party SRTP session in which each endpoint In the context of a multi-party SRTP session in which each endpoint
performs a DTLS handshake as a client with a central DTLS server, the performs a DTLS handshake as a client with a central DTLS server, the
extensions defined in this document allow the DTLS server to set a extensions defined in this document allow the DTLS server to set a
common EKTKey for all participants. Each endpoint can then use EKT common EKTKey for all participants. Each endpoint can then use EKT
tags encrypted with that common key to inform other endpoint of the Tags encrypted with that common key to inform other endpoints of the
keys it uses to protect SRTP packets. This avoids the need for many keys it uses to protect SRTP packets. This avoids the need for many
individual DTLS handshakes among the endpoints, at the cost of individual DTLS handshakes among the endpoints, at the cost of
preventing endpoints from directly authenticating one another. preventing endpoints from directly authenticating one another.
Client A Server Client B Client A Server Client B
<----DTLS Handshake----> <----DTLS Handshake---->
<--------EKTKey--------- <--------EKTKey---------
<----DTLS Handshake----> <----DTLS Handshake---->
---------EKTKey--------> ---------EKTKey-------->
-------------SRTP Packet + EKT Tag-------------> -------------SRTP Packet + EKT Tag------------->
<------------SRTP Packet + EKT Tag-------------- <------------SRTP Packet + EKT Tag--------------
5.2.1. Negotiating an EKTCipher 5.2.1. Negotiating an EKTCipher
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, in preference order, with the
the most preferred version first. If the server agrees to use EKT, most preferred version first. If the server agrees to use EKT, then
then it includes a supported_ekt_ciphers extension in its ServerHello it includes a supported_ekt_ciphers extension in its
containing a cipher selected from among those advertised by the EncryptedExtensions (or ServerHello for DTLS 1.2) containing a cipher
client. selected from among those advertised by the 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 [RFC8446]: 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:
EKTCipherType supported_ciphers<1..255>; EKTCipherType supported_ciphers<1..255>;
case server_hello: case server_hello:
EKTCipherType selected_cipher; EKTCipherType selected_cipher;
case encrypted_extensions:
EKTCipherType selected_cipher;
}; };
} EKTCipher; } EKTCipher;
5.2.2. Establishing an EKT Key 5.2.2. Establishing an EKT Key
Once a client and server have concluded a handshake that negotiated Once a client and server have concluded a handshake that negotiated
an EKTCipher, the server MUST provide to the client a key to be used an EKTCipher, the server MUST provide to the client a key to be used
when encrypting and decrypting EKTCiphertext values. EKTKeys are when encrypting and decrypting EKTCiphertext values. EKTKeys are
sent in encrypted handshake records, using handshake type sent in encrypted handshake records, using handshake type
ekt_key(TBD). The body of the handshake message contains an EKTKey ekt_key(26). The body of the handshake message contains an EKTKey
structure: structure as follows:
[[ NOTE: RFC Editor, please replace "TBD" above with the code point
assigned by IANA ]]
struct { struct {
opaque ekt_key_value<1..256>; opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>; opaque srtp_master_salt<1..256>;
uint16 ekt_spi; uint16 ekt_spi;
uint24 ekt_ttl; uint24 ekt_ttl;
} EKTKey; } EKTKey;
The contents of the fields in this message are as follows: The contents of the fields in this message are as follows:
ekt_key_value ekt_key_value
The EKTKey that the recipient should use when generating The EKTKey that the recipient should use when generating
EKTCiphertext values EKTCiphertext values
srtp_master_salt srtp_master_salt
The SRTP Master Salt to be used with any Master Key encrypted with The SRTP master salt to be used with any master key encrypted with
this EKT Key this EKT Key
ekt_spi ekt_spi
The SPI value to be used to reference this EKTKey and SRTP Master The SPI value to be used to reference this EKTKey and SRTP master
Salt in EKT tags (along with the EKT cipher negotiated in the salt in EKT Tags (along with the EKT Cipher negotiated in the
handshake) handshake)
ekt_ttl ekt_ttl
The maximum amount of time, in seconds, that this EKTKey can be The maximum amount of time, in seconds, that this EKTKey can be
used. The ekt_key_value in this message MUST NOT be used for used. The ekt_key_value in this message MUST NOT be used for
encrypting or decrypting information after the TTL expires. encrypting or decrypting information after the TTL expires.
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 EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey
or the server. messages MUST NOT be sent by the client 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 message as described in Section 7 of MUST respond with an ACK message as described in Section 7 of
[I-D.ietf-tls-dtls13]. The EKTKey message and ACK MUST be [TLS-DTLS13]. The EKTKey message and ACK MUST be retransmitted
retransmitted following the rules of the negotiated version of DTLS. following the rules of the negotiated version of DTLS.
EKT MAY be used with versions of DTLS prior to 1.3. In such cases, EKT MAY be used with versions of DTLS prior to 1.3. In such cases,
the ACK message is still used to provide reliability. Thus, DTLS to provide reliability, the ACK message is still used. Thus, DTLS
implementations supporting EKT with DTLS pre-1.3 will need to have implementations supporting EKT with pre-1.3 versions of DTLS will
explicit affordances for sending the ACK message in response to an need to have explicit affordances for sending the ACK message in
EKTKey message, and for verifying that an ACK message was received. response to an EKTKey message and for verifying that an ACK message
The retransmission rules for both sides are otherwise defined by the was received. The retransmission rules for both sides are otherwise
negotiated version of DTLS. defined by the negotiated version of DTLS.
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 SDP Offer/Answer
Answer messaging. messaging [RFC3264].
5.4. Sending the DTLS EKTKey Reliably 5.4. Sending the DTLS EKTKey Reliably
The DTLS EKTKey message is sent using the retransmissions specified The DTLS EKTKey message is sent using the retransmissions specified
in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished in Section 4.2.4 of DTLS [RFC6347]. Retransmission is finished with
with an ACK message or an alert is received. an ACK message, or an alert is received.
6. Security Considerations 6. Security Considerations
EKT inherits the security properties of the the key management EKT inherits the security properties of the key management protocol
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP that is used to establish the EKTKey, e.g., the DTLS-SRTP extension
extension defined in this document. defined in this document.
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 concerns over the
use of keys, by empowering the SRTP layer to create keys on demand. reuse 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.
SRTP master keys MUST be randomly generated, and [RFC4086] offers SRTP master keys MUST be randomly generated, and [RFC4086] offers
some guidance about random number generation. SRTP master keys MUST some guidance about random number generation. SRTP master keys MUST
NOT be re-used for any other purpose, and SRTP master keys MUST NOT NOT be reused for any other purpose, and SRTP master keys MUST NOT be
be derived from other SRTP master keys. 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.
an attacker to successfully forge a FullEKTField, it would need to
defeat the authentication mechanisms of the EKT Cipher authentication
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. This mitigates the impact of the cut-and-paste attacks SRTP stream. This mitigates the impact of cut-and-paste attacks that
that arise due to the lack of a cryptographic binding between the EKT arise due to the lack of a cryptographic binding between the EKT Tag
tag and the rest of the SRTP packet. SRTP tags can only be cut-and- and the rest of the SRTP packet. SRTP tags can only be cut-and-
pasted within the stream of packets sent by a given RTP endpoint; an pasted within the stream of packets sent by a given RTP endpoint; an
attacker cannot "cross the streams" and use an EKT tag from one SSRC attacker cannot "cross the streams" and use an EKT Tag from one SSRC
to reset the key for another SSRC. The epoch field in the to reset the key for another SSRC. The Epoch field in the
FullEKTField also prevents an attacker from rolling back to a FullEKTField also prevents an attacker from rolling back to a
previous key. previous key.
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.2 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 The key encryption keys distributed with EKTKey messages are group
shared symmetric keys, which means they do not provide protection shared symmetric keys, which means they do not provide protection
within the group. Group members can impersonate each other; for within the group. Group members can impersonate each other; for
example, any group member can generate an EKT tag for any SSRC. The example, any group member can generate an EKT Tag for any SSRC. The
entity that distributes EKTKeys can decrypt any keys distributed entity that distributes EKTKeys can decrypt any keys distributed
using EKT, and thus any media protected with those keys. 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 key length of the EKT Cipher MUST be at least as long as the SRTP
MUST be at least as strong as the SRTP cipher and at least as strong cipher and at least as long 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 is easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does not impose any restrictions on our In practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when choices, since the ciphers in use provide high security even when
much plaintext is known. much plaintext is known.
An EKT cipher MUST resist attacks in which both ciphertexts and An EKT Cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen and adversaries that can query plaintexts can be adaptively chosen by an attacker querying both the
both the encryption and decryption functions adaptively. encryption and decryption functions.
In some systems, when a member of a conference leaves the In some systems, when a member of a conference leaves the conference,
conferences, the conferences is rekeyed so that member no longer has that conference is rekeyed so that the member who left the conference
the key. When changing to a new EKTKey, it is possible that the no longer has the key. When changing to a new EKTKey, it is possible
attacker could block the EKTKey message getting to a particular that the attacker could block the EKTKey message getting to a
endpoint and that endpoint would keep sending media encrypted using particular endpoint and that endpoint would keep sending media
the old key. To mitigate that risk, the lifetime of the EKTKey MUST encrypted using the old key. To mitigate that risk, the lifetime of
be limited using the ekt_ttl. the EKTKey MUST be limited by using the ekt_ttl.
7. IANA Considerations 7. IANA Considerations
7.1. EKT Message Types 7.1. EKT Message Types
IANA is requested to create a new table for "EKT Messages Types" in IANA has created a new table for "EKT Message Types" in the "Real-
the "Real-Time Transport Protocol (RTP) Parameters" registry. The Time Transport Protocol (RTP) Parameters" registry. The initial
initial values in this registry are: values in this registry are as follows:
+--------------+-------+---------------+ +==============+=======+===============+
| Message Type | Value | Specification | | Message Type | Value | Specification |
+==============+=======+===============+
| Short | 0 | RFC 8870 |
+--------------+-------+---------------+ +--------------+-------+---------------+
| Short | 0 | RFCAAAA | | Unassigned | 1 | |
| Full | 2 | RFCAAAA | +--------------+-------+---------------+
| Unallocated | 3-254 | RFCAAAA | | Full | 2 | RFC 8870 |
| Reserved | 255 | RFCAAAA | +--------------+-------+---------------+
| Unassigned | 3-254 | |
+--------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+--------------+-------+---------------+ +--------------+-------+---------------+
Table 2: EKT Messages Types Table 2: EKT Message Types
Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification.
New entries to this table can be added via "Specification Required" New entries in this table can be added via "Specification Required"
as defined in [RFC8126]. IANA SHOULD prefer allocation of even as defined in [RFC8126]. To avoid conflicts with pre-standard
values over odd ones until the even code points are consumed to avoid versions of EKT that have been deployed, IANA SHOULD give preference
conflicts with pre standard versions of EKT that have been deployed. to the allocation of even values over odd values until the even code
Allocated values MUST be in the range of 0 to 254. points are consumed. 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 include a length parameter,
the last element, as specified. as specified in Section 4.1.
7.2. EKT Ciphers 7.2. EKT Ciphers
IANA is requested to create a new table for "EKT Ciphers" in the IANA has created a new table for "EKT Ciphers" in the "Real-Time
"Real-Time Transport Protocol (RTP) Parameters" registry. The Transport Protocol (RTP) Parameters" registry. The initial values in
initial values in this registry are: this registry are as follows:
+-------------+-------+---------------+
| Name | Value | Specification |
+-------------+-------+---------------+
| AESKW128 | 0 | RFCAAAA |
| AESKW256 | 1 | RFCAAAA |
| Unallocated | 2-254 | |
| Reserved | 255 | RFCAAAA |
+-------------+-------+---------------+
Table 3: EKT Cipher Types +============+=======+===============+
| Name | Value | Specification |
+============+=======+===============+
| AESKW128 | 0 | RFC 8870 |
+------------+-------+---------------+
| AESKW256 | 1 | RFC 8870 |
+------------+-------+---------------+
| Unassigned | 2-254 | |
+------------+-------+---------------+
| Reserved | 255 | RFC 8870 |
+------------+-------+---------------+
Note to RFC Editor: Please replace RFCAAAA with the RFC number for Table 3: EKT Cipher Types
this specification.
New entries to this table can be added via "Specification Required" New entries in 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 that the
defines the values for L and T as required in Section 4.4 of RFCAAAA. specification defines the values for L and T as required in
Allocated values MUST be in the range of 0 to 254. Section 4.4 of this document. 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 has added supported_ekt_ciphers as a new extension name to the
name to the "TLS ExtensionType Values" table of the "Transport Layer "TLS ExtensionType Values" table of the "Transport Layer Security
Security (TLS) Extensions" registry: (TLS) Extensions" registry:
Value: [TBD-at-Registration] Value: 39
Extension Name: supported_ekt_ciphers
TLS 1.3: CH, SH
Recommended: Y
Reference: RFCAAAA
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] Extension Name: supported_ekt_ciphers
TLS 1.3: CH, EE
Recommended: Y
Reference: RFC 8870
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 has added ekt_key as a new entry in the "TLS HandshakeType"
HandshakeType Registry" table of the "Transport Layer Security (TLS) table of the "Transport Layer Security (TLS) Parameters" registry:
Parameters" registry:
Value: [TBD-at-Registration] Value: 26
Description: ekt_key
DTLS-OK: Y
Reference: RFCAAAA
Comment:
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] Description: ekt_key
8. Acknowledgements DTLS-OK: Y
Thank you to Russ Housley provided detailed review and significant Reference: RFC 8870
help with crafting text for this document. Thanks to David Benham,
Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul
Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean
Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions,
comments, and contributions to this document.
9. References Comment:
9.1. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 24, line 18 skipping to change at line 1100
<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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 8.2. Informative References
[I-D.ietf-perc-double] [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP "Randomness Requirements for Security", BCP 106, RFC 4086,
Double Encryption Procedures", draft-ietf-perc-double-12 DOI 10.17487/RFC4086, June 2005,
(work in progress), August 2019. <https://www.rfc-editor.org/info/rfc4086>.
[I-D.ietf-perc-private-media-framework] [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
Jones, P., Benham, D., and C. Groves, "A Solution "Double Encryption Procedures for the Secure Real-Time
Framework for Private Media in Privacy Enhanced RTP Transport Protocol (SRTP)", RFC 8723,
Conferencing (PERC)", draft-ietf-perc-private-media- DOI 10.17487/RFC8723, April 2020,
framework-12 (work in progress), June 2019. <https://www.rfc-editor.org/info/rfc8723>.
[I-D.ietf-tls-dtls13] [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy-Enhanced RTP
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
January 2021, <https://www.rfc-editor.org/info/rfc8871>.
[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-38 (work in progress), May 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
2020. dtls13-39, 2 November 2020,
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, Acknowledgments
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, Thank you to Russ Housley, who provided a detailed review and
<https://www.rfc-editor.org/info/rfc4086>. significant help with crafting text for this document. Thanks to
David Benham, Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen
Ismail, Paul Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob
Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for fruitful
discussions, comments, and contributions to this document.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Email: fluffy@iii.ca Email: fluffy@iii.ca
John Mattsson John Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
David A. McGrew David A. McGrew
Cisco Systems Cisco Systems
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
skipping to change at page 25, line 19 skipping to change at line 1156
David A. McGrew David A. McGrew
Cisco Systems Cisco Systems
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
Dan Wing Dan Wing
Citrix Systems, Inc. Citrix Systems, Inc.
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
Flemming Andreason Flemming Andreasen
Cisco Systems Cisco Systems
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 174 change blocks. 
500 lines changed or deleted 516 lines changed or added

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