draft-ietf-avtcore-srtp-ekt-01.txt   draft-ietf-avtcore-srtp-ekt-02.txt 
AVTCORE Working Group D. McGrew AVTCORE Working Group D. McGrew
Internet-Draft F. Andreasen Internet-Draft D. Wing
Intended status: Standards Track D. Wing Intended status: Standards Track F. Andreasen
Expires: April 24, 2014 Cisco Expires: August 18, 2014 Cisco
October 21, 2013 February 14, 2014
Encrypted Key Transport for Secure RTP Encrypted Key Transport for Secure RTP
draft-ietf-avtcore-srtp-ekt-01 draft-ietf-avtcore-srtp-ekt-02
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to Secure Real-time Encrypted Key Transport (EKT) is an extension to Secure Real-time
Transport Protocol (SRTP) that provides for the secure transport of Transport Protocol (SRTP) that provides for the secure transport of
SRTP master keys, Rollover Counters, and other information, within SRTP master keys, Rollover Counters, and other information. This
SRTP or SRTCP. This facility enables SRTP to work for decentralized facility enables SRTP to work for decentralized conferences with
conferences with minimal control. minimal control.
This note defines EKT, and also describes how to use it with SDP This note defines EKT, and also describes how to use it with SDP
Security Descriptions, DTLS-SRTP, and MIKEY. These other key Security Descriptions, DTLS-SRTP, and MIKEY. With EKT, these other
management protocols provide an EKT key to everyone in a session, and key management protocols provide an EKT key to everyone in a session,
EKT coordinates the keys within the session. and EKT coordinates the SRTP keys within the session.
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 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 April 24, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions Used In This Document . . . . . . . . . . . . 5 1.2. Conventions Used In This Document . . . . . . . . . . . . 5
2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 5
2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 6 2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5
2.2. Packet Processing and State Machine . . . . . . . . . . . 8 2.2. Packet Processing and State Machine . . . . . . . . . . . 8
2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8
2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . . 10 2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9
2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 12 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . 12
2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 13 2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 12
2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13
2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Timing and Reliability Consideration . . . . . . . . . . . 14 2.6. Timing and Reliability Consideration . . . . . . . . . . 14
3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 16 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 15
3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 16 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 15
3.2. Relationship between EKT and SDP Security Descriptions . . 17 3.2. Relationship between EKT and SDP Security Descriptions . 16
3.3. Overview of Combined EKT and SDP Security Description 3.3. Overview of Combined EKT and SDP Security Description
Operation . . . . . . . . . . . . . . . . . . . . . . . . 19 Operation . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 19 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 18
3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 19 3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . 18
3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 20 3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 19
3.5.1. Generating the Initial Offer - Unicast Streams . . . . 21 3.5.1. Generating the Initial Offer - Unicast Streams . . . 19
3.5.2. Generating the Initial Answer - Unicast Streams . . . 22 3.5.2. Generating the Initial Answer - Unicast Streams . . . 20
3.5.3. Processing of the Initial Answer - Unicast Streams . . 23 3.5.3. Processing of the Initial Answer - Unicast Streams . 21
3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 24 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . 22
3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 24 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 23
3.8. Backwards Compatibility Considerations . . . . . . . . . . 25 3.8. Backwards Compatibility Considerations . . . . . . . . . 23
3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 27 4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 25
4.1. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 27 4.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Scaling to Large Groups . . . . . . . . . . . . . . . 29 4.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 25
4.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 30 4.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 27
4.2.1. Generating the Initial Offer . . . . . . . . . . . . . 30 4.3.1. Generating the Initial Offer . . . . . . . . . . . . 27
4.2.2. Generating the Initial Answer . . . . . . . . . . . . 31 4.3.2. Generating the Initial Answer . . . . . . . . . . . . 28
4.2.3. Processing the Initial Answer . . . . . . . . . . . . 31 4.3.3. Processing the Initial Answer . . . . . . . . . . . . 28
4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 32 4.3.4. Sending DTLS EKT Key Reliably . . . . . . . . . . . . 29
5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 33 4.3.5. Modifying the Session . . . . . . . . . . . . . . . . 29
5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 34 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 29
5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 36 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 31
5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 36 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 32
5.2.2. Generating the Initial Answer . . . . . . . . . . . . 37 5.2.1. Generating the Initial Offer . . . . . . . . . . . . 32
5.2.3. Processing the Initial Answer . . . . . . . . . . . . 37 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 33
5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 37 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 33
6. Using EKT for interoperability between key management 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 34
systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Using EKT for interoperability between key management systems 34
7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 40 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 41 7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 46 11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 47 11.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with
Security Descriptions . . . . . . . . . . . . . . . . 48 Security Descriptions . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
RTP is designed to allow decentralized groups with minimal control to RTP is designed to allow decentralized groups with minimal control to
establish sessions, such as for multimedia conferences. establish sessions, such as for multimedia conferences.
Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many
minimal-control scenarios, because it requires that SSRC values and minimal-control scenarios, because it requires that SSRC values and
other data be coordinated among all of the participants in a session. other data be coordinated among all of the participants in a session.
For example, if a participant joins a session that is already in For example, if a participant joins a session that is already in
progress, the SRTP rollover counter (ROC) of each SRTP source in the progress, that participant needs to be told the SRTP keys (and SSRC,
session needs to be provided to that participant. ROC and other details) of the other SRTP sources.
The inability of SRTP to work in the absence of central control was The inability of SRTP to work in the absence of central control was
well understood during the design of that protocol; that omission was well understood during the design of the protocol; the omission was
considered less important than optimizations such as bandwidth considered less important than optimizations such as bandwidth
conservation. Additionally, in many situations SRTP is used in conservation. Additionally, in many situations SRTP is used in
conjunction with a signaling system that can provide most of the conjunction with a signaling system that can provide most of the
central control needed by SRTP. However, there are several cases in central control needed by SRTP. However, there are several cases in
which conventional signaling systems cannot easily provide all of the which 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, an This document defines Encrypted Key Transport (EKT) for SRTP, an
extension to SRTP that fits within the SRTP framework and reduces the extension to SRTP that fits within the SRTP framework and reduces the
amount of signaling control that is needed in an SRTP session. EKT amount of external signaling control that is needed in an SRTP
securely distributes the SRTP master key and other information for session. EKT securely distributes the SRTP master key and other
each SRTP source, using SRTCP or SRTP to transport that information. information for each SRTP source (SSRC), using SRTCP or SRTP to
With this method, SRTP entities are free to choose SSRC values as transport that information. With this method, SRTP entities are free
they see fit, and to start up new SRTP sources with new SRTP master to choose SSRC values as they see fit, and to start up new SRTP
keys (see Section 2.2) within a session without coordinating with sources (SSRC) with new SRTP master keys (see Section 2.2) within a
other entities via signaling or other external means. This fact session without coordinating with other entities via external
allows to reinstate the RTP collision detection and repair mechanism, signaling or other external means. This fact allows to reinstate the
which is nullified by the current SRTP specification because of the RTP collision detection and repair mechanism, which is nullified by
need to control SSRC values closely. An SRTP endpoint using EKT can the current SRTP specification because of the need to control SSRC
generate new keys whenever an existing SRTP master key has been values closely. An SRTP endpoint using EKT can generate new keys
overused, or start up a new SRTP source to replace an old SRTP source whenever an existing SRTP master key has been overused, or start up a
that has reached the packet-count limit. EKT also solves the problem new SRTP source (SSRC) to replace an old SRTP source that has reached
in which the burst loss of the N initial SRTP packets can confuse an the packet-count limit. However, EKT does not allow SRTP's ROC to
SRTP receiver, when the initial RTP sequence number is greater than rollover; that requires re-keying outside of EKT (e.g., using MIKEY
or equal to 2^16 - N. These features can simplify many architectures or DTLS-SRTP). EKT also solves the problem in which the burst loss
that implement SRTP. of the N initial SRTP packets can confuse an SRTP receiver, when the
initial RTP sequence number is greater than or equal to 2^16 - N.
These features can simplify many architectures that implement SRTP.
EKT provides a way for an SRTP session participant, either a sender EKT provides a way for an SRTP session participant, either a sender
or a receiver, to securely transport its SRTP master key and current or receiver, to securely transport its SRTP master key and current
SRTP rollover counter to the other participants in the session. This SRTP rollover counter to the other participants in the session. This
data, possibly in conjunction with additional data provided by an data, possibly in conjunction with additional data provided by an
external signaling protocol, furnishes the information needed by the external signaling protocol, furnishes the information needed by the
receiver to instantiate an SRTP/SRTCP receiver context. receiver to instantiate an SRTP/SRTCP receiver context.
EKT does not control the manner in which the SSRC and master key are EKT does not control the manner in which the SSRC is generated; it is
generated; it is only concerned with their secure transport. Those only concerned with their secure transport. Those values may be
values may be generated on demand by the SRTP endpoint, or may be generated on demand by the SRTP endpoint, or may be dictated by an
dictated by an external mechanism such as a signaling agent or a external mechanism such as a signaling agent or a secure group
secure group controller. controller.
EKT is not intended to replace external key establishment mechanisms EKT is not intended to replace external key establishment mechanisms
such as SDP Security Descriptions [RFC4568], DTLS-SRTP [RFC5764], or such as SDP Security Descriptions [RFC4568], DTLS-SRTP [RFC5764], or
MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with
those methods, and it relieves them of the burden of tightly those methods, and it relieves them of the burden of tightly
coordinating every SRTP source among every SRTP participant. coordinating every SRTP source (SSRC) among every SRTP participant.
This document is organized as follows. The complete normative
definition of EKT is contained in Section 2. It mainly consists of
packet processing algorithms (Section 2.2) and cryptographic
definitions (Section 2.3) . Section 3, Section 4, and Section 5
define the use of EKT with SDP Security Descriptions, DTLS-SRTP, and
MIKEY, respectively. Section 7 provides a design rationale.
Section 6 explains how EKT can interwork with keying in call
signaling. Security Considerations are discussed in Section 8, and
IANA considerations are provided in Section 9.
1.1. History 1.1. History
RFC Editor Note: please remove this section prior to publication as [[RFC Editor Note: please remove this section prior to publication as
an RFC. an RFC.]]
This version is substantially revised from earlier versions, in order A substantial change occurred between the EKT documents draft-ietf-
to make it possible for the EKT data to be removed from a packet avt-srtp-ekt-03 and draft-ietf-avtcore-srtp-ekt-00. The change makes
without affecting the ability of the receiver to correctly process it possible for the EKT data to be removed from a packet without
the data that is present in that packet. This capability facilitates affecting the ability of the receiver to correctly process the data
that is present in that packet. This capability facilitates
interoperability between SRTP implementations with different SRTP key interoperability between SRTP implementations with different SRTP key
management methods. The changes also greatly simplify the EKT management methods. The changes also greatly simplify the EKT
processing rules, and make the EKT data that must be carried in SRTP processing rules, and makes the EKT data that must be carried in SRTP
and/or SRTCP packets somewhat larger. and/or SRTCP packets somewhat larger.
In draft-ietf-avtcore-srtp-ekt-02 (this document), SRTP master keys
have to be always generated randomly and never shared, MKI is no
longer allowed with EKT (as MKI duplicates some of EKT's functions),
and text clarifies that EKT must be negotiated during call setup.
Some text was consolidated and re-written, notably Section 2.6
("Timing and Reliability").
1.2. Conventions Used In This Document 1.2. 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].
2. Encrypted Key Transport 2. Encrypted Key Transport
In EKT, an SRTP master key is encrypted with a key encrypting key and In EKT, an SRTP master key is encrypted with a key encrypting key and
the resulting ciphertext is transported in selected SRTCP or in the resulting ciphertext is transported in selected SRTCP packets or
selected SRTP packets. The key encrypting key is called an EKT key. in selected SRTP packets. The key encrypting key is called an EKT
A single such key suffices for a single SRTP session, regardless of key. A single such key suffices for a single SRTP session,
the number of participants in that session. However, there can be regardless of the number of participants in that session. However,
multiple EKT keys used within a particular session. there can be multiple EKT keys used within a particular session.
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 of the SRTP master key, endpoint. In order to convey the ciphertext of the SRTP master key,
and other additional information, an additional EKT field is added to and other additional information, an additional EKT field is added to
SRTP or SRTCP packets. When added to SRTCP, the EKT field appears at SRTP or SRTCP packets. When added to SRTCP, the EKT field appears at
the end of the packet, after the authentication tag, if that tag is the end of the packet, after the authentication tag, if that tag is
present, or after the MKI or the SRTCP index otherwise. When added present, or after the SRTCP index otherwise. When added to SRTP, The
to SRTP, the EKT field appears at the end of the packet, after the EKT field appears at the end of the SRTP packet, after the
authentication tag, if that tag is present, or after the MKI or the authentication tag (if that tag is present), or after the ciphertext
ciphertext of the encrypted portion of the packet otherwise. of the encrypted portion of the packet otherwise.
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
features duplicate some of the functions of EKT.
2.1. EKT Field Formats 2.1. EKT Field Formats
The EKT Field uses one of the two formats defined below. These two The EKT Field uses one of the two formats defined below. These two
formats can always be unambiguously distinguished on receipt by formats can always be unambiguously distinguished on receipt by
examining the final bit of the EKT Field, which is also the final bit examining the final bit of the EKT Field, which is also the final bit
of the SRTP or SRTCP packet. The first format is the Full EKT Field of the SRTP or SRTCP packet. The first format is the Full EKT Field
(or Full_EKT_Field), and the second is the Short EKT Field (or (or Full_EKT_Field), and the second is the Short EKT Field (or
Short_EKT_Field). The formats are defined as Short_EKT_Field). The formats are defined as
EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || ISN
EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || ISN EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext)
EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext)
Full_EKT_Field = EKT_Ciphertext || SPI || '1' Full_EKT_Field = EKT_Ciphertext || SPI || '1'
Short_EKT_Field = Reserved || '0' Short_EKT_Field = Reserved || '0'
Figure 1: EKT data formats Figure 1: EKT data formats
Here || denotes concatenation, and '1' and '0' denote single one and Here || denotes concatenation, and '1' and '0' denote single one and
zero bits, respectively. These fields and data elements are defined zero bits, respectively. These fields and data elements are defined
as follows: as follows:
EKT_Plaintext: The data that is input to the EKT encryption EKT_Plaintext: The data that is input to the EKT encryption
operation. This data never appears on the wire, and is used only operation. This data never appears on the wire, and is used only
in computations internal to EKT. in computations internal to EKT.
EKT_Ciphertext: The data that is output from the EKT encryption EKT_Ciphertext: The data that is output from the EKT encryption
operation, which is performed as as defined in Section 2.3. This operation, described in Section 2.3. This field is included in
field is included in SRTP and SRTCP packets when EKT is in use. SRTP and SRTCP packets when EKT is in use. The length of this
The length of this field is variable, and is equal to the field is variable, and is equal to the ciphertext size N defined
ciphertext size N defined in Section 2.3. Note that the length of in Section 2.3. Note that the length of the field is inferable
the field is inferable from the SPI field, since the particular from the SPI field, since the particular EKT cipher used by the
EKT cipher used by the sender of a packet can be inferred from sender of a packet can be inferred from that field.
that field.
Rollover Counter (ROC): The length of this field is fixed at 32 SRTP_Master_Key: On the sender side, the SRTP Master Key associated
bits. It is included in the EKT plaintext, but does not appear on with the indicated SSRC. The length of this field depends on the
the wire. On the sender side, this field is set to the current cipher suite negotiated during call setup for SRTP or SRTCP.
value of the SRTP rollover counter in the SRTP context associated
with the SSRC in the SRTP or SRTCP packet.
Initial Sequence Number (ISN): The length of this field is fixed at SSRC: On the sender side, this field is the SSRC for this SRTP
16 bits. It is included the EKT plaintext, but does not appear on source. The length of this field is fixed at 32 bits.
the wire. If this field is nonzero, then it indicates the RTP
sequence number of the initial RTP packet that is protected using
the SRTP master key conveyed (in encrypted form) by the EKT
Ciphertext field of this packet. If this field is zero, it
indicates that the initial RTP packet protected using the SRTP
master key conveyed in this packet preceded, or was concurrent
with, the last roll-over of the RTP sequence number.
Security Parameter Index (SPI): The length of this field is fixed at Rollover Counter (ROC): On the sender side, this field is set to the
15 bits. This field is included in SRTP and SRTCP packets when current value of the SRTP rollover counter in the SRTP context
EKT is in use. It indicates the appropriate EKT key and other associated with the SSRC in the SRTP or SRTCP packet. The length
parameters for the receiver to use when processing the packet. It of this field is fixed at 32 bits.
is an "index" into a table of possibilities (which are established
via signaling or some other out-of-band means), much like the Initial Sequence Number (ISN): If this field is nonzero, it
IPsec Security Parameter Index [RFC4301]. The parameters that are indicates the RTP sequence number of the initial RTP packet that
identified by this field are: is protected using the SRTP master key conveyed (in encrypted
form) by the EKT Ciphertext field of this packet. When this field
is present in an RTCP packet it indicates the RTP sequence number
of the first RTP packet encrypted by this master key. If the ISN
field is zero, it indicates that the initial RTP/RTCP packet
protected using the SRTP master key conveyed in this packet
preceded, or was concurrent with, the last roll-over of the RTP
sequence number, and thus should be used as the current master key
for processing this packet. The length of this field is fixed at
16 bits.
Security Parameter Index (SPI): This field is included in SRTP and
SRTCP packets when EKT is in use. It indicates the appropriate
EKT key and other parameters for the receiver to use when
processing the packet. It is an "index" into a table of
possibilities (which are established via signaling or some other
out-of-band means), much like the IPsec Security Parameter Index
[RFC4301]. The length of this field is fixed at 15 bits. The
parameters identified by this field are:
* The EKT key used to process the packet. * The EKT key used to process the packet.
* The EKT cipher used to process the packet. * The EKT cipher used to process the packet.
* The Secure RTP parameters associated with the SRTP Master Key * The Secure RTP parameters associated with the SRTP Master Key
carried by the packet and the SSRC value in the packet. carried by the packet and the SSRC value in the packet.
Section 8.2. of [RFC3711] summarizes the parameters defined by Section 8.2. of [RFC3711] summarizes the parameters defined by
that specification. that specification.
* The Master Salt associated with the Master Key. (This value is * The Master Salt associated with the Master Key. (This value is
part of the parameters mentioned above, but we call it out for part of the parameters mentioned above, but we call it out for
emphasis.) The Master Salt is communicated separately, via emphasis.) The Master Salt is communicated separately, via
signaling, typically along with the EKT key. signaling, typically along with the EKT key.
Together, these data elements assoicated with an instance of EKT Together, these data elements are called an EKT parameter set.
are called an EKT parameter set. Within each SRTP session, each Within each SRTP session, each distinct EKT parameter set that may
distinct EKT parameter set that may be used MUST be associated be used MUST be associated with a distinct SPI value, to avoid
with a distinct SPI value, to avoid ambiguity. ambiguity.
Reserved: MUST be all zeros on transmission, and MUST be ignored on Reserved: The length of this field is 7 bits. MUST be all zeros on
reception. transmission, and MUST be ignored on reception.
Examples of the Full_EKT_Field and Short_EKT_Field formats are shown The Full_EKT_Field and Short_EKT_Field formats are shown in Figure 2
in (Figure 2) and (Figure 3), respectively. These figures show the and Figure 3, respectively. These figures show the on-the-wire data.
on-the-wire data. The Ciphertext field holds encrypted data, and The Ciphertext field holds encrypted data, and thus has no apparent
thus has no apparent inner structure. inner structure.
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 |1| | Security Parameter Index |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Full EKT Field format
Figure 2: An example of the Full EKT Field format 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+
0 1 2 3 | Reserved |0|
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 +-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Reserved |0|
+-+-+-+-+-+-+-+-+
Figure 3: An example of the Short EKT Field format Figure 3: Short EKT Field format
2.2. Packet Processing and State Machine 2.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 (SSRC) has associated with
single EKT parameter set. This parameter set is used to process all it a single EKT parameter set. This parameter set is used to process
outbound packets, and is called the outbound parameter set. There all outbound packets, and is called the outbound parameter set.
may be other EKT parameter sets that are used by other SRTP/SRTCP There may be other EKT parameter sets that are used by other SRTP/
sources in the same session. All of these EKT parameter sets SHOULD SRTCP sources in the same session, including other SRTP/SRTCP sources
be stored by all of the participants in an SRTP session, for use in on the same endpoint (e.g., one endpoint with voice and video might
processing inbound SRTCP traffic. have two EKT parameter sets, or there might be multiple video sources
on an endpoint each with their own EKT parameter set). All of these
EKT parameter sets SHOULD be stored by all of the participants in an
SRTP session, for use in processing inbound SRTP and SRTCP traffic.
All SRTP master keys MUST NOT be re-used, MUST be randomly generated
according to [RFC4086], MUST NOT be equal to or derived from other
SRTP master keys.
2.2.1. Outbound Processing 2.2.1. Outbound Processing
See Section 2.6 which describes when to send an EKT packet and
describes if a Full EKT Field or Short EKT Field is sent.
When an SRTP or SRTCP packet is to be sent, the EKT field for that When an SRTP or SRTCP packet is to be sent, the EKT field for that
packet is created as follows, or uses an equivalent set of steps. packet is created as follows, or uses an equivalent set of steps.
The creation of the EKT field MUST precede the normal SRTP or SRTCP The creation of the EKT field MUST precede the normal SRTP or SRTCP
packet processing, so that the ROC used in EKT is the same as the one packet processing. The ROC used in EKT processing MUST be the same
used in the SRTP or SRTCP processing. as the one used in the SRTP processing.
First, the sender decides whether to use the Full or Short format.
When sending EKT with SRTP, the Full format SHOULD be used on the
initial SRTP packet in a session and after each rekeying event. When
sending EKT with SRTCP, the Full format MUST be used. Not all SRTP
or SRTCP packets need to include the EKT key, but it SHOULD be
included with some regularity, e.g., every second or every ten
seconds, though it need not be sent on a regular schedule.
If the Short format is used, an all-zero Reserved octet is appended If the Short format is used, an all-zero octet is appended to the
to the packet. Otherwise, processing continues as follows. packet. Otherwise, processing continues as follows.
The Rollover Counter field in the packet is set to the current value The Rollover Counter field in the packet is set to the current value
of the SRTP rollover counter (represented as an unsigned integer in of the SRTP rollover counter (represented as an unsigned integer in
network byte order). network byte order).
The Initial Sequence Number field is set to zero, if the initial RTP The Initial Sequence Number field is set to zero, if the initial RTP
packet protected using the current SRTP master key for this source packet protected using the current SRTP master key for this source
preceded, or was concurrent with, the last roll-over of the RTP preceded, or was concurrent with, the last roll-over of the RTP
sequence number. Otherwise, that field is set to the value of the sequence number. Otherwise, that field is set to the value of the
RTP sequence number of the initial RTP packet that was or will be RTP sequence number of the initial RTP packet that was or will be
protected by that key. When the SRTP master key corresponding to a protected by that key. See "rekey" in Section 2.6. The rekeying
source is changed, the new key SHOULD be communicated in advance via event MUST NOT change the value of ROC (otherwise, the current value
EKT. (Note that the ISN field allows the receiver to know when it of the ROC would not be known to late joiners of existing sessions).
should start using the new key to process SRTP packets.) This This means rekeying near the end of sequence number space (e.g., 100
enables the rekeying event to be communicated before any RTP packets packets before sequence number 65535) is not possible because ROC
are protected with the new key. The rekeying event MUST NOT change needs to roll over.
the value of ROC (otherwise, the current value of the ROC would not
be known to late joiners of existing sessions).
The Security Parameter Index field is set to the value of the The Security Parameter Index field is set to the value of the
Security Parameter Index that is associated with the outbound Security Parameter Index that is associated with the outbound
parameter set. parameter set.
The EKT_Plaintext field is computed from the SRTP Master Key, SSRC, The EKT_Plaintext field is computed from the SRTP Master Key, SSRC,
ROC, and ISN fields, as shown in Figure 1. ROC, and ISN fields, as shown in Figure 1.
The EKT_Ciphertext field is set to the ciphertext created by The EKT_Ciphertext field is set to the ciphertext created by
encrypting the EKT_Plaintext with the EKT cipher, using the KEK as encrypting the EKT_Plaintext with the EKT cipher, using the EKT Key
the encryption key. The encryption process is detailed in as the encryption key. The encryption process is detailed in
Section 2.3. Implementations MAY cache the value of this field to Section 2.3. Implementations MAY cache the value of this field to
avoid recomputing it for each packet that is sent. avoid recomputing it for each packet that is sent.
Implementation note: Because of the format of the Full EKT Field, a
packet containing the Full EKT Field MUST be sent when the ROC
changes (i.e., every 2^32 packets).
2.2.2. Inbound Processing 2.2.2. Inbound Processing
When an SRTP or SRTCP packet containing and EKT field is received, it When an SRTP or SRTCP packet containing a Full EKT Field or Short EKT
is processed as follows, or uses an equivalent set of steps. Inbound Field is received, it is processed as follows or using an equivalent
EKT processing MUST take place prior to the usual SRTP or SRTCP set of steps. Inbound EKT processing MUST take place prior to the
processing. usual SRTP or SRTCP processing. Implementation note: the receiver
may want to have a sliding window to retain old master keys for some
brief period of time, so that out of order packets can be processed.
The following steps show processing as packets are received in order.
1. The final bit is checked to determine which EKT format is in use. 1. The final bit is checked to determine which EKT format is in use.
If the packet contains a Short EKT Tag, then the EKT Tag is If the packet contains a Short EKT Field then the Short EKT Field
stripped off of the packet, and then the normal SRTP or SRTCP is removed and normal SRTP or SRTCP processing is applied. If
processing is applied. If the packet contains a Full EKT Tag, the packet contains a Full EKT Field, then processing continues
then processing continues as described below. as described below.
2. The Security Parameter Index (SPI) field is checked to determine 2. The Security Parameter Index (SPI) field is checked to determine
which EKT parameter set should be used when processing the which EKT parameter set should be used when processing the
packet. If multiple parameter sets have been defined for the packet. If multiple parameter sets have been defined for the
SRTP session, then the one that is associated with the value of SRTP session, then the one that is associated with the value of
the SPI field in the packet is used. This parameter set is the SPI field in the packet is used. This parameter set is
called the matching parameter set below. If there is no matching called the matching parameter set below. If there is no matching
SPI, then the verification function MUST return an indication of SPI, then the verification function MUST return an indication of
authentication failure, and the steps described below are not authentication failure, and the steps described below are not
performed. performed.
skipping to change at page 10, line 41 skipping to change at page 10, line 20
then the packet processing halts with an indication of failure. then the packet processing halts with an indication of failure.
Otherwise, the resulting EKT_Plaintext is parsed as described in Otherwise, the resulting EKT_Plaintext is parsed as described in
Figure 1, to recover the SRTP Master Key, SSRC, ROC, and ISN Figure 1, to recover the SRTP Master Key, SSRC, ROC, and ISN
fields. fields.
4. The SSRC field output from the decryption operation is compared 4. The SSRC field output from the decryption operation is compared
to the SSRC field from the SRTP header. If the values of the two to the SSRC field from the SRTP header. If the values of the two
fields do not match, then packet processing halts with an fields do not match, then packet processing halts with an
indication of failure. Otherwise, it continues as follows. indication of failure. Otherwise, it continues as follows.
5. If the ROC from the EKT_Plaintext is less than the ROC in the 5. If an SRTP context associated with the SSRC in the previous step
SRTP context, then packet processing halts. Otherwise, the ROC already exists and the ROC from the EKT_Plaintext is less than
in the SRTP context is set to the value of the ROC from the the ROC in the SRTP context, then EKT processing halts and the
EKT_Plaintext, and the SRTP Master Key from the EKT_Plaintext is packet is processed as an out-of-order packet (if within the
accepted as the SRTP master key corresponding to the SRTP source implementation's sliding window) or dropped (as it is a replay).
that sent the packet. If an MKI is present in the packet, then Otherwise, the ROC in the SRTP context is set to the value of the
the master key corresponds to the particular SSRC and MKI ROC from the EKT_Plaintext, and the SRTP Master Key from the
combination. If there is no SRTP crypto context corresponding to EKT_Plaintext is accepted as the SRTP master key corresponding to
the SSRC in the packet, then a new crypto context is created. If the SSRC indicated in the EKT_Plaintext, beginning at the
the crypto context is not new, then the rollover counter in the sequence number indicated by the ISN (see next step).
context MUST NOT be set to a value lower than its current value.
(If the replay protection step described above is performed, it
ensures that this requirement is satisfied.)
6. If the Initial Sequence Number field is nonzero, then the initial 6. If the ISN from the EKT_Plaintext is less than the RTP sequence
sequence number for the SRTP master key is set to the packet number of an authenticated received SRTP packet, then EKT
index created by appending that field to the current rollover processing halts (as this is a replay). If the Initial Sequence
counter and treating the result as a 48-bit unsigned integer. Number field is nonzero, then the initial sequence number for the
The initial sequence number for the master key is equivalent to SRTP master key is set to the packet index created by appending
the "From" value of the <From, To> pair of indices (Section 8.1.1 that field to the current rollover counter and treating the
of [RFC3711]) that can be associated with a master key. result as a 48-bit unsigned integer. The initial sequence number
for the master key is equivalent to the "From" value of the
<From, To> pair of indices (Section 8.1.1 of [RFC3711]) that can
be associated with a master key.
7. The newly accepted SRTP master key, the SRTP parameters from the 7. The newly accepted SRTP master key, the SRTP parameters from the
matching parameter set, the SSRC from the packet, and the MKI matching parameter set, and the SSRC from the packet are stored
from the packet, if one is present, are stored in the crypto in the crypto context associated with the SRTP source (SSRC).
context associated with the SRTP source. The SRTP Key Derivation The SRTP Key Derivation algorithm is run in order to compute the
algorithm is run in order to compute the SRTP encryption and SRTP encryption and authentication keys, and those keys are
authentication keys, and those keys are stored for use in SRTP stored for use in SRTP processing of inbound packets. The Key
processing of inbound packets. The Key Derivation algorithm Derivation algorithm takes as input the newly accepted SRTP
takes as input the newly accepted SRTP master key, along with the master key, along with the Master Salt from the matching
Master Salt from the matching parameter set. parameter set.
Implementation note: the receiver may want to retain old
master keys for some brief period of time, so that out of
order packets can be processed.
8. At this point, EKT processing has successfully completed, and the 8. At this point, EKT processing has successfully completed, and the
normal SRTP or SRTCP processing takes place. normal SRTP or SRTCP processing takes place.
Implementation note: the value of the EKT Ciphertext field is Implementation note: the value of the EKT Ciphertext field is
identical in successive packets protected by the same EKT identical in successive packets protected by the same EKT
parameter set and the same SRTP master key and ROC. This parameter set and the same SRTP master key, ROC, and ISN.
ciphertext value MAY be cached by an SRTP receiver to minimize This ciphertext value MAY be cached by an SRTP receiver to
computational effort by noting when the SRTP master key is minimize computational effort by noting when the SRTP master
unchanged and avoiding repeating Steps 2, 3, 4 5, and 6. key is unchanged and avoiding repeating Steps 2 through 6.
2.3. Ciphers 2.3. Ciphers
EKT uses an authenticated cipher to encrypt the SRTP master keys, EKT uses an authenticated cipher to encrypt the EKT Plaintext, which
ROC, and ISN. We first specify the interface to the cipher, in order is comprised of the SRTP master keys, SSRC, ROC, and ISN. We first
to abstract the interface away from the details of that function. We specify the interface to the cipher, in order to abstract the
then define the cipher that is used in EKT by default. This cipher interface away from the details of that function. We then define the
MUST be implemented, but another cipher that conforms to this cipher that is used in EKT by default. The default cipher described
interface MAY be used, in which case its use MUST be coordinated by in Section 2.3.1 MUST be implemented, but another cipher that
external means (e.g., call signaling). conforms to this interface MAY be used, in which case its use MUST be
coordinated by external means (e.g., key management).
The master salt length for the offered cipher suites MUST be the
same. In practice the easiest way to achieve this is by offering the
same crypto suite.
An EKT cipher consists of an encryption function and a decryption An EKT cipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following function. The encryption function E(K, P) takes the following
inputs: inputs:
o a secret key K with a length of L bytes, and o a secret key K with a length of L bytes, and
o a plaintext value P with a length of M bytes. o a plaintext value P with a length of M bytes.
The encryption function returns a ciphertext value C whose length is The encryption function returns a ciphertext value C whose length is
N bytes, where N is at least M. The decryption function D(K, C) takes N bytes, where N is at least M. The decryption function D(K, C)
the following inputs: takes the following inputs:
o a secret key K with a length of L bytes, and o a secret key K with a length of L bytes, and
o a ciphertext value C with a length of N bytes. o a ciphertext value C with a length of N bytes.
The decryption function returns a plaintext value P that is M bytes The decryption function returns a plaintext value P that is M bytes
long, or returns an indication that the decryption operation failed long, or returns an indication that the decryption operation failed
because the ciphertext was invalid (i.e. it was not generated by the because the ciphertext was invalid (i.e. it was not generated by the
encryption of plaintext with the key K). encryption of plaintext with the key K).
These functions have the property that D(K, E(K, P)) = P for all These functions have the property that D(K, E(K, P)) = P for all
values of K and P. Each cipher also has a limit T on the number of values of K and P. Each cipher also has a limit T on the number of
times that it can be used with any fixed key value. For each key, times that it can be used with any fixed key value. For each key,
the encryption function MUST NOT be invoked on more than T distinct the encryption function MUST NOT be invoked on more than T distinct
values of P, and the decryption function MUST NOT be invoked on more values of P, and the decryption function MUST NOT be invoked on more
than T distinct values of C. than T distinct values of C.
The length of the EKT Plaintext is ten bytes, plus the length of the The length of the EKT Plaintext is ten bytes, plus the length of the
SRTP Master Key. SRTP Master Key.
Security requirements for EKT ciphers are discussed in Section 8. Security requirements for EKT ciphers are discussed in Section 8.
2.3.1. The Default Cipher 2.3.1. The Default Cipher
The default EKT Cipher is the Advanced Encryption Standard (AES) The default EKT Cipher is the Advanced Encryption Standard (AES)
[FIPS197] Key Wrap with Padding [RFC5649] algorithm, which can be [FIPS197] Key Wrap with Padding [RFC5649] algorithm. It requires a
used with plaintexts larger than 16 bytes in length, and is thus plaintext length M that is at least one octet, and it returns a
suitable for keys of any size. It requires a plaintext length M that ciphertext with a length of N = M + 8 octets. It can be used with
is at least eight bytes, and it returns a ciphertext with a length of key sizes of L = 16, 24, and 32, and its use with those key sizes is
N = M + 8 bytes. It can be used with key sizes of L = 16, 24, and indicated as AESKW_128, AESKW_192, and AESKW_256, respectively. The
32, and its use with those key sizes is indicated as AESKW_128, key size determines the length of the AES key used by the Key Wrap
AESKW_192, and AESKW_256, respectively. The key size determines the algorithm. With this cipher, T=2^48.
length of the AES key used by the Key Wrap algorithm. With this
cipher, T=2^48.
When AES-128 is used in SRTP and/or SRTCP, AESKW_128 SHOULD be used length of length of
in EKT. In this case, the EKT Plaintext is 26 bytes long, the EKT SRTP EKT EKT EKT length of
Ciphertext is 40 bytes long, and the Full EKT field is 42 bytes long. transform transform plaintext ciphertext Full EKT Field
--------- ------------ --------- ---------- --------------
AES-128 AESKW_128 (m) 26 40 42
AES-192 AESKW_192 34 48 50
AES-256 AESKW_256 42 56 58
F8-128 AESKW_128 26 40 42
SEED-128 AESKW_128 26 40 42
When AES-192 is used in SRTP and/or SRTCP, AESKW_192 SHOULD be used Figure 4: AESKW Table
in EKT. In this case, the EKT Plaintext is 34 bytes long, the EKT
Ciphertext is 48 bytes long, and the Full EKT field is 50 bytes long.
When AES-256 is used in SRTP and/or SRTCP, AESKW_256 SHOULD be used The mandatory to implement transform is AESKW_128, indicated by (m).
in EKT. In this case, the EKT Plaintext is 42 bytes long, the EKT
Ciphertext is 56 bytes long, and the Full EKT field is 58 bytes long. As AES-128 is the mandatory to implement transform in SRTP [RFC3711],
AESKW_128 MUST be implemented for EKT.
For all the SRTP transforms listed in the table, the corresponding
EKT transform MUST be used, unless a stronger EKT transform is
negotiated by key management.
2.3.2. Other EKT Ciphers 2.3.2. Other EKT Ciphers
Other specifications may extend this one by defining other EKT Other specifications may extend this one by defining other EKT
ciphers per Section 9. This section defines how those ciphers ciphers per Section 9. This section defines how those ciphers
interact with this specification. interact with this specification.
An EKT cipher determines how the EKT Ciphertext field is written, and An EKT cipher determines how the EKT Ciphertext field is written, and
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, M, N, and T MUST be an input. The values of the parameters L, M, N, and T MUST be
defined by each EKT cipher, and those values MUST be inferable from defined by each EKT cipher, and those values MUST be inferable from
the EKT parameter set. the EKT parameter set.
2.4. Synchronizing Operation 2.4. Synchronizing Operation
A participant in a session MAY opt to use a particular EKT key to A participant in a session MAY opt to use a particular EKT parameter
protect outbound packets after it accepts that EKT key for protecting set to protect outbound packets after it accepts that EKT parameter
inbound traffic. In this case, the fact that one participant has set for protecting inbound traffic. In this case, the fact that one
changed to using a new EKT key for outbound traffic can trigger other participant has changed to using a new EKT key for outbound traffic
participants to switch to using the same key. can trigger other participants to switch to using the same key.
An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT If a source has its EKT key changed by key management, it MUST also
key has been changed. This will ensure that the set of participants change its SRTP master key, which will cause it to send out a new
able to decrypt the traffic will be limited to those who know the Full EKT Field. This ensures that if key management thought the EKT
current EKT key. key needs changing (due to a participant leaving or joining) and
communicated that in key management to a source, the source will also
change its SRTP master key, so that traffic can be decrypted only by
those who know the current EKT key.
The use of EKT MUST be negotiated during key management or call setup
(e.g., using DTLS-SRTP, Security Descriptions, MIKEY, or similar).
2.5. Transport
EKT SHOULD be used over SRTP, and MAY be used over SRTCP. SRTP is
preferred because it shares fate with transmitted media and because
SRTP rekeying can occur without concern for RTCP transmission limits.
The packet processing, state machine, and Authentication Tag format
for EKT over SRTP are nearly identical to that for EKT over SRTCP.
Differences are highlighted in Section 2.2.1 and Section 2.2.2.
The Full EKT Field is appended to the SRTP or SRTCP payload and is
42, 50, or 58 octets long for AES-128, AES-192, or AES-192,
respectively. This length impacts the maximum payload size of the
SRTP (or SRTCP) packet itself. To remain below the network path MTU,
senders SHOULD constrain the SRTP (or SRTCP) payload size by this
length of the Full EKT Field.
EKT can be transported over SRTCP, but some of the information that EKT can be transported over SRTCP, but some of the information that
it conveys is used for SRTP processing; some elements of the EKT it conveys is used for SRTP processing; some elements of the EKT
parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP
packets can be lost and both SRTP and SRTCP packets may be delivered packets can be lost and both SRTP and SRTCP packets may be delivered
out of order. This can lead to various race conditions if EKT is out of order. This can lead to various race conditions if EKT is
transported over SRTCP but not SRTP, which we review below. transported over SRTCP but not SRTP, which we review below.
When joining an SRTP session, SRTP packets may be received before any
EKT over SRTCP packets, which implies the crypto context has not been
established, unless other external signaling mechanism has done so.
Rather than automatically discarding such SRTP packets, the receiver
MAY want to provisionally place them in a jitter buffer and delay
discarding them until playout time.
When an SRTP source using EKT over SRTCP performs a rekeying
operation, there is a race between the actual rekeying signaled via
SRTCP and the SRTP packets secured by the new keying material. If
the SRTP packets are received first, they will fail authentication;
alternatively, if authentication is not being used, they will decrypt
to unintelligible random-looking plaintext. (Note, however, that
[RFC3711] says that SRTP "SHOULD NOT be used without message
authentication".) In order to address this problem, the rekeying
event can be sent before packets using the new SRTP master key are
sent (by use of the ISN field). Another solution involves using an
MKI at the expense of added overhead in each SRTP packet.
Alternatively, receivers MAY want to delay discarding packets from
known SSRCs that fail authentication in anticipation of receiving a
rekeying event via EKT (SRTCP) shortly.
The ROC signaled via EKT over SRTCP may be off by one when it is The ROC signaled via EKT over SRTCP may be off by one when it is
received by the other party(ies) in the session. In order to deal received by the other party(ies) in the session. In order to deal
with this, receivers should simply follow the SRTP packet index with this, receivers should simply follow the SRTP packet index
estimation procedures defined in Section 3.3.1 [RFC3711]. estimation procedures defined in Section 3.3.1 [RFC3711].
2.5. Transport 2.6. Timing and Reliability Consideration
EKT MUST be used over SRTCP, whenever RTCP is in use. EKT MAY be A system using EKT has the SRTP keys distributed with EKT, rather
used over SRTP. When EKT over SRTP is used in an SRTP session in than with call signaling. This means a receiver can immediately
which SRTCP is available, then EKT MUST be used for both SRTP and decrypt an SRTP (or SRTCP packet) using that new key, provided the
SRTCP. SRTP packet (or SRTCP packet) also contains the EKT key. However, a
receiver cannot immediately authenticate or decrypt an SRTCP packets
without the EKT key. Fortunately, the inability to authenticate or
decrypt SRTCP has little immediate impact on the end user.
The packet processing, state machine, and Authentication Tag format This section describes how to reliably and expediently deliver EKT
for EKT over SRTP are nearly identical to that for EKT over SRTCP. keys to receivers.
Differences are highlighted in Section 2.2.1 and Section 2.2.2.
2.6. Timing and Reliability Consideration There are three cases to consider. The first case is a new sender
joining a session which needs to communicate its key to all the
receivers. The second case is a sender changing its key which needs
to be communicated to all the receivers. The third case is a new
receiver joining a session already in progress which needs to know
the sender's key.
SRTCP communicates the master key and ROC for the SRTP session. New sender: A new sender SHOULD send a packet containing the Full EKT
Thus, as explained above, if SRTP packets are received prior to the Field as soon as possible, always before or coincident with sending
corresponding SRTCP (EKT) packet, a race condition occurs. From an its initial SRTP packet. To accommodate packet loss, it is
EKT point of view, it is therefore desirable for an SRTP sender to RECOMMENDED that three consectutive packets contain the Full EKT
send an EKT packet containing the Base Authentication Tag as soon as Field be transmitted. Inclusion of that Full EKT Field can be
possible, and in no case any later than when the initial SRTP packet stopped early if the sender determines all receivers have received
is sent. It is RECOMMENDED that the Base Authentication Tag be the new EKT key by receipt of an SRTCP receiver report or explicit
transmitted 3 times (to accomodate packet loss) and to provide a ACK for a sequence number with the new key.
reliable indication to the receiver that the sender is now using the
EKT key. If the Base Authentication Tag sent in SRTCP, the SRTCP
timing rules associated with the profile under which it runs (e.g.,
RTP/SAVP or RTP/SAVPF) MUST be obeyed. Subject to that constraint,
SRTP senders using EKT over SRTCP SHOULD send an SRTCP packet as soon
as possible after joining a session. Note that there is no need for
SRTP receivers to do so. Also note, that per RFC 3550, Section 6.2,
it is permissible to send a compound RTCP packet immediately after
joining a unicast session (but not a multicast session).
SRTCP is not reliable and hence SRTCP packets may be lost. This is Rekey: By sending EKT over SRTP, the rekeying event shares fate with
obviously a problem for endpoints joining an SRTP session and the SRTP packets protected with that new key. To avoid sending large
receiving SRTP traffic (as opposed to SRTCP), or for endpoints SRTP packets (such as video key frames) with the Full EKT Field, it
receiving SRTP traffic following a rekeying event. To reduce the can be advantageous to send smaller SRTP packets with the Full EKT
impact of lost packets, SRTP senders using EKT over SRTCP SHOULD send Field with the Initial Sequence Number prior to the actual rekey
SRTCP packets as often as allowed by the profile under which they event, but this does eliminate the benefits of fate-sharing EKT with
operate. the SRTP packets with the new key, which increases the chance a new
receiver won't have seen the new key.
New receiver: When a new receiver joins a session it does not need to
communicate its sending key (because it is a receiver). When a new
receiver joins a session the sender is generally unaware of the
receiver joining the session. Thus, senders SHOULD periodically
transmit the Full EKT Field. That interval depends on how frequently
new receivers join the session, the acceptable delay before those
receivers can start processing SRTP packets, and the acceptable
overhead of sending the Full EKT Field. The RECOMMENDED frequency is
the same as the key frame frequency if sending video or every 5
seconds. When joining a session it is likely that SRTP or SRTCP
packets might be received before a packet containing the Full EKT
Field is received. Thus, to avoid doubling the authentication
effort, an implementation joining an EKT session SHOULD buffer
received SRTP and SRTCP packets until it receives the Full EKT Field
packet and use the information in that packet to authenticate and
decrypt the received SRTP/SRTCP packets.
3. Use of EKT with SDP Security Descriptions 3. Use of EKT with SDP Security Descriptions
The SDP Security Descriptions (SDESC) [RFC4568] specification defines The SDP Security Descriptions (SDESC) [RFC4568] specification defines
a generic framework for negotiating security parameters for media a generic framework for negotiating security parameters for media
streams negotiated via the Session Description Protocol by use of a streams negotiated via the Session Description Protocol with the
new SDP "crypto" attribute and the Offer/Answer procedures defined in "crypto" attribute and the Offer/Answer procedures defined in
[RFC3264]. In addition to the general framework, SDES also defines [RFC3264]. In addition to the general framework, SDES also defines
how to use that framework specifically to negotiate security how to use that framework specifically to negotiate security
parameters for Secure RTP. Below, we first provide a brief recap of parameters for Secure RTP. Below, we first provide a brief recap of
the crypto attribute when used for SRTP and we then explain how it is the crypto attribute when used for SRTP and we then explain how it is
complementary to EKT. In the rest of this Section, we provide complementary to EKT. In the rest of this Section, we provide
extensions to the crypto attribute and associated offer/answer extensions to the crypto attribute and associated offer/answer
procedures to define its use with EKT. procedures to define its use with EKT.
3.1. SDP Security Descriptions Recap 3.1. SDP Security Descriptions Recap
The SRTP crypto attribute defined for SDESC contains a tag followed The SRTP crypto attribute defined for SDESC contains a tag followed
by three types of parameters (refer to [RFC4568] for details): by three types of parameters (refer to [RFC4568] for details):
o Crypto-suite. Identifies the encryption and authentication o Crypto-suite. Identifies the encryption and authentication
transform transform.
o Key parameters. SRTP keying material and parameters. o Key parameters. SRTP keying material and parameters.
o Session parameters. Additional (optional) SRTP parameters such as o Session parameters. Additional (optional) SRTP parameters such as
Key Derivation Rate, Forward Error Correction Order, use of Key Derivation Rate, Forward Error Correction Order, use of
unencrypted SRTP, and other parameters defined by SDESC. unencrypted SRTP, and other parameters defined by SDESC.
The crypto attributes in the example SDP in Figure 4 illustrate these The crypto attributes in the example SDP in Figure 5 illustrate these
parameters. parameters.
v=0 v=0
o=sam 2890844526 2890842807 IN IP4 192.0.2.5 o=sam 2890844526 2890842807 IN IP4 192.0.2.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson) e=marge@example.com (Marge Simpson)
c=IN IP4 192.0.2.12 c=IN IP4 192.0.2.12
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20
FEC_ORDER=FEC_SRTP FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80 a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjiiKt|2^20
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 FEC_ORDER=FEC_SRTP
FEC_ORDER=FEC_SRTP
Figure 4: SDP Security Descriptions example Figure 5: SDP Security Descriptions example
For legibility the SDP shows line breaks that are not present on the For legibility the SDP shows line breaks that are not present on the
wire. wire.
The first crypto attribute has the tag "1" and uses the crypto-suite The first crypto attribute has the tag "1" and uses the crypto-suite
AES_CM_128_HMAC_SHA1_80. The "inline" parameter provides the SRTP AES_CM_128_HMAC_SHA1_80. The "inline" parameter provides the SRTP
master key and salt, the master key lifetime (number of packets), and master key and salt and the master key lifetime (number of packets).
the (optional) Master Key Identifier (MKI) whose value is "1" and has Finally, the FEC_ORDER session parameter indicates the order of
a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER Forward Error Correction used (FEC is applied before SRTP processing
session parameter indicates the order of Forward Error Correction by the sender of the SRTP media).
used (FEC is applied before SRTP processing by the sender of the SRTP
media).
The second crypto attribute has the tag "2" and uses the crypto-suite The second crypto attribute has the tag "2", the crypto-suite
F8_128_HMAC_SHA1_80. It includes two SRTP master keys and associated F8_128_HMAC_SHA1_80, two SRTP master keys and associated salts.
salts. The first one is used with the MKI value 1, whereas the Finally, the FEC_ORDER session parameter indicates the order of
second one is used with the MKI value 2. Finally, the FEC_ORDER Forward Error Correction used.
session parameter indicates the order of Forward Error Correction
used.
3.2. Relationship between EKT and SDP Security Descriptions 3.2. Relationship between EKT and SDP Security Descriptions
SDP Security Descriptions [RFC4568] define a generic framework for SDP Security Descriptions [RFC4568] define a generic framework for
negotiating security parameters for media streams negotiated via the negotiating security parameters for media streams negotiated via the
Session Description Protocol by use of the Offer/Answer procedures Session Description Protocol by use of the Offer/Answer procedures
defined in [RFC3264]. In addition to the general framework, SDESC defined in [RFC3264]. In addition to the general framework, SDESC
also defines how to use it specifically to negotiate security also defines how to use it specifically to negotiate security
parameters for Secure RTP. parameters for Secure RTP.
EKT and SDESC are complementary. SDESC can negotiate several of the EKT and SDP Security Descriptions are complementary. SDP Security
SRTP security parameters (e.g., cipher and use of Master Key Descriptions can negotiate several of the SRTP security parameters
Identifier/MKI) as well as SRTP master keys. SDESC, however, does (e.g., cipher and use of Master Key Identifier) as well as SRTP
not negotiate SSRCs and their associated Rollover Counter (ROC). master keys. SDESC, however, does not negotiate SSRCs and their
Instead, SDESC relies on a so-called "late binding", where a newly associated Rollover Counter (ROC). Instead, SDESC relies on a so-
observed SSRC will have its crypto context initialized to a ROC value called "late binding", where a newly observed SSRC will have its
of zero. Clearly, this does not work for participants joining an crypto context initialized to a ROC value of zero. Clearly, this
SRTP session that has been established for a while and hence has a does not work for participants joining an SRTP session that has been
non-zero ROC. It is impossible to use SDESC to join an SRTP session established for a while and hence has a non-zero ROC. It is
that is already in progress. In this case, EKT on the endpoint impossible to use SDESC to join an SRTP session that is already in
running SDP Security can provide the additional signaling necessary progress. In this case, EKT on the endpoint running SDESC can
to communicate the ROC (Section 6.4.1 of [RFC4568]). The use of EKT provide the additional signaling necessary to communicate the ROC
solves this problem by communicating the ROC associated with the SSRC (Section 6.4.1 of [RFC4568]). The use of EKT solves this problem by
in the media plane. communicating the ROC associated with the SSRC in the media plane.
SDP Security Descriptions negotiates different SRTP master keys in SDP Security Descriptions negotiates different SRTP master keys in
the send and receive direction. The offer contains the master key the send and receive direction. The offer contains the master key
used by the offerer to send media, and the answer contains the master used by the offerer to send media, and the answer contains the master
key used by the answerer to send media. Consequently, if media is key used by the answerer to send media. Consequently, if media is
received by the offerer prior to the answer being received, the received by the offerer prior to the answer being received, the
offerer does not know the master key being used. Use of SDP security offerer does not know the master key being used. Use of SDP security
preconditions can solve this problem, however it requires an preconditions can solve this problem, however it requires an
additional round-trip as well as a more complicated state machine. additional round-trip as well as a more complicated state machine.
EKT solves this problem by simply sending the master key used in the EKT solves this problem by simply sending the master key used in the
skipping to change at page 19, line 22 skipping to change at page 18, line 15
3.3. Overview of Combined EKT and SDP Security Description Operation 3.3. Overview of Combined EKT and SDP Security Description Operation
We define three session extension parameters to SDESC to communicate We define three session extension parameters to SDESC to communicate
the EKT cipher, EKT key, and Security Parameter Index to the peer. the EKT cipher, EKT key, and Security Parameter Index to the peer.
The original SDESC parameters are used as defined in [RFC4568], The original SDESC parameters are used as defined in [RFC4568],
however the procedures associated with the SRTP master key differ however the procedures associated with the SRTP master key differ
slightly, since both SDESC and EKT communicate an SRTP master key. slightly, since both SDESC and EKT communicate an SRTP master key.
In particular, the SRTP master key communicated via SDESC is used In particular, the SRTP master key communicated via SDESC is used
only if there is currently no crypto context established for the SSRC only if there is currently no crypto context established for the SSRC
in question. This will be the case when an entity has received only in question. This will be the case when an entity has received only
the offer or answer, but has yet to receive a valid EKT message from the offer or answer, but has yet to receive a valid EKT packet from
the peer. Once a valid EKT message is received for the SSRC, the the peer. Once a valid EKT packet is received for the SSRC, the
crypto context is initialized accordingly, and the SRTP master key crypto context is initialized accordingly, and the SRTP master key
will then be derived from the EKT message. Subsequent offer/answer will then be derived from the EKT packet. Subsequent offer/answer
exchanges do not change this: The most recent SRTP master key exchanges do not change this: The most recent SRTP master key
negotiated via EKT will be used, or, if none is available for the negotiated via EKT will be used, or, if none is available for the
SSRC in question, the most recent SRTP master key negotiated via SSRC in question, the most recent SRTP master key negotiated via
offer/answer will be used. Note that with these rules, once a valid offer/answer will be used. This is done to avoid race conditions
EKT message has been received for a given SSRC, rekeying for that between the offer/answer exchange and EKT, even though this breaks
SSRC can only be done via EKT. The associated SRTP crypto parameters some offer/answer rules. Note that with the rules described in this
however can be changed via SDESC. paragraph, once a valid EKT packet has been received for a given
SSRC, rekeying for that SSRC can only be done via EKT. The
associated SRTP crypto parameters however can be changed via SDESC.
3.4. EKT Extensions to SDP Security Descriptions 3.4. EKT Extensions to SDP Security Descriptions
In order to use EKT and SDESC in conjunction with each other, the In order to use EKT and SDESC in conjunction with each other, the
following new SDES session parameters are defined. These MUST NOT following new SDESC session parameters are defined. These MUST NOT
appear more than once in a given crypto attribute: appear more than once in a given crypto attribute:
EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key
EKT_Key: The EKT key used to encrypt the SRTP Master Key EKT_Key: The EKT key used to encrypt the SRTP Master Key
EKT_SPI: The EKT Security Parameter Index EKT_SPI: The EKT Security Parameter Index
Below are details on each of these attributes. Below are details on each of these attributes.
3.4.1. EKT_Cipher 3.4.1. EKT_Cipher
The (optional) EKT_Cipher parameter defines the EKT cipher used to The (optional) EKT_Cipher parameter defines the EKT cipher used to
encrypt the EKT key with in SRTCP packets. The default value is encrypt the EKT key within SRTP and SRTCP packets. The default value
"AESKW_128" in accordance with Section 2.3.1. For the AES Key Wrap is "AESKW_128" in accordance with Section 2.3.1. For the AES Key
cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are Wrap cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are
defined for values of L=16, 24, and 32 respectively. In the Offer/ defined for values of L=16, 24, and 32 respectively. In the Offer/
Answer model, the EKT_Cipher parameter is a negotiated parameter. Answer model, the EKT_Cipher parameter is a negotiated parameter.
3.4.2. EKT_Key 3.4.2. EKT_Key
The (mandatory) EKT_Key parameter is the key K used to encrypt the The (mandatory) EKT_Key parameter is the key K used to encrypt the
SRTP Master Key in SRTCP packets. The value is base64 encoded as SRTP Master Key within SRTP and SRTCP packets. The value is base64
described in Section 4 [RFC4648]. When base64 decoding the key, encoded with "=" padding if padding is necessary (see Section 3.2 and
padding characters (i.e., one or two "=" at the end of the base64 4 of [RFC4648]). In the Offer/Answer model, the EKT_Key parameter is
encoded data) are discarded (see [RFC4648] for details). Base64 a negotiated parameter.
encoding assumes that the base64 encoding input is an integral number
of octets. If a given EKT cipher requires the use of a key with a
length that is not an integral number of octets, said cipher MUST
define a padding scheme that results in the base64 input being an
integral number of octets. For example, if the length defined was
250 bits, then 6 padding bits would be needed, which could be defined
to be the last 6 bits in a 256 bit input. In the Offer/Answer model,
the EKT_Key parameter is a negotiated parameter.
3.4.3. EKT_SPI 3.4.3. EKT_SPI
The (mandatory) EKT_SPI parameter is the Security Parameter Index. The (mandatory) EKT_SPI parameter is the Security Parameter Index.
It is encoded as an ASCII string representing the hexadecimal value It is encoded as an ASCII string representing the hexadecimal value
of the Security Parameter Index. The SPI identifies the *offer* of the Security Parameter Index. The SPI identifies the *offer*
crypto attribute (including the EKT Key and Cipher) being used for crypto attribute (including the EKT Key and Cipher) being used for
the associated SRTP session. A crypto attribute corresponds to an the associated SRTP session. A crypto attribute corresponds to an
EKT Parameter Set and hence the SPI effectively identifies a EKT Parameter Set and hence the SPI effectively identifies a
particular EKT parameter set. Note that the scope of the SPI is the particular EKT parameter set. Note that the scope of the SPI is the
skipping to change at page 20, line 45 skipping to change at page 19, line 33
associated SIP dialog. In particular, if one of the participants in associated SIP dialog. In particular, if one of the participants in
an SRTP session is an SRTP translator, the scope of the SRTP session an SRTP session is an SRTP translator, the scope of the SRTP session
is not limited to the scope of a single SIP dialog. However, if all is not limited to the scope of a single SIP dialog. However, if all
of the participants in the session are endpoints or mixers, the scope of the participants in the session are endpoints or mixers, the scope
of the SRTP session will correspond to a single SIP dialog. In the of the SRTP session will correspond to a single SIP dialog. In the
Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. Offer/Answer model, the EKT_SPI parameter is a negotiated parameter.
3.5. Offer/Answer Procedures 3.5. Offer/Answer Procedures
In this section, we provide the offer/answer procedures associated In this section, we provide the offer/answer procedures associated
with use of the three new SDESC parameters defined in Section with use of the three new SDESC parameters defined in Section 3.4.
Section 3.4. Since SDESC is defined only for unicast streams, we Since SDESC is defined only for unicast streams, we provide only
provide only offer/answer procedures for unicast streams here as offer/answer procedures for unicast streams here as well.
well.
3.5.1. Generating the Initial Offer - Unicast Streams 3.5.1. Generating the Initial Offer - Unicast Streams
When the initial offer is generated, the offerer MUST follow the When the initial offer is generated, the offerer MUST follow the
steps defined in [RFC4568] Section 7.1.1 as well as the following steps defined in [RFC4568] Section 7.1.1 as well as the following
steps. steps.
For each unicast media line using SDESC and where use of EKT is [[Editor's Note: following paragraph would benefit from rewording.]]
desired, the offerer MUST include one EKT_Key parameter and one
EKT_SPI parameter in at least one "crypto" attribute (see [RFC4568]).
The EKT_SPI parameter serves to identify the EKT parameter set used
for a particular SRTCP packet. Consequently, within a single media
line, a given EKT_SPI value MUST NOT be used with multiple crypto
attributes. Note that the EKT parameter set to use for the session
is not yet established at this point; each offered crypto attribute
contains a candidate EKT parameter set. Furthermore, if the media
line refers to an existing SRTP session, then any SPI values used for
EKT parameter sets in that session MUST NOT be remapped to any
different EKT parameter sets. When an offer describes an SRTP
session that is already in progress, the offer SHOULD use an EKT
parameter set (incl. EKT_SPI and EKT_KEY) that is already in use.
If an EKT_Cipher other than the default cipher is to be used, then For each unicast media line using Security Descriptions and where use
the EKT_Cipher parameter MUST be included as well. of EKT is desired, the offerer MUST include one EKT_Key parameter and
one EKT_SPI parameter in at least one "crypto" attribute (see
[RFC4568]). The EKT_SPI parameter serves to identify the EKT
parameter set used for a particular SRTCP packet. Consequently,
within a single media line, a given EKT_SPI value MUST NOT be used
with multiple crypto attributes. Note that the EKT parameter set to
use for the session is not yet established at this point; each
offered crypto attribute contains a candidate EKT parameter set.
Furthermore, if the media line refers to an existing SRTP session,
then any SPI values used for EKT parameter sets in that session MUST
NOT be remapped to any different EKT parameter sets. When an offer
describes an SRTP session that is already in progress, the offer
SHOULD use an EKT parameter set (including EKT_SPI and EKT_KEY) that
is already in use.
If a given crypto attribute includes more than one set of SRTP key If a given crypto attribute includes more than one set of SRTP key
parameters (SRTP master key, salt, lifetime, MKI), they MUST all use parameters (SRTP master key, salt, lifetime), they MUST all use the
the same salt. (EKT requires a single shared salt between all the same salt. (EKT requires a single shared salt between all the
participants in the direct SRTP session). participants in the direct SRTP session).
As EKT is not defined for use with MKI, the offer and the answer MUST
NOT contain MKI.
Important Note: The scope of the offer/answer exchange is the SIP Important Note: The scope of the offer/answer exchange is the SIP
dialog(s) established as a result of the INVITE, however the scope dialog(s) established as a result of the INVITE, however the scope
of EKT is the direct SRTP session, i.e., all the participants that of EKT is the direct SRTP session, i.e., all the participants that
are able to receive SRTP and SRTCP packets directly. If an SRTP are able to receive SRTP and SRTCP packets directly. If an SRTP
session spans multiple SIP dialogs, the EKT parameter sets MUST be session spans multiple SIP dialogs, the EKT parameter sets MUST be
synchronized between all the SIP dialogs where SRTP and SRTCP synchronized between all the SIP dialogs where SRTP and SRTCP
packets can be exchanged. In the case where the SIP entity packets can be exchanged. In the case where the SIP entity
operates as an RTP mixer (and hence re-originates SRTP and SRTCP operates as an RTP mixer (and hence re-originates SRTP and SRTCP
packets with its own SSRC), this is not an issue, unless the mixer packets with its own SSRC), this is not an issue, unless the mixer
receives traffic from the various participants on the same receives traffic from the various participants on the same
destination IP address and port, in which case further destination IP address and port, in which case further
coordination of SPI values and crypto parameters may be needed coordination of SPI values and crypto parameters may be needed
between the SIP dialogs (note that SIP forking with multiple early between the SIP dialogs (note that SIP forking with multiple early
media senders is an example of this). However if it operates as media senders is an example of this). However, if it operates as
an RTP translator, synchronized negotiation of the EKT parameter a transport translator (relay) then synchronized negotiation of
sets on *all* the involved SIP dialogs will be needed. This is the EKT parameter sets on *all* the involved SIP dialogs will be
non-trivial in a variety of use cases, and hence use of the needed. This is non-trivial in a variety of use cases, and hence
combined SDES/EKT mechanism with RTP translators should be use of the combined SDES/EKT mechanism with RTP translators should
considered very carefully. It should be noted, that use of SRTP be considered very carefully. It should be noted, that use of
with RTP translators in general should be considered very SRTP with RTP translators in general should be considered very
carefully as well. carefully as well.
The EKT session parameters can either be included as optional or The EKT session parameters can either be included as optional or
mandatory parameters, however within a given crypto attribute, they mandatory parameters, however within a given crypto attribute, they
MUST all be either optional or mandatory. MUST all be either optional or mandatory.
3.5.2. Generating the Initial Answer - Unicast Streams 3.5.2. Generating the Initial Answer - Unicast Streams
When the initial answer is generated, the answerer MUST follow the When the initial answer is generated, the answerer MUST follow the
steps defined in [RFC4568] Section 7.1.2 as well as the following steps defined in [RFC4568] Section 7.1.2 as well as the following
skipping to change at page 23, line 16 skipping to change at page 22, line 4
from the answerer's until the answer is received. Similarly, unless from the answerer's until the answer is received. Similarly, unless
the offerer and answerer has other means for correlating an answer the offerer and answerer has other means for correlating an answer
with a particular SRTP session, the answer SHOULD NOT include any with a particular SRTP session, the answer SHOULD NOT include any
declarative session parameters that either were not present in the declarative session parameters that either were not present in the
offered crypto attribute, or were present but with a different value. offered crypto attribute, or were present but with a different value.
If this recommendation is not followed and the offerer receives If this recommendation is not followed and the offerer receives
multiple answers (e.g., due to SIP forking), the offerer may not be multiple answers (e.g., due to SIP forking), the offerer may not be
able to process incoming media stream packets correctly. able to process incoming media stream packets correctly.
3.5.3. Processing of the Initial Answer - Unicast Streams 3.5.3. Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in When the offerer receives the answer, it MUST perform the steps in
[RFC4568] Section 7.1.3 as well as the following steps for each SRTP [RFC4568] Section 7.1.3 as well as the following steps for each SRTP
media stream it offered with one or more crypto lines containing EKT media stream it offered with one or more crypto lines containing EKT
parameters in it. parameters in it.
[[Editor's Note: following paragraph would benefit from rewording.]]
If the answer crypto line contains EKT parameters, and the If the answer crypto line contains EKT parameters, and the
corresponding crypto line from the offer contained the same EKT corresponding crypto line from the offer contained the same EKT
values, use of EKT has been negotiated successfully and MUST be used values, use of EKT has been negotiated successfully and MUST be used
for the media stream. When determining whether the values match, for the media stream. When determining whether the values match,
optional and mandatory parameters MUST be considered equal. optional and mandatory parameters MUST be considered equal.
Furthermore, if the default EKT cipher is being used, it MAY be Furthermore, if the default EKT cipher is being used, it MAY be
either present or absent in the offer and/or answer. either present or absent in the offer and/or answer.
If the answer crypto line does not contain EKT parameters, then EKT If the answer crypto line does not contain EKT parameters, then EKT
MUST NOT be used for the corresponding SRTP session. Note that if MUST NOT be used for the corresponding SRTP session. Note that if
skipping to change at page 23, line 44 skipping to change at page 22, line 33
EKT parameters, then negotiation has failed (Section 5.1.3 of EKT parameters, then negotiation has failed (Section 5.1.3 of
[RFC4568]). [RFC4568]).
If the answer crypto line contains EKT parameters but the If the answer crypto line contains EKT parameters but the
corresponding offered crypto line did not, or if the parameters don't corresponding offered crypto line did not, or if the parameters don't
match or are invalid, then the offerer MUST consider the crypto line match or are invalid, then the offerer MUST consider the crypto line
invalid (see Section 7.1.3 of [RFC4568] for further operation). invalid (see Section 7.1.3 of [RFC4568] for further operation).
The EKT parameter set is established when the answer is received, The EKT parameter set is established when the answer is received,
however there are a couple of special cases to consider here. First however there are a couple of special cases to consider here. First
of all, if an SRTCP packet is received prior to the answer, then the of all, if an SRTP packet containing a Full EKT Field is received
EKT parameter set is established provisionally based on the SPI prior to the answer, then the EKT parameter set is established
included. Once the answer (which may include declarative session provisionally based on the SPI included. Once the answer (which may
parameters) is received, the EKT parameter set is fully established. include declarative session parameters) is received, the EKT
The second case involves receipt of multiple answers due to SIP parameter set is fully established. The second case involves receipt
forking. In this case, there will be multiple EKT parameter sets; of multiple answers due to SIP forking. In this case, there will be
one for each SRTP session. As mentioned earlier, reliable multiple EKT parameter sets; one for each SRTP session. As mentioned
correlation of SIP dialogs to SRTP sessions requires extensions, and earlier, reliable correlation of SIP dialogs to SRTP sessions
hence if one or more of the answers include declarative session requires extensions, and hence if one or more of the answers include
parameters, it may be difficult to fully establish the EKT parameter declarative session parameters, it may be difficult to fully
set for each SRTP session. In the absence of a specific correlation establish the EKT parameter set for each SRTP session. In the
mechanism, it is RECOMMENDED, that such correlation be done based on absence of a specific correlation mechanism, it is RECOMMENDED, that
the signaled receive IP-address in the SDP and the observed source such correlation be done based on the signaled receive IP-address in
IP-address in incoming SRTP/SRTCP packets, and, if necessary, the the SDP and the observed source IP-address in incoming SRTP/SRTCP
signaled receive UDP port and the observed source UDP port. packets, and, if necessary, the signaled receive UDP port and the
observed source UDP port.
3.6. SRTP-Specific Use Outside Offer/Answer 3.6. SRTP-Specific Use Outside Offer/Answer
Security Descriptions use for SRTP is not defined outside offer/ Security Descriptions use for SRTP is not defined outside offer/
answer and hence neither does Security Descriptions with EKT. answer and hence neither does Security Descriptions with EKT.
3.7. Modifying the Session 3.7. Modifying the Session
When a media stream using the SRTP security descriptions has been When a media stream using the SRTP security descriptions has been
established, and a new offer/answer exchange is performed, the established, and a new offer/answer exchange is performed, the
offerer and answerer MUST follow the steps in Section 7.1.4 of offerer and answerer MUST follow the steps in Section 7.1.4 of
[RFC4568] as well as the following steps. SDESC allows for all [RFC4568] as well as the following steps. SDESC allows for all
parameters of the session to be modified, and the EKT session parameters of the session to be modified, and the EKT session
skipping to change at page 24, line 29 skipping to change at page 23, line 20
established, and a new offer/answer exchange is performed, the established, and a new offer/answer exchange is performed, the
offerer and answerer MUST follow the steps in Section 7.1.4 of offerer and answerer MUST follow the steps in Section 7.1.4 of
[RFC4568] as well as the following steps. SDESC allows for all [RFC4568] as well as the following steps. SDESC allows for all
parameters of the session to be modified, and the EKT session parameters of the session to be modified, and the EKT session
parameters are no exception to that, however, there are a few parameters are no exception to that, however, there are a few
additional rules to be adhered to when using EKT. additional rules to be adhered to when using EKT.
It is permissible to start a session without the use of EKT, and then It is permissible to start a session without the use of EKT, and then
subsequently start using EKT, however the converse is not. Thus, subsequently start using EKT, however the converse is not. Thus,
once use of EKT has been negotiated on a particular media stream, EKT once use of EKT has been negotiated on a particular media stream, EKT
MUST continue to be used on that media stream in all subsequent MUST continue to be used on that media stream in all subsequent offer
offer/answer exchanges. /answer exchanges.
The reason for this is that both SDESC and EKT communicate the SRTP The reason for this is that both SDESC and EKT communicate the SRTP
Master Key with EKT Master Keys taking precedence. Reverting back to Master Key with EKT Master Keys taking precedence. Reverting back to
an SDESC-controlled master key in a synchronized manner is difficult. an SDESC-controlled master key in a synchronized manner is difficult.
Once EKT is being used, the salt for the direct SRTP session MUST NOT Once EKT is being used, the salt for the direct SRTP session MUST NOT
be changed. Thus, a new offer/answer which does not create a new be changed. Thus, a new offer/answer which does not create a new
SRTP session (e.g., because it reuses the same IP address and port) SRTP session (e.g., because it reuses the same IP address and port)
MUST use the same salt for all crypto attributes as is currently used MUST use the same salt for all crypto attributes as is currently used
for the direct SRTP session. for the direct SRTP session.
[[Editor's Note: following paragraph would benefit from re-arranging
into earlier-described steps.]]
Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI
value to a different EKT parameter set until 2^32 other mappings have value to a different EKT parameter set until 2^15 other mappings have
been used within the SRTP session. In practice, this requirements is been used within the SRTP session. In practice, this requirements is
most easily met by using a monotonically increasing SPI value (modulo most easily met by using a monotonically increasing SPI value (modulo
2^32 and starting with zero) per direct SRTP session. Note that a 2^15 and starting with zero) per direct SRTP session. Note that a
direct SRTP session may span multiple SIP dialogs, and in such cases direct SRTP session may span multiple SIP dialogs, and in such cases
coordination of SPI values across those SIP dialogs will be required. coordination of SPI values across those SIP dialogs will be required.
In the simple point-to-point unicast case without translators, the In the simple point-to-point unicast case without translators, the
requirement simply applies within each media line in the SDP. In the requirement simply applies within each media line in the SDP. In the
point-to-multipoint case, the requirement applies across all the point-to-multipoint case, the requirement applies across all the
associated SIP dialogs. associated SIP dialogs.
3.8. Backwards Compatibility Considerations 3.8. Backwards Compatibility Considerations
Backwards compatibility can be achieved in a couple of ways. First Backwards compatibility can be achieved in a couple of ways. First
of all, SDESC allows for session parameters to be prefixed with "-" of all, Security Descriptions allows for session parameters to be
to indicate that they are optional. If the answerer does not support prefixed with "-" to indicate that they are optional. If the
the EKT session parameters, such optional parameters will simply be answerer does not support the EKT session parameters, such optional
ignored. When the answer is received, absence of the parameters will parameters will simply be ignored. When the answer is received,
indicate that EKT is not being used. Receipt of SRTCP packets prior absence of the parameters will indicate that EKT is not being used.
to receipt of such an answer will obviously be problematic (as is Receipt of SRTP or SRTCP packets prior to receipt of such an answer
normally the case for SDESC without EKT). will obviously be problematic (as is normally the case for Security
Descriptions without EKT).
Alternatively, SDESC allows for multiple crypto lines to be included Alternatively, Security Descriptions allows for multiple crypto lines
for a particular media stream. Thus, two crypto lines that differ in to be included for a particular media stream. Thus, two crypto lines
their use of EKT parameters (presence in one, absence in the other) that differ in their use of EKT parameters (presence in one, absence
can be used as a way to negotiate use of EKT. When the answer is in the other) can be used as a way to negotiate use of EKT. When the
received, the accepted crypto attribute will indicate whether EKT is answer is received, the accepted crypto attribute will indicate
being used or not. whether EKT is being used or not.
3.9. Grammar 3.9. Grammar
The ABNF [RFC5234] syntax for the one new SDP Security Descriptions The ABNF [RFC5234] syntax for the one new SDP Security Descriptions
session parameter, EKT, comprising three parts is shown in Figure 5. session parameter, EKT, comprising three parts is shown in Figure 6.
ekt = "EKT=" cipher "|" key "|" spi ekt = "EKT=" cipher "|" key "|" spi
cipher = cipher-extension / "AES_128" / "AESKW_128" / cipher = cipher-ext / "AESKW_128" / "AESKW_192" / "AESKW_256"
"AESKW_192" / "AESKW_256" cipher-ext = 1*64(ALPHA / DIGIT / "_")
cipher-extension = 1*(ALPHA / DIGIT / "_") key = 1*(base64) ; See Section 4 of [RFC4648]
key = 1*(base64) ; See Section 4 of [RFC4648] base64 = ALPHA / DIGIT / "+" / "/" / "="
base64 = ALPHA / DIGIT / "+" / "/" / "=" spi = 4HEXDIG ; See [RFC5234]
spi = 4HEXDIG ; See [RFC5234]
Figure 5: ABNF for the EKT session parameters Figure 6: ABNF for the EKT session parameters
Using the example from Figure 5 with the EKT extensions to SDP Using the example from Figure 6 with the EKT extensions to SDP
Security Descriptions results in the following example SDP: Security Descriptions results in the following example SDP:
v=0 v=0
o=sam 2890844526 2890842807 IN IP4 192.0.2.5 o=sam 2890844526 2890842807 IN IP4 192.0.2.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson) e=marge@example.com (Marge Simpson)
c=IN IP4 192.0.2.12 c=IN IP4 192.0.2.12
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 FEC_ORDER=FEC_SRTP EKT=AESKW_128|WWVzQUxvdmVseUVLVGtleQ|AAE0
a=crypto:2 F8_128_HMAC_SHA1_80 a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 FEC_ORDER=FEC_SRTP EKT=AESKW_128|VHdvTG92ZWx5RUtUa2V5cw|AAE0
For legibility the SDP shows line breaks that are not present on the For legibility the SDP shows line breaks that are not present on the
wire. wire.
4. Use of EKT with DTLS-SRTP Key Transport 4. Use of EKT with DTLS-SRTP Key Transport
This document defines an extension to DTLS-SRTP called Key Transport. This document defines an extension to DTLS-SRTP called Key Transport.
Using EKT with the DTLS-SRTP Key Transport extensions allows securely The EKT with the DTLS-SRTP Key Transport enables secure transport of
transporting SRTP keying material from one DTLS-SRTP peer to another, EKT keying material from one DTLS-SRTP peer to another. This enables
so the same SRTP keying material can be used by those peers and so those peers to process EKT keying material in SRTP (or SRTCP) and
those peers can process EKT keys. This combination of protocols is retrieve the embedded SRTP keying material. This combination of
valuable because it combines the advantages of DTLS (strong protocols is valuable because it combines the advantages of DTLS
authentication of the endpoint and flexibility) with the advantages (strong authentication of the endpoint and flexibility) with the
of EKT (allowing secure multiparty RTP with loose coordination and advantages of EKT (allowing secure multiparty RTP with loose
efficient communication of per-source keys). coordination and efficient communication of per-source keys).
4.1. EKT Extensions to DTLS-SRTP 4.1. DTLS-SRTP Recap
DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers
to exchange keying material, algorithms, and parapeters for SRTP.
The SRTP flow operates over the same transport as the DTLS-SRTP
exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
performance and encryption flexibility benefits of SRTP with the
flexibility and convenience of DTLS-integrated key and association
management. DTLS-SRTP can be viewed in two equivalent ways: as a new
key management method for SRTP, and a new RTP-specific data format
for DTLS.
4.2. EKT Extensions to DTLS-SRTP
This document adds a new TLS negotiated extension called "ekt". This This document adds a new TLS negotiated extension called "ekt". This
adds a new TLS content type, EKT, and a new negotiated extension EKT. adds a new TLS content type, EKT, and a new negotiated extension EKT.
The negotiated extension MUST only be requested in conjunction with The negotiated extension MUST only be requested in conjunction with
the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server
indicates its support for EKT by including "dtls-srtp-ekt" in its SDP MUST include "dtls-srtp-ekt" in its SDP (as a session or media level
and "ekt" in its TLS ServerHello message. If a DTLS client includes attribute) and "ekt" in its TLS ServerHello message. If a DTLS
"ekt" in its ClientHello, but does not receive "ekt" in the client includes "ekt" in its ClientHello, but does not receive "ekt"
ServerHello, the DTLS client MUST NOT send DTLS packets with the in the ServerHello, the DTLS client MUST NOT send DTLS packets with
"ekt" content-type. the "ekt" content-type.
The formal description of the dtls-srtp-ekt attribute is defined by
the following ABNF [RFC5234] syntax:
attribute = "a=dtls-srtp-ekt"
Using the syntax described in DTLS [RFC6347], the following Using the syntax described in DTLS [RFC6347], the following
structures are used: structures are used:
enum { enum {
ekt_key(0), ekt_key(0),
ekt_key_ack(1), ekt_key_ack(1),
ekt_key_error(254), ekt_key_error(254),
(255) (255)
} SRTPKeyTransportType; } SRTPKeyTransportType;
struct { struct {
SRTPKeyTransportType keytrans_type; SRTPKeyTransportType keytrans_type;
uint24 length; uint24 length;
uint16 message_seq; uint16 message_seq;
uint24 fragment_offset; uint24 fragment_offset;
uint24 fragment_length; uint24 fragment_length;
select (SRTPKeyTransportType) { select (SRTPKeyTransportType) {
case ekt_key: case ekt_key:
EKTkey; EKTkey;
}; };
} KeyTransport; } KeyTransport;
enum { enum {
AES_128(0), RESERVED(0),
AESKW_128(1), AESKW_128(1),
AESKW_192(2), AESKW_192(2),
AESKW_256(3), AESKW_256(3),
} ektcipher; } ektcipher;
struct { struct {
ektcipher EKT_Cipher; ektcipher EKT_Cipher;
uint EKT_Key_Value<1..256>; uint EKT_Key_Value<1..256>;
uint EKT_Master_Salt<1..256>; uint EKT_Master_Salt<1..256>;
uint16 EKT_SPI; uint16 EKT_SPI;
} EKTkey; } EKTkey;
Figure 6: Additional TLS Data Structures Figure 7: Additional TLS Data Structures
The diagram below shows a message flow of DTLS client and DTLS server The diagram below shows a message flow of DTLS client and DTLS server
using the DTLS-SRTP Key Transport extension. SRTP packets exchanged using the DTLS-SRTP Key Transport extension. SRTP packets exchanged
prior to the ekt_message are encrypted using the SRTP master key prior to the ekt_message are encrypted using the SRTP master key
derived from the normal DTLS-SRTP key derivation function. After the derived from the normal DTLS-SRTP key derivation function. After the
ekt_key message, they can be encrypted using the EKT key. ekt_key message, they can be encrypted using the SRTP key carried by
EKT.
Editor's note: do we need reliability for the ekt_key messages?
Client Server
ClientHello + use_srtp + EKT
-------->
ServerHello + use_srtp + EKT
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
ekt_key -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
Figure 7: Handshake Message Flow
4.1.1. Scaling to Large Groups
In certain scenarios it is useful to perform DTLS-SRTP with a device
that is not the RTP peer. A common scenario is multicast, where it
is necessary to distribute the DTLS-SRTP (and EKT distribution) to
several devices. To allow for this, a new SDP attribute, dtls-srtp-
host, is defined which follows the general syntax specified in
Section 5.13 of [RFC4566]. When signaled, it indicates this host
controls the EKT keying for all group members. For the dtls-srtp-
host attribute:
o the name is the ASCII string "dtls-srtp-host" (lowercase)
o the value is the IP address and port number used for DTLS-SRTP
o This is a media-level attribute and MUST NOT appear at the session
level
The formal description of the attribute is defined by the following
ABNF [RFC5234] syntax:
attribute = "a=dtls-srtp-host:"
dtls-srtp-host-info *(SP dtls-srtp-host-info)
host-info = nettype space addrtype space
connection-address space port CRLF
Multiple IP/port pairs are provided for IPv6/IPv4 interworking, and Client Server
to allow failover. The receiving host SHOULD attempt to use them in
the order provided.
An example of SDP containing the dtls-srtp-host attribute: ClientHello + use_srtp + EKT
-------->
ServerHello + use_srtp + EKT
Certificate*
v=0 ServerKeyExchange*
o=sam 2890844526 2890842807 IN IP4 192.0.2.5 CertificateRequest*
s=SRTP Discussion <-------- ServerHelloDone
i=A discussion of Secure RTP Certificate*
u=http://www.example.com/seminars/srtp.pdf ClientKeyExchange
e=marge@example.com (Marge Simpson) CertificateVerify*
c=IN IP4 192.0.2.12 [ChangeCipherSpec]
t=2873397496 2873404696 Finished -------->
m=audio 49170 UDP/TLS/RTP/SAVP 0 [ChangeCipherSpec]
a=fingerprint:SHA-1 <-------- Finished
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SRTP packets <-------> SRTP packets
a=dtls-srtp-ekt SRTP packets <-------> SRTP packets
a=dtls-srtp-host:IN IP4 192.0.2.13 56789 ekt_key -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
For legibility the SDP shows line breaks that are not present on the Figure 8: Handshake Message Flow
wire.
4.2. Offer/Answer Considerations 4.3. Offer/Answer Considerations
This section describes Offer/Answer considerations for the use of EKT This section describes Offer/Answer considerations for the use of EKT
together with DTLS-SRTP for unicast and multicast streams. The together with DTLS-SRTP for unicast and multicast streams. The
offerer and answerer MUST follow the procedures specified in offerer and answerer MUST follow the procedures specified in
[RFC5764] as well as the following ones. [RFC5764] as well as the following ones.
As most DTLS-SRTP processing is performed on the media channel, As most DTLS-SRTP processing is performed on the media channel,
rather than in SDP, there is little processing performed in SDP other rather than in SDP, there is little processing performed in SDP other
than informational and to redirect DTLS-SRTP to an alternate host. than informational and to redirect DTLS-SRTP to an alternate host.
Advertising support for the extension is necessary in SDP because in Advertising support for the extension is necessary in SDP because in
some cases it is required to establish an SRTP call. For example, a some cases it is required to establish an SRTP call. For example, a
mixer may be able to only support SRTP listeners if those listeners mixer may be able to only support SRTP listeners if those listeners
implement DTLS Key Transport (because it lacks the CPU cycles implement DTLS Key Transport (because it lacks the CPU cycles
necessary to encrypt SRTP uniquely for each listener). necessary to encrypt SRTP uniquely for each listener).
4.2.1. Generating the Initial Offer 4.3.1. Generating the Initial Offer
The initial offer contains a new SDP attribute, "dtls-srtp-ekt", The initial offer contains a new SDP attribute, "dtls-srtp-ekt",
which contains no value. This indicates the offerer is capable of which contains no value. This attribute MUST only appear at the
media level. This attribute indicates the offerer is capable of
supporting DTLS-SRTP with EKT extensions, and indicates the desire to supporting DTLS-SRTP with EKT extensions, and indicates the desire to
use the "ekt" extension during the DTLS-SRTP handshake. If the use the "ekt" extension during the DTLS-SRTP handshake.
offerer wants another host to perform DTLS-SRTP-EKT processing, it
also includes the dtls-srtp-host attribute in its offer
(Section 4.1).
An example of SDP containing the dtls-srtp-ekt attribute:: An example of SDP containing the dtls-srtp-ekt attribute::
v=0 v=0
o=sam 2890844526 2890842807 IN IP4 192.0.2.5 o=sam 2890844526 2890842807 IN IP4 192.0.2.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson) e=marge@example.com (Marge Simpson)
c=IN IP4 192.0.2.12 c=IN IP4 192.0.2.12
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 49170 UDP/TLS/RTP/SAVP 0 m=audio 49170 UDP/TLS/RTP/SAVP 0
a=fingerprint:SHA-1 a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=dtls-srtp-ekt a=dtls-srtp-ekt
For legibility the SDP shows line breaks that are not present on the For legibility the SDP shows line breaks that are not present on the
wire. wire.
4.2.2. Generating the Initial Answer 4.3.2. Generating the Initial Answer
Upon receiving the initial offer, the presence of the dtls-srtp-ekt Upon receiving the initial offer, the presence of the dtls-srtp-ekt
attribute indicates a desire to receive the EKT extension in the attribute indicates a desire to receive the EKT extension in the
DTLS-SRTP handshake. The presence of the dtls-srtp-host attribute DTLS-SRTP handshake. DTLS messages should be constructed according
indicates an alternate host to send the DTLS-SRTP handshake (instead to those two attributes.
of the host on the c/m lines). DTLS messages should be constructed
according to those two attributes.
The SDP answer SHOULD contain the dtls-srtp-ekt attribute to indicate If the answerer does not wish to perform EKT, it MUST NOT include a
the answerer understands dtls-srtp. It should only contain the dtls- =dtls-srtp-ekt in the SDP answer, and it MUST NOT negotiate EKT
srtp-host attribute if the answerer also wishes to offload its DTLS- during its DTLS-SRTP exchange.
SRTP processing to another host.
4.2.3. Processing the Initial Answer Otherwise, the dtls-srtp-ekt attribute SHOULD be included in the
answer, and EKT SHOULD be negotiated in the DTLS-SRTP handshake.
4.3.3. Processing the Initial Answer
The presence of the dtls-srtp-ekt attribute indicates a desire by the The presence of the dtls-srtp-ekt attribute indicates a desire by the
answerer to perform DTLS-SRTP with EKT extensions, and the dtls-srtp- answerer to perform DTLS-SRTP with EKT extensions. There are two
host attribute indicates an alternate host for DTLS-SRTP processing. indications the remote peer does not want to do EKT: the dtls-srtp-
ekt attribute is not present in the answer, or the DTLS-SRTP exchange
fails to negotiate the EKT extension. If the dtls-srtp-ekt attribute
is not present in the answer, the DTLS-SRTP exchange MUST NOT attempt
to negotiate the EKT extension. If the dtls-srtp-ekt attribute is
present in the answer but the DTLS-SRTP exchange fails to negotiate
the EKT extension, EKT MUST NOT be used with that media stream.
After successful negotiation of the key_transport extension, the DTLS After successful DTLS negotiation of the EKT extension, the DTLS
client and server MAY exchange SRTP packets, encrypted using the KDF client and server MAY exchange SRTP packets, encrypted using the KDF
described in [RFC5764]. This is normal and expected, even if Key described in [RFC5764]. This is normal and expected, even if Key
Transport was negotiated by both sides, as neither side may (yet) Transport was negotiated by both sides, as neither side may (yet)
have a need to alter the SRTP key. However, it is also possible that have a need to alter the SRTP key. However, it is also possible that
one (or both) peers will immediately send new_srtp_key message before one (or both) peers will immediately send an EKT packet before
sending any SRTP, and also possible that SRTP, encrypted with an sending any SRTP, and also possible that SRTP, encrypted with an
unknown key, may be received before the new_srtp_key message is unknown key, may be received before the EKT packet is received.
received.
4.2.4. Modifying the Session 4.3.4. Sending DTLS EKT Key Reliably
In the absence of a round trip time estimate, the DTLS ekt_key
message is sent using an exponential backoff initialized to 250ms, so
that if the first message is sent at time 0, the next transmissions
are at 250ms, 500ms, 1000ms, and so on. If a recent round trip time
estimate is available, exponential backoff is used with the first
transmission at 1.5 times the round trip time estimate. In either
case, re-transmission stops when ekt_key_ack or ekt_key_error message
is received for the matching message_seq.
4.3.5. Modifying the Session
As DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel (media As DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel (media
channel) rather than signaling, no special processing for modifying channel) rather than signaling, no special processing for modifying
the session is necessary. the session is necessary.
If the initial offer and initial answer both contained EKT attributes
(indicating the answerer desired to perform EKT), a subsequent offer/
answer exchange MUST also contain those same EKT attributes. If not,
operation is undefined and the sesion MAY be terminated. If the
initial offer and answer failed to negotiate EKT (that is, the answer
did not contain EKT attributes), EKT negotiation failed and a
subsequent offer SHOULD NOT include EKT attributes.
5. Use of EKT with MIKEY 5. Use of EKT with MIKEY
The advantages outlined in Section 1 are useful in some scenarios in The advantages outlined in Section 1 are useful in some scenarios in
which MIKEY is used to establish SRTP sessions. In this section, we which MIKEY is used to establish SRTP sessions. In this section, we
briefly review MIKEY and related work, and discuss these scenarios. briefly review MIKEY and related work, and discuss these scenarios.
An SRTP sender or a group controller can use MIKEY to establish a An SRTP sender or a group controller can use MIKEY to establish a
SRTP cryptographic context. This capability includes the SRTP cryptographic context. This capability includes the
distribution of a TEK generation key (TGK) or the TEK itself, distribution of a TEK generation key (TGK) or the TEK itself,
security policy payload, crypto session bundle ID (CSB_ID) and a security policy payload, crypto session bundle ID (CSB_ID) and a
skipping to change at page 33, line 46 skipping to change at page 30, line 26
MIKEY initiator and responder. The SSRC / ROC value pair is part of MIKEY initiator and responder. The SSRC / ROC value pair is part of
the MIKEY Common Header payload. This allows providing the current the MIKEY Common Header payload. This allows providing the current
ROC value to late joiners of a session. However, in some scenarios a ROC value to late joiners of a session. However, in some scenarios a
key management based ROC synchronization is not sufficient. For key management based ROC synchronization is not sufficient. For
example, in mobile and wireless environments, members may go in and example, in mobile and wireless environments, members may go in and
out of coverage and may miss a sequence number overrun. In point-to- out of coverage and may miss a sequence number overrun. In point-to-
multipoint translator scenarios it is desirable to not require the multipoint translator scenarios it is desirable to not require the
group controller to track the ROC values of each member, but to group controller to track the ROC values of each member, but to
provide the ROC value by the originator of the SRTP packet. A better provide the ROC value by the originator of the SRTP packet. A better
alternative to synchronize the ROC values is to send them directly alternative to synchronize the ROC values is to send them directly
via SRTP/SRTCP, as EKT does. A separate SRTP extension is being via SRTP/SRTCP as EKT does. A separate SRTP extension [RFC4771]
proposed [RFC4771] to include the ROC as part of a modified includes the ROC in a modified authentication tag but that extension
authentication tag. Unlike EKT, this extension uses only SRTP and does not support updating the SRTP master key.
not SRTCP as its transport and does not allow updating the SRTP
master key.
Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP
streams. Each sender of a stream sends the associated SSRC within streams. Each sender of a stream sends the associated SSRC within
the MIKEY message to the other party. If a SRTP session participant the MIKEY message to the other party. If an SRTP session participant
starts a new SRTP source or a new participant is added to a group, starts a new SRTP source (SSRC) or a new participant is added to a
subsequent SDP offer/answer and MIKEY exchanges are necessary to group, subsequent SDP offer/answer and MIKEY exchanges are necessary
update the SSRC values. EKT improves these scenarios by updating the to update the SSRC values. EKT improves these scenarios by updating
keys and SSRC values without coordination on the signaling channel. the keys and SSRC values without coordination on the signaling
With EKT, SRTP can handle early media, since the EKT SPI allows the channel. With EKT, SRTP can handle early media, since the EKT SPI
receiver to identify the cryptographic keys and parameters used by allows the receiver to identify the cryptographic keys and parameters
the source. used by the source.
The MIKEY specification [RFC3830] suggests the use of unicast for The MIKEY specification [RFC3830] suggests the use of unicast for
rekeying. This method does not scale well to large groups or rekeying. This method does not scale well to large groups or
interactive groups. The EKT extension of SRTP/SRTCP provides a interactive groups. The EKT extension of SRTP/SRTCP provides a
solution for rekeying the SRTP master key and for ROC/SSRC solution for rekeying the SRTP master key and for ROC/SSRC
synchronization. EKT is not a substitution for MIKEY, but rather a synchronization. EKT is not a substitution for MIKEY, but rather a
complementary addition to address the above described limitations of complementary addition to address the above described limitations of
MIKEY. MIKEY.
In the next section we provide an extension to MIKEY for support of In the next section we provide an extension to MIKEY for support of
skipping to change at page 34, line 37 skipping to change at page 31, line 16
Additional MIKEY modes specified in separate documents are not Additional MIKEY modes specified in separate documents are not
considered for EKT. considered for EKT.
5.1. EKT extensions to MIKEY 5.1. EKT extensions to MIKEY
In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI
must be negotiated in the MIKEY message exchange. must be negotiated in the MIKEY message exchange.
For EKT we specify a new SRTP Policy Type in the Security Policy (SP) For EKT we specify a new SRTP Policy Type in the Security Policy (SP)
payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload
contains a set of policies. Each policy consists of a number Policy contains a set of policies. Each policy consists of a number of
Param TLVs. Policy Param TLVs.
Prot type | Value
-------------------
EKT | TBD (will be requested from IANA)
For legibility the SDP shows line breaks that are not present on the Prot type | Value
wire. -------------------
EKT | TBD (will be assigned by IANA) NOTE TO RFC EDITOR
Figure 8: EKT Security Policy Figure 9: EKT Security Policy
The EKT Security Policy has one parameter representing the EKT The EKT Security Policy has one parameter representing the EKT
cipher. cipher.
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------- ----------------------------------------------------
0 | EKT cipher | see below 0 | EKT cipher | see below
Figure 9: EKT Security Policy Parameters
EKT cipher | Value Figure 10: EKT Security Policy Parameters
-------------------
AES_128 | 0
AESKW_128 | 1
AESKW_192 | 2
AESKW_256 | 3
Figure 10: EKT Cipher Parameters EKT cipher | Value
-------------------
(reserved) | 0
AESKW_128 | 1
AESKW_192 | 2
AESKW_256 | 3
AES_128 is the default value for the EKT cipher. Figure 11: EKT Cipher Parameters
The two mandatory EKT parameters (EKT_Key and EKT_SPI) are The two mandatory EKT parameters (EKT_Key and EKT_SPI) are
transported in the MIKEY KEMAC payload within one separate Key Data transported in the MIKEY KEMAC payload within one separate Key Data
sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC
payload carries the TEK Generation Key (TGK) or the Traffic payload carries the TEK Generation Key (TGK) or the Traffic
Encryption Key (TEK). One or more TGKs or TEKs are carried in Encryption Key (TEK). One or more TGKs or TEKs are carried in
individual Key Data sub-payloads within the KEMAC payload. The KEMAC individual Key Data sub-payloads within the KEMAC payload. The KEMAC
payload is encrypted as part of MIKEY. The Key Data sub- payload, payload is encrypted as part of MIKEY. The Key Data sub- payload,
specified in Section 6.13 of [RFC3830], has the following format: specified in Section 6.13 of [RFC3830], has the following format:
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | Type | KV | Key data length | | Next Payload | Type | KV | Key data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Key data : : Key data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Salt length (optional) ! Salt data (optional) : : Salt length (optional) ! Salt data (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: KV data (optional) : : KV data (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Key Data Sub-Payload of MIKEY Figure 12: Key Data Sub-Payload of MIKEY
These fields are described below: These fields are described below:
Type: 4 bits in length, indicates the type of key included in the Type: 4 bits in length, indicates the type of key included in the
payload. We define Type = TBD (will be requested from IANA) to payload. We define Type = TBD (will be requested from IANA [NOTE
indicate transport of the EKT key. TO RFC EDITOR]) to indicate transport of the EKT key.
KV: (4 bits): indicates the type of key validity period specified. KV: (4 bits): indicates the type of key validity period specified.
KV=1 is currently specified as an SPI. We use that value to KV=1 is currently specified as an SPI. We use that value to
indicate the KV_data contains the ETK_SPI for the key type indicate the KV data contains the EKT_SPI for the key type
EKT_Key. KV_data would be 16 bits in length, but it is also EKT_Key. KV data would be 16 bits in length, but it is also
possible to interpret the length from the 'Key data len' field. possible to interpret the length from the 'Key data len' field.
KV data MUST NOT be optional for the key type EKT_Key when KV = 1. KV data MUST be present for the key type EKT_Key when KV=1.
Salt length, Salt Data: These optional fields SHOULD be omitted for Salt length, Salt Data: These optional fields SHOULD be omitted for
the key type EKT_Key, if the SRTP master salt is already present the key type EKT_Key, if the SRTP master salt is already present
in the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload in the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload
MUST contain a SRTP master salt, if the SRTP master salt is not MUST contain a SRTP master salt, if the SRTP master salt is not
already present in the TGK or TEK Key Data sub-payload. already present in the TGK or TEK Key Data sub-payload.
KV Data: length determined by Key Data Length field. KV Data: length determined by Key Data Length field.
5.2. Offer/Answer considerations 5.2. Offer/Answer considerations
skipping to change at page 36, line 42 skipping to change at page 33, line 13
can be used on session or media level. On session level, MIKEY can be used on session or media level. On session level, MIKEY
provides the keys for multiple SRTP sessions in the SDP offer. The provides the keys for multiple SRTP sessions in the SDP offer. The
EKT SPI references a EKT parameter set including the Secure RTP EKT SPI references a EKT parameter set including the Secure RTP
parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is
used on session level, it is only possible to use one EKT SPI value. used on session level, it is only possible to use one EKT SPI value.
Therefore, the session-level MIKEY message MUST contain one SRTP Therefore, the session-level MIKEY message MUST contain one SRTP
Security Policy payload only, which is valid for all related SRTP Security Policy payload only, which is valid for all related SRTP
media lines. If MIKEY is used on media level, different SRTP media lines. If MIKEY is used on media level, different SRTP
Security Policy parameters (and consequently different EKT SPI Security Policy parameters (and consequently different EKT SPI
values) can be used for each media line. If MIKEY is used on session values) can be used for each media line. If MIKEY is used on session
and media level, the medial level content overrides the session level and media level, the media level content overrides the session level
content. content.
EKT requires a single shared SRTP master salt between all EKT requires a single shared SRTP master salt between all
participants in the direct SRTP session. If a MIKEY key-mgmt participants in the direct SRTP session. If a MIKEY key-mgmt
attribute contains more than one TGK or TEK Key Data sub-payload, all attribute contains more than one TGK or TEK Key Data sub-payload, all
the sub-payloads MUST contain the same master salt value. the sub-payloads MUST contain the same master salt value.
Consequently, the EKT_Key Key Data sub-payload MAY also contain the Consequently, the EKT_Key Key Data sub-payload MAY also contain the
same salt or MAY omit the salt value. If the SRTP master salt is not same salt or MAY omit the salt value. If the SRTP master salt is not
present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub- present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub-
payload MUST contain a master salt. payload MUST contain a master salt.
5.2.2. Generating the Initial Answer 5.2.2. Generating the Initial Answer
For each media line in the offer using MIKEY, provided on session or/ For each media line in the offer using MIKEY, provided on session and
and on media level, the answerer examines the related MIKEY key-mgmt /or on media level, the answerer examines the related MIKEY key-mgmt
attributes for the presence of EKT parameters. In order to accept attributes for the presence of EKT parameters. In order to accept
the offered key-mgmt attribute, the MIKEY message MUST contain one the offered key-mgmt attribute, the MIKEY message MUST contain one
EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy
payload. The answerer examines also the existence of a SRTP master payload. The answerer examines also the existence of a SRTP master
salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple
salts are available, all values MUST be equal. If the salt values salts are available, all values MUST be equal. If the salt values
differ or no salt is present, the key-mgmt attribute MUST be differ or no salt is present, the key-mgmt attribute MUST be
considered as invalid. considered as invalid.
The MIKEY responder message in the SDP answer does not contain a The MIKEY responder message in the SDP answer does not contain a
MIKEY KEMAC or Security Policy payload and consequently does not MIKEY KEMAC or Security Policy payload and consequently does not
contain any EKT parameters. If the key-mgmt attribute for a media contain any EKT parameters. If a key-mgmt attribute for a media line
line was accepted by the answerer, the EKT parameter set of the was accepted by the answerer, the EKT parameter set of the offerer is
offerer is valid for both directions of the SRTP session. valid for both directions of the SRTP session.
5.2.3. Processing the Initial Answer 5.2.3. Processing the Initial Answer
On reception of the answer, the offerer examines if EKT has been On reception of the answer, the offerer examines if EKT has been
accepted for the offered media lines. If a MIKEY key-mgmt attribute accepted for the offered media lines. If a MIKEY key-mgmt attribute
is received containing a valid MIKEY responder message, EKT has been is received containing a valid MIKEY responder message, EKT has been
successfully negotiated. On receipt of a MIKEY error message, EKT successfully negotiated. On receipt of a MIKEY error message, EKT
negotiation has failed. For example, this may happen if an EKT negotiation has failed. For example, this may happen if an EKT
extended MIKEY initiator message is sent to a MIKEY entity not extended MIKEY initiator message is sent to a MIKEY entity not
supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is
returned to indicate that the EKT_Cipher Security Policy payload or returned to indicate that the EKT_Cipher Security Policy payload or
the EKT_Key sub-payload is not supported. In this case, the offerer the EKT_Key sub-payload is not supported. In this case, the offerer
may send a second SDP offer with a MIKEY key-mgmt attribute without may send a second SDP offer with a MIKEY key-mgmt attribute without
the additional EKT extensions. the additional EKT extensions.
This behavior can be improved by defining an additional key-mgmt This behavior can be improved by defining an additional key-mgmt
prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes.
One attribute offers MIKEY together with EKT and the other one offers One attribute offers MIKEY with SRTP and EKT and the other attribute
MIKEY without EKT. This is for further discussion. offers MIKEY with SRTP without EKT.
5.2.4. Modifying the Session 5.2.4. Modifying the Session
Once a SRTP stream has been established, a new offer/answer exchange Once an SRTP stream has been established, a new offer/answer exchange
can modify the session including the EKT parameters. If the EKT key can modify the session including the EKT parameters. If the EKT key
or EKT cipher is modified (i.e., a new EKT parameter set is created) or EKT cipher is modified (i.e., a new EKT parameter set is created)
the offerer MUST also provide a new EKT SPI value. The offerer MUST the offerer MUST also provide a new EKT SPI value. The offerer MUST
NOT remap an existing EKT SPI value to a new EKT parameter set. NOT remap an existing EKT SPI value to a new EKT parameter set.
Similar, a modification of the SRTP Security Policy leads to a new Similar, a modification of the SRTP Security Policy leads to a new
EKT parameter set and requires a fresh EKT SPI, even the EKT key or EKT parameter set and requires a fresh EKT SPI, even if the EKT key
cipher did not change. or cipher did not change.
Once EKT is being used, the SRTP master salt for the SRTP session Once EKT is being used, the SRTP master salt for the SRTP session
MUST NOT be changed. The salt in the Key Data sub-payloads within MUST NOT be changed. The salt in the Key Data sub-payloads within
the subsequent offers MUST be the same as the one already used. the subsequent offers MUST be the same as the one already used.
After EKT has been successfully negotiated for a session and a SRTP After EKT has been successfully negotiated for a session and an SRTP
master key has been transported by EKT, it is difficult to switch master key has been transported by EKT, it is difficult to switch
back to a pure MIKEY based key exchange in a synchronized way. back to a pure MIKEY based key exchange in a synchronized way.
Therefore, once EKT is being used for a session, EKT MUST be used Therefore, once EKT is being used for a session, EKT MUST be used
also in all subsequent offer/answer exchanges for that session. also in all subsequent offer/answer exchanges for that session.
6. Using EKT for interoperability between key management systems 6. Using EKT for interoperability between key management systems
A media gateway (MGW) can provide interoperability between an SRTP- A media gateway (MGW) can provide interoperability between an SRTP-
EKT endpoint and a non-EKT SRTP endpoint. When doing this function, EKT endpoint and a non-EKT SRTP endpoint. When doing this function,
the MGW can perform non-cryptographic transformations on SRTP packets the MGW can perform non-cryptographic transformations on SRTP packets
outlined above. However, there are some uses of cryptography that outlined above. However, there are some uses of cryptography that
will be required for that gateway. If a new SRTP master key is will be required for that gateway. If a new SRTP master key is
communicated to the MGW (via EKT from the EKT leg, or via Security communicated to the MGW (via EKT from the EKT leg, or via Security
Descriptions from the Security Descriptions leg), the MGW needs to Descriptions without EKT from the Security Descriptions leg), the MGW
convert that information for the other leg, and that process will needs to convert that information for the other leg, and that process
incur some cryptographic operations. Specifically, if the new key will incur some cryptographic operations. Specifically, if the new
arrived via EKT, that must be decrypted and then sent in Security key arrived via EKT, the key must be decrypted and then sent in
Descriptions; likewise, if a new key arrives via Security Security Descriptions (e.g., as a SIP re-INVITE); likewise, if a new
Descriptions that must be encrypted via EKT and sent in SRTP/SRTCP. key arrives via Security Descriptions that must be encrypted via EKT
and sent in SRTP/SRTCP.
Additional non-normative information can be found in Appendix A. Additional non-normative information can be found in Appendix A.
7. Design Rationale 7. Design Rationale
From [RFC3550], a primary function of RTCP is to carry the CNAME, a From [RFC3550], a primary function of RTCP is to carry the CNAME, a
"persistent transport-level identifier for an RTP source" since "persistent transport-level identifier for an RTP source" since
"receivers require the CNAME to keep track of each participant." EKT "receivers require the CNAME to keep track of each participant." EKT
works in much the same way, using SRTCP to carry information needed works in much the same way but uses SRTP to carry information needed
for the proper processing of the SRTP traffic. for the proper processing of the SRTP traffic.
With EKT, SRTP gains the ability to synchronize the creation of With EKT, SRTP gains the ability to synchronize the creation of
cryptographic contexts across all of the participants in a single cryptographic contexts across all of the participants in a single
session. This feature provides some, but not all, of the session. This feature provides some, but not all, of the
functionality that is present in IKE phase two (but not phase one). functionality that is present in IKE phase two (but not phase one).
Importantly, EKT does not provide a way to indicate SRTP options. Importantly, EKT does not provide a way to indicate SRTP options.
With EKT, external signaling mechanisms provide the SRTP options and With EKT, external signaling mechanisms provide the SRTP options and
the EKT Key, but need not provide the key(s) for each individual SRTP the EKT Key, but need not provide the key(s) for each individual SRTP
source. EKT provides a separation between the signaling mechanisms source. EKT provides a separation between the signaling mechanisms
and the details of SRTP. The signaling system need not coordinate and the details of SRTP. The signaling system need not coordinate
all SRTP streams, nor predict in advance how many streams will be all SRTP streams, nor predict in advance how many sources will be
present, nor communicate SRTP-level information (e.g., rollover present, nor communicate SRTP-level information (e.g., rollover
counters) of current sessions. counters) of current sessions.
EKT is especially useful for multi-party sessions, and for the case EKT is especially useful for multi-party sessions, and for the case
where multiple RTP sessions are sent to the same destination where multiple RTP sessions are sent to the same destination
transport address (see the example in the definition of "RTP session" transport address (see the example in the definition of "RTP session"
in [RFC3550]). A SIP offer that is forked in parallel (sent to in [RFC3550]). A SIP offer that is forked in parallel (sent to
multiple endpoints at the same time) can cause multiple RTP sessions multiple endpoints at the same time) can cause multiple RTP sessions
to be sent to the same transport address, making EKT useful for use to be sent to the same transport address, making EKT useful for use
with SIP. with SIP.
EKT can also be used in conjunction with a scalable group-key EKT can also be used in conjunction with a scalable group-key
management system like GDOI [RFC6407]. Such a system provides a management system like GDOI [RFC6407]. In such a combination GDOI
secure entity authentication method and a way to revoke group would provide a secure entity authentication method for group
membership, both of which are out of scope of EKT. members, and a scalable way to revoke group membership; by itself,
EKT does not attempt to provide either capability.
It is natural to use SRTCP to transport encrypted keying material for
SRTP, as it provides a secure control channel for (S)RTP. However,
there are several different places in SRTCP in which the encrypted
SRTP master key and ROC could be conveyed. We briefly review some of
the alternatives in order to motivate the particular choice used in
this specification. One alternative is to have those values carried
as a new SDESC item or RTCP packet. This would require that the
normal SRTCP encryption be turned off for the packets containing that
SDESC item, since on the receiver's side, SRTCP processing completes
before the RTCP processing starts. This tension between encryption
and the desire for RTCP privacy is highly undesirable. Additionally,
this alternative makes SRTCP dependent upon the parsing of the RTCP
compound packet, which adds complexity. It is simpler to carry the
encrypted key in a new SRTCP field. One way to do this and to be
backwards compatible with the existing specification is to define a
new crypto function that incorporates the encrypted key. We define a
new authentication transform because EKT relies on the normal SRTCP
authentication to provide implicit authentication of the encrypted
key.
An SRTP packet containing an SSRC that has not been seen will be EKT carries the encrypted key in a new SRTP field (at the end of the
discarded. This practice may induce a burst of packet loss at the SRTP packet). This maintains compatibility with the existing SRTP
outset of an SRTP stream, due to the loss or reorder of the first specification by defining a new crypto function that incorporates the
SRTCP packet with the EKT containing the key and rollover counter for encrypted key, and a new authentication transform to provide implicit
that stream. However, this practice matches the conservative RTP authentication of the encrypted key.
memory-allocation strategy; many existing applications accept this
risk of initial packet loss. Alternatively, implementations may wish
to delay discarding such packets for a short period of time as
described in Section 2.4.
The main motivation for the use of the variable-length format is The main motivation for the use of the variable-length EKT format is
bandwidth conservation. If EKT is used of SRTP, there will be a loss bandwidth conservation. When EKT is sent over SRTP, there will be a
of bandwidth due to the additional 24 bytes in each RTP packet. For loss of (usable) bandwidth due to the additional EKT bytes in each
some applications, this bandwidth loss is significant. RTP packet. For some applications, this bandwidth loss is
significant.
7.1. Alternatives 7.1. Alternatives
In its current design, EKT requires that the Master Salt be In its current design, EKT requires that the Master Salt be
established out of band. That requirement is undesirable. In an established out of band. That requirement is undesirable. In an
offer/answer environment, it forces the answerer to re-use the same offer/answer environment, it forces the answerer to re-use the same
Master Salt value used by the offerer. The Master Salt value could Master Salt value used by the offerer. The Master Salt value could
be carried in EKT packets though that would consume yet more be carried in EKT packets though that would consume yet more
bandwidth. bandwidth.
In some scenarios, two SRTP sessions may be combined into a single In some scenarios, two SRTP sessions may be combined into a single
session. When using EKT in such sessions, it is desirable to have an session. When using EKT in such sessions, it is desirable to have an
SPI value that is larger than 15 bits, so that collisions between SPI SPI value that is larger than 15 bits, so that collisions between SPI
values in use in the two different sessions are unlikely (since each values in use in the two different sessions are unlikely (since each
collision would confuse the members of one of the sessions.) collision would confuse the members of one of the sessions).
An alternative that addresses both of these needs is as follows: the An alternative that addresses both of these needs is as follows: the
SPI value can be lengthed from 15 bits to 63 bits, and the Master SPI value can be lengthed from 15 bits to 63 bits, and the Master
Salt can be identical to, or constructed from, the SPI value. SRTP Salt can be identical to, or constructed from, the SPI value. SRTP
conventionally uses a 14-byte Master Salt, but shorter values are conventionally uses a 14-byte Master Salt, but shorter values are
acceptable. This alternative would add six bytes to each EKT packet; acceptable. This alternative would add six bytes to each EKT packet;
that overhead may be a reasonable tradeoff for addressing the that overhead may be a reasonable tradeoff for addressing the
problems outlined above. problems outlined above. This is considered too high a bandwidth
penalty.
8. Security Considerations 8. Security Considerations
With EKT, each SRTP sender and receiver can generate distinct SRTP EKT inherits the security properties of the SRTP keying it uses:
Security Descriptions, DTLS-SRTP, or MIKEY.
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 provides complete security, even in the absence of However, EKT remains secure even in the absence of out-of-band
further out-of-band coordination of SSRCs, and even when SSRC values coordination of SSRCs, and even when SSRC values collide.
collide.
In order to avoid potential security issues, the SRTP authentication The EKT Cipher includes its own authentication/integrity check. For
tag length used by the base authentication method MUST be at least an attacker to successfully forge a full EKT packet, it would need to
ten octets. defeat the authentication mechanisms of both the EKT Cipher and the
SRTP authentication mechanism.
The presence of the SSRC in the EKT_Plaintext ensures that an The presence of the SSRC in the EKT_Plaintext ensures that an
attacker cannot substitute an EKT_Ciphertext from one SRTP stream attacker cannot substitute an EKT_Ciphertext from one SRTP stream
into another SRTP stream, even if those two streams are using the into another SRTP stream.
same SRTP master key. This is important because some applications
may use the same master key for multiple streams.
An attacker who strips a Full_EKT_Field from an SRTP packet may An attacker who strips a Full_EKT_Field from an SRTP packet may
prevent the intended receiver of that packet from being able to prevent the intended receiver of that packet from being able to
decrypt it. This is a minor denail of service vulnerability. decrypt it. This is a minor denial of service vulnerability.
Similarly, an attacker who adds a Full_EKT_Field can disrupt service. Similarly, an attacker who adds a Full_EKT_Field can disrupt service.
An attacker could send packets containing either Short EKT Tag or An attacker could send packets containing either Short EKT Field or
Full EKT Tag, in an attempt to consume additional CPU resources of Full EKT Field, in an attempt to consume additional CPU resources of
the receiving system. In the case of the Short EKT Tag, this field the receiving system. In the case of the Short EKT Field, this field
is stripped and normal SRTP or SRTCP processing is performed. In the is stripped and normal SRTP or SRTCP processing is performed. In the
case of the Full EKT Tag, the attacker would have to have guessed or case of the Full EKT Field, the attacker would have to have guessed
otherwise determined the SPI being used by the receiving system. If or otherwise determined the SPI being used by the receiving system.
an invalid SPI is provided by the attacker, processing stops. If a If an invalid SPI is provided by the attacker, processing stops. If
valid SPI is provided by the attacker, the receiving system will a valid SPI is provided by the attacker, the receiving system will
decrypt the EKT ciphertext and return an authentication failure (Step decrypt the EKT ciphertext and return an authentication failure (Step
3 of Section 2.2.2). 3 of Section 2.2.2).
An attacker learns from EKT when SRTP Master Keys change. EKT can rekey an SRTP stream until the SRTP rollover counter (ROC)
needs to roll over. EKT does not extend SRTP's rollover counter
(ROC), and like SRTP itself EKT cannot properly handle a ROC
rollover. Thus even if using EKT, new (master or session) keys need
to be established after 2^48 packets are transmitted in a single SRTP
stream as described in Section 3.3.1 of [RFC3711]. Due to the
relatively low packet rates of typical RTP sessions, this is not
expected to be a burden.
The EKT Cipher MUST be at least as strong as the encryption and The confidentiality, integrity, and authentication of the EKT cipher
authentication operations used in SRTP. MUST be at least as strong as the SRTP cipher.
Part of the EKT_Plaintext is known, or easily guessable to an Part of the EKT_Plaintext 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. For each randomly chosen key, plaintexts can be adaptively chosen. An EKT cipher MUST resist
the encryption and decryption functions cannot be distinguished from attacks in which both ciphertexts and plaintexts can be adaptively
a random permutation and its inverse with non-negligible advantage. chosen and adversaries that can query both the encryption and
This must be true even for adversaries that can query both the decryption functions adaptively.
encryption and decryption functions adaptively. The advantage is
defined as the difference between the probability that the adversary
will identify the cipher as such and the probability that the
adversary will identify the random permutation as the cipher, when
each case is equally likely.
9. IANA Considerations 9. IANA Considerations
IANA is requested to register EKT from Section 3.9 into the Session
Description Protocol (SDP) Security Descriptions [iana-sdp-sdesc]
registry for "SRTP Session Parameters".
IANA is requested to register EKT into the SRTP Session Parameter IANA is requested to register the following new attributes into the
registry [iana-sdp-sdesc]. SDP Attributes registry [iana-sdp-attr].
IANA is requested to register dtls-srtp-ekt and dtls-srtp-host into Attribute name: dtls-srtp-ekt
the att-field table of the SDP Attributes registry [iana-sdp-attr].
We request the following IANA assignments from existing MIKEY IANA Long form name: DTLS-SRTP with EKT
tables:
Type of attribute: Media-level
Subject to charset: No
Purpose: Indicates support for DTLS-SRTP with EKT
Appropriate values: No values
Contact name: Dan Wing, dwing@cisco.com
We request the following IANA assignments from the existing
[iana-mikey] name spaces in the IETF consensus range (0-240)
[RFC3830]:
o From the Key Data payload name spaces, a value to indicate the o From the Key Data payload name spaces, a value to indicate the
type as the 'EKT_Key'. type as the 'EKT_Key'.
o From the Security Policy table name space, a new value to be o From the Security Policy table name space, a new value to be
assigned for 'EKT' (see Figure 8). assigned for 'EKT' (see Figure 9).
Furthermore, we need the following two new IANA registries created, Furthermore, we need the following two new IANA registries created,
populated with the initial values in this document. New values for populated with the initial values in this document. New values for
both of these registries can be defined via Specification Required both of these registries can be defined via Specification Required
[RFC5226]. [RFC5226].
o EKT parameter type (initially populated with the list from o EKT parameter type, initially populated with the list from Figure
Figure 9) 10
o EKT cipher (initially populated with the list from Figure 10) o EKT cipher, initially populated with the list from Figure 11
10. Acknowledgements 10. Acknowledgements
Thanks to Lakshminath Dondeti for assistance with earlier versions of Thanks to Lakshminath Dondeti for assistance with earlier versions of
this document. Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond this document. Thanks to Kai Fischer for writing the MIKEY section.
for fruitful discussions and comments. Thanks to Romain Biehlmann
for his encouragement to add support DTLS-SRTP-EKT key servers for Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond for fruitful
multicast. Thanks to Felix Wyss for his review and comments discussions and comments. Thanks to Felix Wyss for his review and
regarding ciphers. comments regarding ciphers. Thanks to Michael Peck for his review.
Thanks to John Mattsson for his detailed security review highlighting
the duplicative interaction between SRTP MKI with EKT ISN and
encourged the EKT specification to prohibit sharing SRTP master keys.
Thanks to Magnus Westerlund for his review.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal [FIPS197] National Institute of Standards and Technology (NIST),
Information Processing Standard. "The Advanced Encryption Standard (AES)", FIPS-197 Federal
Information Processing Standard, November 2001.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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, June
June 2002. 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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, March 2004. RFC 3711, March 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
Information Type for the General Extension Payload in Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
11.2. Informative References 11.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[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,
September 2009. September 2009.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011. of Interpretation", RFC 6407, October 2011.
[iana-mikey]
IANA, ., "Multimedia Internet KEYing (Mikey) Payload Name
Spaces", 2011, <http://www.iana.org/assignments/mikey-
payloads/mikey-payloads.xhtml>.
[iana-sdp-attr] [iana-sdp-attr]
IANA, "SDP Parameters", 2011, <http://www.iana.org/ IANA, ., "SDP Parameters", 2011, <http://www.iana.org/
assignments/sdp-parameters/sdp-parameters.xml>. assignments/sdp-parameters/sdp-parameters.xml>.
[iana-sdp-sdesc] [iana-sdp-sdesc]
IANA, "SDP Security Descriptions", 2011, <http:// IANA, ., "Session Description Protocol (SDP) Security
www.iana.org/assignments/sdp-security-descriptions/ Descriptions: SRTP Session Parameters", 2011, <http://
sdp-security-descriptions.xml>. www.iana.org/assignments/sdp-security-descriptions/sdp-
security-descriptions.xml#sdp-security-descriptions-4>.
Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security
Descriptions Descriptions
Today, SDP Security Descriptions [RFC4568] is used for distributing Today, SDP Security Descriptions [RFC4568] is used for distributing
SRTP keys in several different IP PBX systems and is expected to be SRTP keys in several different IP PBX systems. The IP PBX systems
used by 3GPP's Long Term Evolution (LTE). The IP PBX systems are are typically used within a single enterprise. A Session Border
typically used within a single enterprise, and LTE is used within the Controller is a reasonable solution to interwork between Security
confines of a mobile operator's network. A Session Border Controller Descriptions in one network and DTLS-SRTP in another network. For
is a reasonable solution to interwork between Security Descriptions example, a mobile operator (or an Enterprise) could operate Security
in one network and DTLS-SRTP in another network. For example, a
mobile operator (or an Enterprise) could operate Security
Descriptions within their network and DTLS-SRTP towards the Internet. Descriptions within their network and DTLS-SRTP towards the Internet.
However, due to the way Security Descriptions and DTLS-SRTP manage However, due to the way Security Descriptions and DTLS-SRTP manage
their SRTP keys, such an SBC has to authenticate, decrypt, re- their SRTP keys, such an SBC has to authenticate, decrypt, re-
encrypt, and re-authenticate the SRTP (and SRTCP) packets in one encrypt, and re-authenticate the SRTP (and SRTCP) packets in one
direction, as shown in Figure 12, below. This is computationally direction, as shown in Figure 13, below. This is computationally
expensive. expensive.
RFC4568 endpoint SBC DTLS-SRTP endpoint RFC4568 endpoint SBC DTLS-SRTP endpoint
| | | | | |
1. |---key=A------------->| | 1. |---key=A------------->| |
2. | |<-DTLS-SRTP handshake->| 2. | |<-DTLS-SRTP handshake->|
3. |<--key=B--------------| | 3. |<--key=B--------------| |
4. | |<--SRTP, encrypted w/B-| 4. | |<--SRTP, encrypted w/B-|
5. |<-SRTP, encrypted w/B-| | 5. |<-SRTP, encrypted w/B-| |
6. |-SRTP, encrypted w/A->| | 6. |-SRTP, encrypted w/A->| |
7. | (decrypt, re-encrypt) | 7. | (decrypt, re-encrypt) |
8. | |-SRTP, encrypted w/C-->| 8. | |-SRTP, encrypted w/C-->|
| | | | | |
Figure 12: Interworking Security Descriptions and DTLS-SRTP Figure 13: Interworking Security Descriptions and DTLS-SRTP
The message flow is as follows (similar steps occur with SRTCP): The message flow is as follows (similar steps occur with SRTCP):
1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP
key to the SBC, using a=crypto in its SDP. key to the SBC, using a=crypto in its SDP.
2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC
derives the SRTP key for traffic from the DTLS-SRTP endpoint (key derives the SRTP key for traffic from the DTLS-SRTP endpoint (key
B) and to the DTLS-SRTP endpoint (key C). B) and to the DTLS-SRTP endpoint (key C).
skipping to change at page 49, line 21 skipping to change at page 42, line 23
6. The Security Descriptions endpoint sends an SRTP packet, 6. The Security Descriptions endpoint sends an SRTP packet,
encrypted with its key A. encrypted with its key A.
7. The SBC has to authenticate and decrypt the SRTP packet (using 7. The SBC has to authenticate and decrypt the SRTP packet (using
key A), and re-encrypt it and generate an HMAC (using key C). key A), and re-encrypt it and generate an HMAC (using key C).
8. The SBC sends the new SRTP packet. 8. The SBC sends the new SRTP packet.
If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the
computationally expensive operation so the SBC does not need not computationally expensive operation so the SBC does not need to
perform any per-packet operations on the SRTP (or SRTCP) packets in perform any per-packet operations on the SRTP (or SRTCP) packets in
either direction. With EKT the SBC can simply forward the SRTP (and either direction. With EKT the SBC can simply forward the SRTP (and
SRTCP) packets in both directions without per-packet HMAC or SRTCP) packets in both directions without per-packet HMAC or
cryptographic operations. cryptographic operations.
To accomplish this interworking, DTLS-SRTP EKT must be supported on To accomplish this interworking, DTLS-SRTP EKT must be supported on
the DTLS-SRTP endpoint, which allows the SBC to transport the the DTLS-SRTP endpoint, which allows the SBC to transport the
Security Description key to the EKT endpoint and send the DTLS-SRTP Security Description key to the EKT endpoint and send the DTLS-SRTP
key to the Security Descriptions endpoint. This works equally well key to the Security Descriptions endpoint. This works equally well
for both incoming and outgoing calls. An abbreviated message flow is for both incoming and outgoing calls. An abbreviated message flow is
shown in Figure 13, below. shown in Figure 14, below.
RFC4568 endpoint SBC DTLS-SRTP endpoint RFC4568 endpoint SBC DTLS-SRTP endpoint
| | | | | |
1. |---key=A------------->| | 1. |---key=A------------->| |
2. | |<-DTLS-SRTP handshake->| 2. | |<-DTLS-SRTP handshake->|
3. |<--key=B--------------| | 3. |<--key=B--------------| |
4. | |--new_srtp_key:A------>| 4. | |--ekt:A--------------->|
5. | |<--SRTP, encrypted w/B-| 5. | |<--SRTP, encrypted w/B-|
5. |<-SRTP, encrypted w/B-| | 5. |<-SRTP, encrypted w/B-| |
6. |-SRTP, encrypted w/A->| | 6. |-SRTP, encrypted w/A->| |
7. | |-SRTP, encrypted w/A-->| 7. | |-SRTP, encrypted w/A-->|
| | | | | |
Figure 13: Interworking Security Descriptions and EKT Figure 14: Interworking Security Descriptions and EKT
The message flow is as follows (similar steps occur with SRTCP): The message flow is as follows (similar steps occur with SRTCP):
1. Security Descriptions endpoint discloses its SRTP key to the SBC 1. Security Descriptions endpoint discloses its SRTP key to the SBC
(a=crypto). (a=crypto).
2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC
derives the SRTP key for traffic from the DTLS-SRTP endpoint (key derives the SRTP key for traffic from the DTLS-SRTP endpoint (key
B) and to the DTLS-SRTP endpoint (key C). B) and to the DTLS-SRTP endpoint (key C).
3. The SBC communicates the SRTP encryption key (key B) to the 3. The SBC communicates the SRTP encryption key (key B) to the
Security Descriptions endpoint. Security Descriptions endpoint.
4. The SBC uses the EKT to indicate that SRTP packets will be 4. The SBC sends an EKT packet indicating that SRTP will be
encrypted with 'key A' towards the DTLS-SRTP endpoint. encrypted with 'key A' towards the DTLS-SRTP endpoint.
5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key
B. This is received by the SBC. B. This is received by the SBC.
6. The received SRTP packet is simply forwarded; the SBC does not 6. The received SRTP packet is simply forwarded; the SBC does not
need to do anything with this packet as its key (key B) was need to do anything with this packet as its key (key B) was
communicated in step 3. communicated in step 3.
7. The Security Descriptions endpoint sends an SRTP packet, 7. The Security Descriptions endpoint sends an SRTP packet,
skipping to change at page 51, line 17 skipping to change at page 43, line 44
David A. McGrew David A. McGrew
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
US US
Phone: (408) 525 8651 Phone: (408) 525 8651
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm URI: http://www.mindspring.com/~dmcgrew/dam.htm
Flemming Andreason
Cisco Systems, Inc.
499 Thornall Street
Edison, NJ 08837
US
Email: fandreas@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
US US
Phone: (408) 853 4197 Phone: (408) 853 4197
Email: dwing@cisco.com Email: dwing@cisco.com
Flemming Andreason
Cisco Systems, Inc.
499 Thornall Street
Edison, NJ 08837
US
Email: fandreas@cisco.com
 End of changes. 198 change blocks. 
870 lines changed or deleted 888 lines changed or added

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