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 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 . [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]