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