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