draft-ietf-perc-srtp-ekt-diet-08.txt   draft-ietf-perc-srtp-ekt-diet-09.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: January 16, 2019 Ericsson AB Expires: April 20, 2019 Ericsson AB
D. McGrew D. McGrew
Cisco Systems
D. Wing D. Wing
F. Andreason F. Andreason
Cisco Systems Cisco Systems
July 15, 2018 October 17, 2018
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-08 draft-ietf-perc-srtp-ekt-diet-09
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.
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 http://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 January 16, 2019. This Internet-Draft will expire on April 20, 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Timing and Reliability Consideration . . . . . . . . . . 13 4.7. Timing and Reliability Consideration . . . . . . . . . . 13
5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 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 EKTCipher . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 20
7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 20
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
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) is designed to allow decentralized Real-time Transport Protocol (RTP) is designed to allow decentralized
groups with minimal control to establish sessions, such as for groups with minimal control to establish sessions, such as for
multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711])
cannot be used in many minimal-control scenarios, because it requires cannot be used in many minimal-control scenarios, because it requires
that synchronization source (SSRC) values and other data be that synchronization source (SSRC) values and other data be
coordinated among all of the participants in a session. For example, coordinated among all of the participants in a session. For example,
skipping to change at page 4, line 23 skipping to change at page 4, line 29
endpoint. This specification also defines a way to send the endpoint. This specification also defines a way to send the
encrypted SRTP master key (with the EKTKey) along with the SRTP encrypted SRTP master key (with the EKTKey) along with the SRTP
packet, see Section 4. Endpoints that receive this and know the packet, see Section 4. Endpoints that receive this and know the
EKTKey can use the EKTKey to decrypt the SRTP master key which can EKTKey can use the EKTKey to decrypt the SRTP master key which can
then be used to decrypt the SRTP packet. then be used to decrypt the SRTP packet.
One way to use this is described in the architecture defined by One way to use this is described in the architecture defined by
[I-D.ietf-perc-private-media-framework]. Each participant in the [I-D.ietf-perc-private-media-framework]. Each participant in the
conference forms a DTLS-SRTP connection to a common key distributor conference forms a DTLS-SRTP connection to a common key distributor
that distributes the same EKTKey to all the endpoints. Then each that distributes the same EKTKey to all the endpoints. Then each
endpoint picks their own SRTP master key for the media they send. endpoint picks its own SRTP master key for the media they send. When
When sending media, the endpoint also includes the SRTP master key sending media, the endpoint also includes the SRTP master key
encrypted with the EKTKey in the SRTP packet. This allows all the encrypted with the EKTKey in the SRTP packet. This allows all the
endpoints to decrypt 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Encrypted Key Transport 4. Encrypted Key Transport
EKT defines a new method of providing SRTP master keys to an EKT defines a new method of providing SRTP master keys to an
endpoint. In order to convey the ciphertext corresponding to the endpoint. In order to convey the ciphertext corresponding to the
SRTP master key, and other additional information, an additional SRTP master key, and other additional information, an additional
field, called EKTField, is added to the SRTP packets. The EKTField field, called EKTField, is added to the SRTP packets. The EKTField
appears at the end of the SRTP packet. It 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 EKTField 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. EKTField Formats 4.1. EKTField Formats
The EKTField uses the format defined below for the FullEKTField and The EKTField uses the format defined in Figure 1 for the FullEKTField
ShortEKTField. and 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 8 skipping to change at page 9, line 8
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 SRTP The computed value of the FullEKTField is written into the SRTP
packet. packet.
When a packet is sent with the ShortEKTField, the ShortEKFField is When a packet is sent with the ShortEKTField, the ShortEKFField is
simply appended to the packet. simply appended to the packet.
Outbound packets SHOULD continue to use the old SRTP Master Key for
250 ms after 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.
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 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 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
skipping to change at page 9, line 34 skipping to change at page 9, line 39
at the end of the packet and thus the type is placed at the very at the end of the 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 authentication is checked and is decrypted, as 3. The EKTCiphertext is authenticated and decrypted, as described in
described in Section 4.4, using the EKTKey and EKTCipher found in Section 4.4, using the EKTKey and EKTCipher found in the previous
the previous step. If the EKT decryption operation returns an step. If the EKT decryption operation returns an authentication
authentication failure, then the packet processing stops. failure, then EKT processing MUST be aborted. The receiver
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 all the information from this
EKTPlaintext MUST be discarded and the following steps in this EKTPlaintext MUST be discarded and the following steps in this
list are skipped. 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
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. If the SRTP Master Key the inbound packets with that SSRC.
recovered from the EKTPlaintext is longer than needed by SRTP
transform in use, the first bytes are used. If the SRTP Master * Unless the transform specifies other acceptable key lengths,
Key recovered from the EKTPlaintext is shorter than needed by the length of the SRTP Master Key MUST be the same as the
SRTP transform in use, then the bytes received replace the first master key length for the SRTP transform in use. If this is
bytes in the existing key but the other bytes after that remain not the case, then the receiver MUST abort EKT processing and
the same as the old key. This applies in transforms such as SHOULD discared the whole UDP packet.
[I-D.ietf-perc-double] for replacing just half the key, but
SHOULD return a processing error otherwise. Outbound packets * If the length of the SRTP Master Key is less than the master
SHOULD continue to use the old SRTP Master Key for 250 ms after key length for the SRTP transform in use, and the transform
sending any new key. This gives all the receivers in the system specifies that this length is acceptable, then the SRTP Master
time to get the new key before they start receiving media Key value is used to replace the first bytes in the existing
encrypted with the new key. master key. The other bytes remain the same as in the old
key. For example, the Double GCM transform
[I-D.ietf-perc-double] allows replacement of the first, "end
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 including replay normal SRTP or SRTCP processing takes place.
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. SRTP senders and receivers MAY cache an
receiver to minimize computational effort by noting when the SRTP EKTCiphertext value to optimize processing in cases where the master
master key is unchanged and avoiding repeating the steps defined in . key hasn't changed. Instead of encrypting and decrypting, senders
can simply copy the pre-computed value and receivers can compare a
received EKTCiphertext to the known value.
The receiver may want to have a sliding window to retain old SRTP Section 4.2.1 recommends that SRTP senders continue using an old key
Master Keys (and related context) for some brief period of time, so for some time after sending a new key in an EKT tag. Receivers that
that out of order packets can be processed as well as packets sent wish to avoid packet loss due to decryption failures MAY perform
during the time keys are changing. trial decryption with both the old key and the new key, keeping the
result of whichever decryption succeeds. Note that this approach is
only compatible with SRTP transforms that include integrity
protection.
When receiving a new EKTKey, implementations need to use the ekt_ttl 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 field (see Section 5.2.2) to create a time after which this key
need to create a counter that keeps track of how many times the key cannot be used and they also need to create a counter that keeps
has been used to encrypt data to ensure it does not exceed the T track of how many times the key has been used to encrypt data to
value for that cipher (see ). If either of these limits are ensure it does not exceed the T value for that cipher (see ). If
exceeded, the key can no longer be used for encryption. At this either of these limits are exceeded, the key can no longer be used
point implementation need to either use the call signaling to for encryption. At this point implementation need to either use the
renegotiate a new session or need to terminate the existing session. call signaling to renegotiate a new session or need to terminate the
Terminating the session is a reasonable implementation choice because existing session. Terminating the session is a reasonable
these limits should not be exceeded except under an attack or error implementation choice because these limits should not be exceeded
condition. except under an attack or error condition.
4.4. Ciphers 4.4. Ciphers
EKT uses an authenticated cipher to encrypt and authenticate the EKT uses an authenticated cipher to encrypt and authenticate the
EKTPlaintext. This specification defines the interface to the EKTPlaintext. This specification defines the interface to the
cipher, in order to abstract the interface away from the details of cipher, in order to abstract the interface away from the details of
that function. This specification also defines the default cipher that function. This specification also defines the default cipher
that is used in EKT. The default cipher described in Section 4.4.1 that is used in EKT. The default cipher described in Section 4.4.1
MUST be implemented, but another cipher that conforms to this MUST be implemented, but another cipher that conforms to this
interface MAY be used. interface MAY be used.
skipping to change at page 12, line 44 skipping to change at page 13, line 7
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. 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 This document defines the use of EKT with SRTP. Its use with SRTCP
to use it over SRTCP. SRTP is preferred because it shares fate with would be similar, but is reserved for a future specification. SRTP
the transmitted media, because SRTP rekeying can occur without is preferred for transmitting key material because it shares fate
concern for RTCP transmission limits, and to avoid SRTCP compound with the transmitted media, because SRTP rekeying can occur without
packets with RTP translators and mixers. concern for RTCP transmission limits, and because it avoids the need
for SRTCP compound 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 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
packet contains a FullEKTField. packet contains a FullEKTField.
This section describes how to reliably and expediently deliver new This section describes how to reliably and expediently deliver new
SRTP master keys to receivers. SRTP master keys to receivers.
There are three cases to consider. The first case is a new sender There are three cases to consider. 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 RECOMMENDED that three consecutive packets contain the
FullEKTField be transmitted. FullEKTField be transmitted. If the sender does not send a
FullEKTField in its initial packets and receivers have not
otherwise been provisioned with a decryption key, then decryption
will fail and SRTP packets will be dropped until the the receives
a 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
skipping to change at page 14, line 37 skipping to change at page 14, line 46
for DTLS. for DTLS.
5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
This document defines a new TLS negotiated extension This document defines a new TLS negotiated extension
supported_ekt_ciphers and a new TLS handshake message type ekt_key. supported_ekt_ciphers and a new TLS handshake message type ekt_key.
The extension negotiates the cipher to be used in encrypting and The extension negotiates the cipher to be used in encrypting and
decrypting EKTCiphertext values, and the handshake message carries decrypting EKTCiphertext values, and the handshake message carries
the corresponding key. the corresponding key.
The diagram below shows a message flow of DTLS 1.3 client and server Figure 4 shows a message flow of DTLS 1.3 client and server using EKT
using EKT configured using the DTLS extensions described in this configured using the DTLS extensions described in this section. (The
section. (The initial cookie exchange and other normal DTLS messages initial cookie exchange and other normal DTLS messages are omitted.)
are omitted.)
Client Server Client Server
ClientHello ClientHello
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
+ use_srtp + use_srtp
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 allows the DTLS server to set a extensions defined in this document allow the DTLS server to set a
common EKTKey for all participants. Each endpoint can then use EKT common EKTKey for all participants. Each endpoint can then use EKT
tags encrypted with that common key to inform other endpoint of the tags encrypted with that common key to inform other endpoint of the
keys it uses to protect SRTP packets. This avoids the need for many keys it uses to protect SRTP packets. This avoids the need for many
individual DTLS handshakes among the endpoints, at the cost of individual DTLS handshakes among the endpoints, at the cost of
preventing endpoints from directly authenticating one another. preventing endpoints from directly authenticating one another.
Client A Server Client B Client A Server Client B
<----DTLS Handshake----> <----DTLS Handshake---->
<--------EKTKey--------- <--------EKTKey---------
skipping to change at page 17, line 41 skipping to change at page 17, line 41
The maximum amount of time, in seconds, that this EKTKey can be The maximum amount of time, in seconds, that this EKTKey can be
used. The ekt_key_value in this message MUST NOT be used for used. The ekt_key_value in this message MUST NOT be used for
encrypting or decrypting information after the TTL expires. encrypting or decrypting information after the TTL expires.
If the server did not provide a supported_ekt_ciphers extension in If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by the client its ServerHello, then EKTKey messages MUST NOT be sent by the 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.
If an EKTKey message is received that cannot be processed, then the If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert. recipient MUST respond with an appropriate DTLS alert.
5.3. Offer/Answer Considerations 5.3. Offer/Answer Considerations
skipping to change at page 18, line 19 skipping to change at page 18, line 19
Answer messaging. Answer messaging.
5.4. Sending the DTLS EKTKey Reliably 5.4. Sending the DTLS EKTKey Reliably
The DTLS EKTKey message is sent using the retransmissions specified The DTLS EKTKey message is sent using the retransmissions specified
in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished
with an Ack message or an alert is received. with an Ack message or an alert is received.
6. Security Considerations 6. Security Considerations
EKT inherits the security properties of the DTLS-SRTP (or other) EKT inherits the security properties of the the key management
keying it uses. protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP
extension defined in this document.
With EKT, each SRTP sender and receiver MUST generate distinct SRTP With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concern over the re- master keys. This property avoids any security concern over the re-
use of keys, by empowering the SRTP layer to create keys on demand. use of keys, by empowering the SRTP layer to create keys on demand.
Note that the inputs of EKT are the same as for SRTP with key- Note that the inputs of EKT are the same as for SRTP with key-
sharing: a single key is provided to protect an entire SRTP session. sharing: a single key is provided to protect an entire SRTP session.
However, EKT remains secure even when SSRC values collide. However, EKT remains secure even when SSRC values collide.
SRTP master keys MUST be randomly generated, and [RFC4086] offers SRTP master keys MUST be randomly generated, and [RFC4086] offers
some guidance about random number generation. SRTP master keys MUST some guidance about random number generation. SRTP master keys MUST
skipping to change at page 19, line 9 skipping to change at page 19, line 9
the packet. The FullEKTField would correctly decode and pass the packet. The FullEKTField would correctly decode and pass
integrity checks. However, the key extracted from the FullEKTField , integrity checks. However, the key extracted from the FullEKTField ,
when used to decrypt the SRTP payload, would be wrong and the SRTP when used to decrypt the SRTP payload, would be wrong and the SRTP
integrity check would fail. Note that the FullEKTField only changes integrity check would fail. Note that the FullEKTField only changes
the decryption key and does not change the encryption key. None of the decryption key and does not change the encryption key. None of
these are considered significant attacks as any attacker that can these are considered significant attacks as any attacker that can
modify the 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 FullEKTField, in an An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system attempt to consume additional CPU resources of the receiving system
by causing the receiving system will decrypt the EKT ciphertext and by causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure. In some cases, caching the detect an authentication failure. In some cases, caching the
previous values of the Ciphertext as described in Section 4.3 helps previous values of the Ciphertext as described in Section 4.3 helps
mitigate this issue. mitigate this issue.
In a similar vein, EKT has no replay protection, so an attacker could
implant improper keys in receivers by capturing EKTCiphertext values
encrypted with a given EKTKey and replaying them in a different
context, e.g., from a different sender. When the underlying SRTP
transform provides integrity protection, this attack will just result
in packet loss. If it does not, then it will result in random data
being fed to RTP payload processing. An attacker that is in a
position to mount these attacks, however, could achieve the same
effects more easily without attacking EKT.
Each EKT cipher specifies a value T that is the maximum number of Each EKT cipher specifies a value T that is the maximum number of
times a given key can be used. An endpoint MUST NOT encrypt more times a given key can be used. An endpoint MUST NOT encrypt more
than T different FullEKTField values using the same EKTKey. In than T different FullEKTField values using the same EKTKey. In
addition, the EKTKey MUST NOT be used beyond the lifetime provided by addition, the EKTKey MUST NOT be used beyond the lifetime provided by
the TTL described in Figure 4. the TTL described in Section 5.2.
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.
An EKT cipher MUST resist attacks in which both ciphertexts and An EKT cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen and adversaries that can query plaintexts can be adaptively chosen and adversaries that can query
both the encryption and decryption functions adaptively. both the encryption and decryption functions adaptively.
In some systems, when a member of a conference leaves the In some systems, when a member of a conference leaves the
conferences, the conferences is rekeyed so that member no longer has conferences, the conferences is rekeyed so that member no longer has
the key. When changing to a new EKTKey, it is possible that the the key. When changing to a new EKTKey, it is possible that the
attacker could block the EKTKey message getting to a particular attacker could block the EKTKey message getting to a particular
endpoint and that endpoint would keep sending media encrypted using endpoint and that endpoint would keep sending media encrypted using
the old key. To mitigate that risk, the lifetime of the EKTKey the old key. To mitigate that risk, the lifetime of the EKTKey MUST
SHOULD be limited using the ekt_ttl. be limited using the ekt_ttl.
7. IANA Considerations 7. IANA Considerations
7.1. EKT Message Types 7.1. EKT Message Types
IANA is requested to create a new table for "EKT Messages Types" in IANA is requested to create a new table for "EKT Messages Types" in
the "Real-Time Transport Protocol (RTP) Parameters" registry. The the "Real-Time Transport Protocol (RTP) Parameters" registry. The
initial values in this registry are: initial values in this registry are:
+--------------+-------+---------------+ +--------------+-------+---------------+
skipping to change at page 21, line 16 skipping to change at page 21, line 32
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 "TLS 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
of [RFC4366] and requires "IETF Consensus".
7.4. TLS Handshake Type 7.4. TLS Handshake Type
IANA is requested to add ekt_key as a new entry in the "TLS IANA is requested to add ekt_key as a new entry in the "TLS
HandshakeType Registry" table of the "Transport Layer Security (TLS) HandshakeType Registry" table of the "Transport Layer Security (TLS)
Parameters" registry with a reference to this specification, a DTLS- Parameters" registry with a reference to this specification, a DTLS-
OK value of "Y", and allocate a value of TBD to for this content OK value of "Y", and allocate a value of TBD to for this content
type. type.
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
This registry was defined in Section 12 of [RFC5246] and requires
"Standards Action".
8. Acknowledgements 8. Acknowledgements
Thank you to Russ Housley provided detailed review and significant Thank you to Russ Housley provided detailed review and significant
help with crafting text for this document. Thanks to David Benham, help with crafting text for this document. Thanks to David Benham,
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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC2119, March 1997,
rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, DOI with Session Description Protocol (SDP)", RFC 3264,
10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002,
editor.org/info/rfc3264>. <https://www.rfc-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, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC5234, January 2008,
rfc5234>. <https://www.rfc-editor.org/info/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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC5246, August 2008,
rfc5246>. <https://www.rfc-editor.org/info/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, DOI (AES) Key Wrap with Padding Algorithm", RFC 5649,
10.17487/RFC5649, September 2009, <https://www.rfc- DOI 10.17487/RFC5649, September 2009,
editor.org/info/rfc5649>. <https://www.rfc-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, DOI Real-time Transport Protocol (SRTP)", RFC 5764,
10.17487/RFC5764, May 2010, <https://www.rfc- DOI 10.17487/RFC5764, May 2010,
editor.org/info/rfc5764>. <https://www.rfc-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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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-09 Double Encryption Procedures", draft-ietf-perc-double-09
(work in progress), May 2018. (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-06 Conferencing", draft-ietf-perc-private-media-framework-07
(work in progress), March 2018. (work in progress), September 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-28 (work in progress), July 1.3", draft-ietf-tls-dtls13-28 (work in progress), July
2018. 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, <https://www.rfc- DOI 10.17487/RFC4086, June 2005,
editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Email: fluffy@iii.ca Email: fluffy@iii.ca
John Mattsson John Mattsson
Ericsson AB Ericsson AB
skipping to change at page 23, line 43 skipping to change at page 24, line 4
John Mattsson John Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
David A. McGrew David A. McGrew
Cisco Systems Cisco Systems
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
Dan Wing Dan Wing
Cisco Systems
Email: dwing@cisco.com Email: dwing-ietf@fuggles.com
Flemming Andreason Flemming Andreason
Cisco Systems Cisco Systems
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 48 change blocks. 
111 lines changed or deleted 135 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/