idnits 2.17.1 draft-ietf-avt-srtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1788 has weird spacing: '...n using the M...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 7989 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'AES' is defined on line 1892, but no explicit reference was found in the text == Unused Reference: 'HMAC' is defined on line 1895, but no explicit reference was found in the text == Unused Reference: 'ES3E' is defined on line 1937, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) == Outdated reference: A later version (-05) exists of draft-rescorla-sec-cons-00 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Baugher, McGrew, 3 AVT Working Group Oran (Cisco) 4 INTERNET-DRAFT Blom, Carrara, Naslund, 5 EXPIRES: September 2002 Norrman (Ericsson) 6 May 2002 8 The Secure Real Time Transport Protocol 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes the Secure Real Time Transport Protocol 35 (SRTP), a profile of the Real Time Transport Protocol (RTP), which 36 can provide confidentiality, message authentication, and replay 37 protection to the RTP/RTCP traffic. 39 SRTP can achieve high throughput and low packet expansion. SRTP 40 proves to be a suitable protection for heterogeneous environments, 41 i.e., environments including both wired and wireless links. To get 42 such features, default transforms are described, based on an 43 additive stream cipher for encryption, a keyed-hash based function 44 for message authentication, and an "implicit" index for 45 sequencing/synchronization based on the RTP sequence number for SRTP 46 and an index number for Secure RTCP (SRTCP). 48 TABLE OF CONTENTS 50 1. Notational Conventions............................................3 51 2. Goals and Features................................................3 52 3. SRTP Framework....................................................5 53 3.1 SRTP Cryptographic Contexts.....................................6 54 3.1.1 Transform-independent parameters............................7 55 3.1.2 Transform-dependent parameters..............................9 56 3.1.3 Mapping SRTP Packets to Cryptographic Contexts..............9 57 3.2 SRTP Packet Processing.........................................10 58 3.2.1 Packet Index Determination, and ROC, s_l Update............11 59 3.2.2 Replay Protection..........................................13 60 3.3 Secure RTCP....................................................14 61 4. Pre-Defined Cryptographic Transforms.............................17 62 4.1 Encryption.....................................................17 63 4.1.1 AES in Counter Mode........................................19 64 4.1.2 AES in f8-mode.............................................20 65 4.1.3 NULL Cipher................................................22 66 4.2 Message Authentication and Integrity...........................22 67 4.2.1. HMAC-SHA1.................................................23 68 4.3 Key Derivation.................................................23 69 4.3.1 Key Derivation Algorithm...................................23 70 4.3.2 SRTCP Key Derivation.......................................25 71 4.3.3 AES-CM PRF.................................................25 72 5. Default and mandatory-to-implement Transforms....................26 73 5.1 Encryption: AES-CM and NULL....................................26 74 5.2 Message Authentication/Integrity: HMAC-SHA1....................26 75 5.3 Key Derivation: AES-CM PRF.....................................26 76 6. Adding SRTP Transforms...........................................26 77 7. Rationale........................................................27 78 7.1 Key derivation.................................................27 79 7.2 Salting key....................................................28 80 7.3 Message Integrity from Universal Hashing.......................28 81 7.4 Data Origin Authentication Considerations......................28 82 8. Key Management Considerations....................................29 83 8.1. Re-keying.....................................................30 84 8.2. Key Management parameters.....................................30 85 9. Security Considerations..........................................31 86 9.1 SSRC collision and two-time pad................................31 87 9.2 Key Usage......................................................32 88 9.3 Confidentiality of the RTP Payload.............................34 89 9.4 Confidentiality of the RTP Header..............................34 90 9.5 Integrity of the RTP payload and header........................35 91 10. Interaction with Forward Error Correction mechanisms............36 92 11. Scenarios.......................................................36 93 11.1 Unicast.......................................................36 94 11.2 Multicast.....................................................37 95 11.2.1 Small multicast with one sender...........................37 96 11.2.2 Large multicast with one sender...........................38 97 11.3 Re-keying and access control..................................38 98 11.4 Summary of basic scenarios....................................39 99 12. IANA Considerations.............................................40 100 13. Acknowledgements................................................40 101 14. Author's Addresses..............................................40 102 15. References......................................................41 103 Appendix A: Pseudocode for Index Determination......................43 104 Appendix B: Test Vectors............................................44 105 B.1 AES-f8 Test Vectors............................................44 106 B.2 AES-CM Test Vectors............................................45 107 B.3 Key Derivation and PRF Test Vectors............................45 109 1. Notational Conventions 111 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 114 The terminology conforms to [RFC2828]. 116 By convention, the adopted representation is the network byte order, 117 i.e. the left most bit (octet) is the most significant one. By XOR 118 we mean bitwise addition modulo 2 of binary strings, and || denotes 119 concatenation. In other words, if C = A || B, then the most 120 significant bits of C are the bits of A, and the least significant 121 bits of C equal the bits of B. Hexadecimal numbers are prefixed by 122 0x. 124 With slight abuse of notation, we refer in some cases to integrity 125 protection of the message as "message authentication". The word 126 "encryption" includes also use of the NULL algorithm (which 127 in practice does leave the data in the clear). 129 2. Goals and Features 131 The security goals for SRTP are to ensure: 133 * the confidentiality of the RTP and RTCP payloads, and 134 * the integrity of the entire RTP and RTCP packets, together with 135 protection against replayed packets. 137 These security services are optional and independent from each 138 other, except that SRTCP integrity protection is mandatory. 140 Other, functional, goals for the protocol are: 142 * a framework that permits upgrading with new cryptographic 143 transforms, 145 * low bandwidth cost, i.e., a framework preserving RTP header 146 compression efficiency, 148 and, asserted by the pre-defined transforms: 150 * a low computational cost, 152 * a small footprint (i.e. small code size and data memory for keying 153 information and replay lists), 155 * limited packet expansion to support the bandwidth economy goal, 157 * independence from the underlying transport, network, and physical 158 layers used by RTP, in particular high tolerance to packet loss 159 and re-ordering, and robustness to transmission bit-errors in the 160 encrypted payload. 162 These properties ensure that SRTP is a suitable protection scheme 163 for RTP/RTCP in both wired and wireless scenarios. 165 2.1 Features 167 Besides the above mentioned direct goals, SRTP provides for some 168 additional features. They have been introduced to lighten the burden 169 on key management and to further increase security. They include: 171 * A single so-called master key provides keying material for 172 confidentiality and integrity protection, both for the SRTP stream 173 and the corresponding SRTCP stream. This is achieved due to a key 174 derivation function (see Section 4.3), providing so-called session 175 keys for the respective security primitive, securely derived from 176 the master key. Under additional SSRC uniqueness requirements, a 177 single master key can even protect several SRTP streams, see 178 Section 9.1. 180 * In addition, the key derivation can be configured to periodically 181 "refresh" the session keys, which limits the amount of ciphertext 182 produced by a fixed key, available for an adversary to 183 cryptanalyze. 185 * So-called salting keys are used to protect against off-line pre- 186 computation attacks. 188 Detailed rationale for these features can be found in Section 7. 190 3. SRTP Framework 192 RTP is the Real Time Transport Protocol [RFC1889]. We define SRTP as 193 a profile of RTP, in a way analogous to RFC1890 which defines the 194 audio/video profile for RTP. Conceptually, we consider it to be a 195 "bump in the stack" implementation which resides between the RTP 196 application and the transport layer. SRTP intercepts RTP packets and 197 then forwards an equivalent SRTP packet on the sending side, and 198 which intercepts SRTP packets and passes an equivalent RTP packet up 199 the stack on the receiving side. 201 The format of an SRTP packet is illustrated in Figure 1. 203 The Encrypted Portion of an SRTP packet consists of the encryption 204 of the RTP payload (including RTP padding when present) of the 205 equivalent RTP packet. (Note: our use of the word "encryption" 206 includes also the possibility of a "NULL" encryption, and we 207 therefore speak of the "Encrypted Portion" even if only the NULL- 208 encryption has been applied.) 210 The optional MKI and optional authentication tag are the only fields 211 defined by SRTP that are not in RTP. Only 8-bit alignment is 212 assumed. 214 MKI (Master Key Identifier): variable length, OPTIONAL 215 The MKI is defined, signaled, and used by key management. 216 The MKI identifies the master key from which the session 217 key(s) were derived that authenticate and/or encrypt the 218 particular packet. Note that the MKI SHALL NOT identify the 219 SRTP cryptographic context, which is identified according to 220 Section 3.1.3. The MKI MAY be used by key management for the 221 purposes of re-keying, identifying a particular master key 222 within the cryptographic context (Section 3.1.1). 224 Authentication tag: variable length, OPTIONAL 225 The authentication tag is used to carry message 226 authentication data. The Authenticated Portion of an SRTP 227 packet consists of the RTP header followed by the Encrypted 228 Portion of the SRTP packet. Thus, note that if both 229 encryption and authentication are applied, encryption SHALL 230 be applied before authentication on the sender side and 231 conversely on the receiver side. The authentication tag 232 provides authentication of the RTP header and payload, and it 233 indirectly provides replay protection by authenticating the 234 sequence number. Note that the MKI is not integrity protected 235 as this does not provide any extra protection. 237 0 1 2 3 238 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 239 +-->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | |V=2|P|X| CC |M| PT | sequence number | 241 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | timestamp | 243 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | synchronization source (SSRC) identifier | 245 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 246 | | contributing source (CSRC) identifiers | 247 | | .... | 248 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | RTP extension (OPTIONAL) | 250 | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | | | 252 | | | payload | 253 | | | .... | 254 +-+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | ~ SRTP MKI (OPTIONAL) ~ 256 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | ~ authentication tag (OPTIONAL) ~ 258 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 | +- Encrypted Portion 261 +---- Authenticated Portion 263 Figure 1. The format of an SRTP packet. 265 Secure RTCP (SRTCP) is described in Section 3.3. SRTCP adds fields 266 to the RTCP packets in a similar way. 268 3.1 SRTP Cryptographic Contexts 270 Each SRTP stream requires the sender and receiver to maintain 271 cryptographic state information. This information is called the 272 "cryptographic context". 274 SRTP uses two types of keys: session keys and master keys. By a 275 "session key", we mean a key which is used directly in a 276 cryptographic transform (e.g. encryption or message authentication), 277 and by a "master key", we mean a random bit string (given by the key 278 management protocol) from which session keys are derived in a 279 cryptographically secure way. 281 3.1.1 Transform-independent parameters 283 "Transform-independent parameters" are present in the cryptographic 284 context independently of the particular encryption or authentication 285 transforms that are used. The transform-independent parameters of 286 the cryptographic context for SRTP consist of: 288 * a 32-bit unsigned rollover counter (ROC), which records how many 289 times the 16-bit RTP sequence number has been reset to zero after 290 passing through 65,535. Unlike the sequence number (SEQ), which 291 SRTP extracts from the RTP packet header, the ROC is maintained by 292 SRTP as described in Section 3.2.1. 294 We define the index of the SRTP packet corresponding to a given 295 ROC and RTP sequence number to be the 48-bit quantity 297 i = 2^16 * ROC + SEQ. 299 * for the receiver only, a 16-bit sequence number s_l, which is the 300 highest received RTP sequence number (possibly authenticated, if 301 message authentication is provided), 303 * an identifier for the encryption algorithm, i.e., the cipher and 304 its mode of operation, 306 * an identifier for the message authentication algorithm (when 307 authentication is provided), 309 * a replay list, maintained by the receiver only (when 310 authentication and replay protection are provided), containing 311 indices of recently received and authenticated SRTP packets, 313 * an MKI indicator (0/1) as to whether an MKI is present in SRTP and 314 SRTCP packets, 316 * if the MKI indicator is set to one, the length (in octets) of the 317 MKI field, and (for the sender) the actual value of the currently 318 active MKI, (the value of the MKI indicator and length MUST be 319 kept fixed for the lifetime of the context), 321 * the master key(s), which MUST be random and kept secret, 322 * for each master key, there is a counter of the number of SRTP 323 packets that has been processed (sent) with that master key 324 (essential for security, see Sections 3.2.1 and 9), 326 * non-negative integers n_e, and n_a, determining the length of the 327 session keys for encryption, and message authentication. 329 In addition, for each master key, an SRTP stream MAY use the 330 following associated values: 332 * a master salt, to be used in the key derivation of session keys. 333 This value, when used, MUST be random, but MAY be public. Use of 334 master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" 335 salt is treated as 00...0. 337 * an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", 338 where an unspecified value is treated as zero, 340 * <"From", "To"> values, specifying the lifetime for a master key, 341 expressed in terms of the two 48-bit index values inside whose 342 range (including the range end-points) the master key is valid. 343 These values are absolute quantities, not relative. Whenever this 344 field is unspecified, the related master key is valid "from the 345 first observed packet" to "until further notice" (with maximum 346 lifetime as specified in Section 3.2.1). 348 SRTCP SHALL by default share the crypto context with SRTP and uses 349 the same cryptographic context parameters, except: 351 * no rollover counter and s_l-value need to be maintained as the 352 RTCP index is explicitly carried in each SRTCP packet, 354 * a separate replay list is maintained (when replay protection is 355 provided), 357 * SRTCP maintains a separate counter for its master key (even if the 358 master key is the same as that for SRTP, see below), as a mean to 359 maintain a count of the number of SRTCP packets that have been 360 processed with that key. 362 Note in particular that the master key(s) MAY be shared between SRTP 363 and SRTCP, if the pre-defined transforms (including the key 364 derivation) are used but the session key(s) MUST NOT be so shared. 366 In addition, there can be cases (see Sections 8 and 9.1) where 367 several SRTP streams, identified by their SSRCs, share most of the 368 crypto context parameters (including master keys). In such cases, 369 just as in the normal SRTP/SRTCP parameter sharing above, separate 370 replay lists and packet counters for each stream (SSRC) MUST still 371 be maintained, but the session keys MAY then be shared between SRTP 372 streams. 374 A summary of parameters, pre-defined transforms, and default values 375 for the above parameters (and other SRTP parameters) can be found in 376 Sections 5 and 8.2. 378 3.1.2 Transform-dependent parameters 380 All encryption, authentication/integrity, and key derivation 381 parameters are defined in the transforms section (Section 4). 382 Typical examples of such parameters are block size of ciphers, 383 session keys, data for IV formation, etc. Future SRTP transform 384 specifications MUST include a section to list the additional 385 cryptographic context's parameters for that transform, if any. 387 3.1.3 Mapping SRTP Packets to Cryptographic Contexts 389 Recall that an RTP session for each participant is defined [RFC1889] 390 by a pair of destination transport addresses (one network address 391 plus a port pair for RTP and RTCP), and that a multimedia session is 392 defined as a collection of RTP sessions. For example, a particular 393 multimedia session could include an audio RTP session, a video RTP 394 session, and a text RTP session. 396 A cryptographic context SHALL be uniquely identified by the triplet 397 context identifier: 399 context id = 402 where the destination network address and the destination transport 403 port are the ones in the current RTP packet (for the sender) or SRTP 404 packet (for the receiver). It is assumed that, when presented with 405 this information, the key management returns a context with the 406 information as described in Section 3.1. 408 As noted above, SRTP and SRTCP by default share the bulk of the 409 parameters in the cryptographic context. Thus, retrieving the crypto 410 context parameters for an SRTCP stream in practice may imply a 411 binding to the correspondent SRTP crypto context. It is up to the 412 implementation to assure such binding, since the RTCP port may not 413 be directly deducible from the RTP port only. Alternatively, the key 414 management may choose to provide separate SRTP- and SRTCP-contexts, 415 duplicating the common parameters (such as master key(s)). The 416 latter approach then also enables SRTP and SRTCP to use, e.g., 417 distinct transforms, if so desired. Similar considerations arise 418 when multiple SRTP streams share keys and other parameters. 420 If no valid context can be found for a packet corresponding to a 421 certain context identifier, that packet MUST be discarded from 422 further SRTP processing. 424 3.2 SRTP Packet Processing 426 The following applies to SRTP. SRTCP is described in Section 3.3. 428 Assuming initialization of the cryptographic context(s) has taken 429 place via key management, the sender SHALL do the following to 430 construct an SRTP packet: 432 1. Determine which cryptographic context to use as described in 433 Section 3.1.3. 435 2. Determine the index of the SRTP packet using the rollover counter 436 in the cryptographic context and the sequence number in the RTP 437 packet, as described in Section 3.2.1. 439 3. Determine the master key and master salt. This is done using the 440 index determined in the previous step or the current MKI in the 441 cryptographic context. 443 4. Determine the session keys and session salt (if they are used by 444 the transform) as described in Section 4.3, using master key, master 445 salt, key_derivation_rate, and session key-lengths in the 446 cryptographic context with the index, determined in Steps 2 and 3. 448 5. Encrypt the RTP payload to produce the Encrypted Portion of the 449 packet (see Section 4.1, for the defined ciphers). This step uses 450 the encryption algorithm indicated in the cryptographic context, the 451 session encryption key and the session salt (if used) found in Step 452 4 together with the index found in Step 2. 454 6. If the MKI indicator is set to one, append the MKI to the packet. 456 7. If message authentication is provided, compute the authentication 457 tag for the Authenticated Portion of the packet, as described in 458 Section 4.2. This step uses the current rollover counter, the 459 authentication algorithm indicated in the cryptographic context, and 460 the session authentication key found in Step 4. Append the 461 authentication tag to the packet. 463 8. If necessary, update the ROC as in Section 3.2.1, using the 464 packet index determined in Step 2. 466 To authenticate and decrypt an SRTP packet, the receiver SHALL do 467 the following: 469 1. Determine which cryptographic context to use as described in 470 Section 3.1.3. 472 2. Estimate the index of the SRTP packet using the rollover counter 473 and highest sequence number in the cryptographic context with the 474 sequence number in the SRTP packet, as described in Section 3.2.1. 476 3. Determine the master key and master salt. If the MKI indicator in 477 the context is set to one, use the MKI in the SRTP packet, otherwise 478 use the index from the previous step. 480 4. Determine the session keys, and session salt (if used by the 481 transform) as described in Section 4.3, using master key, master 482 salt, key_derivation_rate and session key-lengths in the 483 cryptographic context with the index, determined in Steps 2 and 3. 485 5. If message authentication and replay protection are provided, 486 first check if the packet has been replayed (Section 3.2.2), using 487 the Replay List and the index as determined in Step 2. If the packet 488 is judged to be replayed, then the packet MUST be discarded, and the 489 event SHOULD be logged. 491 Next, perform verification of the authentication tag, using the 492 rollover counter from Step 2, the authentication algorithm indicated 493 in the cryptographic context, and the session authentication key 494 from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 495 4.2), the packet MUST be discarded from further processing and the 496 event SHOULD be logged. 498 6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for 499 the defined ciphers), using the decryption algorithm indicated in 500 the cryptographic context, the session encryption key and salt (if 501 used) found in Step 4 with the index from Step 2. 503 7. Update the rollover counter and highest sequence number, s_l, in 504 the cryptographic context as in Section 3.2.1, using the packet 505 index estimated in Step 2. If replay protection is provided, also 506 update the Replay List as described in Section 3.2.2. 508 8. When present, remove the MKI and authentication tag fields from 509 the packet. 511 3.2.1 Packet Index Determination, and ROC, s_l Update 512 SRTP implementations use an "implicit" packet index for sequencing, 513 i.e., not all of the index is explicitly carried in the SRTP packet. 514 For the pre-defined transforms, the index i is used in replay 515 protection (Section 3.2.2), encryption (Section 4.1), message 516 authentication (Section 4.2), and for the key derivation (Section 517 4.3). The index MAY also be used to determine the correct master key 518 when <"From", "To"> values are used to represent key lifetime 519 (Section 3.1.1). 521 When the session starts, the sender side MUST set the rollover 522 counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps 523 modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 524 (see security aspects below). The sender's packet index is then 525 defined as 527 i = 2^16 * ROC + SEQ. 529 Receiver-side implementations use the RTP sequence number to estimate 530 the correct index of a packet, which is the location of the packet in 531 the sequence of all SRTP packets. A robust approach for the proper 532 use of a rollover counter requires its handling and use to be well 533 defined. In particular, out-of-order RTP packets with sequence 534 numbers close to 2^16 or zero must be properly handled. 536 The index estimate is based on the receiver's locally maintained ROC 537 and s_l values. At the setup of the session, ROC MUST be set to zero. 538 Receivers joining an on-going session MUST be given the current ROC 539 value using out of band signaling. Furthermore, the receiver SHALL 540 initialize s_l to the RTP sequence number (SEQ) of the first observed 541 SRTP packet (unless the initial value is provided by key management). 543 On consecutive SRTP packets, the receiver SHOULD estimate the index 544 as 546 i = 2^16 * v + SEQ, 548 where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) 549 such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC 550 + s_l. 552 After the packet has been processed using the estimated index, the 553 receiver MUST decide if s_l and ROC should be updated. For instance, 554 a simple (but not error robust) method is to simply set s_l to SEQ 555 (if SEQ > s_l) and, if the value v = ROC+1 was used, to update ROC to 556 v. 558 After a re-keying occurs (changing to a new master key), the 559 rollover counter maintains its sequence of values, i.e., it MUST NOT 560 be reset to zero, to avoid inconsistencies in key lifetimes. 562 As the rollover counter is 32 bits long and the sequence number is 563 16 bits long, the maximum number of packets belonging to a given 564 SRTP stream that can be secured with the same key is 2^48 using the 565 pre-defined transforms. After that number of SRTP packets have been 566 sent with a given (master or session) key, the sender MUST NOT send 567 any more packets with that key. (There exists a similar limit for 568 SRTCP, which in practice may be more restrictive, see Section 9.2.) 569 This limitation enforces a security benefit by providing an upper 570 bound on the amount of traffic that can pass before cryptographic 571 keys are changed. Re-keying (see Section 8.1) MUST be triggered, 572 before this amount of traffic, and MAY be triggered earlier, e.g., 573 for increased security and access control to media. Recurring key 574 derivation by means of a non-zero key_derivation_rate (see Section 575 4.3), also gives stronger security but does not change the above 576 absolute maximum value. 578 On the receiver side, there is a caveat to updating s_l and ROC: if 579 message authentication is not present, neither the initialization of 580 s_l, nor the ROC update can be made completely robust. The 581 receiver's "implicit index" approach works for the pre-defined 582 transforms as long as the reorder and loss of the packets are not 583 too great and bit-errors do not occur in unfortunate ways. In 584 particular, 2^15 packets would need to be lost, or a packet would 585 need to be 2^15 packets out of sequence before synchronization is 586 lost. Such drastic loss or reorder is likely to disrupt the RTP 587 application itself. 589 A more elaborate and more robust scheme is the handling of RTP's own 590 "rollover counter", see Appendix A.1 of [RFC1889]. 592 3.2.2 Replay Protection 594 Secure replay protection is only possible when integrity protection 595 is present. It is RECOMMENDED to use replay protection, both for RTP 596 and RTCP, as integrity protection alone cannot assure security 597 against replay attacks. 599 A packet is "replayed" when it is stored by an adversary, and then 600 re-injected into the network. When message authentication is 601 provided, SRTP protects against such attacks through a "Replay 602 List". Each SRTP receiver maintains a Replay List, which 603 conceptually contains the indices of all of the packets which have 604 been received and authenticated. In practice, the list can use a 605 "sliding window" approach, so that a fixed amount of storage 606 suffices for replay protection. Packet indices which lag behind the 607 packet index in the context by more than SRTP-WINDOW-SIZE can be 608 assumed to have been received, where SRTP-WINDOW-SIZE is a receiver- 609 side, implementation-dependent parameter and MUST be at least 64, 610 but which MAY be set to a higher value. 612 The receiver checks the index of an incoming packet against the 613 replay list and the window. Only packets with index ahead of the 614 window, or, inside the window but not already received, SHALL be 615 accepted. 617 After the packet has been authenticated (if necessary the window is 618 first moved ahead), the replay list SHALL be updated with the new 619 index. 621 The Replay List can be efficiently implemented by using a bitmap to 622 represent which packets have been received, as described in the 623 Security Architecture for IP [RFC2401]. 625 3.3 Secure RTCP 627 Secure RTCP follows the definition of Secure RTP. SRTCP adds three 628 mandatory new fields (the SRTCP index, an "encrypt-flag", and the 629 authentication tag) and one optional field (the MKI) to the RTCP 630 packet definition. The three mandatory fields MUST be appended to an 631 RTCP packet in order to form an equivalent SRTCP packet. The added 632 fields follow any other profile-specific extensions. 634 According to [RFC1889] there is a "recommended" packet format for 635 compound packets. SRTCP MUST be given packets according to that 636 recommendation in the sense that the first part MUST be a sender 637 report or a receiver report. However, the so-called encryption 638 prefix (Section 6.1 of [RFC1889]), a random 32-bit quantity intended 639 to deter known plaintext attacks, MUST NOT be used (see below). 641 The Encrypted Portion of an SRTCP packet consists of the encryption 642 (Section 4.1) of the RTCP payload of the equivalent compound RTCP 643 packet, from the first RTCP packet, i.e., from the ninth (9) octet 644 to the end of the compound packet. The Authenticated Portion of an 645 SRTCP packet consists of the entire equivalent (eventually compound) 646 RTCP packet, the E flag, and the SRTCP index (after any encryption 647 has been applied to the payload). 649 0 1 2 3 650 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 651 +-->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | |V=2|P| RC | PT=SR or RR | length | 653 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | SSRC of sender | 655 | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 656 | | ~ sender info ~ 657 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | ~ report block 1 ~ 659 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | | ~ report block 2 ~ 661 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | ~ ... ~ 663 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | | |V=2|P| SC | PT=SDES=202 | length | 665 | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 666 | | | SSRC/CSRC_1 | 667 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | ~ SDES items ~ 669 | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 670 | | ~ ... ~ 671 | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 672 | | |E| SRTCP index | 673 +-|>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | | ~ SRTCP MKI (OPTIONAL) ~ 675 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | : authentication tag : 677 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | | 679 | +-- Encrypted Portion 680 +---- Authenticated Portion 682 Figure 2. An example of the format of a Secure RTCP packet, 683 consisting of an underlying RTCP compound packet with a Report and 684 SDES packet. 686 The added fields are: 688 E-flag: 1 bit, REQUIRED 689 The E-flag indicates if the current SRTCP packet is encrypted 690 or unencrypted. Section 9.1 of [RFC1889] allows the split of 691 a compound RTCP packet into two lower-layer packets, one to 692 be encrypted and one to be sent in the clear. The E bit set 693 to "1" indicates encrypted packet, and "0" indicates non- 694 encrypted packet. 696 SRTCP index: 31 bits, REQUIRED 697 The SRTCP index is a 31-bit counter for the SRTCP packet. The 698 index is explicitly included in each packet, in contrast to 699 the "implicit" index approach used for SRTP. The SRTCP index 700 MUST be set to zero before the first SRTCP packet is sent, 701 and MUST be incremented by one, modulo 2^31, after each SRTCP 702 packet is sent. In particular, after a re-key, the SRTCP 703 index MUST NOT be reset to zero again (Section 3.2.1). 705 Authentication Tag: variable length, REQUIRED 706 The authentication tag is used to carry message 707 authentication data. 709 MKI: variable length, OPTIONAL 710 The MKI is the Master Key Indicator, and functions according 711 to the MKI definition in Section 3. 713 SRTCP uses the cryptographic context parameters and packet 714 processing of SRTP by default, with the following changes: 716 * The receiver does not need to "estimate" the index, as it is 717 explicitly signaled in the packet. 719 * If the MKI indicator in the cryptographic context is zero, the 720 master key is determined by the current SRTP index when that key is 721 shared between SRTP and SRTCP, even though SRTCP has its own index. 722 Since the SRTCP source as with any SSRC in an SRTP session has its 723 own sequence number space, the master key <"From", "To"> lifetime 724 MUST be based on the SRTP master key lifetime when the master key is 725 shared by both SRTP and SRTCP. The concomitant re-keying issues are 726 discussed in sections 8 and 9. 728 * Pre-defined SRTCP encryption is as specified in Section 4.1, but 729 using the definition of the SRTCP Encrypted Portion given in this 730 section, and using the SRTCP index as the index i. The encryption 731 transform and related parameters SHALL by default be the same 732 selected for the protection of the associated SRTP stream(s), while 733 the NULL algorithm SHALL be applied to the RTCP packets not to be 734 encrypted. 736 The E-flag is assigned a value by the sender depending on whether 737 the packet was encrypted or not. 739 * SRTCP decryption is performed as in Section 4, but only if the E 740 flag is equal to 1. If so, the Encrypted Portion is decrypted, using 741 the SRTCP index as the index i. In case the E-flag is 0, the payload 742 is simply left unmodified. 744 * SRTCP replay protection is as defined in Section 3.2.2, but using 745 the SRTCP index as the index i and a separate replay list that is 746 specific to SRTCP. 748 * The pre-defined SRTCP authentication tag is specified as in 749 Section 4.2, but with the Authenticated Portion of the SRTCP packet 750 given in this section (which includes the index). The authentication 751 transform and related parameters (e.g., key size) SHALL by default 752 be the same as selected for the protection of the associated SRTP 753 stream(s) (except when SRTP is not authenticated). 755 * In the last step of the processing, only the sender needs to 756 update the value of the SRTCP index by incrementing it modulo 2^31 757 and for security reasons the sender MUST also check the number of 758 RTCP packets processed, see Section 9.2. 760 As noted, the encryption prefix (Section 6.1 of RFC1889]) SHALL NOT 761 be used, as it is not needed by the cryptographic mechanisms used in 762 SRTP. 764 Message authentication for RTCP is REQUIRED, as it is the control 765 protocol (e.g., it has a BYE packet). Note also that the cost in 766 total bandwidth for RTCP authentication is not as high as the one of 767 RTP authentication, as the recommended session bandwidth allocated 768 to RTCP is at most 5% and the RTCP packets are less frequent. 769 However, when adding authentication to RTCP, the overhead in 770 bandwidth SHOULD be considered and the total bandwidth for SRTCP 771 SHOULD preserve the limit of 5%. 773 4. Pre-Defined Cryptographic Transforms 775 While there are numerous encryption and message authentication 776 algorithms that can be used in SRTP, we define below default 777 algorithms in order to avoid the complexity of specifying the 778 encodings for the signaling of algorithm and parameter identifiers. 779 The defined algorithms have been chosen as they fulfill the goals 780 listed in Section 2. Recommendations on how to extend SRTP with new 781 transforms are given in Section 6. 783 4.1 Encryption 785 The following parameters are common to both pre-defined, non-NULL, 786 encryption transforms specified in this section. 788 * BLOCK_CIPHER-MODE indicates the block cipher used and its mode of 789 operation 791 * n_b is the bit-size of the block for the block cipher 792 * k_e is the session encryption key 793 * n_e is the bit-length of k_e 794 * k_s is the session salting key 795 * n_s is the bit-length of k_s 796 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, an 797 non-negative integer, specified by the message authentication code 798 in use. 800 The distinct session keys and salts for SRTP/SRTCP are by default 801 derived as specified in Section 4.3. 803 The encryption transforms defined in SRTP use a "seekable" segmented 804 keystream generator (KG), which maps the SRTP packet index and 805 secret key into a pseudorandom keystream segment. Each keystream 806 segment encrypts a single RTP packet. The process of encrypting a 807 packet consists of generating the keystream segment corresponding to 808 the packet, and then bitwise exclusive-oring that keystream segment 809 onto the payload of the RTP packet to produce the Encrypted Portion 810 of the SRTP packet. Decryption is done the same way, but swapping 811 the roles of the plaintext and ciphertext. 813 The definition of how the keystream is generated, given the index, 814 depends on the cipher and its mode of operation. Below, two such 815 keystream generators are defined. The NULL cipher is also defined, 816 to be used when encryption of RTP is not required. 818 +----+ +------------------+---------------------------------+ 819 | KG |-->| Keystream Prefix | Keystream Suffix |---+ 820 +----+ +------------------+---------------------------------+ | 821 | 822 +---------------------------------+ v 823 | Payload of RTP Packet |->(*) 824 +---------------------------------+ | 825 | 826 +---------------------------------+ | 827 | Encrypted Portion of SRTP Packet|<--+ 828 +---------------------------------+ 830 Figure 3: Default SRTP Encryption Processing. Here KG denotes the 831 keystream generator, and (*) denotes bitwise exclusive-or. 833 The SRTP definition of the keystream is illustrated in Figure 3. The 834 initial octets of each keystream segment MAY be reserved for use in 835 a message authentication code, in which case the keystream used for 836 encryption starts immediately after the last reserved octet. The 837 initial reserved octets are called the "keystream prefix" (not to be 838 confused with the so-called "encryption prefix" of [RFC1889, Section 839 6.1]), and the remaining octets are called the "keystream suffix". 840 The keystream prefix MUST NOT be used for encryption. The process is 841 illustrated in Figure 3. 843 The number of octets in the keystream prefix is denoted as 844 SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, 845 non-zero value of SRTP_PREFIX_LENGTH. This means that, even if 846 confidentiality is not to be provided, the keystream generator 847 output may still need to be computed for packet authentication, in 848 which case the default keystream generator (mode) SHALL be used. 850 The default cipher is the Advanced Encryption Standard (AES), and we 851 define two modes of running AES, Segmented Integer Counter Mode AES 852 and AES in f8-mode. In the sequel, let E(k,x) be AES applied to key 853 k and input block x. 855 4.1.1 AES in Counter Mode 857 Conceptually, counter mode consists of encrypting successive 858 integers. The actual definition is somewhat more complicated, in 859 order to randomize the starting point of the integer sequence. Each 860 packet is encrypted with a distinct keystream segment, which SHALL 861 be computed as follows. 863 A keystream segment SHALL be the concatenation of the 128-bit output 864 blocks of the AES cipher in the encrypt direction, using key k = 865 k_e, in which the block indices are in increasing order. 866 Symbolically, each keystream segment looks like 868 E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ... 870 where the 128-bit integer value IV SHALL be defined by the SSRC, the 871 SRTP packet index i, and the SRTP session salting key k_s, as below. 873 IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16) 875 The inclusion of the SSRC allows the use of the same key to protect 876 distinct SRTP streams (see the security caveats in Section 9.1). 878 In the case of SRTCP, the SSRC of the first header of the compound 879 packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s 880 SHALL be replaced by the SRTCP session key and salt. 882 Note that the initial value, IV, is fixed for each packet. The 883 number of blocks of keystream generated for any fixed value of IV 884 MUST NOT exceed 2^16. The AES has a block size of 128 bits, so 2^16 885 output blocks are sufficient to generate the 2^23 bits of keystream 886 needed to encrypt the largest possible RTP packet (except for IPv6 887 "jumbograms" [RFC2675], which are not likely to be used for RTP- 888 based multimedia traffic). This restriction on the maximum bit-size 889 of the packet that can be encrypted ensures the security of the 890 encryption method by limiting the effectiveness of probabilistic 891 attacks [BDJR]. 893 4.1.2 AES in f8-mode 895 IV 896 | 897 | 898 v 899 +------+ 900 | | 901 +--->| E | 902 | | | 903 | +------+ 904 | | 905 m -> (*) +-----------+-------------+-- ... ------+ 906 | IV' | | | | 907 | | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*) 908 | | | | | 909 | | +-> (*) +-> (*) ... +-> (*) 910 | | | | | | | | 911 | v | v | v | v 912 | +------+ | +------+ | +------+ | +------+ 913 | | | | | | | | | | | | 914 k_e ---+--->| E | | | E | | | E | | | E | 915 | | | | | | | | | | | 916 +------+ | +------+ | +------+ | +------+ 917 | | | | | | | 918 +------+ +--------+ +-- ... ----+ | 919 | | | | 920 v v v v 921 S(0) S(1) S(2) . . . S(L-1) 923 Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). 924 The figure represents the KG in Figure 3, when AES-f8 is used. 926 To encrypt UMTS (Universal Mobile Telecommunications System, as 3G 927 networks) data, a solution (see [ES3D]) known as the f8-algorithm 928 has been developed. On a high level, the proposed scheme is a 929 variant of Output Feedback Mode (OFB) [HAC], with a more elaborate 930 initialization and feedback function. As in normal OFB, the core 931 consists of a block cipher. We also define here the use of AES as a 932 block cipher to be used in f8-mode for RTP encryption. The AES f8- 933 mode SHALL use the same default sizes for session key and salt as 934 AES counter mode. 936 Figure 4 shows the structure of block cipher, E, running in what we 937 shall call "f8-mode of operation". 939 4.1.2.1 f8 Keystream Generation 941 The Initialization Vector (IV) SHALL be determined as described in 942 Section 4.1.2.2. 944 Let IV', S(j), and m denote n_b-bit blocks. The keystream, S(0) || 945 ... || S(L-1), for an N-bit message SHALL be defined by setting IV' 946 = E(k_e XOR m, IV), and S(-1) = 00..0. For j = 0,1,..,L-1 where L = 947 N/n_b (rounded up to nearest integer) compute 949 S(j) = E(k_e, IV' XOR j XOR S(j-1)) 951 Notice that the IV is not used directly. Instead it is fed through E 952 under another key to produce an internal, "masked" value (denoted 953 IV') to prevent an attacker from gaining known input/output pairs. 954 The role of the internal counter, j, is to prevent short keystream 955 cycles. The value of the key mask m SHALL be 957 m = k_s || 0x555..5, 959 i.e. the session salting key, appended by the binary pattern 0101.. 960 to fill out the entire desired key size, n_e. 962 The maximum allowable packet size can be determined as follows. The 963 AES has a block size of 128 bits, and assuming that AES behaves like 964 a random function, it is (heuristically) secure to generate less 965 than 2^64 output blocks, we suggest a maximum of 2^32 blocks, which 966 is sufficient to generate 2^39 bits of keystream. For practical 967 sizes of the RTP packets, much fewer blocks are required though, and 968 the counter j will often be sufficient if implemented as a 16-bit 969 counter. 971 4.1.2.2 f8 SRTP IV Formation 973 The purpose of the following IV formation is to provide a feature 974 which we call implicit header authentication (IHA), see Section 9.5. 976 The SRTP IV for 128-bit block AES-f8 SHALL be formed in the 977 following way: 979 IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC 981 M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from 982 the cryptographic context. 984 The presence of the SSRC as part of the IV allows AES-f8 to be used 985 when a master key is shared between multiple streams, see Section 986 9.1. 988 4.1.2.3 f8 SRTCP IV Formation 990 The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the 991 following way: 993 IV = 0...0 || E || SRTCP index || V || P || RC || PT || length || 994 SSRC 996 where V, P, RC, PT, length, SSRC SHALL be taken from the first 997 header in the RTCP compound packet. E and SRTCP index are the 1-bit 998 and 31-bit fields added to the packet. 1000 4.1.3 NULL Cipher 1002 The NULL cipher is used when no confidentiality for RTP/RTCP is 1003 requested. The keystream can be thought of as "000..0", i.e. the 1004 encryption SHALL simply copy the plaintext input into the ciphertext 1005 output. 1007 4.2 Message Authentication and Integrity 1009 Throughout this section, M will denote data to be integrity 1010 protected: in the case of SRTP, M SHALL consist of the Authenticated 1011 Portion of the packet (as specified in Figure 1) concatenated with 1012 the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M 1013 SHALL consist of the Authenticated Portion (as specified in Figure 1014 2) only. 1016 Common parameters: 1018 * AUTH_ALG is the authentication algorithm 1019 * k_a is the session message authentication key 1020 * n_a is the bit-length of the authentication key 1021 * n_tag is the bit-length of the output authentication tag 1022 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as 1023 defined above, a parameter of AUTH_ALG 1025 The distinct session authentication keys for SRTP/SRTCP are by 1026 default derived as specified in Section 4.3. 1028 The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for 1029 any particular fixed value of the key. 1031 We describe the process of computing authentication tags as follows. 1032 The sender computes the tag of M and appends it to the packet. The 1033 SRTP receiver verifies a message/authentication tag pair by 1034 computing a new authentication tag over M using the selected 1035 algorithm and key, and then compares it to the tag associated with 1036 the received message. If the two tags are equal, then the 1037 message/tag pair is valid; otherwise, it is invalid and the error 1038 audit message "AUTHENTICATION FAILURE" MUST be returned. 1040 4.2.1. HMAC-SHA1 1042 When HMAC-SHA1 is used, the SRTP_PREFIX_LENGTH (Figure 3) SHALL be 1043 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to the 1044 session authentication key and M as specifed above, i.e. HMAC(k_a, 1045 M). The HMAC output SHALL then be truncated to the n_tag left-most 1046 bits. 1048 4.3 Key Derivation 1050 4.3.1 Key Derivation Algorithm 1052 Regardless of the encryption or message authentication transform 1053 that is employed (it may be an SRTP pre-defined transform or newly 1054 introduced according to Section 6), interoperable SRTP 1055 implementations MAY use the SRTP key derivation to generate session 1056 keys. Once the key derivation rate is properly signaled at the start 1057 of the session, there is no need for extra communication between the 1058 parties that use SRTP key derivation. 1060 packet index ---+ 1061 | 1062 | 1063 v 1064 +-----------+ master +--------+ session encr_key 1065 | ext | key | |----------> 1066 | key mgmt |-------->| key | session auth_key 1067 | (optional | | deriv |----------> 1068 | rekey) |-------->| | session salt_key 1069 | | master | |----------> 1070 +-----------+ salt +--------+ 1072 Figure 5: SRTP key derivation. 1074 At least one initial key derivation SHALL be performed by SRTP, 1075 i.e., the first key derivation is REQUIRED. Further applications of 1076 the key derivation MAY be performed, according to the 1077 "key_derivation_rate" value in the cryptographic context. The key 1078 derivation function SHALL be initially invoked before the first 1079 packet and then, if derivation rate is r > 0, further invoked on 1080 every r-th packet, and produce session keys according to the non- 1081 zero key derivation rate. This can be thought of as "refreshing" the 1082 session keys. The value of "key_derivation_rate" MUST be kept fixed 1083 for the lifetime of the associated master key. 1085 Interoperable SRTP implementations MAY also derive session salting 1086 keys for encryption transforms, as is done in both of the pre- 1087 defined transforms. 1089 Let m and n be positive integers. A pseudo-random function family is 1090 a set of keyed functions {PRF_n(k,x)} such that for the (secret) 1091 random key k, given m-bit x, PRF_n(k,x) is an n-bit string, 1092 computationally indistinguishable from random n-bit strings, see 1093 [HAC]. For the purpose of key derivation in SRTP, a secure PRF with 1094 m = 128 (or more) is needed, and a default PRF transform is defined 1095 in Section 4.3.3. 1097 Let "a DIV t" denote integer division of a by t, rounded down, and 1098 with the convention that "a DIV 0 = 0" for all a. We also make the 1099 convention of treating "a DIV t" as a bit string of the same length 1100 as a, and thus "a DIV t" will in general have leading zeros. 1102 Key derivation SHALL be defined as follows in terms of