forked from Mirrors/freeswitch
b3d890ef25
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@1086 d0543943-73ff-0310-b7d9-9358b9ac24b2
3140 lines
131 KiB
Plaintext
3140 lines
131 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group M. Baugher
|
||
Request for Comments: 3711 D. McGrew
|
||
Category: Standards Track Cisco Systems, Inc.
|
||
M. Naslund
|
||
E. Carrara
|
||
K. Norrman
|
||
Ericsson Research
|
||
March 2004
|
||
|
||
|
||
The Secure Real-time Transport Protocol (SRTP)
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document describes the Secure Real-time Transport Protocol
|
||
(SRTP), a profile of the Real-time Transport Protocol (RTP), which
|
||
can provide confidentiality, message authentication, and replay
|
||
protection to the RTP traffic and to the control traffic for RTP, the
|
||
Real-time Transport Control Protocol (RTCP).
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
|
||
2. Goals and Features . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3. SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
3.2. SRTP Cryptographic Contexts. . . . . . . . . . . . . . . 7
|
||
3.2.1. Transform-independent parameters . . . . . . . . 8
|
||
3.2.2. Transform-dependent parameters . . . . . . . . . 10
|
||
3.2.3. Mapping SRTP Packets to Cryptographic Contexts . 10
|
||
3.3. SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
|
||
3.3.1. Packet Index Determination, and ROC, s_l Update. 13
|
||
3.3.2. Replay Protection. . . . . . . . . . . . . . . . 15
|
||
3.4. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 1]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
4. Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
|
||
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
4.1.1. AES in Counter Mode. . . . . . . . . . . . . . . 21
|
||
4.1.2. AES in f8-mode . . . . . . . . . . . . . . . . . 22
|
||
4.1.3. NULL Cipher. . . . . . . . . . . . . . . . . . . 25
|
||
4.2. Message Authentication and Integrity . . . . . . . . . . 25
|
||
4.2.1. HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
|
||
4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
|
||
4.3.1. Key Derivation Algorithm . . . . . . . . . . . . 26
|
||
4.3.2. SRTCP Key Derivation . . . . . . . . . . . . . . 28
|
||
4.3.3. AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
|
||
5. Default and mandatory-to-implement Transforms. . . . . . . . . 28
|
||
5.1. Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
|
||
5.2. Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
|
||
5.3. Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
|
||
6. Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
|
||
7. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
|
||
7.1. Key derivation . . . . . . . . . . . . . . . . . . . . . 30
|
||
7.2. Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
|
||
7.3. Message Integrity from Universal Hashing . . . . . . . . 31
|
||
7.4. Data Origin Authentication Considerations. . . . . . . . 31
|
||
7.5. Short and Zero-length Message Authentication . . . . . . 32
|
||
8. Key Management Considerations. . . . . . . . . . . . . . . . . 33
|
||
8.1. Re-keying . . . . . . . . . . . . . . . . . . . . . . . 34
|
||
8.1.1. Use of the <From, To> for re-keying. . . . . . . 34
|
||
8.2. Key Management parameters. . . . . . . . . . . . . . . . 35
|
||
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
|
||
9.1. SSRC collision and two-time pad. . . . . . . . . . . . . 37
|
||
9.2. Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
|
||
9.3. Confidentiality of the RTP Payload . . . . . . . . . . . 39
|
||
9.4. Confidentiality of the RTP Header. . . . . . . . . . . . 40
|
||
9.5. Integrity of the RTP payload and header. . . . . . . . . 40
|
||
9.5.1. Risks of Weak or Null Message Authentication. . . 42
|
||
9.5.2. Implicit Header Authentication . . . . . . . . . 43
|
||
10. Interaction with Forward Error Correction mechanisms. . . . . 43
|
||
11. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
|
||
11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
|
||
11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
|
||
11.3. Re-keying and access control . . . . . . . . . . . . . . 45
|
||
11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
|
||
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
|
||
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
|
||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
|
||
14.1. Normative References . . . . . . . . . . . . . . . . . . 47
|
||
14.2. Informative References . . . . . . . . . . . . . . . . . 48
|
||
Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
|
||
Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
|
||
B.1. AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 2]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
B.2. AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
|
||
B.3. Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
|
||
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56
|
||
|
||
1. Introduction
|
||
|
||
This document describes the Secure Real-time Transport Protocol
|
||
(SRTP), a profile of the Real-time Transport Protocol (RTP), which
|
||
can provide confidentiality, message authentication, and replay
|
||
protection to the RTP traffic and to the control traffic for RTP,
|
||
RTCP (the Real-time Transport Control Protocol) [RFC3350].
|
||
|
||
SRTP provides a framework for encryption and message authentication
|
||
of RTP and RTCP streams (Section 3). SRTP defines a set of default
|
||
cryptographic transforms (Sections 4 and 5), and it allows new
|
||
transforms to be introduced in the future (Section 6). With
|
||
appropriate key management (Sections 7 and 8), SRTP is secure
|
||
(Sections 9) for unicast and multicast RTP applications (Section 11).
|
||
|
||
SRTP can achieve high throughput and low packet expansion. SRTP
|
||
proves to be a suitable protection for heterogeneous environments
|
||
(mix of wired and wireless networks). To get such features, default
|
||
transforms are described, based on an additive stream cipher for
|
||
encryption, a keyed-hash based function for message authentication,
|
||
and an "implicit" index for sequencing/synchronization based on the
|
||
RTP sequence number for SRTP and an index number for Secure RTCP
|
||
(SRTCP).
|
||
|
||
1.1. Notational Conventions
|
||
|
||
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119]. The
|
||
terminology conforms to [RFC2828] with the following exception. For
|
||
simplicity we use the term "random" throughout the document to denote
|
||
randomly or pseudo-randomly generated values. Large amounts of
|
||
random bits may be difficult to obtain, and for the security of SRTP,
|
||
pseudo-randomness is sufficient [RFC1750].
|
||
|
||
By convention, the adopted representation is the network byte order,
|
||
i.e., the left most bit (octet) is the most significant one. By XOR
|
||
we mean bitwise addition modulo 2 of binary strings, and || denotes
|
||
concatenation. In other words, if C = A || B, then the most
|
||
significant bits of C are the bits of A, and the least significant
|
||
bits of C equal the bits of B. Hexadecimal numbers are prefixed by
|
||
0x.
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 3]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
The word "encryption" includes also use of the NULL algorithm (which
|
||
in practice does leave the data in the clear).
|
||
|
||
With slight abuse of notation, we use the terms "message
|
||
authentication" and "authentication tag" as is common practice, even
|
||
though in some circumstances, e.g., group communication, the service
|
||
provided is actually only integrity protection and not data origin
|
||
authentication.
|
||
|
||
2. Goals and Features
|
||
|
||
The security goals for SRTP are to ensure:
|
||
|
||
* the confidentiality of the RTP and RTCP payloads, and
|
||
|
||
* the integrity of the entire RTP and RTCP packets, together with
|
||
protection against replayed packets.
|
||
|
||
These security services are optional and independent from each other,
|
||
except that SRTCP integrity protection is mandatory (malicious or
|
||
erroneous alteration of RTCP messages could otherwise disrupt the
|
||
processing of the RTP stream).
|
||
|
||
Other, functional, goals for the protocol are:
|
||
|
||
* a framework that permits upgrading with new cryptographic
|
||
transforms,
|
||
|
||
* low bandwidth cost, i.e., a framework preserving RTP header
|
||
compression efficiency,
|
||
|
||
and, asserted by the pre-defined transforms:
|
||
|
||
* a low computational cost,
|
||
|
||
* a small footprint (i.e., small code size and data memory for
|
||
keying information and replay lists),
|
||
|
||
* limited packet expansion to support the bandwidth economy goal,
|
||
|
||
* independence from the underlying transport, network, and physical
|
||
layers used by RTP, in particular high tolerance to packet loss
|
||
and re-ordering.
|
||
|
||
These properties ensure that SRTP is a suitable protection scheme for
|
||
RTP/RTCP in both wired and wireless scenarios.
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 4]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
2.1. Features
|
||
|
||
Besides the above mentioned direct goals, SRTP provides for some
|
||
additional features. They have been introduced to lighten the burden
|
||
on key management and to further increase security. They include:
|
||
|
||
* A single "master key" can provide keying material for
|
||
confidentiality and integrity protection, both for the SRTP stream
|
||
and the corresponding SRTCP stream. This is achieved with a key
|
||
derivation function (see Section 4.3), providing "session keys"
|
||
for the respective security primitive, securely derived from the
|
||
master key.
|
||
|
||
* In addition, the key derivation can be configured to periodically
|
||
refresh the session keys, which limits the amount of ciphertext
|
||
produced by a fixed key, available for an adversary to
|
||
cryptanalyze.
|
||
|
||
* "Salting keys" are used to protect against pre-computation and
|
||
time-memory tradeoff attacks [MF00] [BS00].
|
||
|
||
Detailed rationale for these features can be found in Section 7.
|
||
|
||
3. SRTP Framework
|
||
|
||
RTP is the Real-time Transport Protocol [RFC3550]. We define SRTP as
|
||
a profile of RTP. This profile is an extension to the RTP
|
||
Audio/Video Profile [RFC3551]. Except where explicitly noted, all
|
||
aspects of that profile apply, with the addition of the SRTP security
|
||
features. Conceptually, we consider SRTP to be a "bump in the stack"
|
||
implementation which resides between the RTP application and the
|
||
transport layer. SRTP intercepts RTP packets and then forwards an
|
||
equivalent SRTP packet on the sending side, and intercepts SRTP
|
||
packets and passes an equivalent RTP packet up the stack on the
|
||
receiving side.
|
||
|
||
Secure RTCP (SRTCP) provides the same security services to RTCP as
|
||
SRTP does to RTP. SRTCP message authentication is MANDATORY and
|
||
thereby protects the RTCP fields to keep track of membership, provide
|
||
feedback to RTP senders, or maintain packet sequence counters. SRTCP
|
||
is described in Section 3.4.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 5]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
3.1. Secure RTP
|
||
|
||
The format of an SRTP packet is illustrated in Figure 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
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|
||
|V=2|P|X| CC |M| PT | sequence number | |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| timestamp | |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| synchronization source (SSRC) identifier | |
|
||
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
|
||
| contributing source (CSRC) identifiers | |
|
||
| .... | |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| RTP extension (OPTIONAL) | |
|
||
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| | payload ... | |
|
||
| | +-------------------------------+ |
|
||
| | | RTP padding | RTP pad count | |
|
||
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|
||
| ~ SRTP MKI (OPTIONAL) ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| : authentication tag (RECOMMENDED) : |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| |
|
||
+- Encrypted Portion* Authenticated Portion ---+
|
||
|
||
Figure 1. The format of an SRTP packet. *Encrypted Portion is the
|
||
same size as the plaintext for the Section 4 pre-defined transforms.
|
||
|
||
The "Encrypted Portion" of an SRTP packet consists of the encryption
|
||
of the RTP payload (including RTP padding when present) of the
|
||
equivalent RTP packet. The Encrypted Portion MAY be the exact size
|
||
of the plaintext or MAY be larger. Figure 1 shows the RTP payload
|
||
including any possible padding for RTP [RFC3550].
|
||
|
||
None of the pre-defined encryption transforms uses any padding; for
|
||
these, the RTP and SRTP payload sizes match exactly. New transforms
|
||
added to SRTP (following Section 6) may require padding, and may
|
||
hence produce larger payloads. RTP provides its own padding format
|
||
(as seen in Fig. 1), which due to the padding indicator in the RTP
|
||
header has merits in terms of compactness relative to paddings using
|
||
prefix-free codes. This RTP padding SHALL be the default method for
|
||
transforms requiring padding. Transforms MAY specify other padding
|
||
methods, and MUST then specify the amount, format, and processing of
|
||
their padding. It is important to note that encryption transforms
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 6]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
that use padding are vulnerable to subtle attacks, especially when
|
||
message authentication is not used [V02]. Each specification for a
|
||
new encryption transform needs to carefully consider and describe the
|
||
security implications of the padding that it uses. Message
|
||
authentication codes define their own padding, so this default does
|
||
not apply to authentication transforms.
|
||
|
||
The OPTIONAL MKI and the RECOMMENDED authentication tag are the only
|
||
fields defined by SRTP that are not in RTP. Only 8-bit alignment is
|
||
assumed.
|
||
|
||
MKI (Master Key Identifier): configurable length, OPTIONAL. The
|
||
MKI is defined, signaled, and used by key management. The
|
||
MKI identifies the master key from which the session
|
||
key(s) were derived that authenticate and/or encrypt the
|
||
particular packet. Note that the MKI SHALL NOT identify
|
||
the SRTP cryptographic context, which is identified
|
||
according to Section 3.2.3. The MKI MAY be used by key
|
||
management for the purposes of re-keying, identifying a
|
||
particular master key within the cryptographic context
|
||
(Section 3.2.1).
|
||
|
||
Authentication tag: configurable length, RECOMMENDED. The
|
||
authentication tag is used to carry message authentication
|
||
data. The Authenticated Portion of an SRTP packet
|
||
consists of the RTP header followed by the Encrypted
|
||
Portion of the SRTP packet. Thus, if both encryption and
|
||
authentication are applied, encryption SHALL be applied
|
||
before authentication on the sender side and conversely on
|
||
the receiver side. The authentication tag provides
|
||
authentication of the RTP header and payload, and it
|
||
indirectly provides replay protection by authenticating
|
||
the sequence number. Note that the MKI is not integrity
|
||
protected as this does not provide any extra protection.
|
||
|
||
3.2. SRTP Cryptographic Contexts
|
||
|
||
Each SRTP stream requires the sender and receiver to maintain
|
||
cryptographic state information. This information is called the
|
||
"cryptographic context".
|
||
|
||
SRTP uses two types of keys: session keys and master keys. By a
|
||
"session key", we mean a key which is used directly in a
|
||
cryptographic transform (e.g., encryption or message authentication),
|
||
and by a "master key", we mean a random bit string (given by the key
|
||
management protocol) from which session keys are derived in a
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 7]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
cryptographically secure way. The master key(s) and other parameters
|
||
in the cryptographic context are provided by key management
|
||
mechanisms external to SRTP, see Section 8.
|
||
|
||
3.2.1. Transform-independent parameters
|
||
|
||
Transform-independent parameters are present in the cryptographic
|
||
context independently of the particular encryption or authentication
|
||
transforms that are used. The transform-independent parameters of
|
||
the cryptographic context for SRTP consist of:
|
||
|
||
* a 32-bit unsigned rollover counter (ROC), which records how many
|
||
times the 16-bit RTP sequence number has been reset to zero after
|
||
passing through 65,535. Unlike the sequence number (SEQ), which
|
||
SRTP extracts from the RTP packet header, the ROC is maintained by
|
||
SRTP as described in Section 3.3.1.
|
||
|
||
We define the index of the SRTP packet corresponding to a given
|
||
ROC and RTP sequence number to be the 48-bit quantity
|
||
|
||
i = 2^16 * ROC + SEQ.
|
||
|
||
* for the receiver only, a 16-bit sequence number s_l, which can be
|
||
thought of as the highest received RTP sequence number (see
|
||
Section 3.3.1 for its handling), which SHOULD be authenticated
|
||
since message authentication is RECOMMENDED,
|
||
|
||
* an identifier for the encryption algorithm, i.e., the cipher and
|
||
its mode of operation,
|
||
|
||
* an identifier for the message authentication algorithm,
|
||
|
||
* a replay list, maintained by the receiver only (when
|
||
authentication and replay protection are provided), containing
|
||
indices of recently received and authenticated SRTP packets,
|
||
|
||
* an MKI indicator (0/1) as to whether an MKI is present in SRTP and
|
||
SRTCP packets,
|
||
|
||
* if the MKI indicator is set to one, the length (in octets) of the
|
||
MKI field, and (for the sender) the actual value of the currently
|
||
active MKI (the value of the MKI indicator and length MUST be kept
|
||
fixed for the lifetime of the context),
|
||
|
||
* the master key(s), which MUST be random and kept secret,
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 8]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
* for each master key, there is a counter of the number of SRTP
|
||
packets that have been processed (sent) with that master key
|
||
(essential for security, see Sections 3.3.1 and 9),
|
||
|
||
* non-negative integers n_e, and n_a, determining the length of the
|
||
session keys for encryption, and message authentication.
|
||
|
||
In addition, for each master key, an SRTP stream MAY use the
|
||
following associated values:
|
||
|
||
* a master salt, to be used in the key derivation of session keys.
|
||
This value, when used, MUST be random, but MAY be public. Use of
|
||
master salt is strongly RECOMMENDED, see Section 9.2. A "NULL"
|
||
salt is treated as 00...0.
|
||
|
||
* an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate",
|
||
where an unspecified value is treated as zero. The constraint to
|
||
be a power of 2 simplifies the session-key derivation
|
||
implementation, see Section 4.3.
|
||
|
||
* an MKI value,
|
||
|
||
* <From, To> values, specifying the lifetime for a master key,
|
||
expressed in terms of the two 48-bit index values inside whose
|
||
range (including the range end-points) the master key is valid.
|
||
For the use of <From, To>, see Section 8.1.1. <From, To> is an
|
||
alternative to the MKI and assumes that a master key is in one-
|
||
to-one correspondence with the SRTP session key on which the
|
||
<From, To> range is defined.
|
||
|
||
SRTCP SHALL by default share the crypto context with SRTP, except:
|
||
|
||
* no rollover counter and s_l-value need to be maintained as the
|
||
RTCP index is explicitly carried in each SRTCP packet,
|
||
|
||
* a separate replay list is maintained (when replay protection is
|
||
provided),
|
||
|
||
* SRTCP maintains a separate counter for its master key (even if the
|
||
master key is the same as that for SRTP, see below), as a means to
|
||
maintain a count of the number of SRTCP packets that have been
|
||
processed with that key.
|
||
|
||
Note in particular that the master key(s) MAY be shared between SRTP
|
||
and the corresponding SRTCP, if the pre-defined transforms (including
|
||
the key derivation) are used but the session key(s) MUST NOT be so
|
||
shared.
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 9]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
In addition, there can be cases (see Sections 8 and 9.1) where
|
||
several SRTP streams within a given RTP session, identified by their
|
||
synchronization source (SSRCs, which is part of the RTP header),
|
||
share most of the crypto context parameters (including possibly
|
||
master and session keys). In such cases, just as in the normal
|
||
SRTP/SRTCP parameter sharing above, separate replay lists and packet
|
||
counters for each stream (SSRC) MUST still be maintained. Also,
|
||
separate SRTP indices MUST then be maintained.
|
||
|
||
A summary of parameters, pre-defined transforms, and default values
|
||
for the above parameters (and other SRTP parameters) can be found in
|
||
Sections 5 and 8.2.
|
||
|
||
3.2.2. Transform-dependent parameters
|
||
|
||
All encryption, authentication/integrity, and key derivation
|
||
parameters are defined in the transforms section (Section 4).
|
||
Typical examples of such parameters are block size of ciphers,
|
||
session keys, data for the Initialization Vector (IV) formation, etc.
|
||
Future SRTP transform specifications MUST include a section to list
|
||
the additional cryptographic context's parameters for that transform,
|
||
if any.
|
||
|
||
3.2.3. Mapping SRTP Packets to Cryptographic Contexts
|
||
|
||
Recall that an RTP session for each participant is defined [RFC3550]
|
||
by a pair of destination transport addresses (one network address
|
||
plus a port pair for RTP and RTCP), and that a multimedia session is
|
||
defined as a collection of RTP sessions. For example, a particular
|
||
multimedia session could include an audio RTP session, a video RTP
|
||
session, and a text RTP session.
|
||
|
||
A cryptographic context SHALL be uniquely identified by the triplet
|
||
context identifier:
|
||
|
||
context id = <SSRC, destination network address, destination
|
||
transport port number>
|
||
|
||
where the destination network address and the destination transport
|
||
port are the ones in the SRTP packet. It is assumed that, when
|
||
presented with this information, the key management returns a context
|
||
with the information as described in Section 3.2.
|
||
|
||
As noted above, SRTP and SRTCP by default share the bulk of the
|
||
parameters in the cryptographic context. Thus, retrieving the crypto
|
||
context parameters for an SRTCP stream in practice may imply a
|
||
binding to the correspondent SRTP crypto context. It is up to the
|
||
implementation to assure such binding, since the RTCP port may not be
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 10]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
directly deducible from the RTP port only. Alternatively, the key
|
||
management may choose to provide separate SRTP- and SRTCP- contexts,
|
||
duplicating the common parameters (such as master key(s)). The
|
||
latter approach then also enables SRTP and SRTCP to use, e.g.,
|
||
distinct transforms, if so desired. Similar considerations arise
|
||
when multiple SRTP streams, forming part of one single RTP session,
|
||
share keys and other parameters.
|
||
|
||
If no valid context can be found for a packet corresponding to a
|
||
certain context identifier, that packet MUST be discarded.
|
||
|
||
3.3. SRTP Packet Processing
|
||
|
||
The following applies to SRTP. SRTCP is described in Section 3.4.
|
||
|
||
Assuming initialization of the cryptographic context(s) has taken
|
||
place via key management, the sender SHALL do the following to
|
||
construct an SRTP packet:
|
||
|
||
1. Determine which cryptographic context to use as described in
|
||
Section 3.2.3.
|
||
|
||
2. Determine the index of the SRTP packet using the rollover counter,
|
||
the highest sequence number in the cryptographic context, and the
|
||
sequence number in the RTP packet, as described in Section 3.3.1.
|
||
|
||
3. Determine the master key and master salt. This is done using the
|
||
index determined in the previous step or the current MKI in the
|
||
cryptographic context, according to Section 8.1.
|
||
|
||
4. Determine the session keys and session salt (if they are used by
|
||
the transform) as described in Section 4.3, using master key,
|
||
master salt, key_derivation_rate, and session key-lengths in the
|
||
cryptographic context with the index, determined in Steps 2 and 3.
|
||
|
||
5. Encrypt the RTP payload to produce the Encrypted Portion of the
|
||
packet (see Section 4.1, for the defined ciphers). This step uses
|
||
the encryption algorithm indicated in the cryptographic context,
|
||
the session encryption key and the session salt (if used) found in
|
||
Step 4 together with the index found in Step 2.
|
||
|
||
6. If the MKI indicator is set to one, append the MKI to the packet.
|
||
|
||
7. For message authentication, compute the authentication tag for the
|
||
Authenticated Portion of the packet, as described in Section 4.2.
|
||
This step uses the current rollover counter, the authentication
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 11]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
algorithm indicated in the cryptographic context, and the session
|
||
authentication key found in Step 4. Append the authentication tag
|
||
to the packet.
|
||
|
||
8. If necessary, update the ROC as in Section 3.3.1, using the packet
|
||
index determined in Step 2.
|
||
|
||
To authenticate and decrypt an SRTP packet, the receiver SHALL do the
|
||
following:
|
||
|
||
1. Determine which cryptographic context to use as described in
|
||
Section 3.2.3.
|
||
|
||
2. Run the algorithm in Section 3.3.1 to get the index of the SRTP
|
||
packet. The algorithm uses the rollover counter and highest
|
||
sequence number in the cryptographic context with the sequence
|
||
number in the SRTP packet, as described in Section 3.3.1.
|
||
|
||
3. Determine the master key and master salt. If the MKI indicator in
|
||
the context is set to one, use the MKI in the SRTP packet,
|
||
otherwise use the index from the previous step, according to
|
||
Section 8.1.
|
||
|
||
4. Determine the session keys, and session salt (if used by the
|
||
transform) as described in Section 4.3, using master key, master
|
||
salt, key_derivation_rate and session key-lengths in the
|
||
cryptographic context with the index, determined in Steps 2 and 3.
|
||
|
||
5. For message authentication and replay protection, first check if
|
||
the packet has been replayed (Section 3.3.2), using the Replay
|
||
List and the index as determined in Step 2. If the packet is
|
||
judged to be replayed, then the packet MUST be discarded, and the
|
||
event SHOULD be logged.
|
||
|
||
Next, perform verification of the authentication tag, using the
|
||
rollover counter from Step 2, the authentication algorithm
|
||
indicated in the cryptographic context, and the session
|
||
authentication key from Step 4. If the result is "AUTHENTICATION
|
||
FAILURE" (see Section 4.2), the packet MUST be discarded from
|
||
further processing and the event SHOULD be logged.
|
||
|
||
6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for
|
||
the defined ciphers), using the decryption algorithm indicated in
|
||
the cryptographic context, the session encryption key and salt (if
|
||
used) found in Step 4 with the index from Step 2.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 12]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
7. Update the rollover counter and highest sequence number, s_l, in
|
||
the cryptographic context as in Section 3.3.1, using the packet
|
||
index estimated in Step 2. If replay protection is provided, also
|
||
update the Replay List as described in Section 3.3.2.
|
||
|
||
8. When present, remove the MKI and authentication tag fields from
|
||
the packet.
|
||
|
||
3.3.1. Packet Index Determination, and ROC, s_l Update
|
||
|
||
SRTP implementations use an "implicit" packet index for sequencing,
|
||
i.e., not all of the index is explicitly carried in the SRTP packet.
|
||
For the pre-defined transforms, the index i is used in replay
|
||
protection (Section 3.3.2), encryption (Section 4.1), message
|
||
authentication (Section 4.2), and for the key derivation (Section
|
||
4.3).
|
||
|
||
When the session starts, the sender side MUST set the rollover
|
||
counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps
|
||
modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32
|
||
(see security aspects below). The sender's packet index is then
|
||
defined as
|
||
|
||
i = 2^16 * ROC + SEQ.
|
||
|
||
Receiver-side implementations use the RTP sequence number to
|
||
determine the correct index of a packet, which is the location of the
|
||
packet in the sequence of all SRTP packets. A robust approach for
|
||
the proper use of a rollover counter requires its handling and use to
|
||
be well defined. In particular, out-of-order RTP packets with
|
||
sequence numbers close to 2^16 or zero must be properly handled.
|
||
|
||
The index estimate is based on the receiver's locally maintained ROC
|
||
and s_l values. At the setup of the session, the ROC MUST be set to
|
||
zero. Receivers joining an on-going session MUST be given the
|
||
current ROC value using out-of-band signaling such as key-management
|
||
signaling. Furthermore, the receiver SHALL initialize s_l to the RTP
|
||
sequence number (SEQ) of the first observed SRTP packet (unless the
|
||
initial value is provided by out of band signaling such as key
|
||
management).
|
||
|
||
On consecutive SRTP packets, the receiver SHOULD estimate the index
|
||
as
|
||
i = 2^16 * v + SEQ,
|
||
|
||
where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32)
|
||
such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC
|
||
+ s_l (see Appendix A for pseudocode).
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 13]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
After the packet has been processed and authenticated (when enabled
|
||
for SRTP packets for the session), the receiver MUST use v to
|
||
conditionally update its s_l and ROC variables as follows. If
|
||
v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC,
|
||
then s_l is set to SEQ if and only if SEQ is larger than the current
|
||
s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is
|
||
set to SEQ and ROC is set to v.
|
||
|
||
After a re-keying occurs (changing to a new master key), the rollover
|
||
counter always maintains its sequence of values, i.e., it MUST NOT be
|
||
reset to zero.
|
||
|
||
As the rollover counter is 32 bits long and the sequence number is 16
|
||
bits long, the maximum number of packets belonging to a given SRTP
|
||
stream that can be secured with the same key is 2^48 using the pre-
|
||
defined transforms. After that number of SRTP packets have been sent
|
||
with a given (master or session) key, the sender MUST NOT send any
|
||
more packets with that key. (There exists a similar limit for SRTCP,
|
||
which in practice may be more restrictive, see Section 9.2.) This
|
||
limitation enforces a security benefit by providing an upper bound on
|
||
the amount of traffic that can pass before cryptographic keys are
|
||
changed. Re-keying (see Section 8.1) MUST be triggered, before this
|
||
amount of traffic, and MAY be triggered earlier, e.g., for increased
|
||
security and access control to media. Recurring key derivation by
|
||
means of a non-zero key_derivation_rate (see Section 4.3), also gives
|
||
stronger security but does not change the above absolute maximum
|
||
value.
|
||
|
||
On the receiver side, there is a caveat to updating s_l and ROC: if
|
||
message authentication is not present, neither the initialization of
|
||
s_l, nor the ROC update can be made completely robust. The
|
||
receiver's "implicit index" approach works for the pre-defined
|
||
transforms as long as the reorder and loss of the packets are not too
|
||
great and bit-errors do not occur in unfortunate ways. In
|
||
particular, 2^15 packets would need to be lost, or a packet would
|
||
need to be 2^15 packets out of sequence before synchronization is
|
||
lost. Such drastic loss or reorder is likely to disrupt the RTP
|
||
application itself.
|
||
|
||
The algorithm for the index estimate and ROC update is a matter of
|
||
implementation, and should take into consideration the environment
|
||
(e.g., packet loss rate) and the cases when synchronization is likely
|
||
to be lost, e.g., when the initial sequence number (randomly chosen
|
||
by RTP) is not known in advance (not sent in the key management
|
||
protocol) but may be near to wrap modulo 2^16.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 14]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
A more elaborate and more robust scheme than the one given above is
|
||
the handling of RTP's own "rollover counter", see Appendix A.1 of
|
||
[RFC3550].
|
||
|
||
3.3.2. Replay Protection
|
||
|
||
Secure replay protection is only possible when integrity protection
|
||
is present. It is RECOMMENDED to use replay protection, both for RTP
|
||
and RTCP, as integrity protection alone cannot assure security
|
||
against replay attacks.
|
||
|
||
A packet is "replayed" when it is stored by an adversary, and then
|
||
re-injected into the network. When message authentication is
|
||
provided, SRTP protects against such attacks through a Replay List.
|
||
Each SRTP receiver maintains a Replay List, which conceptually
|
||
contains the indices of all of the packets which have been received
|
||
and authenticated. In practice, the list can use a "sliding window"
|
||
approach, so that a fixed amount of storage suffices for replay
|
||
protection. Packet indices which lag behind the packet index in the
|
||
context by more than SRTP-WINDOW-SIZE can be assumed to have been
|
||
received, where SRTP-WINDOW-SIZE is a receiver-side, implementation-
|
||
dependent parameter and MUST be at least 64, but which MAY be set to
|
||
a higher value.
|
||
|
||
The receiver checks the index of an incoming packet against the
|
||
replay list and the window. Only packets with index ahead of the
|
||
window, or, inside the window but not already received, SHALL be
|
||
accepted.
|
||
|
||
After the packet has been authenticated (if necessary the window is
|
||
first moved ahead), the replay list SHALL be updated with the new
|
||
index.
|
||
|
||
The Replay List can be efficiently implemented by using a bitmap to
|
||
represent which packets have been received, as described in the
|
||
Security Architecture for IP [RFC2401].
|
||
|
||
3.4. Secure RTCP
|
||
|
||
Secure RTCP follows the definition of Secure RTP. SRTCP adds three
|
||
mandatory new fields (the SRTCP index, an "encrypt-flag", and the
|
||
authentication tag) and one optional field (the MKI) to the RTCP
|
||
packet definition. The three mandatory fields MUST be appended to an
|
||
RTCP packet in order to form an equivalent SRTCP packet. The added
|
||
fields follow any other profile-specific extensions.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 15]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
According to Section 6.1 of [RFC3550], there is a REQUIRED packet
|
||
format for compound packets. SRTCP MUST be given packets according
|
||
to that requirement in the sense that the first part MUST be a sender
|
||
report or a receiver report. However, the RTCP encryption prefix (a
|
||
random 32-bit quantity) specified in that Section MUST NOT be used
|
||
since, as is stated there, it is only applicable to the encryption
|
||
method specified in [RFC3550] and is not needed by the cryptographic
|
||
mechanisms used in SRTP.
|
||
|
||
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
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|
||
|V=2|P| RC | PT=SR or RR | length | |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| SSRC of sender | |
|
||
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
|
||
| ~ sender info ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| ~ report block 1 ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| ~ report block 2 ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| ~ ... ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| |V=2|P| SC | PT=SDES=202 | length | |
|
||
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
|
||
| | SSRC/CSRC_1 | |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| ~ SDES items ~ |
|
||
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
|
||
| ~ ... ~ |
|
||
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
|
||
| |E| SRTCP index | |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|
||
| ~ SRTCP MKI (OPTIONAL) ~ |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| : authentication tag : |
|
||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
||
| |
|
||
+-- Encrypted Portion Authenticated Portion -----+
|
||
|
||
|
||
Figure 2. An example of the format of a Secure RTCP packet,
|
||
consisting of an underlying RTCP compound packet with a Sender Report
|
||
and SDES packet.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 16]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
The Encrypted Portion of an SRTCP packet consists of the encryption
|
||
(Section 4.1) of the RTCP payload of the equivalent compound RTCP
|
||
packet, from the first RTCP packet, i.e., from the ninth (9) octet to
|
||
the end of the compound packet. The Authenticated Portion of an
|
||
SRTCP packet consists of the entire equivalent (eventually compound)
|
||
RTCP packet, the E flag, and the SRTCP index (after any encryption
|
||
has been applied to the payload).
|
||
|
||
The added fields are:
|
||
|
||
E-flag: 1 bit, REQUIRED
|
||
The E-flag indicates if the current SRTCP packet is
|
||
encrypted or unencrypted. Section 9.1 of [RFC3550] allows
|
||
the split of a compound RTCP packet into two lower-layer
|
||
packets, one to be encrypted and one to be sent in the
|
||
clear. The E bit set to "1" indicates encrypted packet, and
|
||
"0" indicates non-encrypted packet.
|
||
|
||
SRTCP index: 31 bits, REQUIRED
|
||
The SRTCP index is a 31-bit counter for the SRTCP packet.
|
||
The index is explicitly included in each packet, in contrast
|
||
to the "implicit" index approach used for SRTP. The SRTCP
|
||
index MUST be set to zero before the first SRTCP packet is
|
||
sent, and MUST be incremented by one, modulo 2^31, after
|
||
each SRTCP packet is sent. In particular, after a re-key,
|
||
the SRTCP index MUST NOT be reset to zero again.
|
||
|
||
Authentication Tag: configurable length, REQUIRED
|
||
The authentication tag is used to carry message
|
||
authentication data.
|
||
|
||
MKI: configurable length, OPTIONAL
|
||
The MKI is the Master Key Indicator, and functions according
|
||
to the MKI definition in Section 3.
|
||
|
||
SRTCP uses the cryptographic context parameters and packet processing
|
||
of SRTP by default, with the following changes:
|
||
|
||
* The receiver does not need to "estimate" the index, as it is
|
||
explicitly signaled in the packet.
|
||
|
||
* Pre-defined SRTCP encryption is as specified in Section 4.1, but
|
||
using the definition of the SRTCP Encrypted Portion given in this
|
||
section, and using the SRTCP index as the index i. The encryption
|
||
transform and related parameters SHALL by default be the same
|
||
selected for the protection of the associated SRTP stream(s),
|
||
while the NULL algorithm SHALL be applied to the RTCP packets not
|
||
to be encrypted. SRTCP may have a different encryption transform
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 17]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
than the one used by the corresponding SRTP. The expected use for
|
||
this feature is when the former has NULL-encryption and the latter
|
||
has a non NULL-encryption.
|
||
|
||
The E-flag is assigned a value by the sender depending on whether the
|
||
packet was encrypted or not.
|
||
|
||
* SRTCP decryption is performed as in Section 4, but only if the E
|
||
flag is equal to 1. If so, the Encrypted Portion is decrypted,
|
||
using the SRTCP index as the index i. In case the E-flag is 0,
|
||
the payload is simply left unmodified.
|
||
|
||
* SRTCP replay protection is as defined in Section 3.3.2, but using
|
||
the SRTCP index as the index i and a separate Replay List that is
|
||
specific to SRTCP.
|
||
|
||
* The pre-defined SRTCP authentication tag is specified as in
|
||
Section 4.2, but with the Authenticated Portion of the SRTCP
|
||
packet given in this section (which includes the index). The
|
||
authentication transform and related parameters (e.g., key size)
|
||
SHALL by default be the same as selected for the protection of the
|
||
associated SRTP stream(s).
|
||
|
||
* In the last step of the processing, only the sender needs to
|
||
update the value of the SRTCP index by incrementing it modulo 2^31
|
||
and for security reasons the sender MUST also check the number of
|
||
SRTCP packets processed, see Section 9.2.
|
||
|
||
Message authentication for RTCP is REQUIRED, as it is the control
|
||
protocol (e.g., it has a BYE packet) for RTP.
|
||
|
||
Precautions must be taken so that the packet expansion in SRTCP (due
|
||
to the added fields) does not cause SRTCP messages to use more than
|
||
their share of RTCP bandwidth. To avoid this, the following two
|
||
measures MUST be taken:
|
||
|
||
1. When initializing the RTCP variable "avg_rtcp_size" defined in
|
||
chapter 6.3 of [RFC3550], it MUST include the size of the fields
|
||
that will be added by SRTCP (index, E-bit, authentication tag, and
|
||
when present, the MKI).
|
||
|
||
2. When updating the "avg_rtcp_size" using the variable "packet_size"
|
||
(section 6.3.3 of [RFC3550]), the value of "packet_size" MUST
|
||
include the size of the additional fields added by SRTCP.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 18]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
With these measures in place the SRTCP messages will not use more
|
||
than the allotted bandwidth. The effect of the size of the added
|
||
fields on the SRTCP traffic will be that messages will be sent with
|
||
longer packet intervals. The increase in the intervals will be
|
||
directly proportional to size of the added fields. For the pre-
|
||
defined transforms, the size of the added fields will be at least 14
|
||
octets, and upper bounded depending on MKI and the authentication tag
|
||
sizes.
|
||
|
||
4. Pre-Defined Cryptographic Transforms
|
||
|
||
While there are numerous encryption and message authentication
|
||
algorithms that can be used in SRTP, below we define default
|
||
algorithms in order to avoid the complexity of specifying the
|
||
encodings for the signaling of algorithm and parameter identifiers.
|
||
The defined algorithms have been chosen as they fulfill the goals
|
||
listed in Section 2. Recommendations on how to extend SRTP with new
|
||
transforms are given in Section 6.
|
||
|
||
4.1. Encryption
|
||
|
||
The following parameters are common to both pre-defined, non-NULL,
|
||
encryption transforms specified in this section.
|
||
|
||
* BLOCK_CIPHER-MODE indicates the block cipher used and its mode of
|
||
operation
|
||
* n_b is the bit-size of the block for the block cipher
|
||
* k_e is the session encryption key
|
||
* n_e is the bit-length of k_e
|
||
* k_s is the session salting key
|
||
* n_s is the bit-length of k_s
|
||
* SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a
|
||
non-negative integer, specified by the message authentication code
|
||
in use.
|
||
|
||
The distinct session keys and salts for SRTP/SRTCP are by default
|
||
derived as specified in Section 4.3.
|
||
|
||
The encryption transforms defined in SRTP map the SRTP packet index
|
||
and secret key into a pseudo-random keystream segment. Each
|
||
keystream segment encrypts a single RTP packet. The process of
|
||
encrypting a packet consists of generating the keystream segment
|
||
corresponding to the packet, and then bitwise exclusive-oring that
|
||
keystream segment onto the payload of the RTP packet to produce the
|
||
Encrypted Portion of the SRTP packet. In case the payload size is
|
||
not an integer multiple of n_b bits, the excess (least significant)
|
||
bits of the keystream are simply discarded. Decryption is done the
|
||
same way, but swapping the roles of the plaintext and ciphertext.
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 19]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
+----+ +------------------+---------------------------------+
|
||
| KG |-->| Keystream Prefix | Keystream Suffix |---+
|
||
+----+ +------------------+---------------------------------+ |
|
||
|
|
||
+---------------------------------+ v
|
||
| Payload of RTP Packet |->(*)
|
||
+---------------------------------+ |
|
||
|
|
||
+---------------------------------+ |
|
||
| Encrypted Portion of SRTP Packet|<--+
|
||
+---------------------------------+
|
||
|
||
Figure 3: Default SRTP Encryption Processing. Here KG denotes the
|
||
keystream generator, and (*) denotes bitwise exclusive-or.
|
||
|
||
The definition of how the keystream is generated, given the index,
|
||
depends on the cipher and its mode of operation. Below, two such
|
||
keystream generators are defined. The NULL cipher is also defined,
|
||
to be used when encryption of RTP is not required.
|
||
|
||
The SRTP definition of the keystream is illustrated in Figure 3. The
|
||
initial octets of each keystream segment MAY be reserved for use in a
|
||
message authentication code, in which case the keystream used for
|
||
encryption starts immediately after the last reserved octet. The
|
||
initial reserved octets are called the "keystream prefix" (not to be
|
||
confused with the "encryption prefix" of [RFC3550, Section 6.1]), and
|
||
the remaining octets are called the "keystream suffix". The
|
||
keystream prefix MUST NOT be used for encryption. The process is
|
||
illustrated in Figure 3.
|
||
|
||
The number of octets in the keystream prefix is denoted as
|
||
SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive,
|
||
non-zero value of SRTP_PREFIX_LENGTH. This means that, even if
|
||
confidentiality is not to be provided, the keystream generator output
|
||
may still need to be computed for packet authentication, in which
|
||
case the default keystream generator (mode) SHALL be used.
|
||
|
||
The default cipher is the Advanced Encryption Standard (AES) [AES],
|
||
and we define two modes of running AES, (1) Segmented Integer Counter
|
||
Mode AES and (2) AES in f8-mode. In the remainder of this section,
|
||
let E(k,x) be AES applied to key k and input block x.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 20]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
4.1.1. AES in Counter Mode
|
||
|
||
Conceptually, counter mode [AES-CTR] consists of encrypting
|
||
successive integers. The actual definition is somewhat more
|
||
complicated, in order to randomize the starting point of the integer
|
||
sequence. Each packet is encrypted with a distinct keystream
|
||
segment, which SHALL be computed as follows.
|
||
|
||
A keystream segment SHALL be the concatenation of the 128-bit output
|
||
blocks of the AES cipher in the encrypt direction, using key k = k_e,
|
||
in which the block indices are in increasing order. Symbolically,
|
||
each keystream segment looks like
|
||
|
||
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
|
||
|
||
where the 128-bit integer value IV SHALL be defined by the SSRC, the
|
||
SRTP packet index i, and the SRTP session salting key k_s, as below.
|
||
|
||
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
|
||
|
||
Each of the three terms in the XOR-sum above is padded with as many
|
||
leading zeros as needed to make the operation well-defined,
|
||
considered as a 128-bit value.
|
||
|
||
The inclusion of the SSRC allows the use of the same key to protect
|
||
distinct SRTP streams within the same RTP session, see the security
|
||
caveats in Section 9.1.
|
||
|
||
In the case of SRTCP, the SSRC of the first header of the compound
|
||
packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s
|
||
SHALL be replaced by the SRTCP encryption session key and salt.
|
||
|
||
Note that the initial value, IV, is fixed for each packet and is
|
||
formed by "reserving" 16 zeros in the least significant bits for the
|
||
purpose of the counter. The number of blocks of keystream generated
|
||
for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream
|
||
re-use, see below. The AES has a block size of 128 bits, so 2^16
|
||
output blocks are sufficient to generate the 2^23 bits of keystream
|
||
needed to encrypt the largest possible RTP packet (except for IPv6
|
||
"jumbograms" [RFC2675], which are not likely to be used for RTP-based
|
||
multimedia traffic). This restriction on the maximum bit-size of the
|
||
packet that can be encrypted ensures the security of the encryption
|
||
method by limiting the effectiveness of probabilistic attacks [BDJR].
|
||
|
||
For a particular Counter Mode key, each IV value used as an input
|
||
MUST be distinct, in order to avoid the security exposure of a two-
|
||
time pad situation (Section 9.1). To satisfy this constraint, an
|
||
implementation MUST ensure that the combination of the SRTP packet
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 21]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
index of ROC || SEQ, and the SSRC used in the construction of the IV
|
||
are distinct for any particular key. The failure to ensure this
|
||
uniqueness could be catastrophic for Secure RTP. This is in contrast
|
||
to the situation for RTP itself, which may be able to tolerate such
|
||
failures. It is RECOMMENDED that, if a dedicated security module is
|
||
present, the RTP sequence numbers and SSRC either be generated or
|
||
checked by that module (i.e., sequence-number and SSRC processing in
|
||
an SRTP system needs to be protected as well as the key).
|
||
|
||
4.1.2. AES in f8-mode
|
||
|
||
To encrypt UMTS (Universal Mobile Telecommunications System, as 3G
|
||
networks) data, a solution (see [f8-a] [f8-b]) known as the f8-
|
||
algorithm has been developed. On a high level, the proposed scheme
|
||
is a variant of Output Feedback Mode (OFB) [HAC], with a more
|
||
elaborate initialization and feedback function. As in normal OFB,
|
||
the core consists of a block cipher. We also define here the use of
|
||
AES as a block cipher to be used in what we shall call "f8-mode of
|
||
operation" RTP encryption. The AES f8-mode SHALL use the same
|
||
default sizes for session key and salt as AES counter mode.
|
||
|
||
Figure 4 shows the structure of block cipher, E, running in f8-mode.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 22]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
IV
|
||
|
|
||
v
|
||
+------+
|
||
| |
|
||
+--->| E |
|
||
| +------+
|
||
| |
|
||
m -> (*) +-----------+-------------+-- ... ------+
|
||
| IV' | | | |
|
||
| | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*)
|
||
| | | | |
|
||
| | +-> (*) +-> (*) ... +-> (*)
|
||
| | | | | | | |
|
||
| v | v | v | v
|
||
| +------+ | +------+ | +------+ | +------+
|
||
k_e ---+--->| E | | | E | | | E | | | E |
|
||
| | | | | | | | | | |
|
||
+------+ | +------+ | +------+ | +------+
|
||
| | | | | | |
|
||
+------+ +--------+ +-- ... ----+ |
|
||
| | | |
|
||
v v v v
|
||
S(0) S(1) S(2) . . . S(L-1)
|
||
|
||
Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR).
|
||
The figure represents the KG in Figure 3, when AES-f8 is used.
|
||
|
||
4.1.2.1. f8 Keystream Generation
|
||
|
||
The Initialization Vector (IV) SHALL be determined as described in
|
||
Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP).
|
||
|
||
Let IV', S(j), and m denote n_b-bit blocks. The keystream,
|
||
S(0) ||... || S(L-1), for an N-bit message SHALL be defined by
|
||
setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0. For
|
||
j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it
|
||
is not already an integer) compute
|
||
|
||
S(j) = E(k_e, IV' XOR j XOR S(j-1))
|
||
|
||
Notice that the IV is not used directly. Instead it is fed through E
|
||
under another key to produce an internal, "masked" value (denoted
|
||
IV') to prevent an attacker from gaining known input/output pairs.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 23]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
The role of the internal counter, j, is to prevent short keystream
|
||
cycles. The value of the key mask m SHALL be
|
||
|
||
m = k_s || 0x555..5,
|
||
|
||
i.e., the session salting key, appended by the binary pattern 0101..
|
||
to fill out the entire desired key size, n_e.
|
||
|
||
The sender SHOULD NOT generate more than 2^32 blocks, which is
|
||
sufficient to generate 2^39 bits of keystream. Unlike counter mode,
|
||
there is no absolute threshold above (below) which f8 is guaranteed
|
||
to be insecure (secure). The above bound has been chosen to limit,
|
||
with sufficient security margin, the probability of degenerative
|
||
behavior in the f8 keystream generation.
|
||
|
||
4.1.2.2. f8 SRTP IV Formation
|
||
|
||
The purpose of the following IV formation is to provide a feature
|
||
which we call implicit header authentication (IHA), see Section 9.5.
|
||
|
||
The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following
|
||
way:
|
||
|
||
IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC
|
||
|
||
M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from
|
||
the cryptographic context.
|
||
|
||
The presence of the SSRC as part of the IV allows AES-f8 to be used
|
||
when a master key is shared between multiple streams within the same
|
||
RTP session, see Section 9.1.
|
||
|
||
4.1.2.3. f8 SRTCP IV Formation
|
||
|
||
The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the
|
||
following way:
|
||
|
||
IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC
|
||
|
||
where V, P, RC, PT, length, SSRC SHALL be taken from the first header
|
||
in the RTCP compound packet. E and SRTCP index are the 1-bit and
|
||
31-bit fields added to the packet.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 24]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
4.1.3. NULL Cipher
|
||
|
||
The NULL cipher is used when no confidentiality for RTP/RTCP is
|
||
requested. The keystream can be thought of as "000..0", i.e., the
|
||
encryption SHALL simply copy the plaintext input into the ciphertext
|
||
output.
|
||
|
||
4.2. Message Authentication and Integrity
|
||
|
||
Throughout this section, M will denote data to be integrity
|
||
protected. In the case of SRTP, M SHALL consist of the Authenticated
|
||
Portion of the packet (as specified in Figure 1) concatenated with
|
||
the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M
|
||
SHALL consist of the Authenticated Portion (as specified in Figure 2)
|
||
only.
|
||
|
||
Common parameters:
|
||
|
||
* AUTH_ALG is the authentication algorithm
|
||
* k_a is the session message authentication key
|
||
* n_a is the bit-length of the authentication key
|
||
* n_tag is the bit-length of the output authentication tag
|
||
* SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
|
||
defined above, a parameter of AUTH_ALG
|
||
|
||
The distinct session authentication keys for SRTP/SRTCP are by
|
||
default derived as specified in Section 4.3.
|
||
|
||
The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for
|
||
any particular fixed value of the key.
|
||
|
||
We describe the process of computing authentication tags as follows.
|
||
The sender computes the tag of M and appends it to the packet. The
|
||
SRTP receiver verifies a message/authentication tag pair by computing
|
||
a new authentication tag over M using the selected algorithm and key,
|
||
and then compares it to the tag associated with the received message.
|
||
If the two tags are equal, then the message/tag pair is valid;
|
||
otherwise, it is invalid and the error audit message "AUTHENTICATION
|
||
FAILURE" MUST be returned.
|
||
|
||
4.2.1. HMAC-SHA1
|
||
|
||
The pre-defined authentication transform for SRTP is HMAC-SHA1
|
||
[RFC2104]. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL
|
||
be 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to
|
||
the session authentication key and M as specified above, i.e.,
|
||
HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag
|
||
left-most bits.
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 25]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
4.3. Key Derivation
|
||
|
||
4.3.1. Key Derivation Algorithm
|
||
|
||
Regardless of the encryption or message authentication transform that
|
||
is employed (it may be an SRTP pre-defined transform or newly
|
||
introduced according to Section 6), interoperable SRTP
|
||
implementations MUST use the SRTP key derivation to generate session
|
||
keys. Once the key derivation rate is properly signaled at the start
|
||
of the session, there is no need for extra communication between the
|
||
parties that use SRTP key derivation.
|
||
|
||
packet index ---+
|
||
|
|
||
v
|
||
+-----------+ master +--------+ session encr_key
|
||
| ext | key | |---------->
|
||
| key mgmt |-------->| key | session auth_key
|
||
| (optional | | deriv |---------->
|
||
| rekey) |-------->| | session salt_key
|
||
| | master | |---------->
|
||
+-----------+ salt +--------+
|
||
|
||
Figure 5: SRTP key derivation.
|
||
|
||
At least one initial key derivation SHALL be performed by SRTP, i.e.,
|
||
the first key derivation is REQUIRED. Further applications of the
|
||
key derivation MAY be performed, according to the
|
||
"key_derivation_rate" value in the cryptographic context. The key
|
||
derivation function SHALL initially be invoked before the first
|
||
packet and then, when r > 0, a key derivation is performed whenever
|
||
index mod r equals zero. This can be thought of as "refreshing" the
|
||
session keys. The value of "key_derivation_rate" MUST be kept fixed
|
||
for the lifetime of the associated master key.
|
||
|
||
Interoperable SRTP implementations MAY also derive session salting
|
||
keys for encryption transforms, as is done in both of the pre-
|
||
defined transforms.
|
||
|
||
Let m and n be positive integers. A pseudo-random function family is
|
||
a set of keyed functions {PRF_n(k,x)} such that for the (secret)
|
||
random key k, given m-bit x, PRF_n(k,x) is an n-bit string,
|
||
computationally indistinguishable from random n-bit strings, see
|
||
[HAC]. For the purpose of key derivation in SRTP, a secure PRF with
|
||
m = 128 (or more) MUST be used, and a default PRF transform is
|
||
defined in Section 4.3.3.
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 26]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Let "a DIV t" denote integer division of a by t, rounded down, and
|
||
with the convention that "a DIV 0 = 0" for all a. We also make the
|
||
convention of treating "a DIV t" as a bit string of the same length
|
||
as a, and thus "a DIV t" will in general have leading zeros.
|
||
|
||
Key derivation SHALL be defined as follows in terms of <label>, an
|
||
8-bit constant (see below), master_salt and key_derivation_rate, as
|
||
determined in the cryptographic context, and index, the packet index
|
||
(i.e., the 48-bit ROC || SEQ for SRTP):
|
||
|
||
* Let r = index DIV key_derivation_rate (with DIV as defined above).
|
||
|
||
* Let key_id = <label> || r.
|
||
|
||
* Let x = key_id XOR master_salt, where key_id and master_salt are
|
||
aligned so that their least significant bits agree (right-
|
||
alignment).
|
||
|
||
<label> MUST be unique for each type of key to be derived. We
|
||
currently define <label> 0x00 to 0x05 (see below), and future
|
||
extensions MAY specify new values in the range 0x06 to 0xff for other
|
||
purposes. The n-bit SRTP key (or salt) for this packet SHALL then be
|
||
derived from the master key, k_master as follows:
|
||
|
||
PRF_n(k_master, x).
|
||
|
||
(The PRF may internally specify additional formatting and padding of
|
||
x, see e.g., Section 4.3.3 for the default PRF.)
|
||
|
||
The session keys and salt SHALL now be derived using:
|
||
|
||
- k_e (SRTP encryption): <label> = 0x00, n = n_e.
|
||
|
||
- k_a (SRTP message authentication): <label> = 0x01, n = n_a.
|
||
|
||
- k_s (SRTP salting key): <label> = 0x02, n = n_s.
|
||
|
||
where n_e, n_s, and n_a are from the cryptographic context.
|
||
|
||
The master key and master salt MUST be random, but the master salt
|
||
MAY be public.
|
||
|
||
Note that for a key_derivation_rate of 0, the application of the key
|
||
derivation SHALL take place exactly once.
|
||
|
||
The definition of DIV above is purely for notational convenience.
|
||
For a non-zero t among the set of allowed key derivation rates, "a
|
||
DIV t" can be implemented as a right-shift by the base-2 logarithm of
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 27]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
t. The derivation operation is further facilitated if the rates are
|
||
chosen to be powers of 256, but that granularity was considered too
|
||
coarse to be a requirement of this specification.
|
||
|
||
The upper limit on the number of packets that can be secured using
|
||
the same master key (see Section 9.2) is independent of the key
|
||
derivation.
|
||
|
||
4.3.2. SRTCP Key Derivation
|
||
|
||
SRTCP SHALL by default use the same master key (and master salt) as
|
||
SRTP. To do this securely, the following changes SHALL be done to
|
||
the definitions in Section 4.3.1 when applying session key derivation
|
||
for SRTCP.
|
||
|
||
Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
|
||
(i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
|
||
<label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
|
||
SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
|
||
key.
|
||
|
||
4.3.3. AES-CM PRF
|
||
|
||
The currently defined PRF, keyed by 128, 192, or 256 bit master key,
|
||
has input block size m = 128 and can produce n-bit outputs for n up
|
||
to 2^23. PRF_n(k_master,x) SHALL be AES in Counter Mode as described
|
||
in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16),
|
||
and with the output keystream truncated to the n first (left-most)
|
||
bits. (Requiring n/128, rounded up, applications of AES.)
|
||
|
||
5. Default and mandatory-to-implement Transforms
|
||
|
||
The default transforms also are mandatory-to-implement transforms in
|
||
SRTP. Of course, "mandatory-to-implement" does not imply
|
||
"mandatory-to-use". Table 1 summarizes the pre-defined transforms.
|
||
The default values below are valid for the pre-defined transforms.
|
||
|
||
mandatory-to-impl. optional default
|
||
|
||
encryption AES-CM, NULL AES-f8 AES-CM
|
||
message integrity HMAC-SHA1 - HMAC-SHA1
|
||
key derivation (PRF) AES-CM - AES-CM
|
||
|
||
Table 1: Mandatory-to-implement, optional and default transforms in
|
||
SRTP and SRTCP.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 28]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
5.1. Encryption: AES-CM and NULL
|
||
|
||
AES running in Segmented Integer Counter Mode, as defined in Section
|
||
4.1.1, SHALL be the default encryption algorithm. The default key
|
||
lengths SHALL be 128-bit for the session encryption key (n_e). The
|
||
default session salt key-length (n_s) SHALL be 112 bits.
|
||
|
||
The NULL cipher SHALL also be mandatory-to-implement.
|
||
|
||
5.2. Message Authentication/Integrity: HMAC-SHA1
|
||
|
||
HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message
|
||
authentication code. The default session authentication key-length
|
||
(n_a) SHALL be 160 bits, the default authentication tag length
|
||
(n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero
|
||
for HMAC-SHA1. In addition, for SRTCP, the pre-defined HMAC-SHA1
|
||
MUST NOT be applied with a value of n_tag, nor n_a, that are smaller
|
||
than these defaults. For SRTP, smaller values are NOT RECOMMENDED,
|
||
but MAY be used after careful consideration of the issues in Section
|
||
7.5 and 9.5.
|
||
|
||
5.3. Key Derivation: AES-CM PRF
|
||
|
||
The AES Counter Mode based key derivation and PRF defined in Sections
|
||
4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default
|
||
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.
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 29]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 30]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 31]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 32]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 33]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 34]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 35]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 36]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 37]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 38]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
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
|
||
are used to pad shorter keys to 192 or 256 bits.
|
||
|
||
9.3. Confidentiality of the RTP Payload
|
||
|
||
SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e.,
|
||
ciphers able to efficiently seek to arbitrary locations in their
|
||
keystream (so that the encryption or decryption of one packet does
|
||
not depend on preceding packets). By using seekable stream ciphers,
|
||
SRTP avoids the denial of service attacks that are possible on stream
|
||
ciphers that lack this property. It is important to be aware that,
|
||
as with any stream cipher, the exact length of the payload is
|
||
revealed by the encryption. This means that it may be possible to
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 39]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
deduce certain "formatting bits" of the payload, as the length of the
|
||
codec output might vary due to certain parameter settings etc. This,
|
||
in turn, implies that the corresponding bit of the keystream can be
|
||
deduced. However, if the stream cipher is secure (counter mode and
|
||
f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]),
|
||
knowledge of a few bits of the keystream will not aid an attacker in
|
||
predicting subsequent keystream bits. Thus, the payload length (and
|
||
information deducible from this) will leak, but nothing else.
|
||
|
||
As some RTP packet could contain highly predictable data, e.g., SID,
|
||
it is important to use a cipher designed to resist known plaintext
|
||
attacks (which is the current practice).
|
||
|
||
9.4. Confidentiality of the RTP Header
|
||
|
||
In SRTP, RTP headers are sent in the clear to allow for header
|
||
compression. This means that data such as payload type,
|
||
synchronization source identifier, and timestamp are available to an
|
||
eavesdropper. Moreover, since RTP allows for future extensions of
|
||
headers, we cannot foresee what kind of possibly sensitive
|
||
information might also be "leaked".
|
||
|
||
SRTP is a low-cost method, which allows header compression to reduce
|
||
bandwidth. It is up to the endpoints' policies to decide about the
|
||
security protocol to employ. If one really needs to protect headers,
|
||
and is allowed to do so by the surrounding environment, then one
|
||
should also look at alternatives, e.g., IPsec [RFC2401].
|
||
|
||
9.5. Integrity of the RTP payload and header
|
||
|
||
SRTP messages are subject to attacks on their integrity and source
|
||
identification, and these risks are discussed in Section 9.5.1. To
|
||
protect against these attacks, each SRTP stream SHOULD be protected
|
||
by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key,
|
||
or a message authentication code with equivalent strength. Secure
|
||
RTP SHOULD NOT be used without message authentication, except under
|
||
the circumstances described in this section. It is important to note
|
||
that encryption algorithms, including AES Counter Mode and f8, do not
|
||
provide message authentication. SRTCP MUST NOT be used with weak (or
|
||
NULL) authentication.
|
||
|
||
SRTP MAY be used with weak authentication (e.g., a 32-bit
|
||
authentication tag), or with no authentication (the NULL
|
||
authentication algorithm). These options allow SRTP to be used to
|
||
provide confidentiality in situations where
|
||
|
||
* weak or null authentication is an acceptable security risk, and
|
||
* it is impractical to provide strong message authentication.
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 40]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
These conditions are described below and in Section 7.5. Note that
|
||
both conditions MUST hold in order for weak or null authentication to
|
||
be used. The risks associated with exercising the weak or null
|
||
authentication options need to be considered by a security audit
|
||
prior to their use for a particular application or environment given
|
||
the risks, which are discussed in Section 9.5.1.
|
||
|
||
Weak authentication is acceptable when the RTP application is such
|
||
that the effect of a small fraction of successful forgeries is
|
||
negligible. If the application is stateless, then the effect of a
|
||
single forged RTP packet is limited to the decoding of that
|
||
particular packet. Under this condition, the size of the
|
||
authentication tag MUST ensure that only a negligible fraction of the
|
||
packets passed to the RTP application by the SRTP receiver can be
|
||
forgeries. This fraction is negligible when an adversary, if given
|
||
control of the forged packets, is not able to make a significant
|
||
impact on the output of the RTP application (see the example of
|
||
Section 7.5).
|
||
|
||
Weak or null authentication MAY be acceptable when it is unlikely
|
||
that an adversary can modify ciphertext so that it decrypts to an
|
||
intelligible value. One important case is when it is difficult for
|
||
an adversary to acquire the RTP plaintext data, since for many
|
||
codecs, an adversary that does not know the input signal cannot
|
||
manipulate the output signal in a controlled way. In many cases it
|
||
may be difficult for the adversary to determine the actual value of
|
||
the plaintext. For example, a hidden snooping device might be
|
||
required in order to know a live audio or video signal. The
|
||
adversary's signal must have a quality equivalent to or greater than
|
||
that of the signal under attack, since otherwise the adversary would
|
||
not have enough information to encode that signal with the codec used
|
||
by the victim. Plaintext prediction may also be especially difficult
|
||
for an interactive application such as a telephone call.
|
||
|
||
Weak or null authentication MUST NOT be used when the RTP application
|
||
makes data forwarding or access control decisions based on the RTP
|
||
data. In such a case, an attacker may be able to subvert
|
||
confidentiality by causing the receiver to forward data to an
|
||
attacker. See Section 3 of [B96] for a real-life example of such
|
||
attacks.
|
||
|
||
Null authentication MUST NOT be used when a replay attack, in which
|
||
an adversary stores packets then replays them later in the session,
|
||
could have a non-negligible impact on the receiver. An example of a
|
||
successful replay attack is the storing of the output of a
|
||
surveillance camera for a period of time, later followed by the
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 41]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
injection of that output to the monitoring station to avoid
|
||
surveillance. Encryption does not protect against this attack, and
|
||
non-null authentication is REQUIRED in order to defeat it.
|
||
|
||
If existential message forgery is an issue, i.e., when the accuracy
|
||
of the received data is of non-negligible importance, null
|
||
authentication MUST NOT be used.
|
||
|
||
9.5.1. Risks of Weak or Null Message Authentication
|
||
|
||
During a security audit considering the use of weak or null
|
||
authentication, it is important to keep in mind the following attacks
|
||
which are possible when no message authentication algorithm is used.
|
||
|
||
An attacker who cannot predict the plaintext is still always able to
|
||
modify the message sent between the sender and the receiver so that
|
||
it decrypts to a random plaintext value, or to send a stream of bogus
|
||
packets to the receiver that will decrypt to random plaintext values.
|
||
This attack is essentially a denial of service attack, though in the
|
||
absence of message authentication, the RTP application will have
|
||
inputs that are bit-wise correlated with the true value. Some
|
||
multimedia codecs and common operating systems will crash when such
|
||
data are accepted as valid video data. This denial of service attack
|
||
may be a much larger threat than that due to an attacker dropping,
|
||
delaying, or re-ordering packets.
|
||
|
||
An attacker who cannot predict the plaintext can still replay a
|
||
previous message with certainty that the receiver will accept it.
|
||
Applications with stateless codecs might be robust against this type
|
||
of attack, but for other, more complex applications these attacks may
|
||
be far more grave.
|
||
|
||
An attacker who can predict the plaintext can modify the ciphertext
|
||
so that it will decrypt to any value of her choosing. With an
|
||
additive stream cipher, an attacker will always be able to change
|
||
individual bits.
|
||
|
||
An attacker may be able to subvert confidentiality due to the lack of
|
||
authentication when a data forwarding or access control decision is
|
||
made on decrypted but unauthenticated plaintext. This is because the
|
||
receiver may be fooled into forwarding data to an attacker, leading
|
||
to an indirect breach of confidentiality (see Section 3 of [B96]).
|
||
This is because data-forwarding decisions are made on the decrypted
|
||
plaintext; information in the plaintext will determine to what subnet
|
||
(or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode
|
||
(respectively, transport mode). When Secure RTP is used without
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 42]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
message authentication, it should be verified that the application
|
||
does not make data forwarding or access control decisions based on
|
||
the decrypted plaintext.
|
||
|
||
Some cipher modes of operation that require padding, e.g., standard
|
||
cipher block chaining (CBC) are very sensitive to attacks on
|
||
confidentiality if certain padding types are used in the absence of
|
||
integrity. The attack [V02] shows that this is indeed the case for
|
||
the standard RTP padding as discussed in reference to Figure 1, when
|
||
used together with CBC mode. Later transform additions to SRTP MUST
|
||
therefore carefully consider the risk of using this padding without
|
||
proper integrity protection.
|
||
|
||
9.5.2. Implicit Header Authentication
|
||
|
||
The IV formation of the f8-mode gives implicit authentication (IHA)
|
||
of the RTP header, even when message authentication is not used.
|
||
When IHA is used, an attacker that modifies the value of the RTP
|
||
header will cause the decryption process at the receiver to produce
|
||
random plaintext values. While this protection is not equivalent to
|
||
message authentication, it may be useful for some applications.
|
||
|
||
10. Interaction with Forward Error Correction mechanisms
|
||
|
||
The default processing when using Forward Error Correction (e.g., RFC
|
||
2733) processing with SRTP SHALL be to perform FEC processing prior
|
||
to SRTP processing on the sender side and to perform SRTP processing
|
||
prior to FEC processing on the receiver side. Any change to this
|
||
ordering (reversing it, or, placing FEC between SRTP encryption and
|
||
SRTP authentication) SHALL be signaled out of band.
|
||
|
||
11. Scenarios
|
||
|
||
SRTP can be used as security protocol for the RTP/RTCP traffic in
|
||
many different scenarios. SRTP has a number of configuration
|
||
options, in particular regarding key usage, and can have impact on
|
||
the total performance of the application according to the way it is
|
||
used. Hence, the use of SRTP is dependent on the kind of scenario
|
||
and application it is used with. In the following, we briefly
|
||
illustrate some use cases for SRTP, and give some guidelines for
|
||
recommended setting of its options.
|
||
|
||
11.1. Unicast
|
||
|
||
A typical example would be a voice call or video-on-demand
|
||
application.
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 43]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Consider one bi-directional RTP stream, as one RTP session. It is
|
||
possible for the two parties to share the same master key in the two
|
||
directions according to the principles of Section 9.1. The first
|
||
round of the key derivation splits the master key into any or all of
|
||
the following session keys (according to the provided security
|
||
functions):
|
||
|
||
SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
|
||
|
||
(For simplicity, we omit discussion of the salts, which are also
|
||
derived.) In this scenario, it will in most cases suffice to have a
|
||
single master key with the default lifetime. This guarantees
|
||
sufficiently long lifetime of the keys and a minimum set of keys in
|
||
place for most practical purposes. Also, in this case RTCP
|
||
protection can be applied smoothly. Under these assumptions, use of
|
||
the MKI can be omitted. As the key-derivation in combination with
|
||
large difference in the packet rate in the respective directions may
|
||
require simultaneous storage of several session keys, if storage is
|
||
an issue, we recommended to use low-rate key derivation.
|
||
|
||
The same considerations can be extended to the unicast scenario with
|
||
multiple RTP sessions, where each session would have a distinct
|
||
master key.
|
||
|
||
11.2. Multicast (one sender)
|
||
|
||
Just as with (unprotected) RTP, a scalability issue arises in big
|
||
groups due to the possibly very large amount of SRTCP Receiver
|
||
Reports that the sender might need to process. In SRTP, the sender
|
||
may have to keep state (the cryptographic context) for each receiver,
|
||
or more precisely, for the SRTCP used to protect Receiver Reports.
|
||
The overhead increases proportionally to the size of the group. In
|
||
particular, re-keying requires special concern, see below.
|
||
|
||
Consider first a small group of receivers. There are a few possible
|
||
setups with the distribution of master keys among the receivers.
|
||
Given a single RTP session, one possibility is that the receivers
|
||
share the same master key as per Section 9.1 to secure all their
|
||
respective RTCP traffic. This shared master key could then be the
|
||
same one used by the sender to protect its outbound SRTP traffic.
|
||
Alternatively, it could be a master key shared only among the
|
||
receivers and used solely for their SRTCP traffic. Both alternatives
|
||
require the receivers to trust each other.
|
||
|
||
Considering SRTCP and key storage, it is recommended to use low-rate
|
||
(or zero) key_derivation (except the mandatory initial one), so that
|
||
the sender does not need to store too many session keys (each SRTCP
|
||
stream might otherwise have a different session key at a given point
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 44]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
in time, as the SRTCP sources send at different times). Thus, in
|
||
case key derivation is wanted for SRTP, the cryptographic context for
|
||
SRTP can be kept separate from the SRTCP crypto context, so that it
|
||
is possible to have a key_derivation_rate of 0 for SRTCP and a non-
|
||
zero value for SRTP.
|
||
|
||
Use of the MKI for re-keying is RECOMMENDED for most applications
|
||
(see Section 8.1).
|
||
|
||
If there are more than one SRTP/SRTCP stream (within the same RTP
|
||
session) that share the master key, the upper limit of 2^48 SRTP
|
||
packets / 2^31 SRTCP packets means that, before one of the streams
|
||
reaches its maximum number of packets, re-keying MUST be triggered on
|
||
ALL streams sharing the master key. (From strict security point of
|
||
view, only the stream reaching the maximum would need to be re-keyed,
|
||
but then the streams would no longer be sharing master key, which is
|
||
the intention.) A local policy at the sender side should force
|
||
rekeying in a way that the maximum packet limit is not reached on any
|
||
of the streams. Use of the MKI for re-keying is RECOMMENDED.
|
||
|
||
In large multicast with one sender, the same considerations as for
|
||
the small group multicast hold. The biggest issue in this scenario
|
||
is the additional load placed at the sender side, due to the state
|
||
(cryptographic contexts) that has to be maintained for each receiver,
|
||
sending back RTCP Receiver Reports. At minimum, a replay window
|
||
might need to be maintained for each RTCP source.
|
||
|
||
11.3. Re-keying and access control
|
||
|
||
Re-keying may occur due to access control (e.g., when a member is
|
||
removed during a multicast RTP session), or for pure cryptographic
|
||
reasons (e.g., the key is at the end of its lifetime). When using
|
||
SRTP default transforms, the master key MUST be replaced before any
|
||
of the index spaces are exhausted for any of the streams protected by
|
||
one and the same master key.
|
||
|
||
How key management re-keys SRTP implementations is out of scope, but
|
||
it is clear that there are straightforward ways to manage keys for a
|
||
multicast group. In one-sender multicast, for example, it is
|
||
typically the responsibility of the sender to determine when a new
|
||
key is needed. The sender is the one entity that can keep track of
|
||
when the maximum number of packets has been sent, as receivers may
|
||
join and leave the session at any time, there may be packet loss and
|
||
delay etc. In scenarios other than one-sender multicast, other
|
||
methods can be used. Here, one must take into consideration that key
|
||
exchange can be a costly operation, taking several seconds for a
|
||
single exchange. Hence, some time before the master key is
|
||
exhausted/expires, out-of-band key management is initiated, resulting
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 45]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
in a new master key that is shared with the receiver(s). In any
|
||
event, to maintain synchronization when switching to the new key,
|
||
group policy might choose between using the MKI and the <From, To>,
|
||
as described in Section 8.1.
|
||
|
||
For access control purposes, the <From, To> periods are set at the
|
||
desired granularity, dependent on the packet rate. High rate re-
|
||
keying can be problematic for SRTCP in some large-group scenarios.
|
||
As mentioned, there are potential problems in using the SRTP index,
|
||
rather than the SRTCP index, for determining the master key. In
|
||
particular, for short periods during switching of master keys, it may
|
||
be the case that SRTCP packets are not under the current master key
|
||
of the correspondent SRTP. Therefore, using the MKI for re-keying in
|
||
such scenarios will produce better results.
|
||
|
||
11.4. Summary of basic scenarios
|
||
|
||
The description of these scenarios highlights some recommendations on
|
||
the use of SRTP, mainly related to re-keying and large scale
|
||
multicast:
|
||
|
||
- Do not use fast re-keying with the <From, To> feature. It may, in
|
||
particular, give problems in retrieving the correct SRTCP key, if
|
||
an SRTCP packet arrives close to the re-keying time. The MKI
|
||
SHOULD be used in this case.
|
||
|
||
- If multiple SRTP streams in the same RTP session share the same
|
||
master key, also moderate rate re-keying MAY have the same
|
||
problems, and the MKI SHOULD be used.
|
||
|
||
- Though offering increased security, a non-zero key_derivation_rate
|
||
is NOT RECOMMENDED when trying to minimize the number of keys in
|
||
use with multiple streams.
|
||
|
||
12. IANA Considerations
|
||
|
||
The RTP specification establishes a registry of profile names for use
|
||
by higher-level control protocols, such as the Session Description
|
||
Protocol (SDP), to refer to transport methods. This profile
|
||
registers the name "RTP/SAVP".
|
||
|
||
SRTP uses cryptographic transforms which a key management protocol
|
||
signals. It is the task of each particular key management protocol
|
||
to register the cryptographic transforms or suites of transforms with
|
||
IANA. The key management protocol conveys these protocol numbers,
|
||
not SRTP, and each key management protocol chooses the numbering
|
||
scheme and syntax that it requires.
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 46]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Specification of a key management protocol for SRTP is out of scope
|
||
here. Section 8.2, however, provides guidance on the parameters that
|
||
need to be defined for the default and mandatory transforms.
|
||
|
||
13. Acknowledgements
|
||
|
||
David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this
|
||
document but their valuable contributions are acknowledged here to
|
||
keep the length of the author list down.
|
||
|
||
The authors would in addition like to thank Magnus Westerlund, Brian
|
||
Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie-
|
||
Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen
|
||
Colin Perkins and Stephen Casner, the Transport and Security Area
|
||
Directors, and Eric Rescorla for their reviews and support.
|
||
|
||
14. References
|
||
|
||
14.1. Normative References
|
||
|
||
[AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
|
||
http://www.nist.gov/aes/
|
||
|
||
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
|
||
Hashing for Message Authentication", RFC 2104, February
|
||
1997.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
|
||
Internet Protocol", RFC 2401, November 1998.
|
||
|
||
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
|
||
May 2000.
|
||
|
||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
|
||
"RTP: A Transport Protocol for Real-time Applications", RFC
|
||
3550, July 2003.
|
||
|
||
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
|
||
Video Conferences with Minimal Control", RFC 3551, July
|
||
2003.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 47]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
14.2. Informative References
|
||
|
||
[AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode
|
||
Encryption", NIST, http://csrc.nist.gov/encryption/modes/
|
||
workshop1/papers/lipmaa-ctr.pdf
|
||
|
||
[B96] Bellovin, S., "Problem Areas for the IP Security
|
||
Protocols," in Proceedings of the Sixth Usenix Unix
|
||
Security Symposium, pp. 1-16, San Jose, CA, July 1996
|
||
(http://www.research.att.com/~smb/papers/index.html).
|
||
|
||
[BDJR] Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A
|
||
Concrete Treatment of Symmetric Encryption: Analysis of DES
|
||
Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-
|
||
403, 1997.
|
||
|
||
[BS00] Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data
|
||
Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000,
|
||
LNCS 1976, pp. 1-13, Springer Verlag.
|
||
|
||
[C99] Crowell, W. P., "Introduction to the VENONA Project",
|
||
http://www.nsa.gov:8080/docs/venona/index.html.
|
||
|
||
[CTR] Dworkin, M., NIST Special Publication 800-38A,
|
||
"Recommendation for Block Cipher Modes of Operation:
|
||
Methods and Techniques", 2001.
|
||
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
|
||
38a.pdf.
|
||
|
||
[f8-a] 3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd
|
||
Generation Partnership Project; Technical Specification
|
||
Group Services and System Aspects; 3G Security;
|
||
Specification of the 3GPP Confidentiality and Integrity
|
||
Algorithms; Document 1: f8 and f9 Specification (Release
|
||
4).
|
||
|
||
[f8-b] 3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd
|
||
Generation Partnership Project; Technical Specification
|
||
Group Services and System Aspects; 3G Security; General
|
||
Report on the Design, Specification and Evaluation of 3GPP
|
||
Standard Confidentiality and Integrity Algorithms (Release
|
||
4).
|
||
|
||
[GDOI] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
|
||
Group Domain of Interpretation, RFC 3547, July 2003.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 48]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
[HAC] Menezes, A., Van Oorschot, P. and S. Vanstone, "Handbook
|
||
of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-
|
||
8523-7.
|
||
|
||
[H80] Hellman, M. E., "A cryptanalytic time-memory trade-off",
|
||
IEEE Transactions on Information Theory, July 1980, pp.
|
||
401-406.
|
||
|
||
[IK] T. Iwata and T. Kohno: "New Security Proofs for the 3GPP
|
||
Confidentiality and Integrity Algorithms", Proceedings of
|
||
FSE 2004.
|
||
|
||
[KINK] Thomas, M. and J. Vilhuber, "Kerberized Internet
|
||
Negotiation of Keys (KINK)", Work in Progress.
|
||
|
||
[KEYMGT] Arrko, J., et al., "Key Management Extensions for Session
|
||
Description Protocol (SDP) and Real Time Streaming Protocol
|
||
(RTSP)", Work in Progress.
|
||
|
||
[KSYH] Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable
|
||
Security of KASUMI and 3GPP Encryption Mode f8",
|
||
Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp.
|
||
255-271, 2001.
|
||
|
||
[MIKEY] Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing",
|
||
Work in Progress.
|
||
|
||
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of
|
||
Redundant Plaintext and Implications on Internet Security",
|
||
the Proceedings of the Seventh Annual Workshop on Selected
|
||
Areas in Cryptography (SAC 2000), Springer-Verlag.
|
||
|
||
[PCST1] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
|
||
and Secure Source Authentication for Multicast", in Proc.
|
||
of Network and Distributed System Security Symposium NDSS
|
||
2001, pp. 35-46, 2001.
|
||
|
||
[PCST2] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
|
||
Authentication and Signing of Multicast Streams over Lossy
|
||
Channels", in Proc. of IEEE Security and Privacy Symposium
|
||
S&P2000, pp. 56-73, 2000.
|
||
|
||
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
|
||
Recommendations for Security", RFC 1750, December 1994.
|
||
|
||
[RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
|
||
RFC 2675, August 1999.
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 49]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
|
||
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
|
||
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
|
||
T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
|
||
Framework and Four Profiles: RTP, UDP, ESP, and
|
||
uncompressed (ROHC)", RFC 3095, July 2001.
|
||
|
||
[RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
|
||
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
|
||
3242, April 2002.
|
||
|
||
[SDMS] Andreasen, F., Baugher, M. and D. Wing, "Session
|
||
Description Protocol Security Descriptions for Media
|
||
Streams", Work in Progress.
|
||
|
||
[SWO] Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
|
||
wireless", Proc. PIMRC 2000, London, Sept. 2000.
|
||
|
||
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding -
|
||
Application to SSL, IPsec, WTLS...", Advances in
|
||
Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
|
||
|
||
[WC81] Wegman, M. N., and J.L. Carter, "New Hash Functions and
|
||
Their Use in Authentication and Set Equality", JCSS 22,
|
||
265-279, 1981.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 50]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Appendix A: Pseudocode for Index Determination
|
||
|
||
The following is an example of pseudo-code for the algorithm to
|
||
determine the index i of an SRTP packet with sequence number SEQ. In
|
||
the following, signed arithmetic is assumed.
|
||
|
||
if (s_l < 32,768)
|
||
if (SEQ - s_l > 32,768)
|
||
set v to (ROC-1) mod 2^32
|
||
else
|
||
set v to ROC
|
||
endif
|
||
else
|
||
if (s_l - 32,768 > SEQ)
|
||
set v to (ROC+1) mod 2^32
|
||
else
|
||
set v to ROC
|
||
endif
|
||
endif
|
||
return SEQ + v*65,536
|
||
|
||
Appendix B: Test Vectors
|
||
|
||
All values are in hexadecimal.
|
||
|
||
B.1. AES-f8 Test Vectors
|
||
|
||
SRTP PREFIX LENGTH : 0
|
||
|
||
RTP packet header : 806e5cba50681de55c621599
|
||
|
||
RTP packet payload : 70736575646f72616e646f6d6e657373
|
||
20697320746865206e65787420626573
|
||
74207468696e67
|
||
|
||
ROC : d462564a
|
||
key : 234829008467be186c3de14aae72d62c
|
||
salt key : 32f2870d
|
||
key-mask (m) : 32f2870d555555555555555555555555
|
||
key XOR key-mask : 11baae0dd132eb4d3968b41ffb278379
|
||
|
||
IV : 006e5cba50681de55c621599d462564a
|
||
IV' : 595b699bbd3bc0df26062093c1ad8f73
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 51]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
j = 0
|
||
IV' xor j : 595b699bbd3bc0df26062093c1ad8f73
|
||
S(-1) : 00000000000000000000000000000000
|
||
IV' xor S(-1) xor j : 595b699bbd3bc0df26062093c1ad8f73
|
||
S(0) : 71ef82d70a172660240709c7fbb19d8e
|
||
plaintext : 70736575646f72616e646f6d6e657373
|
||
ciphertext : 019ce7a26e7854014a6366aa95d4eefd
|
||
|
||
j = 1
|
||
IV' xor j : 595b699bbd3bc0df26062093c1ad8f72
|
||
S(0) : 71ef82d70a172660240709c7fbb19d8e
|
||
IV' xor S(0) xor j : 28b4eb4cb72ce6bf020129543a1c12fc
|
||
S(1) : 3abd640a60919fd43bd289a09649b5fc
|
||
plaintext : 20697320746865206e65787420626573
|
||
ciphertext : 1ad4172a14f9faf455b7f1d4b62bd08f
|
||
|
||
j = 2
|
||
IV' xor j : 595b699bbd3bc0df26062093c1ad8f71
|
||
S(1) : 3abd640a60919fd43bd289a09649b5fc
|
||
IV' xor S(1) xor j : 63e60d91ddaa5f0b1dd4a93357e43a8d
|
||
S(2) : 220c7a8715266565b09ecc8a2a62b11b
|
||
plaintext : 74207468696e67
|
||
ciphertext : 562c0eef7c4802
|
||
|
||
B.2. AES-CM Test Vectors
|
||
|
||
Keystream segment length: 1044512 octets (65282 AES blocks)
|
||
Session Key: 2B7E151628AED2A6ABF7158809CF4F3C
|
||
Rollover Counter: 00000000
|
||
Sequence Number: 0000
|
||
SSRC: 00000000
|
||
Session Salt: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
|
||
Offset: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
|
||
|
||
Counter Keystream
|
||
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 E03EAD0935C95E80E166B16DD92B4EB4
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001 D23513162B02D0F72A43A2FE4A5F97AB
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002 41E95B3BB0A2E8DD477901E4FCA894C0
|
||
... ...
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF EC8CDF7398607CB0F2D21675EA9EA1E4
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00 362B7C3C6773516318A077D7FC5073AE
|
||
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01 6A2CC3787889374FBEB4C81B17BA6C44
|
||
|
||
Nota Bene: this test case is contrived so that the latter part of the
|
||
keystream segment coincides with the test case in Section F.5.1 of
|
||
[CTR].
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 52]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
B.3. Key Derivation Test Vectors
|
||
|
||
This section provides test data for the default key derivation
|
||
function, which uses AES-128 in Counter Mode. In the following, we
|
||
walk through the initial key derivation for the AES-128 Counter Mode
|
||
cipher, which requires a 16 octet session encryption key and a 14
|
||
octet session salt, and an authentication function which requires a
|
||
94-octet session authentication key. These values are called the
|
||
cipher key, the cipher salt, and the auth key in the following.
|
||
Since this is the initial key derivation and the key derivation rate
|
||
is equal to zero, the value of (index DIV key_derivation_rate) is
|
||
zero (actually, a six-octet string of zeros). In the following, we
|
||
shorten key_derivation_rate to kdr.
|
||
|
||
The inputs to the key derivation function are the 16 octet master key
|
||
and the 14 octet master salt:
|
||
|
||
master key: E1F97A0D3E018BE0D64FA32C06DE4139
|
||
master salt: 0EC675AD498AFEEBB6960B3AABE6
|
||
|
||
We first show how the cipher key is generated. The input block for
|
||
AES-CM is generated by exclusive-oring the master salt with the
|
||
concatenation of the encryption key label 0x00 with (index DIV kdr),
|
||
then padding on the right with two null octets (which implements the
|
||
multiply-by-2^16 operation, see Section 4.3.3). The resulting value
|
||
is then AES-CM- encrypted using the master key to get the cipher key.
|
||
|
||
index DIV kdr: 000000000000
|
||
label: 00
|
||
master salt: 0EC675AD498AFEEBB6960B3AABE6
|
||
-----------------------------------------------
|
||
xor: 0EC675AD498AFEEBB6960B3AABE6 (x, PRF input)
|
||
|
||
x*2^16: 0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
|
||
|
||
cipher key: C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 53]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Next, we show how the cipher salt is generated. The input block for
|
||
AES-CM is generated by exclusive-oring the master salt with the
|
||
concatenation of the encryption salt label. That value is padded and
|
||
encrypted as above.
|
||
|
||
index DIV kdr: 000000000000
|
||
label: 02
|
||
master salt: 0EC675AD498AFEEBB6960B3AABE6
|
||
|
||
----------------------------------------------
|
||
xor: 0EC675AD498AFEE9B6960B3AABE6 (x, PRF input)
|
||
|
||
x*2^16: 0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
|
||
|
||
30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
|
||
|
||
cipher salt: 30CBBC08863D8C85D49DB34A9AE1
|
||
|
||
We now show how the auth key is generated. The input block for AES-
|
||
CM is generated as above, but using the authentication key label.
|
||
|
||
index DIV kdr: 000000000000
|
||
label: 01
|
||
master salt: 0EC675AD498AFEEBB6960B3AABE6
|
||
-----------------------------------------------
|
||
xor: 0EC675AD498AFEEAB6960B3AABE6 (x, PRF input)
|
||
|
||
x*2^16: 0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)
|
||
|
||
Below, the auth key is shown on the left, while the corresponding AES
|
||
input blocks are shown on the right.
|
||
|
||
auth key AES input blocks
|
||
CEBE321F6FF7716B6FD4AB49AF256A15 0EC675AD498AFEEAB6960B3AABE60000
|
||
6D38BAA48F0A0ACF3C34E2359E6CDBCE 0EC675AD498AFEEAB6960B3AABE60001
|
||
E049646C43D9327AD175578EF7227098 0EC675AD498AFEEAB6960B3AABE60002
|
||
6371C10C9A369AC2F94A8C5FBCDDDC25 0EC675AD498AFEEAB6960B3AABE60003
|
||
6D6E919A48B610EF17C2041E47403576 0EC675AD498AFEEAB6960B3AABE60004
|
||
6B68642C59BBFC2F34DB60DBDFB2 0EC675AD498AFEEAB6960B3AABE60005
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 54]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Questions and comments should be directed to the authors and
|
||
avt@ietf.org:
|
||
|
||
Mark Baugher
|
||
Cisco Systems, Inc.
|
||
5510 SW Orchid Street
|
||
Portland, OR 97219 USA
|
||
|
||
Phone: +1 408-853-4418
|
||
EMail: mbaugher@cisco.com
|
||
|
||
|
||
Elisabetta Carrara
|
||
Ericsson Research
|
||
SE-16480 Stockholm
|
||
Sweden
|
||
|
||
Phone: +46 8 50877040
|
||
EMail: elisabetta.carrara@ericsson.com
|
||
|
||
|
||
David A. McGrew
|
||
Cisco Systems, Inc.
|
||
San Jose, CA 95134-1706
|
||
USA
|
||
|
||
Phone: +1 301-349-5815
|
||
EMail: mcgrew@cisco.com
|
||
|
||
|
||
Mats Naslund
|
||
Ericsson Research
|
||
SE-16480 Stockholm
|
||
Sweden
|
||
|
||
Phone: +46 8 58533739
|
||
EMail: mats.naslund@ericsson.com
|
||
|
||
|
||
Karl Norrman
|
||
Ericsson Research
|
||
SE-16480 Stockholm
|
||
Sweden
|
||
|
||
Phone: +46 8 4044502
|
||
EMail: karl.norrman@ericsson.com
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 55]
|
||
|
||
RFC 3711 SRTP March 2004
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2004). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78 and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at ietf-
|
||
ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Baugher, et al. Standards Track [Page 56]
|
||
|