Encrypted Key Transport for DTLS and Secure RTPCisco Systemsfluffy@iii.caEricsson ABjohn.mattsson@ericsson.comCisco Systemsmcgrew@cisco.comCitrix Systems, Inc.dwing-ietf@fuggles.comCisco Systemsfandreas@cisco.comPERCSRTPRTPconferencingencryptionEncrypted Key Transport (EKT) is an extension to DTLS
(Datagram Transport Layer Security) and the Secure Real-time
Transport Protocol (SRTP) that provides for the secure
transport of SRTP master keys, rollover counters, and other
information within SRTP. This facility enables SRTP for decentralized
conferences by distributing a common key to all of the conference
endpoints.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Overview
. Conventions Used in This Document
. Encrypted Key Transport
. EKTField Formats
. SPIs and EKT Parameter Sets
. Packet Processing and State Machine
. Outbound Processing
. Inbound Processing
. Ciphers
. AES Key Wrap
. Defining New EKT Ciphers
. Synchronizing Operation
. Timing and Reliability Considerations
. Use of EKT with DTLS-SRTP
. DTLS-SRTP Recap
. SRTP EKT Key Transport Extensions to DTLS-SRTP
. Negotiating an EKTCipher
. Establishing an EKT Key
. Offer/Answer Considerations
. Sending the DTLS EKTKey Reliably
. Security Considerations
. IANA Considerations
. EKT Message Types
. EKT Ciphers
. TLS Extensions
. TLS Handshake Type
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionThe Real-time Transport Protocol (RTP) is designed to allow decentralized
groups with minimal control to establish sessions, such as for
multimedia conferences. Unfortunately, Secure RTP (SRTP)
cannot be used in many minimal-control scenarios, because it requires
that synchronization source (SSRC) values and other data be
coordinated among all of the participants in a session. For example,
if a participant joins a session that is already in progress, that
participant needs to be informed of the SRTP keys 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
well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth
conservation. Additionally, in many situations, SRTP is used in
conjunction with a signaling system that can provide the central
control needed by SRTP. However, there are several cases in which
conventional signaling systems cannot easily provide all of the
coordination required.
This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in an
SRTP session with multiple receivers. EKT securely distributes the
SRTP master key and other information for each SRTP source. With 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 within a
session without coordinating with other entities via external signaling
or other external means.
EKT extends DTLS and SRTP to enable a common key encryption key
(called an "EKTKey") to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP
ROC to the other participants in the session. This data
furnishes the information needed by the receiver to instantiate an
SRTP receiver context.
EKT can be used in conferences where the central Media Distributor or
conference bridge cannot decrypt the media, such as the type defined
in . It can also be used for
large-scale conferences where the conference bridge or Media
Distributor can decrypt all the media but wishes to encrypt the media
it is sending just once and then send the same encrypted media to a large
number of participants. This reduces encryption CPU time
in general and is necessary when sending multicast media.
EKT does not control the manner in which the SSRC is generated. It
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. Instead, it is used in conjunction with those methods, and
it relieves those methods of the burden of delivering the context for
each 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.
OverviewThis specification defines a way for the server in a DTLS-SRTP
negotiation (see ) to provide an EKTKey to the client
during 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 endpoint. This specification also defines a way to send the
encrypted SRTP master key (with the EKTKey) along with the SRTP packet
(see ). Endpoints that receive this packet and know the EKTKey can use
the EKTKey to decrypt the SRTP master key, which can then be used to decrypt
the SRTP packet.
One way to use this specification is described in the architecture defined
by . Each participant in the
conference forms a DTLS-SRTP connection to a common Key Distributor
that distributes the same EKTKey to all the endpoints.
Then, each endpoint picks its own SRTP master key for the media
it sends. When sending media, the endpoint may also include the
SRTP master key encrypted with the EKTKey in the SRTP packet.
This allows all the endpoints to decrypt the media.
Conventions Used in This DocumentThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.Encrypted Key TransportEKT defines a new method of providing SRTP master keys to an
endpoint. In order to convey the ciphertext corresponding to the SRTP
master key, and other additional information, an additional field,
called the "EKTField", is added to the SRTP packets. The EKTField appears
at the end of the SRTP packet. It appears after the optional
authentication tag, if one is present; otherwise, the EKTField
appears after the ciphertext portion of the packet.
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> , as those SRTP
features duplicate some of the functions of EKT. Senders MUST NOT
include the MKI when using EKT. Receivers SHOULD simply ignore any MKI
field received if EKT is in use.
This document defines the use of EKT with SRTP. Its use with the
Secure Real-time Transport Control Protocol (SRTCP)
would be similar, but that topic is left for a future specification. SRTP
is preferred for transmitting keying material because (1) it shares fate
with the transmitted media, (2) SRTP rekeying can occur without
concern for RTCP transmission limits, and (3) it avoids the need
for SRTCP compound packets with RTP translators and mixers.
EKTField FormatsThe EKTField uses the formats defined in Figures and for the
FullEKTField and ShortEKTField. The EKTField appended to an SRTP
packet can be referred to as an "EKT Tag".
shows the syntax of the EKTField, expressed in ABNF
. The EKTField is added to the end of an SRTP
packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength,
SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext is
computed by encrypting the EKTPlaintext using the EKTKey. Future
extensions to the EKTField MUST conform to the syntax of the
ExtensionEKTField.
These fields and data elements are defined as follows:
EKTPlaintext:
This is the data that is input to the EKT encryption operation. This data never
appears on the wire; it is used only in computations internal to EKT. This
is the concatenation of the SRTP master key and its length, the SSRC, and
the ROC.
EKTCiphertext:
This is the data that is output from the EKT encryption operation
(see ). This field is included in SRTP
packets when 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, this is the SRTP master key associated with the indicated
SSRC.
SRTPMasterKeyLength:
This is the length of the SRTPMasterKey in bytes. This depends on the cipher
suite negotiated for SRTP using Session Description Protocol (SDP) Offer/Answer .
SSRC:
On the sender side, this is the SSRC for this SRTP source. The 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 current value of the SRTP
ROC in the SRTP context associated with the SSRC in the SRTP
packet. The length of this field is 32 bits.
Security Parameter Index (SPI):
This field indicates the appropriate EKTKey and other parameters for the
receiver to use when processing the packet, within a given conference. The
length of this field is 16 bits, representing a two-byte integer in network
byte order. The parameters identified by this field are as follows:
The EKT Cipher used to process the packet.
The EKTKey used to process the packet.
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. (Recall that 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 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 epoch
value equal to or lower than an epoch already seen.
Together, these data elements are called an "EKT parameter set". To
avoid ambiguity, each distinct EKT parameter set that is used
MUST be associated with a distinct SPI value.
EKTMsgLength:
All EKT Message Types other than the ShortEKTField include a length
in octets (in network byte
order) of either the FullEKTField or the ExtensionEKTField, including this length
field and the EKT Message Type (as defined in the next paragraph).
Message Type:
The last byte is used to indicate the type of the EKTField. This
MUST be 2 for the FullEKTField format and 0 for the ShortEKTField
format. If a received EKT Tag has an unknown Message Type, then the
receiver MUST discard the whole EKT Tag.
SPIs and EKT Parameter SetsThe SPI identifies the parameters for how the EKT Tag should
be processed:
The EKTKey and EKT Cipher used to process the packet.
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". To
avoid ambiguity, each distinct EKT parameter set that is used
MUST be associated with a distinct SPI value. 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
.
Packet Processing and State MachineAt any given time, the SSRC for each SRTP source has associated with
it a single EKT parameter set. This parameter set is used to
process all outbound packets and is called the "outbound parameter
set" for that SSRC. There may be other EKT parameter sets that are used by other
SRTP sources in the same session, including other SRTP
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
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
participants in an SRTP session, for use in processing inbound SRTP
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 will be unable
to receive media from a participant that has changed its media key.
Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets. The decision regarding which parameter to send and when
is specified in .
Outbound ProcessingSee , which describes when to send an SRTP packet with a
FullEKTField. If a FullEKTField is not being sent, then a
ShortEKTField is sent so the receiver can correctly determine how to
process the packet.
When an SRTP packet is sent with a FullEKTField, the EKTField for that
packet is created per either the steps below or an equivalent set of steps.
The Security Parameter Index (SPI) field is set to the value of the
SPI that is associated with the outbound
parameter set.
The EKTPlaintext field is computed from the SRTP master key, SSRC,
and ROC fields, as shown in . The ROC, SRTP master key, and
SSRC used in EKT processing MUST be the same as the one used in
SRTP processing.
The EKTCiphertext field is set to the ciphertext created by
encrypting the EKTPlaintext with the EKTCipher using the EKTKey
as the encryption key. The encryption process is detailed in
.
Then, the FullEKTField is formed using the EKTCiphertext and the SPI
associated with the EKTKey used above. Also appended are the length
and Message Type using the FullEKTField format.
The computed value of the FullEKTField is appended to the end of
the SRTP packet, after the encrypted payload.When a packet is sent with the ShortEKTField, the ShortEKTField
is simply appended to the packet.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
all the receivers in the system time to get the new key before they
start receiving media encrypted with the new key. (The specific
value of 250 ms is chosen to represent a reasonable upper bound on
the amount of latency and jitter that is tolerable in a real-time
context.)
Inbound ProcessingWhen receiving a packet on an RTP stream, the following steps are
applied for each received SRTP packet.
The final byte is checked to determine which EKT format is in
use. When an SRTP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet and then normal SRTP
processing occurs. If the packet contains a FullEKTField, then
processing continues as described below. The reason for using 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
occurred. At this point in the processing, there is no easy way to
know where the EKTField would start. However, the whole SRTP packet
has been received, so instead of starting at the front of the
packet, the parsing works backwards at the end of the packet, and
thus the type is placed at the very end of the packet.
The Security Parameter Index (SPI) field is used to find the
right EKT parameter set to be used for processing the packet.
If there is no matching SPI, then the verification function
MUST return an indication of authentication failure, and
the steps described below are not performed. The EKT parameter
set contains the EKTKey, the EKTCipher, and the SRTP master salt.
The EKTCiphertext is authenticated and decrypted, as
described in , using the EKTKey and EKTCipher found in the
previous step. If the EKT decryption operation returns an
authentication failure, then EKT processing MUST be aborted. The
receiver SHOULD discard the whole SRTP packet.
The resulting EKTPlaintext is parsed as described in , to
recover the SRTP master key, SSRC, and ROC fields. The SRTP master
salt that is associated with the EKTKey is also retrieved. If the
value of the srtp_master_salt (see ) sent as part of the EKTKey is
longer than needed by SRTP, then it is truncated by taking the
first N bytes from the srtp_master_salt field.
If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet
received, then this FullEKTField MUST be discarded and the
subsequent steps in
this list skipped. After stripping the FullEKTField, the remainder of
the SRTP packet MAY be processed as normal.
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
EKTPlaintext and can be used for any future crypto operations on
the inbound packets with that SSRC.
Unless the transform specifies other acceptable key lengths,
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
not the case, then the receiver MUST abort EKT processing and
SHOULD discard the whole SRTP packet.
If the length of the SRTP master key is less than the master
key length for the SRTP transform in use and the transform
specifies that this length is acceptable, then the SRTP master
key value is used to replace the first bytes in the existing
master key. The other bytes remain the same as in the old key.
For example, the double GCM transform
allows replacement of the first ("end-to-end") half of the
master key.
At this point, EKT processing has successfully completed, and the
normal SRTP processing takes place.
The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set, SRTP
master key, and ROC.
SRTP senders and receivers MAY cache an
EKTCiphertext value to optimize processing in cases where the master
key hasn't changed. Instead of encrypting and decrypting, senders
can simply copy the precomputed value and receivers can compare a
received EKTCiphertext to the known value.
recommends that SRTP senders continue using
an old key 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 trial decryption with both the old key and the new key,
keeping the result of whichever decryption succeeds. Note that this
approach is only compatible with SRTP transforms that include
integrity protection.
When receiving a new EKTKey, implementations need to use the
ekt_ttl field (see )
to create a time after which this key 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 ensure that it does not exceed the T value
for that cipher (see ). If either of
these limits is exceeded,
the key can no longer be used for encryption. At this point, implementations
need to either use call signaling to renegotiate a new session
or terminate the existing session. Terminating the session is a
reasonable implementation choice because these limits should not be
exceeded, except under an attack or error condition.
CiphersEKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext. This specification defines the interface to the cipher,
in order to abstract the interface away from the details of that
function. This specification also defines the default cipher that is
used in EKT. The default cipher described in MUST
be implemented, but another cipher that conforms to this interface
MAY be used. The cipher used for a given EKTCiphertext value is
negotiated using the supported_ekt_ciphers extension (see ) and indicated with the
SPI value in the FullEKTField.
An EKTCipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following inputs:
a secret key K with a length of L bytes, and
a plaintext value P with a length of M bytes.
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, C)
takes the following inputs:
a secret key K with a length of L bytes, and
a ciphertext value C with a length of N bytes.
The decryption function returns a plaintext value P that is M bytes
long, or it returns an indication that the decryption operation failed
because the ciphertext was invalid (i.e., it was not generated by the
encryption of plaintext with the key K).
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
times that it can be used with any fixed key value. The EKTKey MUST NOT be used for encryption more than T times. Note that if the same
FullEKTField is retransmitted three times, that only counts as one
encryption.
Security requirements for EKT Ciphers are discussed in .AES Key WrapThe default EKT Cipher is the Advanced Encryption Standard (AES)
Key Wrap with Padding algorithm . It requires a plaintext length M that is at least one
octet, and it returns a ciphertext with a length of N = M + (M mod
8) + 8 octets. It can be used with key sizes of L = 16 octets or L = 32
octets, and its use with those key sizes is indicated as AESKW128
or AESKW256, respectively.
The key size determines the length of the
AES key used by the Key Wrap algorithm. With this cipher,
T=248.
EKT Ciphers
Cipher
L
T
AESKW128
16
248
AESKW256
32
248
As AES-128 is the mandatory-to-implement transform in SRTP, AESKW128
MUST be implemented for EKT. AESKW256 MAY be implemented.
Defining New EKT CiphersOther specifications may extend this document by defining other
EKTCiphers, as described in . This section defines how those
ciphers interact with this specification.
An EKTCipher determines how the EKTCiphertext field is written and
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 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 each
EKTCipher.
The cipher MUST provide integrity protection.
Synchronizing OperationIf a source has its EKTKey changed by key management, it MUST also
change its SRTP master key, which will cause it to send out a new
FullEKTField and eventually begin encrypting with it, as described in
.
This ensures that if key management thought the EKTKey
needs changing (due to a participant leaving or joining) and
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
the current EKTKey.
Timing and Reliability ConsiderationsA system using EKT learns the SRTP master keys distributed with
the FullEKTField sent with SRTP, rather than with call signaling.
A
receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a FullEKTField.
This section describes how to reliably and expediently deliver new
SRTP master keys to receivers.
There are three cases to consider. In the first case, a new
sender joins a session and needs to communicate its SRTP
master key to all the receivers. In the second case, a sender
changes its SRTP master key, which needs to be communicated to all
the receivers. In the third case, a new receiver joins a session
already in progress and needs to know the sender's SRTP
master key.
The three cases are as follows:
New sender:
A new sender SHOULD send a packet containing the
FullEKTField as soon as possible, ideally in its initial SRTP packet. To accommodate packet loss, it is
RECOMMENDED that the FullEKTField be transmitted in three consecutive packets.
If the sender does not send a FullEKTField in its
initial packets and receivers have not otherwise been provisioned
with a decryption key, then decryption will fail and SRTP packets
will be dropped until the receiver receives a FullEKTField from the
sender.
Rekey:
By sending an EKT Tag over SRTP, the rekeying event shares fate with the
SRTP packets protected with that new SRTP master key. To accommodate
packet loss, it is RECOMMENDED that three consecutive packets
containing the FullEKTField be transmitted.
New receiver:
When a new receiver joins a session, it does not need to communicate
its sending SRTP master key (because it is a receiver). Also, when a new
receiver joins a session, the sender is generally unaware of the
receiver joining the session; thus, senders SHOULD periodically
transmit the FullEKTField. That interval depends on how frequently new
receivers join the session, the acceptable delay before those
receivers can start processing SRTP packets, and the acceptable
overhead of sending the FullEKTField. If sending audio and video, the
RECOMMENDED frequency is the same as the rate of intra-coded video
frames. If only sending audio, the RECOMMENDED frequency is every
100 ms.
If none of the above three cases apply, a ShortEKTField SHOULD be sent.
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.
Use of EKT with DTLS-SRTPThis document defines an extension to DTLS-SRTP called "SRTP EKTKey
Transport", which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client. This allows
such a peer to process EKT keying material in SRTP and
retrieve the embedded SRTP keying material.
This combination of
protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility,
along with allowing secure multi-party RTP with loose coordination
and 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 keying material
can allow EKT Keys to be tunneled through an untrusted relay such as
a centralized conference bridge. For more details, see
.
DTLS-SRTP RecapDTLS-SRTP uses an extended DTLS exchange between two
peers to exchange keying material, algorithms, and parameters for
SRTP. The SRTP flow operates over the same transport as the
DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
performance and encryption flexibility benefits of SRTP with the
flexibility and convenience of DTLS-integrated key and association
management. DTLS-SRTP can be viewed in two equivalent ways: as a new
key management method for SRTP and as a new RTP-specific data format
for DTLS.
SRTP EKT Key Transport Extensions to DTLS-SRTPThis document defines a new TLS negotiated extension
called "supported_ekt_ciphers" and a new TLS handshake message type called
"ekt_key". The extension negotiates the cipher to be used in
encrypting and decrypting EKTCiphertext values, and the handshake
message carries the corresponding key.
shows a message
flow between a DTLS 1.3 client and server
using EKT configured using the DTLS extensions described in this
section. (The 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 pre-1.3 TLS,
stacks will not have built-in support for generating and processing
ACK messages.
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 extensions defined in this document allow the DTLS server to set
a common EKTKey for all participants. Each endpoint can then use
EKT 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 individual DTLS handshakes among the endpoints, at the cost
of preventing endpoints from directly authenticating one another.
Client A Server Client B
<----DTLS Handshake---->
<--------EKTKey---------
<----DTLS Handshake---->
---------EKTKey-------->
-------------SRTP Packet + EKT Tag------------->
<------------SRTP Packet + EKT Tag--------------Negotiating an EKTCipherTo indicate its support for EKT, a DTLS-SRTP client includes in its
ClientHello an extension of type supported_ekt_ciphers listing the
ciphers used for EKT by the client, in preference order, with
the most preferred version first. If the server agrees to use EKT,
then it includes a supported_ekt_ciphers extension in its
EncryptedExtensions (or ServerHello for DTLS 1.2)
containing a cipher selected from among those advertised by the
client.
The extension_data field of this extension contains an "EKTCipher" value,
encoded using the syntax defined in :
enum {
reserved(0),
aeskw_128(1),
aeskw_256(2),
} EKTCipherType;
struct {
select (Handshake.msg_type) {
case client_hello:
EKTCipherType supported_ciphers<1..255>;
case server_hello:
EKTCipherType selected_cipher;
case encrypted_extensions:
EKTCipherType selected_cipher;
};
} EKTCipher;Establishing an EKT KeyOnce a client and server have concluded a handshake that negotiated
an EKTCipher, the server MUST provide to the client a key to be
used when encrypting and decrypting EKTCiphertext values. EKTKeys
are sent in encrypted handshake records, using handshake type
ekt_key(26). The body of the handshake message contains an
EKTKey structure as follows:
struct {
opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>;
uint16 ekt_spi;
uint24 ekt_ttl;
} EKTKey;The contents of the fields in this message are as follows:
ekt_key_value
The EKTKey that the recipient should use when generating EKTCiphertext
values
srtp_master_salt
The SRTP master salt to be used with any master key encrypted with this EKT
Key
ekt_spi
The SPI value to be used to reference this EKTKey and SRTP master salt in
EKT Tags (along with the EKT Cipher negotiated in the handshake)
ekt_ttl
The maximum amount of time, in seconds, that this EKTKey can be used. The
ekt_key_value in this message MUST NOT be used for encrypting or decrypting
information after the TTL expires.
If the server did not provide a supported_ekt_ciphers extension in
its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey messages MUST NOT be sent by the client
or the server.
When an EKTKey is received and processed successfully, the
recipient MUST respond with an ACK message as
described in . The EKTKey message and ACK MUST be
retransmitted following the rules of the negotiated version of
DTLS.EKT MAY be used with versions of DTLS prior to
1.3. In such cases, to provide reliability, the ACK message is still used. Thus, DTLS
implementations supporting EKT with pre-1.3 versions of DTLS 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 otherwise defined by the
negotiated version of DTLS.
If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert.
Offer/Answer ConsiderationsWhen using EKT with DTLS-SRTP, the negotiation to use EKT is done at
the DTLS handshake level and does not change the SDP Offer/Answer messaging .
Sending the DTLS EKTKey ReliablyThe DTLS EKTKey message is sent using the retransmissions specified
in DTLS.
Retransmission is finished with an ACK message, or an alert is
received.Security ConsiderationsEKT inherits the security properties of the key management
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP
extension defined in this document.With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concerns over the 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-sharing: a
single key is provided to protect an entire SRTP session. However, EKT
remains secure even when SSRC values collide.
SRTP master keys MUST be randomly generated, and offers
some guidance about random number generation. SRTP master keys MUST NOT be reused for any other purpose, and SRTP master keys MUST NOT be
derived from other SRTP master keys.
The EKT Cipher includes its own authentication/integrity check.
The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream. This mitigates the impact of cut-and-paste attacks
that arise due to the lack of a cryptographic binding between the
EKT Tag 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 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 FullEKTField also prevents an attacker from rolling back to a
previous key.
An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system by
causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the previous
values of the ciphertext as described in helps
mitigate this issue.
In a similar vein, EKT has no replay protection, so an attacker
could implant improper keys in receivers by capturing EKTCiphertext
values encrypted with a given EKTKey and replaying them in a
different context, e.g., from a different sender. When the
underlying SRTP transform provides integrity protection, this attack
will just result 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 position to mount these attacks, however,
could achieve the same 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
times a given key can be used. An endpoint MUST NOT encrypt more than
T different FullEKTField values using the same EKTKey. In addition, the
EKTKey MUST NOT be used beyond the lifetime provided by the TTL
described in .
The key length of the EKT Cipher
MUST be at least as long as the SRTP cipher and at least as long
as the DTLS-SRTP ciphers.
Part of the EKTPlaintext is known or is easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. In
practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when much
plaintext is known.
An EKT Cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen by an attacker querying both
the encryption and decryption functions.
In some systems, when a member of a conference leaves the conference,
that conference is rekeyed so that the member who left the conference no longer has the key. When
changing to a new EKTKey, it is possible that the attacker could block
the EKTKey message getting to a particular endpoint and that endpoint
would keep sending media encrypted using the old key. To mitigate that
risk, the lifetime of the EKTKey MUST be limited by using the ekt_ttl.
IANA ConsiderationsEKT Message TypesIANA has created a new table for "EKT Message Types" in
the "Real-Time Transport Protocol (RTP) Parameters" registry. The
initial values in this registry are as follows:
EKT Message Types
Message Type
Value
Specification
Short
0
RFC 8870
Unassigned
1
Full
2
RFC 8870
Unassigned
3-254
Reserved
255
RFC 8870
New entries in this table can be added via "Specification Required" as
defined in . To avoid conflicts with
pre-standard versions of EKT that have been deployed, IANA
SHOULD give preference to the allocation of even values over odd values until
the even code points are consumed. Allocated values MUST be in the range of 0 to 254.
All new EKT messages MUST be defined to include a length parameter, as specified in .
EKT CiphersIANA has created a new table for "EKT Ciphers" in the
"Real-Time Transport Protocol (RTP) Parameters" registry. The initial
values in this registry are as follows:
EKT Cipher Types
Name
Value
Specification
AESKW128
0
RFC 8870
AESKW256
1
RFC 8870
Unassigned
2-254
Reserved
255
RFC 8870
New entries in this table can be added via "Specification Required" as
defined in . The expert
SHOULD ensure that the specification
defines the values for L and T as required in of this document. Allocated values MUST be in the range of 0 to 254.
TLS ExtensionsIANA has added supported_ekt_ciphers as a new extension
name to the "TLS ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry:
Value:
39
Extension Name:
supported_ekt_ciphers
TLS 1.3:
CH, EE
Recommended:
Y
Reference:
RFC 8870
TLS Handshake TypeIANA has added ekt_key as a new entry in the "TLS
HandshakeType" table of the "Transport Layer Security (TLS)
Parameters" registry:
Value:
26
Description:
ekt_key
DTLS-OK:
Y
Reference:
RFC 8870
Comment:
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]The Secure Real-time Transport Protocol (SRTP)This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Advanced Encryption Standard (AES) Key Wrap with Padding AlgorithmThis document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Informative ReferencesRandomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)The Datagram Transport Layer Security (DTLS) Protocol Version 1.3RTFM, Inc.Arm LimitedGoogle, Inc. This document specifies Version 1.3 of the Datagram Transport Layer
Security (DTLS) protocol. DTLS 1.3 allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is intentionally based on the Transport Layer
Security (TLS) 1.3 protocol and provides equivalent security
guarantees with the exception of order protection/non-replayability.
Datagram semantics of the underlying transport are preserved by the
DTLS protocol.
Work in ProgressAcknowledgmentsThank you to , who provided a detailed
review and significant help with crafting text for this document. Thanks
to , ,
, , , , , , ,
, ,
, and for fruitful discussions, comments, and contributions to this
document.Authors' AddressesCisco Systemsfluffy@iii.caEricsson ABjohn.mattsson@ericsson.comCisco Systemsmcgrew@cisco.comCitrix Systems, Inc.dwing-ietf@fuggles.comCisco Systemsfandreas@cisco.com