draft-ietf-avtcore-srtp-ekt-02.txt   draft-ietf-avtcore-srtp-ekt-03.txt 
AVTCORE Working Group D. McGrew AVTCORE Working Group J. Mattsson, Ed.
Internet-Draft D. Wing Internet-Draft Ericsson
Intended status: Standards Track F. Andreasen Intended status: Standards Track D. McGrew
Expires: August 18, 2014 Cisco Expires: April 23, 2015 D. Wing
February 14, 2014 F. Andreasen
Cisco
October 20, 2014
Encrypted Key Transport for Secure RTP Encrypted Key Transport for Secure RTP
draft-ietf-avtcore-srtp-ekt-02 draft-ietf-avtcore-srtp-ekt-03
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. This SRTP master keys, Rollover Counters, and other information. This
facility enables SRTP to work for decentralized conferences with facility enables SRTP to work for decentralized 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
skipping to change at page 1, line 40 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 August 18, 2014. This Internet-Draft will expire on April 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions Used In This Document . . . . . . . . . . . . 5 1.2. Conventions Used In This Document . . . . . . . . . . . . 5
2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 5 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 5
2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5 2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 12 2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 13
2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13
2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Timing and Reliability Consideration . . . . . . . . . . 14 2.6. Timing and Reliability Consideration . . . . . . . . . . 15
3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 15 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 16
3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 15 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 16
3.2. Relationship between EKT and SDP Security Descriptions . 16 3.2. Relationship between EKT and SDESC . . . . . . . . . . . 17
3.3. Overview of Combined EKT and SDP Security Description 3.3. Overview of Combined EKT and SDESC Operation . . . . . . 19
Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 19
3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 18 3.5. Offer/Answer Considerations . . . . . . . . . . . . . . . 20
3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . 18 3.5.1. Generating the Initial Offer - Unicast Streams . . . 20
3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 19 3.5.2. Generating the Initial Answer - Unicast Streams . . . 21
3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 19 3.5.3. Processing of the Initial Answer - Unicast Streams . 22
3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 19 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . 23
3.5.1. Generating the Initial Offer - Unicast Streams . . . 19
3.5.2. Generating the Initial Answer - Unicast Streams . . . 20
3.5.3. Processing of the Initial Answer - Unicast Streams . 21
3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . 22
3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 23 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 23
3.8. Backwards Compatibility Considerations . . . . . . . . . 23 3.8. Backwards Compatibility Considerations . . . . . . . . . 24
3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 25 4. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 25
4.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 25 4.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 26
4.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 25 4.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 26
4.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 27 4.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 28
4.3.1. Generating the Initial Offer . . . . . . . . . . . . 27 4.3.1. Generating the Initial Offer . . . . . . . . . . . . 28
4.3.2. Generating the Initial Answer . . . . . . . . . . . . 28 4.3.2. Generating the Initial Answer . . . . . . . . . . . . 29
4.3.3. Processing the Initial Answer . . . . . . . . . . . . 28 4.3.3. Processing the Initial Answer . . . . . . . . . . . . 29
4.3.4. Sending DTLS EKT Key Reliably . . . . . . . . . . . . 29 4.3.4. Sending DTLS EKT Key Reliably . . . . . . . . . . . . 30
4.3.5. Modifying the Session . . . . . . . . . . . . . . . . 29 4.3.5. Modifying the Session . . . . . . . . . . . . . . . . 30
5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 29
5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 31 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 30
5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 32 5.1. EKT Extensions to MIKEY . . . . . . . . . . . . . . . . . 32
5.2.1. Generating the Initial Offer . . . . . . . . . . . . 32 5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 33
5.2.2. Generating the Initial Answer . . . . . . . . . . . . 33 5.2.1. Generating the Initial Offer . . . . . . . . . . . . 33
5.2.3. Processing the Initial Answer . . . . . . . . . . . . 33 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 34
5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 34 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 34
6. Using EKT for interoperability between key management systems 34 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 35
7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 35 6. Using EKT for Interoperability between Key Management Systems 35
7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 36 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with
Security Descriptions . . . . . . . . . . . . . . . 41 Security Descriptions . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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, that participant needs to be told the SRTP keys (and SSRC, progress, that participant needs to be told the SRTP keys (and SSRC,
skipping to change at page 5, line 7 skipping to change at page 5, line 7
A substantial change occurred between the EKT documents draft-ietf- A substantial change occurred between the EKT documents draft-ietf-
avt-srtp-ekt-03 and draft-ietf-avtcore-srtp-ekt-00. The change makes avt-srtp-ekt-03 and draft-ietf-avtcore-srtp-ekt-00. The change makes
it possible for the EKT data to be removed from a packet without it possible for the EKT data to be removed from a packet without
affecting the ability of the receiver to correctly process the data affecting the ability of the receiver to correctly process the data
that is present in that packet. This capability facilitates 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 makes 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 In draft-ietf-avtcore-srtp-ekt-02, SRTP master keys have to be always
have to be always generated randomly and never shared, MKI is no generated randomly and not re-used, MKI is no longer allowed with EKT
longer allowed with EKT (as MKI duplicates some of EKT's functions), (as MKI duplicates some of EKT's functions), and text clarifies that
and text clarifies that EKT must be negotiated during call setup. EKT must be negotiated during call setup. Some text was consolidated
Some text was consolidated and re-written, notably Section 2.6 and re-written, notably Section 2.6 ("Timing and Reliability").
("Timing and Reliability"). Support for re-directing the DTLS-SRTP handshake to another host was
removed, as it needed NAT traversal support.
In draft-ietf-avtcore-srtp-ekt-03, the SRTCP compound packet problem
is discussed. Updates and clarifications were made to the SDESC and
MIKEY sections.
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
skipping to change at page 8, line 27 skipping to change at page 8, line 38
all outbound packets, and is called the outbound parameter set. all outbound packets, and is called the outbound parameter set.
There may be other EKT parameter sets that are used by other SRTP/ There may be other EKT parameter sets that are used by other SRTP/
SRTCP sources in the same session, including other SRTP/SRTCP sources SRTCP sources in the same session, including other SRTP/SRTCP sources
on the same endpoint (e.g., one endpoint with voice and video might on the same endpoint (e.g., one endpoint with voice and video might
have two EKT parameter sets, or there might be multiple video sources 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 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 EKT parameter sets SHOULD be stored by all of the participants in an
SRTP session, for use in processing inbound SRTP and SRTCP traffic. SRTP session, for use in processing inbound SRTP and SRTCP traffic.
All SRTP master keys MUST NOT be re-used, MUST be randomly generated 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 according to [RFC4086], and MUST NOT be equal to or derived from
SRTP master keys. 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 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. 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. The ROC used in EKT processing MUST be the same packet processing. The ROC used in EKT processing MUST be the same
skipping to change at page 9, line 27 skipping to change at page 9, line 39
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 EKT Key encrypting the EKT_Plaintext with the EKT cipher, using the EKT Key
as 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 Implementation note: Because of the format of the Full EKT Field, a
packet containing the Full EKT Field MUST be sent when the ROC packet containing the Full EKT Field MUST be sent when the ROC
changes (i.e., every 2^32 packets). changes (i.e., every 2^16 packets).
2.2.2. Inbound Processing 2.2.2. Inbound Processing
When an SRTP or SRTCP packet containing a Full EKT Field or Short EKT When an SRTP or SRTCP packet containing a Full EKT Field or Short EKT
Field is received, it is processed as follows or using an equivalent Field is received, it is processed as follows or using an equivalent
set of steps. Inbound EKT processing MUST take place prior to the set of steps. Inbound EKT processing MUST take place prior to the
usual SRTP or SRTCP processing. Implementation note: the receiver usual SRTP or SRTCP processing. Implementation note: the receiver
may want to have a sliding window to retain old master keys for some 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. brief period of time, so that out of order packets can be processed.
The following steps show processing as packets are received in order. The following steps show processing as packets are received in order.
skipping to change at page 10, line 16 skipping to change at page 10, line 27
3. The EKT_Ciphertext is decrypted using the EKT_Key and EKT_Cipher 3. The EKT_Ciphertext is decrypted using the EKT_Key and EKT_Cipher
in the matching parameter set, as described in Section 2.3. If in the matching parameter set, as described in Section 2.3. If
the EKT decryption operation returns an authentication failure, the EKT decryption operation returns an authentication failure,
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 EKT was received over
fields do not match, then packet processing halts with an SRTP, or from the SRTCP header if EKT was received over SRTCP.
indication of failure. Otherwise, it continues as follows. If the values of the two fields do not match, then packet
processing halts with an indication of failure. Otherwise, it
continues as follows.
5. If an SRTP context associated with the SSRC in the previous step 5. If an SRTP context associated with the SSRC in the previous step
already exists and the ROC from the EKT_Plaintext is less than already exists and the ROC from the EKT_Plaintext is less than
the ROC in the SRTP context, then EKT processing halts and the the ROC in the SRTP context, then EKT processing halts and the
packet is processed as an out-of-order packet (if within the packet is processed as an out-of-order packet (if within the
implementation's sliding window) or dropped (as it is a replay). implementation's sliding window) or dropped (as it is a replay).
Otherwise, the ROC in the SRTP context is set to the value of the Otherwise, the ROC in the SRTP context is set to the value of the
ROC from the EKT_Plaintext, and the SRTP Master Key from the ROC from the EKT_Plaintext, and the SRTP Master Key from the
EKT_Plaintext is accepted as the SRTP master key corresponding to EKT_Plaintext is accepted as the SRTP master key corresponding to
the SSRC indicated in the EKT_Plaintext, beginning at the the SSRC indicated in the EKT_Plaintext, beginning at the
skipping to change at page 13, line 35 skipping to change at page 13, line 50
communicated that in key management to a source, the source will also 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 change its SRTP master key, so that traffic can be decrypted only by
those who know the current EKT key. those who know the current EKT key.
The use of EKT MUST be negotiated during key management or call setup The use of EKT MUST be negotiated during key management or call setup
(e.g., using DTLS-SRTP, Security Descriptions, MIKEY, or similar). (e.g., using DTLS-SRTP, Security Descriptions, MIKEY, or similar).
2.5. Transport 2.5. Transport
EKT SHOULD be used over SRTP, and MAY be used over SRTCP. SRTP is EKT SHOULD be used over SRTP, and MAY be used over SRTCP. SRTP is
preferred because it shares fate with transmitted media and because preferred because it shares fate with transmitted media, because SRTP
SRTP rekeying can occur without concern for RTCP transmission limits. rekeying can occur without concern for RTCP transmission limits, and
to avoid SRTCP compound packets with RTP translators and mixers.
This specification requires the EKT SSRC match the SSRC in the RTCP
header, but Section 6.1 of [RFC3550] encourages creating SRTCP
compound packets:
It is RECOMMENDED that translators and mixers combine individual
RTCP packets from the multiple sources they are forwarding into
one compound packet whenever feasible in order to amortize the
packet overhead (see Section 7).
These compound SRTCP packets might have an SSRC that does not match
the EKT SSRC. To reduce the occasion of this occuring, EKT-aware RTP
mixers and translators which are generating SRTCP compound packets
SHOULD attempt to place an SRTCP payload containing an EKT tag at the
front of the compound packet (so that the EKT receiver will process
it), and MAY be even more robust and implement more sophisticated
algorithms to ensure all EKT tags from different senders are sent at
the front of the compound packet. However, no robust algorithm
exists which ensures robust EKT delivery in conjunction with SRTCP
compound packets. This impact to RTP translators and mixers, and the
inability to realibly determine an RTP translator or mixer might be
involved in an RTP session, provides further incentive to send EKT
over RTP.
The packet processing, state machine, and Authentication Tag format The packet processing, state machine, and Authentication Tag format
for EKT over SRTP are nearly identical to that for EKT over SRTCP. 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. 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 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, 42, 50, or 58 octets long for AES-128, AES-192, or AES-256,
respectively. This length impacts the maximum payload size of the respectively. This length impacts the maximum payload size of the
SRTP (or SRTCP) packet itself. To remain below the network path MTU, SRTP (or SRTCP) packet itself. To remain below the network path MTU,
senders SHOULD constrain the SRTP (or SRTCP) payload size by this senders SHOULD constrain the SRTP (or SRTCP) payload size by this
length of the Full EKT Field. 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.
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.6. Timing and Reliability Consideration 2.6. Timing and Reliability Consideration
A system using EKT has the SRTP keys distributed with EKT, rather A system using EKT has the SRTP master keys distributed with EKT,
than with call signaling. This means a receiver can immediately rather than with call signaling. A receiver can immediately decrypt
decrypt an SRTP (or SRTCP packet) using that new key, provided the an SRTP (or SRTCP packet) using that new key, provided the SRTP
SRTP packet (or SRTCP packet) also contains the EKT key. However, a packet (or SRTCP packet) also contains a Full EKT Field.
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.
This section describes how to reliably and expediently deliver EKT This section describes how to reliably and expediently deliver new
keys to receivers. SRTP master keys to receivers.
There are three cases to consider. The first case is a new sender There are three cases to consider. The first case is a new sender
joining a session which needs to communicate its key to all the joining a session which needs to communicate its SRTP master key to
receivers. The second case is a sender changing its key which needs all the receivers. The second case is a sender changing its SRTP
to be communicated to all the receivers. The third case is a new master key which needs to be communicated to all the receivers. The
receiver joining a session already in progress which needs to know third case is a new receiver joining a session already in progress
the sender's key. which needs to know the sender's SRTP master key.
New sender: A new sender SHOULD send a packet containing the Full EKT New sender: A new sender SHOULD send a packet containing the Full EKT
Field as soon as possible, always before or coincident with sending Field as soon as possible, always before or coincident with sending
its initial SRTP packet. To accommodate packet loss, it is its initial SRTP packet. To accommodate packet loss, it is
RECOMMENDED that three consectutive packets contain the Full EKT RECOMMENDED that three consectutive packets contain the Full EKT
Field be transmitted. Inclusion of that Full EKT Field can be Field be transmitted. Inclusion of that Full EKT Field can be
stopped early if the sender determines all receivers have received stopped early if the sender determines all receivers have received
the new EKT key by receipt of an SRTCP receiver report or explicit the new SRTP master key by receipt of an SRTCP receiver report or
ACK for a sequence number with the new key. explicit ACK for a sequence number with the new key.
Rekey: By sending EKT over SRTP, the rekeying event shares fate with Rekey: By sending EKT over SRTP, the rekeying event shares fate with
the SRTP packets protected with that new key. To avoid sending large the SRTP packets protected with that new SRTP master key. To avoid
SRTP packets (such as video key frames) with the Full EKT Field, it sending large SRTP packets (such as video key frames) with the Full
can be advantageous to send smaller SRTP packets with the Full EKT EKT Field, it can be advantageous to send smaller SRTP packets with
Field with the Initial Sequence Number prior to the actual rekey the Full EKT Field with the Initial Sequence Number prior to the
event, but this does eliminate the benefits of fate-sharing EKT with actual rekey event, but this does eliminate the benefits of fate-
the SRTP packets with the new key, which increases the chance a new sharing EKT with the SRTP packets with the new SRTP master key, which
receiver won't have seen the new key. increases the chance a new receiver won't have seen the new SRTP
master key.
New receiver: When a new receiver joins a session it does not need to 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 communicate its sending SRTP master key (because it is a receiver).
receiver joins a session the sender is generally unaware of the When a new receiver joins a session the sender is generally unaware
receiver joining the session. Thus, senders SHOULD periodically of the receiver joining the session. Thus, senders SHOULD
transmit the Full EKT Field. That interval depends on how frequently periodically transmit the Full EKT Field. That interval depends on
new receivers join the session, the acceptable delay before those how frequently new receivers join the session, the acceptable delay
receivers can start processing SRTP packets, and the acceptable before those receivers can start processing SRTP packets, and the
overhead of sending the Full EKT Field. The RECOMMENDED frequency is acceptable overhead of sending the Full EKT Field. The RECOMMENDED
the same as the key frame frequency if sending video or every 5 frequency is the same as the key frame frequency if sending video or
seconds. When joining a session it is likely that SRTP or SRTCP every 5 seconds. When joining a session it is likely that SRTP or
packets might be received before a packet containing the Full EKT SRTCP packets might be received before a packet containing the Full
Field is received. Thus, to avoid doubling the authentication EKT Field is received. Thus, to avoid doubling the authentication
effort, an implementation joining an EKT session SHOULD buffer effort, an implementation joining an EKT session SHOULD buffer
received SRTP and SRTCP packets until it receives the Full EKT Field received SRTP and SRTCP packets until it receives the Full EKT Field
packet and use the information in that packet to authenticate and packet and use the information in that packet to authenticate and
decrypt the received SRTP/SRTCP packets. 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 with the streams negotiated via the Session Description Protocol with the
"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, SDESC 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
skipping to change at page 15, line 50 skipping to change at page 17, line 5
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 5 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 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:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjiiKt|2^20 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjiiKt|2^20
FEC_ORDER=FEC_SRTP FEC_ORDER=FEC_SRTP
Figure 5: 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 and the master key lifetime (number of packets). master key and salt and the master key lifetime (number of packets).
Finally, the FEC_ORDER session parameter indicates the order of Finally, the FEC_ORDER session parameter indicates the order of
Forward Error Correction used (FEC is applied before SRTP processing Forward Error Correction used (FEC is applied before SRTP processing
by the sender of the SRTP media). by the sender of the SRTP media).
The second crypto attribute has the tag "2", the crypto-suite The second crypto attribute has the tag "2", the crypto-suite
F8_128_HMAC_SHA1_80, two SRTP master keys and associated salts. F8_128_HMAC_SHA1_80, a SRTP master key, and its associated salt.
Finally, the FEC_ORDER session parameter indicates the order of Finally, the FEC_ORDER session parameter indicates the order of
Forward Error Correction used. Forward Error Correction used.
3.2. Relationship between EKT and SDP Security Descriptions 3.2. Relationship between EKT and SDESC
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 SDP Security Descriptions are complementary. SDP Security EKT and SDP Security Descriptions are complementary. SDP Security
Descriptions can negotiate several of the SRTP security parameters Descriptions can negotiate several of the SRTP security parameters
skipping to change at page 17, line 50 skipping to change at page 19, line 4
point-to-multipoint scenario into multiple point-to-point scenarios. point-to-multipoint scenario into multiple point-to-point scenarios.
There are however significant disadvantages to doing so. As long as There are however significant disadvantages to doing so. As long as
the crypto attribute in the answer does not contain any declarative the crypto attribute in the answer does not contain any declarative
parameters that differ from those in the offer, EKT solves this parameters that differ from those in the offer, EKT solves this
problem by use of the SPI correlator and communication of the problem by use of the SPI correlator and communication of the
answerer's SRTP master key in EKT. answerer's SRTP master key in EKT.
As can be seen from the above, the combination of EKT and SDESC As can be seen from the above, the combination of EKT and SDESC
provides a better solution to SRTP negotiation for offer/answer than provides a better solution to SRTP negotiation for offer/answer than
either of them alone. SDESC negotiates the various SRTP crypto either of them alone. SDESC negotiates the various SRTP crypto
parameters (which EKT does not), whereas EKT addresses the parameters (which EKT does not), whereas EKT addresses some of the
shortcomings of SDESC. shortcomings of SDESC.
3.3. Overview of Combined EKT and SDP Security Description Operation 3.3. Overview of Combined EKT and SDESC Operation
We define three session extension parameters to SDESC to communicate We define a new session parameter to SDESC to communicate the EKT
the EKT cipher, EKT key, and Security Parameter Index to the peer. cipher, EKT key, and Security Parameter Index to the peer. The
The original SDESC parameters are used as defined in [RFC4568], original SDESC parameters are used as defined in [RFC4568], however
however the procedures associated with the SRTP master key differ the procedures associated with the SRTP master key differ slightly,
slightly, since both SDESC and EKT communicate an SRTP master key. since both SDESC and EKT communicate an SRTP master key. In
In particular, the SRTP master key communicated via SDESC is used particular, the SRTP master key communicated via SDESC is used only
only if there is currently no crypto context established for the SSRC if there is currently no crypto context established for the SSRC in
in question. This will be the case when an entity has received only question. This will be the case when an entity has received only the
the offer or answer, but has yet to receive a valid EKT packet from offer or answer, but has yet to receive a valid EKT packet from the
the peer. Once a valid EKT packet is received for the SSRC, the peer. Once a valid EKT packet is received for the SSRC, the crypto
crypto context is initialized accordingly, and the SRTP master key context is initialized accordingly, and the SRTP master key will then
will then be derived from the EKT packet. Subsequent offer/answer be derived from the EKT packet. Subsequent offer/answer exchanges do
exchanges do not change this: The most recent SRTP master key not change this: The most recent SRTP master key negotiated via EKT
negotiated via EKT will be used, or, if none is available for the will be used, or, if none is available for the SSRC in question, the
SSRC in question, the most recent SRTP master key negotiated via most recent SRTP master key negotiated via offer/answer will be used.
offer/answer will be used. This is done to avoid race conditions This is done to avoid race conditions between the offer/answer
between the offer/answer exchange and EKT, even though this breaks exchange and EKT, even though this breaks some offer/answer rules.
some offer/answer rules. Note that with the rules described in this Note that with the rules described in this paragraph, once a valid
paragraph, once a valid EKT packet has been received for a given EKT packet has been received for a given SSRC, rekeying for that SSRC
SSRC, rekeying for that SSRC can only be done via EKT. The can only be done via EKT. The associated SRTP crypto parameters
associated SRTP crypto parameters however can be changed via SDESC. 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 new
following new SDESC session parameters are defined. These MUST NOT SDESC session parameter "EKT" is defined. It MUST NOT appear more
appear more than once in a given crypto attribute: than once in a given crypto attribute. In the Offer/Answer model,
the EKT parameter is a negotiated parameter.The "EKT" session
EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key parameter consists of three parts (the formal grammar is provided in
Section 3.9):
EKT_Key: The EKT key used to encrypt the SRTP Master Key
EKT_SPI: The EKT Security Parameter Index "EKT=" <EKT_Cipher> "|" <EKT_Key> "|" <EKT_SPI>
Below are details on each of these attributes. Below are details on each of these attributes.
3.4.1. EKT_Cipher EKT_Cipher: The (optional) EKT_Cipher field defines the EKT cipher
used to encrypt the EKT key within SRTP and SRTCP packets. The
The (optional) EKT_Cipher parameter defines the EKT cipher used to default value is "AESKW_128" in accordance with Section 2.3.1.
encrypt the EKT key within SRTP and SRTCP packets. The default value For the AES Key Wrap cipher, the values "AESKW_128", "AESKW_192",
is "AESKW_128" in accordance with Section 2.3.1. For the AES Key and "AESKW_256" are defined for values of L=16, 24, and 32
Wrap cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are respectively.
defined for values of L=16, 24, and 32 respectively. In the Offer/
Answer model, the EKT_Cipher parameter is a negotiated parameter.
3.4.2. EKT_Key
The (mandatory) EKT_Key parameter is the key K used to encrypt the
SRTP Master Key within SRTP and SRTCP packets. The value is base64
encoded with "=" padding if padding is necessary (see Section 3.2 and
4 of [RFC4648]). In the Offer/Answer model, the EKT_Key parameter is
a negotiated parameter.
3.4.3. EKT_SPI EKT_Key: The (mandatory) EKT_Key field is the EKT key used to
encrypt the SRTP Master Key within SRTP and SRTCP packets. The
value is base64 encoded with "=" padding if padding is necessary
(see Section 3.2 and 4 of [RFC4648]).
The (mandatory) EKT_SPI parameter is the Security Parameter Index. EKT_SPI: The (mandatory) EKT_SPI field is the Security Parameter
It is encoded as an ASCII string representing the hexadecimal value Index. It is encoded as an ASCII string representing the
of the Security Parameter Index. The SPI identifies the *offer* hexadecimal value of the Security Parameter Index. The SPI
crypto attribute (including the EKT Key and Cipher) being used for identifies the *offer* crypto attribute (including the EKT Key and
the associated SRTP session. A crypto attribute corresponds to an Cipher) being used for the associated SRTP session. A crypto
EKT Parameter Set and hence the SPI effectively identifies a attribute corresponds to an EKT Parameter Set and hence the SPI
particular EKT parameter set. Note that the scope of the SPI is the effectively identifies a particular EKT parameter set. Note that
SRTP session, which may or may not be limited to the scope of the the scope of the SPI is the SRTP session, which may or may not be
associated SIP dialog. In particular, if one of the participants in limited to the scope of the associated SIP dialog. In particular,
an SRTP session is an SRTP translator, the scope of the SRTP session if one of the participants in an SRTP session is an SRTP
is not limited to the scope of a single SIP dialog. However, if all translator, the scope of the SRTP session is not limited to the
of the participants in the session are endpoints or mixers, the scope scope of a single SIP dialog. However, if all of the participants
of the SRTP session will correspond to a single SIP dialog. In the in the session are endpoints or mixers, the scope of the SRTP
Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. session will correspond to a single SIP dialog.
3.5. Offer/Answer Procedures 3.5. Offer/Answer Considerations
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 3.4. with use of the new SDESC session parameter defined in Section 3.4.
Since SDESC is defined only for unicast streams, we provide only Since SDESC is defined only for unicast streams, we provide only
offer/answer procedures for unicast streams here as well. offer/answer procedures for unicast streams here as 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.
[[Editor's Note: following paragraph would benefit from rewording.]] [[Editor's Note: following paragraph would benefit from rewording.]]
For each unicast media line using Security Descriptions and where use For each unicast media line using Security Descriptions and where use
of EKT is desired, the offerer MUST include one EKT_Key parameter and of EKT is desired, the offerer MUST include the EKT parameter in at
one EKT_SPI parameter in at least one "crypto" attribute (see least one "crypto" attribute (see [RFC4568]). The EKT paramater MUST
[RFC4568]). The EKT_SPI parameter serves to identify the EKT contain the EKT_Key and EKT_SPI fields. The EKT_SPI field serves to
parameter set used for a particular SRTCP packet. Consequently, identify the EKT parameter set used for a particular SRTP or SRTCP
within a single media line, a given EKT_SPI value MUST NOT be used packet. Consequently, within a single media line, a given EKT_SPI
with multiple crypto attributes. Note that the EKT parameter set to value MUST NOT be used with multiple crypto attributes. Note that
use for the session is not yet established at this point; each the EKT parameter set to use for the session is not yet established
offered crypto attribute contains a candidate EKT parameter set. at this point; each offered crypto attribute contains a candidate EKT
Furthermore, if the media line refers to an existing SRTP session, parameter set. Furthermore, if the media line refers to an existing
then any SPI values used for EKT parameter sets in that session MUST SRTP session, then any SPI values used for EKT parameter sets in that
NOT be remapped to any different EKT parameter sets. When an offer session MUST NOT be remapped to any different EKT parameter sets.
describes an SRTP session that is already in progress, the offer When an offer describes an SRTP session that is already in progress,
SHOULD use an EKT parameter set (including EKT_SPI and EKT_KEY) that the offer SHOULD use an EKT parameter set (including EKT_SPI and
is already in use. EKT_KEY) that is already in use.
If a given crypto attribute includes more than one set of SRTP key
parameters (SRTP master key, salt, lifetime), they MUST all use the
same salt. (EKT requires a single shared salt between all the
participants in the direct SRTP session).
As EKT is not defined for use with MKI, the offer and the answer MUST As EKT is not defined for use with MKI, a "crypto" attribute
NOT contain MKI. containing the EKT parameter 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
skipping to change at page 20, line 42 skipping to change at page 21, line 32
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
a transport translator (relay) then synchronized negotiation of a transport translator (relay) then synchronized negotiation of
the EKT parameter sets on *all* the involved SIP dialogs will be the EKT parameter sets on *all* the involved SIP dialogs will be
needed. This is non-trivial in a variety of use cases, and hence needed. This is non-trivial in a variety of use cases, and hence
use of the combined SDES/EKT mechanism with RTP translators should use of the combined SDES/EKT mechanism with RTP translators should
be considered very carefully. It should be noted, that use of be considered very carefully. It should be noted, that use of
SRTP 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 session parameter "EKT" can either be included as an optional or
mandatory parameters, however within a given crypto attribute, they mandatory parameter.
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
steps. steps.
For each unicast media line using SDESC, the answerer examines the For each unicast media line using SDESC, the answerer examines the
associated crypto attribute(s) for the presence of EKT parameters. associated crypto attribute(s) for the presence of the session
If mandatory EKT parameters are included with a "crypto" attribute, parameter "EKT". If a mandatory EKT parameter is included with a
the answerer MUST support those parameters in order to accept that "crypto" attribute, the answerer MUST support those parameters in
offered crypto attribute. If optional EKT parameters are included order to accept that offered crypto attribute. If an optional EKT
instead, the answerer MAY accept the offered crypto attribute without parameter is included instead, the answerer MAY accept the offered
using EKT. However, doing so will prevent the offerer from crypto attribute without using EKT. However, doing so will prevent
processing any packets received before the answer. If neither the offerer from processing any packets received before the answer.
optional nor mandatory EKT parameters are included with a crypto If no EKT parameter are included with a crypto attribute, and that
attribute, and that crypto attribute is accepted in the answer, EKT crypto attribute is accepted in the answer, EKT MUST NOT be used. If
MUST NOT be used. If a given a crypto attribute includes a mixture a given a crypto attribute includes a malformed EKT parameter, that
of optional and mandatory EKT parameters, or an incomplete set of crypto attribute MUST be considered invalid.
mandatory EKT parameters, that crypto attribute MUST be considered
invalid.
When EKT is used with SDESC, the offerer and answerer MUST use the When EKT is used with SDESC, the offerer and answerer MUST use the
same SRTP master salt. Thus, the SRTP key parameter(s) in the answer same SRTP master salt. Thus, the SRTP key parameter(s) in the answer
crypto attribute MUST use the same master salt as the one accepted crypto attribute MUST use the same master salt as the one accepted
from the offer. from the offer.
When the answerer accepts the offered media line and EKT is being When the answerer accepts the offered media line and EKT is being
used, the crypto attribute included in the answer MUST include the used, the crypto attribute included in the answer MUST include the
same EKT parameter values as found in the accepted crypto attribute same EKT parameter values as found in the accepted crypto attribute
from the offer (however, if the default EKT cipher is being used, it from the offerer (however, if the default EKT cipher is being used,
may be omitted). Furthermore, the EKT parameters included MUST be it may be omitted). Furthermore, the EKT parameter included MUST be
mandatory (i.e., no "-" prefix). mandatory (i.e., no "-" prefix).
Acceptance of a crypto attribute with EKT parameters leads to Acceptance of a crypto attribute with an EKT parameter leads to
establishment of the EKT parameter set for the corresponding SRTP establishment of the EKT parameter set for the corresponding SRTP
session. Consequently, the answerer MUST send packets in accordance session. Consequently, the answerer MUST send packets in accordance
with that particular EKT parameter set only. If the answerer wants with that particular EKT parameter set only. If the answerer wants
to enable the offerer to process SRTP packets received by the offerer to enable the offerer to process SRTP packets received by the offerer
before it receives the answer, the answerer MUST NOT include any before it receives the answer, the answerer MUST 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.
Otherwise, the offerer's view of the EKT parameter set would differ Otherwise, the offerer's view of the EKT parameter set would differ
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
skipping to change at page 22, line 4 skipping to change at page 22, line 38
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.]] [[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 an EKT parameter, 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, an
optional and mandatory parameters MUST be considered equal. optional and mandatory parameter 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 an EKT parameter, 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
the accepted crypto attribute contained mandatory EKT parameters in the accepted crypto attribute contained a mandatory EKT parameter in
the offer, and the crypto attribute in the answer does not contain the offer, and the crypto attribute in the answer does not contain an
EKT parameters, then negotiation has failed (Section 5.1.3 of EKT parameter, 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 an EKT parameter but the
corresponding offered crypto line did not, or if the parameters don't corresponding offered crypto line did not, or if the values 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 SRTP packet containing a Full EKT Field is received of all, if an SRTP packet containing a Full EKT Field is received
prior to the answer, then the EKT parameter set is established prior to the answer, then the EKT parameter set is established
provisionally based on the SPI included. Once the answer (which may provisionally based on the SPI included. Once the answer (which may
include declarative session parameters) is received, the EKT include declarative session parameters) is received, the EKT
parameter set is fully established. The second case involves receipt parameter set is fully established. The second case involves receipt
skipping to change at page 23, line 14 skipping to change at page 23, line 51
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
parameters are no exception to that, however, there are a few parameter 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 offer MUST continue to be used on that media stream in all subsequent
/answer exchanges. offer/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 communicated master keys taking precedence.
an SDESC-controlled master key in a synchronized manner is difficult. Reverting back to 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 [[Editor's Note: following paragraph would benefit from re-arranging
into earlier-described steps.]] into earlier-described steps.]]
skipping to change at page 24, line 5 skipping to change at page 24, line 42
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, Security Descriptions allows for session parameters to be of all, Security Descriptions allows for session parameters to be
prefixed with "-" to indicate that they are optional. If the prefixed with "-" to indicate that they are optional. If the
answerer does not support the EKT session parameters, such optional answerer does not support the EKT session parameter, such optional
parameters will simply be ignored. When the answer is received, parameters will simply be ignored. When the answer is received,
absence of the parameters will indicate that EKT is not being used. absence of the parameter will indicate that EKT is not being used.
Receipt of SRTP or SRTCP packets prior to receipt of such an answer Receipt of SRTP or SRTCP packets prior to receipt of such an answer
will obviously be problematic (as is normally the case for Security will obviously be problematic (as is normally the case for Security
Descriptions without EKT). Descriptions without EKT).
Alternatively, Security Descriptions allows for multiple crypto lines Alternatively, Security Descriptions allows for multiple crypto lines
to be included for a particular media stream. Thus, two crypto lines to be included for a particular media stream. Thus, two crypto lines
that differ in their use of EKT parameters (presence in one, absence that differ in their use of EKT parameters (presence in one, absence
in the other) can be used as a way to negotiate use of EKT. When the in the other) can be used as a way to negotiate use of EKT. When the
answer is received, the accepted crypto attribute will indicate answer is received, the accepted crypto attribute will indicate
whether EKT is being used or not. whether EKT is being used or not.
skipping to change at page 24, line 36 skipping to change at page 25, line 24
cipher-ext = 1*64(ALPHA / DIGIT / "_") cipher-ext = 1*64(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 6: ABNF for the EKT session parameters Figure 6: ABNF for the EKT session parameters
Using the example from Figure 6 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
FEC_ORDER=FEC_SRTP EKT=AESKW_128|WWVzQUxvdmVseUVLVGtleQ|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
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 FEC_ORDER=FEC_SRTP EKT=AESKW_128|VHdvTG92ZWx5RUtUa2V5cw|AAE1
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 Figure 7: SDP Security Descriptions example with EKT
4. Use of EKT with DTLS-SRTP
This document defines an extension to DTLS-SRTP called Key Transport. This document defines an extension to DTLS-SRTP called Key Transport.
The EKT with the DTLS-SRTP Key Transport enables secure transport of The EKT with the DTLS-SRTP Key Transport enables secure transport of
EKT keying material from one DTLS-SRTP peer to another. This enables EKT keying material from one DTLS-SRTP peer to another. This enables
those peers to process EKT keying material in SRTP (or SRTCP) and those peers to process EKT keying material in SRTP (or SRTCP) and
retrieve the embedded SRTP keying material. This combination of retrieve the embedded SRTP keying material. This combination of
protocols is valuable because it combines the advantages of DTLS protocols is valuable because it combines the advantages of DTLS
(strong authentication of the endpoint and flexibility) with the (strong authentication of the endpoint and flexibility) with the
advantages of EKT (allowing secure multiparty RTP with loose advantages of EKT (allowing secure multiparty RTP with loose
coordination and efficient communication of per-source keys). coordination and efficient communication of per-source keys).
skipping to change at page 25, line 48 skipping to change at page 27, line 4
MUST include "dtls-srtp-ekt" in its SDP (as a session or media level MUST include "dtls-srtp-ekt" in its SDP (as a session or media level
attribute) and "ekt" in its TLS ServerHello message. If a DTLS attribute) and "ekt" in its TLS ServerHello message. If a DTLS
client includes "ekt" in its ClientHello, but does not receive "ekt" client includes "ekt" in its ClientHello, but does not receive "ekt"
in the ServerHello, the DTLS client MUST NOT send DTLS packets with in the ServerHello, the DTLS client MUST NOT send DTLS packets with
the "ekt" content-type. the "ekt" content-type.
The formal description of the dtls-srtp-ekt attribute is defined by The formal description of the dtls-srtp-ekt attribute is defined by
the following ABNF [RFC5234] syntax: the following ABNF [RFC5234] syntax:
attribute = "a=dtls-srtp-ekt" 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 {
RESERVED(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 7: Additional TLS Data Structures Figure 8: 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 SRTP key carried by ekt_key message, they can be encrypted using the SRTP key carried by
EKT. EKT.
Client Server Client Server
ClientHello + use_srtp + EKT
-------->
ServerHello + use_srtp + EKT
Certificate*
ServerKeyExchange* ClientHello + use_srtp + EKT
CertificateRequest* -------->
<-------- ServerHelloDone ServerHello + use_srtp + EKT
Certificate* Certificate*
ClientKeyExchange ServerKeyExchange*
CertificateVerify* CertificateRequest*
[ChangeCipherSpec] <-------- ServerHelloDone
Finished --------> Certificate*
[ChangeCipherSpec] ClientKeyExchange
<-------- Finished CertificateVerify*
SRTP packets <-------> SRTP packets [ChangeCipherSpec]
SRTP packets <-------> SRTP packets Finished -------->
ekt_key --------> [ChangeCipherSpec]
SRTP packets <-------> SRTP packets <-------- Finished
SRTP packets <-------> SRTP packets SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
ekt_key -------->
SRTP packets <-------> SRTP packets
SRTP packets <-------> SRTP packets
Figure 8: Handshake Message Flow Figure 9: Handshake Message Flow
4.3. 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
skipping to change at page 28, line 5 skipping to change at page 29, line 7
4.3.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 attribute MUST only appear at the which contains no value. This attribute MUST only appear at the
media level. This attribute indicates the offerer is capable of 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. use the "ekt" extension during the DTLS-SRTP handshake.
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.3.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. DTLS messages should be constructed according DTLS-SRTP handshake. DTLS messages should be constructed according
to those two attributes. to those two attributes.
If the answerer does not wish to perform EKT, it MUST NOT include a If the answerer does not wish to perform EKT, it MUST NOT include
=dtls-srtp-ekt in the SDP answer, and it MUST NOT negotiate EKT a=dtls-srtp-ekt in the SDP answer, and it MUST NOT negotiate EKT
during its DTLS-SRTP exchange. during its DTLS-SRTP exchange.
Otherwise, the dtls-srtp-ekt attribute SHOULD be included in the Otherwise, the dtls-srtp-ekt attribute SHOULD be included in the
answer, and EKT SHOULD be negotiated in the DTLS-SRTP handshake. answer, and EKT SHOULD be negotiated in the DTLS-SRTP handshake.
4.3.3. Processing the Initial Answer 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. There are two answerer to perform DTLS-SRTP with EKT extensions. There are two
indications the remote peer does not want to do EKT: the dtls-srtp- indications the remote peer does not want to do EKT: the dtls-srtp-
skipping to change at page 31, line 9 skipping to change at page 32, line 13
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
EKT. EKT can be used only with the pre-shared key or public-key EKT. EKT can be used only with the pre-shared key or public-key
encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode
is not suitable in conjunction with EKT, because it is not possible is not suitable in conjunction with EKT, because it is not possible
to establish one common EKT key over multiple EKT entities. to establish one common EKT key over multiple EKT entities.
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. is negotiated in the MIKEY message exchange.
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
contains a set of policies. Each policy consists of a number of
Policy Param TLVs.
Prot type | Value
-------------------
EKT | TBD (will be assigned by IANA) NOTE TO RFC EDITOR
Figure 9: EKT Security Policy
The EKT Security Policy has one parameter representing the EKT The following parameters are added to the MIKEY Security Protocol
cipher. Parameters namespace ([RFC3830], Section 6.10.1). (TBD will be
requested from IANA [NOTE TO RFC EDITOR])
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------- ----------------------------------------------------
0 | EKT cipher | see below TBD | EKT cipher | see below
TBD | EKT SPI | a 15-bit value
Figure 10: EKT Security Policy Parameters Figure 10: MIKEY Security Protocol Parameters
EKT cipher | Value EKT cipher | Value
------------------- -------------------
(reserved) | 0 (reserved) | 0
AESKW_128 | 1 AESKW_128 | 1
AESKW_192 | 2 AESKW_192 | 2
AESKW_256 | 3 AESKW_256 | 3
Figure 11: EKT Cipher Parameters Figure 11: EKT Cipher Parameters
The two mandatory EKT parameters (EKT_Key and EKT_SPI) are EKT_Key is transported in the MIKEY KEMAC payload within one separate
transported in the MIKEY KEMAC payload within one separate Key Data Key Data sub-payload. As specified in Section 6.2 of [RFC3830], the
sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC 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 12: 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 [NOTE payload. We define Type = TBD (will be requested from IANA [NOTE
TO RFC EDITOR]) to 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.
skipping to change at page 32, line 40 skipping to change at page 33, line 40
KV data MUST be present 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
This section describes Offer/Answer considerations for the use of EKT This section describes Offer/Answer considerations for the use of EKT
together with MIKEY for unicast streams. The offerer and answerer together with MIKEY for unicast streams. The offerer and answerer
MUST follow the procedures specified in [RFC3830] and [RFC4567] as MUST follow the procedures specified in [RFC3830] and [RFC4567] as
well as the following ones. well as the following ones.
5.2.1. Generating the Initial Offer 5.2.1. Generating the Initial Offer
If it is intended to use MIKEY together with EKT, the offerer MUST If it is intended to use MIKEY together with EKT, the offerer MUST
include at least one MIKEY key-mgmt attribute with one EKT_Key Key include at least one MIKEY key-mgmt attribute with one EKT_Key Key
Data sub-payload and the EKT_Cipher Security Policy payload. MIKEY Data sub-payload and the SRTP Security Policy payload (SP) with the
can be used on session or media level. On session level, MIKEY policy parameter EKT SPI. The policy parameter EKT Cipher is
provides the keys for multiple SRTP sessions in the SDP offer. The OPTIONAL, The default value is "AESKW_128" in accordance with
EKT SPI references a EKT parameter set including the Secure RTP Section 2.3.1. MIKEY can be used on session or media level. On
parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is session level, MIKEY provides the keys for multiple SRTP sessions in
used on session level, it is only possible to use one EKT SPI value. the SDP offer. The EKT SPI references a EKT parameter set including
Therefore, the session-level MIKEY message MUST contain one SRTP the Secure RTP parameters as specified in Section 8.2 in [RFC3711].
Security Policy payload only, which is valid for all related SRTP If MIKEY is used on session level, it is only possible to use one EKT
media lines. If MIKEY is used on media level, different SRTP SPI value. Therefore, the session-level MIKEY message MUST contain
one SRTP Security Policy payload only, which is valid for all related
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 media 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 and For each media line in the offer using MIKEY, provided on session
/or on media level, the answerer examines the related MIKEY key-mgmt and/or on media level, the answerer examines the related MIKEY key-
attributes for the presence of EKT parameters. In order to accept mgmt attributes for the presence of EKT parameters. In order to
the offered key-mgmt attribute, the MIKEY message MUST contain one accept the offered key-mgmt attribute, the MIKEY message MUST contain
EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy one EKT_Key Key Data sub-payload and the SRTP Security Policy payload
payload. The answerer examines also the existence of a SRTP master with policy parameter EKT SPI. The answerer examines also the
salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple existence of a SRTP master salt in the TGK/TEK and/or the EKT_Key
salts are available, all values MUST be equal. If the salt values sub-payloads. If multiple salts are available, all values MUST be
differ or no salt is present, the key-mgmt attribute MUST be equal. If the salt values differ or no salt is present, the key-mgmt
considered as invalid. attribute MUST be 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 a key-mgmt attribute for a media line contain any EKT parameters. If a key-mgmt attribute for a media line
was accepted by the answerer, the EKT parameter set of the offerer is was accepted by the answerer, the EKT parameter set of the 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 SPpar' or 'Invalid DT'
returned to indicate that the EKT_Cipher Security Policy payload or is returned to indicate that the EKT parameters (EKT Cipher and EKT
the EKT_Key sub-payload is not supported. In this case, the offerer SPI) in the SRTP Security Policy payload or the EKT_Key sub-payload
may send a second SDP offer with a MIKEY key-mgmt attribute without is not supported. In this case, the offerer may send a second SDP
the additional EKT extensions. offer with a MIKEY key-mgmt attribute without the additional EKT
extensions.
This behavior can be improved by defining an additional key-mgmt This behavior can be improved by offering two key-mgmt SDP
prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. attributes. One attribute offers MIKEY with SRTP and EKT and the
One attribute offers MIKEY with SRTP and EKT and the other attribute other attribute offers MIKEY with SRTP without EKT.
offers MIKEY with SRTP without EKT.
5.2.4. Modifying the Session 5.2.4. Modifying the Session
Once an 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 if the EKT key EKT parameter set and requires a fresh EKT SPI, even if the EKT key
skipping to change at page 34, line 36 skipping to change at page 35, line 38
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 an 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 without EKT from the Security Descriptions leg), the MGW Descriptions without EKT from the Security Descriptions leg), the MGW
needs to convert that information for the other leg, and that process needs to convert that information for the other leg, and that process
will incur some cryptographic operations. Specifically, if the new will incur some cryptographic operations. Specifically, if the new
skipping to change at page 38, line 32 skipping to change at page 39, line 35
Contact name: Dan Wing, dwing@cisco.com Contact name: Dan Wing, dwing@cisco.com
We request the following IANA assignments from the existing We request the following IANA assignments from the existing
[iana-mikey] name spaces in the IETF consensus range (0-240) [iana-mikey] name spaces in the IETF consensus range (0-240)
[RFC3830]: [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
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 Figure o EKT parameter type, initially populated with the list from
10 Figure 10
o EKT cipher, initially populated with the list from Figure 11 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 Kai Fischer for writing the MIKEY section. this document. Thanks to Kai Fischer for writing the MIKEY section.
Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond for fruitful Thanks to Nermeen Ismail, Eddy Lem,Rob Raymond, and Yi Cheng for
discussions and comments. Thanks to Felix Wyss for his review and fruitful discussions and comments. Thanks to Felix Wyss for his
comments regarding ciphers. Thanks to Michael Peck for his review. review and comments regarding ciphers. Thanks to Michael Peck for
Thanks to John Mattsson for his detailed security review highlighting his review. Thanks to Magnus Westerlund for his review. Thanks to
the duplicative interaction between SRTP MKI with EKT ISN and Michael Peck and Jonathan Lennox for their review comments.
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] National Institute of Standards and Technology (NIST), [FIPS197] National Institute of Standards and Technology (NIST),
"The Advanced Encryption Standard (AES)", FIPS-197 Federal "The Advanced Encryption Standard (AES)", FIPS-197 Federal
Information Processing Standard, November 2001. 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
skipping to change at page 40, line 45 skipping to change at page 41, line 41
time Transport Protocol (SRTP)", RFC 4771, January 2007. 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-mikey]
IANA, ., "Multimedia Internet KEYing (Mikey) Payload Name IANA, , "Multimedia Internet KEYing (Mikey) Payload Name
Spaces", 2011, <http://www.iana.org/assignments/mikey- Spaces", 2011, <http://www.iana.org/assignments/mikey-
payloads/mikey-payloads.xhtml>. payloads/mikey-payloads.xhtml>.
[iana-sdp-attr] [iana-sdp-attr]
IANA, ., "SDP Parameters", 2011, <http://www.iana.org/ IANA, , "SDP Parameters", 2011,
assignments/sdp-parameters/sdp-parameters.xml>. <http://www.iana.org/assignments/sdp-parameters/
sdp-parameters.xml>.
[iana-sdp-sdesc] [iana-sdp-sdesc]
IANA, ., "Session Description Protocol (SDP) Security IANA, , "Session Description Protocol (SDP) Security
Descriptions: SRTP Session Parameters", 2011, <http:// Descriptions: SRTP Session Parameters", 2011,
www.iana.org/assignments/sdp-security-descriptions/sdp- <http://www.iana.org/assignments/sdp-security-
security-descriptions.xml#sdp-security-descriptions-4>. 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. The IP PBX systems SRTP keys in several different IP PBX systems. The IP PBX systems
are typically used within a single enterprise. A Session Border are typically used within a single enterprise. A Session Border
Controller is a reasonable solution to interwork between Security Controller is a reasonable solution to interwork between Security
Descriptions in one network and DTLS-SRTP in another network. For Descriptions in one network and DTLS-SRTP in another network. For
example, a mobile operator (or an Enterprise) could operate Security 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 13, 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 13: 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).
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 (using a=crypto). (There is no Security Descriptions endpoint (using a=crypto). (There is no
way, with DTLS-SRTP, to communicate the Security Descriptions key way, with DTLS-SRTP, to communicate the Security Descriptions key
to the DTLS-SRTP key endpoint.) to the DTLS-SRTP key endpoint.)
4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 4. 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.
5. The received SRTP packet is simply forwarded; the SBC does not 5. 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
already communicated in step 3. already communicated in step 3.
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).
skipping to change at page 42, line 36 skipping to change at page 43, line 39
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 14, 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. | |--ekt: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 14: 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 sends an EKT packet indicating that SRTP 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,
encrypted with its key A. encrypted with its key A.
8. The received SRTP packet is simply forwarded; the SBC does not 8. The received SRTP packet is simply forwarded; the SBC does not
need to do anything with this packet as its key (key A) was need to do anything with this packet as its key (key A) was
communicated in step 4. communicated in step 4.
Authors' Addresses Authors' Addresses
John Mattsson (editor)
Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
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
 End of changes. 89 change blocks. 
437 lines changed or deleted 447 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/