idnits 2.17.1 draft-ietf-avt-srtp-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1859 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 (June 2002) is 7958 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 1963, but no explicit reference was found in the text == Unused Reference: 'HMAC' is defined on line 1966, 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: 7 errors (**), 0 flaws (~~), 6 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: December 2002 Norrman (Ericsson) 6 June 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 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..............................9 49 3.2.3 Mapping SRTP Packets to Cryptographic Contexts.............10 50 3.3 SRTP Packet Processing.........................................10 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.....................................................18 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...........................23 60 4.2.1. HMAC-SHA1.................................................24 61 4.3 Key Derivation.................................................24 62 4.3.1 Key Derivation Algorithm...................................24 63 4.3.2 SRTCP Key Derivation.......................................26 64 4.3.3 AES-CM PRF.................................................26 65 5. Default and mandatory-to-implement Transforms....................27 66 5.1 Encryption: AES-CM and NULL....................................27 67 5.2 Message Authentication/Integrity: HMAC-SHA1....................27 68 5.3 Key Derivation: AES-CM PRF.....................................27 69 6. Adding SRTP Transforms...........................................27 70 7. Rationale........................................................28 71 7.1 Key derivation.................................................28 72 7.2 Salting key....................................................29 73 7.3 Message Integrity from Universal Hashing.......................29 74 7.4 Data Origin Authentication Considerations......................29 75 8. Key Management Considerations....................................30 76 8.1. Re-keying.....................................................31 77 8.2. Key Management parameters.....................................32 78 9. Security Considerations..........................................33 79 9.1 SSRC collision and two-time pad................................33 80 9.2 Key Usage......................................................34 81 9.3 Confidentiality of the RTP Payload.............................35 82 9.4 Confidentiality of the RTP Header..............................36 83 9.5 Integrity of the RTP payload and header........................36 84 10. Interaction with Forward Error Correction mechanisms............37 85 11. Scenarios.......................................................37 86 11.1 Unicast.......................................................37 87 11.2 Multicast.....................................................38 88 11.2.1 Small multicast with one sender...........................38 89 11.2.2 Large multicast with one sender...........................39 90 11.3 Re-keying and access control..................................40 91 11.4 Summary of basic scenarios....................................40 92 12. IANA Considerations.............................................41 93 13. Acknowledgements................................................41 94 14. Author's Addresses..............................................42 95 15. References......................................................42 96 Appendix A: Pseudocode for Index Determination......................45 97 Appendix B: Test Vectors............................................45 98 B.1 AES-f8 Test Vectors............................................45 99 B.2 AES-CM Test Vectors............................................46 100 B.3 Key Derivation Test Vectors....................................47 102 1. Introduction 104 This document describes the Secure Real-time Transport Protocol 105 (SRTP), a profile of the Real-time Transport Protocol (RTP), which 106 can provide confidentiality, message authentication, and replay 107 protection to the RTP/RTCP traffic. 109 SRTP provides a framework for encryption and message authentication 110 of RTP and RTCP streams (Section 3). SRTP defines a set of default 111 cryptographic transforms (Sections 4 and 5), and it allows new 112 transforms to be introduced in the future (Section 6). With 113 appropriate key management (Sections 7 and 8), SRTP is secure 114 (Sections 9 and 10) for unicast and multicast RTP applications 115 (Section 11). 117 SRTP can achieve high throughput and low packet expansion. SRTP 118 proves to be a suitable protection for heterogeneous environments. 119 To get such features, default transforms are described, based on an 120 additive stream cipher for encryption, a keyed-hash based function 121 for message authentication, and an "implicit" index for 122 sequencing/synchronization based on the RTP sequence number for SRTP 123 and an index number for Secure RTCP (SRTCP). 125 1.1. Notational Conventions 127 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 130 The terminology conforms to [RFC2828]. 132 By convention, the adopted representation is the network byte order, 133 i.e. the left most bit (octet) is the most significant one. By XOR 134 we mean bitwise addition modulo 2 of binary strings, and || denotes 135 concatenation. In other words, if C = A || B, then the most 136 significant bits of C are the bits of A, and the least significant 137 bits of C equal the bits of B. Hexadecimal numbers are prefixed by 138 0x. 140 The word "encryption" includes also use of the NULL algorithm (which 141 in practice does leave the data in the clear). 143 With slight abuse of notation, we use the terms "message 144 authentication" and "authentication tag" as is common practice even 145 though in some circumstances, e.g. group communication, the service 146 provided is actually only integrity protection and not data origin 147 authentication. 149 2. Goals and Features 151 The security goals for SRTP are to ensure: 153 * the confidentiality of the RTP and RTCP payloads, and 155 * the integrity of the entire RTP and RTCP packets, together with 156 protection against replayed packets. 158 These security services are optional and independent from each 159 other, except that SRTCP integrity protection is mandatory 160 (malicious or erroneous alteration of RTCP messages could disrupt 161 the processing of the RTP stream). 163 Other, functional, goals for the protocol are: 165 * a framework that permits upgrading with new cryptographic 166 transforms, 168 * low bandwidth cost, i.e., a framework preserving RTP header 169 compression efficiency, 171 and, asserted by the pre-defined transforms: 173 * a low computational cost, 175 * a small footprint (i.e. small code size and data memory for keying 176 information and replay lists), 178 * limited packet expansion to support the bandwidth economy goal, 179 * independence from the underlying transport, network, and physical 180 layers used by RTP, in particular high tolerance to packet loss 181 and re-ordering, and robustness to transmission bit-errors in the 182 encrypted payload. 184 These properties ensure that SRTP is a suitable protection scheme 185 for RTP/RTCP in both wired and wireless scenarios. 187 2.1 Features 189 Besides the above mentioned direct goals, SRTP provides for some 190 additional features. They have been introduced to lighten the burden 191 on key management and to further increase security. They include: 193 * A single "master key" provides keying material for 194 confidentiality and integrity protection, both for the SRTP stream 195 and the corresponding SRTCP stream. This is achieved due to a key 196 derivation function (see Section 4.3), providing "session keys" 197 for the respective security primitive, securely derived from 198 the master key. Under additional SSRC uniqueness requirements, a 199 single master key can even protect several SRTP streams, see 200 Section 9.1. 202 * In addition, the key derivation can be configured to periodically 203 "refresh" the session keys, which limits the amount of ciphertext 204 produced by a fixed key, available for an adversary to 205 cryptanalyze. 207 * "Salting keys" are used to protect against pre-computation attacks 208 [MF00]. 210 Detailed rationale for these features can be found in Section 7. 212 3. SRTP Framework 214 RTP is the Real-time Transport Protocol [RFC1889]. We define SRTP as 215 a profile of RTP, in a way analogous to RFC1890 which defines the 216 audio/video profile for RTP. Conceptually, we consider it to be a 217 "bump in the stack" implementation which resides between the RTP 218 application and the transport layer. SRTP intercepts RTP packets and 219 then forwards an equivalent SRTP packet on the sending side, and 220 which intercepts SRTP packets and passes an equivalent RTP packet up 221 the stack on the receiving side. 223 Secure RTCP (SRTCP) provides the same security services to RTCP as 224 SRTP does to RTP. SRTCP message authentication is MANDATORY to 225 protect the RTCP messages and thereby protect the RTP session that 226 uses RTP fields to keep track of membership, provide feedback to RTP 227 senders, or maintain packet sequence counters. SRTCP is described 228 in Section 3.4. 230 3.1 Secure RTP 232 The format of an SRTP packet is illustrated in Figure 1. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 237 |V=2|P|X| CC |M| PT | sequence number | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 239 | timestamp | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 241 | synchronization source (SSRC) identifier | | 242 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 243 | contributing source (CSRC) identifiers | | 244 | .... | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 246 | RTP extension (OPTIONAL) | | 247 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 248 | | payload ... | | 249 | | +-------------------------------+ | 250 | | | RTP padding | RTP pad count | | 251 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 252 | ~ SRTP MKI (OPTIONAL) ~ | 253 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | ~ authentication tag (OPTIONAL) ~ | 255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 256 | | 257 +- Encrypted Portion* Authenticated Portion ---+ 259 Figure 1. The format of an SRTP packet. *Encrypted Portion is the 260 same size as the plaintext for the Section 4 pre-defined transforms. 262 The Encrypted Portion of an SRTP packet consists of the encryption 263 of the RTP payload (including RTP padding when present) of the 264 equivalent RTP packet. (Note: the "Encrypted Portion" MAY be the 265 exact size of the plaintext or MAY be larger. It is exact for the 266 pre-defined transforms and for NULL-encryption, which doesn't change 267 the payload in any way.) 269 The optional MKI and optional authentication tag are the only fields 270 defined by SRTP that are not in RTP. Only 8-bit alignment is 271 assumed. 273 MKI (Master Key Identifier): variable length, OPTIONAL 274 The MKI is defined, signaled, and used by key management. 275 The MKI identifies the master key from which the session 276 key(s) were derived that authenticate and/or encrypt the 277 particular packet. Note that the MKI SHALL NOT identify the 278 SRTP cryptographic context, which is identified according to 279 Section 3.2.3. The MKI MAY be used by key management for the 280 purposes of re-keying, identifying a particular master key 281 within the cryptographic context (Section 3.2.1). 283 Authentication tag: variable length, OPTIONAL 284 The authentication tag is used to carry message 285 authentication data. The Authenticated Portion of an SRTP 286 packet consists of the RTP header followed by the Encrypted 287 Portion of the SRTP packet. Thus, note that if both 288 encryption and authentication are applied, encryption SHALL 289 be applied before authentication on the sender side and 290 conversely on the receiver side. The authentication tag 291 provides authentication of the RTP header and payload, and it 292 indirectly provides replay protection by authenticating the 293 sequence number. Note that the MKI is not integrity protected 294 as this does not provide any extra protection. 296 3.2 SRTP Cryptographic Contexts 298 Each SRTP stream requires the sender and receiver to maintain 299 cryptographic state information. This information is called the 300 "cryptographic context". 302 SRTP uses two types of keys: session keys and master keys. By a 303 "session key", we mean a key which is used directly in a 304 cryptographic transform (e.g. encryption or message authentication), 305 and by a "master key", we mean a random bit string (given by the key 306 management protocol) from which session keys are derived in a 307 cryptographically secure way. 309 3.2.1 Transform-independent parameters 311 "Transform-independent parameters" are present in the cryptographic 312 context independently of the particular encryption or authentication 313 transforms that are used. The transform-independent parameters of 314 the cryptographic context for SRTP consist of: 316 * a 32-bit unsigned rollover counter (ROC), which records how many 317 times the 16-bit RTP sequence number has been reset to zero after 318 passing through 65,535. Unlike the sequence number (SEQ), which 319 SRTP extracts from the RTP packet header, the ROC is maintained by 320 SRTP as described in Section 3.3.1. 322 We define the index of the SRTP packet corresponding to a given 323 ROC and RTP sequence number to be the 48-bit quantity 325 i = 2^16 * ROC + SEQ. 327 * for the receiver only, a 16-bit sequence number s_l, which is the 328 highest received RTP sequence number (possibly authenticated, if 329 message authentication is provided), 331 * an identifier for the encryption algorithm, i.e., the cipher and 332 its mode of operation, 334 * an identifier for the message authentication algorithm (when 335 authentication is provided), 337 * a replay list, maintained by the receiver only (when 338 authentication and replay protection are provided), containing 339 indices of recently received and authenticated SRTP packets, 341 * an MKI indicator (0/1) as to whether an MKI is present in SRTP and 342 SRTCP packets, 344 * if the MKI indicator is set to one, the length (in octets) of the 345 MKI field, and (for the sender) the actual value of the currently 346 active MKI, (the value of the MKI indicator and length MUST be 347 kept fixed for the lifetime of the context), 349 * the master key(s), which MUST be random and kept secret, 351 * for each master key, there is a counter of the number of SRTP 352 packets that has been processed (sent) with that master key 353 (essential for security, see Sections 3.3.1 and 9), 355 * non-negative integers n_e, and n_a, determining the length of the 356 session keys for encryption, and message authentication. 358 In addition, for each master key, an SRTP stream MAY use the 359 following associated values: 361 * a master salt, to be used in the key derivation of session keys. 362 This value, when used, MUST be random, but MAY be public. Use of 363 master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" 364 salt is treated as 00...0. 366 * an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", 367 where an unspecified value is treated as zero. The constraint to 368 be a power of 2 simplifies the implementation, see Section 4.3. 370 * <"From", "To"> values, specifying the lifetime for a master key, 371 expressed in terms of the two 48-bit index values inside whose 372 range (including the range end-points) the master key is valid. 373 These values are absolute quantities, not relative. Whenever this 374 field is unspecified, the related master key is valid "from the 375 first observed packet" to "until further notice" (with maximum 376 lifetime as specified in Section 3.3.1). 378 SRTCP SHALL by default share the crypto context with SRTP and uses 379 the same cryptographic context parameters, except: 381 * no rollover counter and s_l-value need to be maintained as the 382 RTCP index is explicitly carried in each SRTCP packet, 384 * a separate replay list is maintained (when replay protection is 385 provided), 387 * SRTCP maintains a separate counter for its master key (even if the 388 master key is the same as that for SRTP, see below), as a mean to 389 maintain a count of the number of SRTCP packets that have been 390 processed with that key. 392 Note in particular that the master key(s) MAY be shared between SRTP 393 and SRTCP, if the pre-defined transforms (including the key 394 derivation) are used but the session key(s) MUST NOT be so shared. 396 In addition, there can be cases (see Sections 8 and 9.1) where 397 several SRTP streams, identified by their SSRCs, share most of the 398 crypto context parameters (including master keys). In such cases, 399 just as in the normal SRTP/SRTCP parameter sharing above, separate 400 replay lists and packet counters for each stream (SSRC) MUST still 401 be maintained, but the session keys MAY then be shared between SRTP 402 streams. 404 A summary of parameters, pre-defined transforms, and default values 405 for the above parameters (and other SRTP parameters) can be found in 406 Sections 5 and 8.2. 408 3.2.2 Transform-dependent parameters 410 All encryption, authentication/integrity, and key derivation 411 parameters are defined in the transforms section (Section 4). 412 Typical examples of such parameters are block size of ciphers, 413 session keys, data for IV formation, etc. Future SRTP transform 414 specifications MUST include a section to list the additional 415 cryptographic context's parameters for that transform, if any. 417 3.2.3 Mapping SRTP Packets to Cryptographic Contexts 419 Recall that an RTP session for each participant is defined [RFC1889] 420 by a pair of destination transport addresses (one network address 421 plus a port pair for RTP and RTCP), and that a multimedia session is 422 defined as a collection of RTP sessions. For example, a particular 423 multimedia session could include an audio RTP session, a video RTP 424 session, and a text RTP session. 426 A cryptographic context SHALL be uniquely identified by the triplet 427 context identifier: 429 context id = 432 where the destination network address and the destination transport 433 port are the ones in the current RTP packet (for the sender) or SRTP 434 packet (for the receiver). It is assumed that, when presented with 435 this information, the key management returns a context with the 436 information as described in Section 3.2. 438 As noted above, SRTP and SRTCP by default share the bulk of the 439 parameters in the cryptographic context. Thus, retrieving the crypto 440 context parameters for an SRTCP stream in practice may imply a 441 binding to the correspondent SRTP crypto context. It is up to the 442 implementation to assure such binding, since the RTCP port may not 443 be directly deducible from the RTP port only. Alternatively, the key 444 management may choose to provide separate SRTP- and SRTCP-contexts, 445 duplicating the common parameters (such as master key(s)). The 446 latter approach then also enables SRTP and SRTCP to use, e.g., 447 distinct transforms, if so desired. Similar considerations arise 448 when multiple SRTP streams share keys and other parameters. 450 If no valid context can be found for a packet corresponding to a 451 certain context identifier, that packet MUST be discarded from 452 further SRTP processing. 454 3.3 SRTP Packet Processing 456 The following applies to SRTP. SRTCP is described in Section 3.4. 458 Assuming initialization of the cryptographic context(s) has taken 459 place via key management, the sender SHALL do the following to 460 construct an SRTP packet: 462 1. Determine which cryptographic context to use as described in 463 Section 3.2.3. 465 2. Determine the index of the SRTP packet using the rollover counter 466 in the cryptographic context and the sequence number in the RTP 467 packet, as described in Section 3.3.1. 469 3. Determine the master key and master salt. This is done using the 470 index determined in the previous step or the current MKI in the 471 cryptographic context. 473 4. Determine the session keys and session salt (if they are used by 474 the transform) as described in Section 4.3, using master key, master 475 salt, key_derivation_rate, and session key-lengths in the 476 cryptographic context with the index, determined in Steps 2 and 3. 478 5. Encrypt the RTP payload to produce the Encrypted Portion of the 479 packet (see Section 4.1, for the defined ciphers). This step uses 480 the encryption algorithm indicated in the cryptographic context, the 481 session encryption key and the session salt (if used) found in Step 482 4 together with the index found in Step 2. 484 6. If the MKI indicator is set to one, append the MKI to the packet. 486 7. If message authentication is provided, compute the authentication 487 tag for the Authenticated Portion of the packet, as described in 488 Section 4.2. This step uses the current rollover counter, the 489 authentication algorithm indicated in the cryptographic context, and 490 the session authentication key found in Step 4. Append the 491 authentication tag to the packet. 493 8. If necessary, update the ROC as in Section 3.3.1, using the 494 packet index determined in Step 2. 496 To authenticate and decrypt an SRTP packet, the receiver SHALL do 497 the following: 499 1. Determine which cryptographic context to use as described in 500 Section 3.2.3. 502 2. Estimate the index of the SRTP packet using the rollover counter 503 and highest sequence number in the cryptographic context with the 504 sequence number in the SRTP packet, as described in Section 3.3.1. 506 3. Determine the master key and master salt. If the MKI indicator in 507 the context is set to one, use the MKI in the SRTP packet, otherwise 508 use the index from the previous step. 510 4. Determine the session keys, and session salt (if used by the 511 transform) as described in Section 4.3, using master key, master 512 salt, key_derivation_rate and session key-lengths in the 513 cryptographic context with the index, determined in Steps 2 and 3. 515 5. If message authentication and replay protection are provided, 516 first check if the packet has been replayed (Section 3.3.2), using 517 the Replay List and the index as determined in Step 2. If the packet 518 is judged to be replayed, then the packet MUST be discarded, and the 519 event SHOULD be logged. 521 Next, perform verification of the authentication tag, using the 522 rollover counter from Step 2, the authentication algorithm indicated 523 in the cryptographic context, and the session authentication key 524 from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 525 4.2), the packet MUST be discarded from further processing and the 526 event SHOULD be logged. 528 6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for 529 the defined ciphers), using the decryption algorithm indicated in 530 the cryptographic context, the session encryption key and salt (if 531 used) found in Step 4 with the index from Step 2. 533 7. Update the rollover counter and highest sequence number, s_l, in 534 the cryptographic context as in Section 3.3.1, using the packet 535 index estimated in Step 2. If replay protection is provided, also 536 update the Replay List as described in Section 3.3.2. 538 8. When present, remove the MKI and authentication tag fields from 539 the packet. 541 3.3.1 Packet Index Determination, and ROC, s_l Update 543 SRTP implementations use an "implicit" packet index for sequencing, 544 i.e., not all of the index is explicitly carried in the SRTP packet. 545 For the pre-defined transforms, the index i is used in replay 546 protection (Section 3.3.2), encryption (Section 4.1), message 547 authentication (Section 4.2), and for the key derivation (Section 548 4.3). The index MAY also be used to determine the correct master key 549 when <"From", "To"> values are used to represent key lifetime 550 (Section 3.2.1). 552 When the session starts, the sender side MUST set the rollover 553 counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps 554 modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 555 (see security aspects below). The sender's packet index is then 556 defined as 558 i = 2^16 * ROC + SEQ. 560 Receiver-side implementations use the RTP sequence number to estimate 561 the correct index of a packet, which is the location of the packet in 562 the sequence of all SRTP packets. A robust approach for the proper 563 use of a rollover counter requires its handling and use to be well 564 defined. In particular, out-of-order RTP packets with sequence 565 numbers close to 2^16 or zero must be properly handled. 567 The index estimate is based on the receiver's locally maintained ROC 568 and s_l values. At the setup of the session, ROC MUST be set to zero. 569 Receivers joining an on-going session MUST be given the current ROC 570 value using out of band signaling. Furthermore, the receiver SHALL 571 initialize s_l to the RTP sequence number (SEQ) of the first observed 572 SRTP packet (unless the initial value is provided by key management). 574 On consecutive SRTP packets, the receiver SHOULD estimate the index 575 as 577 i = 2^16 * v + SEQ, 579 where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) 580 such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC 581 + s_l. 583 After the packet has been processed using the estimated index, the 584 receiver MUST decide if s_l and ROC should be updated. For instance, 585 a simple (but not error robust) method is to simply set s_l to SEQ 586 (if SEQ > s_l) and, if the value v = ROC+1 was used, to update ROC to 587 v. 589 After a re-keying occurs (changing to a new master key), the 590 rollover counter maintains its sequence of values, i.e., it MUST NOT 591 be reset to zero, to avoid inconsistencies in key lifetimes. 593 As the rollover counter is 32 bits long and the sequence number is 594 16 bits long, the maximum number of packets belonging to a given 595 SRTP stream that can be secured with the same key is 2^48 using the 596 pre-defined transforms. After that number of SRTP packets have been 597 sent with a given (master or session) key, the sender MUST NOT send 598 any more packets with that key. (There exists a similar limit for 599 SRTCP, which in practice may be more restrictive, see Section 9.2.) 600 This limitation enforces a security benefit by providing an upper 601 bound on the amount of traffic that can pass before cryptographic 602 keys are changed. Re-keying (see Section 8.1) MUST be triggered, 603 before this amount of traffic, and MAY be triggered earlier, e.g., 604 for increased security and access control to media. Recurring key 605 derivation by means of a non-zero key_derivation_rate (see Section 606 4.3), also gives stronger security but does not change the above 607 absolute maximum value. 609 On the receiver side, there is a caveat to updating s_l and ROC: if 610 message authentication is not present, neither the initialization of 611 s_l, nor the ROC update can be made completely robust. The 612 receiver's "implicit index" approach works for the pre-defined 613 transforms as long as the reorder and loss of the packets are not 614 too great and bit-errors do not occur in unfortunate ways. In 615 particular, 2^15 packets would need to be lost, or a packet would 616 need to be 2^15 packets out of sequence before synchronization is 617 lost. Such drastic loss or reorder is likely to disrupt the RTP 618 application itself. 620 The algorithm for the index estimate and ROC update is a matter of 621 implementation, and should take into consideration the environment 622 (e.g., packet loss rate) and the cases when synchronisation is 623 likely to be lost, e.g. when the initial sequence number (randomly 624 chosen by RTP) is not known in advance (not sent in the key 625 management protocol) but may be near to wrap modulo 2^16. 626 A more elaborate and more robust scheme than the one given above is 627 the handling of RTP's own "rollover counter", see Appendix A.1 of 628 [RFC1889]. 630 3.3.2 Replay Protection 632 Secure replay protection is only possible when integrity protection 633 is present. It is RECOMMENDED to use replay protection, both for RTP 634 and RTCP, as integrity protection alone cannot assure security 635 against replay attacks. 637 A packet is "replayed" when it is stored by an adversary, and then 638 re-injected into the network. When message authentication is 639 provided, SRTP protects against such attacks through a "Replay 640 List". Each SRTP receiver maintains a Replay List, which 641 conceptually contains the indices of all of the packets which have 642 been received and authenticated. In practice, the list can use a 643 "sliding window" approach, so that a fixed amount of storage 644 suffices for replay protection. Packet indices which lag behind the 645 packet index in the context by more than SRTP-WINDOW-SIZE can be 646 assumed to have been received, where SRTP-WINDOW-SIZE is a receiver- 647 side, implementation-dependent parameter and MUST be at least 64, 648 but which MAY be set to a higher value. 650 The receiver checks the index of an incoming packet against the 651 replay list and the window. Only packets with index ahead of the 652 window, or, inside the window but not already received, SHALL be 653 accepted. 655 After the packet has been authenticated (if necessary the window is 656 first moved ahead), the replay list SHALL be updated with the new 657 index. 659 The Replay List can be efficiently implemented by using a bitmap to 660 represent which packets have been received, as described in the 661 Security Architecture for IP [RFC2401]. 663 3.4 Secure RTCP 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 668 |V=2|P| RC | PT=SR or RR | length | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 670 | SSRC of sender | | 671 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 672 | ~ sender info ~ | 673 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 674 | ~ report block 1 ~ | 675 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 676 | ~ report block 2 ~ | 677 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 678 | ~ ... ~ | 679 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 680 | |V=2|P| SC | PT=SDES=202 | length | | 681 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 682 | | SSRC/CSRC_1 | | 683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 684 | ~ SDES items ~ | 685 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 686 | ~ ... ~ | 687 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 688 | |E| SRTCP index | | 689 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 690 | ~ SRTCP MKI (OPTIONAL) ~ | 691 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 692 | : authentication tag : | 693 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 694 | | 695 +-- Encrypted Portion Authenticated Portion -----+ 697 Figure 2. An example of the format of a Secure RTCP packet, 698 consisting of an underlying RTCP compound packet with a Report and 699 SDES packet. 701 Secure RTCP follows the definition of Secure RTP. SRTCP adds three 702 mandatory new fields (the SRTCP index, an "encrypt-flag", and the 703 authentication tag) and one optional field (the MKI) to the RTCP 704 packet definition. The three mandatory fields MUST be appended to an 705 RTCP packet in order to form an equivalent SRTCP packet. The added 706 fields follow any other profile-specific extensions. 708 According to [RFC1889] there is a "recommended" packet format for 709 compound packets. SRTCP MUST be given packets according to that 710 recommendation in the sense that the first part MUST be a sender 711 report or a receiver report. However, the encryption prefix (Section 712 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known 713 plaintext attacks, MUST NOT be used (see below). 715 The Encrypted Portion of an SRTCP packet consists of the encryption 716 (Section 4.1) of the RTCP payload of the equivalent compound RTCP 717 packet, from the first RTCP packet, i.e., from the ninth (9) octet 718 to the end of the compound packet. The Authenticated Portion of an 719 SRTCP packet consists of the entire equivalent (eventually compound) 720 RTCP packet, the E flag, and the SRTCP index (after any encryption 721 has been applied to the payload). 723 The added fields are: 725 E-flag: 1 bit, REQUIRED 726 The E-flag indicates if the current SRTCP packet is encrypted 727 or unencrypted. Section 9.1 of [RFC1889] allows the split of 728 a compound RTCP packet into two lower-layer packets, one to 729 be encrypted and one to be sent in the clear. The E bit set 730 to "1" indicates encrypted packet, and "0" indicates non- 731 encrypted packet. 733 SRTCP index: 31 bits, REQUIRED 734 The SRTCP index is a 31-bit counter for the SRTCP packet. The 735 index is explicitly included in each packet, in contrast to 736 the "implicit" index approach used for SRTP. The SRTCP index 737 MUST be set to zero before the first SRTCP packet is sent, 738 and MUST be incremented by one, modulo 2^31, after each SRTCP 739 packet is sent. In particular, after a re-key, the SRTCP 740 index MUST NOT be reset to zero again (Section 3.3.1). 742 Authentication Tag: variable length, REQUIRED 743 The authentication tag is used to carry message 744 authentication data. 746 MKI: variable length, OPTIONAL 747 The MKI is the Master Key Indicator, and functions according 748 to the MKI definition in Section 3. 750 SRTCP uses the cryptographic context parameters and packet 751 processing of SRTP by default, with the following changes: 753 * The receiver does not need to "estimate" the index, as it is 754 explicitly signaled in the packet. 756 * If the MKI indicator in the cryptographic context is zero, the 757 master key is determined by the current SRTCP index when that key is 758 shared between SRTP and SRTCP, even though SRTCP has its own index. 759 Since the SRTCP source as with any SSRC in an SRTP session has its 760 own sequence number space, the master key <"From", "To"> lifetime 761 MUST be based on the SRTP master key lifetime when the master key is 762 shared by both SRTP and SRTCP. The concomitant re-keying issues are 763 discussed in sections 8 and 9. 765 * Pre-defined SRTCP encryption is as specified in Section 4.1, but 766 using the definition of the SRTCP Encrypted Portion given in this 767 section, and using the SRTCP index as the index i. The encryption 768 transform and related parameters SHALL by default be the same 769 selected for the protection of the associated SRTP stream(s), while 770 the NULL algorithm SHALL be applied to the RTCP packets not to be 771 encrypted. SRTCP may have a different encryption transform than the 772 one used by the corresponding SRTP. The expected use for this 773 feature is when the former has NULL-encryption and the latter has a 774 non NULL-encryption. 776 The E-flag is assigned a value by the sender depending on whether 777 the packet was encrypted or not. 779 * SRTCP decryption is performed as in Section 4, but only if the E 780 flag is equal to 1. If so, the Encrypted Portion is decrypted, using 781 the SRTCP index as the index i. In case the E-flag is 0, the payload 782 is simply left unmodified. 784 * SRTCP replay protection is as defined in Section 3.3.2, but using 785 the SRTCP index as the index i and a separate replay list that is 786 specific to SRTCP. 788 * The pre-defined SRTCP authentication tag is specified as in 789 Section 4.2, but with the Authenticated Portion of the SRTCP packet 790 given in this section (which includes the index). The authentication 791 transform and related parameters (e.g., key size) SHALL by default 792 be the same as selected for the protection of the associated SRTP 793 stream(s) (except when SRTP is not authenticated). 795 * In the last step of the processing, only the sender needs to 796 update the value of the SRTCP index by incrementing it modulo 2^31 797 and for security reasons the sender MUST also check the number of 798 RTCP packets processed, see Section 9.2. 800 As noted, the encryption prefix (Section 6.1 of RFC1889]) SHALL NOT 801 be used, as it is not needed by the cryptographic mechanisms used in 802 SRTP. 804 Message authentication for RTCP is REQUIRED, as it is the control 805 protocol (e.g., it has a BYE packet) for RTP. 807 Precautions must be taken so that the packet expansion in SRTCP (due 808 to the added fields) does not cause SRTCP messages to use more than 809 their share of RTCP bandwidth. To avoid this, the following two 810 measures MUST be taken: 812 1. When initializing the RTCP variable "avg_rtcp_size" defined in 813 chapter 6.3 of [RFC1889], it MUST include the size of the fields 814 that will be added by SRTCP (index, E-bit, authentication tag, and 815 when present, the MKI). 817 2. When updating the "avg_rtcp_size" using the variable packet_size" 818 (section 6.3.3 of [RFC1889]), the value of "packet_size" MUST 819 include the size of the additional fields added by SRTCP. 821 With these measures in place the SRTCP messages will not use more 822 than the allotted bandwidth. The effect of the size of the added 823 fields on the SRTCP traffic will be that messages will be sent with 824 larger packet intervals. The increase in the intervals will be 825 directly proportional to size of the added fields. 827 4. Pre-Defined Cryptographic Transforms 829 While there are numerous encryption and message authentication 830 algorithms that can be used in SRTP, we define below default 831 algorithms in order to avoid the complexity of specifying the 832 encodings for the signaling of algorithm and parameter identifiers. 833 The defined algorithms have been chosen as they fulfill the goals 834 listed in Section 2. Recommendations on how to extend SRTP with new 835 transforms are given in Section 6. 837 4.1 Encryption 839 The following parameters are common to both pre-defined, non-NULL, 840 encryption transforms specified in this section. 842 * BLOCK_CIPHER-MODE indicates the block cipher used and its mode of 843 operation 845 * n_b is the bit-size of the block for the block cipher 846 * k_e is the session encryption key 847 * n_e is the bit-length of k_e 848 * k_s is the session salting key 849 * n_s is the bit-length of k_s 850 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, an 851 non-negative integer, specified by the message authentication code 852 in use. 854 The distinct session keys and salts for SRTP/SRTCP are by default 855 derived as specified in Section 4.3. 857 The encryption transforms defined in SRTP map the SRTP packet index 858 and secret key into a pseudorandom keystream segment. Each keystream 859 segment encrypts a single RTP packet. The process of encrypting a 860 packet consists of generating the keystream segment corresponding to 861 the packet, and then bitwise exclusive-oring that keystream segment 862 onto the payload of the RTP packet to produce the Encrypted Portion 863 of the SRTP packet. Decryption is done the same way, but swapping 864 the roles of the plaintext and ciphertext. 866 The definition of how the keystream is generated, given the index, 867 depends on the cipher and its mode of operation. Below, two such 868 keystream generators are defined. The NULL cipher is also defined, 869 to be used when encryption of RTP is not required. 871 +----+ +------------------+---------------------------------+ 872 | KG |-->| Keystream Prefix | Keystream Suffix |---+ 873 +----+ +------------------+---------------------------------+ | 874 | 875 +---------------------------------+ v 876 | Payload of RTP Packet |->(*) 877 +---------------------------------+ | 878 | 879 +---------------------------------+ | 880 | Encrypted Portion of SRTP Packet|<--+ 881 +---------------------------------+ 883 Figure 3: Default SRTP Encryption Processing. Here KG denotes the 884 keystream generator, and (*) denotes bitwise exclusive-or. 886 The SRTP definition of the keystream is illustrated in Figure 3. The 887 initial octets of each keystream segment MAY be reserved for use in 888 a message authentication code, in which case the keystream used for 889 encryption starts immediately after the last reserved octet. The 890 initial reserved octets are called the "keystream prefix" (not to be 891 confused with the "encryption prefix" of [RFC1889, Section 6.1]), 892 and the remaining octets are called the "keystream suffix". The 893 keystream prefix MUST NOT be used for encryption. The process is 894 illustrated in Figure 3. 896 The number of octets in the keystream prefix is denoted as 897 SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, 898 non-zero value of SRTP_PREFIX_LENGTH. This means that, even if 899 confidentiality is not to be provided, the keystream generator 900 output may still need to be computed for packet authentication, in 901 which case the default keystream generator (mode) SHALL be used. 903 The default cipher is the Advanced Encryption Standard (AES), and we 904 define two modes of running AES, Segmented Integer Counter Mode AES 905 and AES in f8-mode. In the remainder of this section, let E(k,x) be 906 AES applied to key k and input block x. 908 4.1.1 AES in Counter Mode 910 Conceptually, counter mode [AES-CTR] consists of encrypting 911 successive integers. The actual definition is somewhat more 912 complicated, in order to randomize the starting point of the integer 913 sequence. Each packet is encrypted with a distinct keystream 914 segment, which SHALL be computed as follows. 916 A keystream segment SHALL be the concatenation of the 128-bit output 917 blocks of the AES cipher in the encrypt direction, using key k = 918 k_e, in which the block indices are in increasing order. 919 Symbolically, each keystream segment looks like 921 E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ... 923 where the 128-bit integer value IV SHALL be defined by the SSRC, the 924 SRTP packet index i, and the SRTP session salting key k_s, as below. 926 IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16) 928 Each of the three terms in the XOR-sum above is padded with as many 929 leading zeros as needed to make the operation well-defined, 930 considered as a 128-bit value. 932 The inclusion of the SSRC allows the use of the same key to protect 933 distinct SRTP streams (see the security caveats in Section 9.1). 935 In the case of SRTCP, the SSRC of the first header of the compound 936 packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s 937 SHALL be replaced by the SRTCP session key and salt. 939 Note that the initial value, IV, is fixed for each packet. The 940 number of blocks of keystream generated for any fixed value of IV 941 MUST NOT exceed 2^16. The AES has a block size of 128 bits, so 2^16 942 output blocks are sufficient to generate the 2^23 bits of keystream 943 needed to encrypt the largest possible RTP packet (except for IPv6 944 "jumbograms" [RFC2675], which are not likely to be used for RTP- 945 based multimedia traffic). This restriction on the maximum bit-size 946 of the packet that can be encrypted ensures the security of the 947 encryption method by limiting the effectiveness of probabilistic 948 attacks [BDJR]. 950 4.1.2 AES in f8-mode 952 IV 953 | 954 | 955 v 956 +------+ 957 | | 958 +--->| E | 959 | | | 960 | +------+ 961 | | 962 m -> (*) +-----------+-------------+-- ... ------+ 963 | IV' | | | | 964 | | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*) 965 | | | | | 966 | | +-> (*) +-> (*) ... +-> (*) 967 | | | | | | | | 968 | v | v | v | v 969 | +------+ | +------+ | +------+ | +------+ 970 | | | | | | | | | | | | 971 k_e ---+--->| E | | | E | | | E | | | E | 972 | | | | | | | | | | | 973 +------+ | +------+ | +------+ | +------+ 974 | | | | | | | 975 +------+ +--------+ +-- ... ----+ | 976 | | | | 977 v v v v 978 S(0) S(1) S(2) . . . S(L-1) 980 Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). 981 The figure represents the KG in Figure 3, when AES-f8 is used. 983 To encrypt UMTS (Universal Mobile Telecommunications System, as 3G 984 networks) data, a solution (see [f8-a], [f8-b]) known as the f8- 985 algorithm has been developed. On a high level, the proposed scheme 986 is a variant of Output Feedback Mode (OFB) [HAC], with a more 987 elaborate initialization and feedback function. As in normal OFB, 988 the core consists of a block cipher. We also define here the use of 989 AES as a block cipher to be used in f8-mode for RTP encryption. The 990 AES f8-mode SHALL use the same default sizes for session key and 991 salt as AES counter mode. 993 Figure 4 shows the structure of block cipher, E, running in what we 994 shall call "f8-mode of operation". 996 4.1.2.1 f8 Keystream Generation 998 The Initialization Vector (IV) SHALL be determined as described in 999 Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP). 1001 Let IV', S(j), and m denote n_b-bit blocks. The keystream, S(0) || 1002 ... || S(L-1), for an N-bit message SHALL be defined by setting IV' 1003 = E(k_e XOR m, IV), and S(-1) = 00..0. For j = 0,1,..,L-1 where L = 1004 N/n_b (rounded up to nearest integer) compute 1006 S(j) = E(k_e, IV' XOR j XOR S(j-1)) 1008 Notice that the IV is not used directly. Instead it is fed through E 1009 under another key to produce an internal, "masked" value (denoted 1010 IV') to prevent an attacker from gaining known input/output pairs. 1011 The role of the internal counter, j, is to prevent short keystream 1012 cycles. The value of the key mask m SHALL be 1014 m = k_s || 0x555..5, 1016 i.e. the session salting key, appended by the binary pattern 0101.. 1017 to fill out the entire desired key size, n_e. 1019 The sender SHOULD NOT generate more than 2^32 blocks, which is 1020 sufficient to generate 2^39 bits of keystream. Unlike counter mode, 1021 there is no absolute threshold above (below) which f8 is guaranteed 1022 to be insecure (secure). The above bound has been chosen to limit, 1023 with sufficient security margin, the probability of degenerative 1024 behavior in the f8 keystream generation. 1026 4.1.2.2 f8 SRTP IV Formation 1028 The purpose of the following IV formation is to provide a feature 1029 which we call implicit header authentication (IHA), see Section 9.5. 1031 The SRTP IV for 128-bit block AES-f8 SHALL be formed in the 1032 following way: 1034 IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC 1036 M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from 1037 the cryptographic context. 1039 The presence of the SSRC as part of the IV allows AES-f8 to be used 1040 when a master key is shared between multiple streams, see Section 1041 9.1. 1043 4.1.2.3 f8 SRTCP IV Formation 1045 The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the 1046 following way: 1048 IV = 0...0 || E || SRTCP index || V || P || RC || PT || length || 1049 SSRC 1051 where V, P, RC, PT, length, SSRC SHALL be taken from the first 1052 header in the RTCP compound packet. E and SRTCP index are the 1-bit 1053 and 31-bit fields added to the packet. 1055 4.1.3 NULL Cipher 1057 The NULL cipher is used when no confidentiality for RTP/RTCP is 1058 requested. The keystream can be thought of as "000..0", i.e. the 1059 encryption SHALL simply copy the plaintext input into the ciphertext 1060 output. 1062 4.2 Message Authentication and Integrity 1064 Throughout this section, M will denote data to be integrity 1065 protected: in the case of SRTP, M SHALL consist of the Authenticated 1066 Portion of the packet (as specified in Figure 1) concatenated with 1067 the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M 1068 SHALL consist of the Authenticated Portion (as specified in Figure 1069 2) only. 1071 Common parameters: 1073 * AUTH_ALG is the authentication algorithm 1074 * k_a is the session message authentication key 1075 * n_a is the bit-length of the authentication key 1076 * n_tag is the bit-length of the output authentication tag 1077 * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as 1078 defined above, a parameter of AUTH_ALG 1080 The distinct session authentication keys for SRTP/SRTCP are by 1081 default derived as specified in Section 4.3. 1083 The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for 1084 any particular fixed value of the key. 1086 We describe the process of computing authentication tags as follows. 1087 The sender computes the tag of M and appends it to the packet. The 1088 SRTP receiver verifies a message/authentication tag pair by 1089 computing a new authentication tag over M using the selected 1090 algorithm and key, and then compares it to the tag associated with 1091 the received message. If the two tags are equal, then the 1092 message/tag pair is valid; otherwise, it is invalid and the error 1093 audit message "AUTHENTICATION FAILURE" MUST be returned. 1095 4.2.1. HMAC-SHA1 1097 The pre-defined authentication transform for SRTP is HMAC-SHA1. With 1098 HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL be 0. For SRTP 1099 (respectively SRTCP), the HMAC SHALL be applied to the session 1100 authentication key and M as specifed above, i.e. HMAC(k_a, M). The 1101 HMAC output SHALL then be truncated to the n_tag left-most bits. 1103 4.3 Key Derivation 1105 4.3.1 Key Derivation Algorithm 1107 Regardless of the encryption or message authentication transform 1108 that is employed (it may be an SRTP pre-defined transform or newly 1109 introduced according to Section 6), interoperable SRTP 1110 implementations MAY use the SRTP key derivation to generate session 1111 keys. Once the key derivation rate is properly signaled at the start 1112 of the session, there is no need for extra communication between the 1113 parties that use SRTP key derivation. 1115 packet index ---+ 1116 | 1117 v 1118 +-----------+ master +--------+ session encr_key 1119 | ext | key | |----------> 1120 | key mgmt |-------->| key | session auth_key 1121 | (optional | | deriv |----------> 1122 | rekey) |-------->| | session salt_key 1123 | | master | |----------> 1124 +-----------+ salt +--------+ 1126 Figure 5: SRTP key derivation. 1128 At least one initial key derivation SHALL be performed by SRTP, 1129 i.e., the first key derivation is REQUIRED. Further applications of 1130 the key derivation MAY be performed, according to the 1131 "key_derivation_rate" value in the cryptographic context. The key 1132 derivation function SHALL be initially invoked before the first 1133 packet and then, if derivation rate is r > 0, further invoked on 1134 every r-th packet, and produce session keys according to the non- 1135 zero key derivation rate. This can be thought of as "refreshing" the 1136 session keys. The value of "key_derivation_rate" MUST be kept fixed 1137 for the lifetime of the associated master key. 1139 Interoperable SRTP implementations MAY also derive session salting 1140 keys for encryption transforms, as is done in both of the pre- 1141 defined transforms. 1143 Let m and n be positive integers. A pseudo-random function family is 1144 a set of keyed functions {PRF_n(k,x)} such that for the (secret) 1145 random key k, given m-bit x, PRF_n(k,x) is an n-bit string, 1146 computationally indistinguishable from random n-bit strings, see 1147 [HAC]. For the purpose of key derivation in SRTP, a secure PRF with 1148 m = 128 (or more) is needed, and a default PRF transform is defined 1149 in Section 4.3.3. 1151 Let "a DIV t" denote integer division of a by t, rounded down, and 1152 with the convention that "a DIV 0 = 0" for all a. We also make the 1153 convention of treating "a DIV t" as a bit string of the same length 1154 as a, and thus "a DIV t" will in general have leading zeros. 1156 Key derivation SHALL be defined as follows in terms of