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