Internet Engineering Task Force David A. McGrew
Audio/Video Transport Working Group David Oran
INTERNET-DRAFT Cisco Systems, Inc.
Expires in May, 2001 November, 2000
The Secure Real Time Protocol
<draft-mcgrew-avt-srtp-00.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC-2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Table of Contents
1. Abstract...................................................2
2. Notational Conventions.....................................2
3. Goals......................................................2
4. SRTP Overview..............................................3
4.1 SRTP Cryptographic Contexts..............................4
4.2 Mapping SRTP Packets to Cryptographic Contexts...........4
4.3 SRTP Packet Processing...................................4
4.4 Cryptographic Algorithms.................................6
5. Synchronization............................................6
6. Replay Protection..........................................7
7. Encryption.................................................7
7.1 Default Cipher: Counter Mode AES.........................8
8. Message Authentication.....................................8
8.1 Default MAC: UMAC........................................8
9. SRTP Parameters............................................9
10. Secure RTCP................................................9
11. Rationale.................................................11
McGrew, Oran [Page 1]
Internet Draft Secure RTP November, 2000
11.1 Synchronization.........................................11
11.2 Replay Protection.......................................12
11.3 Source Origin Authentication............................12
12. Security Considerations...................................13
13. Contact Information.......................................15
14. References................................................15
1. Abstract
This document describes the Secure Real Time Protocol (SRTP), a
profile of the Real Time Protocol (RTP) which provides privacy,
message authentication, and replay protection.
SRTP achieves high throughput and low packet expansion by using an
additive stream cipher for encryption, a universal hashing based
function for message authentication, and an `implicit' index for
sequencing based on the RTP sequence number.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [B97].
3. Goals
The security goals for SRTP are to ensure:
* the privacy of the RTP payload, the RTP contributing source
identifiers, and any RTP header extensions, if present,
* the authentication of the RTP header, payload, and header
extensions, if present, and
* replay protection.
Source origin authentication (e.g., digitally signed packets) may
be desirable in some situations, but is deferred from consideration
in this document. See Section 10.3 for a discussion on this point.
Other goals for the protocol are:
* a low computational cost,
* a low footprint (i.e., small code size and data memory for key
McGrew, Oran [Page 2]
Internet Draft Secure RTP November, 2000
schedules and replay lists),
* limited packet expansion, and
* preservation of RTP header compression efficacy.
4. SRTP Overview
RTP is the Real Time Protocol [SCFJ96]. We define SRTP as a
profile of RTP, in an analogous way to RFC1890 which defines the
audio/video profile for RTP. Conceptually, we consider a `bump in
the stack' implementation which resides between the RTP application
and the transport layer, which intercepts RTP packets and then
forwards an equivalent SRTP packet on the sending side, and which
intercepts SRTP packets and passes an equivalent RTP packet up the
stack on the receiving side.
Figure 1. The format of an SRTP packet.
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 |
| | | .... |
+->+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | authentication tag |
| | | .... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| +- Encrypted Portion
+---- Authenticated Portion
The format of an SRTP packet is illustrated in Figure 1. The
McGrew, Oran [Page 3]
Internet Draft Secure RTP November, 2000
authentication tag is the only field defined by SRTP that is not in
RTP. It provides data origin authentication of the header and
payload, and it indirectly provides replay protection by
authenticating the sequence number. The Encrypted Portion of an
SRTP packet consists of the contributing source identifiers, the
RTP extension (if present), and the RTP payload, of the equivalent
RTP packet. The Authenticated Portion of an SRTP packet consists
of the entire equivalent RTP packet.
4.1 SRTP Cryptographic Contexts
Each SRTP session requires the sender and receiver to maintain
cryptographic state information. This information is called the
cryptographic context, and it consists of:
* an encryption key k_e,
* a message authentication key k_a,
* a 32-bit rollover counter r (which records how many times the
16-bit RTP sequence number has been reset to zero after passing
through 65,535),
* a sequence number s_l (which is the last received and
authenticated sequence number for the receiver, and is the last
sequence number sent for the sender), and
* a replay list L (maintained by the receiver only).
4.2 Mapping SRTP Packets to Cryptographic Contexts
The RTP synchronization source (SSRC) identifier is used by a
receiver to identify the proper cryptographic context for each
packet.
An SSRC identifier is unique for a given session, and all packets
with the same SSRC form part of the same timing and sequence number
space. Thus, the SSRC field can be used by an SRTP receiver (or by
a bump in the stack implementation on the sender's side) to
identify the proper cryptographic context.
The authentication key and encryption key of each context MUST
remain fixed for the duration of that context. This ensures that
incorrect keys will not be used by the receiver due to a
synchronization error.
McGrew, Oran [Page 4]
Internet Draft Secure RTP November, 2000
4.3 SRTP Packet Processing
To construct a proper SRTP packet, given an RTP packet, the
sender does the following:
1. Determine which cryptographic context to use by checking the
SSRC field of the RTP packet.
2. Determine the index of the SRTP packet from the rollover counter
in the cryptographic context and the sequence number from the
RTP packet, as described in Section 5.
3. Encrypt the Encrypted Portion of the packet, as described in
Section 7, using the index determined in Step 2 and the
encryption key in the context found in Step 1.
4. Compute the authentication tag for the Authenticated Portion of
the packet, as described in Section 8, using the index
determined in Step 2 and the authentication key in the context
found in Step 1. Note that the Encrypted Portion is encrypted
before the authentication tag is computed.
To authenticate and decrypt an SRTP packet, the receiver does the
following:
1. Determine which cryptographic context to use by checking the
SSRC field of the RTP packet.
2. Determine the index of the SRTP packet from the rollover counter
in the cryptographic context and the sequence number from the RTP
packet.
3. Check the Replay List to ensure that no packet with that index
has been received and authenticated before, as described in
Section 6. If that index is in the list, then the packet has
been replayed and is invalid. It MUST be discarded, and the
event SHOULD be logged.
4. Compute the authentication tag for the Authenticated Portion of
the packet, as described in Section 8, using the index
determined in Step 2 and the authentication key in the context
found in Step 1. Note that the Encrypted Portion is not
decrypted before the authentication tag is computed.
If the authentication tag that is computed matches that in the
SRTP packet, then the packet is accepted and the index is added
to the Replay List. Otherwise, the packet is invalid: it MUST
be discarded, and the event SHOULD be logged.
McGrew, Oran [Page 5]
Internet Draft Secure RTP November, 2000
5. Decrypt the Encrypted Portion of the packet, as described in
Section 7, using the index determined in Step 2 and the
encryption key in the context found in Step 1.
The processing has been chosen to maximize resistance to denial of
service attacks (i.e., to minimize the receiver's effort in
processing spurious packets).
4.4 Cryptographic Algorithms
Default encryption and authentication algorithms are specified in
Sections 7.1 and 8.1. While there are numerous encryption and
message authentication algorithms that can be used in SRTP, we
define default algorithms in order to avoid the complexity of
specifying the encodings for the signaling of algorithm and
parameter identifiers.
5. Synchronization
SRTP implementations use an `implicit' packet index for sequencing.
Receiver-side implementations use the RTP sequence number to
reconstruct the correct index (that is, location in the sequence of
all RTP packets). The index is defined as s + r * 65,536, where
the sequence number is s and the rollover counter is r.
A robust approach for the proper use of a rollover counter requires
that its handling and use be well defined. In particular,
out-of-order RTP packets with sequence numbers close to 65,536 or
zero must be properly dealt with.
A receiver reconstructs the index i of a packet with sequence
number s using the estimate
i = 65,536 * t + s,
where t is chosen from the set { r-1, r, r+1 } such that i is
closest to the value 65,536 * r + s_l. If the value r+1 is used,
then the rollover counter r in the cryptographic context is
incremented by one.
The pseudocode for the algorithm to process a packet with sequence
number s follows:
if (s_l < 32,768)
if (s - s_l > 32,768)
set i to s + 65,536 * (r-1)
else
McGrew, Oran [Page 6]
Internet Draft Secure RTP November, 2000
set i to s + 65,536 * r
endif
else
if (s_l - 32,768 > s)
set r to r + 1
endif
set i to s + r * 65,536
endif
set s_l to s
The index i is used in replay protection (Section 6), in encryption
(Section 7), and in message authentication (Section 8).
As the rollover counter is 32 bits long, the maximum number of
packets in any given SRTP session is 2^48 = 281,474,976,710,656.
After that number of SRTP packets have been sent, the sender MUST
not send any more packets with that cryptographic context. This
limitation enforces a security benefit by providing an upper bound
on the amount of traffic that can pass before cryptographic keys
are changed.
Other approaches to sequencing were considered and rejected; please
see Section 10.1 for our rationale.
6. Replay Protection
A packet is `replayed' when it is stored by an adversary, then
re-injected onto the network. SRTP provides protection against
such attacks by requiring the storage of the indices of the most
recently received and authenticated packets.
Each SRTP receiver maintains a Replay List, which contains the
indices of the packets which have been received and authenticated
which are no less than s_l * 65,536 - SRTP_WINDOW_SIZE, where
SRTP_WINDOW_SIZE is a parameter that MUST be at least 64, and which
MAY be set to a higher value. In this `sliding window' approach, a
fixed amount of storage is used for replay protection.
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 [KA98a].
7. Encryption
Encryption uses a `seekable' additive stream cipher, following the
Stream Cipher ESP [sc-esp]. The stream ciphers that can be used
McGrew, Oran [Page 7]
Internet Draft Secure RTP November, 2000
must be able to efficiently seek to arbitrary locations in their
keystream. Ciphers that can do this include SEAL [RC94, RC98],
LEVIATHAN [MF00b], and any block cipher run in counter mode [LRW00,
M00]. In particular, AES in counter mode will provide good
security, reasonable performance, and conform to emerging
U.S. Federal standards, and is thus defined as the default cipher.
SRTP encryption consists of generating a keystream segment
corresponding to the index of the packet, and then bitwise
exclusive-oring that keystream segment into the RTP packet,
starting at bit number 96 (the first bit in the first contributing
source identifier, if present). Decryption is the done the same
way, but swapping the roles of the plaintext and ciphertext. The
definition of how keystream is generated, given the index, depends
on the cipher.
7.1 Default Cipher: Counter Mode AES
AES will be used with a 128 bit key size and a 128 bit block size,
using the Segmented Integer Counter Mode [M00].
In Counter Mode AES, keystream for the packet with index i is
defined as the concatenation of the outputs of the AES cipher with
the inputs
i*4096, i*4096 + 1, i*4096 + 2, ... , (i+1)*4096 - 1.
The AES has a block size of 128 bits, so 4096 output blocks are
sufficient to generate the 8 * 64,536 = 524,288 bits of keystream
needed to encrypt the largest possible RTP packet (actually, any
IPv4 or IPv6 packet except for IPv6 `jumbograms' [rfc2675], which
are not likely to be used for RTP-based multimedia traffic).
8. Message Authentication
Message integrity authentication can be provided by any message
authentication code, though the default value is UMAC [KBHHKR00].
The authentication tag is computed by applying the UMAC function
to the Authenticated Portion of the SRTP packet.
8.1 Default MAC: UMAC
The default message authentication code is UMAC [KBHHKR00], which
has proven security properties and is quite fast. Furthermore, it
McGrew, Oran [Page 8]
Internet Draft Secure RTP November, 2000
can be used with short (e.g., two or four byte) authentication
tags, as well as larger tags.
The authentication tag is appended to the RTP packet. This
expansion of the RTP packet may cause the packet size to exceed the
Maximum Transmission Unit (MTU) of a network interface on its path,
especially in circumstances when the application is attempting to
`optimize' the size of packets. MTU path discovery SHOULD be used
to avoid this problem.
UMAC is a parameterized algorithm (see Section 2.1 of [KBHHKR00]).
The default selection of UMAC parameters for SRTP are:
WORD-LEN 2
UMAC-OUTPUT-LEN 4
L1-KEY-LEN 128
UMAC-KEY-LEN 16
ENDIAN-FAVORITE BIG
L1-OPERATIONS-SIGN SIGNED
This choice of parameters is intended to work well on low-power
processors, to minimize packet expansion, and to minimize the size
of the cryptographic context. The WORD-LEN of two will work well
on 16 bit and higher processors. The packet expansion is
determined by the UMAC-OUTPUT-LEN to be only four bytes. The
storage requirement, per cryptographic context, is 144 bytes.
These parameters ensure a forgery probability of no greater than
1/2^30 for each individual packet. Please see the security
considerations section in [KBHHKR00] and the references therein for
a more detailed discussion.
9. SRTP Parameters
The SRTP_WINDOW_SIZE (Section 6) is the only currently defined
parameter. Other parameters may be added in the future.
10. Secure RTCP
Secure RTCP follows the definition of Secure RTP, but defines the
index differently. In order to differentiate this quantity, we
refer to it as the SRTP index.
Each sender must use a distinct cryptographic context, as there is
no way to synchronize sequencing information among senders.
Therefore, each SSRC corresponds to a distinct SRTCP cryptographic
context (and to a distinct SRTP context as well).
McGrew, Oran [Page 9]
Internet Draft Secure RTP November, 2000
SRTCP is defined as a profile of RTCP, and it adds two new fields
to the RTCP packet definition, the SRTCP index and the
authentication tag. Those fields are appended to an RTCP packet in
order to form an equivalent SRTP packet, so that they follow any
other profile-specific extensions. An SRTCP packet is illustrated
in Figure 2.
Figure 2. The format of a Secure RTCP packet, after Section
6.3.1 of [SCFJ96]. In this case, the underlying RTCP packet is
a sender report packet; the SRTP format is identical for other
RTCP packet types.
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=200 | length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | SSRC of sender |
| +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | ... |
| | | sender info |
| | | ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | ... |
| | | report block 1 |
| | | ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | ... |
| | | report block 2 |
| | | ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | ... |
| | | |
| | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | ... |
| | | profile-specific extensions |
| | | ... |
| +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | SRTCP index |
+-|>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | ... |
| | | authentication tag |
| | | ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| +-- Encrypted Portion
+ ---- Authenticated Portion
McGrew, Oran [Page 10]
Internet Draft Secure RTP November, 2000
The SRTCP index is a 32-bit value, which is set to zero before the
first SRTCP packet is sent, and is incremented by one after each
SRTCP is sent. This index is explicitly included in each packet,
in contrast to the `implicit' index approach used for SRTP.
SRTCP packet processing is identical to that of SRTP packet
processing, with the following changes:
* SRTCP replay protection is as defined in Section 6, but using the
the SRTCP index as the index i.
* SRTCP encryption is as defined in Section 7, but using the
definition of the SRTCP Encrypted Portion as defined in this
section, and using the SRTCP index as the index i.
* The SRTCP authentication tag is defined as in Section 8, but
applying the UMAC function to the Authenticated Portion of the
SRTCP packet as defined in this section, and using the SRTCP
index as the index i.
The encryption prefix (Section 6.1 of [SCFJ96]), which is a random
32-bit quantity intended to improve privacy, SHOULD NOT be used.
This is because SRTP encryption uses an additive stream cipher, and
thus the prefix offers no benefit.
The maximum number of SRTCP packets is limited to 2^32 =
4,294,967,296. The last RTCP packet MUST contain an RTCP BYE.
SRTCP senders MUST send an RTCP BYE in the final packet, if the
maximum number of SRTCP packets is reached. Similarly, SRTCP
receivers MUST act as though the last RTCP packet included a BYE,
even if no BYE was included in the packet, if the maximum number of
SRTCP packets is reached.
11. Rationale
SRTP achieves high throughput and low packet expansion by using
fast stream ciphers for encryption, universal hash functions for
message authentication, and an implicit index for synchronization.
Only a single header extension may be appended to the RTP data
header, so the use of a header extension for SRTP was avoided.
SRTP and SRTCP are defined as profiles of RTP and RTCP,
respectively.
10.1 Synchronization
McGrew, Oran [Page 11]
Internet Draft Secure RTP November, 2000
RTP runs over unreliable transport. Thus, maintaining
synchronization of the cryptographic context between the sender and
receiver is a conspicuous challenge. Because of the requirement to
minimize packet expansion, no explicit sequencing information
should be added. RTP packets contain two fields for
synchronization purposes, the timestamp and the sequence number.
The timestamp field could be used for cryptographic synchronization
in some circumstances. However, this field is not appropriate for
such use; from [SCFJ96]:
Several consecutive RTP packets may have equal timestamps if
they are (logically) generated at once, e.g., belong to the same
video frame. Consecutive RTP packets may contain timestamps that
are not monotonic if the data is not transmitted in the order it
was sampled, as in the case of MPEG interpolated video frames.
The RTP sequence number cannot be directly used as a unique
identifier for SRTP packets. It has only sixteen bits, which would
limit the duration of an SRTP security association to only 64,536
packets.
The `implicit index' approach works as long as the reorder and loss
of the packets is not too great. In particular, 32,768 packets
would need to be lost, or a packet would need to be 32,768 packets
out of sequence in order for synchronization to be lost. Such
drastic loss or reorder is likely to disrupt the RTP application
itself.
10.2 Replay Protection
Replay protection is undoubtedly important for multimedia data.
Otherwise, it would be possible for an adversary to perform simple
manipulations on data that subverted security. For example, in a
voice application, the phrase ``yes'' could be substituted for
``no'' if replay protection were not present.
10.3 Source Origin Authentication
`Source origin authentication' was listed as an option in the
security goals, not because it not an appropriate goal, but because
it may not be achievable. This goal may be desirable in some
circumstances, such as multicast environments in which the sender
is more trusted than the receivers, or when translators or mixers
(Section 2.3 of [SCFJ96]) are used. However, it is not clear
that this capability can always be provided, as mixers and
translators can change the payload. Furthermore, this security
McGrew, Oran [Page 12]
Internet Draft Secure RTP November, 2000
service essentially requires digital signatures (at least if
collusion resistance is required [BF00]).
Two examples of the multicast scenario mentioned above are a
military commander addressing his troops over RTP, and financial
market data sent over RTP. In these situations, a `stream signing'
method can provide digital signatures on the entire RTP packets.
An extensive literature on such methods is developing, and it is
reasonable to expect that one of these methods can be reduced to
practice and specified for RTP. This suggests that it should be
left as an option in the current specification. A future effort
can define a stream signing method as an authentication type for
RTP, which could be used as a replacement for a message integrity
transform.
Examples of the mixer and translator scenarios include a translator
re-encoding data at a lower rate or in a different encoding, and a
mixer combining the audio streams of multiple speakers in a
teleconference. In these cases, it is not clear that meaningful
source origin authentication is possible, as the data that is
received is not the same as the data that is signed. If the
translator is trusted by the receivers, then it could sign or
re-sign the data streams, but this scenario may not be prevalent.
It may be possible to devise a signing scheme that authenticates
the source but not the content (enabling the receivers to know that
``John is one of the people talking'', but not providing
authentication on who said what) by signing the concatenation of
the Contributing source (CSRC) field and some sequencing
information (e.g., a timestamp or sequence number), but such
schemes require synchronization between the senders. This
synchronization is not required by the RTP protocol itself, and may
be difficult or impossible to arrange.
11. Security Considerations
The security of UMAC is well understood, and is described in
[KBHHKR00].
Additive ciphers do not provide any security service other than
privacy. In particular, they do not provide message authentication
(see [RK99] or [S96] for a discussion of this security service).
However, SRTP uses a message authentication code to provide that
security service.
By using `seekable' stream ciphers, SRTP avoids the denial of
service attacks that are possible on stream ciphers that lack this
property (these attacks are described in Section 3.4 of [B96]).
McGrew, Oran [Page 13]
Internet Draft Secure RTP November, 2000
No bit of keystream in an additive stream cipher should ever be
used to encrypt multiple distinct plaintext bits. Such keystream
reuse (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. In SRTP, a
`two-time pad' is avoided by requiring that both keys and indices
be unique.
If manual keying is used, two different cryptographic contexts
might accidentally use the same encryption key with non-negligible
probability, through manual error or procedural inadequacies.
Thus, manual keying SHOULD NOT be used for SRTP (or SRTCP).
An 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,Bi96]. 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, 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.
In order to provide an effective key size of n bits in a deployment
in which 2^m SRTP/SRTCP cryptographic contexts will be created, the
true key size will need to be n+m bits. The value of m SHOULD be
32 bits for networks with 50,000 connections (fully meshed networks
with up to 200 devices), and SHOULD be 64 bits for networks with
49e+12 connections (fully meshed networks with up to 7,000,000
devices). These choices of m ensures that key collision attacks
amortized over a ten year period offer no advantage over exhaustive
search, when new SC/ESP keys are established for every connection
every hour (note that such an attack requires the storage of all
network traffic over the ten year period). These choices will
suffice for many networks, though SRTP deployments with more
stringent security requirements will need to make a detailed
assessment of those requirements with respect to the attacks
described in [MF00].
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.
It is an important point that the m bits of `extra' key provided to
McGrew, Oran [Page 14]
Internet Draft Secure RTP November, 2000
thwart these attacks need not be private. In jurisdictions with
mandated limits on the length of a secret key, the additional key
bits could be made public. This is because those bits are
functionally equivalent to the `salt' that is used to protect
passwords from dictionary attacks. The fact that the `extra' key
bits are distinct for many different keys defeats the key collision
and time-memory tradeoff attacks by reducing the number of keys
over which cryptanalytic computation can be amortized.
Note that other security protocols which use additive ciphers for
the encryption of Internet traffic (e.g., SSL, TLS, SSH, IPSEC) are
also vulnerable to the attacks described in [MF00]. Those attacks
are generic to additive encryption of redundant plaintext, and are
not particular to SRTP.
12. Contact Information
Questions and comments about this memo can be directed to:
David A. McGrew
David Oran
Cisco Systems, Inc.
San Jose, CA 95134-1706 USA
mcgrew@cisco.com, oran@cisco.com
13. References
[B97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[KA98a] Kent, S., and R. Atkinson, "Security Architecture for IP",
RFC 2401, November 1998.
[BF00] Boneh, D., and Franklin, M., "Message Authentication in a
Multicast Environment", the Proceedings of the Seventh
Annual Workshop on Selected Areas in Cryptography (SAC
2000), Springer-Verlag.
[C99] Crowell, W. P., "Introduction to the VENONA Project",
http://www.nsa.gov:8080/docs/venona/index.html.
[H80] Hellman, M. E., "A cryptanalytic time-memory trade-off", IEEE
Transactions on Information Theory, July 1980, pp. 401-406.
[KBHHKR00] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk,
H., Rogaway, P., "UMAC: Message Authentication Code using
Universal Hashing", Internet Draft, October 2000,
McGrew, Oran [Page 15]
Internet Draft Secure RTP November, 2000
<draft-krovetz-umac-01.txt>.
[LRW00] Lipmaa, H., Rogaway, P., and Wagner, D., "Comments to NIST
Concerning AES Modes of Operation: CTR-Mode Encryption",
NIST Workshop on AES Modes of Operation,
http://csrc.nist.gov/encryption/aes/modes/lipmaa-ctr.pdf
[M00] McGrew, D., "Segmented Integer Counter Mode: Specification
and Rationale", NIST Workshop on AES Modes of Operation,
http://www.mindspring.com/~dmcgrew/sic-mode.pdf
[MF00] McGrew, D., and Fluhrer, S., "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.
[MF00b] McGrew, D., and Fluhrer, S., "The Stream Cipher LEVIATHAN:
Specification and Supporting Documentation", Submission to
the New European Schemes for Signatures, Integrity, and
Encryption (NESSIE) Process, October, 2000.
http://www.cryptonessie.org/.
[R92] Rueppel, R., "Stream Ciphers", Chapter 2 of Simmons, G.,
"Contemporary Cryptology: the Science of Information
Integrity," 1992, IEEE Press.
[RC94] Rogaway, P. and Coppersmith, D., "A Software-Optimized
Encryption Algorithm", Proceedings of the 1994 Fast
Software Encryption Workshop, Lecture Notes In Computer
Science, Volume 809, Springer-Verlag, 1994, pp. 56-63.
[RC98] Rogaway, P. and Coppersmith, D., "A Software-Optimized
Encryption Algorithm", Journal of Cryptology, Volume 11,
Number 4, Springer-Verlag, 1998, Pages 273-287. Also
available on the Internet at
http://www.cs.ucdavis.edu/~rogaway/papers/seal-abstract.html.
[RK99] Rescorla, E., and Korver, B., "Guidelines for Writing RFC
Text on Security Considerations,"
draft-rescorla-sec-cons-00.txt
[S96] Schneier, B. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C", Wiley, 1996.
[SCFJ96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications",
IETF Request For Comments RFC 1889.
McGrew, Oran [Page 16]