draft-ietf-perc-srtp-ekt-diet-12.txt   draft-ietf-perc-srtp-ekt-diet-13.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: December 20, 2020 Ericsson AB Expires: December 25, 2020 Ericsson AB
D. McGrew D. McGrew
Cisco Systems Cisco Systems
D. Wing D. Wing
Citrix Systems, Inc. Citrix Systems, Inc.
F. Andreason F. Andreason
Cisco Systems Cisco Systems
June 18, 2020 June 23, 2020
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-12 draft-ietf-perc-srtp-ekt-diet-13
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
Transport Layer Security) and Secure Real-time Transport Protocol Transport Layer Security) and Secure Real-time Transport Protocol
(SRTP) that provides for the secure transport of SRTP master keys, (SRTP) that provides for the secure transport of SRTP master keys,
rollover counters, and other information within SRTP. This facility rollover counters, and other information within SRTP. This facility
enables SRTP for decentralized conferences by distributing a common enables SRTP for decentralized conferences by distributing a common
key to all of the conference endpoints. key to all of the conference endpoints.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2020. This Internet-Draft will expire on December 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used In This Document . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4
4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4
4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5
4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8 4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8
4.3. Packet Processing and State Machine . . . . . . . . . . . 8 4.3. Packet Processing and State Machine . . . . . . . . . . . 8
4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 9
4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10 4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10
4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12 4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12
4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13
4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13
4.6. Timing and Reliability Consideration . . . . . . . . . . 13 4.6. Timing and Reliability Consideration . . . . . . . . . . 13
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 15
5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15
5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17
5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19
5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21
7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 40 skipping to change at page 3, line 40
this method, SRTP entities are free to choose SSRC values as they see this method, SRTP entities are free to choose SSRC values as they see
fit, and to start up new SRTP sources with new SRTP master keys fit, and to start up new SRTP sources with new SRTP master keys
within a session without coordinating with other entities via within a session without coordinating with other entities via
external signaling or other external means. external signaling or other external means.
EKT extends DTLS and SRTP to enable a common key encryption key EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each (called an EKTKey) to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP endpoint can securely send its SRTP master key and current SRTP
rollover counter to the other participants in the session. This data rollover counter to the other participants in the session. This data
furnishes the information needed by the receiver to instantiate an furnishes the information needed by the receiver to instantiate an
SRTP/SRTCP receiver context. SRTP receiver context.
EKT can be used in conferences where the central media distributor or EKT can be used in conferences where the central media distributor or
conference bridge cannot decrypt the media, such as the type defined conference bridge cannot decrypt the media, such as the type defined
for [I-D.ietf-perc-private-media-framework]. It can also be used for for [I-D.ietf-perc-private-media-framework]. It can also be used for
large scale conferences where the conference bridge or media large scale conferences where the conference bridge or media
distributor can decrypt all the media but wishes to encrypt the media distributor can decrypt all the media but wishes to encrypt the media
it is sending just once and then send the same encrypted media to a it is sending just once and then send the same encrypted media to a
large number of participants. This reduces the amount of CPU time large number of participants. This reduces the amount of CPU time
needed for encryption and can be used for some optimization to media needed for encryption and can be used for some optimization to media
sending that use source specific multicast. sending that use source specific multicast.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
This document defines the use of EKT with SRTP. Its use with SRTCP This document defines the use of EKT with SRTP. Its use with SRTCP
would be similar, but is reserved for a future specification. SRTP would be similar, but is reserved for a future specification. SRTP
is preferred for transmitting key material because it shares fate is preferred for transmitting key material because it shares fate
with the transmitted media, because SRTP rekeying can occur without with the transmitted media, because SRTP rekeying can occur without
concern for RTCP transmission limits, and because it avoids the need concern for RTCP transmission limits, and because it avoids the need
for SRTCP compound packets with RTP translators and mixers. for SRTCP compound packets with RTP translators and mixers.
4.1. EKTField Formats 4.1. EKTField Formats
The EKTField uses the format defined in Figure 1 for the FullEKTField The EKTField uses the format defined in Figure 1 for the FullEKTField
and ShortEKTField. and ShortEKTField. The EKTField appended to an SRTP packet can be
referred to as an "EKT tag".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: EKT Ciphertext : : EKT Ciphertext :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index | Epoch | | Security Parameter Index | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 48 skipping to change at page 5, line 49
Figure 1: FullEKTField format Figure 1: FullEKTField format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: ShortEKTField format Figure 2: ShortEKTField format
The following shows the syntax of the EKTField expressed in ABNF 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 packet. The
packet. The EKTPlaintext is the concatenation of EKTPlaintext is the concatenation of SRTPMasterKeyLength,
SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is
EKTCiphertext is computed by encrypting the EKTPlaintext using the computed by encrypting the EKTPlaintext using the EKTKey. Future
EKTKey. Future extensions to the EKTField MUST conform to the syntax extensions to the EKTField MUST conform to the syntax of
of ExtensionEKTField. ExtensionEKTField.
BYTE = %x00-FF BYTE = %x00-FF
EKTMsgTypeFull = %x02 EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00 EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to
; usage by legacy implementations.
EKTMsgLength = 2BYTE; EKTMsgLength = 2BYTE;
SRTPMasterKeyLength = BYTE SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1*256BYTE SRTPMasterKey = 1*242BYTE
SSRC = 4BYTE; SSRC from RTP SSRC = 4BYTE; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE Epoch = 2BYTE
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
ShortEKTField = EKTMsgTypeShort ShortEKTField = EKTMsgTypeShort
ExtensionData = 1*1024BYTE ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField Syntax Figure 3: EKTField Syntax
These fields and data elements are defined as follows: These fields and data elements are defined as follows:
EKTPlaintext: The data that is input to the EKT encryption operation. EKTPlaintext: 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
and its length, the SSRC, and the ROC. and its length, the SSRC, and the ROC.
skipping to change at page 7, line 15 skipping to change at page 7, line 18
SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
depends on the cipher suite negotiated for SRTP using SDP Offer/ depends on the cipher suite negotiated for SRTP using SDP Offer/
Answer [RFC3264] for the SRTP. Answer [RFC3264] for the SRTP.
SSRC: On the sender side, this is the SSRC for this SRTP source. The SSRC: On the sender side, this is the SSRC for this SRTP source. The
length of this field is 32 bits. The SSRC value in the EKT tag MUST length of this field is 32 bits. The SSRC value in the EKT tag MUST
be the same as the one in the header of the SRTP packet to which the be the same as the one in the header of the SRTP packet to which the
tag is appended. tag is appended.
Rollover Counter (ROC): On the sender side, this is set to the Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP/SRTCP context current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP or SRTCP packet. The length of associated with the SSRC in the SRTP packet. The length of this
this field is 32 bits. field is 32 bits.
Security Parameter Index (SPI): This field indicates the appropriate Security Parameter Index (SPI): This field indicates the appropriate
EKTKey and other parameters for the receiver to use when processing EKTKey and other parameters for the receiver to use when processing
the packet, within a given conference. The length of this field is the packet, within a given conference. The length of this field is
16 bits, representing a two-byte integer in network byte order. The 16 bits, representing a two-byte integer in network byte order. The
parameters identified by this field are: parameters identified by this field are:
o The EKT cipher used to process the packet. o The EKT cipher used to process the packet.
o The EKTKey used to process the packet. o The EKTKey used to process the packet.
skipping to change at page 8, line 29 skipping to change at page 8, line 32
signaling, typically along with the EKTKey. signaling, typically along with the EKTKey.
Together, these data elements are called an "EKT parameter set". Together, these data elements are called an "EKT parameter set".
Each distinct EKT parameter set that is used MUST be associated with Each distinct EKT parameter set that is used MUST be associated with
a distinct SPI value to avoid ambiguity. The association of a given a distinct SPI value to avoid ambiguity. The association of a given
parameter set with a given SPI value is configured by some other parameter set with a given SPI value is configured by some other
protocol, e.g., the DTLS-SRTP extension defined in Section 5. protocol, e.g., the DTLS-SRTP extension defined in Section 5.
4.3. Packet Processing and State Machine 4.3. Packet Processing and State Machine
At any given time, each SRTP/SRTCP source has associated with it a At any given time, each SRTP source has associated with it a single
single EKT parameter set. This parameter set is used to process all EKT parameter set. This parameter set is used to process all
outbound packets, and is called the outbound parameter set for that outbound packets, and is called the outbound parameter set for that
SSRC. There may be other EKT parameter sets that are used by other SSRC. There may be other EKT parameter sets that are used by other
SRTP/SRTCP sources in the same session, including other SRTP/SRTCP SRTP sources in the same session, including other SRTP sources on the
sources on the same endpoint (e.g., one endpoint with voice and video same endpoint (e.g., one endpoint with voice and video might have two
might have two EKT parameter sets, or there might be multiple video EKT parameter sets, or there might be multiple video sources on an
sources on an endpoint each with their own EKT parameter set). All endpoint each with their own EKT parameter set). All of the received
of the received EKT parameter sets SHOULD be stored by all of the EKT parameter sets SHOULD be stored by all of the participants in an
participants in an SRTP session, for use in processing inbound SRTP SRTP session, for use in processing inbound SRTP traffic. If a
and SRTCP traffic. If a participant deletes an EKT parameter set participant deletes an EKT parameter set (e.g., because of space
(e.g., because of space limitations, then it will be unable to limitations, then it will be unable to process Full EKT Tags
process Full EKT Tags containing updated media keys, and thus unable containing updated media keys, and thus unable to receive media from
to receive media from a particpant that has changed its media key. a particpant that has changed its media key.
Either the FullEKTField or ShortEKTField is appended at the tail end Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets. The decision on which to send when is specified of all SRTP packets. The decision on which to send when is specified
in Section 4.6. in Section 4.6.
4.3.1. Outbound Processing 4.3.1. Outbound Processing
See Section 4.6 which describes when to send an SRTP packet with a See Section 4.6 which describes when to send an SRTP packet with a
FullEKTField. If a FullEKTField is not being sent, then a FullEKTField. If a FullEKTField is not being sent, then a
ShortEKTField is sent so the receiver can correctly determine how to ShortEKTField is sent so the receiver can correctly determine how to
process the packet. process the packet.
When an SRTP packet is sent with a FullEKTField, the EKTField for When an SRTP packet is sent with a FullEKTField, the EKTField for
that packet is created as follows, or uses an equivalent set of that packet is created as follows, or uses an equivalent set of
steps. The creation of the EKTField MUST precede the normal SRTP steps.
packet processing.
1. The Security Parameter Index (SPI) field is set to the value of 1. The Security Parameter Index (SPI) field is set to the value of
the Security Parameter Index that is associated with the outbound the Security Parameter Index that is associated with the outbound
parameter set. parameter set.
2. The EKTPlaintext field is computed from the SRTP Master Key, 2. The EKTPlaintext field is computed from the SRTP Master Key,
SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP
Master Key, and SSRC used in EKT processing MUST be the same as Master Key, and SSRC used in EKT processing MUST be the same as
the one used in the SRTP processing. the one used in the SRTP processing.
skipping to change at page 10, line 11 skipping to change at page 10, line 11
value of 250ms is chosen to represent a reasonable upper bound on the value of 250ms is chosen to represent a reasonable upper bound on the
amount of latency and jitter that is tolerable in a real-time amount of latency and jitter that is tolerable in a real-time
context.) context.)
4.3.2. Inbound Processing 4.3.2. Inbound Processing
When receiving a packet on a RTP stream, the following steps are When receiving a packet on a RTP stream, the following steps are
applied for each SRTP received packet. applied for each SRTP received packet.
1. The final byte is checked to determine which EKT format is in 1. The final byte is checked to determine which EKT format is in
use. When an SRTP or SRTCP packet contains a ShortEKTField, the use. When an SRTP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP or ShortEKTField is removed from the packet then normal SRTP
SRTCP processing occurs. If the packet contains a FullEKTField, processing occurs. If the packet contains a FullEKTField, then
then processing continues as described below. The reason for processing continues as described below. The reason for using
using the last byte of the packet to indicate the type is that the last byte of the packet to indicate the type is that the
the length of the SRTP or SRTCP part is not known until the length of the SRTP part is not known until the decryption has
decryption has occurred. At this point in the processing, there occurred. At this point in the processing, there is no easy way
is no easy way to know where the EKTField would start. However, to know where the EKTField would start. However, the whole UDP
the whole UDP packet has been received, so instead of the packet has been received, so instead of the starting at the front
starting at the front of the packet, the parsing works backwards of the packet, the parsing works backwards at the end of the
at the end of the packet and thus the type is placed at the very packet and thus the type is placed at the very end of the packet.
end of the packet.
2. The Security Parameter Index (SPI) field is used to find the 2. The Security Parameter Index (SPI) field is used to find the
right EKT parameter set to be used for processing the packet. If right EKT parameter set to be used for processing the packet. If
there is no matching SPI, then the verification function MUST there is no matching SPI, then the verification function MUST
return an indication of authentication failure, and the steps return an indication of authentication failure, and the steps
described below are not performed. The EKT parameter set described below are not performed. The EKT parameter set
contains the EKTKey, EKTCipher, and the SRTP Master Salt. contains the EKTKey, EKTCipher, and the SRTP Master Salt.
3. The EKTCiphertext is authenticated and decrypted, as described in 3. The EKTCiphertext is authenticated and decrypted, as described in
Section 4.4, using the EKTKey and EKTCipher found in the previous Section 4.4, using the EKTKey and EKTCipher found in the previous
skipping to change at page 10, line 45 skipping to change at page 10, line 44
SHOULD discard the whole UDP packet. SHOULD discard the whole UDP packet.
4. The resulting EKTPlaintext is parsed as described in Section 4.1, 4. The resulting EKTPlaintext is parsed as described in Section 4.1,
to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP
Master Salt that is associated with the EKTKey is also retrieved. Master Salt that is associated with the EKTKey is also retrieved.
If the value of the srtp_master_salt sent as part of the EKTkey If the value of the srtp_master_salt 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 received, then all the information from this SRTP packet received, then this FullEKTField MUST be discarded
EKTPlaintext MUST be discarded and the following steps in this and the following steps in this list skipped. After stripping
list are skipped. the FullEKTField, the remainder of the SRTP packet MAY be
processed as normal.
6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
steps are saved in a map indexed by the SSRC found in the steps are saved in a map indexed by the SSRC found in the
EKTPlaintext and can be used for any future crypto operations on EKTPlaintext and can be used for any future crypto operations on
the inbound packets with that SSRC. the inbound packets with that SSRC.
* Unless the transform specifies other acceptable key lengths, * Unless the transform specifies other acceptable key lengths,
the length of the SRTP Master Key MUST be the same as the the length of the SRTP Master Key MUST be the same as the
master key length for the SRTP transform in use. If this is master key length for the SRTP transform in use. If this is
not the case, then the receiver MUST abort EKT processing and not the case, then the receiver MUST abort EKT processing and
skipping to change at page 11, line 21 skipping to change at page 11, line 21
* If the length of the SRTP Master Key is less than the master * If the length of the SRTP Master Key is less than the master
key length for the SRTP transform in use, and the transform key length for the SRTP transform in use, and the transform
specifies that this length is acceptable, then the SRTP Master specifies that this length is acceptable, then the SRTP Master
Key value is used to replace the first bytes in the existing Key value is used to replace the first bytes in the existing
master key. The other bytes remain the same as in the old master key. The other bytes remain the same as in the old
key. For example, the Double GCM transform key. For example, the Double GCM transform
[I-D.ietf-perc-double] allows replacement of the first, "end [I-D.ietf-perc-double] allows replacement of the first, "end
to end" half of the master key. to end" half of the master key.
7. At this point, EKT processing has successfully completed, and the 7. At this point, EKT processing has successfully completed, and the
normal SRTP or SRTCP processing takes place. normal SRTP processing takes place.
The value of the EKTCiphertext field is identical in successive The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP packets protected by the same EKT parameter set and the same SRTP
master key, and ROC. SRTP senders and receivers MAY cache an master key, and ROC. SRTP senders and receivers MAY cache an
EKTCiphertext value to optimize processing in cases where the master EKTCiphertext value to optimize processing in cases where the master
key hasn't changed. Instead of encrypting and decrypting, senders key hasn't changed. Instead of encrypting and decrypting, senders
can simply copy the pre-computed value and receivers can compare a can simply copy the pre-computed value and receivers can compare a
received EKTCiphertext to the known value. received EKTCiphertext to the known value.
Section 4.3.1 recommends that SRTP senders continue using an old key Section 4.3.1 recommends that SRTP senders continue using an old key
skipping to change at page 13, line 39 skipping to change at page 13, line 39
how it is processed when it is read. This field is opaque to the how it is processed when it is read. This field is opaque to the
other aspects of EKT processing. EKT ciphers are free to use this other aspects of EKT processing. EKT ciphers are free to use this
field in any way, but they SHOULD NOT use other EKT or SRTP fields as field in any way, but they SHOULD NOT use other EKT or SRTP fields as
an input. The values of the parameters L, and T MUST be defined by an input. The values of the parameters L, and T MUST be defined by
each EKTCipher. The cipher MUST provide integrity protection. each EKTCipher. The cipher MUST provide integrity protection.
4.5. Synchronizing Operation 4.5. Synchronizing Operation
If a source has its EKTKey changed by the key management, it MUST If a source has its EKTKey changed by the key management, it MUST
also change its SRTP master key, which will cause it to send out a also change its SRTP master key, which will cause it to send out a
new FullEKTField. This ensures that if key management thought the new FullEKTField and eventually begin encrypting with it, as defined
in Section 4.3.1. This ensures that if key management thought the
EKTKey needs changing (due to a participant leaving or joining) and EKTKey needs changing (due to a participant leaving or joining) and
communicated that to a source, the source will also change its SRTP communicated that to a source, the source will also change its SRTP
master key, so that traffic can be decrypted only by those who know master key, so that traffic can be decrypted only by those who know
the current EKTKey. the current EKTKey.
4.6. Timing and Reliability Consideration 4.6. Timing and Reliability Consideration
A system using EKT learns the SRTP master keys distributed with the A system using EKT learns the SRTP master keys distributed with the
FullEKTField sent with the SRTP, rather than with call signaling. A FullEKTField sent with the SRTP, rather than with call signaling. A
receiver can immediately decrypt an SRTP packet, provided the SRTP receiver can immediately decrypt an SRTP packet, provided the SRTP
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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 RECOMMENDED that the FullEKTField be transmitted in three
FullEKTField be transmitted. If the sender does not send a consecutive packets. If the sender does not send a FullEKTField
FullEKTField in its initial packets and receivers have not in its initial packets and receivers have not otherwise been
otherwise been provisioned with a decryption key, then decryption provisioned with a decryption key, then decryption will fail and
will fail and SRTP packets will be dropped until the receiver SRTP packets will be dropped until the receiver receives a
receives a FullEKTField from the sender. FullEKTField from the sender.
Rekey: Rekey:
By sending EKT tag over SRTP, the rekeying event shares fate with By sending EKT tag over SRTP, the rekeying event shares fate with
the SRTP packets protected with that new SRTP master key. To the SRTP packets protected with that new SRTP master key. To
accommodate packet loss, it is RECOMMENDED that three consecutive accommodate packet loss, it is RECOMMENDED that three consecutive
packets contain the FullEKTField be transmitted. packets contain the FullEKTField be transmitted.
New receiver: New receiver:
When a new receiver joins a session it does not need to When a new receiver joins a session it does not need to
communicate its sending SRTP master key (because it is a communicate its sending SRTP master key (because it is a
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 SRTP packets, and the acceptable overhead of sending the
FullEKTField. If sending audio and video, the RECOMMENDED FullEKTField. If sending audio and video, the RECOMMENDED
frequency is the same as the rate of intra coded video frames. If frequency is the same as the rate of intra coded video frames. If
only sending audio, the RECOMMENDED frequency is every 100ms. only sending audio, the RECOMMENDED frequency is every 100ms.
In general, sending EKT tags less frequently will consume less
bandwidth, but increase the time it takes for a join or rekey to take
effect. Applications should schedule the sending of EKT tags in a
way that makes sense for their bandwidth and latency requirements.
5. Use of EKT with DTLS-SRTP 5. Use of EKT with DTLS-SRTP
This document defines an extension to DTLS-SRTP called SRTP EKTKey This document defines an extension to DTLS-SRTP called SRTP EKTKey
Transport which enables secure transport of EKT keying material from Transport which enables secure transport of EKT keying material 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 and retrieve the
retrieve the embedded SRTP keying material. This combination of embedded SRTP keying material. This combination of protocols is
protocols is valuable because it combines the advantages of DTLS, valuable because it combines the advantages of DTLS, which has strong
which has strong authentication of the endpoint and flexibility, authentication of the endpoint and flexibility, along with allowing
along with allowing secure multiparty RTP with loose coordination and secure multiparty RTP with loose coordination and efficient
efficient communication of per-source keys. communication of per-source keys.
In cases where the DTLS termination point is more trusted than the In cases where the DTLS termination point is more trusted than the
media relay, the protection that DTLS affords to EKT key material can media relay, the protection that DTLS affords to EKT key material can
allow EKT keys to be tunneled through an untrusted relay such as a allow EKT keys to be tunneled through an untrusted relay such as a
centralized conference bridge. For more details, see centralized conference bridge. For more details, see
[I-D.ietf-perc-private-media-framework]. [I-D.ietf-perc-private-media-framework].
5.1. DTLS-SRTP Recap 5.1. DTLS-SRTP Recap
DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers
 End of changes. 30 change blocks. 
78 lines changed or deleted 85 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/