method for generating session keys. The default master salt length
SHALL be 112 bits and the default key-derivation rate SHALL be zero.
6. Adding SRTP Transforms
Section 4 provides examples of the level of detail needed for
defining transforms. Whenever a new transform is to be added to
SRTP, a companion standard track RFC MUST be written to exactly
define how the new transform can be used with SRTP (and SRTCP). Such
a companion RFC SHOULD avoid overlap with the SRTP protocol document.
Note however, that it MAY be necessary to extend the SRTP or SRTCP
cryptographic context definition with new parameters (including fixed
or default values), add steps to the packet processing, or even add
fields to the SRTP/SRTCP packets. The companion RFC SHALL explain
any known issues regarding interactions between the transform and
other aspects of SRTP.
Each new transform document SHOULD specify its key attributes, e.g.,
size of keys (minimum, maximum, recommended), format of keys,
recommended/required processing of input keying material,
requirements/recommendations on key lifetime, re-keying and key
derivation, whether sharing of keys between SRTP and SRTCP is allowed
or not, etc.
An added message integrity transform SHOULD define a minimum
acceptable key/tag size for SRTCP, equivalent in strength to the
minimum values as defined in Section 5.2.
7. Rationale
This section explains the rationale behind several important features
of SRTP.
7.1. Key derivation
Key derivation reduces the burden on the key establishment. As many
as six different keys are needed per crypto context (SRTP and SRTCP
encryption keys and salts, SRTP and SRTCP authentication keys), but
these are derived from a single master key in a cryptographically
secure way. Thus, the key management protocol needs to exchange only
one master key (plus master salt when required), and then SRTP itself
derives all the necessary session keys (via the first, mandatory
application of the key derivation function).
Multiple applications of the key derivation function are optional,
but will give security benefits when enabled. They prevent an
attacker from obtaining large amounts of ciphertext produced by a
single fixed session key. If the attacker was able to collect a
large amount of ciphertext for a certain session key, he might be
helped in mounting certain attacks.
Multiple applications of the key derivation function provide
backwards and forward security in the sense that a compromised
session key does not compromise other session keys derived from the
same master key. This means that the attacker who is able to recover
a certain session key, is anyway not able to have access to messages
secured under previous and later session keys (derived from the same
master key). (Note that, of course, a leaked master key reveals all
the session keys derived from it.)
Considerations arise with high-rate key refresh, especially in large
multicast settings, see Section 11.
7.2. Salting key
The master salt guarantees security against off-line key-collision
attacks on the key derivation that might otherwise reduce the
effective key size [MF00].
The derived session salting key used in the encryption, has been
introduced to protect against some attacks on additive stream
ciphers, see Section 9.2. The explicit inclusion method of the salt
in the IV has been selected for ease of hardware implementation.
7.3. Message Integrity from Universal Hashing
The particular definition of the keystream given in Section 4.1 (the
keystream prefix) is to give provision for particular universal hash
functions, suitable for message authentication in the Wegman-Carter
paradigm [WC81]. Such functions are provably secure, simple, quick,
and especially appropriate for Digital Signal Processors and other
processors with a fast multiply operation.
No authentication transforms are currently provided in SRTP other
than HMAC-SHA1. Future transforms, like the above mentioned
universal hash functions, MAY be added following the guidelines in
Section 6.
7.4. Data Origin Authentication Considerations
Note that in pair-wise communications, integrity and data origin
authentication are provided together. However, in group scenarios
where the keys are shared between members, the MAC tag only proves
that a member of the group sent the packet, but does not prevent
against a member impersonating another. Data origin authentication
(DOA) for multicast and group RTP sessions is a hard problem that
needs a solution; while some promising proposals are being
investigated [PCST1] [PCST2], more work is needed to rigorously
specify these technologies. Thus SRTP data origin authentication in
groups is for further study.
DOA can be done otherwise using signatures. However, this has high
impact in terms of bandwidth and processing time, therefore we do not
offer this form of authentication in the pre-defined packet-integrity
transform.
The presence of mixers and translators does not allow data origin
authentication in case the RTP payload and/or the RTP header are
manipulated. Note that these types of middle entities also disrupt
end-to-end confidentiality (as the IV formation depends e.g., on the
RTP header preservation). A certain trust model may choose to trust
the mixers/translators to decrypt/re-encrypt the media (this would
imply breaking the end-to-end security, with related security
implications).
7.5. Short and Zero-length Message Authentication
As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP.
A full 80-bit authentication-tag SHOULD be used, but a shorter tag or
even a zero-length tag (i.e., no message authentication) MAY be used
under certain conditions to support either of the following two
application environments.
1. Strong authentication can be impractical in environments where
bandwidth preservation is imperative. An important special
case is wireless communication systems, in which bandwidth is a
scarce and expensive resource. Studies have shown that for
certain applications and link technologies, additional bytes
may result in a significant decrease in spectrum efficiency
[SWO]. Considerable effort has been made to design IP header
compression techniques to improve spectrum efficiency
[RFC3095]. A typical voice application produces 20 byte
samples, and the RTP, UDP and IP headers need to be jointly
compressed to one or two bytes on average in order to obtain
acceptable wireless bandwidth economy [RFC3095]. In this case,
strong authentication would impose nearly fifty percent
overhead.
2. Authentication is impractical for applications that use data
links with fixed-width fields that cannot accommodate the
expansion due to the authentication tag. This is the case for
some important existing wireless channels. For example, zero-
byte header compression is used to adapt EVRC/SMV voice with
the legacy IS-95 bearer channel in CDMA2000 VoIP services. It
was found that not a single additional octet could be added to
the data, which motivated the creation of a zero-byte profile
for ROHC [RFC3242].
A short tag is secure for a restricted set of applications. Consider
a voice telephony application, for example, such as a G.729 audio
codec with a 20-millisecond packetization interval, protected by a
32-bit message authentication tag. The likelihood of any given
packet being successfully forged is only one in 2^32. Thus an
adversary can control no more than 20 milliseconds of audio output
during a 994-day period, on average. In contrast, the effect of a
single forged packet can be much larger if the application is
stateful. A codec that uses relative or predictive compression
across packets will propagate the maliciously generated state,
affecting a longer duration of output.
Certainly not all SRTP or telephony applications meet the criteria
for short or zero-length authentication tags. Section 9.5.1
discusses the risks of weak or no message authentication, and section
9.5 describes the circumstances when it is acceptable and when it is
unacceptable.
8. Key Management Considerations
There are emerging key management standards [MIKEY] [KEYMGT] [SDMS]
for establishing an SRTP cryptographic context (e.g., an SRTP master
key). Both proprietary and open-standard key management methods are
likely to be used for telephony applications [MIKEY] [KINK] and
multicast applications [GDOI]. This section provides guidance for
key management systems that service SRTP session.
For initialization, an interoperable SRTP implementation SHOULD be
given the SSRC and MAY be given the initial RTP sequence number for
the RTP stream by key management (thus, key management has a
dependency on RTP operational parameters). Sending the RTP sequence
number in the key management may be useful e.g., when the initial
sequence number is close to wrapping (to avoid synchronization
problems), and to communicate the current sequence number to a
joining endpoint (to properly initialize its replay list).
If the pre-defined transforms are used, SRTP allows sharing of the
same master key between SRTP/SRTCP streams belonging to the same RTP
session.
First, sharing between SRTP streams belonging to the same RTP session
is secure if the design of the synchronization mechanism, i.e., the
IV, avoids keystream re-use (the two-time pad, Section 9.1). This is
taken care of by the fact that RTP provides for unique SSRCs for
streams belonging to the same RTP session. See Section 9.1 for
further discussion.
Second, sharing between SRTP and the corresponding SRTCP is secure.
The fact that an SRTP stream and its associated SRTCP stream both
carry the same SSRC does not constitute a problem for the two-time
pad due to the key derivation. Thus, SRTP and SRTCP corresponding to
one RTP session MAY share master keys (as they do by default).
Note that message authentication also has a dependency on SSRC
uniqueness that is unrelated to the problem of keystream reuse: SRTP
streams authenticated under the same key MUST have a distinct SSRC in
order to identify the sender of the message. This requirement is
needed because the SSRC is the cryptographically authenticated field
used to distinguish between different SRTP streams. Were two streams
to use identical SSRC values, then an adversary could substitute
messages from one stream into the other without detection.
SRTP/SRTCP MUST NOT share master keys under any other circumstances
than the ones given above, i.e., between SRTP and its corresponding
SRTCP, and, between streams belonging to the same RTP session.
8.1. Re-keying
The recommended way for a particular key management system to provide
re-key within SRTP is by associating a master key in a crypto context
with an MKI.
This provides for easy master key retrieval (see Scenarios in Section
11), but has the disadvantage of adding extra bits to each packet.
As noted in Section 7.5, some wireless links do not cater for added
bits, therefore SRTP also defines a more economic way of triggering
re-keying, via use of <From, To>, which works in some specific,
simple scenarios (see Section 8.1.1).
SRTP senders SHALL count the amount of SRTP and SRTCP traffic being
used for a master key and invoke key management to re-key if needed
(Section 9.2). These interactions are defined by the key management
interface to SRTP and are not defined by this protocol specification.
8.1.1. Use of the <From, To> for re-keying
In addition to the use of the MKI, SRTP defines another optional
mechanism for master key retrieval, the <From, To>. The <From, To>
specifies the range of SRTP indices (a pair of sequence number and
ROC) within which a certain master key is valid, and is (when used)
part of the crypto context. By looking at the 48-bit SRTP index of
the current SRTP packet, the corresponding master key can be found by
determining which From-To interval it belongs to. For SRTCP, the
most recently observed/used SRTP index (which can be obtained from
the cryptographic context) is used for this purpose, even though
SRTCP has its own (31-bit) index (see caveat below).
This method, compared to the MKI, has the advantage of identifying
the master key and defining its lifetime without adding extra bits to
each packet. This could be useful, as already noted, for some
wireless links that do not cater for added bits. However, its use
SHOULD be limited to specific, very simple scenarios. We recommend
to limit its use when the RTP session is a simple unidirectional or
bi-directional stream. This is because in case of multiple streams,
it is difficult to trigger the re-key based on the <From, To> of a
single RTP stream. For example, if several streams share a master
key, there is no simple one-to-one correspondence between the index
sequence space of a certain stream, and the index sequence space on
which the <From, To> values are based. Consequently, when a master
key is shared between streams, one of these streams MUST be
designated by key management as the one whose index space defines the
re-keying points. Also, the re-key triggering on SRTCP is based on
the correspondent SRTP stream, i.e., when the SRTP stream changes the
master key, so does the correspondent SRTCP. This becomes obviously
more and more complex with multiple streams.
The default values for the <From, To> are "from the first observed
packet" and "until further notice". However, the maximum limit of
SRTP/SRTCP packets that are sent under each given master/session key
(Section 9.2) MUST NOT be exceeded.
In case the <From, To> is used as key retrieval, then the MKI is not
inserted in the packet (and its indicator in the crypto context is
zero). However, using the MKI does not exclude using <From, To> key
lifetime simultaneously. This can for instance be useful to signal
at the sender side at which point in time an MKI is to be made
active.
8.2. Key Management parameters
The table below lists all SRTP parameters that key management can
supply. For reference, it also provides a summary of the default and
mandatory-to-support values for an SRTP implementation as described
in Section 5.
Parameter Mandatory-to-support Default
--------- -------------------- -------
SRTP and SRTCP encr transf. AES_CM, NULL AES_CM
(Other possible values: AES_f8)
SRTP and SRTCP auth transf. HMAC-SHA1 HMAC-SHA1
SRTP and SRTCP auth params:
n_tag (tag length) 80 80
SRTP prefix_length 0 0
Key derivation PRF AES_CM AES_CM
Key material params
(for each master key):
master key length 128 128
n_e (encr session key length) 128 128
n_a (auth session key length) 160 160
master salt key
length of the master salt 112 112
n_s (session salt key length) 112 112
key derivation rate 0 0
key lifetime
SRTP-packets-max-lifetime 2^48 2^48
SRTCP-packets-max-lifetime 2^31 2^31
from-to-lifetime <From, To>
MKI indicator 0 0
length of the MKI 0 0
value of the MKI
Crypto context index params:
SSRC value
ROC
SEQ
SRTCP Index
Transport address
Port number
Relation to other RTP profiles:
sender’s order between FEC and SRTP FEC-SRTP FEC-SRTP
(see Section 10)
9. Security Considerations
9.1. SSRC collision and two-time pad
Any fixed keystream output, generated from the same key and index
MUST only be used to encrypt once. Re-using such keystream (jokingly
called a "two-time pad" system by cryptographers), can seriously
compromise security. The NSA’s VENONA project [C99] provides a
historical example of such a compromise. It is REQUIRED that
automatic key management be used for establishing and maintaining
SRTP and SRTCP keying material; this requirement is to avoid
keystream reuse, which is more likely to occur with manual key
management. Furthermore, in SRTP, a "two-time pad" is avoided by
requiring the key, or some other parameter of cryptographic
significance, to be unique per RTP/RTCP stream and packet. The pre-
defined SRTP transforms accomplish packet-uniqueness by including the
packet index and stream-uniqueness by inclusion of the SSRC.
The pre-defined transforms (AES-CM and AES-f8) allow master keys to
be shared across streams belonging to the same RTP session by the
inclusion of the SSRC in the IV. A master key MUST NOT be shared
among different RTP sessions.
Thus, the SSRC MUST be unique between all the RTP streams within the
same RTP session that share the same master key. RTP itself provides
an algorithm for detecting SSRC collisions within the same RTP
session. Thus, temporary collisions could lead to temporary two-time
pad, in the unfortunate event that SSRCs collide at a point in time
when the streams also have identical sequence numbers (occurring with
probability roughly 2^(-48)). Therefore, the key management SHOULD
take care of avoiding such SSRC collisions by including the SSRCs to
be used in the session as negotiation parameters, proactively
assuring their uniqueness. This is a strong requirements in
scenarios where for example, there are multiple senders that can
start to transmit simultaneously, before SSRC collision are detected
at the RTP level.
Note also that even with distinct SSRCs, extensive use of the same
key might improve chances of probabilistic collision and time-
memory-tradeoff attacks succeeding.
As described, master keys MAY be shared between streams belonging to
the same RTP session, but it is RECOMMENDED that each SSRC have its
own master key. When master keys are shared among SSRC participants
and SSRCs are managed by a key management module as recommended
above, the RECOMMENDED policy for an SSRC collision error is for the
participant to leave the SRTP session as it is a sign of malfunction.
9.2. Key Usage
The effective key size is determined (upper bounded) by the size of
the master key and, for encryption, the size of the salting key. Any
additive stream cipher is vulnerable to attacks that use statistical
knowledge about the plaintext source to enable key collision and
time-memory tradeoff attacks [MF00] [H80] [BS00]. These attacks take
advantage of commonalities among plaintexts, and provide a way for a
cryptanalyst to amortize the computational effort of decryption over
many keys, or over many bytes of output, thus reducing the effective
key size of the cipher. A detailed analysis of these attacks and
their applicability to the encryption of Internet traffic is provided
in [MF00]. In summary, the effective key size of SRTP when used in a
security system in which m distinct keys are used, is equal to the
key size of the cipher less the logarithm (base two) of m.
Protection against such attacks can be provided simply by increasing
the size of the keys used, which here can be accomplished by the use
of the salting key. Note that the salting key MUST be random but MAY
be public. A salt size of (the suggested) size 112 bits protects
against attacks in scenarios where at most 2^112 keys are in use.
This is sufficient for all practical purposes.
Implementations SHOULD use keys that are as large as possible.
Please note that in many cases increasing the key size of a cipher
does not affect the throughput of that cipher.
The use of the SRTP and SRTCP indices in the pre-defined transforms
fixes the maximum number of packets that can be secured with the same
key. This limit is fixed to 2^48 SRTP packets for an SRTP stream,
and 2^31 SRTCP packets, when SRTP and SRTCP are considered
independently. Due to for example re-keying, reaching this limit may
or may not coincide with wrapping of the indices, and thus the sender
MUST keep packet counts. However, when the session keys for related
SRTP and SRTCP streams are derived from the same master key (the
default behavior, Section 4.3), the upper bound that has to be
considered is in practice the minimum of the two quantities. That
is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
with the same key (whichever occurs before), the key management MUST
be called to provide new master key(s) (previously stored and used
keys MUST NOT be used again), or the session MUST be terminated. If
a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not
updated the master or session key prior to sending 2^48 SRTP (or 2^31
SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to
the security policy of the RTCP sender how to behave, e.g., whether
an RTCP BYE-packet should be sent and/or if the event should be
logged.
Note: in most typical applications (assuming at least one RTCP packet
for every 128,000 RTP packets), it will be the SRTCP index that first
reaches the upper limit, although the time until this occurs is very
long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is
enough to secure approximately 4 months of communication.
Note that if the master key is to be shared between SRTP streams
within the same RTP session (Section 9.1), although the above bounds
are on a per stream (i.e., per SSRC) basis, the sender MUST base re-
key decision on the stream whose sequence number space is the first
to be exhausted.
Key derivation limits the amount of plaintext that is encrypted with
a fixed session key, and made available to an attacker for analysis,
but key derivation does not extend the master key’s lifetime. To see
this, simply consider our requirements to avoid two-time pad: two
distinct packets MUST either be processed with distinct IVs, or with
distinct session keys, and both the distinctness of IV and of the
session keys are (for the pre-defined transforms) dependent on the
distinctness of the packet indices.
Note that with the key derivation, the effective key size is at most
that of the master key, even if the derived session key is
considerably longer. With the pre-defined authentication transform,
the session authentication key is 160 bits, but the master key by
default is only 128 bits. This design choice was made to comply with
certain recommendations in [RFC2104] so that an existing HMAC
implementation can be plugged into SRTP without problems. Since the
default tag size is 80 bits, it is, for the applications in mind,
also considered acceptable from security point of view. Users having
concerns about this are RECOMMENDED to instead use a 192 bit master
key in the key derivation. It was, however, chosen not to mandate
192-bit keys since existing AES implementations to be used in the
key-derivation may not always support key-lengths other than 128
bits. Since AES is not defined (or properly analyzed) for use with
160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes