One document matched: draft-ietf-avt-srtp-ekt-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml'>
<!ENTITY rfc2675 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2675.xml'>
<!ENTITY rfc4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc2409 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml'>
<!ENTITY rfc2410 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2410.xml'>
<!ENTITY rfc2406 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2406.xml'>
<!ENTITY rfc2407 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2407.xml'>
<!ENTITY rfc3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3264 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY rfc3394 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3394.xml'>
<!ENTITY rfc3548 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3548.xml'>
<!ENTITY rfc3550 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY rfc3610 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml'>
<!ENTITY rfc3602 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml'>
<!ENTITY rfc3686 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml'>
<!ENTITY rfc3830 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml'>
<!ENTITY rfc3711 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
<!ENTITY rfc4563 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml'>
<!ENTITY rfc4771 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4771.xml'>
<!ENTITY rfc4568 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml'>
<!ENTITY I-D.wing-avt-dtls-srtp-key-transport SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-avt-dtls-srtp-key-transport">
<!ENTITY I-D.ietf-avt-dtls-srtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-avt-dtls-srtp-07">
<!ENTITY I-D.ietf-tls-rfc4347-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4347-bis">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-avt-srtp-ekt-00.txt">
<front>
<title abbrev="EKT SRTP">
Encrypted Key Transport for Secure RTP
</title>
<author initials="D.A.M." surname="McGrew" fullname="David A. McGrew">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 525 8651</phone>
<email>mcgrew@cisco.com</email>
<uri>http://www.mindspring.com/~dmcgrew/dam.htm</uri>
</address>
</author>
<author initials="F.A." surname="Andreasen" fullname="Flemming
Andreason">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>499 Thornall Street</street>
<city>Edison</city>
<region>NJ</region>
<code>08837</code>
<country>US</country>
</postal>
<email>fandreas@cisco.com</email>
</address>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 853 4197 </phone>
<email>dwing@cisco.com</email>
</address>
</author>
<author initials="L." surname="Dondeti" fullname="Lakshminath Dondeti">
<organization>QUALCOMM</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>US</country>
</postal>
<email>ldondeti@qualcomm.com</email>
</address>
</author>
<date month="March" year="2010" />
<area>Audio/Video Transport</area>
<keyword>RTP</keyword>
<abstract>
<t>
SRTP Encrypted Key Transport (EKT) is an extension to SRTP that
provides for the secure transport of SRTP master keys, Rollover
Counters, and other information, within SRTP or SRTCP. This facility
enables SRTP to work for decentralized conferences with minimal
control, and to handle situations caused by early media.
</t>
<t>
This note defines EKT, and also describes how to use it
with SDP Security Descriptions, DTLS-SRTP Key Transport (KTR),
and MIKEY. These other key management protocols provide
an EKT key to everyone in a session, and EKT coordinates
the keys within the session.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
RTP is designed to allow decentralized groups with minimal control to
establish sessions, e.g. for multimedia conferences. Unfortunately,
Secure RTP (SRTP, <xref target="RFC3711"/>) cannot be used in many
minimal-control scenarios, because it requires that SSRC values and
other data be coordinated among all of the participants in a session.
For example, if a participant joins a session that is already in
progress, the SRTP rollover counter (ROC) of each SRTP source in the
session needs to be provided to that participant.
</t>
<t>
The inability of SRTP to work in the absence of central control was
well understood during the design of that protocol; that omission was
considered less important than optimizations such as bandwidth
conservation. Additionally, in many situations SRTP is used in
conjunction with a signaling system that can provide most of the
central control needed by SRTP. However, there are several cases in
which conventional signaling systems cannot easily provide all of the
coordination required. It is also desirable to eliminate the layer
violations that occur when signaling systems coordinate certain SRTP
parameters, such as SSRC values and ROCs.
</t>
<t>
This document defines Encrypted Key Transport (EKT) for SRTP, an
extension to SRTP that fits within the SRTP framework and reduces the
amount of signaling control that is needed in an SRTP session. EKT
securely distributes the SRTP master key and other information for
each SRTP source, using SRTCP or SRTP to transport that information. With
this method, SRTP entities are free to choose SSRC values as they see
fit, and to start up new SRTP sources with new SRTP master keys (see
Section 2.2) within a session without coordinating with other entities
via signaling or other external means. This fact allows to reinstate
the RTP collision detection and repair mechanism, which is nullified
by the current SRTP specification because of the need to control SSRC
values closely. An SRTP endpoint using EKT can generate new keys
whenever an existing SRTP master key has been overused, or start up a
new SRTP source to replace an old SRTP source that has reached the
packet-count limit. EKT also solves the problem in which the burst
loss of the N initial SRTP packets can confuse an SRTP receiver, when
the initial RTP sequence number is greater than or equal to 2^16 -
N. These
features simplify many architectures that implement SRTP.
</t>
<t>
EKT provides a way for an SRTP session participant, either sender or
receiver, to securely transport its SRTP master key and current SRTP
rollover counter to the other participants in the session. This data,
possibly in conjunction with additional data provided by an external
signaling protocol, furnishes the information needed by the receiver
to instantiate an SRTP/SRTCP receiver context.
</t>
<t>
EKT does not control the manner in which the SSRC and master key are
generated; it is concerned only with their secure transport. Those
values may be generated on demand by the SRTP endpoint, or may be
dictated by an external mechanism such as a signaling agent or a
secure group controller.
</t>
<t>
EKT is not intended to replace external key establishment mechanisms
such as DTLS-SRTP Key Transport
<xref target="I-D.wing-avt-dtls-srtp-key-transport"/>, SDP
Security Descriptions <xref target="RFC4568"/>, or MIKEY
<xref target="RFC3830"/>. Instead, it is used in conjunction with
those methods, and it relieves them of the burden of tightly
coordinating every SRTP source among every SRTP participant.
</t>
<t>
This document is organized as follows. A complete normative
definition of EKT is provided in <xref target="normative"/>. It
consists of packet processing algorithms (<xref target="processing"/>)
and cryptographic definitions (<xref target="cipher"/>) . In <xref
target="sdes"/>, the use of EKT with SDP Security Descriptions is
defined, and in <xref target="dtls-srtp-kt"/> its use with DTLS-SRTP
Key Transport is defined. In <xref target="mikey"/> we outline the
use of EKT with MIKEY. <xref target="rationale"/> provides a design
rationale. Security Considerations are provided in <xref
target="sec"/>, and IANA considerations are provided in <xref
target="iana"/>.
</t>
<section title="Conventions Used In This Document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
</section>
<section anchor="normative" title="Encrypted Key Transport">
<t>
In EKT, an SRTP master key is encrypted with a Key Encrypting Key
(KEK), and the resulting ciphertext is transported in every SRTCP
packet, or in selected SRTP packets. A single KEK suffices for a
single SRTP session, regardless of the number of participants in the
session. However, there can be multiple KEKs used within a particular
session. We use terms "KEK" or "EKT key" to mean the same thing; the
latter term is used when describing the relation of EKT to
external key management.
<!-- do we need to say "compound packet" everywhere? -->
</t>
<t>
In order to convey the ciphertext of the SRTP master key, and other
additional information, the Authentication Tag field is
subdivided as defined in <xref target="EKT"/>. EKT defines new
SRTP and SRTCP authentication functions, which uses this format. It
incorporates a conventional authentication function, which is
called the base authentication function in this specification. Any
authentication function, such as the default one of HMAC-SHA1
with a 160-bit key and an 80-bit authentication tag, can be used as a
base authentication function. EKT also defines a new method of
providing SRTP master keys to an endpoint.
</t>
<figure anchor="fig1" title="The EKT Authentication Tag format.">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Base Authentication Tag :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Encrypted Master Key :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rollover Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Security Parameter Index |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Base Authentication Tag :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |0|
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<section anchor="EKT" title="Authentication Tag Format">
<!--
<t>
We use the following definitions. An RTP session consists of the RTP
packets sent to a particular destination transport address or set of
such addresses. An SRTP session is an RTP session protected by SRTP.
A single session participant may have multiple RTP sources.
</t>
-->
<t>
EKT uses the Authentication Tag format shown in <xref target="fig1"/>.
The top diagram shows the format in the case that the final bit is set
to one, in which case all of the EKT fields are present. The bottom
diagram shows the format in the case that the final bit is set to
zero, in which case the Encrypted Master Key, Rollover Counter,
Initial Sequence Number, and Security Parameter Index fields are
absent, and the Reserved field is present; the latter field MUST be
set to the all-zero value. These two cases can always be
unambiguously distinguished by the final bit, or by checking to see if
the final byte in the packet has the all-zero value.
</t>
<t>
The Authentication Tag field contains the following sub-fields:
<list style="hanging">
<t hangText="Base Authentication Tag">
This field contains the authentication
tag computed by the base authentication function. The value
of this field is used to check the authenticity of the packet.
</t>
<t hangText="Encrypted Master Key">
The length of this field is variable, and is equal to the
ciphertext size N defined in <xref target="cipher"/>. Note that
the length of the field is inferable from the SPI field, since
the particular EKT cipher used by the sender of a packet is
inferable from that field. The Encrypted Master Key field is
included outside of the authenticated portion of the SRTCP
packet, immediately following the Authentication Tag. It
contains the ciphertext value resulting from the encryption of
the SRTP master key corresponding to the SSRC contained in the
packet. The encryption and decryption of this value is done
using a cipher as defined in <xref target="cipher"/>.
</t>
<t hangText="Rollover Counter">
The length of this field is fixed at 32 bits.
This field is set to the current value of the SRTP rollover
counter in the SRTP context associated with the SSRC in the SRTCP
packet. This field immediately follows the Encrypted Master Key
field.
</t>
<t hangText="Initial Sequence Number (ISN)">
The length of this field is fixed at 16 bits. If this field is
nonzero, then it indicates the RTP sequence number of the initial
RTP packet that is protected using the SRTP master key conveyed
(in encrypted form) by the Encrypted Master Key field of this
packet. If this field is zero, it indicates that the initial RTP
packet protected using the SRTP master key conveyed in this
packet preceded, or was concurrent with, the last roll-over of
the RTP sequence number.
The ISN field follows the Rollover Counter field.
</t>
<t hangText="Security Parameter Index (SPI)">
The length of this field is
fixed at 16 bits. This field indicates the appropriate Key
Encrypting Key and other parameters for the receiver to use
when processing the packet. It is an "index" into a table of
possibilities (which are established via signaling or some other
out-of-band means), much like the IPsec Security Parameter Index
<xref target="RFC4301"/>. The parameters that are identified
by this field are:
<list>
<t>
The Key Encrypting Key used to process the packet.
</t>
<t>
The EKT cipher used to process the packet.
</t>
<t>
The Secure RTP parameters associated with the SRTP Master Key
carried by the packet and the SSRC value in the packet. Section
8.2. of <xref target="RFC3711"/> summarizes the parameters
defined by that specification.
</t>
<t>
The Master Salt associated with the Master Key. (This value
is part of the parameters mentioned above, but we call
it out for emphasis.) The Master Salt is communicated
separately, via signaling, typically along with the EKT
Key Encrypting Key.
</t>
</list>
Together, these elements are called an EKT parameter set.
Within each SRTP session, each distinct EKT parameter set that
may be used MUST be associated with a distinct SPI value, to
avoid ambiguity.
<!-- Each
value MUST be associated with a Key Encrypting Key, and MAY be
associated with an EKT cipher and an SRTP parameter set.
-->
The SPI field follows the Initial Sequence Number. Since it
appears at the end of the packet, and has a fixed length, it is
always possible to unambiguously parse this field.
</t>
<t>
The finial bit of the EKT Authentication Tag format is a flag
that indicates the presence or absence of the Encrypted Master
Key, Rollover Counter, Initial Sequence Number, and Security
Parameter Index fields, as shown in <xref target="fig1"/>.
</t>
</list>
</t>
</section>
<section anchor="processing" title="Packet Processing and State Machine">
<t>
At any given time, each SRTP/SRTCP source has associated with it a
single EKT parameter set. This parameter set is used to process all
outbound packets, and is called the outbound parameter set. There may
be other EKT parameter sets that are used by other SRTP/SRTCP sources
in the same session. All of these EKT parameter sets SHOULD be stored
by all of the participants in an SRTP session, for use in processing
inbound SRTCP traffic.
</t>
<!--
adds some additional steps to the SRTCP packet processing rules.
-->
<t>
We next review SRTP authentication and show how the EKT authentication
method is built on top of a base authentication method. An SRTP or SRTCP
authentication method consists of a tag-generation function and a
verification function. The tag-generation function takes as input a
secret key, the data to be authenticated, and the packet index.
It provides an authentication tag as its sole output, and is used in
the processing of outbound packets. The verification function takes
as input a secret key, the data to be authenticated, the packet
index, and the authentication tag. It returns an indication of
whether or not the data, index, and tag are valid or not. It is used
in the processing of inbound packets. EKT defines a tag-generation
function in terms of the base tag-generation function, and defines a
verification function in terms of the base verification function. The
tag-generation function is used to process outbound packets, and the
verification function is used to process inbound packets.
</t>
<section anchor="outbound" title="Outbound (Tag Generation)">
<t>
When an SRTP or SRTCP packet needs to be sent, the EKT tag generation function
works as follows.
<!--
(see <xref target="fig2"/> and
<xref target="fig3"/>).
-->
The Rollover Counter field in the packet
is set to the current value of the SRTP rollover counter (represented
as an unsigned integer in network byte order).
</t>
<t>
The Initial Sequence Number field is set to zero, if the initial RTP
packet protected using the current SRTP master key for this source
preceded, or was concurrent with, the last roll-over of the RTP
sequence number. Otherwise, that field is set to the value of the RTP
sequence number of the initial RTP packet that was or will be
protected by that key. When the SRTP master key corresponding to a
source is changed, the new key SHOULD be communicated in advance via
EKT. (Note that the ISN field allows the receiver to know when it
should start using the new key to process SRTP packets.) This enables
the rekeying event to be communicated before any RTP packets are
protected with the new key. The rekeying event MUST not change the
value of ROC (otherwise, the current value of the ROC would not be
known to late joiners of existing sessions).
</t>
<t>
The Security Parameter Index field is set to the value of the Security
Parameter Index that is associated with the outbound parameter set.
<!-- If only one Key
Encrypting Key is provided for the session, then an all-null value for
the identifier SHOULD be used,
-->
</t>
<t>
The Encrypted Master Key field is set to the ciphertext created by
encrypting the SRTP master key with the EKT cipher, using the KEK as
the encryption key. The encryption process is detailed
in <xref target="cipher"/>.
Implementations MAY cache the value of this
field to avoid recomputing it for each packet that is sent.
<!--
Then the Encrypted Master Key
field is computed using the EKT cipher's encryption function. The
SRTP master key corresponding to the SSRC (and MKI, if present) in
the packet is the plaintext input, and the Key Encrypting Key is used
as its key.
<list style="empty">
<t> Note: the value of the Encrypted Master Key field is identical
in successive packets protected by the same KEK and SRTP
master key. This value MAY be cached by an SRTP sender to
minimize computational effort. (This property follows from
the fact that the EKT cipher is deterministic, and so
identical ciphertexts will decrypt to identical plaintexts.
When the ciphertext form of the master key matches the
Encrypted Master Key field in a packet, we know that the
decryption of that field will match the master key.)
</t>
</list>
The computed value of the Encrypted Master Key field is written into
the packet.
-->
</t>
<section anchor="base" title="Base Authentication Tag">
<t >
The Base Authentication Tag field is computed using the base
tag-generation function as follows. It can only be computed after all
of the other fields have been set. The authenticated input consists
of the following elements, in order:
<list>
<t> the SRTP or SRTCP authenticated portion, </t>
<t> a string of zero bits whose length exactly matches that of the
Base Authentication Tag field,
</t>
<t> the Encrypted Master Key field,</t>
<t> the Rollover Counter field, </t>
<t> the Initial Sequence Number field, and </t>
<t> the Security Parameter Index field. </t>
</list>
<!--
Both the sender and receiver compute the Base Authentication Tag in
the same manner.
-->
</t>
<t>
<list style="empty">
<t>
Implementation note: the string of zero bits is included in the
authenticated input in order to allow implementations to compute
the base authentication tag using a single pass of the base
authentication function. Implementations MAY write zeros into
the Base Authentication Tag field prior to computing that
function, on the sending side.
</t>
</list>
</t>
<!--
<t>
The Initial Sequence Number (ISN) field is set to zero unless the SRTP
master key has been changed, and the EKT fields
are being carried in an SRTCP packet. In that case, then
that field is set to the SRTP sequence number of the initial packet
that was sent immediately after the current master key was put into
use.
</t>
<t>
The Security Parameter Index field is set to the value of the SPI
that is currently in use.
</t>
<figure anchor="fig2" title="EKT outbound processing; generating the
Encrypted Master Key">
<artwork>
+------- SRTP master key (plaintext)
|
v
+------------+
| Encryption |
| Function |<-- Key Encrypting Key
+------------+
|
v
Encrypted Master Key (ciphertext)
</artwork>
</figure>
<figure anchor="fig3" title="EKT outbound processing; generating the
Authentication Tag">
<artwork>
authenticated portion of SRTCP packet
|
v
+----------------+ SRTCP
| Base SRTCP | authentication
| Tag Generation |<---- key
+----------------+
|
v
Authentication Tag
</artwork>
</figure>
-->
</section>
</section>
<section anchor="inbound" title="Inbound (Tag Verification)">
<t>
The EKT verification function proceeds as follows (see
<xref target="fig4"/>), or uses an equivalent set of steps. Recall
that the verification function is a component of SRTP and SRTCP processing.
When a packet does not pass the verification step, the function
indicates this fact to the SRTCP packet processing function
when it returns control to that function.
<!--
The SSRC field in the packet is checked to see if it corresponds to a
known
SRTP source with a known crypto context. If it does not, then the
following steps are taken.
-->
</t>
<t>
<list style="numbers">
<t>
The Security Parameter Index field is checked to determine which EKT
parameter set should be used when processing the packet. If multiple
parameter sets been defined for the SRTP session, then the one that is
associated with the Security Parameter Index value that matches the
Security Parameter Index field in the packet is used. This parameter
set is called the matching parameter set below. If there is no
matching SPI, then the verification function MUST return an
indication of authentication failure, and the steps described
below are not performed.
<!-- If there is
only a single session key, it SHOULD be used only if the field is set
to the all-null value.
-->
</t>
<t>
If there is already an SRTP crypto context associated with the SSRC in
the packet, and replay protection is in use, then the receiver
performs the replay check described in Section 3.3.2 of <xref
target="RFC3711"/>. If the EKT fields are conveyed in an RTCP
packet, then the packet index used in that check is formed from
the Rollover Counter and the Initial Sequence Number fields
in that packet. If the EKT fields are conveyed in an SRTP
packet, then the packet index used in that check is formed
from the EKT Rollover Counter field and the RTP Sequence Number
in that packet.
</t>
<t>
The Encrypted Master Key field is decrypted using the EKT cipher's
decryption function. That field is used as the ciphertext input, and
the Key Encrypting Key in the matching parameter set is used as the
decryption key. The decryption process is detailed in
<xref target="cipher"/>. The plaintext resulting from this decryption
is provisionally accepted as the SRTP master key corresponding to the
SSRC in the packet. If an MKI is present in the packet, then the
provisional key corresponds to the particular SSRC and MKI
combination. A provisional key MUST be used only to process one
single packet. A provisional SRTP or SRTCP authentication key is generated
from the provisional master key, and the SRTP master salt from the
matching parameter set, using the SRTP key derivation algorithm (see
Section 4.3 of <xref target="RFC3711"/>).
</t>
<t>
An authentication check is performed on the packet, using the
provisional SRTP or SRTCP authentication key. This key is provided to the
base authentication function (see <xref target="fig4"/>), which
is evaluated as described in <xref target="base"/>. If the Base
Authentication Tag field matches the tag computed by the base
authentication function, then the packet passes the check.
<list style="empty">
<t>
Implementation note: a receiver MAY copy the Base
Authentication Tag field into temporary storage, then write zeros
into that field, prior to computing the base authentication tag
value. This step allows the base authentication function to be
computed in a single pass over the data in the packet.
</t>
</list>
<!--
An SRTCP packet passes its authentication check when
the base authentication tag computed by the reciever matches the Base
Authentication Tag field carried in the packet.
-->
</t>
<t>
If the base authentication check using the provisional key fails, then
the provisional key MUST be discarded and it MUST NOT affect any
subsequent processing. The verification function MUST return an
indication of authentication failure, and the steps described below
are not performed.
</t>
<t>
Otherwise, if the base authentication check is passed, the provisional
key is also accepted as the SRTP master key corresponding to the SRTP
source that sent the packet. If an MKI is present in the packet, then
the master key corresponds to the particular SSRC and MKI combination.
If there is no SRTP crypto context corresponding to the SSRC in the
packet, then a new crypto context is created. The rollover counter in
the context is set to the value of the Rollover Counter field. If the
crypto context is not new, then the rollover counter in the context
MUST NOT be set to a value lower than its current value. (If the
replay protection step described above is performed, it ensures that
this requirement is satisfied.)
</t>
<t>
If the Initial Sequence Number field is nonzero, then the initial
sequence number for the SRTP master key is set to the packet index
created by appending that field to the current rollover counter and
treating the result as a 48-bit unsigned integer. The initial
sequence number for the master key is equivalent to the "From" value
of the < From, To > pair of indices (Section 8.1.1 of
<xref target="RFC3711"/>) that can be associated with a master key.
</t>
<t>
The newly accepted SRTP master key, the SRTP parameters from the
matching parameter set, the SSRC from the packet, and the MKI from the
packet, if one is present, are stored in the crypto context associated
with the SRTP source. The SRTP Key Derivation algorithm is run in
order to compute the SRTP encryption and authentication keys, and
those keys are stored for use in SRTP processing of inbound packets.
The Key Derivation algorithm takes as input the newly accepted
SRTP master key, along with the Master Salt from the matching
parameter set.
<list style="empty">
<t>
Implementation note: the receiver may want to retain old master keys
for some brief period of time, so that out-of-order packets can be
processed.
</t>
</list>
</t>
<t>
The verification function then returns an indication that the packet
passed the verification.
<!--
Original text: If the value of the Rollover Counter field (when
considered as an
unsigned integer in network byte order) is greater than the current
value of the SRTP rollover counter, then the rollover counter is set
to the value of the field.
-->
<list style="empty">
<t> Implementation note: the value of the Encrypted Master Key
field is identical in successive packets protected by the same
KEK and SRTP master key. This value MAY be cached by an SRTP
receiver to minimize computational effort, by allowing it to
recognize when the SRTP master key is unchanged, and thus
avoid repeating Steps 2, 6, and 7.
</t>
</list>
</t>
</list>
<!--
If the SSRC field in the packet does correspond to a known SRTP
source, then the packet is processed as follows, or using an
equivalent set of steps.
<list style="numbers">
<t>
The appropriate parameter set is selected using the Security Parameter
Index field, as in Step 1 above, and the Encrypted Master Key
field is decrypted using the Key Encrypting Key as in Step 2 above.
The resulting plaintext is used as a provisional SRTP master key.
</t>
<t>
If the provisional key matches the key associated with the SSRC (and
MKI, if one is present), then the packet is processed as follows. The
base authentication function is used to check the authenticity of the
packet, as described in Step 3 above. If the check passes, the packet
is accepted, and then the SRTP rollover counter is set to the value of
the Rollover Counter field.
</t>
<t>
If the provisional key does not match the SRTP master key associated
with the SRTP source (and MKI, if present), then processing proceeds
as follows. The authenticity of the packet is checked using the
provisional key and base SRTCP authentication function, as in Step 3
above. If that check passes, then the packet is accepted, and the
context associated with the SRTP source is set as described in Step 5
above. SRTP master keys can be associated with an initial packet
index (Section 8.1.1. of <xref target="RFC3711"/>). The initial
packet index associated with the new SRTP master key is formed from
the value of the Initial Sequence Number and Rollover Counter fields
(considered as an unsigned integer in network byte order), by
multiplying the ROC by 2^16 then adding the ISN to the result.
</t>
</list>
-->
</t>
<t>
<figure anchor="fig4" title="EKT inbound processing.">
<artwork>
+------- Encrypted Master Key
|
v
+------------+
| Decryption |
| Function |<-------------------------- Key Encrypting Key
+------------+
| +----------------+ EKT
+--------+-- provisional ---->| SRTCP |<-- master
| master key | Key Derivation | salt
| +----------------+
| |
| provisional SRTCP authentication key
| |
| v
| +----------------+
| authenticated portion --> | Base SRTCP |
| authentication tag -----> | Verification |
| +----------------+
| |
| +----------------+ +---+
| | return FAIL |<- FAIL -| ? |
| +----------------+ +---+
| |
| +----------------+ |
+------->| set master key,|<- PASS ---+
| ROC, and MKI |
+----------------+
|
v
+----------------+
| return PASS |
+----------------+
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="cipher"
title="Ciphers">
<t>
EKT uses a cipher to encrypt the SRTP master keys. We first specify
the interface to the cipher, in order to abstract the interface away
from the details of that function. We then define the cipher that is
used in EKT by default. This cipher MUST be implemented, but another
cipher that conforms to this interface MAY be used, in which case its
use MUST be coordinated by external means (e.g. call signaling).
</t>
<t>
An EKT cipher consists of an encryption function and a decryption
function. The encryption function E(K, P) takes the following inputs:
<list>
<t>
a secret key K with a length of L bytes, and
</t>
<t>
a plaintext value P with a length of M bytes.
</t>
</list>
The encryption function returns a ciphertext value C whose length is N
bytes, where N is at least M. The decryption function D(K, C) takes
the following inputs:
<list>
<t>
a secret key K with a length of L bytes, and
</t>
<t>
a ciphertext value C with a length of N bytes.
</t>
</list>
The decryption function returns a plaintext value P that is M bytes
long. These functions have the property that D(K, E(K, P)) = P for
all values of K and P. Each cipher also has a limit T on the number
of times that it can be used with any fixed key value. For each key,
the encryption function MUST NOT be invoked on more than T distinct
values of P, and the decryption function MUST NOT be invoked on more
than T distinct values of C.
</t>
<t>
An EKT cipher MUST resist attacks in which both ciphertexts and
plaintexts can be adaptively chosen. For each randomly chosen key,
the encryption and decryption functions cannot be distinguished from a
random permutation and its inverse with non-negligible advantage.
This must be true even for adversaries that can query both the
encryption and decryption functions adaptively. The advantage is
defined as the difference between the probability that the adversary
will identify the cipher as such and the probability that the
adversary will identify the random permutation as the cipher, when
each case is equally likely.
</t>
<section anchor="DefaultCipher" title="The Default Cipher">
<t>
The default cipher is the Advanced Encryption Standard (AES)
<xref target="FIPS197"/> with 128-bit keys, in Electronic Codebook
(ECB) Mode. Its parameters are fixed at L=16, M=16, and T=2^48. Note
that M matches the size of the SRTP master keys used by the default
SRTP key derivation function; if an SRTP cipher with a different SRTP
master key length is to be used with EKT, then another EKT cipher must
be used. ECB is the simplest mode of operation of a block cipher, in
which the block cipher is used in its raw form.
</t>
</section>
<section anchor="AESKeyWrap" title="The AES Key Wrap Cipher">
<t>
The AES Key Wrap <xref target="RFC3394"/> defines a cipher that can be
used with plaintexts larger than 16 bytes in length. It requires a
plaintext length M that is a multiple of eight bytes, and it returns a
ciphertext with a length of N = M + 8 bytes. It can be used with key
sizes of L = 16, 24, and 32. The key size determines the length of
the AES key used by the Key Wrap algorithm. With this cipher, T=2^48.
</t>
</section>
<section title="Other EKT Ciphers">
<t>
Other specification MAY extend this one by defining other EKT ciphers.
This section defines how those ciphers interact with this specification.
</t>
<t>
An EKT cipher determines how the Encrypted Master Key field is
written, and how it is processed when it is read. This field is
opaque to the other aspects of EKT processing. EKT ciphers are free
to use this field in any way, but they SHOULD NOT use other EKT or
SRTP fields as an input. The values of the parameters L, M, N, and T
MUST be defined by each EKT cipher, and those values MUST be
inferable from the EKT parameter set.
</t>
</section>
</section>
<section anchor="SynchronizingOperation" title="Synchronizing Operation">
<t>
A participant in a session MAY opt to use a particular EKT key to
protect outbound packets after it accepts that EKT key for protecting
inbound traffic. In this case, the fact that one participant has
changed to using a new EKT key for outbound traffic can trigger other
participants to switch to using the same key.
</t>
<t>
An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT
key has been changed. This will ensure that the set of participants
able to decrypt the traffic will be limited to those who know the
current EKT key.
</t>
<t>
EKT can be transported over SRTCP, but some of the information that it
conveys is used for SRTP processing; some elements of the EKT
parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP packets
can be lost and both SRTP and SRTCP packets may be delivered
out-of-order. This can lead to various race conditions, which we
review below.
</t>
<t>
When joining an SRTP session, SRTP packets may be received before any
EKT over SRTCP packets, which implies the crypto context has not been
established, unless other external signaling mechanism has done
so. Rather than automatically discarding such SRTP packets, the
receiver MAY want to provisionally place them in a jitter buffer and
delay discarding them until playout time.
</t>
<t>
When an SRTP source using EKT over SRTCP performs a rekeying
operation, there is a race between the actual rekeying signaled via
SRTCP and the SRTP packets secured by the new keying material. If the
SRTP packets are received first, they will fail authentication;
alternatively, if authentication is not being used, they will decrypt
to unintelligible random-looking plaintext. (Note, however, that <xref
target="RFC3711"/> says that SRTP "SHOULD NOT be used without message
authentication".) In order to address this problem, the rekeying
event can be sent before packets using the new SRTP master key are
sent (by use of the ISN field). Another solution involves using an MKI
at the expense of added overhead in each SRTP packet. Alternatively,
receivers MAY want to delay discarding packets from known SSRCs that
fail authentication in anticipation of receiving a rekeying event via
EKT (SRTCP) shortly.
</t>
<t>
<!--
<list style="empty">
<t>
Note: It was considered to include <From, To> functionality in EKT to
indicate when a particular set of parameters would apply. However, if
this is to be done without increasing the SRTP packet size, then the
From and To values can only include the 16-bit SRTP Sequence Number,
not the full (32-bit) SRTP Packet Index (which includes the
ROC). Thus, once the sequence number wraps, such an indication will no
longer be correct.
</t>
</list>
-->
</t>
<t>
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 with
this, receivers should simply follow the SRTP packet index estimation
procedures defined in [SRTP] Section 3.3.1.
</t>
</section>
<section anchor="srtp" title="Transport">
<t>
EKT MUST be used over SRTCP, whenever RTCP is in use. EKT MAY be used
over SRTP. When EKT over SRTP is used in an SRTP session in which
SRTCP is available, then EKT MUST be used for both SRTP and SRTCP.
</t>
<t>
The packet processing, state machine, and Authentication Tag format
for EKT over SRTP are nearly identical to that for EKT over SRTCP.
Differences are highlighted in <xref target="outbound"/> and <xref
target="inbound"/>.
</t>
</section>
<section title="Timing and Reliability Consideration">
<t>
SRTCP communicates the master key and ROC for the SRTP session. Thus,
as explained above, if SRTP packets are received prior to the
corresponding SRTCP (EKT) packet, a race condition occurs. From an EKT
point of view, it is therefore desirable for an SRTP sender to send an
EKT packet as soon as possible, and in no case any later than when the
initial SRTP packet is sent. SRTCP however MUST obey the timing rules
associated with the profile under which it runs (e.g. RTP/SAVP or
RTP/SAVPF). Subject to that constraint, SRTP senders using EKT over
SRTCP SHOULD send an SRTCP packet as soon as possible after joining a
session. Note that there is no need for SRTP receivers to do so. Also
note, that per RFC 3550, Section 6.2, it is permissible to send a
compound RTCP packet immediately after joining a unicast session (but
not a multicast session).
</t>
<t>
SRTCP is not reliable and hence SRTCP packets may be lost. This is
obviously a problem for endpoints joining an SRTP session and
receiving SRTP traffic (as opposed to SRTCP), or for endpoints
receiving SRTP traffic following a rekeying event. To reduce the
impact of lost packets, SRTP senders using EKT over SRTCP SHOULD send
SRTCP packets as often as allowed by the profile under which they
operate.
<!-- Editor's
Note: For unicast sessions, use of a reliable protocol to transport
EKT packets should be considered. STUN (as used by ICE) is one option,
however we would need to include SSRC identification as well as
procedures for SSRC collission detection and resolution then.
-->
</t>
</section>
</section>
<section anchor="sdes" title="EKT and SDP Security Descriptions">
<t>
The SDP Security Descriptions (SDES) <xref target="RFC4568"/>
specification defines a generic framework for negotiating security
parameters for media streams negotiated via the Session Description
Protocol by use of a new SDP "crypto" attribute and the Offer/Answer
procedures defined in <xref target="RFC3264"/>. In addition to the
general framework, SDES also defines how to use that framework
specifically to negotiate security 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 complementary to EKT. In the rest
of this Section, we provide extensions to the crypto attribute and
associated offer/answer procedures to define its use with EKT.
</t>
<section title="SDP Security Descriptions Recap">
<t>
The SRTP crypto attribute defined for SDP Security Descriptions
contains a tag followed by three types of parameters (refer to <xref
target="RFC4568"/>
for details):
<list style="hanging">
<t> Crypto-suite. Identifies the encryption and
authentication transform
</t>
<t> Key parameters. SRTP keying material and parameters.
</t>
<t>
Session parameters. Additional (optional) SRTP parameters
such as Key Derivation Rate, Forward Error Correction
Order, use of unencrypted SRTP, etc.
</t>
</list>
The crypto attributes in the example SDP in <xref target="figSDP"/>
illustrate these parameters.
<figure anchor="figSDP" title="SDP Security Descriptions example.
Line breaks are included for formatting purposes only.">
<artwork>
v=0
o=sam 2890844526 2890842807 IN IP4 192.0.2.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 192.0.2.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
</artwork>
</figure>
</t>
<t>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
master key and salt, the master key lifetime (number of packets), and
the (optional) Master Key Identifier (MKI) whose value is "1" and has
a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER
session parameter indicates the order of Forward Error Correction used
(FEC is applied before SRTP processing by the sender of the SRTP
media).
</t>
<!-- EDITOR's NOTE: EKT only includes the master key. What
about the salt ? -->
<t>
The second crypto attribute has the tag "2" and uses the crypto-suite
"F8_128_HMAC_SHA1_80". It includes two SRTP master keys and associated
salts. The first one is used with the MKI value 1, whereas the second
one is used with the MKI value 2. Finally, the FEC_ORDER session
parameter indicates the order of Forward Error Correction used.
</t>
</section>
<section title="Relationship between EKT and SDP Security Descriptions">
<t>
SDP Security Descriptions <xref target="RFC4568"/> define a generic
framework for negotiating security parameters for media streams
negotiated via the Session Description Protocol by use of the
Offer/Answer procedures defined in <xref target="RFC3264"/>. In
addition to the general framework, SDP Security Descriptions (SDES)
also defines how to use it specifically to negotiate security
parameters for Secure RTP.
</t>
<t>
EKT and SDESC are complementary. SDP Security Descriptions can
negotiate several of the SRTP security parameters (e.g. cipher and use
of Master Key Identifier/MKI) as well as SRTP master keys. SDP
Security Descriptions however does not negotiate SSRCs and their
associated Rollover Counter (ROC). Instead, SDES relies on a so-called
"late binding", where a newly observed SSRC will have its crypto
context initialized to a ROC value of zero. Clearly, this does not
work for participants joining an SRTP session that has been
established for a while and hence has a non-zero ROC. It is
impossible to use SDES to join an SRTP session that is already in
progress. In this case, EKT on the endpoint running SDP Security can
provide the additional signaling necessary to communicate the ROC
(Section 6.4.1 of <xref target="RFC4568"></xref>). The use of EKT
solves this problem by communicating the ROC associated with the SSRC
in the media plane.
</t>
<t>
SDP Security Descriptions negotiates different SRTP master keys in the
send and receive direction. The offer contains the master key used by
the offerer to send media, and the answer contains the master key used
by the answerer to send media. Consequently, if media is received by
the offerer prior to the answer being received, the offerer does not
know the master key being used. Use of SDP security preconditions can
solve this problem, however it requires an additional round-trip as
well as a more complicated state machine. EKT solves this problem by
simply sending the master key used in the media plane thereby avoiding
the need for security preconditions.
</t>
<t>
If multiple crypto-suites were offered, the offerer also will not know
which of the crypto-suites offered was selected until the answer is
received. EKT solves this problem by using a correlator, the Security
Parameter Index (SPI), which uniquely identifies each crypto
attribute in the offer.
</t>
<!--
EDITOR'S NOTE: How does EKT help solve that ? One solution would be to
include the "tag" from the selected crypto attribute, however this is
sdes specific (may need something else for MIKEY). It also does not
solve the issue of declarative parameters included in the answer,
which the offerer needs to know about to correctly process incoming
media. Propose to simply note that as a limitation of the solution (if
you want the whole nine yards, you need security preconditions).
-->
<t>
One of the primary call signaling protocols using offer/answer is the
Session Initiation Protocol (SIP) <xref target="RFC3261"/>. SIP uses
the INVITE message to initiate a media session and typically includes
an offer SDP in the INVITE. An INVITE may be "forked" to multiple
recipients which potentially can lead to multiple answers being
received. SDP Security Descriptions however does not properly support
this scenario, mainly because SDP and RTP/RTCP does not contain
sufficient information to allow for correlation of an incoming
RTP/RTCP packet with a particular answer SDP. Note that extensions
providing this correlation do exist, e.g. Interactive Connectivity
Establishment (ICE). SDP Security Descriptions addresses this
point-to-multipoint problem by moving each answer to a separate RTP
transport address thereby turning a point-to-multipoint scenario into
multiple point-to-point scenarios. There are however significant
disadvantages to doing so. As long as the crypto attribute in the
answer does not contain any declarative parameters that differ from
those in the offer, EKT solves this problem by use of the SPI
correlator and communication of the answerer's SRTP master key in EKT.
</t>
<!--
EDITOR's NOTE: How does EKT help solve that ? We would need to include
a correlator that is found in both the SDP and the RTCP packet. It
should be noted that ICE already provides this.
-->
<t>
As can be seen from the above, the combination of EKT and SDES
provides a better solution to SRTP negotiation for offer/answer than
either of them alone. SDES negotiates the various SRTP crypto
parameters (which EKT does not), whereas EKT addresses the
shortcomings of SDES.
</t>
</section>
<section title="Overview of Combined EKT and SDP Security Description Operation">
<t>
We define three session extension parameters to SDES to communicate
the EKT cipher, EKT key, and Security Parameter Index to the
peer. The original SDES parameters are used as defined in
<xref target="RFC4568"/>, however the procedures associated with the SRTP
master key differ slightly, since both SDES and EKT communicate an
SRTP master key. In particular, the SRTP master key communicated via
SDES is used only if there is currently no crypto context established
for the SSRC in question. This will be the case when an entity has
received only the offer or answer, but has yet to receive a valid EKT
message from the peer. Once a valid EKT message is received for the
SSRC, the crypto context is initialized accordingly, and the SRTP
master key will then be derived from the EKT message. Subsequent
offer/answer exchanges do not change this: The most recent SRTP master
key negotiated via EKT will be used, or, if none is available for the
SSRC in question, the most recent SRTP master key negotiated via
offer/answer will be used. Note that with these rules, once a valid
EKT message has been received for a given SSRC, rekeying for that SSRC
can only be done via EKT. The associated SRTP crypto parameters
however can be changed via SDES.
<!-- DAM - have not edited this section, shouldn't use default key -->
</t>
</section>
<section title="EKT Extensions to SDP Security Descriptions"
anchor="ext">
<t>
In order to use EKT and SDES in conjunction, we now define the
following new SDES session parameters, each of which MUST NOT appear
more than once in a given crypto attribute:
<list style="hanging">
<t hangText="EKT_Cipher "> The EKT cipher used to encrypt the SRTP
Master Key
</t>
<t hangText="EKT_Key">
The EKT key used to encrypt the SRTP Master Key
</t>
<t hangText="EKT_SPI">
The EKT Security Parameter Index
</t>
</list>
</t>
<t>
Below, we provide additional detail on each of these attributes.
</t>
<section title="EKT_Cipher">
<t>
The (optional) EKT_Cipher parameter parameter defines the EKT cipher
used to encrypt the EKT key with in SRTCP packets. The default value
is "AES_128" in accordance with <xref target="DefaultCipher"/>. For
the AES Key Wrap cipher (see <xref target="AESKeyWrap"/>, the values
"AESKW_128", "AESKW_192", and "AESKW_256" are defined for values of
L=16, 24, and 32 respectively. In the Offer/Answer model, the
EKT_Cipher parameter is a
negotiated parameter.
</t>
</section>
<section title="EKT_Key">
<t>
The (mandatory) EKT_Key parameter is the key K used to encrypt the
SRTP Master Key in SRTCP packets. The value is base64 encoded (see
<xref target="RFC3548"/>, Section 3). When base64 decoding the key,
padding characters (i.e., one or two "=" at the end of the base64
encoded data) are discarded (see <xref target="RFC3548"/> for
details). Base64 encoding assumes that the base64 encoding input is
an integral number of octets. If a given EKT cipher requires the use
of a key with a length that is not an integral number of octets, said
cipher MUST define a padding scheme that results in the base64 input
being an integral number of octets. For example, if the length defined
was 250 bits, then 6 padding bits would be needed, which could be
defined to be the last 6 bits in a 256 bit input. In the Offer/Answer
model, the EKT_Key parameter is a negotiated parameter.
</t>
</section>
<section title="EKT_SPI">
<t>
The (mandatory) EKT_SPI parameter is the Security Parameter
Index. It is encoded as an ASCII string representing the
hexadecimal value of the Security Parameter Index. The SPI
identifies the *offer* crypto attribute (including the EKT Key and
Cipher) being used for the associated SRTP session. A crypto
attribute corresponds to an EKT Parameter Set and hence the SPI
effectively identifies a particular EKT parameter set. Note that the
scope of the SPI is the SRTP session, which may or may not be limited
to the scope of the associated SIP dialog. In particular, if one of
the participants in an SRTP session is an SRTP translator, the
scope of the SRTP session is not limited to the scope of a single SIP
dialog. However, if all of the participants in the session are
endpoints or mixers, the scope of the SRTP session will correspond to
a single SIP dialog. In the Offer/Answer model, the EKT_SPI
parameter is a negotiated parameter.
</t>
</section>
</section>
<section title="Offer/Answer Procedures">
<t>
In this section, we provide the offer/answer procedures associated
with use of the three new SDES parameters defined in Section
<xref target="ext"/>. Since SDES is defined only for unicast streams, we
provide only offer/answer procedures for unicast streams here as well.
</t>
<section title="Generating the Initial Offer - Unicast Streams">
<t>
When the initial offer is generated, the offerer MUST follow the steps
defined in <xref target="RFC4568"/> Section 7.1.1 as well as the
following steps.
</t>
<t>
For each unicast media line using SDES and where use of EKT is
desired, the offerer MUST include one EKT_Key parameter and one
EKT_SPI parameter in at least one "crypto" attribute (see
<xref target="RFC4568"/>). The EKT_SPI parameter serves to identify the
EKT parameter set used for a particular SRTCP packet. Consequently,
within a single media line,
a given EKT_SPI value MUST NOT be used with multiple crypto
attributes. Note that the EKT parameter set to use for the session
is not yet established at this point; each offered crypto attribute
contains a candidate EKT parameter set.
<!--
Can we be more precise in describing a "crypto attribute" -it's an SDES
thing, I assume.
FSA: Right.
-->
Furthermore, if the media line refers to an existing SRTP
session, then any SPI values used for EKT parameter sets in that
session MUST NOT be remapped to any different EKT parameter sets.
When an offer describes an SRTP session that is already
in progress, the offer SHOULD use an EKT parameter set (incl. EKT_SPI
and
EKT_KEY) that is already in use.
</t>
<t>
If an EKT_Cipher other than the default cipher is to be used, then the
EKT_Cipher parameter MUST be included as well.
</t>
<t>
If a given crypto attribute includes more than one set of SRTP key
parameters (SRTP master key, salt, lifetime, MKI), they MUST all use
the same salt. (EKT requires a single shared salt between all the
participants in the direct SRTP session).
</t>
<!--
EDITOR's NOTE: Do we ever see a need to allow for a remapping
? We really just need to make sure there is no ambiguity, and
simply cycling the value once we hit 2^32 would be more than
enough here.
-->
<!--
EDITOR'S NOTE: Do we need the ability to negotiate different
EKT Ciphers in a single O/A exchange ? If so, we will need a
way for EKT to tell us which one was actually chosen. For now,
no such capability has been included.
-->
<t>
Important Note: The scope of the offer/answer exchange is the SIP
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 are
able to receive SRTP and SRTCP packets directly. If an SRTP session
spans multiple SIP dialogs, the EKT parameter sets MUST be synchronized
between all the SIP dialogs where SRTP and SRTCP packets can be
exchanged. In the case where the SIP entity 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 receives traffic from the
various participants on the same destination IP address and port, in
which case further coordination of SPI values and crypto parameters
may be needed between the SIP dialogs (note that SIP forking with
multiple early media senders is an example of this). However if it
operates as an RTP translator, synchronized negotiation of 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 use of the combined
SDES/EKT mechanism with RTP translators should be considered very
carefully. It should be noted, that use of SRTP with RTP translators
in general should be considered very carefully as well.
</t>
<!-- Editor's Note: Need to dedicate a section to more fully explain
(and exemplify) the issues here. Need to clarify RTP mixer and RTP
translator operation. Also need to explain SIP forking with early
media from multiple entities.
-->
<!--
EDITOR's NOTE: Can we have SRTP session where some
participants support EKT, and some do not ? For now, I assume
the answer is no.
-->
<t>
The EKT session parameters can either be included as optional or
mandatory parameters, however within a given crypto attribute, they
MUST all be either optional or mandatory.
</t>
</section>
<section title="Generating the Initial Answer - Unicast Streams">
<t>
When the initial answer is generated, the answerer MUST follow the
steps defined in <xref target="RFC4568"/> Section 7.1.2 as well as the
following steps.
</t>
<t>
For each unicast media line using SDES, the answerer examines the
associated crypto attribute(s) for the presence of EKT parameters. If
mandatory EKT parameters are included with a "crypto" attribute, the
answerer MUST support those parameters in order to accept that offered
crypto attribute. If optional EKT parameters are included instead, the
answerer MAY accept the offered crypto attribute without using EKT.
However, doing so will prevent the offerer from processing any
packets received before the answer. If
neither optional nor mandatory EKT parameters are included with a
crypto attribute, and that crypto attribute is accepted in the answer,
EKT MUST NOT be used. If a given a crypto attribute includes a mixture
of optional and mandatory EKT parameters, or an incomplete set of
mandatory EKT parameters, that crypto attribute MUST be considered
invalid.
</t>
<t>
When EKT is used with SDES, the offerer and answerer MUST use the 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 from the offer.
<!-- DAM - should we say "master salt" instead of just "salt"? -->
</t>
<t>
When the answerer accepts the offered media line and EKT is being
used, the crypto attribute included in the answer MUST include the
same EKT parameter values as found in the accepted crypto attribute
from the offer (however, if the default EKT cipher is being used, it
may be omitted). Furthermore, the EKT parameters included MUST be
mandatory (i.e. no "-" prefix).
</t>
<t>
Acceptance of a crypto attribute with EKT parameters leads to
establishment of the EKT parameter set for the corresponding SRTP
session. Consequently, the answerer MUST send packets in accordance
with that particular EKT parameter set only. If the answerer wants to
enable the offerer to process SRTP packets
received by the offerer before it receives the answer, the answerer
MUST NOT include any declarative session parameters that either were
not present in the offered crypto attribute, or were present but with
a different value. Otherwise, the offerer's view of the EKT parameter
set would differ from the answerer's until the answer is received.
Similarly, unless the offerer and answerer has other means for
correlating an answer with a particular SRTP session, the answer
SHOULD NOT include any declarative session parameters that either were
not present in the offered crypto attribute, or were present but with
a different value. If this recommendation is not followed and the
offerer receives multiple answers (e.g. due to SIP forking), the
offerer may not be able to process incoming media stream packets
correctly.
</t>
<!--
EDITOR'S NOTE: It would be sufficient to just include the
EKT_SPI as there is enough context to determine what was
accepted otherwise. However, sdes has a rule saying negotiated
session parameters need to be included in the answer.
-->
</section>
<section title="Processing of the Initial Answer - Unicast Streams">
<t>
When the offerer receives the answer, it MUST perform the steps in
<xref target="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
parameters in it.
</t>
<t>
If the answer crypto line contains EKT parameters, and the
corresponding crypto line from the offer contained the same EKT
values, use of EKT has been negotiated successfully and MUST be used
for the media stream. When determining whether the values match,
optional and mandatory parameters MUST be considered
equal. Furthermore, if the default EKT cipher is being used, it MAY be
either present or absent in the offer and/or answer.
</t>
<t>
If the answer crypto line does not contain EKT parameters, then EKT
MUST NOT be used for the corresponding SRTP session. Note that per
<xref target="RFC4568"/> Section 5.1.3, if the accepted crypto attribute
contained mandatory EKT parameters in the offer, and the crypto
attribute in the answer does not contain EKT parameters, then
negotiation has failed.
</t>
<t>
If the answer crypto line contains EKT parameters but the
corresponding offered crypto line did not, or if the parameters don't
match or are invalid, then the offerer MUST consider the crypto line
invalid (see <xref target="RFC4568"/> Section 7.1.3 for further operation).
</t>
<t>
The EKT parameter set is established when the answer is received,
however there are a couple of special cases to consider here. First of
all, if an SRTCP packet is received prior to the answer, then the EKT
parameter set is established provisionally based on the SPI
included. Once the answer (which may include declarative session
parameters) is received, the EKT parameter set is fully
established. The second case involves receipt of multiple answers due
to SIP forking. In this case, there will be multiple EKT parameter
sets; one for each SRTP session. As mentioned earlier, reliable
correlation of SIP dialogs to SRTP sessions requires extensions, and
hence if one or more of the answers include declarative session
parameters, it may be difficult to fully establish the EKT parameter
set for each SRTP session. In the absence of a specific correlation
mechanism, it is RECOMMENDED, that such correlation be done based on
the signaled receive IP-address in the SDP and the observed source
IP-address in incoming SRTP/SRTCP packets, and, if necessary, the
signaled receive UDP port and the observed source UDP port.
</t>
</section>
</section>
<section title="SRTP-Specific Use Outside Offer/Answer">
<t>
SDES use for SRTP is not defined outside offer/answer and hence
neither is SDES with EKT.
</t>
</section>
<section title="Modifying the Session">
<t>
When a media stream using the SRTP security descriptions has been
established, and a new offer/answer exchange is performed, the offerer
and answerer MUST follow the steps in <xref target="RFC4568"/> Section
7.1.4 as well as the following steps. SDES allows for all parameters
of the session to be modified, and the EKT session parameters are no
exception to that, however, there are a few additional rules to be
adhered to when using EKT.
</t>
<t>
It is permissible to start a session without the use of EKT, and then
subsequently start using EKT, however the converse is not. Thus, 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/answer exchanges.
</t>
<t>
The reason for this is that both SDES and EKT communicate the
SRTP Master Key with EKT Master Keys taking
precedence. Reverting back to an SDES controlled master key in
a synchronized manner is difficult.
</t>
<t>
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 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 for the
direct SRTP session.
</t>
<t>
Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI
value to a different EKT parameter set until 2^32 other mappings have
been used within the SRTP session. In practice, this requirements is
most easily met by using a monotonically increasing SPI value (modulo
2^32 and starting with zero) per direct SRTP session. Note that a
direct SRTP session may span multiple SIP dialogs, and in such cases
coordination of SPI values across those SIP dialogs will be
required. In the simple point-to-point unicast case without
translators, the requirement simply applies within each media line in
the SDP. In the point-to-multipoint case, the requirement applies
across all the associated SIP dialogs.
</t>
<!--
EDITOR'S NOTE: I'm not entirely happy and comfortable with
this restriction. Should probably take another look and see if
we could accommodate this.
-->
</section>
<!--
<section title="Offer/Answer Example">
<t>
To be provided.
</t>
</section>
-->
<section title="Backwards Compatibility Considerations">
<t>
Backwards compatibility can be achieved in a couple of ways. First of
all, SDES allows for session parameters to be prefixed with "-" to
indicate that they are optional. If the answerer does not support the
EKT session parameters, such optional parameters will simply be
ignored. When the answer is received, absence of the parameters will
indicate that EKT is not being used. Receipt of SRTCP packets prior to
receipt of such an answer will obviously be problematic (as is
normally the case for SDES without EKT).
</t>
<t>
Alternatively, SDES allows for multiple 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 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 whether EKT is
being used or not.
</t>
</section>
<section title="Grammar">
<t>
The Augmented Backus-Naur Form (ABNF) syntax <xref target="RFC4234"/>
for the three new SDES session parameters is as in
<xref target="figABNF"/>.
<figure anchor="figABNF" title="ABNF for the EKT session parameters.">
<artwork>
EKT = EKT_Cipher "|" EKT_Key "|" EKT_SPI
EKT_Cipher = "EKT=" EKT_Cipher_Name
EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128"
; "AESKW_192" and "AESKW_256"
; defined in this document.
EKT_Key = 1*(base64) ; See Section 3 in RFC3548
base64 = ALPHA / DIGIT / "+" / "/" / "="
EKT_SPI = 4HEXDIG ; See RFC4234
</artwork>
</figure>
</t>
<t>
Using the example from <xref target="figABNF"/> with the EKT extensions to
SDP Security Descriptions results in the following example SDP:
<!-- may need to add a figure here -->
<figure>
<artwork>
v=0
o=sam 2890844526 2890842807 IN IP4 192.0.2.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 192.0.2.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="dtls-srtp-kt" title="Use of EKT with DTLS-SRTP Key Transport">
<t>
DTLS-SRTP Key Transport (KTR)
<xref target="I-D.wing-avt-dtls-srtp-key-transport" /> uses DTLS
to securely transport
SRTP keying material from one DTLS-SRTP peer to another, so the
same SRTP keying material can be used by multiple DTLS-SRTP peers.
This extension can be used to establish EKT keys. This combination
of protocols is valuable because it combines the advantages
of DTLS (strong authentication of the endpoint, flexibility)
with the advantages of EKT (allowing secure multiparty RTP with
loose coordination and efficient communication of per-source keys).
</t>
<section title="DTLS-SRTP Extension">
<t>This document adds a new TLS negotiated extension called
"ekt". This adds a new TLS content type, EKT, and a new negotiated
extension EKT. The negotiated extension MUST only be requested in
conjunction with the
"use_srtp" extension (Section 3.2 of <xref
target="I-D.ietf-avt-dtls-srtp"></xref>). The DTLS server indicates
its support for EKT by including "ekt" in its
ServerHello message. If a DTLS client includes "ekt" in its
ClientHello, but does not receive "ekt" in the ServerHello,
the DTLS client MUST NOT send DTLS packets with the "ekt"
content-type.</t>
<figure anchor="tls_datastructure" title="Additional TLS Data Structure">
<preamble>Using the syntax described in <xref
target="I-D.ietf-tls-rfc4347-bis">DTLS</xref>, the following
structures are used:</preamble>
<artwork align="center"><![CDATA[
enum {
ekt_key(0),
ekt_key_ack(1),
ekt_key_error(254),
(255)
} SRTPKeyTransportType;
struct {
SRTPKeyTransportType keytrans_type;
uint24 length;
uint16 message_seq;
uint24 fragment_offset;
uint24 fragment_length;
select (SRTPKeyTransportType) {
case ekt_key: EKTkey;
};
} KeyTransport;
enum {
AES_128(0),
AESKW_128(1),
AESKW_192(2),
AESKW_256(3),
} ektcipher;
struct {
ektcipher EKT_Cipher;
uint EKT_Key_Value<1..256>;
uint EKT_Master_Salt<1..256>;
uint16 EKT_SPI;
} EKTkey;
]]></artwork>
</figure>
<t>A message flow showing a DTLS client and DTLS server using
the EKT extension. The first set of SRTP packets, if present, are
encrypted using the normal DTLS-SRTP key derivation function. The
second set of SRTP packets, after the ekt_key message,
can be encrypted using the EKT key. Reliability of the ekt_key is
achieved _____ (how?).</t>
<figure anchor="tls_handshake_message_flow" title="Handshake Message
Flow">
<preamble></preamble>
<artwork align="center"><![CDATA[
Client Server
ClientHello + use_srtp + EKT
-------->
ServerHello + use_srtp + EKT
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
ekt_key -------->
SRTP packets <-------> SRTP packets
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section anchor="mikey" title="Use of EKT with MIKEY">
<t>
The advantages outlined in Section 1 are useful in some scenarios in
which MIKEY is used to establish SRTP sessions. In this section, we
briefly review MIKEY and related work, and discuss these scenarios. A
n SRTP sender or a group controller can use MIKEY to establish a SRTP
cryptographic context. This capability includes the distribution of
the TEK or a TEK generation key (TGK) , security policy payload,
crypto session bundle ID (CSB_ID), and a crypto session ID
(CS_ID). The TEK directly maps to an SRTP master key, whereas the TGK
is used along with the CSB_ID and a CS_ID to generate a TEK. The CS_ID
can be used to generate multiple TEKs from a single TGK. For group
communication, the sender or group controller sends the same TGK,
CSB_ID, and CS_ID to all the members. For interactive conferencing,
each sender distributes the same SRTP crypto context to the rest of
the members.
</t>
<t>
The MIKEY specification <xref target="RFC3830"/> suggests the use of
unicast for rekeying. This method does not scale well to large groups
or interactive groups. MIKEY also provides a way to provide ROC values
to members when they join the group. It is desirable to not require
the group controller to track the ROC values of each member. For
example, in mobile and wireless environments, members may go in and
out of coverage, and in those cases, key management based ROC
synchronization is not reliable or sufficient. A better alternative
to support ROC synchronization is to send ROC values via SRTP, as EKT
does. A separate SRTP extension is being proposed
<xref target="RFC4771"/> to include the ROC as part of a modified
authentication tag. Unlike EKT, this extension uses SRTP and not
SRTCP as its transport. A new MIKEY extension
<xref target="RFC4563"/> specifies the use of MIKEY to
update group keys via multicast or broadcast for 3GPP MBMS networks.
</t>
<t>
The EKT extension of SRTP/SRTCP provides a combined solution for
rekeying and ROC synchronization. It also offers several advantages.
With EKT, an SRTP session participant can start a new SRTP source
without coordinating with a group controller about the selection of
keys or SSRC values. With EKT, SRTP can handle early media, since its
SPI allows the receiver to identify the cryptographic keys and
parameters used by the source. EKT also allows SRTP to work with SIP
forking.
</t>
<t>
MIKEY can readily be extended so that it can establish the EKT key,
cipher and SPI values.
</t>
<section title="EKT transform attribute mapping in MIKEY">
<t>
Interactive group communication using MIKEY currently requires
each member to send its own TGK and SSRC information to
the other members, resulting in O(n^2) MIKEY sessions. That is
not desirable. With EKT, the conference organizer or
only one of the members needs to distribute the EKT parameters to
all the members. After that, each member can
distribute its SRTP master key and ROC values using EKT.
Cryptographic policy initially distributed via MIKEY will
apply to all sessions. MIKEY specifies a security policy (SP)
payload to negotiate or distribute SRTP security
policy. Policy payload attributes include Session Encryption key
length, Authentication algorithm, Session
Authentication key length, Session Salt key length, SRTP PRF,
Authentication tag length and other fields (see Section
6.10.1 of RFC 3830).
</t>
<t>For the EKT_Cipher parameter, we propose to specify a new
SRTP Policy Type in the Security Policy (SP) payload of MIKEY (see
Section 6.10 of RFC 3830). The SP payload contains a number
of Policy Param TLVs. We define Type = TBD: (will be
requested from IANA) for EKT_Cipher. As with other payloads
specifying cryptographic algorithms, we only specify
Type and Values only. </t>
<t>
<figure anchor="EKT_Cipher" title="EKT_Cipher Table">
<artwork>
<![CDATA[
EKT_Cipher | Value
-------------------
AES_128 | 0
AESKW_128 | 1
AESKW_192 | 2
AESKW_256 | 3
]]>
</artwork>
<postamble/>
</figure>
</t>
<t> We propose to use the KEMAC payload to transport the two
mandatory EKT parameters: EKT_Key and EKT_SPI
MIKEY KEMAC payload, as specified in RFC 3830 carries the Traffic
Encryption Key (TEK) or the TEK Generation Key
(TGK). One or more TEKs or TGKs are carried in individual Key
Data sub-payloads within the KEMAC payload. The KEMAC
payload is encrypted as part of MIKEY. The Key Data sub-
payload, specified in Section 6.13 of RFC 3830, has the
following format:
<figure anchor="KeyData" title="Key Data Sub-Payload of MIKEY">
<artwork>
<![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
<postamble/>
</figure>
</t>
<t>The Type field, 4 bits in length, indicates the type of key
included in the payload. We define Type = TBD (will be
requested from IANA) to indicate transport of EKT_Key.</t>
<t>KV (4 bits): indicates the type of key validity period
specified. KV=1 is currently specified as an SPI. We
propose to use that value to indicate the KV_data contains the
ETK_SPI. KV_data would be 16 octets in length, but
it is also possible to interpret the length from the 'Key data
len' field.</t>
<t>KV data MUST NOT be optional when KV = 1.</t>
</section>
</section>
<section title="Interworking with Other SRTP Key Management Systems">
<section title="Security Descriptions">
<t>Today, <xref target="RFC4568">Security Descriptions</xref> is
used for distributing SRTP keys in several different IP PBX systems
and is expected to be used by 3GPP's Long Term Evolution (LTE). The
IP PBX systems are typically used within a single enterprise, and
LTE is used within the confines of a mobile operator's network. A
Session Border Controller is a reasonable solution to interwork
between Security Descriptions in one network and DTLS-SRTP in
another network. For example, a mobile operator (or an Enterprise)
could operate Security Descriptions within their network and
DTLS-SRTP towards the Internet.</t>
<t>However, due to the way Security Descriptions and DTLS-SRTP
manage their SRTP keys, such an SBC has to authenticate, decrypt,
re-encrypt, and re-authenticate the SRTP (and SRTCP) packets in one
direction, as shown in <xref
target="interworking-expensive"></xref>, below. This is
computationally expensive.</t>
<figure anchor="interworking-expensive"
title="Interworking Security Descriptions and DTLS-SRTP">
<preamble></preamble>
<artwork align="center"><![CDATA[RFC4568 endpoint SBC
DTLS-SRTP endpoint
| | |
1. |---key=A------------->| |
2. | |<-DTLS-SRTP handshake->|
3. |<--key=B--------------| |
4. | |<--SRTP, encrypted w/B-|
5. |<-SRTP, encrypted w/B-| |
6. |-SRTP, encrypted w/A->| |
7. | (decrypt, re-encrypt) |
8. | |-SRTP, encrypted w/C-->|
| | |]]></artwork>
<postamble></postamble>
</figure>
<t>The message flow is as follows (similar steps occur with
SRTCP):<list style="numbers">
<t>The <xref target="RFC4568">Security Descriptions</xref>
endpoint discloses its SRTP key to the SBC, using a=crypto in
its SDP.</t>
<t>SBC completes DTLS-SRTP handshake. From this handshake, the
SBC derives the SRTP key for traffic from the DTLS-SRTP endpoint
(key B) and to the DTLS-SRTP endpoint (key C).</t>
<t>The SBC communicates the SRTP encryption key (key B) to the
Security Descriptions endpoint (using a=crypto). (There is no
way, with DTLS-SRTP, to communicate the Security Descriptions
key to the DTLS-SRTP key endpoint.)</t>
<t>The DTLS-SRTP endpoint sends an SRTP key, encrypted with its
key B. This is received by the SBC.</t>
<t>The received SRTP packet is simply forwarded; the SBC does
not need to do anything with this packet as its key (key B) was
already communicated in step 3.</t>
<t>The Security Descriptions endpoint sends an SRTP packet,
encrypted with its key A.</t>
<t>The SBC has to authenticate and decrypt the SRTP packet
(using key A), and re-encrypt it and generate an HMAC (using key
C).</t>
<t>The SBC sends the new SRTP packet.</t>
</list></t>
<t>If EKT is deployed on the DTLS-SRTP endpoints, EKT helps
to avoid the computationally expensive operation so the SBC
does not need not perform any per-packet operations on the
SRTP (or SRTCP) packets in either direction. With EKT the SBC
can simply forward the SRTP (and SRTCP) packets in both
directions without per-packet HMAC or cryptographic
operations.</t>
<t>To accomplish this interworking, DTLS-SRTP EKT must be
supported on the DTLS-SRTP endpoint, which allows the SBC to
transport the Security Description key to the EKT endpoint
and send the DTLS-SRTP key to the Security Descriptions
endpoint. This works equally well for both incoming and
outgoing calls. An abbreviated message flow is shown in <xref
target="interworking-cheap"></xref>, below.</t>
<figure anchor="interworking-cheap"
title="Interworking Security Descriptions and EKT">
<preamble></preamble>
<artwork align="center"><![CDATA[RFC4568 endpoint SBC
DTLS-SRTP endpoint
| | |
1. |---key=A------------->| |
2. | |<-DTLS-SRTP handshake->|
3. |<--key=B--------------| |
4. | |--new_srtp_key:A------>|
5. | |<--SRTP, encrypted w/B-|
5. |<-SRTP, encrypted w/B-| |
6. |-SRTP, encrypted w/A->| |
7. | |-SRTP, encrypted w/A-->|
| | |]]></artwork>
<postamble></postamble>
</figure>
<t>The message flow is as follows (similar steps occur with
SRTCP):<list style="numbers">
<t>Security Descriptions endpoint discloses its SRTP key to the
SBC (a=crypto).</t>
<t>SBC completes DTLS-SRTP handshake. From this handshake, the
SBC derives the SRTP key for traffic from the DTLS-SRTP endpoint
(key B) and to the DTLS-SRTP endpoint (key C).</t>
<t>The SBC communicates the SRTP encryption key (key B) to the
Security Descriptions endpoint.</t>
<t>The SBC uses the EKT to indicate that SRTP packets
will be encrypted with 'key A' towards the DTLS-SRTP
endpoint.</t>
<t>The DTLS-SRTP endpoint sends an SRTP key, encrypted with its
key B. This is received by the SBC.</t>
<t>The received SRTP packet is simply forwarded; the SBC does
not need to do anything with this packet as its key (key B) was
communicated in step 3.</t>
<t>The Security Descriptions endpoint sends an SRTP packet,
encrypted with its key A.</t>
<t>The received SRTP packet is simply forwarded; the SBC does
not need to do anything with this packet as its key (key A) was
communicated in step 4.</t>
</list></t>
</section>
</section>
<section anchor="rationale" title="Design Rationale">
<t>
From <xref target="RFC3550"/>, a primary function of RTCP is to carry
the CNAME, a "persistent transport-level identifier for an RTP source"
since "receivers require the CNAME to keep track of each participant."
EKT works in much the same way, using SRTCP to carry information
needed for the proper processing of the SRTP traffic.
</t>
<t>
With EKT, SRTP gains the ability to synchronize the creation of
cryptographic contexts across all of the participants in a single
session. This feature provides some, but not all, of the
functionality that is present in IKE phase two (but not phase one).
Importantly, EKT does not provide a way to indicate SRTP options.
</t>
<t>
With EKT, external signaling mechanisms provide the SRTP options and
the EKT Key, but need not provide the key(s) for each individual SRTP
source. EKT provides a separation between the signaling mechanisms
and the details of SRTP. The signaling system need not coordinate all
SRTP streams, nor predict in advance how many streams will be present,
nor communicate SRTP-level information (e.g. rollover counters) of
current sessions.
</t>
<t>
EKT is especially useful for multi-party sessions, and for the case
where multiple RTP sessions are sent to the same destination transport
address (see the example in the definition of "RTP session" in
<xref target="RFC3550"/>). A SIP offer that is forked in parallel
(sent to multiple endpoints at the same time) can cause multiple RTP
sessions to be sent to the same transport address, making EKT useful
for use with SIP.
</t>
<t>
EKT can also be used in conjunction with a scalable group-key
management system like GDOI. Such a system provides a secure entity
authentication method and a way to revoke group membership, both of
which are out of scope of EKT.
</t>
<!--
There are several scenarios in which there are more than two
participants in an SRTP sessions, besides the important case of
multi-party conferences. For example, a session may be recorded (by a
voicemail system) or monitored (by a supervisor), or may
unintentionally include a third party (for example, a receptionist)
due to a race condition in call signaling.
A session can start out as conversational voice, then switch codecs
and SSRC values to send a fax transmission.
-->
<t>
It is natural to use SRTCP to transport encrypted keying material for
SRTP, as it provides a secure control channel for (S)RTP. However,
there are several different places in SRTCP in which the encrypted
SRTP master key and ROC could be conveyed. We briefly review some of
the alternatives in order to motivate the particular choice used in
this specification. One alternative is to have those values carried
as a new SDES item or RTCP packet. This would require that the normal
SRTCP encryption be turned off for the packets containing that SDES
item, since on the receiver's side, SRTCP processing completes before
the RTCP processing starts. This tension between encryption and the
desire for RTCP privacy is highly undesirable. Additionally, this
alternative makes SRTCP dependent upon the parsing of the RTCP
compound packet, which adds complexity. It is simpler to carry the
encrypted key in a new SRTCP field. One way to do this and to be
backwards compatible with the existing specification is to define a
new crypto function that incorporates the encrypted key. We define a
new authentication transform because EKT relies on the normal SRTCP
authentication to provide implicit authentication of the encrypted
key.
<!--
Recall that SRTP allows a transform definition to "add steps to
the packet processing, or even add fields to the SRTP/SRTCP packets."
-->
</t>
<t>
An SRTP packet containing an SSRC that has not been seen will be
discarded. This practice may induce a burst of packet loss at the
outset of an SRTP stream, due to the loss or reorder of the first
SRTCP packet with the EKT containing the key and rollover counter for
that stream. However, this practice matches the conservative RTP
memory-allocation strategy; many existing applications accept this
risk of initial packet loss. Alternatively, implementations may wish
to delay discarding such packets for a short period of time as
described in <xref target="SynchronizingOperation"/>.
</t>
<t>
When EKT is carried in SRTCP, it adds eight additional bytes to each
SRTCP packet, plus the length of the Encrypted Master Key field.
Using the SRTP and EKT defaults, the total overhead is 24 bytes. This
overhead does not detract from the total bandwidth used by SRTP, since
it is included in the RTCP bandwidth computation. However, it will
cause the control protocol to issue packets less frequently.
</t>
<t>
The main motivation for the use of the variable-length format is
bandwidth conservation. If EKT is used of SRTP, there will be a loss
of bandwidth due to the additional 24 bytes in each RTP packet. For
some applications, this bandwidth loss is significant.
<!--
A data format
that uses this approach is defined in <xref target="appendix"/>. We
leave this point open for discussion.
-->
</t>
<!--
<t>
The main motivation for defining the ability to run EKT over
SRTP instead of RTCP are the unfortunate facts that RTCP is not
always available, and that
some firewalls and NAT devices can pass RTP but not RTCP.
</t>
-->
</section>
<section anchor="sec" title="Security Considerations">
<t>
With EKT, each SRTP sender and receiver can generate distinct SRTP
master keys. This property avoids any security concern over the
re-use of keys, by empowering the SRTP layer to create keys on demand.
Note that the inputs of EKT are the same as for SRTP with key-sharing:
a single key is provided to protect an entire SRTP session. However,
EKT provides complete security, even in the absence of further
out-of-band coordination of SSRCs, and even when SSRC values collide.
</t>
<t>
EKT uses encrypted key transport with implicit authentication. A
strong cipher is used to ensure the confidentiality of the master keys
as they are transported. The authenticity of the master keys is
ensured by the base authentication check, which uses the plaintext
form of that key. If the base authentication function and
the cipher cannot be defeated by a particular attacker, then that
attacker will be unable to defeat the implicit authentication.
</t>
<t>
In order to avoid potential security issues, the SRTP authentication
tag length used by the base authentication method MUST be at least ten
octets.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This section registers with IANA the following SRTP session
parameters for SDP Security Descriptions <xref target="RFC4568"/>:
<list>
<t>EKT_KEY</t>
<t>EKT_CIPHER</t>
<t>EKT_SPI</t>
</list>
The definition of these parameters is provided in <xref target="ext"/>.
</t>
<!-- Editor's Note: Do we need an IANA registry for EKT ciphers (as
well as procedures for who can define new ones) ? Similarly, for SDES,
do we need a new IANA subregistry under the existing SDES one for the
new EKT_cipher parameter to register EKT ciphers (I think so)
-->
<!--MIKEY Registrations-->
<t>
We request the following IANA assignments from existing MIKEY
IANA tables:
<list>
<t> From the "Key Data payload name spaces:"
a value to indicate the type as the "EKT_Key."</t>
<t>From the "SRTP" policy table name space, a new value to
be assigned for "EKT_Cipher."</t>
</list>
</t>
<t>Furthermore, we need a new table to be defined:
<figure anchor="EKT_Cipher_IANA" title="EKT_Cipher Table">
<artwork>
<![CDATA[
EKT_Cipher | Value
-------------------
AES_128 | 0
AESKW_128 | 1
AESKW_192 | 2
AESKW_256 | 3
]]>
</artwork>
<postamble/>
</figure>
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Rob Raymond, Nermeen Ismail, and Kai Fischer for fruitful discussions and
comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="FIPS197">
<front>
<title>The Advanced Encryption Standard (AES)</title>
<author fullname="National Institute of Standards and Technology
(NIST)">
<organization/>
</author>
</front>
<seriesInfo name="FIPS-197" value="Federal Information
Processing Standard" />
</reference>
<!--
<reference anchor="LRW02">
<front>
<title>Tweakable Block Ciphers</title>
<author initials="M." surname="Liskov" fullname="Moses Liskov">
<organization/>
</author>
<author initials="R." surname="Rivest" fullname="Ron Rivest">
<organization/>
</author>
<author initials="D." surname="Wagner" fullname="David Wagner">
<organization/>
</author>
<date month="August" year="2002"/>
</front>
<seriesInfo name="CRYPTO 2002" value="Springer-Verlag" />
</reference>
<reference anchor="SDES">
<front>
<title> Session Description Protocol Security Descriptions
for Media Streams </title>
<author initials="F." surname="Andreasen"
fullname = "Flemming Andreasen">
<organization/>
</author>
<author initials="M." surname="Baugher"
fullname = "Mark Baugher">
<organization/>
</author>
<author initials="D." surname="Wing"
fullname = "Dan Wing">
<organization/>
</author>
</front>
<seriesInfo name="Work In Progress." value="<draft-ietf-mmusic-sdescriptions-11.txt>"/>
</reference>
-->
<!--
<reference anchor="RCC">
<front>
<title> Integrity Transform Carrying Roll-over Counter </title>
<author initials="V." surname="Lehtovirta"
fullname = "Vesa Lehtovirta">
<organization/>
</author>
<author initials="M." surname="Naslund"
fullname = "Mats Naslund">
<organization/>
</author>
<author initials="K." surname="Norrman"
fullname = "Karl Norrman">
<organization/>
</author>
</front>
<seriesInfo name="Work In Progress." value="<draft-lehtovirta-srtp-rcc-01.txt>"/>
</reference>
<reference anchor="KEYID">
<front>
<title> The Key ID Information Type for the General
Extension Payload in MIKEY
</title>
<author initials="E." surname="Carrara"
fullname = "Elisabetta Carrara"> <organization/>
</author>
<author initials="V." surname="Lehtovirta"
fullname = "Vesa Lehtovirta"> <organization/>
</author>
<author initials="K." surname="Norrman"
fullname = "Karl Norrman">
<organization/>
</author>
</front>
<seriesInfo name="Work In Progress." value="<draft-ietf-msec-newtype-keyid-04.txt>"/>
</reference>
-->
&rfc4563;
&rfc4568;
&rfc4771;
&rfc2119;
&rfc3261;
&rfc3264;
&rfc3394;
&rfc3550;
&rfc3548;
&rfc3711;
&rfc4234;
&I-D.ietf-avt-dtls-srtp;
&I-D.ietf-tls-rfc4347-bis;
</references>
<references title="Informative References">
&I-D.wing-avt-dtls-srtp-key-transport;
&rfc3830;
&rfc4301;
</references>
<!--
<section anchor="appendix" title="Alternate Format">
<t>
In this appendix we describe an alternate Authentication Tag format,
which is intended for the purposes of discussion. It allows a sender
to optionally omit the EKT data from a packet. As discussed in
<xref target="rationale"/>, this feature is desirable because it
allows bandwidth conservation, and it gives the sender the discretion
of when to send the EKT data, without any need for external
coordination.
</t>
<t>
The alternate format is shown in <xref target="altFormat"/>. The top
diagram shows the format in the case that the final bit is set to one,
in which case all of the EKT fields are present. The bottom diagram
shows the format in the case that the final bit is set to zero, in
which case the Encrypted Master Key, Rollover Counter, Initial
Sequence Number, and Security Parameter Index fields are absent. The
Reserved field MUST be set to the all-zero value. These two cases can
always be unambiguously distinguished by the final bit, or by checking
to see if the final byte in the packet has the all-zero value.
</t>
<figure anchor="altFormat" title="Alternate EKT Authentication Tag format.">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Base Authentication Tag :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Encrypted Master Key :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rollover Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Security Parameter Index |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Base Authentication Tag :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |0|
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t> In the alternate format, the SPI field is 15 bits long, instead of
16 bits long. Sender-side implementations using the existing format
can achieve interoperability with the alternate format by selecting
SPI values have a final bit that is equal to one. Receiver
implementations using the existing format can interoperate with the
alternate format if SPI values ending in one are used, and the sender
always sends all of the EKT fields.
</t>
<t>
The main motivation for the alternate format is the case when RTCP is
not available and EKT data is carried by RTP, and bandwidth
conservation is important. However, it may be acceptable to use it
for RTCP as well.
</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:40:22 |