idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 17, 2012) is 4453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CCM' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC4658' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC6188' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 875, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Informational K.M. Igoe 5 Expires: August 20, 2012 National Security Agency 6 February 17, 2012 8 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 9 draft-ietf-avtcore-srtp-aes-gcm-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 20, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document defines how AES-GCM, AES-CCM, and other Authenticated 46 Encryption with Associated Data (AEAD) algorithms, can be used to 47 provide confidentiality and data authentication mechanisms in the 48 SRTP protocol. 50 Table of Contents 52 1. Introduction.....................................................2 53 1.1. Conventions Used In This Document...........................3 54 1.2. AEAD processing for SRTP....................................4 55 1.2.1. AEAD versus SRTP/SRTCP Authentication..................5 56 1.2.2. Values used to form the Initialization Vector (IV).....6 57 1.3. SRTP IV formation for AES-GCM and AES-CCM...................6 58 1.4. SRTCP IV formation for AES-GCM and AES-CCM..................7 59 1.5. AEAD Processing of SRTP Packets.............................8 60 1.6. AEAD Processing of SRTCP Packets............................8 61 1.6.1. Encrypted SRTCP packets................................9 62 1.6.2. Unencrypted SRTCP packets.............................10 63 1.7. Initialization of the Counters.............................10 64 1.8. Prevention of IV Reuse.....................................11 65 2. AEAD parameters for SRTP and SRTCP..............................11 66 2.1. Generic AEAD Parameter Constraints.........................11 67 2.2. AES-GCM for SRTP/SRTCP.....................................12 68 2.3. AES-CCM for SRTP/SRTCP.....................................13 69 2.4. Key Derivation Functions...................................13 70 3. Security Considerations.........................................14 71 3.1. Handling of Security Critical Parameters...................14 72 3.2. Size of the Authentication Tag.............................14 73 4. IANA Considerations.............................................15 74 5. Acknowledgements................................................16 75 6. References......................................................17 76 6.1. Normative References.......................................17 77 6.2. Informative References.....................................18 79 1. Introduction 81 The Secure Real-time Transport Protocol (SRTP) is a profile of the 82 Real-time Transport Protocol (RTP), which can provide 83 confidentiality, message authentication, and replay protection to the 84 RTP traffic and to the control traffic for RTP, the Real-time 85 Transport Control Protocol (RTCP). 87 SRTP/SRTCP assumes that both the sender and recipient have a shared 88 secret master key and a shared master salt. As described in sections 89 4.3.1 and 4.3.3 of [RFC3711], a Key Derivation Function is applied to 90 these values to obtain separate encryption keys, authentication keys 91 and salting keys for SRTP and for SRTCP. (Note: As will be explained 92 below, AEAD SRTP/SRTCP does not make use of these authentication 93 keys.) 95 Authenticated encryption [BN00] is a form of encryption that, in 96 addition to providing confidentiality for the plaintext that is 97 encrypted, provides a way to check its integrity and authenticity. 98 Authenticated Encryption with Associated Data, or AEAD [R02], adds 99 the ability to check the integrity and authenticity of some 100 Associated Data (AD), also called "additional authenticated data", 101 that is not encrypted. This specification makes use of the interface 102 to a generic AEAD algorithm as defined in [RFC5116]. 104 The Advanced Encryption Standard (AES) is a block cipher that 105 provides a high level of security, and can accept different key 106 sizes. Two families of AEAD algorithm families, AES Galois/Counter 107 Mode (AES-GCM) and AES Counter with Cipher Block Chaining-Message 108 Authentication Code (AES-CCM), are based upon AES. This 109 specification makes use of the AES versions that use 128-bit and 110 256-bit keys, which we call AES-128 and AES-256, respectively. 112 The Galois/Counter Mode of operation (GCM) and the Counter with 113 Cipher Block Chaining-Message Authentication Code mode of operation 114 (CCM) are both AEAD modes of operation for block ciphers. Both use 115 counter mode to encrypt the data, an operation that can be 116 efficiently pipelined. Further, GCM authentication uses operations 117 that are particularly well suited to efficient implementation in 118 hardware, making it especially appealing for high-speed 119 implementations, or for implementations in an efficient and compact 120 circuit. CCM is well suited for use in compact software 121 implementations. This specification uses GCM and CCM with both 122 AES-128 and AES-256. 124 In summary, this document defines how to use AEAD algorithms, 125 particularly AES-GCM and AES-CCM, to provide confidentiality and 126 message authentication within SRTP and SRTCP packets. 128 1.1. Conventions Used In This Document 130 The following terms have very specific meanings in the context of 131 this RFC: 133 Crypto Context For the purposes of this document a crypto context 134 is the outcome of any process which results in 135 authentication of each participant in the SRTP 136 session and possession by each partcipant of a 137 shared secret master key and a shared master 138 salt. Details of how the maser key and master 139 salt are established are outside the scope of this 140 document. Similarly any mechanism for rekeying an 141 existing Ciper Contest is outside the scope of the 142 document. The master key MUST be at least as 143 large as the encryption key. The SRTP/SRTCP Key 144 Derivation Function (KDF) defined in [RFC3711] is 145 applied to the master key and master SALT to 146 derive the SRTP_encr_key, SRTCP_encr_key, 147 SRTP_SALT, and SRTCP_SALT. Authentication keys 148 are not used in AEAD. 150 Instantiation Once keys have been established, an instance of 151 the AEAD algorithm is created using the 152 appropriate key and salt. In a point-to-point 153 scenario, each participant in the SRTP/SRTCP 154 session will need four instantiations of the AEAD 155 algorithm; one for inbound SRTP traffic, one for 156 outbound SRTP traffic source, one for inbound 157 SRTCP traffic, and one for outbound SRTCP traffic 158 source. See section 1.2 for details on what is 159 required of each instantiation. 161 Invocation SRTP/SRTCP data streams are broken into packets. 162 Each packet is processed by a single invocation of 163 the appropriate instantiation of the AEAD 164 algorithm. 166 Each AEAD instantiation has its own key, a 48-bit zero-based packet 167 counter that is incremented after that particular instantiation has 168 been invoked to process an SRTP packet, and a 31-bit zero-based SRTCP 169 index that is incremented each time an SRTCP packet is processed. A 170 32-bit Block Counter is incremented each time a block of key is 171 produced and is reset (to zero for CCM and to one for GCM) at the 172 start of each packet. As we shall see in sections 1.3 and 1.4, the 173 packet counter and SRTCP counter play a crucial role in the formation 174 of each packet's IV. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 1.2. AEAD processing for SRTP 182 We first define how to use a generic AEAD algorithm in SRTP, then we 183 describe the specific use of the AES-128-GCM and AES-256-GCM 184 algorithms. 186 The use of an AEAD algorithm is defined by expressing the AEAD 187 encryption algorithm inputs in terms of SRTP fields and data 188 structures. The AEAD encryption inputs are as follows: 190 Key This input is the SRTP encryption key 191 (SRTP_encr_key) produced from the shared 192 secret master key using the key derivation 193 process. (Note that the SRTP_auth_key is 194 not used). 196 Associated Data This is data that is to be authenticated 197 but not encrypted. In SRTP, the associated 198 data consists of the entire RTP header, 199 including the list of CSRC identifiers (if 200 present) and the RTP header extension (if 201 present), as shown in Figure 3. 203 Plaintext Data that is to be both encrypted and 204 authenticated. In SRTP this consists of 205 the RTP payload, the RTP padding and the 206 RTP pad count fields (if the latter two 207 fields are present) as shown in Figure 3. 208 The padding service provided by RTP is not 209 needed by the AEAD encryption algorithm, so 210 the RTP padding and RTP pad count fields 211 SHOULD be omitted. 213 Initialization Vector Each SRTP/SRTCP packet has its own 12-octet 214 initialization vector (IV). Construction 215 of this IV is covered in more detail 216 below. 218 The AEAD encryption algorithm accepts these four inputs and returns a 219 Ciphertext field. 221 1.2.1. AEAD versus SRTP/SRTCP Authentication 223 The reader is reminded that in addition to providing confidentiality 224 for the plaintext that is encrypted, an AEAD algorithm also provides 225 a mechanism that allows the intended recipient to check the data 226 integrity and authenticity of the plaintext and associated data. The 227 AEAD authentication tag is incorporated into the Ciphertext field by 228 RFC 5116, thus AEAD does not make use of the SRTP/SRTCP 229 Authentication Tag fields defined in RFC 3711. (Note that this means 230 that the cipher text will be longer than the plain text by precisely 231 the length of the AEAD authentication tag.) 233 The AEAD message authentication mechanism MUST be the primary message 234 authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP 235 authentication mechanisms SHOULD NOT be used with any AEAD algorithm 236 and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED 237 and SHOULD NOT be present. Note that this contradicts section 3.4 of 238 [RFC3711] which makes the use of the SRTCP Authentication field 239 mandatory, but the presence of the AEAD authentication renders the 240 older authentication methods redundant. 242 Rationale. Some applications use the SRTP/SRTCP Authentication 243 Tag as a means of conveying additional information, notably 244 [RFC4771]. This document retains the Authentication Tag field 245 primarily to preserve compatibility with these applications. 247 1.2.2. Values used to form the Initialization Vector (IV) 249 The initialization vector for an SRTP packet is formed from the: 251 SSRC The 4-octet Synchronization Source identifier 252 (SSRC), found in the RTP header. 254 Packet Counter Each AEAD instantiation MUST maintain a 6 octet 255 zero-based packet counter which is incremented 256 each time an SRTP packet is sent. As we shall 257 see below, the packet counter is used to insure 258 each SRTP packet gets a unique initialization 259 vector. 261 Sequence Number The 2-octet RTP Sequence Number (SEQ), found in 262 the RTP header. The SEQ is just the 16 least 263 significant bits of the packet counter. 265 Rollover Counter A 4-octet Rollover Counter (ROC), maintained 266 independently by both sides of the link, 267 incremented each time the Sequence Number cycles 268 back to 0. The ROC is just the 32 most 269 significant bits of the Packet Counter. 271 SRTCP index The SRTCP index is a 31-bit counter that plays 272 the same role for SRTCP packets that the Packet 273 Counter does for SRTP packets. Unlike the 274 Packet Counter, the SRTCP index is explicitly 275 included in each STRCP packet. The sender MUST 276 increment the SRTCP index by one after each SRTP 277 packet is sent. 279 SALT A 12-octet SRTP session encryption salt produced 280 by the SRTP Key Derivation Function (KDF) (see 281 section 2.4). 283 The reader is reminded that both SRTP and SRTCP allow packets to 284 arrive out of order, presenting the receiver with a synchronization 285 problem. The 31-bit SRTCP index is contained in the unencrypted (but 286 authenticated) portion of the SRTCP header, allowing the recipient to 287 read the SRTCP index directly from the header. But only the low 16 288 bits of the SRTP Packet counter are contained in the SRTP header (in 289 the sequence number field). Section 3.3.1 of [RFC3711] explains in 290 great detail how the 16-bit sequence number and 32-bit Rollover 291 Counter are to be used to recover the 48-bit Packet Counter. 293 1.3. SRTP IV formation for AES-GCM and AES-CCM 295 AES-GCM and AES-CCM SRTP use a 12 byte initialization vector which is 296 formed as follows. A 12-octet string is formed by concatenating 297 2-octets of zeroes, the 4-octet SSRC, and the 6-octet Packet 298 Counter. The resulting string is bitwise exclusive-ored with the 299 12-octet salt to form the 12-octet IV. 301 0 0 0 0 0 0 0 0 0 0 1 1 302 0 1 2 3 4 5 6 7 8 9 0 1 303 +--+--+--+--+--+--+--+--+--+--+--+--+ 304 |00|00| SSRC | Packet_Counter |---+ 305 +--+--+--+--+--+--+--+--+--+--+--+--+ | 306 | 307 +--+--+--+--+--+--+--+--+--+--+--+--+ | 308 | Encryption Salt |->(+) 309 +--+--+--+--+--+--+--+--+--+--+--+--+ | 310 | 311 +--+--+--+--+--+--+--+--+--+--+--+--+ | 312 | Initialization Vector |<--+ 313 +--+--+--+--+--+--+--+--+--+--+--+--+ 315 Figure 1: AES-GCM and AES-CCM SRTP 316 Initialization Vector formation. 318 Using the terminology of section 8.2.1. of [GCM], the first six 319 octets of the IV are the fixed field and the last six bytes are the 320 invocation field. 322 1.4. SRTCP IV formation for AES-GCM and AES-CCM 324 The initialization vector for an SRTCP packet is formed from the 325 4-octet Synchronization Source identifier (SSRC), 31-bit SRTCP Index 326 (packed zero-filled, right justified into a 4-octet field), and a 327 12-octet SRTCP session encryption salt produced by the SRTP Key 328 Derivation Function (KDF). 330 0 1 2 3 4 5 6 7 8 9 10 11 331 +--+--+--+--+--+--+--+--+--+--+--+--+ 332 |00|00| SSRC |00|00|SRTCP Index|---+ 333 +--+--+--+--+--+--+--+--+--+--+--+--+ | 334 | 335 +--+--+--+--+--+--+--+--+--+--+--+--+ | 336 | Encryption Salt |->(+) 337 +--+--+--+--+--+--+--+--+--+--+--+--+ | 338 | 339 +--+--+--+--+--+--+--+--+--+--+--+--+ | 340 | Initialization Vector |<--+ 341 +--+--+--+--+--+--+--+--+--+--+--+--+ 343 Figure 2: SRTCP Initialization Vector formation. 345 As shown if figure 2, a 12-octet string is formed by concatenating in 346 order 2-octets of zeroes, the 4-octet SSRC, 2 more zero octets, and 347 the 4-octet SRTCP index. The resulting 12-octet string is bitwise 348 exclusive-ored into salt; the output of that process is the IV. The 349 IV is always exactly 12 octets in length. Using the terminology of 350 section 8.2.1. of [GCM], the first eight octets of the IV are the 351 fixed field and the last four bytes are the invocation field. 353 1.5. AEAD Processing of SRTP Packets 355 All SRTP packets MUST be authenticated and encrypted. Figure 3 below 356 shows which fields of AEAD SRTP packet are to be treated as plaintext 357 and which are to be treated as additional authenticated data. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 A |V=2|P|X| CC |M| Packet Type | sequence number | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 A | timestamp | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 A | synchronization source (SSRC) identifier | 367 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 368 A | contributing source (CSRC) identifiers (optional) | 369 A | .... | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 A | RTP extension (OPTIONAL) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 P | payload ... | 374 P | +-------------------------------+ 375 P | | RTP padding | RTP pad count | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 X : authentication tag (NOT RECOMMENDED) : 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 P = Plaintext (to be encrypted and authenticated) 381 A = Associated Data (to be authenticated only) 382 X = neither encrypted nor authenticated 384 Note: The RTP padding and RP padding count fields are optional 385 and are not recommended 387 Figure 3: AEAD inputs from an SRTP packet. 389 1.6. AEAD Processing of SRTCP Packets 391 All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP 392 packet encryption is optional. A sender can select which packets to 393 encrypt, and indicates this choice with a 1-bit encryption flag 394 (located in the leftmost bit of the 32-bit word that contains the 395 SRTCP index) 397 1.6.1. Encrypted SRTCP packets 399 When the encryption flag is set to 1, the first 8-octets, the 400 encryption flag and 31-bit SRTCP index MUST be treated as AAD. The 401 remaining data MUST be treated as plaintext, and hence is to be both 402 encrypted and AEAD authenticated, save for the optional SRTCP MKI 403 index and optional SRTCP authentication tag, which MUST be neither 404 encrypted nor AEAD authenticated. Figure 4 below shows how fields of 405 an RTCP packet are to be treated when the encryption flag is set to 406 1. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 A |V=2|P| RC | Packet Type | length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 A | synchronization source (SSRC) of Sender | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 P | sender info | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 P | report block 1 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 P | report block 2 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 P | ... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 P |V=2|P| SC | Packet Type | length | 424 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 425 P | SSRC/CSRC_1 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 P | SDES items | 428 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 429 P | ... | 430 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 431 A |1| SRTCP index | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 X | SRTCP MKI (optional)index | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 X : authentication tag (NOT RECOMMENDED) : 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 P = Plaintext (to be encrypted and authenticated) 439 A = Associated Data (to be authenticated only) 440 X = neither encrypted nor authenticated 442 Figure 4: AEAD SRTCP inputs when encryption flag = 1. 444 1.6.2. Unencrypted SRTCP packets 446 When the encryption flag is set to 0, all of the data up to and 447 including the SRTCP index is treated as AAD. Figure 5 shows how the 448 fields of an RTCP packet are to be treated when the encryption flag 449 is set to 0. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 A |V=2|P| RC | Packet Type | length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 A | synchronization source (SSRC) of Sender | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 A | sender info | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 A | report block 1 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 A | report block 2 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 A | ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 A |V=2|P| SC | Packet Type | length | 467 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 468 A | SSRC/CSRC_1 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 A | SDES items | 471 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 472 A | ... | 473 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 474 A |0| SRTCP index | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 X | SRTCP MKI (optional)index | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 X : authentication tag (NOT RECOMMENDED) : 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 A = Associated Data (to be authenticated only) 482 X = neither encrypted nor authenticated 484 Figure 5: AEAD SRTCP inputs when encryption flag = 0. 486 1.7. Initialization of the Counters 488 When an AEAD Crypto Context is first established, both the SRTCP 489 index and the rollover counter are set to zero. The Sequence Number 490 is set to a value passed to it by RTP. When the context is rekeyed 491 these counters keep their current values and are not reset to zero. 492 These conventions assist in making a seamless transition from the old 493 key (if any) to the new key despite of the fact that packets are 494 allowed to arrive out of order. 496 As mentioned in section 1.1, AES-GCM and AES-CCM both use a Block 497 Counter which is reset at the start of each packet. For AES-CCM it 498 is reset to 0 and for AES-GCM it is reset to 1. 500 1.8. Prevention of IV Reuse 502 For a given key it is critical that the IV not repeat. This reduces 503 to the problem of insuring neither the Packet Counter nor the SRTCP 504 index do not repeat before the AEAD instantiation is rekeyed. 506 Processing MUST cease if either the 48-bit Packet Counter or the 507 31-bit SRTCP index cycles back to their initial value. Processing 508 MUST NOT resume until a new SRTP/SRTCP session has been established 509 using a new shared secret master key and shares master salt. 510 Ideally, a rekey should be done well before either of these counters 511 cycle. 513 2. AEAD parameters for SRTP and SRTCP 515 In general, any AEAD algorithm can accept inputs with varying 516 lengths, but each algorithm can accept only a limited range of 517 lengths for a specific parameter. In this section, we describe the 518 constraints on the parameter lengths that any AEAD algorithm must 519 support to be used in AEAD-SRTP. Additionally we specify a complete 520 parameter set for two specific AEAD algorithms, namely AES-GCM and 521 AES-CCM. 523 2.1. Generic AEAD Parameter Constraints 525 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 526 constraints listed below: 528 PARAMETER Meaning Value 530 A_MAX maximum additional MUST be at least 12 octets 531 authenticated data 532 length 533 N_MIN minimum nonce (IV) MUST be no more than 12 octets 534 length 535 N_MAX maximum nonce (IV) MUST be at least 12 octets 536 length 537 C_MAX maximum ciphertext MUST be at most 2^16-40 octets 538 length per invocation SHOULD be at least 2232 540 The upper bound on C_MAX is obtained by subtracting away a 20-octet 541 IP header, an 8-octet UDP header, and a 12-octet RTP header out of 542 the largest possible IP packet, the total length of which is 2^16 543 octets. 545 Similarly the lower bound on C_MAX is based on the maximum 546 transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many 547 RTP applications use very short payloads (for example, the G.729 548 codec used in VoIP can be as short as 20 octets), implementations 549 that only support a maximum ciphertext length smaller than 2232 550 octets are permitted under this RFC. However, in the interest of 551 maximizing interoperability between various AEAD implementations, the 552 use of C_MAX values less than 2232 is discouraged. 554 For sake of clarity we specify two additional parameters: 556 Authentication Tag Length MUST be either 8, 12, or 16 557 octets 558 Maximum number of invocations MUST be at most 2^48 for SRTP 559 for a given instantiation MUST be at most 2^31 for SRTCP 561 The reader is reminded that the plaintext is shorter than the 562 ciphertext by exactly the length of the AEAD authentication tag. 564 2.2. AES-GCM for SRTP/SRTCP 566 AES-GCM is a family of AEAD algorithms built around the AES block 567 cipher algorithm. AES-GCM uses AES counter mode for encryption and 568 Galois Message Authentication Code (GMAC) for authentication. A 569 detailed description of the AES-GCM family can be found in 570 [RFC5116]. The following members of the AES-GCM family may be used 571 with SRTP/SRTCP: 573 Table 1: AES-GCM algorithms for SRTP/SRTCP 574 Name Key Size Auth. Tag Size Reference 575 ================================================================ 576 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 577 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 578 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 579 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 580 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 581 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 583 Any implementation of AES-GCM SRTP SHOULD support both 584 AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the 585 four other variants shown in the table. 587 In addition to the Packet Counter used in the formation of IVs, each 588 instantiation of AES-GCM has a block counter which is incremented 589 each time AES is called to produce a 16-octet output block. The 590 block counter is reset to "1" each time AES-GCM is invoked to process 591 a new packet. The 128-bit concatentation of the IV and the block 592 counter is input to AES and the output is used as a block of key that 593 is XORed to the next block of data to be encrypted/decypted. 595 1 1 1 1 1 1 596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 597 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 598 | initialization | block | 599 | vector | counter | 600 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 602 Figure 6: AES Inputs for Counter Mode Encryption 604 2.3. AES-CCM for SRTP/SRTCP 606 AES-CCM is another family of AEAD algorithms built around the AES 607 block cipher algorithm. AES-GCM uses AES counter mode for encryption 608 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 609 for authentication. A detailed description of the AES-CCM family can 610 be found in [RFC5116]. The following members of the AES-CCM family 611 may be used with SRTP/SRTCP: 613 Table 2: AES-CCM algorithms for SRTP/SRTCP 614 Name Key Size Auth. Tag Size Reference 615 ================================================================ 616 AEAD_AES_128_CCM 16 octets 16 octets [RFC5116] 617 AEAD_AES_256_CCM 32 octets 16 octets [RFC5116] 619 Any implementation of AES-CCM SRTP/SRTCP SHOULD support both 620 AEAD_AES_128_CCM and AEAD_AES_256_CCM. 622 In addition to the Packet Counter used in the formation of IVs, 623 each instantiation of AES-CCM has a block counter which is 624 incremented each time AES is called to produce a 16-octet output 625 block. The block counter is reset to "0" each time AES-CCM is 626 invoked to process a new packet. As with AES-GCM, the 128-bit 627 concatentation of the IV abd the block counter is input to AES to 628 produce a block of key that is XORed to the next block of data to 629 be encrypted/decypted. 631 AES-CCM uses a flag octet that conveys information about the length 632 of the authentication tag, length of the block counter, and presence 633 of additional authenticated data. For AES-CCM in SRTP/SRTCP, the 634 flag octet has the hex value 5A if an 8-octet authentication tag is 635 used, 6A if a 12-octet authentication tag is used, and 7A if a 636 16-octet authentication tag is used. The flag octet is one of the 637 inputs to AES during the counter mode encryption of the plaintext. 639 2.4. Key Derivation Functions 641 A Key Derivation Function (KDF) is used to derive all of the required 642 encryption and authentication keys from a secret value shared by the 643 two endpoints. Both the AEAD_AES_128_GCM algorithms and the 644 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 645 Derivation Function described in [RFC3711]. Both the 646 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 647 use the AES_256_CM_PRF Key Derivation Function described in [RFC 648 6188]. 650 3. Security Considerations 652 3.1. Handling of Security Critical Parameters 654 As with any security process, the implementer must take care to 655 ensure cryptographically sensitive parameters are properly handled. 656 Many of these recommendations hold for all SRTP cryptographic 657 algorithms, but we include them here to emphasize their importance. 659 - If the master salt is to be kept secret it MUST be properly 660 erased when no longer needed. 661 - The secret master key and all keys derived from it MUST be kept 662 secret. All keys MUST be properly erased when no longer 663 needed. 664 - Packets that fail the authentication check SHOULD be silently 665 discarded. 666 - The sender MUST increment the Packet Counter after each SRTP 667 packet is processed. 668 - The sender MUST increment the SRTCP index after each SRTCP 669 packet is processed. 670 - At the start of each packet the block counter MUST be reset (to 671 0 for CCM, to 1 for GCM). The block counter is incremented 672 after each block key has been produced, but it MUST NOT be 673 allowed to exceed 2^32-1. 674 - Each time a rekey occurs the initial values of the invocation 675 counter and SRTCP index MUST be saved. 676 - Processing MUST cease if the 48-bit Packet Counter or the 31-bit 677 SRTCP index cycles back to its initial value. Processing MUST 678 NOT resume until a new SRTP/SRTCP session has been established 679 using a new SRTP master key. Ideally, a rekey should be done 680 well before either of these counters cycle. 682 3.2. Size of the Authentication Tag 684 We require that the AEAD authentication tag must be at least 8 685 octets, significantly reducing the probability of an adversary 686 successfully introducing fraudulent data. The goal of an 687 authentication tag is to minimize the probability of a successful 688 forgery occurring anywhere in the network we are attempting to 689 defend. There are three relevant factors: how low we wish the 690 probability of successful forgery to be (prob_success), how many 691 attempts the adversary can make (N_tries) and the size of the 692 authentication tag in bits (N_tag_bits). Then 694 prob_success < expected number of successes 695 = N_tries * 2^-N_tag_bits. 697 Suppose an adversary wishes to introduce a forged or altered packet 698 into a target network by randomly selecting an authentication value 699 until by chance they hit a valid authentication tag. The table below 700 summarizes the relationship between the number of forged packets the 701 adversary has tried, the size of the authentication tag, and the 702 probability of a compromise occurring (i.e. at least one of the 703 attempted forgeries having a valid authentication tag). The reader 704 is reminded that the forgery attempts can be made over the entire 705 network, not just a single link, and that frequently changing the key 706 does not decrease the probability of a compromise occurring. 708 |==================+========================================| 709 | Authentication | Probability of a Compromise Occurring | 710 | Tag Size |------------+-------------+-------------| 711 | (octets) | 2^-30 | 2^-20 | 2^-10 | 712 |==================+=============+=============+============| 713 | 4 | 2^2 tries | 2^12 tries | 2^22 tries | 714 |==================+============+=============+=============| 715 | 8 | 2^34 tries | 2^44 tries | 2^54 tries | 716 |==================+============+=============+=============| 717 | 12 | 2^66 tries | 2^76 tries | 2^86 tries | 718 |==================+============+=============+=============| 719 | 16 | 2^98 tries | 2^108 tries | 2^118 tries | 720 |==================+============+=============+=============| 722 Table 1: Probability of a compromise occurring for a given 723 number of forgery attempts and tag size. 725 4. IANA Considerations 727 RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to 728 a particular AEAD algorithm in SRTP. In order to allow SDP to signal 729 the use of the algorithms defined in this document, IANA will 730 register the following crypto suites into the subregistry for SRTP 731 crypto suites under the SRTP transport of the SDP Security 732 Descriptions: 734 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 735 "AEAD_AES_256_GCM" / 736 "AEAD_AES_128_GCM_8" / 737 "AEAD_AES_256_GCM_8" / 738 "AEAD_AES_128_GCM_12" / 739 "AEAD_AES_256_GCM_12" / 740 "AEAD_AES_128_CCM" / 741 "AEAD_AES_256_CCM" / 742 srtp-crypto-suite-ext 744 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it 745 also corresponds to the use of an AEAD algorithm in SRTP. In order 746 to allow the use of the algorithms defined in this document in 747 DTLS-SRTP, IANA will also register the following SRTP Protection 748 Profiles: 750 SRTP_AEAD_AES_128_GCM 751 SRTP_AEAD_AES_256_GCM 752 SRTP_AEAD_AES_128_GCM_8 753 SRTP_AEAD_AES_256_GCM_8 754 SRTP_AEAD_AES_128_GCM_12 755 SRTP_AEAD_AES_256_GCM_12 756 SRTP_AEAD_AES_128_CCM 757 SRTP_AEAD_AES_256_CCM 759 5. Acknowledgements 761 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 762 and many other reviewers who provided valuable comments on earlier 763 drafts of this document. 765 6. References 767 6.1. Normative References 769 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 770 Mode for Authentication and Confidentiality", U.S. 771 National Institute of Standards and Technology http:// 772 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 774 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 775 Recommendation for Block Cipher Modes of Operation: 776 Galois/Counter Mode (GCM) and GMAC.", U.S. National 777 Institute of Standards and Technology http:// 778 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, March 1997. 783 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 784 K. Norrman, "The Secure Real-time Transport Protocol 785 (SRTP)", RFC 3711, March 2004. 787 [RFC4658] Andreasen, F., Baugher, M., and D.Wing, "Session 788 Description Protocol (SDP): Security Descriptions for 789 Media Streams", RFC 4568, July 2006. 791 [RFC5116] McGrew, D., "An Interface and Algorithms for 792 Authenticated Encryption with Associated Data", RFC 5116, 793 January 2008. 795 [RFC5116] McGrew, D., "An Interface and Algorithms for 796 Authenticated Encryption with Associated Data", RFC 5116, 797 January 2008. 799 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 800 Algorithms with the Encrypted Payload of the Internet Key 801 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. 803 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 804 Security (DTLS) Extension to Establish Keys for the Secure 805 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 807 [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" 808 RFC 6811, March 2011 810 6.2. Informative References 812 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 813 Relations among notions and analysis of the generic 814 composition paradigm", Proceedings of ASIACRYPT 2000, 815 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 816 www-cse.ucsd.edu/users/mihir/papers/oem.html. 818 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 819 and Key Establishment", Springer, 2003 . 821 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 822 CryptoToolkit/modes/800-38_Series_Publications/ 823 SP800-38B.pdf. 825 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 826 provably repairing the SSH authenticated encryption 827 scheme: A case study of the Encode-then-Encrypt-and-MAC 828 paradigm", ACM Transactions on Information and System Secu 829 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 830 TISSEC04/. 832 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 833 than Real: Security Challenges in Virtual Machine Based 834 Computing Environments", Proceedings of the 10th Workshop 835 on Hot Topics in Operating Systems http:// 836 www.stanford.edu/~talg/papers/HOTOS05/ 837 virtual-harder-hotos05.pdf. 839 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 840 Proceedings of the 9th Annual Workshop on Selected Areas 841 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 842 proposedmodes/ccm/ccm-ad1.pdf, 2002. 844 [MODES] Dworkin, M., "NIST Special Publication 800-38: 845 Recommendation for Block Cipher Modes of Operation", U.S. 846 National Institute of Standards and Technology http:// 847 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 849 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 850 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 851 '04, http://eprint.iacr.org/2004/193, December 2004. 853 [R02] Rogaway, P., "Authenticated encryption with Associated- 854 Data", ACM Conference on Computer and Communication 855 Security (CCS'02), pp. 98-107, ACM Press, 856 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 858 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 859 Hashing for Message Authentication", RFC 2104, 860 February 1997. 862 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 863 Requirements for Security", BCP 106, RFC 4086, June 2005. 865 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 866 (GCM) in IPsec Encapsulating Security Payload (ESP)", 867 RFC 4106, June 2005. 869 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 870 Key Management", BCP 107, RFC 4107, June 2005. 872 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 873 RFC 4303, December 2005. 875 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 876 Mode with IPsec Encapsulating Security Payload (ESP)", 877 RFC 4309, December 2005. 879 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 880 Transform Carrying Roll-Over Counter for the Secure Real- 881 time Transport Protocol (SRTP)", RFC 4771, January 2007. 883 Author's Address 885 David A. McGrew 886 Cisco Systems, Inc. 887 510 McCarthy Blvd. 888 Milpitas, CA 95035 889 US 890 Phone: (408) 525 8651 891 Email: mcgrew@cisco.com 892 URI: http://www.mindspring.com/~dmcgrew/dam.htm 894 Kevin M. Igoe 895 NSA/CSS Commercial Solutions Center 896 National Security Agency 897 EMail: kmigoe@nsa.gov 899 Acknowledgement 901 Funding for the RFC Editor function is provided by the IETF 902 Administrative Support Activity (IASA).