1 2 3 4 5 6 7Network Working Group M. Baugher 8Request for Comments: 3711 D. McGrew 9Category: Standards Track Cisco Systems, Inc. 10 M. Naslund 11 E. Carrara 12 K. Norrman 13 Ericsson Research 14 March 2004 15 16 17 The Secure Real-time Transport Protocol (SRTP) 18 19Status of this Memo 20 21 This document specifies an Internet standards track protocol for the 22 Internet community, and requests discussion and suggestions for 23 improvements. Please refer to the current edition of the "Internet 24 Official Protocol Standards" (STD 1) for the standardization state 25 and status of this protocol. Distribution of this memo is unlimited. 26 27Copyright Notice 28 29 Copyright (C) The Internet Society (2004). All Rights Reserved. 30 31Abstract 32 33 This document describes the Secure Real-time Transport Protocol 34 (SRTP), a profile of the Real-time Transport Protocol (RTP), which 35 can provide confidentiality, message authentication, and replay 36 protection to the RTP traffic and to the control traffic for RTP, the 37 Real-time Transport Control Protocol (RTCP). 38 39Table of Contents 40 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 43 2. Goals and Features . . . . . . . . . . . . . . . . . . . . . . 4 44 2.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 45 3. SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . . 5 46 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 6 47 3.2. SRTP Cryptographic Contexts. . . . . . . . . . . . . . . 7 48 3.2.1. Transform-independent parameters . . . . . . . . 8 49 3.2.2. Transform-dependent parameters . . . . . . . . . 10 50 3.2.3. Mapping SRTP Packets to Cryptographic Contexts . 10 51 3.3. SRTP Packet Processing . . . . . . . . . . . . . . . . . 11 52 3.3.1. Packet Index Determination, and ROC, s_l Update. 13 53 3.3.2. Replay Protection. . . . . . . . . . . . . . . . 15 54 3.4. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15 55 56 57 58Baugher, et al. Standards Track [Page 1] 59 60RFC 3711 SRTP March 2004 61 62 63 4. Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19 64 4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19 65 4.1.1. AES in Counter Mode. . . . . . . . . . . . . . . 21 66 4.1.2. AES in f8-mode . . . . . . . . . . . . . . . . . 22 67 4.1.3. NULL Cipher. . . . . . . . . . . . . . . . . . . 25 68 4.2. Message Authentication and Integrity . . . . . . . . . . 25 69 4.2.1. HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25 70 4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 26 71 4.3.1. Key Derivation Algorithm . . . . . . . . . . . . 26 72 4.3.2. SRTCP Key Derivation . . . . . . . . . . . . . . 28 73 4.3.3. AES-CM PRF . . . . . . . . . . . . . . . . . . . 28 74 5. Default and mandatory-to-implement Transforms. . . . . . . . . 28 75 5.1. Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29 76 5.2. Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29 77 5.3. Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29 78 6. Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29 79 7. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30 80 7.1. Key derivation . . . . . . . . . . . . . . . . . . . . . 30 81 7.2. Salting key. . . . . . . . . . . . . . . . . . . . . . . 30 82 7.3. Message Integrity from Universal Hashing . . . . . . . . 31 83 7.4. Data Origin Authentication Considerations. . . . . . . . 31 84 7.5. Short and Zero-length Message Authentication . . . . . . 32 85 8. Key Management Considerations. . . . . . . . . . . . . . . . . 33 86 8.1. Re-keying . . . . . . . . . . . . . . . . . . . . . . . 34 87 8.1.1. Use of the <From, To> for re-keying. . . . . . . 34 88 8.2. Key Management parameters. . . . . . . . . . . . . . . . 35 89 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 90 9.1. SSRC collision and two-time pad. . . . . . . . . . . . . 37 91 9.2. Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38 92 9.3. Confidentiality of the RTP Payload . . . . . . . . . . . 39 93 9.4. Confidentiality of the RTP Header. . . . . . . . . . . . 40 94 9.5. Integrity of the RTP payload and header. . . . . . . . . 40 95 9.5.1. Risks of Weak or Null Message Authentication. . . 42 96 9.5.2. Implicit Header Authentication . . . . . . . . . 43 97 10. Interaction with Forward Error Correction mechanisms. . . . . 43 98 11. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43 99 11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43 100 11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44 101 11.3. Re-keying and access control . . . . . . . . . . . . . . 45 102 11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46 103 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46 104 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 47 107 14.2. Informative References . . . . . . . . . . . . . . . . . 48 108 Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51 109 Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51 110 B.1. AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51 111 112 113 114Baugher, et al. Standards Track [Page 2] 115 116RFC 3711 SRTP March 2004 117 118 119 B.2. AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52 120 B.3. Key Derivation Test Vectors. . . . . . . . . . . . . . . 53 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 122 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56 123 1241. Introduction 125 126 This document describes the Secure Real-time Transport Protocol 127 (SRTP), a profile of the Real-time Transport Protocol (RTP), which 128 can provide confidentiality, message authentication, and replay 129 protection to the RTP traffic and to the control traffic for RTP, 130 RTCP (the Real-time Transport Control Protocol) [RFC3350]. 131 132 SRTP provides a framework for encryption and message authentication 133 of RTP and RTCP streams (Section 3). SRTP defines a set of default 134 cryptographic transforms (Sections 4 and 5), and it allows new 135 transforms to be introduced in the future (Section 6). With 136 appropriate key management (Sections 7 and 8), SRTP is secure 137 (Sections 9) for unicast and multicast RTP applications (Section 11). 138 139 SRTP can achieve high throughput and low packet expansion. SRTP 140 proves to be a suitable protection for heterogeneous environments 141 (mix of wired and wireless networks). To get such features, default 142 transforms are described, based on an additive stream cipher for 143 encryption, a keyed-hash based function for message authentication, 144 and an "implicit" index for sequencing/synchronization based on the 145 RTP sequence number for SRTP and an index number for Secure RTCP 146 (SRTCP). 147 1481.1. Notational Conventions 149 150 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. The 153 terminology conforms to [RFC2828] with the following exception. For 154 simplicity we use the term "random" throughout the document to denote 155 randomly or pseudo-randomly generated values. Large amounts of 156 random bits may be difficult to obtain, and for the security of SRTP, 157 pseudo-randomness is sufficient [RFC1750]. 158 159 By convention, the adopted representation is the network byte order, 160 i.e., the left most bit (octet) is the most significant one. By XOR 161 we mean bitwise addition modulo 2 of binary strings, and || denotes 162 concatenation. In other words, if C = A || B, then the most 163 significant bits of C are the bits of A, and the least significant 164 bits of C equal the bits of B. Hexadecimal numbers are prefixed by 165 0x. 166 167 168 169 170Baugher, et al. Standards Track [Page 3] 171 172RFC 3711 SRTP March 2004 173 174 175 The word "encryption" includes also use of the NULL algorithm (which 176 in practice does leave the data in the clear). 177 178 With slight abuse of notation, we use the terms "message 179 authentication" and "authentication tag" as is common practice, even 180 though in some circumstances, e.g., group communication, the service 181 provided is actually only integrity protection and not data origin 182 authentication. 183 1842. Goals and Features 185 186 The security goals for SRTP are to ensure: 187 188 * the confidentiality of the RTP and RTCP payloads, and 189 190 * the integrity of the entire RTP and RTCP packets, together with 191 protection against replayed packets. 192 193 These security services are optional and independent from each other, 194 except that SRTCP integrity protection is mandatory (malicious or 195 erroneous alteration of RTCP messages could otherwise disrupt the 196 processing of the RTP stream). 197 198 Other, functional, goals for the protocol are: 199 200 * a framework that permits upgrading with new cryptographic 201 transforms, 202 203 * low bandwidth cost, i.e., a framework preserving RTP header 204 compression efficiency, 205 206 and, asserted by the pre-defined transforms: 207 208 * a low computational cost, 209 210 * a small footprint (i.e., small code size and data memory for 211 keying information and replay lists), 212 213 * limited packet expansion to support the bandwidth economy goal, 214 215 * independence from the underlying transport, network, and physical 216 layers used by RTP, in particular high tolerance to packet loss 217 and re-ordering. 218 219 These properties ensure that SRTP is a suitable protection scheme for 220 RTP/RTCP in both wired and wireless scenarios. 221 222 223 224 225 226Baugher, et al. Standards Track [Page 4] 227 228RFC 3711 SRTP March 2004 229 230 2312.1. Features 232 233 Besides the above mentioned direct goals, SRTP provides for some 234 additional features. They have been introduced to lighten the burden 235 on key management and to further increase security. They include: 236 237 * A single "master key" can provide keying material for 238 confidentiality and integrity protection, both for the SRTP stream 239 and the corresponding SRTCP stream. This is achieved with a key 240 derivation function (see Section 4.3), providing "session keys" 241 for the respective security primitive, securely derived from the 242 master key. 243 244 * In addition, the key derivation can be configured to periodically 245 refresh the session keys, which limits the amount of ciphertext 246 produced by a fixed key, available for an adversary to 247 cryptanalyze. 248 249 * "Salting keys" are used to protect against pre-computation and 250 time-memory tradeoff attacks [MF00] [BS00]. 251 252 Detailed rationale for these features can be found in Section 7. 253 2543. SRTP Framework 255 256 RTP is the Real-time Transport Protocol [RFC3550]. We define SRTP as 257 a profile of RTP. This profile is an extension to the RTP 258 Audio/Video Profile [RFC3551]. Except where explicitly noted, all 259 aspects of that profile apply, with the addition of the SRTP security 260 features. Conceptually, we consider SRTP to be a "bump in the stack" 261 implementation which resides between the RTP application and the 262 transport layer. SRTP intercepts RTP packets and then forwards an 263 equivalent SRTP packet on the sending side, and intercepts SRTP 264 packets and passes an equivalent RTP packet up the stack on the 265 receiving side. 266 267 Secure RTCP (SRTCP) provides the same security services to RTCP as 268 SRTP does to RTP. SRTCP message authentication is MANDATORY and 269 thereby protects the RTCP fields to keep track of membership, provide 270 feedback to RTP senders, or maintain packet sequence counters. SRTCP 271 is described in Section 3.4. 272 273 274 275 276 277 278 279 280 281 282Baugher, et al. Standards Track [Page 5] 283 284RFC 3711 SRTP March 2004 285 286 2873.1. Secure RTP 288 289 The format of an SRTP packet is illustrated in Figure 1. 290 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 294 |V=2|P|X| CC |M| PT | sequence number | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 296 | timestamp | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 298 | synchronization source (SSRC) identifier | | 299 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 300 | contributing source (CSRC) identifiers | | 301 | .... | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 303 | RTP extension (OPTIONAL) | | 304 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 305 | | payload ... | | 306 | | +-------------------------------+ | 307 | | | RTP padding | RTP pad count | | 308 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 309 | ~ SRTP MKI (OPTIONAL) ~ | 310 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 311 | : authentication tag (RECOMMENDED) : | 312 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 313 | | 314 +- Encrypted Portion* Authenticated Portion ---+ 315 316 Figure 1. The format of an SRTP packet. *Encrypted Portion is the 317 same size as the plaintext for the Section 4 pre-defined transforms. 318 319 The "Encrypted Portion" of an SRTP packet consists of the encryption 320 of the RTP payload (including RTP padding when present) of the 321 equivalent RTP packet. The Encrypted Portion MAY be the exact size 322 of the plaintext or MAY be larger. Figure 1 shows the RTP payload 323 including any possible padding for RTP [RFC3550]. 324 325 None of the pre-defined encryption transforms uses any padding; for 326 these, the RTP and SRTP payload sizes match exactly. New transforms 327 added to SRTP (following Section 6) may require padding, and may 328 hence produce larger payloads. RTP provides its own padding format 329 (as seen in Fig. 1), which due to the padding indicator in the RTP 330 header has merits in terms of compactness relative to paddings using 331 prefix-free codes. This RTP padding SHALL be the default method for 332 transforms requiring padding. Transforms MAY specify other padding 333 methods, and MUST then specify the amount, format, and processing of 334 their padding. It is important to note that encryption transforms 335 336 337 338Baugher, et al. Standards Track [Page 6] 339 340RFC 3711 SRTP March 2004 341 342 343 that use padding are vulnerable to subtle attacks, especially when 344 message authentication is not used [V02]. Each specification for a 345 new encryption transform needs to carefully consider and describe the 346 security implications of the padding that it uses. Message 347 authentication codes define their own padding, so this default does 348 not apply to authentication transforms. 349 350 The OPTIONAL MKI and the RECOMMENDED authentication tag are the only 351 fields defined by SRTP that are not in RTP. Only 8-bit alignment is 352 assumed. 353 354 MKI (Master Key Identifier): configurable length, OPTIONAL. The 355 MKI is defined, signaled, and used by key management. The 356 MKI identifies the master key from which the session 357 key(s) were derived that authenticate and/or encrypt the 358 particular packet. Note that the MKI SHALL NOT identify 359 the SRTP cryptographic context, which is identified 360 according to Section 3.2.3. The MKI MAY be used by key 361 management for the purposes of re-keying, identifying a 362 particular master key within the cryptographic context 363 (Section 3.2.1). 364 365 Authentication tag: configurable length, RECOMMENDED. The 366 authentication tag is used to carry message authentication 367 data. The Authenticated Portion of an SRTP packet 368 consists of the RTP header followed by the Encrypted 369 Portion of the SRTP packet. Thus, if both encryption and 370 authentication are applied, encryption SHALL be applied 371 before authentication on the sender side and conversely on 372 the receiver side. The authentication tag provides 373 authentication of the RTP header and payload, and it 374 indirectly provides replay protection by authenticating 375 the sequence number. Note that the MKI is not integrity 376 protected as this does not provide any extra protection. 377 3783.2. SRTP Cryptographic Contexts 379 380 Each SRTP stream requires the sender and receiver to maintain 381 cryptographic state information. This information is called the 382 "cryptographic context". 383 384 SRTP uses two types of keys: session keys and master keys. By a 385 "session key", we mean a key which is used directly in a 386 cryptographic transform (e.g., encryption or message authentication), 387 and by a "master key", we mean a random bit string (given by the key 388 management protocol) from which session keys are derived in a 389 390 391 392 393 394Baugher, et al. Standards Track [Page 7] 395 396RFC 3711 SRTP March 2004 397 398 399 cryptographically secure way. The master key(s) and other parameters 400 in the cryptographic context are provided by key management 401 mechanisms external to SRTP, see Section 8. 402 4033.2.1. Transform-independent parameters 404 405 Transform-independent parameters are present in the cryptographic 406 context independently of the particular encryption or authentication 407 transforms that are used. The transform-independent parameters of 408 the cryptographic context for SRTP consist of: 409 410 * a 32-bit unsigned rollover counter (ROC), which records how many 411 times the 16-bit RTP sequence number has been reset to zero after 412 passing through 65,535. Unlike the sequence number (SEQ), which 413 SRTP extracts from the RTP packet header, the ROC is maintained by 414 SRTP as described in Section 3.3.1. 415 416 We define the index of the SRTP packet corresponding to a given 417 ROC and RTP sequence number to be the 48-bit quantity 418 419 i = 2^16 * ROC + SEQ. 420 421 * for the receiver only, a 16-bit sequence number s_l, which can be 422 thought of as the highest received RTP sequence number (see 423 Section 3.3.1 for its handling), which SHOULD be authenticated 424 since message authentication is RECOMMENDED, 425 426 * an identifier for the encryption algorithm, i.e., the cipher and 427 its mode of operation, 428 429 * an identifier for the message authentication algorithm, 430 431 * a replay list, maintained by the receiver only (when 432 authentication and replay protection are provided), containing 433 indices of recently received and authenticated SRTP packets, 434 435 * an MKI indicator (0/1) as to whether an MKI is present in SRTP and 436 SRTCP packets, 437 438 * if the MKI indicator is set to one, the length (in octets) of the 439 MKI field, and (for the sender) the actual value of the currently 440 active MKI (the value of the MKI indicator and length MUST be kept 441 fixed for the lifetime of the context), 442 443 * the master key(s), which MUST be random and kept secret, 444 445 446 447 448 449 450Baugher, et al. Standards Track [Page 8] 451 452RFC 3711 SRTP March 2004 453 454 455 * for each master key, there is a counter of the number of SRTP 456 packets that have been processed (sent) with that master key 457 (essential for security, see Sections 3.3.1 and 9), 458 459 * non-negative integers n_e, and n_a, determining the length of the 460 session keys for encryption, and message authentication. 461 462 In addition, for each master key, an SRTP stream MAY use the 463 following associated values: 464 465 * a master salt, to be used in the key derivation of session keys. 466 This value, when used, MUST be random, but MAY be public. Use of 467 master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" 468 salt is treated as 00...0. 469 470 * an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", 471 where an unspecified value is treated as zero. The constraint to 472 be a power of 2 simplifies the session-key derivation 473 implementation, see Section 4.3. 474 475 * an MKI value, 476 477 * <From, To> values, specifying the lifetime for a master key, 478 expressed in terms of the two 48-bit index values inside whose 479 range (including the range end-points) the master key is valid. 480 For the use of <From, To>, see Section 8.1.1. <From, To> is an 481 alternative to the MKI and assumes that a master key is in one- 482 to-one correspondence with the SRTP session key on which the 483 <From, To> range is defined. 484 485 SRTCP SHALL by default share the crypto context with SRTP, except: 486 487 * no rollover counter and s_l-value need to be maintained as the 488 RTCP index is explicitly carried in each SRTCP packet, 489 490 * a separate replay list is maintained (when replay protection is 491 provided), 492 493 * SRTCP maintains a separate counter for its master key (even if the 494 master key is the same as that for SRTP, see below), as a means to 495 maintain a count of the number of SRTCP packets that have been 496 processed with that key. 497 498 Note in particular that the master key(s) MAY be shared between SRTP 499 and the corresponding SRTCP, if the pre-defined transforms (including 500 the key derivation) are used but the session key(s) MUST NOT be so 501 shared. 502 503 504 505 506Baugher, et al. Standards Track [Page 9] 507 508RFC 3711 SRTP March 2004 509 510 511 In addition, there can be cases (see Sections 8 and 9.1) where 512 several SRTP streams within a given RTP session, identified by their 513 synchronization source (SSRCs, which is part of the RTP header), 514 share most of the crypto context parameters (including possibly 515 master and session keys). In such cases, just as in the normal 516 SRTP/SRTCP parameter sharing above, separate replay lists and packet 517 counters for each stream (SSRC) MUST still be maintained. Also, 518 separate SRTP indices MUST then be maintained. 519 520 A summary of parameters, pre-defined transforms, and default values 521 for the above parameters (and other SRTP parameters) can be found in 522 Sections 5 and 8.2. 523 5243.2.2. Transform-dependent parameters 525 526 All encryption, authentication/integrity, and key derivation 527 parameters are defined in the transforms section (Section 4). 528 Typical examples of such parameters are block size of ciphers, 529 session keys, data for the Initialization Vector (IV) formation, etc. 530 Future SRTP transform specifications MUST include a section to list 531 the additional cryptographic context's parameters for that transform, 532 if any. 533 5343.2.3. Mapping SRTP Packets to Cryptographic Contexts 535 536 Recall that an RTP session for each participant is defined [RFC3550] 537 by a pair of destination transport addresses (one network address 538 plus a port pair for RTP and RTCP), and that a multimedia session is 539 defined as a collection of RTP sessions. For example, a particular 540 multimedia session could include an audio RTP session, a video RTP 541 session, and a text RTP session. 542 543 A cryptographic context SHALL be uniquely identified by the triplet 544 context identifier: 545 546 context id = <SSRC, destination network address, destination 547 transport port number> 548 549 where the destination network address and the destination transport 550 port are the ones in the SRTP packet. It is assumed that, when 551 presented with this information, the key management returns a context 552 with the information as described in Section 3.2. 553 554 As noted above, SRTP and SRTCP by default share the bulk of the 555 parameters in the cryptographic context. Thus, retrieving the crypto 556 context parameters for an SRTCP stream in practice may imply a 557 binding to the correspondent SRTP crypto context. It is up to the 558 implementation to assure such binding, since the RTCP port may not be 559 560 561 562Baugher, et al. Standards Track [Page 10] 563 564RFC 3711 SRTP March 2004 565 566 567 directly deducible from the RTP port only. Alternatively, the key 568 management may choose to provide separate SRTP- and SRTCP- contexts, 569 duplicating the common parameters (such as master key(s)). The 570 latter approach then also enables SRTP and SRTCP to use, e.g., 571 distinct transforms, if so desired. Similar considerations arise 572 when multiple SRTP streams, forming part of one single RTP session, 573 share keys and other parameters. 574 575 If no valid context can be found for a packet corresponding to a 576 certain context identifier, that packet MUST be discarded. 577 5783.3. SRTP Packet Processing 579 580 The following applies to SRTP. SRTCP is described in Section 3.4. 581 582 Assuming initialization of the cryptographic context(s) has taken 583 place via key management, the sender SHALL do the following to 584 construct an SRTP packet: 585 586 1. Determine which cryptographic context to use as described in 587 Section 3.2.3. 588 589 2. Determine the index of the SRTP packet using the rollover counter, 590 the highest sequence number in the cryptographic context, and the 591 sequence number in the RTP packet, as described in Section 3.3.1. 592 593 3. Determine the master key and master salt. This is done using the 594 index determined in the previous step or the current MKI in the 595 cryptographic context, according to Section 8.1. 596 597 4. Determine the session keys and session salt (if they are used by 598 the transform) as described in Section 4.3, using master key, 599 master salt, key_derivation_rate, and session key-lengths in the 600 cryptographic context with the index, determined in Steps 2 and 3. 601 602 5. Encrypt the RTP payload to produce the Encrypted Portion of the 603 packet (see Section 4.1, for the defined ciphers). This step uses 604 the encryption algorithm indicated in the cryptographic context, 605 the session encryption key and the session salt (if used) found in 606 Step 4 together with the index found in Step 2. 607 608 6. If the MKI indicator is set to one, append the MKI to the packet. 609 610 7. For message authentication, compute the authentication tag for the 611 Authenticated Portion of the packet, as described in Section 4.2. 612 This step uses the current rollover counter, the authentication 613 614 615 616 617 618Baugher, et al. Standards Track [Page 11] 619 620RFC 3711 SRTP March 2004 621 622 623 algorithm indicated in the cryptographic context, and the session 624 authentication key found in Step 4. Append the authentication tag 625 to the packet. 626 627 8. If necessary, update the ROC as in Section 3.3.1, using the packet 628 index determined in Step 2. 629 630 To authenticate and decrypt an SRTP packet, the receiver SHALL do the 631 following: 632 633 1. Determine which cryptographic context to use as described in 634 Section 3.2.3. 635 636 2. Run the algorithm in Section 3.3.1 to get the index of the SRTP 637 packet. The algorithm uses the rollover counter and highest 638 sequence number in the cryptographic context with the sequence 639 number in the SRTP packet, as described in Section 3.3.1. 640 641 3. Determine the master key and master salt. If the MKI indicator in 642 the context is set to one, use the MKI in the SRTP packet, 643 otherwise use the index from the previous step, according to 644 Section 8.1. 645 646 4. Determine the session keys, and session salt (if used by the 647 transform) as described in Section 4.3, using master key, master 648 salt, key_derivation_rate and session key-lengths in the 649 cryptographic context with the index, determined in Steps 2 and 3. 650 651 5. For message authentication and replay protection, first check if 652 the packet has been replayed (Section 3.3.2), using the Replay 653 List and the index as determined in Step 2. If the packet is 654 judged to be replayed, then the packet MUST be discarded, and the 655 event SHOULD be logged. 656 657 Next, perform verification of the authentication tag, using the 658 rollover counter from Step 2, the authentication algorithm 659 indicated in the cryptographic context, and the session 660 authentication key from Step 4. If the result is "AUTHENTICATION 661 FAILURE" (see Section 4.2), the packet MUST be discarded from 662 further processing and the event SHOULD be logged. 663 664 6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for 665 the defined ciphers), using the decryption algorithm indicated in 666 the cryptographic context, the session encryption key and salt (if 667 used) found in Step 4 with the index from Step 2. 668 669 670 671 672 673 674Baugher, et al. Standards Track [Page 12] 675 676RFC 3711 SRTP March 2004 677 678 679 7. Update the rollover counter and highest sequence number, s_l, in 680 the cryptographic context as in Section 3.3.1, using the packet 681 index estimated in Step 2. If replay protection is provided, also 682 update the Replay List as described in Section 3.3.2. 683 684 8. When present, remove the MKI and authentication tag fields from 685 the packet. 686 6873.3.1. Packet Index Determination, and ROC, s_l Update 688 689 SRTP implementations use an "implicit" packet index for sequencing, 690 i.e., not all of the index is explicitly carried in the SRTP packet. 691 For the pre-defined transforms, the index i is used in replay 692 protection (Section 3.3.2), encryption (Section 4.1), message 693 authentication (Section 4.2), and for the key derivation (Section 694 4.3). 695 696 When the session starts, the sender side MUST set the rollover 697 counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps 698 modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 699 (see security aspects below). The sender's packet index is then 700 defined as 701 702 i = 2^16 * ROC + SEQ. 703 704 Receiver-side implementations use the RTP sequence number to 705 determine the correct index of a packet, which is the location of the 706 packet in the sequence of all SRTP packets. A robust approach for 707 the proper use of a rollover counter requires its handling and use to 708 be well defined. In particular, out-of-order RTP packets with 709 sequence numbers close to 2^16 or zero must be properly handled. 710 711 The index estimate is based on the receiver's locally maintained ROC 712 and s_l values. At the setup of the session, the ROC MUST be set to 713 zero. Receivers joining an on-going session MUST be given the 714 current ROC value using out-of-band signaling such as key-management 715 signaling. Furthermore, the receiver SHALL initialize s_l to the RTP 716 sequence number (SEQ) of the first observed SRTP packet (unless the 717 initial value is provided by out of band signaling such as key 718 management). 719 720 On consecutive SRTP packets, the receiver SHOULD estimate the index 721 as 722 i = 2^16 * v + SEQ, 723 724 where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) 725 such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC 726 + s_l (see Appendix A for pseudocode). 727 728 729 730Baugher, et al. Standards Track [Page 13] 731 732RFC 3711 SRTP March 2004 733 734 735 After the packet has been processed and authenticated (when enabled 736 for SRTP packets for the session), the receiver MUST use v to 737 conditionally update its s_l and ROC variables as follows. If 738 v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, 739 then s_l is set to SEQ if and only if SEQ is larger than the current 740 s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is 741 set to SEQ and ROC is set to v. 742 743 After a re-keying occurs (changing to a new master key), the rollover 744 counter always maintains its sequence of values, i.e., it MUST NOT be 745 reset to zero. 746 747 As the rollover counter is 32 bits long and the sequence number is 16 748 bits long, the maximum number of packets belonging to a given SRTP 749 stream that can be secured with the same key is 2^48 using the pre- 750 defined transforms. After that number of SRTP packets have been sent 751 with a given (master or session) key, the sender MUST NOT send any 752 more packets with that key. (There exists a similar limit for SRTCP, 753 which in practice may be more restrictive, see Section 9.2.) This 754 limitation enforces a security benefit by providing an upper bound on 755 the amount of traffic that can pass before cryptographic keys are 756 changed. Re-keying (see Section 8.1) MUST be triggered, before this 757 amount of traffic, and MAY be triggered earlier, e.g., for increased 758 security and access control to media. Recurring key derivation by 759 means of a non-zero key_derivation_rate (see Section 4.3), also gives 760 stronger security but does not change the above absolute maximum 761 value. 762 763 On the receiver side, there is a caveat to updating s_l and ROC: if 764 message authentication is not present, neither the initialization of 765 s_l, nor the ROC update can be made completely robust. The 766 receiver's "implicit index" approach works for the pre-defined 767 transforms as long as the reorder and loss of the packets are not too 768 great and bit-errors do not occur in unfortunate ways. In 769 particular, 2^15 packets would need to be lost, or a packet would 770 need to be 2^15 packets out of sequence before synchronization is 771 lost. Such drastic loss or reorder is likely to disrupt the RTP 772 application itself. 773 774 The algorithm for the index estimate and ROC update is a matter of 775 implementation, and should take into consideration the environment 776 (e.g., packet loss rate) and the cases when synchronization is likely 777 to be lost, e.g., when the initial sequence number (randomly chosen 778 by RTP) is not known in advance (not sent in the key management 779 protocol) but may be near to wrap modulo 2^16. 780 781 782 783 784 785 786Baugher, et al. Standards Track [Page 14] 787 788RFC 3711 SRTP March 2004 789 790 791 A more elaborate and more robust scheme than the one given above is 792 the handling of RTP's own "rollover counter", see Appendix A.1 of 793 [RFC3550]. 794 7953.3.2. Replay Protection 796 797 Secure replay protection is only possible when integrity protection 798 is present. It is RECOMMENDED to use replay protection, both for RTP 799 and RTCP, as integrity protection alone cannot assure security 800 against replay attacks. 801 802 A packet is "replayed" when it is stored by an adversary, and then 803 re-injected into the network. When message authentication is 804 provided, SRTP protects against such attacks through a Replay List. 805 Each SRTP receiver maintains a Replay List, which conceptually 806 contains the indices of all of the packets which have been received 807 and authenticated. In practice, the list can use a "sliding window" 808 approach, so that a fixed amount of storage suffices for replay 809 protection. Packet indices which lag behind the packet index in the 810 context by more than SRTP-WINDOW-SIZE can be assumed to have been 811 received, where SRTP-WINDOW-SIZE is a receiver-side, implementation- 812 dependent parameter and MUST be at least 64, but which MAY be set to 813 a higher value. 814 815 The receiver checks the index of an incoming packet against the 816 replay list and the window. Only packets with index ahead of the 817 window, or, inside the window but not already received, SHALL be 818 accepted. 819 820 After the packet has been authenticated (if necessary the window is 821 first moved ahead), the replay list SHALL be updated with the new 822 index. 823 824 The Replay List can be efficiently implemented by using a bitmap to 825 represent which packets have been received, as described in the 826 Security Architecture for IP [RFC2401]. 827 8283.4. Secure RTCP 829 830 Secure RTCP follows the definition of Secure RTP. SRTCP adds three 831 mandatory new fields (the SRTCP index, an "encrypt-flag", and the 832 authentication tag) and one optional field (the MKI) to the RTCP 833 packet definition. The three mandatory fields MUST be appended to an 834 RTCP packet in order to form an equivalent SRTCP packet. The added 835 fields follow any other profile-specific extensions. 836 837 838 839 840 841 842Baugher, et al. Standards Track [Page 15] 843 844RFC 3711 SRTP March 2004 845 846 847 According to Section 6.1 of [RFC3550], there is a REQUIRED packet 848 format for compound packets. SRTCP MUST be given packets according 849 to that requirement in the sense that the first part MUST be a sender 850 report or a receiver report. However, the RTCP encryption prefix (a 851 random 32-bit quantity) specified in that Section MUST NOT be used 852 since, as is stated there, it is only applicable to the encryption 853 method specified in [RFC3550] and is not needed by the cryptographic 854 mechanisms used in SRTP. 855 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 859 |V=2|P| RC | PT=SR or RR | length | | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 861 | SSRC of sender | | 862 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 863 | ~ sender info ~ | 864 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 865 | ~ report block 1 ~ | 866 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 867 | ~ report block 2 ~ | 868 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 869 | ~ ... ~ | 870 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 871 | |V=2|P| SC | PT=SDES=202 | length | | 872 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 873 | | SSRC/CSRC_1 | | 874 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 875 | ~ SDES items ~ | 876 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 877 | ~ ... ~ | 878 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 879 | |E| SRTCP index | | 880 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 881 | ~ SRTCP MKI (OPTIONAL) ~ | 882 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 883 | : authentication tag : | 884 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 885 | | 886 +-- Encrypted Portion Authenticated Portion -----+ 887 888 889 Figure 2. An example of the format of a Secure RTCP packet, 890 consisting of an underlying RTCP compound packet with a Sender Report 891 and SDES packet. 892 893 894 895 896 897 898Baugher, et al. Standards Track [Page 16] 899 900RFC 3711 SRTP March 2004 901 902 903 The Encrypted Portion of an SRTCP packet consists of the encryption 904 (Section 4.1) of the RTCP payload of the equivalent compound RTCP 905 packet, from the first RTCP packet, i.e., from the ninth (9) octet to 906 the end of the compound packet. The Authenticated Portion of an 907 SRTCP packet consists of the entire equivalent (eventually compound) 908 RTCP packet, the E flag, and the SRTCP index (after any encryption 909 has been applied to the payload). 910 911 The added fields are: 912 913 E-flag: 1 bit, REQUIRED 914 The E-flag indicates if the current SRTCP packet is 915 encrypted or unencrypted. Section 9.1 of [RFC3550] allows 916 the split of a compound RTCP packet into two lower-layer 917 packets, one to be encrypted and one to be sent in the 918 clear. The E bit set to "1" indicates encrypted packet, and 919 "0" indicates non-encrypted packet. 920 921 SRTCP index: 31 bits, REQUIRED 922 The SRTCP index is a 31-bit counter for the SRTCP packet. 923 The index is explicitly included in each packet, in contrast 924 to the "implicit" index approach used for SRTP. The SRTCP 925 index MUST be set to zero before the first SRTCP packet is 926 sent, and MUST be incremented by one, modulo 2^31, after 927 each SRTCP packet is sent. In particular, after a re-key, 928 the SRTCP index MUST NOT be reset to zero again. 929 930 Authentication Tag: configurable length, REQUIRED 931 The authentication tag is used to carry message 932 authentication data. 933 934 MKI: configurable length, OPTIONAL 935 The MKI is the Master Key Indicator, and functions according 936 to the MKI definition in Section 3. 937 938 SRTCP uses the cryptographic context parameters and packet processing 939 of SRTP by default, with the following changes: 940 941 * The receiver does not need to "estimate" the index, as it is 942 explicitly signaled in the packet. 943 944 * Pre-defined SRTCP encryption is as specified in Section 4.1, but 945 using the definition of the SRTCP Encrypted Portion given in this 946 section, and using the SRTCP index as the index i. The encryption 947 transform and related parameters SHALL by default be the same 948 selected for the protection of the associated SRTP stream(s), 949 while the NULL algorithm SHALL be applied to the RTCP packets not 950 to be encrypted. SRTCP may have a different encryption transform 951 952 953 954Baugher, et al. Standards Track [Page 17] 955 956RFC 3711 SRTP March 2004 957 958 959 than the one used by the corresponding SRTP. The expected use for 960 this feature is when the former has NULL-encryption and the latter 961 has a non NULL-encryption. 962 963 The E-flag is assigned a value by the sender depending on whether the 964 packet was encrypted or not. 965 966 * SRTCP decryption is performed as in Section 4, but only if the E 967 flag is equal to 1. If so, the Encrypted Portion is decrypted, 968 using the SRTCP index as the index i. In case the E-flag is 0, 969 the payload is simply left unmodified. 970 971 * SRTCP replay protection is as defined in Section 3.3.2, but using 972 the SRTCP index as the index i and a separate Replay List that is 973 specific to SRTCP. 974 975 * The pre-defined SRTCP authentication tag is specified as in 976 Section 4.2, but with the Authenticated Portion of the SRTCP 977 packet given in this section (which includes the index). The 978 authentication transform and related parameters (e.g., key size) 979 SHALL by default be the same as selected for the protection of the 980 associated SRTP stream(s). 981 982 * In the last step of the processing, only the sender needs to 983 update the value of the SRTCP index by incrementing it modulo 2^31 984 and for security reasons the sender MUST also check the number of 985 SRTCP packets processed, see Section 9.2. 986 987 Message authentication for RTCP is REQUIRED, as it is the control 988 protocol (e.g., it has a BYE packet) for RTP. 989 990 Precautions must be taken so that the packet expansion in SRTCP (due 991 to the added fields) does not cause SRTCP messages to use more than 992 their share of RTCP bandwidth. To avoid this, the following two 993 measures MUST be taken: 994 995 1. When initializing the RTCP variable "avg_rtcp_size" defined in 996 chapter 6.3 of [RFC3550], it MUST include the size of the fields 997 that will be added by SRTCP (index, E-bit, authentication tag, and 998 when present, the MKI). 999 1000 2. When updating the "avg_rtcp_size" using the variable "packet_size" 1001 (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST 1002 include the size of the additional fields added by SRTCP. 1003 1004 1005 1006 1007 1008 1009 1010Baugher, et al. Standards Track [Page 18] 1011 1012RFC 3711 SRTP March 2004 1013 1014 1015 With these measures in place the SRTCP messages will not use more 1016 than the allotted bandwidth. The effect of the size of the added 1017 fields on the SRTCP traffic will be that messages will be sent with 1018 longer packet intervals. The increase in the intervals will be 1019 directly proportional to size of the added fields. For the pre- 1020 defined transforms, the size of the added fields will be at least 14 1021 octets, and upper bounded depending on MKI and the authentication tag 1022 sizes. 1023 10244. Pre-Defined Cryptographic Transforms 1025 1026 While there are numerous encryption and message authentication 1027 algorithms that can be used in SRTP, below we define default 1028 algorithms in order to avoid the complexity of specifying the 1029 encodings for the signaling of algorithm and parameter identifiers. 1030 The defined algorithms have been chosen as they fulfill the goals 1031 listed in Section 2. Recommendations on how to extend SRTP with new 1032 transforms are given in Section 6. 1033 10344.1. Encryption 1035 1036 The following parameters are common to both pre-defined, non-NULL, 1037 encryption transforms specified in this section. 1038 1039 * BLOCK_CIPHER-MODE indicates the block cipher used and its mode of 1040 operation 1041 * n_b is the bit-size of the block for the block cipher 1042 * k_e is the session encryption key 1043 * n_e is the bit-length of k_e 1044 * k_s is the session salting key 1045 * n_s is the bit-length of k_s 1046 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a 1047 non-negative integer, specified by the message authentication code 1048 in use. 1049 1050 The distinct session keys and salts for SRTP/SRTCP are by default 1051 derived as specified in Section 4.3. 1052 1053 The encryption transforms defined in SRTP map the SRTP packet index 1054 and secret key into a pseudo-random keystream segment. Each 1055 keystream segment encrypts a single RTP packet. The process of 1056 encrypting a packet consists of generating the keystream segment 1057 corresponding to the packet, and then bitwise exclusive-oring that 1058 keystream segment onto the payload of the RTP packet to produce the 1059 Encrypted Portion of the SRTP packet. In case the payload size is 1060 not an integer multiple of n_b bits, the excess (least significant) 1061 bits of the keystream are simply discarded. Decryption is done the 1062 same way, but swapping the roles of the plaintext and ciphertext. 1063 1064 1065 1066Baugher, et al. Standards Track [Page 19] 1067 1068RFC 3711 SRTP March 2004 1069 1070 1071 +----+ +------------------+---------------------------------+ 1072 | KG |-->| Keystream Prefix | Keystream Suffix |---+ 1073 +----+ +------------------+---------------------------------+ | 1074 | 1075 +---------------------------------+ v 1076 | Payload of RTP Packet |->(*) 1077 +---------------------------------+ | 1078 | 1079 +---------------------------------+ | 1080 | Encrypted Portion of SRTP Packet|<--+ 1081 +---------------------------------+ 1082 1083 Figure 3: Default SRTP Encryption Processing. Here KG denotes the 1084 keystream generator, and (*) denotes bitwise exclusive-or. 1085 1086 The definition of how the keystream is generated, given the index, 1087 depends on the cipher and its mode of operation. Below, two such 1088 keystream generators are defined. The NULL cipher is also defined, 1089 to be used when encryption of RTP is not required. 1090 1091 The SRTP definition of the keystream is illustrated in Figure 3. The 1092 initial octets of each keystream segment MAY be reserved for use in a 1093 message authentication code, in which case the keystream used for 1094 encryption starts immediately after the last reserved octet. The 1095 initial reserved octets are called the "keystream prefix" (not to be 1096 confused with the "encryption prefix" of [RFC3550, Section 6.1]), and 1097 the remaining octets are called the "keystream suffix". The 1098 keystream prefix MUST NOT be used for encryption. The process is 1099 illustrated in Figure 3. 1100 1101 The number of octets in the keystream prefix is denoted as 1102 SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, 1103 non-zero value of SRTP_PREFIX_LENGTH. This means that, even if 1104 confidentiality is not to be provided, the keystream generator output 1105 may still need to be computed for packet authentication, in which 1106 case the default keystream generator (mode) SHALL be used. 1107 1108 The default cipher is the Advanced Encryption Standard (AES) [AES], 1109 and we define two modes of running AES, (1) Segmented Integer Counter 1110 Mode AES and (2) AES in f8-mode. In the remainder of this section, 1111 let E(k,x) be AES applied to key k and input block x. 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122Baugher, et al. Standards Track [Page 20] 1123 1124RFC 3711 SRTP March 2004 1125 1126 11274.1.1. AES in Counter Mode 1128 1129 Conceptually, counter mode [AES-CTR] consists of encrypting 1130 successive integers. The actual definition is somewhat more 1131 complicated, in order to randomize the starting point of the integer 1132 sequence. Each packet is encrypted with a distinct keystream 1133 segment, which SHALL be computed as follows. 1134 1135 A keystream segment SHALL be the concatenation of the 128-bit output 1136 blocks of the AES cipher in the encrypt direction, using key k = k_e, 1137 in which the block indices are in increasing order. Symbolically, 1138 each keystream segment looks like 1139 1140 E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ... 1141 1142 where the 128-bit integer value IV SHALL be defined by the SSRC, the 1143 SRTP packet index i, and the SRTP session salting key k_s, as below. 1144 1145 IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16) 1146 1147 Each of the three terms in the XOR-sum above is padded with as many 1148 leading zeros as needed to make the operation well-defined, 1149 considered as a 128-bit value. 1150 1151 The inclusion of the SSRC allows the use of the same key to protect 1152 distinct SRTP streams within the same RTP session, see the security 1153 caveats in Section 9.1. 1154 1155 In the case of SRTCP, the SSRC of the first header of the compound 1156 packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s 1157 SHALL be replaced by the SRTCP encryption session key and salt. 1158 1159 Note that the initial value, IV, is fixed for each packet and is 1160 formed by "reserving" 16 zeros in the least significant bits for the 1161 purpose of the counter. The number of blocks of keystream generated 1162 for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream 1163 re-use, see below. The AES has a block size of 128 bits, so 2^16 1164 output blocks are sufficient to generate the 2^23 bits of keystream 1165 needed to encrypt the largest possible RTP packet (except for IPv6 1166 "jumbograms" [RFC2675], which are not likely to be used for RTP-based 1167 multimedia traffic). This restriction on the maximum bit-size of the 1168 packet that can be encrypted ensures the security of the encryption 1169 method by limiting the effectiveness of probabilistic attacks [BDJR]. 1170 1171 For a particular Counter Mode key, each IV value used as an input 1172 MUST be distinct, in order to avoid the security exposure of a two- 1173 time pad situation (Section 9.1). To satisfy this constraint, an 1174 implementation MUST ensure that the combination of the SRTP packet 1175 1176 1177 1178Baugher, et al. Standards Track [Page 21] 1179 1180RFC 3711 SRTP March 2004 1181 1182 1183 index of ROC || SEQ, and the SSRC used in the construction of the IV 1184 are distinct for any particular key. The failure to ensure this 1185 uniqueness could be catastrophic for Secure RTP. This is in contrast 1186 to the situation for RTP itself, which may be able to tolerate such 1187 failures. It is RECOMMENDED that, if a dedicated security module is 1188 present, the RTP sequence numbers and SSRC either be generated or 1189 checked by that module (i.e., sequence-number and SSRC processing in 1190 an SRTP system needs to be protected as well as the key). 1191 11924.1.2. AES in f8-mode 1193 1194 To encrypt UMTS (Universal Mobile Telecommunications System, as 3G 1195 networks) data, a solution (see [f8-a] [f8-b]) known as the f8- 1196 algorithm has been developed. On a high level, the proposed scheme 1197 is a variant of Output Feedback Mode (OFB) [HAC], with a more 1198 elaborate initialization and feedback function. As in normal OFB, 1199 the core consists of a block cipher. We also define here the use of 1200 AES as a block cipher to be used in what we shall call "f8-mode of 1201 operation" RTP encryption. The AES f8-mode SHALL use the same 1202 default sizes for session key and salt as AES counter mode. 1203 1204 Figure 4 shows the structure of block cipher, E, running in f8-mode. 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234Baugher, et al. Standards Track [Page 22] 1235 1236RFC 3711 SRTP March 2004 1237 1238 1239 IV 1240 | 1241 v 1242 +------+ 1243 | | 1244 +--->| E | 1245 | +------+ 1246 | | 1247 m -> (*) +-----------+-------------+-- ... ------+ 1248 | IV' | | | | 1249 | | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*) 1250 | | | | | 1251 | | +-> (*) +-> (*) ... +-> (*) 1252 | | | | | | | | 1253 | v | v | v | v 1254 | +------+ | +------+ | +------+ | +------+ 1255 k_e ---+--->| E | | | E | | | E | | | E | 1256 | | | | | | | | | | | 1257 +------+ | +------+ | +------+ | +------+ 1258 | | | | | | | 1259 +------+ +--------+ +-- ... ----+ | 1260 | | | | 1261 v v v v 1262 S(0) S(1) S(2) . . . S(L-1) 1263 1264 Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). 1265 The figure represents the KG in Figure 3, when AES-f8 is used. 1266 12674.1.2.1. f8 Keystream Generation 1268 1269 The Initialization Vector (IV) SHALL be determined as described in 1270 Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP). 1271 1272 Let IV', S(j), and m denote n_b-bit blocks. The keystream, 1273 S(0) ||... || S(L-1), for an N-bit message SHALL be defined by 1274 setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0. For 1275 j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it 1276 is not already an integer) compute 1277 1278 S(j) = E(k_e, IV' XOR j XOR S(j-1)) 1279 1280 Notice that the IV is not used directly. Instead it is fed through E 1281 under another key to produce an internal, "masked" value (denoted 1282 IV') to prevent an attacker from gaining known input/output pairs. 1283 1284 1285 1286 1287 1288 1289 1290Baugher, et al. Standards Track [Page 23] 1291 1292RFC 3711 SRTP March 2004 1293 1294 1295 The role of the internal counter, j, is to prevent short keystream 1296 cycles. The value of the key mask m SHALL be 1297 1298 m = k_s || 0x555..5, 1299 1300 i.e., the session salting key, appended by the binary pattern 0101.. 1301 to fill out the entire desired key size, n_e. 1302 1303 The sender SHOULD NOT generate more than 2^32 blocks, which is 1304 sufficient to generate 2^39 bits of keystream. Unlike counter mode, 1305 there is no absolute threshold above (below) which f8 is guaranteed 1306 to be insecure (secure). The above bound has been chosen to limit, 1307 with sufficient security margin, the probability of degenerative 1308 behavior in the f8 keystream generation. 1309 13104.1.2.2. f8 SRTP IV Formation 1311 1312 The purpose of the following IV formation is to provide a feature 1313 which we call implicit header authentication (IHA), see Section 9.5. 1314 1315 The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following 1316 way: 1317 1318 IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC 1319 1320 M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from 1321 the cryptographic context. 1322 1323 The presence of the SSRC as part of the IV allows AES-f8 to be used 1324 when a master key is shared between multiple streams within the same 1325 RTP session, see Section 9.1. 1326 13274.1.2.3. f8 SRTCP IV Formation 1328 1329 The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the 1330 following way: 1331 1332 IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC 1333 1334 where V, P, RC, PT, length, SSRC SHALL be taken from the first header 1335 in the RTCP compound packet. E and SRTCP index are the 1-bit and 1336 31-bit fields added to the packet. 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346Baugher, et al. Standards Track [Page 24] 1347 1348RFC 3711 SRTP March 2004 1349 1350 13514.1.3. NULL Cipher 1352 1353 The NULL cipher is used when no confidentiality for RTP/RTCP is 1354 requested. The keystream can be thought of as "000..0", i.e., the 1355 encryption SHALL simply copy the plaintext input into the ciphertext 1356 output. 1357 13584.2. Message Authentication and Integrity 1359 1360 Throughout this section, M will denote data to be integrity 1361 protected. In the case of SRTP, M SHALL consist of the Authenticated 1362 Portion of the packet (as specified in Figure 1) concatenated with 1363 the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M 1364 SHALL consist of the Authenticated Portion (as specified in Figure 2) 1365 only. 1366 1367 Common parameters: 1368 1369 * AUTH_ALG is the authentication algorithm 1370 * k_a is the session message authentication key 1371 * n_a is the bit-length of the authentication key 1372 * n_tag is the bit-length of the output authentication tag 1373 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as 1374 defined above, a parameter of AUTH_ALG 1375 1376 The distinct session authentication keys for SRTP/SRTCP are by 1377 default derived as specified in Section 4.3. 1378 1379 The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for 1380 any particular fixed value of the key. 1381 1382 We describe the process of computing authentication tags as follows. 1383 The sender computes the tag of M and appends it to the packet. The 1384 SRTP receiver verifies a message/authentication tag pair by computing 1385 a new authentication tag over M using the selected algorithm and key, 1386 and then compares it to the tag associated with the received message. 1387 If the two tags are equal, then the message/tag pair is valid; 1388 otherwise, it is invalid and the error audit message "AUTHENTICATION 1389 FAILURE" MUST be returned. 1390 13914.2.1. HMAC-SHA1 1392 1393 The pre-defined authentication transform for SRTP is HMAC-SHA1 1394 [RFC2104]. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL 1395 be 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to 1396 the session authentication key and M as specified above, i.e., 1397 HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag 1398 left-most bits. 1399 1400 1401 1402Baugher, et al. Standards Track [Page 25] 1403 1404RFC 3711 SRTP March 2004 1405 1406 14074.3. Key Derivation 1408 14094.3.1. Key Derivation Algorithm 1410 1411 Regardless of the encryption or message authentication transform that 1412 is employed (it may be an SRTP pre-defined transform or newly 1413 introduced according to Section 6), interoperable SRTP 1414 implementations MUST use the SRTP key derivation to generate session 1415 keys. Once the key derivation rate is properly signaled at the start 1416 of the session, there is no need for extra communication between the 1417 parties that use SRTP key derivation. 1418 1419 packet index ---+ 1420 | 1421 v 1422 +-----------+ master +--------+ session encr_key 1423 | ext | key | |----------> 1424 | key mgmt |-------->| key | session auth_key 1425 | (optional | | deriv |----------> 1426 | rekey) |-------->| | session salt_key 1427 | | master | |----------> 1428 +-----------+ salt +--------+ 1429 1430 Figure 5: SRTP key derivation. 1431 1432 At least one initial key derivation SHALL be performed by SRTP, i.e., 1433 the first key derivation is REQUIRED. Further applications of the 1434 key derivation MAY be performed, according to the 1435 "key_derivation_rate" value in the cryptographic context. The key 1436 derivation function SHALL initially be invoked before the first 1437 packet and then, when r > 0, a key derivation is performed whenever 1438 index mod r equals zero. This can be thought of as "refreshing" the 1439 session keys. The value of "key_derivation_rate" MUST be kept fixed 1440 for the lifetime of the associated master key. 1441 1442 Interoperable SRTP implementations MAY also derive session salting 1443 keys for encryption transforms, as is done in both of the pre- 1444 defined transforms. 1445 1446 Let m and n be positive integers. A pseudo-random function family is 1447 a set of keyed functions {PRF_n(k,x)} such that for the (secret) 1448 random key k, given m-bit x, PRF_n(k,x) is an n-bit string, 1449 computationally indistinguishable from random n-bit strings, see 1450 [HAC]. For the purpose of key derivation in SRTP, a secure PRF with 1451 m = 128 (or more) MUST be used, and a default PRF transform is 1452 defined in Section 4.3.3. 1453 1454 1455 1456 1457 1458Baugher, et al. Standards Track [Page 26] 1459 1460RFC 3711 SRTP March 2004 1461 1462 1463 Let "a DIV t" denote integer division of a by t, rounded down, and 1464 with the convention that "a DIV 0 = 0" for all a. We also make the 1465 convention of treating "a DIV t" as a bit string of the same length 1466 as a, and thus "a DIV t" will in general have leading zeros. 1467 1468 Key derivation SHALL be defined as follows in terms of <label>, an 1469 8-bit constant (see below), master_salt and key_derivation_rate, as 1470 determined in the cryptographic context, and index, the packet index 1471 (i.e., the 48-bit ROC || SEQ for SRTP): 1472 1473 * Let r = index DIV key_derivation_rate (with DIV as defined above). 1474 1475 * Let key_id = <label> || r. 1476 1477 * Let x = key_id XOR master_salt, where key_id and master_salt are 1478 aligned so that their least significant bits agree (right- 1479 alignment). 1480 1481 <label> MUST be unique for each type of key to be derived. We 1482 currently define <label> 0x00 to 0x05 (see below), and future 1483 extensions MAY specify new values in the range 0x06 to 0xff for other 1484 purposes. The n-bit SRTP key (or salt) for this packet SHALL then be 1485 derived from the master key, k_master as follows: 1486 1487 PRF_n(k_master, x). 1488 1489 (The PRF may internally specify additional formatting and padding of 1490 x, see e.g., Section 4.3.3 for the default PRF.) 1491 1492 The session keys and salt SHALL now be derived using: 1493 1494 - k_e (SRTP encryption): <label> = 0x00, n = n_e. 1495 1496 - k_a (SRTP message authentication): <label> = 0x01, n = n_a. 1497 1498 - k_s (SRTP salting key): <label> = 0x02, n = n_s. 1499 1500 where n_e, n_s, and n_a are from the cryptographic context. 1501 1502 The master key and master salt MUST be random, but the master salt 1503 MAY be public. 1504 1505 Note that for a key_derivation_rate of 0, the application of the key 1506 derivation SHALL take place exactly once. 1507 1508 The definition of DIV above is purely for notational convenience. 1509 For a non-zero t among the set of allowed key derivation rates, "a 1510 DIV t" can be implemented as a right-shift by the base-2 logarithm of 1511 1512 1513 1514Baugher, et al. Standards Track [Page 27] 1515 1516RFC 3711 SRTP March 2004 1517 1518 1519 t. The derivation operation is further facilitated if the rates are 1520 chosen to be powers of 256, but that granularity was considered too 1521 coarse to be a requirement of this specification. 1522 1523 The upper limit on the number of packets that can be secured using 1524 the same master key (see Section 9.2) is independent of the key 1525 derivation. 1526 15274.3.2. SRTCP Key Derivation 1528 1529 SRTCP SHALL by default use the same master key (and master salt) as 1530 SRTP. To do this securely, the following changes SHALL be done to 1531 the definitions in Section 4.3.1 when applying session key derivation 1532 for SRTCP. 1533 1534 Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index 1535 (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use 1536 <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the 1537 SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting 1538 key. 1539 15404.3.3. AES-CM PRF 1541 1542 The currently defined PRF, keyed by 128, 192, or 256 bit master key, 1543 has input block size m = 128 and can produce n-bit outputs for n up 1544 to 2^23. PRF_n(k_master,x) SHALL be AES in Counter Mode as described 1545 in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16), 1546 and with the output keystream truncated to the n first (left-most) 1547 bits. (Requiring n/128, rounded up, applications of AES.) 1548 15495. Default and mandatory-to-implement Transforms 1550 1551 The default transforms also are mandatory-to-implement transforms in 1552 SRTP. Of course, "mandatory-to-implement" does not imply 1553 "mandatory-to-use". Table 1 summarizes the pre-defined transforms. 1554 The default values below are valid for the pre-defined transforms. 1555 1556 mandatory-to-impl. optional default 1557 1558 encryption AES-CM, NULL AES-f8 AES-CM 1559 message integrity HMAC-SHA1 - HMAC-SHA1 1560 key derivation (PRF) AES-CM - AES-CM 1561 1562 Table 1: Mandatory-to-implement, optional and default transforms in 1563 SRTP and SRTCP. 1564 1565 1566 1567 1568 1569 1570Baugher, et al. Standards Track [Page 28] 1571 1572RFC 3711 SRTP March 2004 1573 1574 15755.1. Encryption: AES-CM and NULL 1576 1577 AES running in Segmented Integer Counter Mode, as defined in Section 1578 4.1.1, SHALL be the default encryption algorithm. The default key 1579 lengths SHALL be 128-bit for the session encryption key (n_e). The 1580 default session salt key-length (n_s) SHALL be 112 bits. 1581 1582 The NULL cipher SHALL also be mandatory-to-implement. 1583 15845.2. Message Authentication/Integrity: HMAC-SHA1 1585 1586 HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message 1587 authentication code. The default session authentication key-length 1588 (n_a) SHALL be 160 bits, the default authentication tag length 1589 (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero 1590 for HMAC-SHA1. In addition, for SRTCP, the pre-defined HMAC-SHA1 1591 MUST NOT be applied with a value of n_tag, nor n_a, that are smaller 1592 than these defaults. For SRTP, smaller values are NOT RECOMMENDED, 1593 but MAY be used after careful consideration of the issues in Section 1594 7.5 and 9.5. 1595 15965.3. Key Derivation: AES-CM PRF 1597 1598 The AES Counter Mode based key derivation and PRF defined in Sections 1599 4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default 1600 method for generating session keys. The default master salt length 1601 SHALL be 112 bits and the default key-derivation rate SHALL be zero. 1602 16036. Adding SRTP Transforms 1604 1605 Section 4 provides examples of the level of detail needed for 1606 defining transforms. Whenever a new transform is to be added to 1607 SRTP, a companion standard track RFC MUST be written to exactly 1608 define how the new transform can be used with SRTP (and SRTCP). Such 1609 a companion RFC SHOULD avoid overlap with the SRTP protocol document. 1610 Note however, that it MAY be necessary to extend the SRTP or SRTCP 1611 cryptographic context definition with new parameters (including fixed 1612 or default values), add steps to the packet processing, or even add 1613 fields to the SRTP/SRTCP packets. The companion RFC SHALL explain 1614 any known issues regarding interactions between the transform and 1615 other aspects of SRTP. 1616 1617 Each new transform document SHOULD specify its key attributes, e.g., 1618 size of keys (minimum, maximum, recommended), format of keys, 1619 recommended/required processing of input keying material, 1620 requirements/recommendations on key lifetime, re-keying and key 1621 derivation, whether sharing of keys between SRTP and SRTCP is allowed 1622 or not, etc. 1623 1624 1625 1626Baugher, et al. Standards Track [Page 29] 1627 1628RFC 3711 SRTP March 2004 1629 1630 1631 An added message integrity transform SHOULD define a minimum 1632 acceptable key/tag size for SRTCP, equivalent in strength to the 1633 minimum values as defined in Section 5.2. 1634 16357. Rationale 1636 1637 This section explains the rationale behind several important features 1638 of SRTP. 1639 16407.1. Key derivation 1641 1642 Key derivation reduces the burden on the key establishment. As many 1643 as six different keys are needed per crypto context (SRTP and SRTCP 1644 encryption keys and salts, SRTP and SRTCP authentication keys), but 1645 these are derived from a single master key in a cryptographically 1646 secure way. Thus, the key management protocol needs to exchange only 1647 one master key (plus master salt when required), and then SRTP itself 1648 derives all the necessary session keys (via the first, mandatory 1649 application of the key derivation function). 1650 1651 Multiple applications of the key derivation function are optional, 1652 but will give security benefits when enabled. They prevent an 1653 attacker from obtaining large amounts of ciphertext produced by a 1654 single fixed session key. If the attacker was able to collect a 1655 large amount of ciphertext for a certain session key, he might be 1656 helped in mounting certain attacks. 1657 1658 Multiple applications of the key derivation function provide 1659 backwards and forward security in the sense that a compromised 1660 session key does not compromise other session keys derived from the 1661 same master key. This means that the attacker who is able to recover 1662 a certain session key, is anyway not able to have access to messages 1663 secured under previous and later session keys (derived from the same 1664 master key). (Note that, of course, a leaked master key reveals all 1665 the session keys derived from it.) 1666 1667 Considerations arise with high-rate key refresh, especially in large 1668 multicast settings, see Section 11. 1669 16707.2. Salting key 1671 1672 The master salt guarantees security against off-line key-collision 1673 attacks on the key derivation that might otherwise reduce the 1674 effective key size [MF00]. 1675 1676 1677 1678 1679 1680 1681 1682Baugher, et al. Standards Track [Page 30] 1683 1684RFC 3711 SRTP March 2004 1685 1686 1687 The derived session salting key used in the encryption, has been 1688 introduced to protect against some attacks on additive stream 1689 ciphers, see Section 9.2. The explicit inclusion method of the salt 1690 in the IV has been selected for ease of hardware implementation. 1691 16927.3. Message Integrity from Universal Hashing 1693 1694 The particular definition of the keystream given in Section 4.1 (the 1695 keystream prefix) is to give provision for particular universal hash 1696 functions, suitable for message authentication in the Wegman-Carter 1697 paradigm [WC81]. Such functions are provably secure, simple, quick, 1698 and especially appropriate for Digital Signal Processors and other 1699 processors with a fast multiply operation. 1700 1701 No authentication transforms are currently provided in SRTP other 1702 than HMAC-SHA1. Future transforms, like the above mentioned 1703 universal hash functions, MAY be added following the guidelines in 1704 Section 6. 1705 17067.4. Data Origin Authentication Considerations 1707 1708 Note that in pair-wise communications, integrity and data origin 1709 authentication are provided together. However, in group scenarios 1710 where the keys are shared between members, the MAC tag only proves 1711 that a member of the group sent the packet, but does not prevent 1712 against a member impersonating another. Data origin authentication 1713 (DOA) for multicast and group RTP sessions is a hard problem that 1714 needs a solution; while some promising proposals are being 1715 investigated [PCST1] [PCST2], more work is needed to rigorously 1716 specify these technologies. Thus SRTP data origin authentication in 1717 groups is for further study. 1718 1719 DOA can be done otherwise using signatures. However, this has high 1720 impact in terms of bandwidth and processing time, therefore we do not 1721 offer this form of authentication in the pre-defined packet-integrity 1722 transform. 1723 1724 The presence of mixers and translators does not allow data origin 1725 authentication in case the RTP payload and/or the RTP header are 1726 manipulated. Note that these types of middle entities also disrupt 1727 end-to-end confidentiality (as the IV formation depends e.g., on the 1728 RTP header preservation). A certain trust model may choose to trust 1729 the mixers/translators to decrypt/re-encrypt the media (this would 1730 imply breaking the end-to-end security, with related security 1731 implications). 1732 1733 1734 1735 1736 1737 1738Baugher, et al. Standards Track [Page 31] 1739 1740RFC 3711 SRTP March 2004 1741 1742 17437.5. Short and Zero-length Message Authentication 1744 1745 As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP. 1746 A full 80-bit authentication-tag SHOULD be used, but a shorter tag or 1747 even a zero-length tag (i.e., no message authentication) MAY be used 1748 under certain conditions to support either of the following two 1749 application environments. 1750 1751 1. Strong authentication can be impractical in environments where 1752 bandwidth preservation is imperative. An important special 1753 case is wireless communication systems, in which bandwidth is a 1754 scarce and expensive resource. Studies have shown that for 1755 certain applications and link technologies, additional bytes 1756 may result in a significant decrease in spectrum efficiency 1757 [SWO]. Considerable effort has been made to design IP header 1758 compression techniques to improve spectrum efficiency 1759 [RFC3095]. A typical voice application produces 20 byte 1760 samples, and the RTP, UDP and IP headers need to be jointly 1761 compressed to one or two bytes on average in order to obtain 1762 acceptable wireless bandwidth economy [RFC3095]. In this case, 1763 strong authentication would impose nearly fifty percent 1764 overhead. 1765 1766 2. Authentication is impractical for applications that use data 1767 links with fixed-width fields that cannot accommodate the 1768 expansion due to the authentication tag. This is the case for 1769 some important existing wireless channels. For example, zero- 1770 byte header compression is used to adapt EVRC/SMV voice with 1771 the legacy IS-95 bearer channel in CDMA2000 VoIP services. It 1772 was found that not a single additional octet could be added to 1773 the data, which motivated the creation of a zero-byte profile 1774 for ROHC [RFC3242]. 1775 1776 A short tag is secure for a restricted set of applications. Consider 1777 a voice telephony application, for example, such as a G.729 audio 1778 codec with a 20-millisecond packetization interval, protected by a 1779 32-bit message authentication tag. The likelihood of any given 1780 packet being successfully forged is only one in 2^32. Thus an 1781 adversary can control no more than 20 milliseconds of audio output 1782 during a 994-day period, on average. In contrast, the effect of a 1783 single forged packet can be much larger if the application is 1784 stateful. A codec that uses relative or predictive compression 1785 across packets will propagate the maliciously generated state, 1786 affecting a longer duration of output. 1787 1788 1789 1790 1791 1792 1793 1794Baugher, et al. Standards Track [Page 32] 1795 1796RFC 3711 SRTP March 2004 1797 1798 1799 Certainly not all SRTP or telephony applications meet the criteria 1800 for short or zero-length authentication tags. Section 9.5.1 1801 discusses the risks of weak or no message authentication, and section 1802 9.5 describes the circumstances when it is acceptable and when it is 1803 unacceptable. 1804 18058. Key Management Considerations 1806 1807 There are emerging key management standards [MIKEY] [KEYMGT] [SDMS] 1808 for establishing an SRTP cryptographic context (e.g., an SRTP master 1809 key). Both proprietary and open-standard key management methods are 1810 likely to be used for telephony applications [MIKEY] [KINK] and 1811 multicast applications [GDOI]. This section provides guidance for 1812 key management systems that service SRTP session. 1813 1814 For initialization, an interoperable SRTP implementation SHOULD be 1815 given the SSRC and MAY be given the initial RTP sequence number for 1816 the RTP stream by key management (thus, key management has a 1817 dependency on RTP operational parameters). Sending the RTP sequence 1818 number in the key management may be useful e.g., when the initial 1819 sequence number is close to wrapping (to avoid synchronization 1820 problems), and to communicate the current sequence number to a 1821 joining endpoint (to properly initialize its replay list). 1822 1823 If the pre-defined transforms are used, SRTP allows sharing of the 1824 same master key between SRTP/SRTCP streams belonging to the same RTP 1825 session. 1826 1827 First, sharing between SRTP streams belonging to the same RTP session 1828 is secure if the design of the synchronization mechanism, i.e., the 1829 IV, avoids keystream re-use (the two-time pad, Section 9.1). This is 1830 taken care of by the fact that RTP provides for unique SSRCs for 1831 streams belonging to the same RTP session. See Section 9.1 for 1832 further discussion. 1833 1834 Second, sharing between SRTP and the corresponding SRTCP is secure. 1835 The fact that an SRTP stream and its associated SRTCP stream both 1836 carry the same SSRC does not constitute a problem for the two-time 1837 pad due to the key derivation. Thus, SRTP and SRTCP corresponding to 1838 one RTP session MAY share master keys (as they do by default). 1839 1840 Note that message authentication also has a dependency on SSRC 1841 uniqueness that is unrelated to the problem of keystream reuse: SRTP 1842 streams authenticated under the same key MUST have a distinct SSRC in 1843 order to identify the sender of the message. This requirement is 1844 needed because the SSRC is the cryptographically authenticated field 1845 1846 1847 1848 1849 1850Baugher, et al. Standards Track [Page 33] 1851 1852RFC 3711 SRTP March 2004 1853 1854 1855 used to distinguish between different SRTP streams. Were two streams 1856 to use identical SSRC values, then an adversary could substitute 1857 messages from one stream into the other without detection. 1858 1859 SRTP/SRTCP MUST NOT share master keys under any other circumstances 1860 than the ones given above, i.e., between SRTP and its corresponding 1861 SRTCP, and, between streams belonging to the same RTP session. 1862 18638.1. Re-keying 1864 1865 The recommended way for a particular key management system to provide 1866 re-key within SRTP is by associating a master key in a crypto context 1867 with an MKI. 1868 1869 This provides for easy master key retrieval (see Scenarios in Section 1870 11), but has the disadvantage of adding extra bits to each packet. 1871 As noted in Section 7.5, some wireless links do not cater for added 1872 bits, therefore SRTP also defines a more economic way of triggering 1873 re-keying, via use of <From, To>, which works in some specific, 1874 simple scenarios (see Section 8.1.1). 1875 1876 SRTP senders SHALL count the amount of SRTP and SRTCP traffic being 1877 used for a master key and invoke key management to re-key if needed 1878 (Section 9.2). These interactions are defined by the key management 1879 interface to SRTP and are not defined by this protocol specification. 1880 18818.1.1. Use of the <From, To> for re-keying 1882 1883 In addition to the use of the MKI, SRTP defines another optional 1884 mechanism for master key retrieval, the <From, To>. The <From, To> 1885 specifies the range of SRTP indices (a pair of sequence number and 1886 ROC) within which a certain master key is valid, and is (when used) 1887 part of the crypto context. By looking at the 48-bit SRTP index of 1888 the current SRTP packet, the corresponding master key can be found by 1889 determining which From-To interval it belongs to. For SRTCP, the 1890 most recently observed/used SRTP index (which can be obtained from 1891 the cryptographic context) is used for this purpose, even though 1892 SRTCP has its own (31-bit) index (see caveat below). 1893 1894 This method, compared to the MKI, has the advantage of identifying 1895 the master key and defining its lifetime without adding extra bits to 1896 each packet. This could be useful, as already noted, for some 1897 wireless links that do not cater for added bits. However, its use 1898 SHOULD be limited to specific, very simple scenarios. We recommend 1899 to limit its use when the RTP session is a simple unidirectional or 1900 bi-directional stream. This is because in case of multiple streams, 1901 it is difficult to trigger the re-key based on the <From, To> of a 1902 single RTP stream. For example, if several streams share a master 1903 1904 1905 1906Baugher, et al. Standards Track [Page 34] 1907 1908RFC 3711 SRTP March 2004 1909 1910 1911 key, there is no simple one-to-one correspondence between the index 1912 sequence space of a certain stream, and the index sequence space on 1913 which the <From, To> values are based. Consequently, when a master 1914 key is shared between streams, one of these streams MUST be 1915 designated by key management as the one whose index space defines the 1916 re-keying points. Also, the re-key triggering on SRTCP is based on 1917 the correspondent SRTP stream, i.e., when the SRTP stream changes the 1918 master key, so does the correspondent SRTCP. This becomes obviously 1919 more and more complex with multiple streams. 1920 1921 The default values for the <From, To> are "from the first observed 1922 packet" and "until further notice". However, the maximum limit of 1923 SRTP/SRTCP packets that are sent under each given master/session key 1924 (Section 9.2) MUST NOT be exceeded. 1925 1926 In case the <From, To> is used as key retrieval, then the MKI is not 1927 inserted in the packet (and its indicator in the crypto context is 1928 zero). However, using the MKI does not exclude using <From, To> key 1929 lifetime simultaneously. This can for instance be useful to signal 1930 at the sender side at which point in time an MKI is to be made 1931 active. 1932 19338.2. Key Management parameters 1934 1935 The table below lists all SRTP parameters that key management can 1936 supply. For reference, it also provides a summary of the default and 1937 mandatory-to-support values for an SRTP implementation as described 1938 in Section 5. 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962Baugher, et al. Standards Track [Page 35] 1963 1964RFC 3711 SRTP March 2004 1965 1966 1967 Parameter Mandatory-to-support Default 1968 --------- -------------------- ------- 1969 1970 SRTP and SRTCP encr transf. AES_CM, NULL AES_CM 1971 (Other possible values: AES_f8) 1972 1973 SRTP and SRTCP auth transf. HMAC-SHA1 HMAC-SHA1 1974 1975 SRTP and SRTCP auth params: 1976 n_tag (tag length) 80 80 1977 SRTP prefix_length 0 0 1978 1979 Key derivation PRF AES_CM AES_CM 1980 1981 Key material params 1982 (for each master key): 1983 master key length 128 128 1984 n_e (encr session key length) 128 128 1985 n_a (auth session key length) 160 160 1986 master salt key 1987 length of the master salt 112 112 1988 n_s (session salt key length) 112 112 1989 key derivation rate 0 0 1990 1991 key lifetime 1992 SRTP-packets-max-lifetime 2^48 2^48 1993 SRTCP-packets-max-lifetime 2^31 2^31 1994 from-to-lifetime <From, To> 1995 MKI indicator 0 0 1996 length of the MKI 0 0 1997 value of the MKI 1998 1999 Crypto context index params: 2000 SSRC value 2001 ROC 2002 SEQ 2003 SRTCP Index 2004 Transport address 2005 Port number 2006 2007 Relation to other RTP profiles: 2008 sender's order between FEC and SRTP FEC-SRTP FEC-SRTP 2009 (see Section 10) 2010 2011 2012 2013 2014 2015 2016 2017 2018Baugher, et al. Standards Track [Page 36] 2019 2020RFC 3711 SRTP March 2004 2021 2022 20239. Security Considerations 2024 20259.1. SSRC collision and two-time pad 2026 2027 Any fixed keystream output, generated from the same key and index 2028 MUST only be used to encrypt once. Re-using such keystream (jokingly 2029 called a "two-time pad" system by cryptographers), can seriously 2030 compromise security. The NSA's VENONA project [C99] provides a 2031 historical example of such a compromise. It is REQUIRED that 2032 automatic key management be used for establishing and maintaining 2033 SRTP and SRTCP keying material; this requirement is to avoid 2034 keystream reuse, which is more likely to occur with manual key 2035 management. Furthermore, in SRTP, a "two-time pad" is avoided by 2036 requiring the key, or some other parameter of cryptographic 2037 significance, to be unique per RTP/RTCP stream and packet. The pre- 2038 defined SRTP transforms accomplish packet-uniqueness by including the 2039 packet index and stream-uniqueness by inclusion of the SSRC. 2040 2041 The pre-defined transforms (AES-CM and AES-f8) allow master keys to 2042 be shared across streams belonging to the same RTP session by the 2043 inclusion of the SSRC in the IV. A master key MUST NOT be shared 2044 among different RTP sessions. 2045 2046 Thus, the SSRC MUST be unique between all the RTP streams within the 2047 same RTP session that share the same master key. RTP itself provides 2048 an algorithm for detecting SSRC collisions within the same RTP 2049 session. Thus, temporary collisions could lead to temporary two-time 2050 pad, in the unfortunate event that SSRCs collide at a point in time 2051 when the streams also have identical sequence numbers (occurring with 2052 probability roughly 2^(-48)). Therefore, the key management SHOULD 2053 take care of avoiding such SSRC collisions by including the SSRCs to 2054 be used in the session as negotiation parameters, proactively 2055 assuring their uniqueness. This is a strong requirements in 2056 scenarios where for example, there are multiple senders that can 2057 start to transmit simultaneously, before SSRC collision are detected 2058 at the RTP level. 2059 2060 Note also that even with distinct SSRCs, extensive use of the same 2061 key might improve chances of probabilistic collision and time- 2062 memory-tradeoff attacks succeeding. 2063 2064 As described, master keys MAY be shared between streams belonging to 2065 the same RTP session, but it is RECOMMENDED that each SSRC have its 2066 own master key. When master keys are shared among SSRC participants 2067 and SSRCs are managed by a key management module as recommended 2068 above, the RECOMMENDED policy for an SSRC collision error is for the 2069 participant to leave the SRTP session as it is a sign of malfunction. 2070 2071 2072 2073 2074Baugher, et al. Standards Track [Page 37] 2075 2076RFC 3711 SRTP March 2004 2077 2078 20799.2. Key Usage 2080 2081 The effective key size is determined (upper bounded) by the size of 2082 the master key and, for encryption, the size of the salting key. Any 2083 additive stream cipher is vulnerable to attacks that use statistical 2084 knowledge about the plaintext source to enable key collision and 2085 time-memory tradeoff attacks [MF00] [H80] [BS00]. These attacks take 2086 advantage of commonalities among plaintexts, and provide a way for a 2087 cryptanalyst to amortize the computational effort of decryption over 2088 many keys, or over many bytes of output, thus reducing the effective 2089 key size of the cipher. A detailed analysis of these attacks and 2090 their applicability to the encryption of Internet traffic is provided 2091 in [MF00]. In summary, the effective key size of SRTP when used in a 2092 security system in which m distinct keys are used, is equal to the 2093 key size of the cipher less the logarithm (base two) of m. 2094 Protection against such attacks can be provided simply by increasing 2095 the size of the keys used, which here can be accomplished by the use 2096 of the salting key. Note that the salting key MUST be random but MAY 2097 be public. A salt size of (the suggested) size 112 bits protects 2098 against attacks in scenarios where at most 2^112 keys are in use. 2099 This is sufficient for all practical purposes. 2100 2101 Implementations SHOULD use keys that are as large as possible. 2102 Please note that in many cases increasing the key size of a cipher 2103 does not affect the throughput of that cipher. 2104 2105 The use of the SRTP and SRTCP indices in the pre-defined transforms 2106 fixes the maximum number of packets that can be secured with the same 2107 key. This limit is fixed to 2^48 SRTP packets for an SRTP stream, 2108 and 2^31 SRTCP packets, when SRTP and SRTCP are considered 2109 independently. Due to for example re-keying, reaching this limit may 2110 or may not coincide with wrapping of the indices, and thus the sender 2111 MUST keep packet counts. However, when the session keys for related 2112 SRTP and SRTCP streams are derived from the same master key (the 2113 default behavior, Section 4.3), the upper bound that has to be 2114 considered is in practice the minimum of the two quantities. That 2115 is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured 2116 with the same key (whichever occurs before), the key management MUST 2117 be called to provide new master key(s) (previously stored and used 2118 keys MUST NOT be used again), or the session MUST be terminated. If 2119 a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not 2120 updated the master or session key prior to sending 2^48 SRTP (or 2^31 2121 SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to 2122 the security policy of the RTCP sender how to behave, e.g., whether 2123 an RTCP BYE-packet should be sent and/or if the event should be 2124 logged. 2125 2126 2127 2128 2129 2130Baugher, et al. Standards Track [Page 38] 2131 2132RFC 3711 SRTP March 2004 2133 2134 2135 Note: in most typical applications (assuming at least one RTCP packet 2136 for every 128,000 RTP packets), it will be the SRTCP index that first 2137 reaches the upper limit, although the time until this occurs is very 2138 long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is 2139 enough to secure approximately 4 months of communication. 2140 2141 Note that if the master key is to be shared between SRTP streams 2142 within the same RTP session (Section 9.1), although the above bounds 2143 are on a per stream (i.e., per SSRC) basis, the sender MUST base re- 2144 key decision on the stream whose sequence number space is the first 2145 to be exhausted. 2146 2147 Key derivation limits the amount of plaintext that is encrypted with 2148 a fixed session key, and made available to an attacker for analysis, 2149 but key derivation does not extend the master key's lifetime. To see 2150 this, simply consider our requirements to avoid two-time pad: two 2151 distinct packets MUST either be processed with distinct IVs, or with 2152 distinct session keys, and both the distinctness of IV and of the 2153 session keys are (for the pre-defined transforms) dependent on the 2154 distinctness of the packet indices. 2155 2156 Note that with the key derivation, the effective key size is at most 2157 that of the master key, even if the derived session key is 2158 considerably longer. With the pre-defined authentication transform, 2159 the session authentication key is 160 bits, but the master key by 2160 default is only 128 bits. This design choice was made to comply with 2161 certain recommendations in [RFC2104] so that an existing HMAC 2162 implementation can be plugged into SRTP without problems. Since the 2163 default tag size is 80 bits, it is, for the applications in mind, 2164 also considered acceptable from security point of view. Users having 2165 concerns about this are RECOMMENDED to instead use a 192 bit master 2166 key in the key derivation. It was, however, chosen not to mandate 2167 192-bit keys since existing AES implementations to be used in the 2168 key-derivation may not always support key-lengths other than 128 2169 bits. Since AES is not defined (or properly analyzed) for use with 2170 160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes 2171 are used to pad shorter keys to 192 or 256 bits. 2172 21739.3. Confidentiality of the RTP Payload 2174 2175 SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e., 2176 ciphers able to efficiently seek to arbitrary locations in their 2177 keystream (so that the encryption or decryption of one packet does 2178 not depend on preceding packets). By using seekable stream ciphers, 2179 SRTP avoids the denial of service attacks that are possible on stream 2180 ciphers that lack this property. It is important to be aware that, 2181 as with any stream cipher, the exact length of the payload is 2182 revealed by the encryption. This means that it may be possible to 2183 2184 2185 2186Baugher, et al. Standards Track [Page 39] 2187 2188RFC 3711 SRTP March 2004 2189 2190 2191 deduce certain "formatting bits" of the payload, as the length of the 2192 codec output might vary due to certain parameter settings etc. This, 2193 in turn, implies that the corresponding bit of the keystream can be 2194 deduced. However, if the stream cipher is secure (counter mode and 2195 f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]), 2196 knowledge of a few bits of the keystream will not aid an attacker in 2197 predicting subsequent keystream bits. Thus, the payload length (and 2198 information deducible from this) will leak, but nothing else. 2199 2200 As some RTP packet could contain highly predictable data, e.g., SID, 2201 it is important to use a cipher designed to resist known plaintext 2202 attacks (which is the current practice). 2203 22049.4. Confidentiality of the RTP Header 2205 2206 In SRTP, RTP headers are sent in the clear to allow for header 2207 compression. This means that data such as payload type, 2208 synchronization source identifier, and timestamp are available to an 2209 eavesdropper. Moreover, since RTP allows for future extensions of 2210 headers, we cannot foresee what kind of possibly sensitive 2211 information might also be "leaked". 2212 2213 SRTP is a low-cost method, which allows header compression to reduce 2214 bandwidth. It is up to the endpoints' policies to decide about the 2215 security protocol to employ. If one really needs to protect headers, 2216 and is allowed to do so by the surrounding environment, then one 2217 should also look at alternatives, e.g., IPsec [RFC2401]. 2218 22199.5. Integrity of the RTP payload and header 2220 2221 SRTP messages are subject to attacks on their integrity and source 2222 identification, and these risks are discussed in Section 9.5.1. To 2223 protect against these attacks, each SRTP stream SHOULD be protected 2224 by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key, 2225 or a message authentication code with equivalent strength. Secure 2226 RTP SHOULD NOT be used without message authentication, except under 2227 the circumstances described in this section. It is important to note 2228 that encryption algorithms, including AES Counter Mode and f8, do not 2229 provide message authentication. SRTCP MUST NOT be used with weak (or 2230 NULL) authentication. 2231 2232 SRTP MAY be used with weak authentication (e.g., a 32-bit 2233 authentication tag), or with no authentication (the NULL 2234 authentication algorithm). These options allow SRTP to be used to 2235 provide confidentiality in situations where 2236 2237 * weak or null authentication is an acceptable security risk, and 2238 * it is impractical to provide strong message authentication. 2239 2240 2241 2242Baugher, et al. Standards Track [Page 40] 2243 2244RFC 3711 SRTP March 2004 2245 2246 2247 These conditions are described below and in Section 7.5. Note that 2248 both conditions MUST hold in order for weak or null authentication to 2249 be used. The risks associated with exercising the weak or null 2250 authentication options need to be considered by a security audit 2251 prior to their use for a particular application or environment given 2252 the risks, which are discussed in Section 9.5.1. 2253 2254 Weak authentication is acceptable when the RTP application is such 2255 that the effect of a small fraction of successful forgeries is 2256 negligible. If the application is stateless, then the effect of a 2257 single forged RTP packet is limited to the decoding of that 2258 particular packet. Under this condition, the size of the 2259 authentication tag MUST ensure that only a negligible fraction of the 2260 packets passed to the RTP application by the SRTP receiver can be 2261 forgeries. This fraction is negligible when an adversary, if given 2262 control of the forged packets, is not able to make a significant 2263 impact on the output of the RTP application (see the example of 2264 Section 7.5). 2265 2266 Weak or null authentication MAY be acceptable when it is unlikely 2267 that an adversary can modify ciphertext so that it decrypts to an 2268 intelligible value. One important case is when it is difficult for 2269 an adversary to acquire the RTP plaintext data, since for many 2270 codecs, an adversary that does not know the input signal cannot 2271 manipulate the output signal in a controlled way. In many cases it 2272 may be difficult for the adversary to determine the actual value of 2273 the plaintext. For example, a hidden snooping device might be 2274 required in order to know a live audio or video signal. The 2275 adversary's signal must have a quality equivalent to or greater than 2276 that of the signal under attack, since otherwise the adversary would 2277 not have enough information to encode that signal with the codec used 2278 by the victim. Plaintext prediction may also be especially difficult 2279 for an interactive application such as a telephone call. 2280 2281 Weak or null authentication MUST NOT be used when the RTP application 2282 makes data forwarding or access control decisions based on the RTP 2283 data. In such a case, an attacker may be able to subvert 2284 confidentiality by causing the receiver to forward data to an 2285 attacker. See Section 3 of [B96] for a real-life example of such 2286 attacks. 2287 2288 Null authentication MUST NOT be used when a replay attack, in which 2289 an adversary stores packets then replays them later in the session, 2290 could have a non-negligible impact on the receiver. An example of a 2291 successful replay attack is the storing of the output of a 2292 surveillance camera for a period of time, later followed by the 2293 2294 2295 2296 2297 2298Baugher, et al. Standards Track [Page 41] 2299 2300RFC 3711 SRTP March 2004 2301 2302 2303 injection of that output to the monitoring station to avoid 2304 surveillance. Encryption does not protect against this attack, and 2305 non-null authentication is REQUIRED in order to defeat it. 2306 2307 If existential message forgery is an issue, i.e., when the accuracy 2308 of the received data is of non-negligible importance, null 2309 authentication MUST NOT be used. 2310 23119.5.1. Risks of Weak or Null Message Authentication 2312 2313 During a security audit considering the use of weak or null 2314 authentication, it is important to keep in mind the following attacks 2315 which are possible when no message authentication algorithm is used. 2316 2317 An attacker who cannot predict the plaintext is still always able to 2318 modify the message sent between the sender and the receiver so that 2319 it decrypts to a random plaintext value, or to send a stream of bogus 2320 packets to the receiver that will decrypt to random plaintext values. 2321 This attack is essentially a denial of service attack, though in the 2322 absence of message authentication, the RTP application will have 2323 inputs that are bit-wise correlated with the true value. Some 2324 multimedia codecs and common operating systems will crash when such 2325 data are accepted as valid video data. This denial of service attack 2326 may be a much larger threat than that due to an attacker dropping, 2327 delaying, or re-ordering packets. 2328 2329 An attacker who cannot predict the plaintext can still replay a 2330 previous message with certainty that the receiver will accept it. 2331 Applications with stateless codecs might be robust against this type 2332 of attack, but for other, more complex applications these attacks may 2333 be far more grave. 2334 2335 An attacker who can predict the plaintext can modify the ciphertext 2336 so that it will decrypt to any value of her choosing. With an 2337 additive stream cipher, an attacker will always be able to change 2338 individual bits. 2339 2340 An attacker may be able to subvert confidentiality due to the lack of 2341 authentication when a data forwarding or access control decision is 2342 made on decrypted but unauthenticated plaintext. This is because the 2343 receiver may be fooled into forwarding data to an attacker, leading 2344 to an indirect breach of confidentiality (see Section 3 of [B96]). 2345 This is because data-forwarding decisions are made on the decrypted 2346 plaintext; information in the plaintext will determine to what subnet 2347 (or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode 2348 (respectively, transport mode). When Secure RTP is used without 2349 2350 2351 2352 2353 2354Baugher, et al. Standards Track [Page 42] 2355 2356RFC 3711 SRTP March 2004 2357 2358 2359 message authentication, it should be verified that the application 2360 does not make data forwarding or access control decisions based on 2361 the decrypted plaintext. 2362 2363 Some cipher modes of operation that require padding, e.g., standard 2364 cipher block chaining (CBC) are very sensitive to attacks on 2365 confidentiality if certain padding types are used in the absence of 2366 integrity. The attack [V02] shows that this is indeed the case for 2367 the standard RTP padding as discussed in reference to Figure 1, when 2368 used together with CBC mode. Later transform additions to SRTP MUST 2369 therefore carefully consider the risk of using this padding without 2370 proper integrity protection. 2371 23729.5.2. Implicit Header Authentication 2373 2374 The IV formation of the f8-mode gives implicit authentication (IHA) 2375 of the RTP header, even when message authentication is not used. 2376 When IHA is used, an attacker that modifies the value of the RTP 2377 header will cause the decryption process at the receiver to produce 2378 random plaintext values. While this protection is not equivalent to 2379 message authentication, it may be useful for some applications. 2380 238110. Interaction with Forward Error Correction mechanisms 2382 2383 The default processing when using Forward Error Correction (e.g., RFC 2384 2733) processing with SRTP SHALL be to perform FEC processing prior 2385 to SRTP processing on the sender side and to perform SRTP processing 2386 prior to FEC processing on the receiver side. Any change to this 2387 ordering (reversing it, or, placing FEC between SRTP encryption and 2388 SRTP authentication) SHALL be signaled out of band. 2389 239011. Scenarios 2391 2392 SRTP can be used as security protocol for the RTP/RTCP traffic in 2393 many different scenarios. SRTP has a number of configuration 2394 options, in particular regarding key usage, and can have impact on 2395 the total performance of the application according to the way it is 2396 used. Hence, the use of SRTP is dependent on the kind of scenario 2397 and application it is used with. In the following, we briefly 2398 illustrate some use cases for SRTP, and give some guidelines for 2399 recommended setting of its options. 2400 240111.1. Unicast 2402 2403 A typical example would be a voice call or video-on-demand 2404 application. 2405 2406 2407 2408 2409 2410Baugher, et al. Standards Track [Page 43] 2411 2412RFC 3711 SRTP March 2004 2413 2414 2415 Consider one bi-directional RTP stream, as one RTP session. It is 2416 possible for the two parties to share the same master key in the two 2417 directions according to the principles of Section 9.1. The first 2418 round of the key derivation splits the master key into any or all of 2419 the following session keys (according to the provided security 2420 functions): 2421 2422 SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key. 2423 2424 (For simplicity, we omit discussion of the salts, which are also 2425 derived.) In this scenario, it will in most cases suffice to have a 2426 single master key with the default lifetime. This guarantees 2427 sufficiently long lifetime of the keys and a minimum set of keys in 2428 place for most practical purposes. Also, in this case RTCP 2429 protection can be applied smoothly. Under these assumptions, use of 2430 the MKI can be omitted. As the key-derivation in combination with 2431 large difference in the packet rate in the respective directions may 2432 require simultaneous storage of several session keys, if storage is 2433 an issue, we recommended to use low-rate key derivation. 2434 2435 The same considerations can be extended to the unicast scenario with 2436 multiple RTP sessions, where each session would have a distinct 2437 master key. 2438 243911.2. Multicast (one sender) 2440 2441 Just as with (unprotected) RTP, a scalability issue arises in big 2442 groups due to the possibly very large amount of SRTCP Receiver 2443 Reports that the sender might need to process. In SRTP, the sender 2444 may have to keep state (the cryptographic context) for each receiver, 2445 or more precisely, for the SRTCP used to protect Receiver Reports. 2446 The overhead increases proportionally to the size of the group. In 2447 particular, re-keying requires special concern, see below. 2448 2449 Consider first a small group of receivers. There are a few possible 2450 setups with the distribution of master keys among the receivers. 2451 Given a single RTP session, one possibility is that the receivers 2452 share the same master key as per Section 9.1 to secure all their 2453 respective RTCP traffic. This shared master key could then be the 2454 same one used by the sender to protect its outbound SRTP traffic. 2455 Alternatively, it could be a master key shared only among the 2456 receivers and used solely for their SRTCP traffic. Both alternatives 2457 require the receivers to trust each other. 2458 2459 Considering SRTCP and key storage, it is recommended to use low-rate 2460 (or zero) key_derivation (except the mandatory initial one), so that 2461 the sender does not need to store too many session keys (each SRTCP 2462 stream might otherwise have a different session key at a given point 2463 2464 2465 2466Baugher, et al. Standards Track [Page 44] 2467 2468RFC 3711 SRTP March 2004 2469 2470 2471 in time, as the SRTCP sources send at different times). Thus, in 2472 case key derivation is wanted for SRTP, the cryptographic context for 2473 SRTP can be kept separate from the SRTCP crypto context, so that it 2474 is possible to have a key_derivation_rate of 0 for SRTCP and a non- 2475 zero value for SRTP. 2476 2477 Use of the MKI for re-keying is RECOMMENDED for most applications 2478 (see Section 8.1). 2479 2480 If there are more than one SRTP/SRTCP stream (within the same RTP 2481 session) that share the master key, the upper limit of 2^48 SRTP 2482 packets / 2^31 SRTCP packets means that, before one of the streams 2483 reaches its maximum number of packets, re-keying MUST be triggered on 2484 ALL streams sharing the master key. (From strict security point of 2485 view, only the stream reaching the maximum would need to be re-keyed, 2486 but then the streams would no longer be sharing master key, which is 2487 the intention.) A local policy at the sender side should force 2488 rekeying in a way that the maximum packet limit is not reached on any 2489 of the streams. Use of the MKI for re-keying is RECOMMENDED. 2490 2491 In large multicast with one sender, the same considerations as for 2492 the small group multicast hold. The biggest issue in this scenario 2493 is the additional load placed at the sender side, due to the state 2494 (cryptographic contexts) that has to be maintained for each receiver, 2495 sending back RTCP Receiver Reports. At minimum, a replay window 2496 might need to be maintained for each RTCP source. 2497 249811.3. Re-keying and access control 2499 2500 Re-keying may occur due to access control (e.g., when a member is 2501 removed during a multicast RTP session), or for pure cryptographic 2502 reasons (e.g., the key is at the end of its lifetime). When using 2503 SRTP default transforms, the master key MUST be replaced before any 2504 of the index spaces are exhausted for any of the streams protected by 2505 one and the same master key. 2506 2507 How key management re-keys SRTP implementations is out of scope, but 2508 it is clear that there are straightforward ways to manage keys for a 2509 multicast group. In one-sender multicast, for example, it is 2510 typically the responsibility of the sender to determine when a new 2511 key is needed. The sender is the one entity that can keep track of 2512 when the maximum number of packets has been sent, as receivers may 2513 join and leave the session at any time, there may be packet loss and 2514 delay etc. In scenarios other than one-sender multicast, other 2515 methods can be used. Here, one must take into consideration that key 2516 exchange can be a costly operation, taking several seconds for a 2517 single exchange. Hence, some time before the master key is 2518 exhausted/expires, out-of-band key management is initiated, resulting 2519 2520 2521 2522Baugher, et al. Standards Track [Page 45] 2523 2524RFC 3711 SRTP March 2004 2525 2526 2527 in a new master key that is shared with the receiver(s). In any 2528 event, to maintain synchronization when switching to the new key, 2529 group policy might choose between using the MKI and the <From, To>, 2530 as described in Section 8.1. 2531 2532 For access control purposes, the <From, To> periods are set at the 2533 desired granularity, dependent on the packet rate. High rate re- 2534 keying can be problematic for SRTCP in some large-group scenarios. 2535 As mentioned, there are potential problems in using the SRTP index, 2536 rather than the SRTCP index, for determining the master key. In 2537 particular, for short periods during switching of master keys, it may 2538 be the case that SRTCP packets are not under the current master key 2539 of the correspondent SRTP. Therefore, using the MKI for re-keying in 2540 such scenarios will produce better results. 2541 254211.4. Summary of basic scenarios 2543 2544 The description of these scenarios highlights some recommendations on 2545 the use of SRTP, mainly related to re-keying and large scale 2546 multicast: 2547 2548 - Do not use fast re-keying with the <From, To> feature. It may, in 2549 particular, give problems in retrieving the correct SRTCP key, if 2550 an SRTCP packet arrives close to the re-keying time. The MKI 2551 SHOULD be used in this case. 2552 2553 - If multiple SRTP streams in the same RTP session share the same 2554 master key, also moderate rate re-keying MAY have the same 2555 problems, and the MKI SHOULD be used. 2556 2557 - Though offering increased security, a non-zero key_derivation_rate 2558 is NOT RECOMMENDED when trying to minimize the number of keys in 2559 use with multiple streams. 2560 256112. IANA Considerations 2562 2563 The RTP specification establishes a registry of profile names for use 2564 by higher-level control protocols, such as the Session Description 2565 Protocol (SDP), to refer to transport methods. This profile 2566 registers the name "RTP/SAVP". 2567 2568 SRTP uses cryptographic transforms which a key management protocol 2569 signals. It is the task of each particular key management protocol 2570 to register the cryptographic transforms or suites of transforms with 2571 IANA. The key management protocol conveys these protocol numbers, 2572 not SRTP, and each key management protocol chooses the numbering 2573 scheme and syntax that it requires. 2574 2575 2576 2577 2578Baugher, et al. Standards Track [Page 46] 2579 2580RFC 3711 SRTP March 2004 2581 2582 2583 Specification of a key management protocol for SRTP is out of scope 2584 here. Section 8.2, however, provides guidance on the parameters that 2585 need to be defined for the default and mandatory transforms. 2586 258713. Acknowledgements 2588 2589 David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this 2590 document but their valuable contributions are acknowledged here to 2591 keep the length of the author list down. 2592 2593 The authors would in addition like to thank Magnus Westerlund, Brian 2594 Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie- 2595 Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen 2596 Colin Perkins and Stephen Casner, the Transport and Security Area 2597 Directors, and Eric Rescorla for their reviews and support. 2598 259914. References 2600 260114.1. Normative References 2602 2603 [AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, 2604 http://www.nist.gov/aes/ 2605 2606 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 2607 Hashing for Message Authentication", RFC 2104, February 2608 1997. 2609 2610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2611 Requirement Levels", BCP 14, RFC 2119, March 1997. 2612 2613 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for 2614 Internet Protocol", RFC 2401, November 1998. 2615 2616 [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, 2617 May 2000. 2618 2619 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2620 "RTP: A Transport Protocol for Real-time Applications", RFC 2621 3550, July 2003. 2622 2623 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2624 Video Conferences with Minimal Control", RFC 3551, July 2625 2003. 2626 2627 2628 2629 2630 2631 2632 2633 2634Baugher, et al. Standards Track [Page 47] 2635 2636RFC 3711 SRTP March 2004 2637 2638 263914.2. Informative References 2640 2641 [AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode 2642 Encryption", NIST, http://csrc.nist.gov/encryption/modes/ 2643 workshop1/papers/lipmaa-ctr.pdf 2644 2645 [B96] Bellovin, S., "Problem Areas for the IP Security 2646 Protocols," in Proceedings of the Sixth Usenix Unix 2647 Security Symposium, pp. 1-16, San Jose, CA, July 1996 2648 (http://www.research.att.com/~smb/papers/index.html). 2649 2650 [BDJR] Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A 2651 Concrete Treatment of Symmetric Encryption: Analysis of DES 2652 Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394- 2653 403, 1997. 2654 2655 [BS00] Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data 2656 Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000, 2657 LNCS 1976, pp. 1-13, Springer Verlag. 2658 2659 [C99] Crowell, W. P., "Introduction to the VENONA Project", 2660 http://www.nsa.gov:8080/docs/venona/index.html. 2661 2662 [CTR] Dworkin, M., NIST Special Publication 800-38A, 2663 "Recommendation for Block Cipher Modes of Operation: 2664 Methods and Techniques", 2001. 2665 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800- 2666 38a.pdf. 2667 2668 [f8-a] 3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd 2669 Generation Partnership Project; Technical Specification 2670 Group Services and System Aspects; 3G Security; 2671 Specification of the 3GPP Confidentiality and Integrity 2672 Algorithms; Document 1: f8 and f9 Specification (Release 2673 4). 2674 2675 [f8-b] 3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd 2676 Generation Partnership Project; Technical Specification 2677 Group Services and System Aspects; 3G Security; General 2678 Report on the Design, Specification and Evaluation of 3GPP 2679 Standard Confidentiality and Integrity Algorithms (Release 2680 4). 2681 2682 [GDOI] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The 2683 Group Domain of Interpretation, RFC 3547, July 2003. 2684 2685 2686 2687 2688 2689 2690Baugher, et al. Standards Track [Page 48] 2691 2692RFC 3711 SRTP March 2004 2693 2694 2695 [HAC] Menezes, A., Van Oorschot, P. and S. Vanstone, "Handbook 2696 of Applied Cryptography", CRC Press, 1997, ISBN 0-8493- 2697 8523-7. 2698 2699 [H80] Hellman, M. E., "A cryptanalytic time-memory trade-off", 2700 IEEE Transactions on Information Theory, July 1980, pp. 2701 401-406. 2702 2703 [IK] T. Iwata and T. Kohno: "New Security Proofs for the 3GPP 2704 Confidentiality and Integrity Algorithms", Proceedings of 2705 FSE 2004. 2706 2707 [KINK] Thomas, M. and J. Vilhuber, "Kerberized Internet 2708 Negotiation of Keys (KINK)", Work in Progress. 2709 2710 [KEYMGT] Arrko, J., et al., "Key Management Extensions for Session 2711 Description Protocol (SDP) and Real Time Streaming Protocol 2712 (RTSP)", Work in Progress. 2713 2714 [KSYH] Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable 2715 Security of KASUMI and 3GPP Encryption Mode f8", 2716 Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp. 2717 255-271, 2001. 2718 2719 [MIKEY] Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing", 2720 Work in Progress. 2721 2722 [MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of 2723 Redundant Plaintext and Implications on Internet Security", 2724 the Proceedings of the Seventh Annual Workshop on Selected 2725 Areas in Cryptography (SAC 2000), Springer-Verlag. 2726 2727 [PCST1] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient 2728 and Secure Source Authentication for Multicast", in Proc. 2729 of Network and Distributed System Security Symposium NDSS 2730 2001, pp. 35-46, 2001. 2731 2732 [PCST2] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient 2733 Authentication and Signing of Multicast Streams over Lossy 2734 Channels", in Proc. of IEEE Security and Privacy Symposium 2735 S&P2000, pp. 56-73, 2000. 2736 2737 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2738 Recommendations for Security", RFC 1750, December 1994. 2739 2740 [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", 2741 RFC 2675, August 1999. 2742 2743 2744 2745 2746Baugher, et al. Standards Track [Page 49] 2747 2748RFC 3711 SRTP March 2004 2749 2750 2751 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H., 2752 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 2753 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 2754 T., Yoshimura, T. and H. Zheng, "RObust Header Compression: 2755 Framework and Four Profiles: RTP, UDP, ESP, and 2756 uncompressed (ROHC)", RFC 3095, July 2001. 2757 2758 [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 2759 (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC 2760 3242, April 2002. 2761 2762 [SDMS] Andreasen, F., Baugher, M. and D. Wing, "Session 2763 Description Protocol Security Descriptions for Media 2764 Streams", Work in Progress. 2765 2766 [SWO] Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over- 2767 wireless", Proc. PIMRC 2000, London, Sept. 2000. 2768 2769 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 2770 Application to SSL, IPsec, WTLS...", Advances in 2771 Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545. 2772 2773 [WC81] Wegman, M. N., and J.L. Carter, "New Hash Functions and 2774 Their Use in Authentication and Set Equality", JCSS 22, 2775 265-279, 1981. 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802Baugher, et al. Standards Track [Page 50] 2803 2804RFC 3711 SRTP March 2004 2805 2806 2807Appendix A: Pseudocode for Index Determination 2808 2809 The following is an example of pseudo-code for the algorithm to 2810 determine the index i of an SRTP packet with sequence number SEQ. In 2811 the following, signed arithmetic is assumed. 2812 2813 if (s_l < 32,768) 2814 if (SEQ - s_l > 32,768) 2815 set v to (ROC-1) mod 2^32 2816 else 2817 set v to ROC 2818 endif 2819 else 2820 if (s_l - 32,768 > SEQ) 2821 set v to (ROC+1) mod 2^32 2822 else 2823 set v to ROC 2824 endif 2825 endif 2826 return SEQ + v*65,536 2827 2828Appendix B: Test Vectors 2829 2830 All values are in hexadecimal. 2831 2832B.1. AES-f8 Test Vectors 2833 2834 SRTP PREFIX LENGTH : 0 2835 2836 RTP packet header : 806e5cba50681de55c621599 2837 2838 RTP packet payload : 70736575646f72616e646f6d6e657373 2839 20697320746865206e65787420626573 2840 74207468696e67 2841 2842 ROC : d462564a 2843 key : 234829008467be186c3de14aae72d62c 2844 salt key : 32f2870d 2845 key-mask (m) : 32f2870d555555555555555555555555 2846 key XOR key-mask : 11baae0dd132eb4d3968b41ffb278379 2847 2848 IV : 006e5cba50681de55c621599d462564a 2849 IV' : 595b699bbd3bc0df26062093c1ad8f73 2850 2851 2852 2853 2854 2855 2856 2857 2858Baugher, et al. Standards Track [Page 51] 2859 2860RFC 3711 SRTP March 2004 2861 2862 2863 j = 0 2864 IV' xor j : 595b699bbd3bc0df26062093c1ad8f73 2865 S(-1) : 00000000000000000000000000000000 2866 IV' xor S(-1) xor j : 595b699bbd3bc0df26062093c1ad8f73 2867 S(0) : 71ef82d70a172660240709c7fbb19d8e 2868 plaintext : 70736575646f72616e646f6d6e657373 2869 ciphertext : 019ce7a26e7854014a6366aa95d4eefd 2870 2871 j = 1 2872 IV' xor j : 595b699bbd3bc0df26062093c1ad8f72 2873 S(0) : 71ef82d70a172660240709c7fbb19d8e 2874 IV' xor S(0) xor j : 28b4eb4cb72ce6bf020129543a1c12fc 2875 S(1) : 3abd640a60919fd43bd289a09649b5fc 2876 plaintext : 20697320746865206e65787420626573 2877 ciphertext : 1ad4172a14f9faf455b7f1d4b62bd08f 2878 2879 j = 2 2880 IV' xor j : 595b699bbd3bc0df26062093c1ad8f71 2881 S(1) : 3abd640a60919fd43bd289a09649b5fc 2882 IV' xor S(1) xor j : 63e60d91ddaa5f0b1dd4a93357e43a8d 2883 S(2) : 220c7a8715266565b09ecc8a2a62b11b 2884 plaintext : 74207468696e67 2885 ciphertext : 562c0eef7c4802 2886 2887B.2. AES-CM Test Vectors 2888 2889 Keystream segment length: 1044512 octets (65282 AES blocks) 2890 Session Key: 2B7E151628AED2A6ABF7158809CF4F3C 2891 Rollover Counter: 00000000 2892 Sequence Number: 0000 2893 SSRC: 00000000 2894 Session Salt: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted) 2895 Offset: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 2896 2897 Counter Keystream 2898 2899 F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 E03EAD0935C95E80E166B16DD92B4EB4 2900 F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001 D23513162B02D0F72A43A2FE4A5F97AB 2901 F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002 41E95B3BB0A2E8DD477901E4FCA894C0 2902 ... ... 2903 F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF EC8CDF7398607CB0F2D21675EA9EA1E4 2904 F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00 362B7C3C6773516318A077D7FC5073AE 2905 F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01 6A2CC3787889374FBEB4C81B17BA6C44 2906 2907 Nota Bene: this test case is contrived so that the latter part of the 2908 keystream segment coincides with the test case in Section F.5.1 of 2909 [CTR]. 2910 2911 2912 2913 2914Baugher, et al. Standards Track [Page 52] 2915 2916RFC 3711 SRTP March 2004 2917 2918 2919B.3. Key Derivation Test Vectors 2920 2921 This section provides test data for the default key derivation 2922 function, which uses AES-128 in Counter Mode. In the following, we 2923 walk through the initial key derivation for the AES-128 Counter Mode 2924 cipher, which requires a 16 octet session encryption key and a 14 2925 octet session salt, and an authentication function which requires a 2926 94-octet session authentication key. These values are called the 2927 cipher key, the cipher salt, and the auth key in the following. 2928 Since this is the initial key derivation and the key derivation rate 2929 is equal to zero, the value of (index DIV key_derivation_rate) is 2930 zero (actually, a six-octet string of zeros). In the following, we 2931 shorten key_derivation_rate to kdr. 2932 2933 The inputs to the key derivation function are the 16 octet master key 2934 and the 14 octet master salt: 2935 2936 master key: E1F97A0D3E018BE0D64FA32C06DE4139 2937 master salt: 0EC675AD498AFEEBB6960B3AABE6 2938 2939 We first show how the cipher key is generated. The input block for 2940 AES-CM is generated by exclusive-oring the master salt with the 2941 concatenation of the encryption key label 0x00 with (index DIV kdr), 2942 then padding on the right with two null octets (which implements the 2943 multiply-by-2^16 operation, see Section 4.3.3). The resulting value 2944 is then AES-CM- encrypted using the master key to get the cipher key. 2945 2946 index DIV kdr: 000000000000 2947 label: 00 2948 master salt: 0EC675AD498AFEEBB6960B3AABE6 2949 ----------------------------------------------- 2950 xor: 0EC675AD498AFEEBB6960B3AABE6 (x, PRF input) 2951 2952 x*2^16: 0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input) 2953 2954 cipher key: C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output) 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970Baugher, et al. Standards Track [Page 53] 2971 2972RFC 3711 SRTP March 2004 2973 2974 2975 Next, we show how the cipher salt is generated. The input block for 2976 AES-CM is generated by exclusive-oring the master salt with the 2977 concatenation of the encryption salt label. That value is padded and 2978 encrypted as above. 2979 2980 index DIV kdr: 000000000000 2981 label: 02 2982 master salt: 0EC675AD498AFEEBB6960B3AABE6 2983 2984 ---------------------------------------------- 2985 xor: 0EC675AD498AFEE9B6960B3AABE6 (x, PRF input) 2986 2987 x*2^16: 0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input) 2988 2989 30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut) 2990 2991 cipher salt: 30CBBC08863D8C85D49DB34A9AE1 2992 2993 We now show how the auth key is generated. The input block for AES- 2994 CM is generated as above, but using the authentication key label. 2995 2996 index DIV kdr: 000000000000 2997 label: 01 2998 master salt: 0EC675AD498AFEEBB6960B3AABE6 2999 ----------------------------------------------- 3000 xor: 0EC675AD498AFEEAB6960B3AABE6 (x, PRF input) 3001 3002 x*2^16: 0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input) 3003 3004 Below, the auth key is shown on the left, while the corresponding AES 3005 input blocks are shown on the right. 3006 3007 auth key AES input blocks 3008 CEBE321F6FF7716B6FD4AB49AF256A15 0EC675AD498AFEEAB6960B3AABE60000 3009 6D38BAA48F0A0ACF3C34E2359E6CDBCE 0EC675AD498AFEEAB6960B3AABE60001 3010 E049646C43D9327AD175578EF7227098 0EC675AD498AFEEAB6960B3AABE60002 3011 6371C10C9A369AC2F94A8C5FBCDDDC25 0EC675AD498AFEEAB6960B3AABE60003 3012 6D6E919A48B610EF17C2041E47403576 0EC675AD498AFEEAB6960B3AABE60004 3013 6B68642C59BBFC2F34DB60DBDFB2 0EC675AD498AFEEAB6960B3AABE60005 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026Baugher, et al. Standards Track [Page 54] 3027 3028RFC 3711 SRTP March 2004 3029 3030 3031Authors' Addresses 3032 3033 Questions and comments should be directed to the authors and 3034 avt@ietf.org: 3035 3036 Mark Baugher 3037 Cisco Systems, Inc. 3038 5510 SW Orchid Street 3039 Portland, OR 97219 USA 3040 3041 Phone: +1 408-853-4418 3042 EMail: mbaugher@cisco.com 3043 3044 3045 Elisabetta Carrara 3046 Ericsson Research 3047 SE-16480 Stockholm 3048 Sweden 3049 3050 Phone: +46 8 50877040 3051 EMail: elisabetta.carrara@ericsson.com 3052 3053 3054 David A. McGrew 3055 Cisco Systems, Inc. 3056 San Jose, CA 95134-1706 3057 USA 3058 3059 Phone: +1 301-349-5815 3060 EMail: mcgrew@cisco.com 3061 3062 3063 Mats Naslund 3064 Ericsson Research 3065 SE-16480 Stockholm 3066 Sweden 3067 3068 Phone: +46 8 58533739 3069 EMail: mats.naslund@ericsson.com 3070 3071 3072 Karl Norrman 3073 Ericsson Research 3074 SE-16480 Stockholm 3075 Sweden 3076 3077 Phone: +46 8 4044502 3078 EMail: karl.norrman@ericsson.com 3079 3080 3081 3082Baugher, et al. Standards Track [Page 55] 3083 3084RFC 3711 SRTP March 2004 3085 3086 3087Full Copyright Statement 3088 3089 Copyright (C) The Internet Society (2004). This document is subject 3090 to the rights, licenses and restrictions contained in BCP 78 and 3091 except as set forth therein, the authors retain all their rights. 3092 3093 This document and the information contained herein are provided on an 3094 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3095 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3096 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3097 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3098 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3099 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3100 3101Intellectual Property 3102 3103 The IETF takes no position regarding the validity or scope of any 3104 Intellectual Property Rights or other rights that might be claimed to 3105 pertain to the implementation or use of the technology described in 3106 this document or the extent to which any license under such rights 3107 might or might not be available; nor does it represent that it has 3108 made any independent effort to identify any such rights. Information 3109 on the procedures with respect to rights in RFC documents can be 3110 found in BCP 78 and BCP 79. 3111 3112 Copies of IPR disclosures made to the IETF Secretariat and any 3113 assurances of licenses to be made available, or the result of an 3114 attempt made to obtain a general license or permission for the use of 3115 such proprietary rights by implementers or users of this 3116 specification can be obtained from the IETF on-line IPR repository at 3117 http://www.ietf.org/ipr. 3118 3119 The IETF invites any interested party to bring to its attention any 3120 copyrights, patents or patent applications, or other proprietary 3121 rights that may cover technology that may be required to implement 3122 this standard. Please address the information to the IETF at ietf- 3123 ipr@ietf.org. 3124 3125Acknowledgement 3126 3127 Funding for the RFC Editor function is currently provided by the 3128 Internet Society. 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138Baugher, et al. Standards Track [Page 56] 3139 3140