draft-ietf-perc-srtp-ekt-diet-07.txt   draft-ietf-perc-srtp-ekt-diet-08.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Mattsson Intended status: Standards Track J. Mattsson
Expires: September 6, 2018 Ericsson AB Expires: January 16, 2019 Ericsson AB
D. McGrew D. McGrew
D. Wing D. Wing
F. Andreason F. Andreason
Cisco Systems Cisco Systems
March 5, 2018 July 15, 2018
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-07 draft-ietf-perc-srtp-ekt-diet-08
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS and Secure Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
Real-time Transport Protocol (SRTP) that provides for the secure Transport Layer Security) and Secure Real-time Transport Protocol
transport of SRTP master keys, rollover counters, and other (SRTP) that provides for the secure transport of SRTP master keys,
information within SRTP. This facility enables SRTP for rollover counters, and other information within SRTP. This facility
decentralized conferences by distributing a common key to all of the enables SRTP for decentralized conferences by distributing a common
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on January 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used In This Document . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4
4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4
4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Processing and State Machine . . . . . . . . . . . 7 4.2. Packet Processing and State Machine . . . . . . . . . . . 7
4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8
4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9
4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10
4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12
4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12
4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Timing and Reliability Consideration . . . . . . . . . . 12 4.7. Timing and Reliability Consideration . . . . . . . . . . 13
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 13 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14
5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14
5.2.1. Negotiating an EKT Cipher . . . . . . . . . . . . . . 16 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 16
5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18
5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19
7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21
7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 27 skipping to change at page 3, line 27
conventional signaling systems cannot easily provide all of the conventional signaling systems cannot easily provide all of the
coordination required. It is also desirable to eliminate the layer coordination required. It is also desirable to eliminate the layer
violations that occur when signaling systems coordinate certain SRTP violations that occur when signaling systems coordinate certain SRTP
parameters, such as SSRC values and ROCs. parameters, such as SSRC values and ROCs.
This document defines Encrypted Key Transport (EKT) for SRTP and This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a reduces the amount of external signaling control that is needed in a
SRTP session with multiple receivers. EKT securely distributes the SRTP session with multiple receivers. EKT securely distributes the
SRTP master key and other information for each SRTP source. With SRTP master key and other information for each SRTP source. With
this method, SRTP entities are free to choose SSRC values as they see this method, SRTP entities are free to choose SSRC values as they see
fit, and to start up new SRTP sources with new SRTP master keys (see fit, and to start up new SRTP sources with new SRTP master keys
Section 2.2) within a session without coordinating with other within a session without coordinating with other entities via
entities via external signaling or other external means. external signaling or other external means.
EKT provides a way for an SRTP session participant, either a sender EKT provides a way for an SRTP session participant, to securely
or receiver, to securely transport its SRTP master key and current transport its SRTP master key and current SRTP rollover counter to
SRTP rollover counter to the other participants in the session. This the other participants in the session. This data furnishes the
data furnishes the information needed by the receiver to instantiate information needed by the receiver to instantiate an SRTP/SRTCP
an SRTP/SRTCP receiver context. receiver context.
EKT can be used in conferences where the central media distributor or EKT can be used in conferences where the central media distributor or
conference bridge can not decrypt the media, such as the type defined conference bridge cannot decrypt the media, such as the type defined
for [I-D.ietf-perc-private-media-framework]. It can also be used for for [I-D.ietf-perc-private-media-framework]. It can also be used for
large scale conferences where the conference bridge or media large scale conferences where the conference bridge or media
distributor can decrypt all the media but wishes to encrypt the media distributor can decrypt all the media but wishes to encrypt the media
it is sending just once then send the same encrypted media to a large it is sending just once and then send the same encrypted media to a
number of participants. This reduces the amount of CPU time needed large number of participants. This reduces the amount of CPU time
for encryption and can be used for some optimization to media sending needed for encryption and can be used for some optimization to media
that use source specific multicast. sending that use source specific multicast.
EKT does not control the manner in which the SSRC is generated; it is EKT does not control the manner in which the SSRC is generated; it is
only concerned with their secure transport. only concerned with their secure transport.
EKT is not intended to replace external key establishment mechanisms. EKT is not intended to replace external key establishment mechanisms.
Instead, it is used in conjunction with those methods, and it Instead, it is used in conjunction with those methods, and it
relieves those methods of the burden to deliver the context for each relieves those methods of the burden to deliver the context for each
SRTP source to every SRTP participant. SRTP source to every SRTP participant.
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 to provide an ekt_key to the client during the DTLS negotiation, see Section 5, to provide an EKTKey to the client during
handshake. This ekt_key can be used to encrypt the SRTP master key the DTLS handshake. The EKTKey thus obtained can be used to encrypt
used to encrypt the media the endpoint sends. This specification the SRTP master key that is used to encrypt the media sent by the
also defines a way to send the encrypted SRTP master key along with endpoint. This specification also defines a way to send the
the SRTP packet. Endpoints that receive this and know the ekt_key encrypted SRTP master key (with the EKTKey) along with the SRTP
can use the ekt_key to decrypt the SRTP master key then use the SRTP packet, see Section 4. Endpoints that receive this and know the
master key to decrypt the SRTP packet. 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 is used is described in the architecture defined One way to use this is described in the architecture defined by
by [I-D.ietf-perc-private-media-framework]. Each participants in the [I-D.ietf-perc-private-media-framework]. Each participant in the
conference call forms a DTLS-SRTP connection to a common key conference forms a DTLS-SRTP connection to a common key distributor
distributor that gives all the endpoints the same ekt_key. Then each that distributes the same EKTKey to all the endpoints. Then each
endpoint picks there own SRTP master key for the media they send. endpoint picks their own SRTP master key for the media they send.
When sending media, the endpoint also includes the SRTP master key When sending media, the endpoint also includes the SRTP master key
encrypted with the ekt_key. This allows all the endpoints to decrypt encrypted with the EKTKey in the SRTP packet. This allows all the
the media. endpoints to decrypt 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 EKT SRTP master key, and other additional information, an additional
field is added to SRTP packets. The EKT field appears at the end of field, called EKTField, is added to the SRTP packets. The EKTField
the SRTP packet. The EKT field appears after the optional appears at the end of the SRTP packet. It appears after the optional
authentication tag if one is present, otherwise the EKT field appears authentication tag if one is present, otherwise the EKTField appears
after the ciphertext portion of the packet. after the ciphertext portion of the packet.
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
features duplicate some of the functions of EKT. Senders MUST NOT features duplicate some of the functions of EKT. Senders MUST NOT
include MKI when using EKT. Receivers SHOULD simply ignore any MKI include MKI when using EKT. Receivers SHOULD simply ignore any MKI
field received if EKT is in use. field received if EKT is in use.
4.1. EKT Field Formats 4.1. EKTField Formats
The EKT Field uses the format defined below for the FullEKTField and The EKTField uses the format defined below for the FullEKTField and
ShortEKTField. ShortEKTField.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: EKT Ciphertext : : EKT Ciphertext :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Length | | Security Parameter Index | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: Full EKT Field 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: Short EKT Field format Figure 2: ShortEKTField format
The following shows the syntax of the EKTField expressed in ABNF The following shows the syntax of the EKTField expressed in ABNF
[RFC5234]. The EKTField is added to the end of an SRTP or SRTCP [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP
packet. The EKTPlaintext is the concatenation of packet. The EKTPlaintext is the concatenation of
SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The
EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTCiphertext is computed by encrypting the EKTPlaintext using the
EKTKey. Future extensions to the EKTField MUST conform to the syntax EKTKey. Future extensions to the EKTField MUST conform to the syntax
of ExtensionEKTField. of ExtensionEKTField.
BYTE = %x00-FF BYTE = %x00-FF
skipping to change at page 6, line 38 skipping to change at page 6, line 38
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField Syntax Figure 3: EKTField Syntax
These fields and data elements are defined as follows: These fields and data elements are defined as follows:
EKTPlaintext: The data that is input to the EKT encryption operation. EKTPlaintext: The data that is input to the EKT encryption operation.
This data never appears on the wire, and is used only in computations This data never appears on the wire, and is used only in computations
internal to EKT. This is the concatenation of the SRTP Master Key, internal to EKT. This is the concatenation of the SRTP Master Key
the SSRC, and the ROC. and its length, the SSRC, and the ROC.
EKTCiphertext: The data that is output from the EKT encryption EKTCiphertext: The data that is output from the EKT encryption
operation, described in Section 4.4. This field is included in SRTP operation, described in Section 4.4. This field is included in SRTP
packets when EKT is in use. The length of EKTCiphertext can be packets when EKT is in use. The length of EKTCiphertext can be
larger than the length of the EKTPlaintext that was encrypted. larger than the length of the EKTPlaintext that was encrypted.
SRTPMasterKey: On the sender side, the SRTP Master Key associated SRTPMasterKey: On the sender side, the SRTP Master Key associated
with the indicated SSRC. with the indicated SSRC.
SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
depends on the cipher suite negotiated for SRTP using SDP Offer/ depends on the cipher suite negotiated for SRTP using SDP Offer/
Answer [RFC3264] for the SRTP. Answer [RFC3264] for the SRTP.
SSRC: On the sender side, this field is the SSRC for this SRTP SSRC: On the sender side, this is the SSRC for this SRTP source. The
source. The length of this field is 32 bits. length of this field is 32 bits.
Rollover Counter (ROC): On the sender side, this field is set to the Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP context current value of the SRTP rollover counter in the SRTP/SRTCP context
associated with the SSRC in the SRTP or SRTCP packet. The length of associated with the SSRC in the SRTP or SRTCP packet. The length of
this field is 32 bits. this field is 32 bits.
Security Parameter Index (SPI): This field indicates the appropriate Security Parameter Index (SPI): This field indicates the appropriate
EKT Key and other parameters for the receiver to use when processing EKTKey and other parameters for the receiver to use when processing
the packet. The length of this field is 16 bits. The parameters the packet. The length of this field is 16 bits. The parameters
identified by this field are: identified by this field are:
o The EKT cipher used to process the packet. o The EKT cipher used to process the packet.
o The EKT Key used to process the packet. o The EKTKey used to process the packet.
o The SRTP Master Salt associated with any Master Key encrypted with o The SRTP Master Salt associated with any master key encrypted with
this EKT Key. The Master Salt is communicated separately, via this EKT Key. The master salt is communicated separately, via
signaling, typically along with the EKTKey. signaling, typically along with the EKTKey.
Together, these data elements are called an EKT parameter set. Each Together, these data elements are called an EKT parameter set. Each
distinct EKT parameter set that is used MUST be associated with a distinct EKT parameter set that is used MUST be associated with a
distinct SPI value to avoid ambiguity. distinct SPI value to avoid ambiguity.
EKTMsgLength: All EKT message other that ShortEKTField have a length EKTMsgLength: All EKT messages types other than the ShortEKTField
as second from the last element. This is the length in octets of have a length as second from the last element. This is the length in
either the FullEKTField/ExtensionEKTField including this length field octets of either the FullEKTField/ExtensionEKTField including this
and the following message type. length field and the following EKT Message Type.
Message Type: The last byte is used to indicate the type of the Message Type: The last byte is used to indicate the type of the
EKTField. This MUST be 2 in the FullEKTField format and 0 in EKTField. This MUST be 2 for the FullEKTField format and 0 in
ShortEKTField format. Values less than 64 are mandatory to ShortEKTField format. Values less than 64 are mandatory to
understand while other values are optional to understand. A receiver understand while other values are optional to understand. A receiver
SHOULD discard the whole EKTField if it contains any message type SHOULD discard the whole EKTField if it contains any message type
value that is less than 64 and that is not understood. Message type value that is less than 64 and that is not understood. Message type
values that are 64 or greater but not implemented or understood can values that are 64 or greater but not implemented or understood can
simply be ignored. simply be ignored.
4.2. Packet Processing and State Machine 4.2. Packet Processing and State Machine
At any given time, each SRTP/SRTCP source has associated with it a At any given time, each SRTP/SRTCP source has associated with it a
skipping to change at page 8, line 10 skipping to change at page 8, line 10
SSRC. There may be other EKT parameter sets that are used by other SSRC. There may be other EKT parameter sets that are used by other
SRTP/SRTCP sources in the same session, including other SRTP/SRTCP SRTP/SRTCP sources in the same session, including other SRTP/SRTCP
sources on the same endpoint (e.g., one endpoint with voice and video sources on the same endpoint (e.g., one endpoint with voice and video
might have two EKT parameter sets, or there might be multiple video might have two EKT parameter sets, or there might be multiple video
sources on an endpoint each with their own EKT parameter set). All sources on an endpoint each with their own EKT parameter set). All
of the received EKT parameter sets SHOULD be stored by all of the of the received EKT parameter sets SHOULD be stored by all of the
participants in an SRTP session, for use in processing inbound SRTP participants in an SRTP session, for use in processing inbound SRTP
and SRTCP traffic. and SRTCP traffic.
Either the FullEKTField or ShortEKTField is appended at the tail end Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets. The decision on which to send is specified in of all SRTP packets. The decision on which to send when is specified
Section 4.7. in Section 4.7.
4.2.1. Outbound Processing 4.2.1. Outbound Processing
See Section 4.7 which describes when to send an SRTP packet with a See Section 4.7 which describes when to send an SRTP packet with a
FullEKTField. If a FullEKTField is not being sent, then a FullEKTField. If a FullEKTField is not being sent, then a
ShortEKTField is sent so the receiver can correctly determine how to ShortEKTField is sent so the receiver can correctly determine how to
process the packet. process the packet.
When an SRTP packet is sent with a FullEKTField, the EKTField for When an SRTP packet is sent with a FullEKTField, the EKTField for
that packet is created as follows, or uses an equivalent set of that packet is created as follows, or uses an equivalent set of
skipping to change at page 8, line 35 skipping to change at page 8, line 35
1. The Security Parameter Index (SPI) field is set to the value of 1. The Security Parameter Index (SPI) field is set to the value of
the Security Parameter Index that is associated with the outbound the Security Parameter Index that is associated with the outbound
parameter set. parameter set.
2. The EKTPlaintext field is computed from the SRTP Master Key, 2. The EKTPlaintext field is computed from the SRTP Master Key,
SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP
Master Key, and SSRC used in EKT processing SHOULD be the same as Master Key, and SSRC used in EKT processing SHOULD be the same as
the one used in the SRTP processing. the one used in the SRTP processing.
3. The EKTCiphertext field is set to the ciphertext created by 3. The EKTCiphertext field is set to the ciphertext created by
encrypting the EKTPlaintext with the EKT cipher, using the EKTKey encrypting the EKTPlaintext with the EKTCipher using the EKTKey
as the encryption key. The encryption process is detailed in as the encryption key. The encryption process is detailed in
Section 4.4. Section 4.4.
4. Then the FullEKTField is formed using the EKTCiphertext and the 4. Then the FullEKTField is formed using the EKTCiphertext and the
SPI associated with the EKTKey used above. Also appended are the SPI associated with the EKTKey used above. Also appended are the
Length and Message Type using the FullEKTField format. Length and Message Type using the FullEKTField format.
* Note: the value of the EKTCiphertext field is identical in * Note: the value of the EKTCiphertext field is identical in
successive packets protected by the same EKTKey and SRTP successive packets protected by the same EKTKey and SRTP
master key. This value MAY be cached by an SRTP sender to master key. This value MAY be cached by an SRTP sender to
minimize computational effort. minimize computational effort.
The computed value of the FullEKTField is written into the The computed value of the FullEKTField is written into the SRTP
packet. packet.
When a packet is sent with the Short EKT Field, the ShortEKFField is When a packet is sent with the ShortEKTField, the ShortEKFField is
simply appended to the packet. simply appended to the packet.
4.2.2. Inbound Processing 4.2.2. Inbound Processing
When receiving a packet on a RTP stream, the following steps are When receiving a packet on a RTP stream, the following steps are
applied for each received packet. applied for each SRTP received packet.
1. The final byte is checked to determine which EKT format is in 1. The final byte is checked to determine which EKT format is in
use. When an SRTP or SRTCP packet contains a ShortEKTField, the use. When an SRTP or SRTCP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP or ShortEKTField is removed from the packet then normal SRTP or
SRTCP processing occurs. If the packet contains a FullEKTField, SRTCP processing occurs. If the packet contains a FullEKTField,
then processing continues as described below. The reason for then processing continues as described below. The reason for
using the last byte of the packet to indicate the type is that using the last byte of the packet to indicate the type is that
the length of the SRTP or SRTCP part is not known until the the length of the SRTP or SRTCP part is not known until the
decryption has occurred. At this point in the processing, there decryption has occurred. At this point in the processing, there
is no easy way to know where the EKT field would start. However, is no easy way to know where the EKTField would start. However,
the whole UDP packet has been received so instead of the starting the whole UDP packet has been received, so instead of the
at the front of the packet, the parsing works backwards off the starting at the front of the packet, the parsing works backwards
end of the packet and thus the type is put at the very end of the at the end of the packet and thus the type is placed at the very
packet. end of the packet.
2. The Security Parameter Index (SPI) field is used to find which 2. The Security Parameter Index (SPI) field is used to find the
EKT parameter set to be used when 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 SRTP Master Salt. contains the EKTKey, EKTCipher, and the SRTP Master Salt.
3. The EKTCiphertext authentication is checked and it is decrypted, 3. The EKTCiphertext authentication is checked and is decrypted, as
as described in Section 4.4, using the EKTKey and EKTCipher found described in Section 4.4, using the EKTKey and EKTCipher found in
in the previous step. If the EKT decryption operation returns an the previous step. If the EKT decryption operation returns an
authentication failure, then the packet processing stops. authentication failure, then the packet processing stops.
4. The resulting EKTPlaintext is parsed as described in Section 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 sent as part of the EKTkey
is longer than needed by SRTP, then it is truncated by taking the is longer than needed by SRTP, then it is truncated by taking the
first N bytes from the srtp_master_salt field. first N bytes from the srtp_master_salt field.
5. If the SSRC in the EKTPlaintext does not match the SSRC of the 5. If the SSRC in the EKTPlaintext does not match the SSRC of the
SRTP packet, then all the information from this EKTPlaintext MUST SRTP packet received, then all the information from this
be discarded and the following steps in this list are not done. EKTPlaintext MUST be discarded and the following steps in this
list are skipped.
6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
step are saved in a map indexed by the SSRC found in the 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. If the SRTP Master Key the inbound packets with that SSRC. If the SRTP Master Key
recovered from the EKTPlaintext is longer than needed by SRTP recovered from the EKTPlaintext is longer than needed by SRTP
transform in use, the first bytes are used. If the SRTP Master transform in use, the first bytes are used. If the SRTP Master
Key recovered from the EKTPlaintext is shorter than needed by Key recovered from the EKTPlaintext is shorter than needed by
SRTP transform in use, then the bytes received replace the first SRTP transform in use, then the bytes received replace the first
bytes in the existing key but the other bytes after that remain bytes in the existing key but the other bytes after that remain
the same as the old key. This allows for replacing just half the the same as the old key. This applies in transforms such as
key for transforms such as [I-D.ietf-perc-double]. Outbound [I-D.ietf-perc-double] for replacing just half the key, but
packets SHOULD continue to use the old SRTP Master Key for 250 ms SHOULD return a processing error otherwise. Outbound packets
after sending any new key. This gives all the receivers in the SHOULD continue to use the old SRTP Master Key for 250 ms after
system time to get the new key before they start receiving media 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. encrypted with the new key.
7. At this point, EKT processing has successfully completed, and the 7. At this point, EKT processing has successfully completed, and the
normal SRTP or SRTCP processing takes place including replay normal SRTP or SRTCP processing takes place including replay
protection. protection.
4.3. Implementation Notes 4.3. Implementation Notes
The value of the EKTCiphertext field is identical in successive The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP packets protected by the same EKT parameter set and the same SRTP
master key, and ROC. This ciphertext value MAY be cached by an SRTP master key, and ROC. This ciphertext value MAY be cached by an SRTP
receiver to minimize computational effort by noting when the SRTP receiver to minimize computational effort by noting when the SRTP
master key is unchanged and avoiding repeating the above steps. master key is unchanged and avoiding repeating the steps defined in .
The receiver may want to have a sliding window to retain old SRTP The receiver may want to have a sliding window to retain old SRTP
master keys (and related context) for some brief period of time, so Master Keys (and related context) for some brief period of time, so
that out of order packets can be processed as well as packets sent that out of order packets can be processed as well as packets sent
during the time keys are changing. during the time keys are changing.
When receiving a new EKTKey, implementations need to use the ekt_ttl When receiving a new EKTKey, implementations need to use the ekt_ttl
to create a time after which this key cannot be used and they also 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 keys need to create a counter that keeps track of how many times the key
has been used to encrypt data to ensure it does not exceed the T has been used to encrypt data to ensure it does not exceed the T
value for that cipher. If either of these limits are exceeded, the value for that cipher (see ). If either of these limits are
key can no longer be used for encryption. At this point exceeded, the key can no longer be used for encryption. At this
implementation need to either use the call signaling to renegotiation point implementation need to either use the call signaling to
a new session or need to terminate the existing session. Terminating renegotiate a new session or need to terminate the existing session.
the session is a reasonable implementation choice because these Terminating the session is a reasonable implementation choice because
limits should not be exceeded except under an attack or error these limits should not be exceeded except under an attack or error
condition. 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
skipping to change at page 11, line 43 skipping to change at page 11, line 50
FullEKTField is retransmitted 3 times, that only counts as 1 FullEKTField is retransmitted 3 times, that only counts as 1
encryption. encryption.
Security requirements for EKT ciphers are discussed in Section 6. Security requirements for EKT ciphers are discussed in Section 6.
4.4.1. Ciphers 4.4.1. Ciphers
The default EKT Cipher is the Advanced Encryption Standard (AES) Key The default EKT Cipher is the Advanced Encryption Standard (AES) Key
Wrap with Padding [RFC5649] algorithm. It requires a plaintext Wrap with Padding [RFC5649] algorithm. It requires a plaintext
length M that is at least one octet, and it returns a ciphertext with length M that is at least one octet, and it returns a ciphertext with
a length of N = M + (M mod 8) + 8 octets. It can be used with key a length of N = M + (M mod 8) + 8 octets.
sizes of L = 16, and L = 32 octets, and its use with those key sizes It can be used with key sizes of L = 16, and L = 32 octets, and its
is indicated as AESKW128, or AESKW256, respectively. The key size use with those key sizes is indicated as AESKW128, or AESKW256,
determines the length of the AES key used by the Key Wrap algorithm. respectively. The key size determines the length of the AES key used
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
skipping to change at page 12, line 44 skipping to change at page 12, line 46
new FullEKTField. This ensures that if key management thought the new FullEKTField. This ensures that if key management thought the
EKTKey needs changing (due to a participant leaving or joining) and EKTKey needs changing (due to a participant leaving or joining) and
communicated that to a source, the source will also change its SRTP communicated that to a source, the source will also change its SRTP
master key, so that traffic can be decrypted only by those who know master key, so that traffic can be decrypted only by those who know
the current EKTKey. the current EKTKey.
4.6. Transport 4.6. Transport
EKT SHOULD be used over SRTP, and other specification MAY define how EKT SHOULD be used over SRTP, and other specification MAY define how
to use it over SRTCP. SRTP is preferred because it shares fate with to use it over SRTCP. SRTP is preferred because it shares fate with
transmitted media, because SRTP rekeying can occur without concern the transmitted media, because SRTP rekeying can occur without
for RTCP transmission limits, and to avoid SRTCP compound packets concern for RTCP transmission limits, and to avoid SRTCP compound
with RTP translators and mixers. packets with RTP translators and mixers.
4.7. Timing and Reliability Consideration 4.7. Timing and Reliability Consideration
A system using EKT learns the SRTP master keys distributed with A system using EKT learns the SRTP master keys distributed with the
FullEKTFields sent with the SRTP, rather than with call signaling. A FullEKTField sent with the SRTP, rather than with call signaling. A
receiver can immediately decrypt an SRTP packet, provided the SRTP receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a Full EKT Field. packet contains a FullEKTField.
This section describes how to reliably and expediently deliver new This section describes how to reliably and expediently deliver new
SRTP master keys to receivers. SRTP master keys to receivers.
There are three cases to consider. The first case is a new sender There are three cases to consider. The first case is a new sender
joining a session which needs to communicate its SRTP master key to joining a session which needs to communicate its SRTP master key to
all the receivers. The second case is a sender changing its SRTP all the receivers. The second case is a sender changing its SRTP
master key which needs to be communicated to all the receivers. The master key which needs to be communicated to all the receivers. The
third case is a new receiver joining a session already in progress third case is a new receiver joining a session already in progress
which needs to know the sender's SRTP master key. which needs to know the sender's SRTP master key.
The three cases are: The three cases are:
New sender: New sender:
A new sender SHOULD send a packet containing the FullEKTField as A new sender SHOULD send a packet containing the FullEKTField as
soon as possible, always before or coincident with sending its soon as possible, always before or coincident with sending its
initial SRTP packet. To accommodate packet loss, it is initial SRTP packet. To accommodate packet loss, it is
RECOMMENDED that three consecutive packets contain the Full EKT RECOMMENDED that three consecutive packets contain the
Field be transmitted. FullEKTField be transmitted.
Rekey: Rekey:
By sending EKT over SRTP, the rekeying event shares fate with the By sending EKT tag over SRTP, the rekeying event shares fate with
SRTP packets protected with that new SRTP master key. To the SRTP packets protected with that new SRTP master key. To
accommodate packet loss, it is RECOMMENDED that three consecutive accommodate packet loss, it is RECOMMENDED that three consecutive
packets contain the FullEKTField be transmitted. packets contain the FullEKTField be transmitted.
New receiver: New receiver:
When a new receiver joins a session it does not need to When a new receiver joins a session it does not need to
communicate its sending SRTP master key (because it is a communicate its sending SRTP master key (because it is a
receiver). When a new receiver joins a session the sender is receiver). When a new receiver joins a session, the sender is
generally unaware of the receiver joining the session. Thus, generally unaware of the receiver joining the session. Thus,
senders SHOULD periodically transmit the FullEKTField. That senders SHOULD periodically transmit the FullEKTField. That
interval depends on how frequently new receivers join the session, interval depends on how frequently new receivers join the session,
the acceptable delay before those receivers can start processing the acceptable delay before those receivers can start processing
SRTP packets, and the acceptable overhead of sending the FullEKT SRTP packets, and the acceptable overhead of sending the
Field. If sending audio and video, the RECOMMENDED frequency is FullEKTField. If sending audio and video, the RECOMMENDED
the same as the rate of intra coded video frames. If only sending frequency is the same as the rate of intra coded video frames. If
audio, the RECOMMENDED frequency is every 100ms. only sending audio, the RECOMMENDED frequency is every 100ms.
5. Use of EKT with DTLS-SRTP 5. Use of EKT with DTLS-SRTP
This document defines an extension to DTLS-SRTP called SRTP EKT Key This document defines an extension to DTLS-SRTP called SRTP EKTKey
Transport which enables secure transport of EKT keying material from Transport which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client. This allows the DTLS-SRTP peer in the server role to the client. This allows
those peers to process EKT keying material in SRTP (or SRTCP) and those peers to process EKT keying material in SRTP (or SRTCP) and
retrieve the embedded SRTP keying material. This combination of retrieve the embedded SRTP keying material. This combination of
protocols is valuable because it combines the advantages of DTLS, protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility, which has strong authentication of the endpoint and flexibility,
along with allowing secure multiparty RTP with loose coordination and along with allowing secure multiparty RTP with loose coordination and
efficient communication of per-source keys. efficient communication of per-source keys.
5.1. DTLS-SRTP Recap 5.1. DTLS-SRTP Recap
skipping to change at page 15, line 41 skipping to change at page 15, line 41
<> 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
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 session allow the DTLS server to set a extensions defined in this session allows the DTLS server to set a
common EKT key among all participants. Each endpoint can then use common EKTKey for all participants. Each endpoint can then use EKT
EKT tags encrypted with that common key to inform other endpoint of tags encrypted with that common key to inform other endpoint of the
the keys it is using to protect SRTP packet. This avoids the need keys it uses to protect SRTP packets. This avoids the need for many
for many individual DTLS handshakes among the endpoints, at the cost individual DTLS handshakes among the endpoints, at the cost of
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 EKT Cipher 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
EKT ciphers the client supports in preference order, with the most ciphers used for EKT by the client supports in preference order, with
preferred version first. If the server agrees to use EKT, then it the most preferred version first. If the server agrees to use EKT,
includes a supported_ekt_ciphers extension in its ServerHello then it includes a supported_ekt_ciphers extension in its ServerHello
containing a cipher selected from among those advertised by the containing a cipher selected from among those advertised by the
client. client.
The extension_data field of this extension contains an "EKTCipher" The extension_data field of this extension contains an "EKTCipher"
value, encoded using the syntax defined in [RFC5246]: value, encoded using the syntax defined in [RFC5246]:
enum { enum {
reserved(0), reserved(0),
aeskw_128(1), aeskw_128(1),
aeskw_256(2), aeskw_256(2),
skipping to change at page 16, line 47 skipping to change at page 16, line 47
EKTCipherType supported_ciphers<1..255>; EKTCipherType supported_ciphers<1..255>;
case server_hello: case server_hello:
EKTCipherType selected_cipher; 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 EKT cipher, 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. EKT keys 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(TBD). The body of the handshake message contains an EKTKey
structure: structure:
[[ NOTE: RFC Editor, please replace "TBD" above with the code point [[ NOTE: RFC Editor, please replace "TBD" above with the code point
assigned by IANA ]] 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 EKT Key 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 EKT Key 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 EKT Key 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 either the its ServerHello, then EKTKey messages MUST NOT be sent by the client
client or the server. or the server.
When an EKTKey is received and processed successfully, the recipient When an EKTKey is received and processed successfully, the recipient
MUST respond with an Ack handshake message as described in Section 7 MUST respond with an Ack handshake message as described in Section 7
of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be
retransmitted following the rules in Section 4.2.4 of [RFC6347]. retransmitted following the rules in Section 4.2.4 of [RFC6347].
Note: To be clear, EKT can be used with versions of DTLS prior to Note: To be clear, EKT can be used with versions of DTLS prior to
1.3. The only difference is that in a pre-1.3 TLS stacks will not 1.3. The only difference is that in a pre-1.3 TLS stacks will not
have built-in support for generating and processing Ack messages. have built-in support for generating and processing Ack messages.
skipping to change at page 18, line 48 skipping to change at page 18, line 48
The presence of the SSRC in the EKTPlaintext ensures that an attacker The presence of the SSRC in the EKTPlaintext ensures that an attacker
cannot substitute an EKTCiphertext from one SRTP stream into another cannot substitute an EKTCiphertext from one SRTP stream into another
SRTP stream. SRTP stream.
An attacker who tampers with the bits in FullEKTField can prevent the An attacker who tampers with the bits in FullEKTField can prevent the
intended receiver of that packet from being able to decrypt it. This intended receiver of that packet from being able to decrypt it. This
is a minor denial of service vulnerability. Similarly the attacker is a minor denial of service vulnerability. Similarly the attacker
could take an old FullEKTField from the same session and attach it to could take an old FullEKTField from the same session and attach it to
the packet. The FullEKTField would correctly decode and pass the packet. The FullEKTField would correctly decode and pass
integrity but the key extracted from the FullEKTField , when used to integrity checks. However, the key extracted from the FullEKTField ,
decrypt the SRTP payload, would be wrong and the SRTP integrity check when used to decrypt the SRTP payload, would be wrong and the SRTP
would fail. Note that the FullEKTField only changes the decryption integrity check would fail. Note that the FullEKTField only changes
key and does not change the encryption key. None of these are the decryption key and does not change the encryption key. None of
considered significant attacks as any attacker that can modify the these are considered significant attacks as any attacker that can
packets in transit and cause the integrity check to fail. modify the packets in transit and cause the integrity check to fail.
An attacker could send packets containing a Full EKT Field, in an An attacker could send packets containing a 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 will decrypt the EKT ciphertext and by causing the receiving system will decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the detect an authentication failure. In some cases, caching the
previous values of the Ciphertext as described in Section 4.3 helps previous values of the Ciphertext as described in Section 4.3 helps
mitigate this issue. mitigate this issue.
Each EKT cipher specifies a value T that is the maximum number of Each EKT cipher specifies a value T that is the maximum number of
times a given key can be used. An endpoint MUST NOT encrypt more times a given key can be used. An endpoint MUST NOT encrypt more
than T different Full EKT Field using the same EKTKey. In addition, than T different FullEKTField values using the same EKTKey. In
the EKTKey MUST NOT be used beyond the lifetime provided by the TTL addition, the EKTKey MUST NOT be used beyond the lifetime provided by
described in Figure 4. the TTL described in Figure 4.
The confidentiality, integrity, and authentication of the EKT cipher The confidentiality, integrity, and authentication of the EKT cipher
MUST be at least as strong as the SRTP cipher and at least as strong MUST be at least as strong as the SRTP cipher and at least as strong
as the DTLS-SRTP ciphers. as the DTLS-SRTP ciphers.
Part of the EKTPlaintext is known, or easily guessable to an Part of the EKTPlaintext is known, or easily guessable to an
attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does not impose any restrictions on our In practice, this requirement does not impose any restrictions on our
choices, since the ciphers in use provide high security even when choices, since the ciphers in use provide high security even when
much plaintext is known. much plaintext is known.
skipping to change at page 21, line 10 skipping to change at page 21, line 10
this specification. this specification.
New entries to this table can be added via "Specification Required" New entries to this table can be added via "Specification Required"
as defined in [RFC8126]. The expert SHOULD ensure the specification as defined in [RFC8126]. The expert SHOULD ensure the specification
defines the values for L and T as required in Section 4.4 of RFCAAAA. defines the values for L and T as required in Section 4.4 of RFCAAAA.
Allocated values MUST be in the range of 1 to 254. Allocated values MUST be in the range of 1 to 254.
7.3. TLS Extensions 7.3. TLS Extensions
IANA is requested to add supported_ekt_ciphers as a new extension IANA is requested to add supported_ekt_ciphers as a new extension
name to the "ExtensionType Values" table of the "Transport Layer name to the "TLS ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this. specification and allocate a value of TBD to for this.
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
Considerations for this type of extension are described in Section 5 Considerations for this type of extension are described in Section 5
of [RFC4366] and requires "IETF Consensus". of [RFC4366] and requires "IETF Consensus".
7.4. TLS Handshake Type 7.4. TLS Handshake Type
skipping to change at page 21, line 46 skipping to change at page 21, line 46
Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul
Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean
Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions,
comments, and contributions to this document. comments, and contributions to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997, <https://www.rfc-editor.org/info/
<https://www.rfc-editor.org/info/rfc2119>. 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
DOI 10.17487/RFC3264, June 2002, 10.17487/RFC3264, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
DOI 10.17487/RFC5234, January 2008, RFC5234, January 2008, <https://www.rfc-editor.org/info/
<https://www.rfc-editor.org/info/rfc5234>. rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
DOI 10.17487/RFC5246, August 2008, RFC5246, August 2008, <https://www.rfc-editor.org/info/
<https://www.rfc-editor.org/info/rfc5246>. rfc5246>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
DOI 10.17487/RFC5649, September 2009, 10.17487/RFC5649, September 2009, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5649>. editor.org/info/rfc5649>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764, DOI
DOI 10.17487/RFC5764, May 2010, 10.17487/RFC5764, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-perc-double] [I-D.ietf-perc-double]
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Double Encryption Procedures", draft-ietf-perc-double-07 Double Encryption Procedures", draft-ietf-perc-double-09
(work in progress), September 2017. (work in progress), May 2018.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-05 Conferencing", draft-ietf-perc-private-media-framework-06
(work in progress), October 2017. (work in progress), March 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-22 (work in progress), 1.3", draft-ietf-tls-dtls13-28 (work in progress), July
November 2017. 2018.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4086>. editor.org/info/rfc4086>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
 End of changes. 78 change blocks. 
177 lines changed or deleted 180 lines changed or added

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