idnits 2.17.1 draft-mcgrew-avt-srtp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'B96' is mentioned on line 603, but not defined == Missing Reference: 'Bi96' is mentioned on line 620, but not defined == Unused Reference: 'LRW00' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'R92' is defined on line 719, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'BF00' -- Possible downref: Non-RFC (?) normative reference: ref. 'C99' -- Possible downref: Non-RFC (?) normative reference: ref. 'H80' -- Possible downref: Non-RFC (?) normative reference: ref. 'KBHHKR00' -- Possible downref: Non-RFC (?) normative reference: ref. 'LRW00' -- Possible downref: Non-RFC (?) normative reference: ref. 'M00' -- Possible downref: Non-RFC (?) normative reference: ref. 'MF00' -- Possible downref: Non-RFC (?) normative reference: ref. 'MF00b' -- Possible downref: Non-RFC (?) normative reference: ref. 'R92' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC94' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC98' == Outdated reference: A later version (-05) exists of draft-rescorla-sec-cons-00 -- Possible downref: Normative reference to a draft: ref. 'RK99' -- Possible downref: Non-RFC (?) normative reference: ref. 'S96' ** Obsolete normative reference: RFC 1889 (ref. 'SCFJ96') (Obsoleted by RFC 3550) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force David A. McGrew 3 Audio/Video Transport Working Group David Oran 4 INTERNET-DRAFT Cisco Systems, Inc. 5 Expires in May, 2001 November, 2000 7 The Secure Real Time Protocol 8 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC-2026. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and working groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Table of Contents 31 1. Abstract...................................................2 32 2. Notational Conventions.....................................2 33 3. Goals......................................................2 34 4. SRTP Overview..............................................3 35 4.1 SRTP Cryptographic Contexts..............................4 36 4.2 Mapping SRTP Packets to Cryptographic Contexts...........4 37 4.3 SRTP Packet Processing...................................4 38 4.4 Cryptographic Algorithms.................................6 39 5. Synchronization............................................6 40 6. Replay Protection..........................................7 41 7. Encryption.................................................7 42 7.1 Default Cipher: Counter Mode AES.........................8 43 8. Message Authentication.....................................8 44 8.1 Default MAC: UMAC........................................8 45 9. SRTP Parameters............................................9 46 10. Secure RTCP................................................9 47 11. Rationale.................................................11 48 11.1 Synchronization.........................................11 49 11.2 Replay Protection.......................................12 50 11.3 Source Origin Authentication............................12 51 12. Security Considerations...................................13 52 13. Contact Information.......................................15 53 14. References................................................15 55 1. Abstract 57 This document describes the Secure Real Time Protocol (SRTP), a 58 profile of the Real Time Protocol (RTP) which provides privacy, 59 message authentication, and replay protection. 61 SRTP achieves high throughput and low packet expansion by using an 62 additive stream cipher for encryption, a universal hashing based 63 function for message authentication, and an `implicit' index for 64 sequencing based on the RTP sequence number. 66 2. Notational Conventions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 70 this document are to be interpreted as described in RFC-2119 [B97]. 72 3. Goals 74 The security goals for SRTP are to ensure: 76 * the privacy of the RTP payload, the RTP contributing source 77 identifiers, and any RTP header extensions, if present, 79 * the authentication of the RTP header, payload, and header 80 extensions, if present, and 82 * replay protection. 84 Source origin authentication (e.g., digitally signed packets) may 85 be desirable in some situations, but is deferred from consideration 86 in this document. See Section 10.3 for a discussion on this point. 88 Other goals for the protocol are: 90 * a low computational cost, 92 * a low footprint (i.e., small code size and data memory for key 93 schedules and replay lists), 95 * limited packet expansion, and 97 * preservation of RTP header compression efficacy. 99 4. SRTP Overview 101 RTP is the Real Time Protocol [SCFJ96]. We define SRTP as a 102 profile of RTP, in an analogous way to RFC1890 which defines the 103 audio/video profile for RTP. Conceptually, we consider a `bump in 104 the stack' implementation which resides between the RTP application 105 and the transport layer, which intercepts RTP packets and then 106 forwards an equivalent SRTP packet on the sending side, and which 107 intercepts SRTP packets and passes an equivalent RTP packet up the 108 stack on the receiving side. 110 Figure 1. The format of an SRTP packet. 112 0 1 2 3 113 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 114 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | |V=2|P|X| CC |M| PT | sequence number | 116 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | timestamp | 118 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | | synchronization source (SSRC) identifier | 120 | +->+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 121 | | | contributing source (CSRC) identifiers | 122 | | | .... | 123 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | | RTP extension (optional) | 125 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | | | 127 | | | payload | 128 | | | .... | 129 +->+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | | authentication tag | 131 | | | .... | 132 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 | +- Encrypted Portion 135 +---- Authenticated Portion 137 The format of an SRTP packet is illustrated in Figure 1. The 138 authentication tag is the only field defined by SRTP that is not in 139 RTP. It provides data origin authentication of the header and 140 payload, and it indirectly provides replay protection by 141 authenticating the sequence number. The Encrypted Portion of an 142 SRTP packet consists of the contributing source identifiers, the 143 RTP extension (if present), and the RTP payload, of the equivalent 144 RTP packet. The Authenticated Portion of an SRTP packet consists 145 of the entire equivalent RTP packet. 147 4.1 SRTP Cryptographic Contexts 149 Each SRTP session requires the sender and receiver to maintain 150 cryptographic state information. This information is called the 151 cryptographic context, and it consists of: 153 * an encryption key k_e, 155 * a message authentication key k_a, 157 * a 32-bit rollover counter r (which records how many times the 158 16-bit RTP sequence number has been reset to zero after passing 159 through 65,535), 161 * a sequence number s_l (which is the last received and 162 authenticated sequence number for the receiver, and is the last 163 sequence number sent for the sender), and 165 * a replay list L (maintained by the receiver only). 167 4.2 Mapping SRTP Packets to Cryptographic Contexts 169 The RTP synchronization source (SSRC) identifier is used by a 170 receiver to identify the proper cryptographic context for each 171 packet. 173 An SSRC identifier is unique for a given session, and all packets 174 with the same SSRC form part of the same timing and sequence number 175 space. Thus, the SSRC field can be used by an SRTP receiver (or by 176 a bump in the stack implementation on the sender's side) to 177 identify the proper cryptographic context. 179 The authentication key and encryption key of each context MUST 180 remain fixed for the duration of that context. This ensures that 181 incorrect keys will not be used by the receiver due to a 182 synchronization error. 184 4.3 SRTP Packet Processing 186 To construct a proper SRTP packet, given an RTP packet, the 187 sender does the following: 189 1. Determine which cryptographic context to use by checking the 190 SSRC field of the RTP packet. 192 2. Determine the index of the SRTP packet from the rollover counter 193 in the cryptographic context and the sequence number from the 194 RTP packet, as described in Section 5. 196 3. Encrypt the Encrypted Portion of the packet, as described in 197 Section 7, using the index determined in Step 2 and the 198 encryption key in the context found in Step 1. 200 4. Compute the authentication tag for the Authenticated Portion of 201 the packet, as described in Section 8, using the index 202 determined in Step 2 and the authentication key in the context 203 found in Step 1. Note that the Encrypted Portion is encrypted 204 before the authentication tag is computed. 206 To authenticate and decrypt an SRTP packet, the receiver does the 207 following: 209 1. Determine which cryptographic context to use by checking the 210 SSRC field of the RTP packet. 212 2. Determine the index of the SRTP packet from the rollover counter 213 in the cryptographic context and the sequence number from the RTP 214 packet. 216 3. Check the Replay List to ensure that no packet with that index 217 has been received and authenticated before, as described in 218 Section 6. If that index is in the list, then the packet has 219 been replayed and is invalid. It MUST be discarded, and the 220 event SHOULD be logged. 222 4. Compute the authentication tag for the Authenticated Portion of 223 the packet, as described in Section 8, using the index 224 determined in Step 2 and the authentication key in the context 225 found in Step 1. Note that the Encrypted Portion is not 226 decrypted before the authentication tag is computed. 228 If the authentication tag that is computed matches that in the 229 SRTP packet, then the packet is accepted and the index is added 230 to the Replay List. Otherwise, the packet is invalid: it MUST 231 be discarded, and the event SHOULD be logged. 233 5. Decrypt the Encrypted Portion of the packet, as described in 234 Section 7, using the index determined in Step 2 and the 235 encryption key in the context found in Step 1. 237 The processing has been chosen to maximize resistance to denial of 238 service attacks (i.e., to minimize the receiver's effort in 239 processing spurious packets). 241 4.4 Cryptographic Algorithms 243 Default encryption and authentication algorithms are specified in 244 Sections 7.1 and 8.1. While there are numerous encryption and 245 message authentication algorithms that can be used in SRTP, we 246 define default algorithms in order to avoid the complexity of 247 specifying the encodings for the signaling of algorithm and 248 parameter identifiers. 250 5. Synchronization 252 SRTP implementations use an `implicit' packet index for sequencing. 253 Receiver-side implementations use the RTP sequence number to 254 reconstruct the correct index (that is, location in the sequence of 255 all RTP packets). The index is defined as s + r * 65,536, where 256 the sequence number is s and the rollover counter is r. 258 A robust approach for the proper use of a rollover counter requires 259 that its handling and use be well defined. In particular, 260 out-of-order RTP packets with sequence numbers close to 65,536 or 261 zero must be properly dealt with. 263 A receiver reconstructs the index i of a packet with sequence 264 number s using the estimate 266 i = 65,536 * t + s, 268 where t is chosen from the set { r-1, r, r+1 } such that i is 269 closest to the value 65,536 * r + s_l. If the value r+1 is used, 270 then the rollover counter r in the cryptographic context is 271 incremented by one. 273 The pseudocode for the algorithm to process a packet with sequence 274 number s follows: 276 if (s_l < 32,768) 277 if (s - s_l > 32,768) 278 set i to s + 65,536 * (r-1) 279 else 280 set i to s + 65,536 * r 281 endif 282 else 283 if (s_l - 32,768 > s) 284 set r to r + 1 285 endif 286 set i to s + r * 65,536 287 endif 288 set s_l to s 290 The index i is used in replay protection (Section 6), in encryption 291 (Section 7), and in message authentication (Section 8). 293 As the rollover counter is 32 bits long, the maximum number of 294 packets in any given SRTP session is 2^48 = 281,474,976,710,656. 295 After that number of SRTP packets have been sent, the sender MUST 296 not send any more packets with that cryptographic context. This 297 limitation enforces a security benefit by providing an upper bound 298 on the amount of traffic that can pass before cryptographic keys 299 are changed. 301 Other approaches to sequencing were considered and rejected; please 302 see Section 10.1 for our rationale. 304 6. Replay Protection 306 A packet is `replayed' when it is stored by an adversary, then 307 re-injected onto the network. SRTP provides protection against 308 such attacks by requiring the storage of the indices of the most 309 recently received and authenticated packets. 311 Each SRTP receiver maintains a Replay List, which contains the 312 indices of the packets which have been received and authenticated 313 which are no less than s_l * 65,536 - SRTP_WINDOW_SIZE, where 314 SRTP_WINDOW_SIZE is a parameter that MUST be at least 64, and which 315 MAY be set to a higher value. In this `sliding window' approach, a 316 fixed amount of storage is used for replay protection. 318 The Replay List can be efficiently implemented by using a bitmap to 319 represent which packets have been received, as described in the 320 Security Architecture for IP [KA98a]. 322 7. Encryption 324 Encryption uses a `seekable' additive stream cipher, following the 325 Stream Cipher ESP [sc-esp]. The stream ciphers that can be used 326 must be able to efficiently seek to arbitrary locations in their 327 keystream. Ciphers that can do this include SEAL [RC94, RC98], 328 LEVIATHAN [MF00b], and any block cipher run in counter mode [LRW00, 329 M00]. In particular, AES in counter mode will provide good 330 security, reasonable performance, and conform to emerging 331 U.S. Federal standards, and is thus defined as the default cipher. 333 SRTP encryption consists of generating a keystream segment 334 corresponding to the index of the packet, and then bitwise 335 exclusive-oring that keystream segment into the RTP packet, 336 starting at bit number 96 (the first bit in the first contributing 337 source identifier, if present). Decryption is the done the same 338 way, but swapping the roles of the plaintext and ciphertext. The 339 definition of how keystream is generated, given the index, depends 340 on the cipher. 342 7.1 Default Cipher: Counter Mode AES 344 AES will be used with a 128 bit key size and a 128 bit block size, 345 using the Segmented Integer Counter Mode [M00]. 347 In Counter Mode AES, keystream for the packet with index i is 348 defined as the concatenation of the outputs of the AES cipher with 349 the inputs 351 i*4096, i*4096 + 1, i*4096 + 2, ... , (i+1)*4096 - 1. 353 The AES has a block size of 128 bits, so 4096 output blocks are 354 sufficient to generate the 8 * 64,536 = 524,288 bits of keystream 355 needed to encrypt the largest possible RTP packet (actually, any 356 IPv4 or IPv6 packet except for IPv6 `jumbograms' [rfc2675], which 357 are not likely to be used for RTP-based multimedia traffic). 359 8. Message Authentication 361 Message integrity authentication can be provided by any message 362 authentication code, though the default value is UMAC [KBHHKR00]. 364 The authentication tag is computed by applying the UMAC function 365 to the Authenticated Portion of the SRTP packet. 367 8.1 Default MAC: UMAC 369 The default message authentication code is UMAC [KBHHKR00], which 370 has proven security properties and is quite fast. Furthermore, it 371 can be used with short (e.g., two or four byte) authentication 372 tags, as well as larger tags. 374 The authentication tag is appended to the RTP packet. This 375 expansion of the RTP packet may cause the packet size to exceed the 376 Maximum Transmission Unit (MTU) of a network interface on its path, 377 especially in circumstances when the application is attempting to 378 `optimize' the size of packets. MTU path discovery SHOULD be used 379 to avoid this problem. 381 UMAC is a parameterized algorithm (see Section 2.1 of [KBHHKR00]). 382 The default selection of UMAC parameters for SRTP are: 384 WORD-LEN 2 385 UMAC-OUTPUT-LEN 4 386 L1-KEY-LEN 128 387 UMAC-KEY-LEN 16 388 ENDIAN-FAVORITE BIG 389 L1-OPERATIONS-SIGN SIGNED 391 This choice of parameters is intended to work well on low-power 392 processors, to minimize packet expansion, and to minimize the size 393 of the cryptographic context. The WORD-LEN of two will work well 394 on 16 bit and higher processors. The packet expansion is 395 determined by the UMAC-OUTPUT-LEN to be only four bytes. The 396 storage requirement, per cryptographic context, is 144 bytes. 397 These parameters ensure a forgery probability of no greater than 398 1/2^30 for each individual packet. Please see the security 399 considerations section in [KBHHKR00] and the references therein for 400 a more detailed discussion. 402 9. SRTP Parameters 404 The SRTP_WINDOW_SIZE (Section 6) is the only currently defined 405 parameter. Other parameters may be added in the future. 407 10. Secure RTCP 409 Secure RTCP follows the definition of Secure RTP, but defines the 410 index differently. In order to differentiate this quantity, we 411 refer to it as the SRTP index. 413 Each sender must use a distinct cryptographic context, as there is 414 no way to synchronize sequencing information among senders. 415 Therefore, each SSRC corresponds to a distinct SRTCP cryptographic 416 context (and to a distinct SRTP context as well). 418 SRTCP is defined as a profile of RTCP, and it adds two new fields 419 to the RTCP packet definition, the SRTCP index and the 420 authentication tag. Those fields are appended to an RTCP packet in 421 order to form an equivalent SRTP packet, so that they follow any 422 other profile-specific extensions. An SRTCP packet is illustrated 423 in Figure 2. 425 Figure 2. The format of a Secure RTCP packet, after Section 426 6.3.1 of [SCFJ96]. In this case, the underlying RTCP packet is 427 a sender report packet; the SRTP format is identical for other 428 RTCP packet types. 430 0 1 2 3 431 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 432 +-->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | |V=2|P| RC | PT=SR=200 | length | 434 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | SSRC of sender | 436 | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 437 | | | ... | 438 | | | sender info | 439 | | | ... | 440 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | | ... | 442 | | | report block 1 | 443 | | | ... | 444 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | | ... | 446 | | | report block 2 | 447 | | | ... | 448 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | | | 450 | | | ... | 451 | | | | 452 | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 453 | | | ... | 454 | | | profile-specific extensions | 455 | | | ... | 456 | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 457 | | | SRTCP index | 458 +-|>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | | ... | 460 | | | authentication tag | 461 | | | ... | 462 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 | +-- Encrypted Portion 465 + ---- Authenticated Portion 466 The SRTCP index is a 32-bit value, which is set to zero before the 467 first SRTCP packet is sent, and is incremented by one after each 468 SRTCP is sent. This index is explicitly included in each packet, 469 in contrast to the `implicit' index approach used for SRTP. 471 SRTCP packet processing is identical to that of SRTP packet 472 processing, with the following changes: 474 * SRTCP replay protection is as defined in Section 6, but using the 475 the SRTCP index as the index i. 477 * SRTCP encryption is as defined in Section 7, but using the 478 definition of the SRTCP Encrypted Portion as defined in this 479 section, and using the SRTCP index as the index i. 481 * The SRTCP authentication tag is defined as in Section 8, but 482 applying the UMAC function to the Authenticated Portion of the 483 SRTCP packet as defined in this section, and using the SRTCP 484 index as the index i. 486 The encryption prefix (Section 6.1 of [SCFJ96]), which is a random 487 32-bit quantity intended to improve privacy, SHOULD NOT be used. 488 This is because SRTP encryption uses an additive stream cipher, and 489 thus the prefix offers no benefit. 491 The maximum number of SRTCP packets is limited to 2^32 = 492 4,294,967,296. The last RTCP packet MUST contain an RTCP BYE. 493 SRTCP senders MUST send an RTCP BYE in the final packet, if the 494 maximum number of SRTCP packets is reached. Similarly, SRTCP 495 receivers MUST act as though the last RTCP packet included a BYE, 496 even if no BYE was included in the packet, if the maximum number of 497 SRTCP packets is reached. 499 11. Rationale 501 SRTP achieves high throughput and low packet expansion by using 502 fast stream ciphers for encryption, universal hash functions for 503 message authentication, and an implicit index for synchronization. 505 Only a single header extension may be appended to the RTP data 506 header, so the use of a header extension for SRTP was avoided. 507 SRTP and SRTCP are defined as profiles of RTP and RTCP, 508 respectively. 510 10.1 Synchronization 511 RTP runs over unreliable transport. Thus, maintaining 512 synchronization of the cryptographic context between the sender and 513 receiver is a conspicuous challenge. Because of the requirement to 514 minimize packet expansion, no explicit sequencing information 515 should be added. RTP packets contain two fields for 516 synchronization purposes, the timestamp and the sequence number. 517 The timestamp field could be used for cryptographic synchronization 518 in some circumstances. However, this field is not appropriate for 519 such use; from [SCFJ96]: 521 Several consecutive RTP packets may have equal timestamps if 522 they are (logically) generated at once, e.g., belong to the same 523 video frame. Consecutive RTP packets may contain timestamps that 524 are not monotonic if the data is not transmitted in the order it 525 was sampled, as in the case of MPEG interpolated video frames. 527 The RTP sequence number cannot be directly used as a unique 528 identifier for SRTP packets. It has only sixteen bits, which would 529 limit the duration of an SRTP security association to only 64,536 530 packets. 532 The `implicit index' approach works as long as the reorder and loss 533 of the packets is not too great. In particular, 32,768 packets 534 would need to be lost, or a packet would need to be 32,768 packets 535 out of sequence in order for synchronization to be lost. Such 536 drastic loss or reorder is likely to disrupt the RTP application 537 itself. 539 10.2 Replay Protection 541 Replay protection is undoubtedly important for multimedia data. 542 Otherwise, it would be possible for an adversary to perform simple 543 manipulations on data that subverted security. For example, in a 544 voice application, the phrase ``yes'' could be substituted for 545 ``no'' if replay protection were not present. 547 10.3 Source Origin Authentication 549 `Source origin authentication' was listed as an option in the 550 security goals, not because it not an appropriate goal, but because 551 it may not be achievable. This goal may be desirable in some 552 circumstances, such as multicast environments in which the sender 553 is more trusted than the receivers, or when translators or mixers 554 (Section 2.3 of [SCFJ96]) are used. However, it is not clear 555 that this capability can always be provided, as mixers and 556 translators can change the payload. Furthermore, this security 557 service essentially requires digital signatures (at least if 558 collusion resistance is required [BF00]). 560 Two examples of the multicast scenario mentioned above are a 561 military commander addressing his troops over RTP, and financial 562 market data sent over RTP. In these situations, a `stream signing' 563 method can provide digital signatures on the entire RTP packets. 564 An extensive literature on such methods is developing, and it is 565 reasonable to expect that one of these methods can be reduced to 566 practice and specified for RTP. This suggests that it should be 567 left as an option in the current specification. A future effort 568 can define a stream signing method as an authentication type for 569 RTP, which could be used as a replacement for a message integrity 570 transform. 572 Examples of the mixer and translator scenarios include a translator 573 re-encoding data at a lower rate or in a different encoding, and a 574 mixer combining the audio streams of multiple speakers in a 575 teleconference. In these cases, it is not clear that meaningful 576 source origin authentication is possible, as the data that is 577 received is not the same as the data that is signed. If the 578 translator is trusted by the receivers, then it could sign or 579 re-sign the data streams, but this scenario may not be prevalent. 580 It may be possible to devise a signing scheme that authenticates 581 the source but not the content (enabling the receivers to know that 582 ``John is one of the people talking'', but not providing 583 authentication on who said what) by signing the concatenation of 584 the Contributing source (CSRC) field and some sequencing 585 information (e.g., a timestamp or sequence number), but such 586 schemes require synchronization between the senders. This 587 synchronization is not required by the RTP protocol itself, and may 588 be difficult or impossible to arrange. 590 11. Security Considerations 592 The security of UMAC is well understood, and is described in 593 [KBHHKR00]. 595 Additive ciphers do not provide any security service other than 596 privacy. In particular, they do not provide message authentication 597 (see [RK99] or [S96] for a discussion of this security service). 598 However, SRTP uses a message authentication code to provide that 599 security service. 601 By using `seekable' stream ciphers, SRTP avoids the denial of 602 service attacks that are possible on stream ciphers that lack this 603 property (these attacks are described in Section 3.4 of [B96]). 605 No bit of keystream in an additive stream cipher should ever be 606 used to encrypt multiple distinct plaintext bits. Such keystream 607 reuse (jokingly called a `two-time pad' system by cryptographers), 608 can seriously compromise security. The NSA's VENONA project [C99] 609 provides a historical example of such a compromise. In SRTP, a 610 `two-time pad' is avoided by requiring that both keys and indices 611 be unique. 613 If manual keying is used, two different cryptographic contexts 614 might accidentally use the same encryption key with non-negligible 615 probability, through manual error or procedural inadequacies. 616 Thus, manual keying SHOULD NOT be used for SRTP (or SRTCP). 618 An additive stream cipher is vulnerable to attacks that use 619 statistical knowledge about the plaintext source to enable key 620 collision and time-memory tradeoff attacks [MF00,H80,Bi96]. These 621 attacks take advantage of commonalities among plaintexts, and 622 provide a way for a cryptanalyst to amortize the computational 623 effort of decryption over many keys, thus reducing the effective 624 key size of the cipher. A detailed analysis of these attacks and 625 their applicability to the encryption of Internet traffic is 626 provided in [MF00]. In summary, the effective key size of SRTP 627 when used in a security system in which m distinct keys are used, 628 is equal to the key size of the cipher less the logarithm (base 629 two) of m. Protection against such attacks can be provided simply by 630 increasing the size of the keys used. 632 In order to provide an effective key size of n bits in a deployment 633 in which 2^m SRTP/SRTCP cryptographic contexts will be created, the 634 true key size will need to be n+m bits. The value of m SHOULD be 635 32 bits for networks with 50,000 connections (fully meshed networks 636 with up to 200 devices), and SHOULD be 64 bits for networks with 637 49e+12 connections (fully meshed networks with up to 7,000,000 638 devices). These choices of m ensures that key collision attacks 639 amortized over a ten year period offer no advantage over exhaustive 640 search, when new SC/ESP keys are established for every connection 641 every hour (note that such an attack requires the storage of all 642 network traffic over the ten year period). These choices will 643 suffice for many networks, though SRTP deployments with more 644 stringent security requirements will need to make a detailed 645 assessment of those requirements with respect to the attacks 646 described in [MF00]. 648 Implementations SHOULD use keys that are as large as possible. 649 Please note that in many cases increasing the key size of a cipher 650 does not affect the throughput of that cipher. 652 It is an important point that the m bits of `extra' key provided to 653 thwart these attacks need not be private. In jurisdictions with 654 mandated limits on the length of a secret key, the additional key 655 bits could be made public. This is because those bits are 656 functionally equivalent to the `salt' that is used to protect 657 passwords from dictionary attacks. The fact that the `extra' key 658 bits are distinct for many different keys defeats the key collision 659 and time-memory tradeoff attacks by reducing the number of keys 660 over which cryptanalytic computation can be amortized. 662 Note that other security protocols which use additive ciphers for 663 the encryption of Internet traffic (e.g., SSL, TLS, SSH, IPSEC) are 664 also vulnerable to the attacks described in [MF00]. Those attacks 665 are generic to additive encryption of redundant plaintext, and are 666 not particular to SRTP. 668 12. Contact Information 670 Questions and comments about this memo can be directed to: 672 David A. McGrew 673 David Oran 674 Cisco Systems, Inc. 675 San Jose, CA 95134-1706 USA 676 mcgrew@cisco.com, oran@cisco.com 678 13. References 680 [B97] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", RFC 2119, March 1997. 683 [KA98a] Kent, S., and R. Atkinson, "Security Architecture for IP", 684 RFC 2401, November 1998. 686 [BF00] Boneh, D., and Franklin, M., "Message Authentication in a 687 Multicast Environment", the Proceedings of the Seventh 688 Annual Workshop on Selected Areas in Cryptography (SAC 689 2000), Springer-Verlag. 691 [C99] Crowell, W. P., "Introduction to the VENONA Project", 692 http://www.nsa.gov:8080/docs/venona/index.html. 693 [H80] Hellman, M. E., "A cryptanalytic time-memory trade-off", IEEE 694 Transactions on Information Theory, July 1980, pp. 401-406. 696 [KBHHKR00] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, 697 H., Rogaway, P., "UMAC: Message Authentication Code using 698 Universal Hashing", Internet Draft, October 2000, 699 . 700 [LRW00] Lipmaa, H., Rogaway, P., and Wagner, D., "Comments to NIST 701 Concerning AES Modes of Operation: CTR-Mode Encryption", 702 NIST Workshop on AES Modes of Operation, 703 http://csrc.nist.gov/encryption/aes/modes/lipmaa-ctr.pdf 705 [M00] McGrew, D., "Segmented Integer Counter Mode: Specification 706 and Rationale", NIST Workshop on AES Modes of Operation, 707 http://www.mindspring.com/~dmcgrew/sic-mode.pdf 708 [MF00] McGrew, D., and Fluhrer, S., "Attacks on Encryption of 709 Redundant Plaintext and Implications on Internet Security", 710 the Proceedings of the Seventh Annual Workshop on Selected 711 Areas in Cryptography (SAC 2000), Springer-Verlag. 713 [MF00b] McGrew, D., and Fluhrer, S., "The Stream Cipher LEVIATHAN: 714 Specification and Supporting Documentation", Submission to 715 the New European Schemes for Signatures, Integrity, and 716 Encryption (NESSIE) Process, October, 2000. 717 http://www.cryptonessie.org/. 719 [R92] Rueppel, R., "Stream Ciphers", Chapter 2 of Simmons, G., 720 "Contemporary Cryptology: the Science of Information 721 Integrity," 1992, IEEE Press. 723 [RC94] Rogaway, P. and Coppersmith, D., "A Software-Optimized 724 Encryption Algorithm", Proceedings of the 1994 Fast 725 Software Encryption Workshop, Lecture Notes In Computer 726 Science, Volume 809, Springer-Verlag, 1994, pp. 56-63. 728 [RC98] Rogaway, P. and Coppersmith, D., "A Software-Optimized 729 Encryption Algorithm", Journal of Cryptology, Volume 11, 730 Number 4, Springer-Verlag, 1998, Pages 273-287. Also 731 available on the Internet at 732 http://www.cs.ucdavis.edu/~rogaway/papers/seal-abstract.html. 734 [RK99] Rescorla, E., and Korver, B., "Guidelines for Writing RFC 735 Text on Security Considerations," 736 draft-rescorla-sec-cons-00.txt 738 [S96] Schneier, B. "Applied Cryptography: Protocols, Algorithms, 739 and Source Code in C", Wiley, 1996. 741 [SCFJ96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 742 "RTP: A Transport Protocol for Real-Time Applications", 743 IETF Request For Comments RFC 1889.