idnits 2.17.1 draft-ietf-avt-srtp-08.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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 278 has weird spacing: '...ecurity and f...' == Line 968 has weird spacing: '... could be ca...' == 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 2003) is 7650 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) == Missing Reference: 'RTPnew' is mentioned on line 269, but not defined == Missing Reference: 'ROHC' is mentioned on line 1422, but not defined == Unused Reference: 'AES' is defined on line 2144, but no explicit reference was found in the text == Unused Reference: 'RK99' is defined on line 2249, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'AVPNEW' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'RTPNEW' ** 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 -- Obsolete informational reference (is this intentional?): RFC 3242 (Obsoleted by RFC 4362) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 6 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: November 2003 Norrman (Ericsson) 6 May 2003 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/1id-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 TABLE OF CONTENTS 41 1. Introduction......................................................3 42 1.1. Notational Conventions..........................................3 43 2. Goals and Features................................................4 44 3. SRTP Framework....................................................5 45 3.1 Secure RTP......................................................6 46 3.2 SRTP Cryptographic Contexts.....................................7 47 3.2.1 Transform-independent parameters............................7 48 3.2.2 Transform-dependent parameters.............................10 49 3.2.3 Mapping SRTP Packets to Cryptographic Contexts.............10 50 3.3 SRTP Packet Processing.........................................11 51 3.3.1 Packet Index Determination, and ROC, s_l Update............12 52 3.3.2 Replay Protection..........................................14 53 3.4 Secure RTCP....................................................15 54 4. Pre-Defined Cryptographic Transforms.............................18 55 4.1 Encryption.....................................................19 56 4.1.1 AES in Counter Mode........................................20 57 4.1.2 AES in f8-mode.............................................21 58 4.1.3 NULL Cipher................................................23 59 4.2 Message Authentication and Integrity...........................24 60 4.2.1 HMAC-SHA1..................................................24 61 4.3 Key Derivation.................................................25 62 4.3.1 Key Derivation Algorithm...................................25 63 4.3.2 SRTCP Key Derivation.......................................27 64 4.3.3 AES-CM PRF.................................................27 65 5. Default and mandatory-to-implement Transforms....................27 66 5.1 Encryption: AES-CM and NULL....................................28 67 5.2 Message Authentication/Integrity: HMAC-SHA1....................28 68 5.3 Key Derivation: AES-CM PRF.....................................28 69 6. Adding SRTP Transforms...........................................28 70 7. Rationale........................................................29 71 7.1 Key derivation.................................................29 72 7.2 Salting key....................................................30 73 7.3 Message Integrity from Universal Hashing.......................30 74 7.4 Data Origin Authentication Considerations......................30 75 7.5 Short and Zero-length Message Authentication...................31 76 8. Key Management Considerations....................................32 77 8.1. Re-keying.....................................................33 78 8.2. Key Management parameters.....................................34 79 9. Security Considerations..........................................35 80 9.1 SSRC collision and two-time pad................................35 81 9.2 Key Usage......................................................36 82 9.3 Confidentiality of the RTP Payload.............................38 83 9.4 Confidentiality of the RTP Header..............................38 84 9.5 Integrity of the RTP payload and header........................39 85 9.5.1. Risks of Weak or Null Message Authentication..............40 86 9.5.2 Implicit Header Authentication.............................41 88 10. Interaction with Forward Error Correction mechanisms............41 89 11. Scenarios.......................................................42 90 11.1 Unicast.......................................................42 91 11.2 Multicast (one sender)........................................43 92 11.3 Re-keying and access control..................................44 93 11.4 Summary of basic scenarios....................................44 94 12. IANA Considerations.............................................45 95 13. Acknowledgements................................................45 96 14. Author's Addresses..............................................45 97 15. References......................................................46 98 16. Intellectual Property Right Considerations......................49 99 17. Full Copyright Statement........................................50 100 Appendix A: Pseudocode for Index Determination......................50 101 Appendix B: Test Vectors............................................51 102 B.1 AES-f8 Test Vectors............................................51 103 B.2 AES-CM Test Vectors............................................52 104 B.3 Key Derivation Test Vectors....................................52 106 1. Introduction 108 This document describes the Secure Real-time Transport Protocol 109 (SRTP), a profile of the Real-time Transport Protocol (RTP), which 110 can provide confidentiality, message authentication, and replay 111 protection to the RTP/RTCP traffic. 113 SRTP provides a framework for encryption and message authentication 114 of RTP and RTCP streams (Section 3). SRTP defines a set of default 115 cryptographic transforms (Sections 4 and 5), and it allows new 116 transforms to be introduced in the future (Section 6). With 117 appropriate key management (Sections 7 and 8), SRTP is secure 118 (Sections 9 and 10) for unicast and multicast RTP applications 119 (Section 11). 121 SRTP can achieve high throughput and low packet expansion. SRTP 122 proves to be a suitable protection for heterogeneous environments. 123 To get such features, default transforms are described, based on an 124 additive stream cipher for encryption, a keyed-hash based function 125 for message authentication, and an "implicit" index for 126 sequencing/synchronization based on the RTP sequence number for SRTP 127 and an index number for Secure RTCP (SRTCP). 129 1.1. Notational Conventions 131 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 134 The terminology conforms to [RFC2828]. 136 By convention, the adopted representation is the network byte order, 137 i.e. the left most bit (octet) is the most significant one. By XOR 138 we mean bitwise addition modulo 2 of binary strings, and || denotes 139 concatenation. In other words, if C = A || B, then the most 140 significant bits of C are the bits of A, and the least significant 141 bits of C equal the bits of B. Hexadecimal numbers are prefixed by 142 0x. 144 The word "encryption" includes also use of the NULL algorithm (which 145 in practice does leave the data in the clear). 147 With slight abuse of notation, we use the terms "message 148 authentication" and "authentication tag" as is common practice even 149 though in some circumstances, e.g. group communication, the service 150 provided is actually only integrity protection and not data origin 151 authentication. 153 2. Goals and Features 155 The security goals for SRTP are to ensure: 157 * the confidentiality of the RTP and RTCP payloads, and 159 * the integrity of the entire RTP and RTCP packets, together with 160 protection against replayed packets. 162 These security services are optional and independent from each 163 other, except that SRTCP integrity protection is mandatory 164 (malicious or erroneous alteration of RTCP messages could disrupt 165 the processing of the RTP stream). 167 Other, functional, goals for the protocol are: 169 * a framework that permits upgrading with new cryptographic 170 transforms, 172 * low bandwidth cost, i.e., a framework preserving RTP header 173 compression efficiency, 175 and, asserted by the pre-defined transforms: 177 * a low computational cost, 179 * a small footprint (i.e. small code size and data memory for keying 180 information and replay lists), 182 * limited packet expansion to support the bandwidth economy goal, 183 * independence from the underlying transport, network, and physical 184 layers used by RTP, in particular high tolerance to packet loss 185 and re-ordering. 187 These properties ensure that SRTP is a suitable protection scheme 188 for RTP/RTCP in both wired and wireless scenarios. 190 2.1 Features 192 Besides the above mentioned direct goals, SRTP provides for some 193 additional features. They have been introduced to lighten the burden 194 on key management and to further increase security. They include: 196 * A single "master key" provides keying material for 197 confidentiality and integrity protection, both for the SRTP stream 198 and the corresponding SRTCP stream. This is achieved with a key 199 derivation function (see Section 4.3), providing "session keys" 200 for the respective security primitive, securely derived from 201 the master key. 203 * In addition, the key derivation can be configured to periodically 204 "refresh" the session keys, which limits the amount of ciphertext 205 produced by a fixed key, available for an adversary to 206 cryptanalyze. 208 * "Salting keys" are used to protect against pre-computation and 209 time-memory tradeoff attacks [MF00,BS00]. 211 Detailed rationale for these features can be found in Section 7. 213 3. SRTP Framework 215 RTP is the Real-time Transport Protocol [RTPNEW]. We define SRTP as 216 a profile of RTP. This profile is an extension to the RTP 217 Audio/Video Profile [AVPNEW]. Except where explicitly noted, all 218 aspects of that profile apply, with the addition of the SRTP 219 security features. Conceptually, we consider SRTP to be a "bump in 220 the stack" implementation which resides between the RTP application 221 and the transport layer. SRTP intercepts RTP packets and then 222 forwards an equivalent SRTP packet on the sending side, and which 223 intercepts SRTP packets and passes an equivalent RTP packet up the 224 stack on the receiving side. 226 Secure RTCP (SRTCP) provides the same security services to RTCP as 227 SRTP does to RTP. SRTCP message authentication is MANDATORY and 228 thereby protects the RTCP fields to keep track of membership, 229 provide feedback to RTP senders, or maintain packet sequence 230 counters. SRTCP is described in Section 3.4. 232 3.1 Secure RTP 234 The format of an SRTP packet is illustrated in Figure 1. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 239 |V=2|P|X| CC |M| PT | sequence number | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 241 | timestamp | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 243 | synchronization source (SSRC) identifier | | 244 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 245 | contributing source (CSRC) identifiers | | 246 | .... | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 248 | RTP extension (OPTIONAL) | | 249 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 250 | | payload ... | | 251 | | +-------------------------------+ | 252 | | | RTP padding | RTP pad count | | 253 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 254 | ~ SRTP MKI (OPTIONAL) ~ | 255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 256 | ~ authentication tag (RECOMMENDED) ~ | 257 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 258 | | 259 +- Encrypted Portion* Authenticated Portion ---+ 261 Figure 1. The format of an SRTP packet. *Encrypted Portion is the 262 same size as the plaintext for the Section 4 pre-defined transforms. 264 The Encrypted Portion of an SRTP packet consists of the encryption 265 of the RTP payload (including RTP padding when present) of the 266 equivalent RTP packet. The "Encrypted Portion" MAY be the exact 267 size of the plaintext or MAY be larger. It is exact for the pre- 268 defined transforms. Figure 1 shows the RTP payload including any 269 possible padding for RTP [RTPnew]. The presence of RTP padding is 270 transparent to SRTP, i.e. is treated as part of the plaintext. Note 271 that an encryption transform used in SRTP MAY choose to specify its 272 own padding, independently of the RTP pad, in which case the 273 encrypted portion may be larger than the original RTP packet. None 274 of the pre-defined transforms, however, uses any padding so for 275 these, the sizes match exactly. Each future addition to SRTP MUST 276 specify the amount and format of its padding, if any. While it 277 could seem more attractive to specify a fixed padding scheme for all 278 transforms, security and flexibility of transform specifications 279 REQUIRE that each transform specify a secure padding method. 281 The OPTIONAL MKI and RECOMMENDED authentication tag are the only 282 fields defined by SRTP that are not in RTP. Only 8-bit alignment is 283 assumed. 285 MKI (Master Key Identifier): configurable length, OPTIONAL 286 The MKI is defined, signaled, and used by key management. 287 The MKI identifies the master key from which the session 288 key(s) were derived that authenticate and/or encrypt the 289 particular packet. Note that the MKI SHALL NOT identify the 290 SRTP cryptographic context, which is identified according to 291 Section 3.2.3. The MKI MAY be used by key management for the 292 purposes of re-keying, identifying a particular master key 293 within the cryptographic context (Section 3.2.1). 295 Authentication tag: configurable length, RECOMMENDED 296 The authentication tag is used to carry message 297 authentication data. The Authenticated Portion of an SRTP 298 packet consists of the RTP header followed by the Encrypted 299 Portion of the SRTP packet. Thus, if both encryption and 300 authentication are applied, encryption SHALL be applied 301 before authentication on the sender side and conversely on 302 the receiver side. The authentication tag provides 303 authentication of the RTP header and payload, and it 304 indirectly provides replay protection by authenticating the 305 sequence number. Note that the MKI is not integrity protected 306 as this does not provide any extra protection. 308 3.2 SRTP Cryptographic Contexts 310 Each SRTP stream requires the sender and receiver to maintain 311 cryptographic state information. This information is called the 312 "cryptographic context". 314 SRTP uses two types of keys: session keys and master keys. By a 315 "session key", we mean a key which is used directly in a 316 cryptographic transform (e.g. encryption or message authentication), 317 and by a "master key", we mean a random bit string (given by the key 318 management protocol) from which session keys are derived in a 319 cryptographically secure way. The master key(s) and other parameters 320 in the cryptographic context are provided by key management 321 mechanisms external to SRTP, see Section 8. 323 3.2.1 Transform-independent parameters 324 "Transform-independent parameters" are present in the cryptographic 325 context independently of the particular encryption or authentication 326 transforms that are used. The transform-independent parameters of 327 the cryptographic context for SRTP consist of: 329 * a 32-bit unsigned rollover counter (ROC), which records how many 330 times the 16-bit RTP sequence number has been reset to zero after 331 passing through 65,535. Unlike the sequence number (SEQ), which 332 SRTP extracts from the RTP packet header, the ROC is maintained by 333 SRTP as described in Section 3.3.1. 335 We define the index of the SRTP packet corresponding to a given 336 ROC and RTP sequence number to be the 48-bit quantity 338 i = 2^16 * ROC + SEQ. 340 * for the receiver only, a 16-bit sequence number s_l, which is the 341 highest received RTP sequence number, which SHOULD be 342 authenticated since message authentication is RECOMMENDED, 344 * an identifier for the encryption algorithm, i.e., the cipher and 345 its mode of operation, 347 * an identifier for the message authentication algorithm, 349 * a replay list, maintained by the receiver only (when 350 authentication and replay protection are provided), containing 351 indices of recently received and authenticated SRTP packets, 353 * an MKI indicator (0/1) as to whether an MKI is present in SRTP and 354 SRTCP packets, 356 * if the MKI indicator is set to one, the length (in octets) of the 357 MKI field, and (for the sender) the actual value of the currently 358 active MKI (the value of the MKI indicator and length MUST be 359 kept fixed for the lifetime of the context), 361 * the master key(s), which MUST be random and kept secret, 363 * for each master key, there is a counter of the number of SRTP 364 packets that have been processed (sent) with that master key 365 (essential for security, see Sections 3.3.1 and 9), 367 * non-negative integers n_e, and n_a, determining the length of the 368 session keys for encryption, and message authentication. 370 In addition, for each master key, an SRTP stream MAY use the 371 following associated values: 373 * a master salt, to be used in the key derivation of session keys. 374 This value, when used, MUST be random, but MAY be public. Use of 375 master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" 376 salt is treated as 00...0. 378 * an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", 379 where an unspecified value is treated as zero. The constraint to 380 be a power of 2 simplifies the session-key derivation 381 implementation, see Section 4.3. 383 * an MKI, 385 * <"From", "To"> values, specifying the lifetime for a master key, 386 expressed in terms of the two 48-bit index values inside whose 387 range (including the range end-points) the master key is valid. For 388 the use of , see Section 8.1.1. <"From", "To"> is an 389 alternative to the MKI and assumes that a master key is in one-to- 390 one correspondence with the SRTP session key on which the <"From", 391 "To"> range is defined. 393 SRTCP SHALL by default share the crypto context with SRTP, except: 395 * no rollover counter and s_l-value need to be maintained as the 396 RTCP index is explicitly carried in each SRTCP packet, 398 * a separate replay list is maintained (when replay protection is 399 provided), 401 * SRTCP maintains a separate counter for its master key (even if the 402 master key is the same as that for SRTP, see below), as a means to 403 maintain a count of the number of SRTCP packets that have been 404 processed with that key. 406 Note in particular that the master key(s) MAY be shared between SRTP 407 and the corresponding SRTCP, if the pre-defined transforms 408 (including the key derivation) are used but the session key(s) MUST 409 NOT be so shared. 411 In addition, there can be cases (see Sections 8 and 9.1) where 412 several SRTP streams within a given RTP session, identified by their 413 SSRCs, share most of the crypto context parameters (including 414 possibly master and session keys). In such cases, just as in the 415 normal SRTP/SRTCP parameter sharing above, separate replay lists and 416 packet counters for each stream (SSRC) MUST still be maintained. 417 Also, separate SRTP indices MUST then be maintained. 419 A summary of parameters, pre-defined transforms, and default values 420 for the above parameters (and other SRTP parameters) can be found in 421 Sections 5 and 8.2. 423 3.2.2 Transform-dependent parameters 425 All encryption, authentication/integrity, and key derivation 426 parameters are defined in the transforms section (Section 4). 427 Typical examples of such parameters are block size of ciphers, 428 session keys, data for IV formation, etc. Future SRTP transform 429 specifications MUST include a section to list the additional 430 cryptographic context's parameters for that transform, if any. 432 3.2.3 Mapping SRTP Packets to Cryptographic Contexts 434 Recall that an RTP session for each participant is defined [RTPNEW] 435 by a pair of destination transport addresses (one network address 436 plus a port pair for RTP and RTCP), and that a multimedia session is 437 defined as a collection of RTP sessions. For example, a particular 438 multimedia session could include an audio RTP session, a video RTP 439 session, and a text RTP session. 441 A cryptographic context SHALL be uniquely identified by the triplet 442 context identifier: 444 context id = 447 where the destination network address and the destination transport 448 port are the ones in the SRTP packet. It is assumed that, when 449 presented with this information, the key management returns a 450 context with the information as described in Section 3.2. 452 As noted above, SRTP and SRTCP by default share the bulk of the 453 parameters in the cryptographic context. Thus, retrieving the crypto 454 context parameters for an SRTCP stream in practice may imply a 455 binding to the correspondent SRTP crypto context. It is up to the 456 implementation to assure such binding, since the RTCP port may not 457 be directly deducible from the RTP port only. Alternatively, the key 458 management may choose to provide separate SRTP- and SRTCP-contexts, 459 duplicating the common parameters (such as master key(s)). The 460 latter approach then also enables SRTP and SRTCP to use, e.g., 461 distinct transforms, if so desired. Similar considerations arise 462 when multiple SRTP streams, forming part of one single RTP session, 463 share keys and other parameters. 465 If no valid context can be found for a packet corresponding to a 466 certain context identifier, that packet MUST be discarded from 467 further SRTP processing. 469 3.3 SRTP Packet Processing 471 The following applies to SRTP. SRTCP is described in Section 3.4. 473 Assuming initialization of the cryptographic context(s) has taken 474 place via key management, the sender SHALL do the following to 475 construct an SRTP packet: 477 1. Determine which cryptographic context to use as described in 478 Section 3.2.3. 480 2. Determine the index of the SRTP packet using the rollover 481 counter, the highest sequence number in the cryptographic context, 482 and the sequence number in the RTP packet, as described in Section 483 3.3.1. 485 3. Determine the master key and master salt. This is done using the 486 index determined in the previous step or the current MKI in the 487 cryptographic context, according to Section 8.1. 489 4. Determine the session keys and session salt (if they are used by 490 the transform) as described in Section 4.3, using master key, master 491 salt, key_derivation_rate, and session key-lengths in the 492 cryptographic context with the index, determined in Steps 2 and 3. 494 5. Encrypt the RTP payload to produce the Encrypted Portion of the 495 packet (see Section 4.1, for the defined ciphers). This step uses 496 the encryption algorithm indicated in the cryptographic context, the 497 session encryption key and the session salt (if used) found in Step 498 4 together with the index found in Step 2. 500 6. If the MKI indicator is set to one, append the MKI to the packet. 502 7. For message authentication, compute the authentication tag for 503 the Authenticated Portion of the packet, as described in Section 504 4.2. This step uses the current rollover counter, the authentication 505 algorithm indicated in the cryptographic context, and the session 506 authentication key found in Step 4. Append the authentication tag to 507 the packet. 509 8. If necessary, update the ROC as in Section 3.3.1, using the 510 packet index determined in Step 2. 512 To authenticate and decrypt an SRTP packet, the receiver SHALL do 513 the following: 515 1. Determine which cryptographic context to use as described in 516 Section 3.2.3. 518 2. Run the algorithm in Section 3.3.1 to get the index of the SRTP 519 packet. The algorithm uses the rollover counter and highest 520 sequence number in the cryptographic context with the sequence 521 number in the SRTP packet, as described in Section 3.3.1. 523 3. Determine the master key and master salt. If the MKI indicator in 524 the context is set to one, use the MKI in the SRTP packet, otherwise 525 use the index from the previous step, according to Section 8.1. 527 4. Determine the session keys, and session salt (if used by the 528 transform) as described in Section 4.3, using master key, master 529 salt, key_derivation_rate and session key-lengths in the 530 cryptographic context with the index, determined in Steps 2 and 3. 532 5. For message authentication and replay protection, first check if 533 the packet has been replayed (Section 3.3.2), using the Replay List 534 and the index as determined in Step 2. If the packet is judged to be 535 replayed, then the packet MUST be discarded, and the event SHOULD be 536 logged. 538 Next, perform verification of the authentication tag, using the 539 rollover counter from Step 2, the authentication algorithm indicated 540 in the cryptographic context, and the session authentication key 541 from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 542 4.2), the packet MUST be discarded from further processing and the 543 event SHOULD be logged. 545 6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for 546 the defined ciphers), using the decryption algorithm indicated in 547 the cryptographic context, the session encryption key and salt (if 548 used) found in Step 4 with the index from Step 2. 550 7. Update the rollover counter and highest sequence number, s_l, in 551 the cryptographic context as in Section 3.3.1, using the packet 552 index estimated in Step 2. If replay protection is provided, also 553 update the Replay List as described in Section 3.3.2. 555 8. When present, remove the MKI and authentication tag fields from 556 the packet. 558 3.3.1 Packet Index Determination, and ROC, s_l Update 559 SRTP implementations use an "implicit" packet index for sequencing, 560 i.e., not all of the index is explicitly carried in the SRTP packet. 561 For the pre-defined transforms, the index i is used in replay 562 protection (Section 3.3.2), encryption (Section 4.1), message 563 authentication (Section 4.2), and for the key derivation (Section 564 4.3). 566 When the session starts, the sender side MUST set the rollover 567 counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps 568 modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 569 (see security aspects below). The sender's packet index is then 570 defined as 572 i = 2^16 * ROC + SEQ. 574 Receiver-side implementations use the RTP sequence number to 575 determine the correct index of a packet, which is the location of 576 the packet in the sequence of all SRTP packets. A robust approach 577 for the proper use of a rollover counter requires its handling and 578 use to be well defined. In particular, out-of-order RTP packets with 579 sequence numbers close to 2^16 or zero must be properly handled. 581 The index estimate is based on the receiver's locally maintained ROC 582 and s_l values. At the setup of the session, the ROC MUST be set to 583 zero. Receivers joining an on-going session MUST be given the current 584 ROC value using out-of-band signaling such as key-management 585 signaling. Furthermore, the receiver SHALL initialize s_l to the RTP 586 sequence number (SEQ) of the first observed SRTP packet (unless the 587 initial value is provided by out of band signaling such as key 588 management). 590 On consecutive SRTP packets, the receiver SHOULD estimate the index 591 as 592 i = 2^16 * v + SEQ, 594 where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) 595 such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC 596 + s_l (see Appendix A for pseudocode). 598 After the packet has been processed and authenticated (when enabled 599 for SRTP packets for the session), the receiver MUST use v to 600 conditionally update its s_l and ROC variables as follows. If 601 v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, 602 then s_l is set to SEQ if and only if SEQ is larger; there is no 603 change to ROC. If v=(ROC+1) mod 2^32, then s_l is set to SEQ and ROC 604 is set to v. 606 After a re-keying occurs (changing to a new master key), the 607 rollover counter always maintains its sequence of values, i.e., it 608 MUST NOT be reset to zero. 610 As the rollover counter is 32 bits long and the sequence number is 611 16 bits long, the maximum number of packets belonging to a given 612 SRTP stream that can be secured with the same key is 2^48 using the 613 pre-defined transforms. After that number of SRTP packets have been 614 sent with a given (master or session) key, the sender MUST NOT send 615 any more packets with that key. (There exists a similar limit for 616 SRTCP, which in practice may be more restrictive, see Section 9.2.) 617 This limitation enforces a security benefit by providing an upper 618 bound on the amount of traffic that can pass before cryptographic 619 keys are changed. Re-keying (see Section 8.1) MUST be triggered, 620 before this amount of traffic, and MAY be triggered earlier, e.g., 621 for increased security and access control to media. Recurring key 622 derivation by means of a non-zero key_derivation_rate (see Section 623 4.3), also gives stronger security but does not change the above 624 absolute maximum value. 626 On the receiver side, there is a caveat to updating s_l and ROC: if 627 message authentication is not present, neither the initialization of 628 s_l, nor the ROC update can be made completely robust. The 629 receiver's "implicit index" approach works for the pre-defined 630 transforms as long as the reorder and loss of the packets are not 631 too great and bit-errors do not occur in unfortunate ways. In 632 particular, 2^15 packets would need to be lost, or a packet would 633 need to be 2^15 packets out of sequence before synchronization is 634 lost. Such drastic loss or reorder is likely to disrupt the RTP 635 application itself. 637 The algorithm for the index estimate and ROC update is a matter of 638 implementation, and should take into consideration the environment 639 (e.g., packet loss rate) and the cases when synchronization is 640 likely to be lost, e.g. when the initial sequence number (randomly 641 chosen by RTP) is not known in advance (not sent in the key 642 management protocol) but may be near to wrap modulo 2^16. 644 A more elaborate and more robust scheme than the one given above is 645 the handling of RTP's own "rollover counter", see Appendix A.1 of 646 [RTPNEW]. 648 3.3.2 Replay Protection 650 Secure replay protection is only possible when integrity protection 651 is present. It is RECOMMENDED to use replay protection, both for RTP 652 and RTCP, as integrity protection alone cannot assure security 653 against replay attacks. 655 A packet is "replayed" when it is stored by an adversary, and then 656 re-injected into the network. When message authentication is 657 provided, SRTP protects against such attacks through a "Replay 658 List". Each SRTP receiver maintains a Replay List, which 659 conceptually contains the indices of all of the packets which have 660 been received and authenticated. In practice, the list can use a 661 "sliding window" approach, so that a fixed amount of storage 662 suffices for replay protection. Packet indices which lag behind the 663 packet index in the context by more than SRTP-WINDOW-SIZE can be 664 assumed to have been received, where SRTP-WINDOW-SIZE is a receiver- 665 side, implementation-dependent parameter and MUST be at least 64, 666 but which MAY be set to a higher value. 668 The receiver checks the index of an incoming packet against the 669 replay list and the window. Only packets with index ahead of the 670 window, or, inside the window but not already received, SHALL be 671 accepted. 673 After the packet has been authenticated (if necessary the window is 674 first moved ahead), the replay list SHALL be updated with the new 675 index. 677 The Replay List can be efficiently implemented by using a bitmap to 678 represent which packets have been received, as described in the 679 Security Architecture for IP [RFC2401]. 681 3.4 Secure RTCP 683 Secure RTCP follows the definition of Secure RTP. SRTCP adds three 684 mandatory new fields (the SRTCP index, an "encrypt-flag", and the 685 authentication tag) and one optional field (the MKI) to the RTCP 686 packet definition. The three mandatory fields MUST be appended to an 687 RTCP packet in order to form an equivalent SRTCP packet. The added 688 fields follow any other profile-specific extensions. 690 According to Section 6.1 of [RTPNEW], there is a REQUIRED packet 691 format for compound packets. SRTCP MUST be given packets according 692 to that requirement in the sense that the first part MUST be a 693 sender report or a receiver report. However, the RTCP encryption 694 prefix (a random 32-bit quantity) specified in that Section MUST NOT 695 be used since, as is stated there, it is only applicable to the 696 encryption method specified in [RTPNEW] and is not needed by the 697 cryptographic mechanisms used in SRTP. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 702 |V=2|P| RC | PT=SR or RR | length | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 704 | SSRC of sender | | 705 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 706 | ~ sender info ~ | 707 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 708 | ~ report block 1 ~ | 709 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 710 | ~ report block 2 ~ | 711 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 712 | ~ ... ~ | 713 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 714 | |V=2|P| SC | PT=SDES=202 | length | | 715 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 716 | | SSRC/CSRC_1 | | 717 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 718 | ~ SDES items ~ | 719 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 720 | ~ ... ~ | 721 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 722 | |E| SRTCP index | | 723 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 724 | ~ SRTCP MKI (OPTIONAL) ~ | 725 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 726 | : authentication tag : | 727 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 728 | | 729 +-- Encrypted Portion Authenticated Portion -----+ 731 Figure 2. An example of the format of a Secure RTCP packet, 732 consisting of an underlying RTCP compound packet with a Sender 733 Report and SDES packet. 735 The Encrypted Portion of an SRTCP packet consists of the encryption 736 (Section 4.1) of the RTCP payload of the equivalent compound RTCP 737 packet, from the first RTCP packet, i.e., from the ninth (9) octet 738 to the end of the compound packet. The Authenticated Portion of an 739 SRTCP packet consists of the entire equivalent (eventually compound) 740 RTCP packet, the E flag, and the SRTCP index (after any encryption 741 has been applied to the payload). 743 The added fields are: 745 E-flag: 1 bit, REQUIRED 746 The E-flag indicates if the current SRTCP packet is encrypted 747 or unencrypted. Section 9.1 of [RTPNEW] allows the split of a 748 compound RTCP packet into two lower-layer packets, one to be 749 encrypted and one to be sent in the clear. The E bit set to 750 "1" indicates encrypted packet, and "0" indicates non- 751 encrypted packet. 753 SRTCP index: 31 bits, REQUIRED 754 The SRTCP index is a 31-bit counter for the SRTCP packet. The 755 index is explicitly included in each packet, in contrast to 756 the "implicit" index approach used for SRTP. The SRTCP index 757 MUST be set to zero before the first SRTCP packet is sent, 758 and MUST be incremented by one, modulo 2^31, after each SRTCP 759 packet is sent. In particular, after a re-key, the SRTCP 760 index MUST NOT be reset to zero again (Section 3.3.1). 762 Authentication Tag: configurable length, REQUIRED 763 The authentication tag is used to carry message 764 authentication data. 766 MKI: configurable length, OPTIONAL 767 The MKI is the Master Key Indicator, and functions according 768 to the MKI definition in Section 3. 770 SRTCP uses the cryptographic context parameters and packet 771 processing of SRTP by default, with the following changes: 773 * The receiver does not need to "estimate" the index, as it is 774 explicitly signaled in the packet. 776 * Pre-defined SRTCP encryption is as specified in Section 4.1, but 777 using the definition of the SRTCP Encrypted Portion given in this 778 section, and using the SRTCP index as the index i. The encryption 779 transform and related parameters SHALL by default be the same 780 selected for the protection of the associated SRTP stream(s), while 781 the NULL algorithm SHALL be applied to the RTCP packets not to be 782 encrypted. SRTCP may have a different encryption transform than the 783 one used by the corresponding SRTP. The expected use for this 784 feature is when the former has NULL-encryption and the latter has a 785 non NULL-encryption. 787 The E-flag is assigned a value by the sender depending on whether 788 the packet was encrypted or not. 790 * SRTCP decryption is performed as in Section 4, but only if the E 791 flag is equal to 1. If so, the Encrypted Portion is decrypted, using 792 the SRTCP index as the index i. In case the E-flag is 0, the payload 793 is simply left unmodified. 795 * SRTCP replay protection is as defined in Section 3.3.2, but using 796 the SRTCP index as the index i and a separate replay list that is 797 specific to SRTCP. 799 * The pre-defined SRTCP authentication tag is specified as in 800 Section 4.2, but with the Authenticated Portion of the SRTCP packet 801 given in this section (which includes the index). The authentication 802 transform and related parameters (e.g., key size) SHALL by default 803 be the same as selected for the protection of the associated SRTP 804 stream(s)). 806 * In the last step of the processing, only the sender needs to 807 update the value of the SRTCP index by incrementing it modulo 2^31 808 and for security reasons the sender MUST also check the number of 809 SRTCP packets processed, see Section 9.2. 811 Message authentication for RTCP is REQUIRED, as it is the control 812 protocol (e.g., it has a BYE packet) for RTP. 814 Precautions must be taken so that the packet expansion in SRTCP (due 815 to the added fields) does not cause SRTCP messages to use more than 816 their share of RTCP bandwidth. To avoid this, the following two 817 measures MUST be taken: 819 1. When initializing the RTCP variable "avg_rtcp_size" defined in 820 chapter 6.3 of [RTPNEW], it MUST include the size of the fields that 821 will be added by SRTCP (index, E-bit, authentication tag, and when 822 present, the MKI). 824 2. When updating the "avg_rtcp_size" using the variable packet_size" 825 (section 6.3.3 of [RTPNEW]), the value of "packet_size" MUST include 826 the size of the additional fields added by SRTCP. 828 With these measures in place the SRTCP messages will not use more 829 than the allotted bandwidth. The effect of the size of the added 830 fields on the SRTCP traffic will be that messages will be sent with 831 longer packet intervals. The increase in the intervals will be 832 directly proportional to size of the added fields. For the pre- 833 defined transforms, the size of the added fields will be at least 14 834 octets, and upper bounded depending on MKI and the authentication 835 tag sizes. 837 4. Pre-Defined Cryptographic Transforms 839 While there are numerous encryption and message authentication 840 algorithms that can be used in SRTP, we define below default 841 algorithms in order to avoid the complexity of specifying the 842 encodings for the signaling of algorithm and parameter identifiers. 843 The defined algorithms have been chosen as they fulfill the goals 844 listed in Section 2. Recommendations on how to extend SRTP with new 845 transforms are given in Section 6. 847 4.1 Encryption 849 The following parameters are common to both pre-defined, non-NULL, 850 encryption transforms specified in this section. 852 * BLOCK_CIPHER-MODE indicates the block cipher used and its mode of 853 operation 854 * n_b is the bit-size of the block for the block cipher 855 * k_e is the session encryption key 856 * n_e is the bit-length of k_e 857 * k_s is the session salting key 858 * n_s is the bit-length of k_s 859 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, an 860 non-negative integer, specified by the message authentication code 861 in use. 863 The distinct session keys and salts for SRTP/SRTCP are by default 864 derived as specified in Section 4.3. 866 The encryption transforms defined in SRTP map the SRTP packet index 867 and secret key into a pseudorandom keystream segment. Each keystream 868 segment encrypts a single RTP packet. The process of encrypting a 869 packet consists of generating the keystream segment corresponding to 870 the packet, and then bitwise exclusive-oring that keystream segment 871 onto the payload of the RTP packet to produce the Encrypted Portion 872 of the SRTP packet. Decryption is done the same way, but swapping 873 the roles of the plaintext and ciphertext. 875 +----+ +------------------+---------------------------------+ 876 | KG |-->| Keystream Prefix | Keystream Suffix |---+ 877 +----+ +------------------+---------------------------------+ | 878 | 879 +---------------------------------+ v 880 | Payload of RTP Packet |->(*) 881 +---------------------------------+ | 882 | 883 +---------------------------------+ | 884 | Encrypted Portion of SRTP Packet|<--+ 885 +---------------------------------+ 887 Figure 3: Default SRTP Encryption Processing. Here KG denotes the 888 keystream generator, and (*) denotes bitwise exclusive-or. 890 The definition of how the keystream is generated, given the index, 891 depends on the cipher and its mode of operation. Below, two such 892 keystream generators are defined. The NULL cipher is also defined, 893 to be used when encryption of RTP is not required. 895 The SRTP definition of the keystream is illustrated in Figure 3. The 896 initial octets of each keystream segment MAY be reserved for use in 897 a message authentication code, in which case the keystream used for 898 encryption starts immediately after the last reserved octet. The 899 initial reserved octets are called the "keystream prefix" (not to be 900 confused with the "encryption prefix" of [RTPNEW, Section 6.1]), and 901 the remaining octets are called the "keystream suffix". The 902 keystream prefix MUST NOT be used for encryption. The process is 903 illustrated in Figure 3. 905 The number of octets in the keystream prefix is denoted as 906 SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, 907 non-zero value of SRTP_PREFIX_LENGTH. This means that, even if 908 confidentiality is not to be provided, the keystream generator 909 output may still need to be computed for packet authentication, in 910 which case the default keystream generator (mode) SHALL be used. 912 The default cipher is the Advanced Encryption Standard (AES), and we 913 define two modes of running AES, (1) Segmented Integer Counter Mode 914 AES and (2) AES in f8-mode. In the remainder of this section, let 915 E(k,x) be AES applied to key k and input block x. 917 4.1.1 AES in Counter Mode 919 Conceptually, counter mode [AES-CTR] consists of encrypting 920 successive integers. The actual definition is somewhat more 921 complicated, in order to randomize the starting point of the integer 922 sequence. Each packet is encrypted with a distinct keystream 923 segment, which SHALL be computed as follows. 925 A keystream segment SHALL be the concatenation of the 128-bit output 926 blocks of the AES cipher in the encrypt direction, using key k = 927 k_e, in which the block indices are in increasing order. 928 Symbolically, each keystream segment looks like 930 E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ... 932 where the 128-bit integer value IV SHALL be defined by the SSRC, the 933 SRTP packet index i, and the SRTP session salting key k_s, as below. 935 IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16) 937 Each of the three terms in the XOR-sum above is padded with as many 938 leading zeros as needed to make the operation well-defined, 939 considered as a 128-bit value. 941 The inclusion of the SSRC allows the use of the same key to protect 942 distinct SRTP streams within the same RTP session, see the security 943 caveats in Section 9.1. 945 In the case of SRTCP, the SSRC of the first header of the compound 946 packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s 947 SHALL be replaced by the SRTCP session key and salt. 949 Note that the initial value, IV, is fixed for each packet and is 950 formed by "reserving" 16 zeros in the least significant bits for the 951 purpose of the counter. The number of blocks of keystream generated 952 for any fixed value of IV MUST NOT exceed 2^16 to avoid key stream 953 re-use, see below. The AES has a block size of 128 bits, so 2^16 954 output blocks are sufficient to generate the 2^23 bits of keystream 955 needed to encrypt the largest possible RTP packet (except for IPv6 956 "jumbograms" [RFC2675], which are not likely to be used for RTP- 957 based multimedia traffic). This restriction on the maximum bit-size 958 of the packet that can be encrypted ensures the security of the 959 encryption method by limiting the effectiveness of probabilistic 960 attacks [BDJR]. 962 For a fixed Counter Mode key, each IV value used as an input MUST be 963 distinct, in order to avoid the security exposure of a two-time pad 964 situation (Section 9.1). To satisfy this constraint, an 965 implementation MUST ensure that the values of the SRTP packet index 966 of ROC || SEQ, and the SSRC used in the construction of the IV are 967 distinct for any fixed key. The failure to ensure this uniqueness 968 could be catastrophic for Secure RTP. This is in contrast to the 969 situation for RTP itself, which may be able to tolerate such 970 failures. It is RECOMMENDED that, if a dedicated security module is 971 present, the RTP sequence numbers and SSRC either be generated or 972 checked by that module (i.e., sequence-number and SSRC processing in 973 an SRTP system needs to be protected as well as the key). 975 4.1.2 AES in f8-mode 977 To encrypt UMTS (Universal Mobile Telecommunications System, as 3G 978 networks) data, a solution (see [f8-a], [f8-b]) known as the f8- 979 algorithm has been developed. On a high level, the proposed scheme 980 is a variant of Output Feedback Mode (OFB) [HAC], with a more 981 elaborate initialization and feedback function. As in normal OFB, 982 the core consists of a block cipher. We also define here the use of 983 AES as a block cipher to be used in what we shall call "f8-mode of 984 operation" RTP encryption. The AES f8-mode SHALL use the same 985 default sizes for session key and salt as AES counter mode. 987 Figure 4 shows the structure of block cipher, E, running in f8-mode. 989 IV 990 | 991 v 992 +------+ 993 | | 994 +--->| E | 995 | | | 996 | +------+ 997 | | 998 m -> (*) +-----------+-------------+-- ... ------+ 999 | IV' | | | | 1000 | | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*) 1001 | | | | | 1002 | | +-> (*) +-> (*) ... +-> (*) 1003 | | | | | | | | 1004 | v | v | v | v 1005 | +------+ | +------+ | +------+ | +------+ 1006 | | | | | | | | | | | | 1007 k_e ---+--->| E | | | E | | | E | | | E | 1008 | | | | | | | | | | | 1009 +------+ | +------+ | +------+ | +------+ 1010 | | | | | | | 1011 +------+ +--------+ +-- ... ----+ | 1012 | | | | 1013 v v v v 1014 S(0) S(1) S(2) . . . S(L-1) 1016 Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). 1017 The figure represents the KG in Figure 3, when AES-f8 is used. 1019 4.1.2.1 f8 Keystream Generation 1021 The Initialization Vector (IV) SHALL be determined as described in 1022 Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP). 1024 Let IV', S(j), and m denote n_b-bit blocks. The keystream, S(0) || 1025 ... || S(L-1), for an N-bit message SHALL be defined by setting IV' 1026 = E(k_e XOR m, IV), and S(-1) = 00..0. For j = 0,1,..,L-1 where L = 1027 N/n_b (rounded up to nearest integer) compute 1029 S(j) = E(k_e, IV' XOR j XOR S(j-1)) 1031 Notice that the IV is not used directly. Instead it is fed through E 1032 under another key to produce an internal, "masked" value (denoted 1033 IV') to prevent an attacker from gaining known input/output pairs. 1034 The role of the internal counter, j, is to prevent short keystream 1035 cycles. The value of the key mask m SHALL be 1037 m = k_s || 0x555..5, 1039 i.e. the session salting key, appended by the binary pattern 0101.. 1040 to fill out the entire desired key size, n_e. 1042 The sender SHOULD NOT generate more than 2^32 blocks, which is 1043 sufficient to generate 2^39 bits of keystream. Unlike counter mode, 1044 there is no absolute threshold above (below) which f8 is guaranteed 1045 to be insecure (secure). The above bound has been chosen to limit, 1046 with sufficient security margin, the probability of degenerative 1047 behavior in the f8 keystream generation. 1049 4.1.2.2 f8 SRTP IV Formation 1051 The purpose of the following IV formation is to provide a feature 1052 which we call implicit header authentication (IHA), see Section 9.5. 1054 The SRTP IV for 128-bit block AES-f8 SHALL be formed in the 1055 following way: 1057 IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC 1059 M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from 1060 the cryptographic context. 1062 The presence of the SSRC as part of the IV allows AES-f8 to be used 1063 when a master key is shared between multiple streams within the same 1064 RTP session, see Section 9.1. 1066 4.1.2.3 f8 SRTCP IV Formation 1068 The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the 1069 following way: 1071 IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC 1073 where V, P, RC, PT, length, SSRC SHALL be taken from the first 1074 header in the RTCP compound packet. E and SRTCP index are the 1-bit 1075 and 31-bit fields added to the packet. 1077 4.1.3 NULL Cipher 1078 The NULL cipher is used when no confidentiality for RTP/RTCP is 1079 requested. The keystream can be thought of as "000..0", i.e. the 1080 encryption SHALL simply copy the plaintext input into the ciphertext 1081 output. 1083 4.2 Message Authentication and Integrity 1085 Throughout this section, M will denote data to be integrity 1086 protected. In the case of SRTP, M SHALL consist of the Authenticated 1087 Portion of the packet (as specified in Figure 1) concatenated with 1088 the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M 1089 SHALL consist of the Authenticated Portion (as specified in Figure 1090 2) only. 1092 Common parameters: 1094 * AUTH_ALG is the authentication algorithm 1095 * k_a is the session message authentication key 1096 * n_a is the bit-length of the authentication key 1097 * n_tag is the bit-length of the output authentication tag 1098 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as 1099 defined above, a parameter of AUTH_ALG 1101 The distinct session authentication keys for SRTP/SRTCP are by 1102 default derived as specified in Section 4.3. 1104 The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for 1105 any particular fixed value of the key. 1107 We describe the process of computing authentication tags as follows. 1108 The sender computes the tag of M and appends it to the packet. The 1109 SRTP receiver verifies a message/authentication tag pair by 1110 computing a new authentication tag over M using the selected 1111 algorithm and key, and then compares it to the tag associated with 1112 the received message. If the two tags are equal, then the 1113 message/tag pair is valid; otherwise, it is invalid and the error 1114 audit message "AUTHENTICATION FAILURE" MUST be returned. 1116 4.2.1 HMAC-SHA1 1118 The pre-defined authentication transform for SRTP is HMAC-SHA1 1119 [RFC2104]. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL 1120 be 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to 1121 the session authentication key and M as specified above, i.e. 1122 HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag 1123 left-most bits. 1125 4.3 Key Derivation 1127 4.3.1 Key Derivation Algorithm 1129 Regardless of the encryption or message authentication transform 1130 that is employed (it may be an SRTP pre-defined transform or newly 1131 introduced according to Section 6), interoperable SRTP 1132 implementations MUST use the SRTP key derivation to generate session 1133 keys. Once the key derivation rate is properly signaled at the start 1134 of the session, there is no need for extra communication between the 1135 parties that use SRTP key derivation. 1137 packet index ---+ 1138 | 1139 v 1140 +-----------+ master +--------+ session encr_key 1141 | ext | key | |----------> 1142 | key mgmt |-------->| key | session auth_key 1143 | (optional | | deriv |----------> 1144 | rekey) |-------->| | session salt_key 1145 | | master | |----------> 1146 +-----------+ salt +--------+ 1148 Figure 5: SRTP key derivation. 1150 At least one initial key derivation SHALL be performed by SRTP, 1151 i.e., the first key derivation is REQUIRED. Further applications of 1152 the key derivation MAY be performed, according to the 1153 "key_derivation_rate" value in the cryptographic context. The key 1154 derivation function SHALL be initially invoked before the first 1155 packet and then, if derivation rate is r > 0, further invoked on 1156 every r-th packet, and produce session keys according to the non- 1157 zero key derivation rate. This can be thought of as "refreshing" the 1158 session keys. The value of "key_derivation_rate" MUST be kept fixed 1159 for the lifetime of the associated master key. 1161 Interoperable SRTP implementations MAY also derive session salting 1162 keys for encryption transforms, as is done in both of the pre- 1163 defined transforms. 1165 Let m and n be positive integers. A pseudo-random function family is 1166 a set of keyed functions {PRF_n(k,x)} such that for the (secret) 1167 random key k, given m-bit x, PRF_n(k,x) is an n-bit string, 1168 computationally indistinguishable from random n-bit strings, see 1169 [HAC]. For the purpose of key derivation in SRTP, a secure PRF with 1170 m = 128 (or more) MUST be used, and a default PRF transform is 1171 defined in Section 4.3.3. 1173 Let "a DIV t" denote integer division of a by t, rounded down, and 1174 with the convention that "a DIV 0 = 0" for all a. We also make the 1175 convention of treating "a DIV t" as a bit string of the same length 1176 as a, and thus "a DIV t" will in general have leading zeros. 1178 Key derivation SHALL be defined as follows in terms of