wdiff draft-ietf-perc-srtp-ekt-diet-01.txt draft-ietf-perc-srtp-ekt-diet-02.txt

PERC Working Group J. Mattsson, Ed. C. Jennings
Internet-Draft Ericsson Cisco
Intended status: Standards Track D. McGrew J. Mattsson, Ed.
Expires: January 9, May 4, 2017 Ericsson
D. McGrew
D. Wing
F. Andreasen
C. Jennings
Cisco
July 8,
October 31, 2016

Encrypted Key Transport for Secure RTP
draft-ietf-perc-srtp-ekt-diet-01
draft-ietf-perc-srtp-ekt-diet-02

Abstract

Encrypted Key Transport (EKT) is an extension to Secure Real-time
Transport Protocol (SRTP) that provides for the secure transport of
SRTP master keys, Rollover Counters, rollover counters, and other information within
SRTP. This facility enables SRTP to work for decentralized conferences with minimal control by allowing
distributing a common key to be used
across multiple all of the conference endpoints.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
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 http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 9, May 4, 2017.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 3
2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4
2.2. Packet Processing and State Machine . . . . . . . . . . . 6
2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 7
2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 7 8
2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 8 9
2.3.1. The Default Cipher Ciphers . . . . . . . . . . . . . . . . . . 9
2.3.2. Other EKT Ciphers . . . . . 10
2.3.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 10
2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10 11
2.6. Timing and Reliability Consideration . . . . . . . . . . 11
3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 11 12
3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12
3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 12
3.3. Offer/Answer Considerations . . . . . . . . . . . . 12
3.3. Offer/Answer Considerations . . . 15
3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 14 15
4. Sending the DTLS EKT_Key Reliably Security Considerations . . . . . . . . . . . . . . . . . . 14 . 15
5. Security IANA Considerations . . . . . . . . . . . . . . . . . . . 14
6. Open Issues . . 17
5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17
5.2. EKT Ciphers . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 17
5.3. TLS Extensions . . 16
8. . . . . . . . . . . . . . . . . . . . 18
5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. 19
7.2. Informative References . . . . . . . . . . . . . . . . . 17 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 20

1. Introduction

RTP

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 ( SRTP [RFC3711])
cannot be used in many minimal-control scenarios, because it requires
that SSRC 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 told the SRTP keys (and along with the SSRC,
ROC roll
over counter (ROC) and other details) 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 most of the central
control needed by SRTP. However, there are several cases in which
conventional signaling systems cannot easily provide all of the
coordination required. It is also desirable to eliminate the layer
violations that occur when signaling systems coordinate certain SRTP
parameters, such as SSRC values and ROCs.

This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a
SRTP session that is shared 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 (SSRC) with new SRTP master keys (see
Section 2.2) within a session without coordinating with other
entities via external signaling or other external means.

EKT provides a way for an SRTP session participant, either a sender
or receiver, to securely transport its SRTP master key and current
SRTP rollover counter to the other participants in the session. This
data furnishes the information needed by the receiver to instantiate
an SRTP/SRTCP receiver context.

EKT does not control the manner in which the SSRC is generated; it is
only concerned with their secure transport.

EKT is not intended to replace external key establishment mechanisms, mechanisms.
Instead, it is used in conjunction with those methods, and it
relieves them those methods of the burden of tightly coordinating every to deliver the context for each
SRTP source
(SSRC) among to every SRTP participant.

1.1. Conventions Used In This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

2. Encrypted Key Transport

EKT defines a new method of providing SRTP master keys to an
endpoint. In order to convey the ciphertext of corresponding to the
SRTP master key, and other additional information, an additional EKT
field is added to SRTP packets. When added to SRTP, the EKT field
appears at the end of the SRTP packet, after the authentication tag
(if that tag is present), or after the ciphertext of the encrypted
portion of the packet otherwise.

EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
features duplicate some of the functions of EKT.

2.1. EKT Field Formats

The EKT Field uses the format defined below for the Full_EKT_Field FullEKTField and Short_EKT_Field.
ShortEKTField.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: EKT Ciphertext :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Length | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+

Figure 1: Full EKT Field format

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0|0| 0 0|
+-+-+-+-+-+-+-+-+

Figure 2: Short EKT Field format

TODO: move

The following shows the syntax to ABNF. Move name of Short the EKTField expressed in ABNF
[RFC5234]. The EKTField is added to Empty.
Move name the end of Full an SRTP or SRTCP
packet. The EKTCiphertext is computed by encrypting the EKTPlaintext
using the EKTKey. Future extensions to EncryptedKey. Drop extra EKT.

EKT_Msg_Type_Full the EKTField MUST conform to
the syntax of ExtensionEKTField.

BYTE = 2 ; 8 bits
EKT_Msg_Length ; 16 bits. length in octets including type and length

EKT_Plaintext %x00-FF

EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF

EKTMsgLength = 2BYTE;

SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*256BYTE
SSRC = 4BYTE; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

EKTPlaintext = SRTP_Master_Key || SRTPMasterKeyLength SRTPMasterKey SSRC || ROC || TTL

EKT_Ciphertext

EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
SPI = EKT_Encrypt(EKT_Key, EKT_Plaintext)

Full_EKT_Field 2BYTE

FullEKTField = EKT_Ciphertext || EKTCiphertext SPI ||
EKT_Msg_Length || EKT_Msg_Type_Full

Short_EKT_Field EKTMsgLength EKTMsgTypeFull

ShortEKTField = EKTMsgTypeShort

ExtensionData = 1*1024BYTE
ExtensionEKTField = '00000000' ExtensionData EKTMsgLength EKTMsgTypeExtension

EKTField = FullEKTField / ShortEKTField / ExtensionEKTField

Figure 3: EKT data formats EKTField Syntax

These fields and data elements are defined as follows:

EKT_Plaintext:

EKTPlaintext: The data that is input to the EKT encryption
operation. This data never appears on the wire, and is used only
in computations internal to EKT. This is the concatenation of the
SRTP Master Key, the SSRC, ROC, and the TTL.

EKT_Ciphertext: ROC.

EKTCiphertext: The data that is output from the EKT encryption
operation, described in Section 2.3. This field is included in
SRTP packets when EKT is in use. The length of this field is
variable, and is equal to the ciphertext size N defined in
Section 2.3. Note that the length of the field is inferable from
the SPI field, since the SPI will indicate the cipher being used
and thus the size.

SRTP_Master_Key:

SRTPMasterKey: On the sender side, the SRTP Master Key associated
with the indicated SSRC.

SRTPMasterKeyLength: The length of this field the SRTPMasterKey. This depends
on the cipher suite negotiated during call setup for SRTP or SRTCP. using [RFC3264] SDP Offer/
Answer for the SRTP.

SSRC: On the sender side, this field is the SSRC for this SRTP
source. The length of this field is 32 bits.

Rollover Counter (ROC): On the sender side, this field is set to the
current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP or SRTCP packet. The length
of this field is 32 bits.

Time to Live (TTL): The maximum amount of time that this key can be
used. A unsigned 16 bit integer representing duration in seconds.
The SRTP Master key in this message MUST NOT be used for
encrypting or decrypting information after this time. Open Issue:
does this need to be absolute time not duration? TODO: discuss in
security section.

Security Parameter Index (SPI): This field indicates the appropriate
EKT Key and other parameters for the receiver to use when
processing the packet. Each time a different EKT Key is received,
it will have a larger SPI than the previous key (after taking
rollover into account). The length of this field is 16 bits. The
parameters identified by this field are:

* The EKT cipher used to process the packet.

* The EKT Key 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.
Within each SRTP session, each
Each distinct EKT parameter set that may
be is used MUST be associated
with a distinct SPI value, value to avoid ambiguity.

EKT_Msg_Length

EKTMsgLength All EKT message other that Short EKT Field ShortEKTField must have a
length as the second from the last elements. element. This is the length in
octets of either the full EKT message FullEKTField/ExtensionEKTField including this
length field and the following message type.

Message Type The last byte is used to indicate the type of the
Field.
EKTField. This MUST be 2 in the Full EKT Field FullEKTField format and 0 in Short
EKT Field. Future specifications that define new types SHOULD use
even values until all the even code points are consumed to avoid
conflicts with pre standards version of EKT that have been
deployed.
ShortEKTField format. Values less than 64 are mandatory to
understand and the whole EKT field EKTField SHOULD be discarded if it
contains message type value that is less than 64 and is not
implemented.

TODO - add IANA registry for Message Type.

2.2. Packet Processing and State Machine

At any given time, each SRTP/SRTCP source (SSRC) 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/SRTCP sources in the same session, including other SRTP/
SRTCP SRTP/SRTCP
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
and SRTCP traffic.

All SRTP master keys MUST NOT be re-used, MUST be randomly generated
according to [RFC4086], and MUST NOT be equal to or derived from
other SRTP master keys.

Either the Full_EKT_Field FullEKTField or Short_EKT_Field ShortEKTField is appended at the tail end
of all the SRTP packet. packets.

2.2.1. Outbound Processing

See Section 2.6 which describes when to send an EKT packet with a
Full EKT Field.
FullEKTField. If a Full EKT Field FullEKTField is not being sent, then a Short
EKT Field
ShortEKTField needs to be sent so the receiver can correctly
determine how to process the packet.

When an SRTP packet is to be sent with a Full EKT Field, FullEKTField, the EKT
field EKTField
for that packet is created as follows, or uses an equivalent set of
steps. The creation of the EKT field EKTField MUST precede the normal SRTP
packet processing.

1. The Security Parameter Index (SPI) field is set to the value of
the Security Parameter Index that is associated with the outbound
parameter set.

2. The EKT_Plaintext EKTPlaintext field is computed from the SRTP Master Key,
SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP
Master Key, and SSRC used in EKT processing SHOULD be the same as
the one used in the SRTP processing.

3. The EKT_Ciphertext EKTCiphertext field is set to the ciphertext created by
encrypting the EKT_Plaintext EKTPlaintext with the EKT cipher, using the EKT
Key EKTKey
as the encryption key. The encryption process is detailed in
Section 2.3.

4. Then the Full EKT Field FullEKTField is formed using the EKT Ciphertext EKTCiphertext and the
SPI associated with the EKT Key EKTKey used above. Also appended are the
Length and EKTMEsgTypeFull elements.

Note: the value of the EKT Ciphertext field is identical in
successive packets protected by the same EKTKey and SRTP
master key. This value MAY be cached by an SRTP sender to
minimize computational effort.

The computed value of the Full EKT Field FullEKTField is written into the
packet.

When a packet is sent with the Short EKT Field, the Short EKF Field ShortEKFField is
simply appended to the packet.

2.2.2. Inbound Processing

Inbound

When receiving a packet on a RTP stream where EKT processing MUST take place prior to was negotiated, the usual SRTP or
SRTCP processing. The
following steps show processing as packets are applied for each received in order. packet.

1. The final byte is checked to determine which EKT format is in
use. When an SRTP or SRTCP packet contains a Short EKT Field, ShortEKTField, the Short EKT Field
ShortEKTField is removed from the packet then normal SRTP or
SRTCP processing occurs. If the packet contains a Full EKT
Field, FullEKTField,
then processing continues as described below.

2. The combination of the SSRC and the Security Parameter Index (SPI) field is used to find which
EKT parameter set should to be used when 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 EKT Key, EKT Cipher, EKTKey, EKTCipher, and SRTP Master Salt.

3. The EKT Ciphertext EKTCiphertext authentication is checked and it is decrypted,
as described in Section 2.3, using the EKT Key EKTKey and EKT Cipher EKTCipher found
in the previous step. If the EKT decryption operation returns an
authentication failure, then the packet processing stops.

4. The resulting EKT Plaintext EKTPlaintext is parsed as described in Section 2.1,
to recover the SRTP Master Key, SSRC, and ROC fields. The Master
Salt that is assocted associated with the EKT Keys used
to do the decription EKTKey is also retreived. retrieved. If
the value of the srtp_master_salt sent as part of the EKTkey is
longer than needed by SRTP, then it is truncated by taking the
first N bytes from the srtp_master_salt field.

5. The SRTP Master Key, ROC, and SRTP Master Salt from the prevous previous
step are saved in a map indexed by the SSRC found in the EKT Plaintext
EKTPlaintext and can be used for any future crypto operations for on
the inbound or
outbound packets with the that SSRC. Outbound packets SHOULD
continue to use the old key SRTP Master Key for 250 ms after receipt of the sending
any new key. This gives all the receivers in the system time to
get the new key before they start receiving media encrypted with
the new key. The key MUST NOT be used beyond the lifetime found in the
TTL field.

6. At this point, EKT processing has successfully completed, and the
normal SRTP or SRTCP processing takes place including replay
protection.

2.2.2.1. Implementation note: Notes for Inbound Processing

The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP
master key, and ROC. This ciphertext value MAY be cached by an SRTP
receiver to minimize computational effort by noting when the SRTP
master key is unchanged and avoiding repeating the above steps.

The receiver may want to have a sliding window to retain old SRTP
master keys (and related context) for some brief period of time, so
that out of order packets can be processed as well as packets sent
during the time keys are changing.

2.3. Ciphers

EKT uses an authenticated cipher to encrypt and authenticate the EKT
Plaintext.
EKTPlaintext. We first specify the interface to the cipher, in order
to abstract the interface away from the details of that function. We
then define the cipher that is used in EKT by default. The default
cipher described in Section 2.3.1 MUST be implemented, but another
cipher that conforms to this interface MAY be used, in which case its
use MUST be coordinated by external means (e.g., key management).

An EKT cipher EKTCipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following
inputs:

o a secret key K with a length of L bytes, and

o 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 is at least may be larger than M. The decryption function D(K,
C) takes the following inputs:

o a secret key K with a length of L bytes, and

o a ciphertext value C with a length of N bytes.

The decryption function returns a plaintext value P that is at least
M bytes long, or 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
concatenated with optional padding) 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. For each key,
the encryption function The EKTKey MUST NOT be invoked on used more than that T distinct
values of P, and the decryption function MUST NOT be invoked on more
than T distinct values of C.
times.

Security requirements for EKT ciphers are discussed in Section 5. 4.

2.3.1. The Default Cipher Ciphers

The default EKT Cipher is the Advanced Encryption Standard (AES) Key
Wrap with Padding [RFC5649] 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, and L = 32 octets, and its use with those key sizes
is indicated as
AESKW_128, AESKW128, or AESKW_256, AESKW256, respectively. The key size
determines the length of the AES key used by the Key Wrap algorithm.
With this cipher, T=2^48.

length of length of
SRTP EKT EKT EKT length of
transform transform plaintext ciphertext Full EKT Field
--------- ------------ --------- ---------- --------------
AES-128 AESKW_128 26 40 42
AES-256 AESKW_256 42 56 58

Figure 4: AESKW

+----------+----+------+
| Cipher | L | T |
+----------+----+------+
| AESKW128 | 16 | 2^48 |
| | | |
| AESKW256 | 32 | 2^48 |
+----------+----+------+

Table 1: EKT Ciphers

As AES-128 is the mandatory to implement transform in SRTP [RFC3711],
AESKW_128
AESKW128 MUST be implemented for EKT.

For all the SRTP transforms listed in the table, the corresponding EKT transform MUST and AESKW256 MAY be used, unless a stronger EKT transform is
negotiated by key management. implemented.

2.3.2. Other Defining New EKT Ciphers

Other specifications may extend this one document by defining other EKT
ciphers per
EKTCiphers as described in Section 7. 5. This section defines how those
ciphers interact with this specification.

An EKT cipher EKTCipher determines how the EKT Ciphertext 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, M, N, and T MUST be defined by
each EKT cipher, and those values MUST be inferable from
the EKT parameter set. EKTCipher.

2.4. Synchronizing Operation

If a source has its EKT key EKTKey changed by the key management, it MUST
also change its SRTP master key, which will cause it to send out a
new Full EKT Field. FullEKTField. This ensures that if key management thought the
EKT key
EKTKey needs changing (due to a participant leaving or joining) and
communicated that in key management 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 EKT key. EKTKey.

2.5. Transport

EKT SHOULD be used over SRTP, and other specification MAY define how
to use it over SRTCP. SRTP is preferred because it shares fate with
transmitted media, because SRTP rekeying can occur without concern
for RTCP transmission limits, and to avoid SRTCP compound packets
with RTP translators and mixers.

2.6. Timing and Reliability Consideration

A system using EKT learns the SRTP master keys distributed with Full
EKT Fields send
FullEKTFields sent with the SRTP, rather than with call signaling. A
receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a Full EKT Field.

This section describes how to reliably and expediently deliver new
SRTP master keys to receivers.

There are three cases to consider. The first case is a new sender
joining a session which needs to communicate its SRTP master key to
all the receivers. The second case is a sender changing its SRTP
master key which needs to be communicated to all the receivers. The
third case is a new receiver joining a session already in progress
which needs to know the sender's SRTP master key.

The three cases are:

New sender: A new sender SHOULD send a packet containing the Full EKT
Field
FullEKTField as soon as possible, always before or coincident with
sending its initial SRTP packet. To accommodate packet loss, it
is RECOMMENDED that three consecutive packets contain the Full EKT
Field be transmitted.

Rekey: By sending EKT over SRTP, the rekeying event shares fate with
the SRTP packets protected with that new SRTP master key. To
accommodate packet loss, it is RECOMMENDED that three consecutive
packets contain 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). When a new receiver joins a session the sender is
generally unaware of the receiver joining the session. Thus,
senders SHOULD periodically transmit the Full EKT Field. 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 Full EKT FullEKT
Field. The If sending audio and video, the RECOMMENDED frequency is
the same as the key frame frequency if sending rate of intra coded video and frames. If only sending
audio, the RECOMMENDED frequency is every 100ms for audio. 100ms.

3. Use of EKT with DTLS-SRTP

This document defines an extension to DTLS-SRTP called Key Transport.
The SRTP EKT with the DTLS-SRTP Key
Transport which enables secure transport of EKT keying material from
one DTLS-SRTP peer to another. This enables allows those peers to process
EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP
keying material. This combination of protocols is valuable because
it combines the advantages of DTLS
(strong DTLS, which has strong authentication
of the endpoint and flexibility) flexibility, along with the
advantages of EKT (allowing allowing secure
multiparty RTP with loose coordination and efficient communication of
per-source keys). keys.

3.1. DTLS-SRTP Recap

DTLS-SRTP [RFC5764] 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 a new RTP-specific data format
for DTLS.

3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP

This document adds defines a new TLS negotiated extension called "ekt". This
adds
"srtp_ekt_key_transport"and a new TLS content type, EKT, and a new negotiated extension EKT.
The DTLS server includes "ekt" in its TLS ServerHello message. If a
DTLS client includes "ekt" in its ClientHello, but does not receive
"ekt" in the ServerHello, the DTLS client MUST NOT send DTLS packets
with the "ekt" content-type. type called EKTMessage.

Using the syntax described in DTLS [RFC6347], the following
structures are used:

enum {
ekt_key(0),
ekt_key_ack(1),
ekt_key_error(254),
(255)
reserved(0),
aeskw_128(1),
aeskw_256(3),
} SRTPKeyTransportType; EKTCipherType;

struct {
SRTPKeyTransportType keytrans_type;
uint24 length;
uint16 message_seq;
uint24 fragment_offset;
uint24 fragment_length;
select (SRTPKeyTransportType) {
case ekt_key:
EKTkey;
};
EKTCipherType ekt_ciphers<0..254>;
} KeyTransport;

enum {
RESERVED(0),
AESKW_128(1),
AESKW_256(3),
} ektcipher; SupportedEKTCiphers;

struct {
ektcipher EKT_Cipher;
EKTCipherType ekt_cipher;
uint EKT_Key_Value<1..256>; ekt_key_value<1..256>;
uint EKT_Master_Salt<1..256>; srtp_master_salt<1..256>;
uint16 EKT_SPI; ekt_spi;
uint24 ekt_ttl;
} EKTkey;

enum {
ekt_key(0),
ekt_key_ack(1),
ekt_key_error(254),
(255)
} EKTMessageType;

struct {
EKTMessageType ekt_message_type;
select (EKTMessage.ekt_message_type) {
case ekt_key:
EKTKey;
} message;
} EKTMessage;

Figure 5: 4: Additional TLS Data Structures

The diagram below shows

If a message flow of DTLS client and includes "srtp_ekt_key_transport" in its
ClientHello, then a DTLS server
using the DTLS-SRTP Key Transport extension.

Client Server

ClientHello + use_srtp + EKT
--------> that supports this extensions will
includes "srtp_ekt_key_transport" in its ServerHello + use_srtp + EKT
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ekt_key <--------
ACK -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
ekt_key (rekey) <-------
ACK -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets

Figure 6: Handshake Message Flow

3.3. Offer/Answer Considerations

When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
the message. If a
DTLS handshake level and client includes "srtp_ekt_key_transport" in its ClientHello, but
does not change receive "srtp_ekt_key_transport" in the [RFC3264] Offer /
Answer messaging.

4. Sending ServerHello, the
DTLS EKT_Key Reliably

The client MUST NOT send DTLS ekt_key is sent using the retransmiions specified in
Section 4.2.4. of EKTMessage messages.

When a DTLS [RFC6347].

5. Security Considerations

EKT inherits the security properties of client sends the DTLS-SRTP (or other)
keying "srtp_ekt_key_transport" in its
ClientHello message, it uses.

With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concern over include the re-
use of keys, by empowering SupportedEKTCiphers as the SRTP layer to create keys on demand.
Note that
extension_data for the inputs of EKT are extension, listing the same as for SRTP with key-
sharing: a single key EKTCipherTypes the
client is provided willing to protect an entire SRTP session.
However, EKT remains secure even when SSRC values collide.

The EKT Cipher includes its own authentication/integrity check. For
an attacker to successfully forge a full EKT packet, it would need to
defeat the authentication mechanisms of use in preference order, with the EKT Cipher authentication
mechanism.

The presence of most preferred
version first. When the SSRC server responds in the EKT_Plaintext ensures
"srtp_ekt_key_transport" in its ServerHello message, it must include
a SupportedEKTCiphers list that an
attacker cannot substitute an EKT_Ciphertext selects a single EKTCipherType to use
(selected from one SRTP stream
into another SRTP stream.

An attacker who tampers with the bits in Full_EKT_Field can prevent list provided by the intended receiver of that packet from being able client) or it returns an
empty list to decrypt it.
This indicate there is a minor denial of service vulnerability.

An attacker could send packets containing a Full EKT Field, no matching EKTCipherType in an
attempt the
clients list that the server is also willing to consume additional CPU resources of use. The value to be
used in the receiving system
by causing EKTCipherType for future extensions that define new
ciphers is the receiving system will decrypt value from the EKT ciphertext and
detect an authentication failure

EKT can rekey an SRTP stream until "EKT Ciphers Type" IANA registry
defined in Section 5.2.

The figure above defines the SRTP rollover counter (ROC)
needs to roll over. EKT does not extend SRTP's rollover counter
(ROC), and like SRTP itself EKT cannot properly handle contents for a ROC
rollover. Thus even if using EKT, new (master or session) keys need
to be established after 2^48 packets are transmitted TLS content type
called EKTMessage which is registered in a single SRTP
stream Section 5.4. The EKTMessage
above is used as described the opaque fragment in the TLSPlaintext structure
defined in Section 3.3.1 6.2.1 of [RFC3711]. Due to [RFC5246] and the
relatively low packet rates "srtp_ekt_message" as
the content type. The "srtp_ekt_message" content type is defined and
registered in Section 5.3.

ekt_ttl: The maximum amount of typical RTP sessions, time, in seconds, that this is not
expected to
ekt_key_value can be a burden. used. The confidentiality, ekt_key_value in this message MUST
NOT be used for encrypting or decrypting information after the TTL
expires.

When the Server wishes to provide a new EKT Key, it can send
EKTMessage containing an EKTKey with the new key information. The
client MUST respond with an EKTMessage of type ekt_key_ack, if the
EKTKey was successfully processed and stored or respond with the the
ekt_key_error EKTMessage otherwise.

The diagram below shows a message flow of DTLS client and DTLS server
using the DTLS-SRTP Key Transport extension.

Client Server

ClientHello + use_srtp + srtp_ekt_key_trans
-------->
ServerHello+use_srtp+srtp_ekt_key_trans
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ekt_key <--------
ekt_key_ack -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
ekt_key (rekey) <-------
ekt_key_ack -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets

Figure 5: DTLS/SRTP Message Flow

3.3. Offer/Answer Considerations

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 /
Answer messaging.

3.4. Sending the DTLS EKT_Key Reliably

The DTLS ekt_key is sent using the retransmissions specified in
Section 4.2.4. of DTLS [RFC6347].

4. Security Considerations

EKT inherits the security properties of the DTLS-SRTP (or other)
keying it uses.

With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concern over the re-
use of keys, by empowering the SRTP layer to create keys on demand.
Note that the inputs of EKT are the same as for SRTP with key-
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 [RFC4086] offers
some guidance about random number generation. SRTP master keys MUST
NOT be re-used for any other purpose, and SRTP master keys MUST NOT
be derived from other SRTP master keys.

The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream.

An attacker who tampers with the bits in FullEKTField can prevent the
intended receiver of that packet from being able to decrypt it. This
is a minor denial of service vulnerability.

An attacker could send packets containing a Full EKT Field, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system will decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the
previous values of the Ciphertext as described in Section 2.2.2.1
helps mitigate this issue.

Each EKT cipher specifies a value T that is the maximum number of
times a given key can be used. An endpoint MUST NOT send more than T
Full EKT Field using the same EKTKey. In addition, the EKTKey MUST
NOT be used beyond the lifetime provided by the TTL described in
Section 3.2.

The confidentiality, integrity, and authentication of the EKT cipher
MUST cipher
MUST be at least as strong as the SRTP cipher and at least as strong
as the DTLS-SRTP ciphers.

Part of the EKTPlaintext is known, or 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 and adversaries that can query
both the encryption and decryption functions adaptively.

In some systems, when a member of a conference leaves the
conferences, the conferences is rekeyed so that member 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
SHOULD be limited using the ekt_ttl.

5. IANA Considerations

5.1. EKT Message Types

IANA is requested to create a new registry for "EKT Messages Types".
The initial values in this registry are:

Table 2: EKT Messages Types

Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification.

New entries to this table can be at least as strong added via "Specification Required"
as defined in [RFC5226]. When requesting a new value, the SRTP cipher.

Part of the EKT_Plaintext requestor
needs to indicate if it is known, mandatory to understand or easily guessable not. If it is
mandatory to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does understand, IANA needs to allocate a value less than 64,
if it is not impose any restrictions on our
choices, since mandatory to understand, a value greater than or equal
to 64 needs to be allocated. IANA SHOULD prefer allocation of even
values over odd ones until the ciphers in use provide high security even when
much plaintext is known.

An code points are consumed to avoid
conflicts with pre standard versions of EKT cipher MUST resist attacks that have been deployed.

5.2. EKT Ciphers

IANA is requested to create a new registry for "EKT Ciphers". The
initial values in which both ciphertexts and
plaintexts this registry are:

Table 3: EKT Cipher Types

Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification.

New entries to this table can be adaptively chosen and adversaries that can query
both added via "Specification Required"
as defined in [RFC5226]. The expert SHOULD ensure the encryption and decryption functions adaptively.

6. Open Issues

What length should specification
defines the SPI be?
Should we limit values for L and T as required in Section 2.3 of RFCAAA.
Allocated values MUST be in the number range of saved SPI for a given SSRC? Or limit 1 to 254.

5.3. TLS Extensions

IANA is requested to add "srtp_ekt_key_transport" as an new extension
name to the lifetime "ExtensionType Values" table of old ones after the "Transport Layer
Security (TLS) Extensions" registry with a new one is received? At some level reference to this may not matter because even if the
specification and allocate a SRTP packet is injected
with an old value, it value of TBD to for this. Note to RFC
Editor: TBD will be discards allocated by the RTP stack IANA.

Considerations for being
old. It is more important that new things this type of extension are encrypted with the
most recent EKT Key.

How many bits to differentiate different types described in Section 5
of packets [RFC4366] and allow
for extensibility?

Given requires "IETF Consensus".

5.4. TLS Content Type

IANA is requested to add "srtp_ekt_message" as an new descriptions
name to the amount "TLS ContentType Registry" table of old EKT deployed, should the Full EKT use "Transport Layer
Security (TLS) Extensions" registry with a reference to this
specification, a
different code point than the "1" at the end?

Do we need AES-192?

7. IANA Considerations

No IANA actions are required.

8. DTLS-OK value of "Y", and allocate a value of TBD to
for this content type. Note to RFC Editor: TBD will be allocated by
IANA.

This registry was defined in Section 12 of [RFC5246] and requires
"Standards Action".

6. Acknowledgements

Thank you to Russ Housley provided detailed review and significant
help with crafting text for this document. Thanks to David Benham,
Eddy Lem, Felix Wyss, Jonathan Lennox, Kai Fischer, Lakshminath
Dondeti, Magnus Westerlund, Michael Peck, Nermeen Ismail, Paul Jones,
Rob Raymond, and Yi Cheng for fruitful discussions, comments, and
contributions to this document.

This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03
and most much of the text here came from that draft.

7. References

9.1.

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/
RFC2119, 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009,
<http://www.rfc-editor.org/info/rfc5649>.

[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.

9.2.

7.2. Informative References

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.

[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<http://www.rfc-editor.org/info/rfc4366>.

Authors' Addresses

Cullen Jennings
Cisco Systems
Calgary, AB
Canada

Email: fluffy@iii.ca

John Mattsson (editor)
Ericsson AB
SE-164 80 Stockholm
Sweden

Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
David A. McGrew
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
US

Phone: (408) 525 8651
Email: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm

Dan Wing
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
US

Phone: (408) 853 4197
Email: dwing@cisco.com

Flemming Andreason
Cisco Systems
499 Thornall Street
Edison, NJ 08837
US

Email: fandreas@cisco.com

Cullen Jennings
Cisco Systems
Calgary, AB
Canada

Email: fluffy@iii.ca