idnits 2.17.1 draft-ietf-avt-srtp-aes-gcm-02.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 (October 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CCM' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC6811' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFCxxx' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 800, 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: May 03, 2012 National Security Agency 6 October 31, 2011 8 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 9 draft-ietf-avt-srtp-aes-gcm-02 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 May 03, 2012. 28 Copyright Notice 30 Copyright (c) 2011 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).....5 57 1.2.3. SRTP IV formation for AES-GCM and AES-CCM..............6 58 1.2.4. SRTCP IV formation for AES-GCM and AES-CCM.............7 59 1.2.5. AEAD Processing of SRTP Packets........................8 60 1.2.6. AEAD Processing of SRTCP Packets.......................8 61 1.2.6.1. Encrypted SRTCP packets...........................9 62 1.2.6.2. Unencrypted SRTCP packets........................10 63 2. AEAD parameters for SRTP and SRTCP..............................10 64 2.1. Generic AEAD Parameter Constraints.........................11 65 2.2. AES-GCM for SRTP/SRTCP.....................................11 66 2.3. AES-CCM for SRTP/SRTCP.....................................12 67 2.4. Key Derivation Functions...................................13 68 3. Security Considerations.........................................13 69 3.1. Header Extensions..........................................13 70 3.2. Size of the Authentication Tag.............................13 71 4. IANA Considerations.............................................14 72 5. Acknowledgements................................................15 73 6. References......................................................16 74 6.1. Normative References.......................................16 75 6.2. Informative References.....................................17 77 1. Introduction 79 The Secure Real-time Transport Protocol (SRTP) is a profile of the 80 Real-time Transport Protocol (RTP), which can provide 81 confidentiality, message authentication, and replay protection to the 82 RTP traffic and to the control traffic for RTP, the Real-time 83 Transport Control Protocol (RTCP). 85 SRTP/SRTCP assumes that both the sender and recipient have a shared 86 secret master key and a shared secret master salt. As described in 87 sections 4.3.1 and 4.3.3 of [RFC3711], a Key Derivation Function is 88 applied to these secret values to obtain separate encryption keys, 89 authentication keys and salting keys for SRTP and for SRTCP. (Note: 90 As will be explained below, AEAD SRTP/SRTCP does not make use of 91 these authentication keys.) 92 Authenticated encryption [BN00] is a form of encryption that, in 93 addition to providing confidentiality for the plaintext that is 94 encrypted, provides a way to check its integrity and authenticity. 95 Authenticated Encryption with Associated Data, or AEAD [R02], adds 96 the ability to check the integrity and authenticity of some 97 Associated Data (AD), also called "additional authenticated data", 98 that is not encrypted. This specification makes use of the interface 99 to a generic AEAD algorithm as defined in [RFC5116]. 101 The Advanced Encryption Standard (AES) is a block cipher that 102 provides a high level of security, and can accept different key 103 sizes. Two families of AEAD algorithm families, AES Galois/Counter 104 Mode (AES-GCM) and AES Cipher Block Chaining/Counter Mode (AES/CCM), 105 are based upon AES. This specification makes use of the AES versions 106 that use 128-bit and 256-bit keys, which we call AES-128 and AES-256, 107 respectively. 109 The Galois/Counter Mode (GCM) of operation and the Counter with CBC 110 MAC (CCM) mode are AEAD modes of operation for block ciphers. Both 111 use counter mode to encrypt the data, an operation that can be 112 efficiently pipelined. Further, GCM authentication uses operations 113 that are particularly well suited to efficient implementation in 114 hardware, making it especially appealing for high-speed 115 implementations, or for implementations in an efficient and compact 116 circuit. CCM is well suited for use in compact software 117 implementations. This specification uses GCM and CCM with both 118 AES-128 and AES-256. 120 In summary, this document defines how to use AEAD algorithms, 121 particularly AES-GCM and AES-CCM, to provide confidentiality and 122 message authentication within SRTP and SRTCP packets. 124 1.1. Conventions Used In This Document 126 The following terms have very specific meanings in the context of 127 this RFC: 129 Crypto Context For the purposes of this document a crypto context 130 is the outcome of any process which results in 131 authentication of each participant in the SRTP 132 session and in their possession of a shared secret 133 master key and a shared master salt. Details of 134 how the maser key and master salt are established 135 are outside the scope of this document. The 136 master key MUST be at least as large as the 137 encryption key. The SRTP/SRTCP Key Derivation 138 Function (KDF) defined in [RFC3711] is applied to 139 the master key and master SALT to derive the 140 SRTP_encr_key, SRTCP_encr_key, SRTP_SALT, and 141 SRTCP_SALT. Authentication keys are not used in 142 AEAD. 144 Instantiation Once keys have been established, an instance of 145 the AEAD algorithm is created using the 146 appropriate key and salt. In a point-to-point 147 scenario, each participant in the SRTP/SRTCP 148 session will need four instantiations of the AEAD 149 algorithm; one for inbound SRTP traffic, one for 150 outbound SRTP traffic source, one for inbound 151 SRTCP traffic, and one for outbound SRTCP traffic 152 source. See section 1.2 for details on what is 153 required of each instantiation. 155 Invocation SRTP/SRTCP data streams are broken into packets. 156 Each packet is processed by a single invocation of 157 the appropriate instantiation of the AEAD 158 algorithm. 160 Each AEAD instantiation has its own key, a 48-bit zero-based packet 161 counter that is incremented after that particular instantiation has 162 been invoked to process a data packet, and a 32-bit one-based block 163 counter which is reset to one each time a packet has been processed. 164 (Note: for processing SRTCP packets, a 32-bit packet counter will 165 suffice). As we shall see in sections 1.2.3 and 1.2.4, the packet 166 counter plays a crucial role in the formation of the IV. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 1.2. AEAD processing for SRTP 174 We first define how to use a generic AEAD algorithm in SRTP, then we 175 describe the specific use of the AES-128-GCM and AES-256-GCM 176 algorithms. 178 The use of an AEAD algorithm is defined by expressing the AEAD 179 encryption algorithm inputs in terms of SRTP fields and data 180 structures. The AEAD encryption inputs are as follows: 182 Key This input is the SRTP encryption key 183 (SRTP_encr_key) produced from the shared 184 secret master key using the key derivation 185 process. (Note that the SRTP_auth_key is 186 not used). 188 Associated Data This is data that is to be authenticated 189 but not encrypted. In SRTP, the associated 190 data consists of the entire RTP header, 191 including the list of CSRC identifiers (if 192 present) and the RTP header extension (if 193 present), as shown in Figure 2. 195 Plaintext Data that is to be both encrypted and 196 authenticated. In SRTP this consists of 197 the RTP payload, the RTP padding and the 198 RTP pad count fields (if the latter two 199 fields are present) as shown in Figure 2. 200 The padding service provided by RTP is not 201 needed by the AEAD encryption algorithm, so 202 the RTP padding and RTP pad count fields 203 SHOULD be omitted. 205 Initialization Vector Each SRTP/SRTCP packet has its own 12-octet 206 initialization vector (IV). Construction 207 of this IV is covered in more detail 208 below. 210 The AEAD encryption algorithm accepts these four inputs and returns a 211 Ciphertext field. 213 1.2.1. AEAD versus SRTP/SRTCP Authentication 215 The reader is reminded that in addition to providing confidentiality 216 for the plaintext that is encrypted, an AEAD algorithm also also 217 provides a mechanism that allows the intended recipient to check the 218 data integrity and authenticity of the plaintext and associated 219 data. The AEAD authentication tag is incorporated into the 220 Ciphertext field by RFC 5116, thus AEAD does not make use of the 221 SRTP/SRTCP Authentication Tag fields defined in RFC 3711. (Note that 222 this means that the cipher text will be longer than the plain text by 223 precisely the length of the AEAD authentication tag.) 225 The AEAD message authentication mechanism MUST be the primary message 226 authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP 227 authentication mechanisms SHOULD NOT be used with any AEAD algorithm 228 and the optional SRTP Authentication Tag is NOT RECOMMEDNDED and 229 SHOULD NOT be present. 231 Rationale. Some applications use the SRTP/SRTCP Authentication 232 Tag as a means of conveying additional information, notably 233 [RFC4771]. This document retains the Authentication Tag field 234 primarily to preserve compatibility with these applications. 236 1.2.2. Values used to form the Initialization Vector (IV) 238 The initialization vector for an SRTP packet is formed from the: 240 SSRC The 4-octet Synchronization Source identifier 241 (SSRC), found in the RTP header. 243 Packet Counter Each AEAD instantiation MUST maintain a 6 octet 244 zero-based packet counter which is incremented 245 after a given instantiation has been invoked to 246 process a packet of data. The packet counter is 247 mixed with the salt and SSRC to populate the 248 invocation field discussed in NIST Special 249 Publication 800 38-D [GCM], "Recommendation for 250 Block Cipher Modes of Operation: Galois/Counter 251 Mode (GCM) and GMAC". As we shall see below, 252 the packet counter is used to insure each packet 253 gets a unique initialization vector. 255 Sequence Number The 2-octet RTP Sequence Number (SEQ), found in 256 the RTP header. SEQ is just the two least 257 significant bytes of the packet counter. 259 Rollover Counter A 4-octet Rollover Counter (ROC), maintained by 260 both sides of the link. The ROC is just the 4 261 most significant octets of the packet counter. 263 SALT A 12-octet SRTP session encryption salt produced 264 by the SRTP Key Derivation Function (KDF) (see 265 section 2.4). 267 1.2.3. SRTP IV formation for AES-GCM and AES-CCM 269 AES-GCM and AES-CCM SRTP use a 12 byte initialization vector which is 270 formed as follows. A 12-octet string is formed by concatenating 271 2-octets of zeroes, the 4-octet SSRC, and the 6-octet invocation 272 counter. The resulting string is bitwise exclusive-ored with the 273 12-octet salt to form the 12-octet IV 275 0 0 0 0 0 0 0 0 0 0 1 1 276 0 1 2 3 4 5 6 7 8 9 0 1 277 +--+--+--+--+--+--+--+--+--+--+--+--+ 278 |00|00| SSRC | Packet_Counter |---+ 279 +--+--+--+--+--+--+--+--+--+--+--+--+ | 280 | 281 +--+--+--+--+--+--+--+--+--+--+--+--+ | 282 | Encryption Salt |->(+) 283 +--+--+--+--+--+--+--+--+--+--+--+--+ | 284 | 285 +--+--+--+--+--+--+--+--+--+--+--+--+ | 286 | Initialization Vector |<--+ 287 +--+--+--+--+--+--+--+--+--+--+--+--+ 289 Figure 1: AES-GCM and AES-CCM SRTP 290 Initialization Vector formation. 291 Using the terminology of section 8.2.1. of [GCM], the first six 292 octets of the IV are the fixed field and the last six bytes are the 293 invocation field. 295 1.2.4. SRTCP IV formation for AES-GCM and AES-CCM 297 The initialization vector for an SRTCP packet is formed from the 298 4-octet Synchronization Source identifier (SSRC), 31-bit SRTCP Index 299 (packed zero-filled, right justified into a 4-octet field), and a 300 12-octet SRTCP session encryption salt produced by the SRTP Key 301 Derivation Function (KDF) (see section 2.4). (The 31-bit SRTCP index 302 serves as the invocation counter.) First a 12-octet string is formed 303 by concatenating in order 2-octets of zeroes, the 4-octet SSRC, 2 304 more zero octets, and the 4-octet SRTCP index. The resulting 305 12-octet string is bitwise exclusive-ored into salt; the output of 306 that process is the IV. The process is illustrated in Figure 3. The 307 IV is always exactly 12 octets in length. 309 0 0 0 0 0 0 0 0 0 0 1 1 310 0 1 2 3 4 5 6 7 8 9 0 1 311 +--+--+--+--+--+--+--+--+--+--+--+--+ 312 |00|00| SSRC |00|00|SRTCP Index|---+ 313 +--+--+--+--+--+--+--+--+--+--+--+--+ | 314 | 315 +--+--+--+--+--+--+--+--+--+--+--+--+ | 316 | Encryption Salt |->(+) 317 +--+--+--+--+--+--+--+--+--+--+--+--+ | 318 | 319 +--+--+--+--+--+--+--+--+--+--+--+--+ | 320 | Initialization Vector |<--+ 321 +--+--+--+--+--+--+--+--+--+--+--+--+ 323 Figure 2: SRTCP Initialization Vector formation. 325 Using the terminology of section 8.2.1. of [GCM], the first eight 326 octets of the IV are the fixed field and the last four bytes are the 327 invocation field. 329 1.2.5. AEAD Processing of SRTP Packets 331 All SRTP packets MUST be authenticated and encrypted. Figure 3 below 332 shows which fields of AEAD SRTP packet are to be treated as plaintext 333 and which are to be treated as additional authenticated data. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 A |V=2|P|X| CC |M| Packet Type | sequence number | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 A | timestamp | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 A | synchronization source (SSRC) identifier | 343 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 344 A | contributing source (CSRC) identifiers (optional) | 345 A | .... | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 A | RTP extension (OPTIONAL) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 P | payload ... | 350 P | +-------------------------------+ 351 P | | RTP padding | RTP pad count | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 X : authentication tag (NOT RECOMMENDED) : 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 P = Plaintext (to be encrypted and authenticated) 357 A = Associated Data (to be authenticated only) 358 X = neither encrypted nor authenticated 360 Note: The RTP padding and RP padding count fields are optional 361 and are not recommended 363 Figure 3: AEAD inputs from an SRTP packet. 365 1.2.6. AEAD Processing of SRTCP Packets 367 All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP 368 packet encryption is optional. A sender can select which packets to 369 encrypt, and indicates this choice with a 1-bit encryption flag 370 (located in the leftmost bit of the 32-bit word that contains the 371 SRTCP index) 373 1.2.6.1. Encrypted SRTCP packets 375 When the encryption flag is set to 1, the first 8-octets, the 376 encrpytion flag and 32-bit SRTCP index MUST be treated as AAD. The 377 remaing data MUST be treated as plaintext, and hence is to be both 378 encrypted and AEAD authenticates, save for the optional STCP MKI 379 index and optional SRTCP authentication tag, which are MUST be 380 neither encrypted nor AEAD authenticated. Figure 4 below shows how 381 fields of an RTCP packet are to be treated when the encryption flag 382 is set to 1. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 A |V=2|P| RC | Packet Type | length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 A | synchronization source (SSRC) of Sender | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 P | sender info | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 P | report block 1 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 P | report block 2 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 P | ... | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 P |V=2|P| SC | Packet Type | length | 400 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 401 P | SSRC/CSRC_1 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 P | SDES items | 404 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 405 P | ... | 406 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 407 A |1| SRTCP index | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 X | SRTCP MKI (optional)index | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 X : authentication tag (NOT RECOMMENDED) : 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 P = Plaintext (to be encrypted and authenticated) 415 A = Associated Data (to be authenticated only) 416 X = neither encrypted nor authenticated 418 Figure 4: AEAD SRTCP inputs when encryption flag = 1. 420 1.2.6.2. Unencrypted SRTCP packets 422 When the encryption flag is set to 0, all of the data up to and 423 including the SRTCP index is treated as AAD. Figure 5 shows how the 424 fields of an RTCP packet are to be treated when the encryption flag 425 is set to 0. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 A |V=2|P| RC | Packet Type | length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 A | synchronization source (SSRC) of Sender | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 A | sender info | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 A | report block 1 | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 A | report block 2 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 A | ... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 A |V=2|P| SC | Packet Type | length | 443 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 444 A | SSRC/CSRC_1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 A | SDES items | 447 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 448 A | ... | 449 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 450 A |0| SRTCP index | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 X | SRTCP MKI (optional)index | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 X : authentication tag (NOT RECOMMENDED) : 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 A = Associated Data (to be authenticated only) 458 X = neither encrypted nor authenticated 460 Figure 5: AEAD SRTCP inputs when encryption flag = 0. 462 2. AEAD parameters for SRTP and SRTCP 464 In general, any AEAD algorithm can accept inputs with varying 465 lengths, but each algorithm can accept only a limited range of 466 lengths for a specific parameter. In this section, we describe the 467 constraints on the parameter lengths that any AEAD algorithm must 468 support to be used in AEAD-SRTP. Additionally we specify a complete 469 parameter set for two specific AEAD algorithms, namely AES-GCM and 470 AES-CCM. 472 2.1. Generic AEAD Parameter Constraints 474 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 475 constraints listed below: 477 PARAMETER Meaning Value 479 A_MAX maximum additional MUST be at least 12 octets 480 authenticated data 481 length 482 N_MIN minimum nonce (IV) MUST be no more than 12 octets 483 length 484 N_MAX maximum nonce (IV) MUST be at least 12 octets 485 length 486 C_MAX maximum ciphertext MUST be at most 2^16-40 octets 487 length per invocation SHOULD be at least 2232 489 The upper bound on C_MAX is obtained by subtracting away a 20-octet 490 IP header, an 8-octet UDP header, and a 12-octet RTP header out of 491 the largest possible IP packet, the total length of which is 2^16 492 octets. 494 Similarly the lower bound on C_MAX is based on the maximum 495 transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many 496 RTP applications use very short payloads (for example, the G.729 497 codec used in VoIP can be as short as 20 octets), implementations 498 that only support a maximum ciphertext length smaller than 2232 499 octets are permitted under this RFC. However, in the interest of 500 maximizing interoperability between various AEAD implementations, the 501 use of C_MAX values less than 2232 is discouraged. 503 For sake of clarity we specify two additional parameters: 505 Authentication Tag Length MUST be either 8, 12, or 16 506 octets 507 Maximum number of invocations MUST be at most 2^48 for SRTP 508 for a given instantiation MUST be at most 2^31 for SRTCP 510 The reader is reminded that the plaintext is shorter than the 511 ciphertext by exactly the length of the AEAD authentication tag. 513 2.2. AES-GCM for SRTP/SRTCP 515 AES-GCM is a family of AEAD algorithms built around the AES block 516 cipher algorithm. AES-GCM uses AES counter mode for encryption and 517 Galois Message Authentication Code (GMAC) for authentication. A 518 detailed description of the AES-GCM family can be found in 520 [RFC5116]. The following members of the AES-GCM family may be used 521 with SRTP/SRTCP: 523 Table 1: AES-GCM algorithms for SRTP/SRTCP 524 Name Key Size Auth. Tag Size Reference 525 ================================================================ 526 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 527 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 528 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 529 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 530 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 531 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 533 Any implementation of AES-GCM SRTP MUST support both 534 AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the 535 four other variants shown in the table. 537 In addition to the invocation counter used in the formation of IVs, 538 each instantiation of AES-GCM has a block counter which is 539 incremented each time AES is called to produce a 16-octet output 540 block. The block counter is reset to "1" each time AES-GCM is 541 invoked. 543 1 1 1 1 1 1 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 545 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 546 | | salt | | salt xor | block | 547 | salt | xor | salt | invocation | counter | 548 | | ssrc | | counter | | 549 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 551 Figure 5: AES Inputs for Counter Mode Encryption in GCM 553 2.3. AES-CCM for SRTP/SRTCP 555 AES-CCM is another family of AEAD algorithms built around the AES 556 block cipher algorithm. AES-GCM uses AES counter mode for encryption 557 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 558 for authentication. A detailed description of the AES-CCM family can 559 be found in [RFC5116]. The following members of the AES-CCM family 560 may be used with SRTP/SRTCP: 562 Table 2: AES-CCM algorithms for SRTP/SRTCP 563 Name Key Size Auth. Tag Size Reference 564 ================================================================ 565 AEAD_AES_128_CCM 16 octets 16 octets [RFC5116] 566 AEAD_AES_256_CCM 32 octets 16 octets [RFC5116] 568 Any implementation of AES-CCM SRTP/SRTCP MUST support both 569 AEAD_AES_128_CC and AEAD_AES_256_CCM. 571 In addition to the invocation counter used in the formation of 572 IVs, each instantiation of AES-CCM has a block counter which is 573 incremented each time AES is called to produce a 16-octet output 574 block. The block counter is reset to "0" each time AES-CCM is 575 invoked. 577 AES-CCM uses a flag octet that conveys information about the length 578 of the authentication tag, length of the block counter, and presence 579 of additional authenticated data. For AES-CCM in SRTP/SRTCP, the 580 flag octet has the hex value 5A if an 8-octet authentication tag is 581 used, 6A if a 12-octet authentication tag is used, and 7A if a 582 16-octet authentication tag is used. The flag octet is one of the 583 inputs to AES during the counter mode encryption of the plaintext. 585 2.4. Key Derivation Functions 587 A Key Derivation Function (KDF) is used to derive all of the required 588 encryption and authentication keys from a secret value shared by the 589 two endpoints. Both the AEAD_AES_128_GCM algoritms and the 590 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 591 Derivation Function described in [RFC3711]. Both the 592 AEAD_AES_256_GCM algorithms and the AEAD_AES_128_CCM algorithms MUST 593 use the AES_256_CM_PRF Key Derivation Function described in [RFC 594 6188]. 596 3. Security Considerations 598 3.1. Header Extensions 600 As described in section 1.2.5, this document requires all header 601 extensions to be treated as Additional Authenticated Data. RFC XXXX 602 describes a separate mechanism for the encryption and integrity 603 tagging of these header extensions. Middle boxes are often used to 604 process these headers extensions independently of the processing done 605 at the SRTP/SRTCP endpoint. The reader is cautioned to ensure the 606 level of security provided at these middle boxes is appropriate to 607 the level of risk posed by a compromise of these fields. Similarly, 608 the mechanism used to securely deliver the header encryption and 609 integrity keys to the middle boxes must be robust enough to 610 adequately authenticate and protect these keys. 612 3.2. Size of the Authentication Tag 614 We require that the AEAD authentication tag must be at least 8 615 octets, significantly reducing the probability of an adversary 616 successfully introducing fraudulent data. The goal of an 617 authentication tag is to minimize the probability of a successful 618 forgery occurring anywhere in the network we are attempting to 619 defend. There are three relevant factors: how low we wish the 620 probability of successful forgery to be (prob_success), how many 621 attempts the adversary can make (N_tries) and the size of the 622 authentication tag in bits (N_tag_bits). Then 624 prob_success < expected number of successes 625 = N_tries * 2^-N_tag_bits. 627 Suppose an adversary wishes to introduce a forged or altered packet 628 into a target network by randomly selecting an authentication value 629 until by chance they hit a valid authentication tag. The table below 630 summarizes the relationship between the number of forged packets the 631 adversary has tried, the size of the authentication tag, and the 632 probability of a compromise occurring (i.e. at least one of the 633 attempted forgeries having a valid authentication tag). The reader 634 is reminded that the forgery attempts can be made over the entire 635 network, not just a single link, and that frequently changing the key 636 does not decrease the probability of a compromise occurring. 638 |==================+========================================| 639 | Authentication | Probability of a Compromise Occurring | 640 | Tag Size |------------+-------------+-------------| 641 | (octets) | 2^-30 | 2^-20 | 2^-10 | 642 |==================+=============+=============+============| 643 | 4 | 2^2 tries | 2^12 tries | 2^22 tries | 644 |==================+============+=============+=============| 645 | 8 | 2^34 tries | 2^44 tries | 2^54 tries | 646 |==================+============+=============+=============| 647 | 12 | 2^66 tries | 2^76 tries | 2^86 tries | 648 |==================+============+=============+=============| 649 | 16 | 2^98 tries | 2^108 tries | 2^118 tries | 650 |==================+============+=============+=============| 652 Table 1: Probability of a compromise occurring for a given 653 number of forgery attempts and tag size. 655 4. IANA Considerations 657 RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to 658 a particular AEAD algorithm in SRTP. In order to allow SDP to signal 659 the use of the algorithms defined in this document, IANA will 660 register the following crypto suites into the subregistry for SRTP 661 crypto suites under the SRTP transport of the SDP Security 662 Descriptions: 664 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 665 "AEAD_AES_256_GCM" / 666 "AEAD_AES_128_GCM_8" / 667 "AEAD_AES_256_GCM_8" / 668 "AEAD_AES_128_GCM_12" / 669 "AEAD_AES_256_GCM_12" / 670 "AEAD_AES_128_CCM" / 671 "AEAD_AES_256_CCM" / 672 srtp-crypto-suite-ext 674 DTLS-SRTR [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it 675 also corresponds to the use of an AEAD algorithm in SRTP. In order 676 to allow the use of the algorithms defined in this document in 677 DTLS-SRTP, IANA will also register the following SRTP Protection 678 Profiles: 680 SRTP_AEAD_AES_128_GCM 681 SRTP_AEAD_AES_256_GCM 682 SRTP_AEAD_AES_128_GCM_8 683 SRTP_AEAD_AES_256_GCM_8 684 SRTP_AEAD_AES_128_GCM_12 685 SRTP_AEAD_AES_256_GCM_12 686 SRTP_AEAD_AES_128_CCM 687 SRTP_AEAD_AES_256_CCM 689 5. Acknowledgements 691 The authors would like to thank Michael Peck, Qin Wu, and many other 692 reviewers who provided valuable comments on earlier drafts of this 693 document. 695 6. References 697 6.1. Normative References 699 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 700 Mode for Authentication and Confidentiality", U.S. 701 National Institute of Standards and Technology http:// 702 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 704 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 705 Recommendation for Block Cipher Modes of Operation: 706 Galois/Counter Mode (GCM) and GMAC.", U.S. National 707 Institute of Standards and Technology http:// 708 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, March 1997. 713 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 714 K. Norrman, "The Secure Real-time Transport Protocol 715 (SRTP)", RFC 3711, March 2004. 717 [RFC5116] McGrew, D., "An Interface and Algorithms for 718 Authenticated Encryption with Associated Data", RFC 5116, 719 January 2008. 721 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 722 Algorithms with the Encrypted Payload of the Internet Key 723 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. 725 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 726 Security (DTLS) Extension to Establish Keys for the Secure 727 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 729 [RFC6811] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" 730 RFC 6811, March 2011 732 [RFCxxx] Lennox, J., "Encryption of Header Extensions in the Secure 733 Real-Time Transport Protocol (SRTP)", RFC xxxx, Nov,2011 735 6.2. Informative References 737 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 738 Relations among notions and analysis of the generic 739 composition paradigm", Proceedings of ASIACRYPT 2000, 740 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 741 www-cse.ucsd.edu/users/mihir/papers/oem.html. 743 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 744 and Key Establishment", Springer, 2003 . 746 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 747 CryptoToolkit/modes/800-38_Series_Publications/ 748 SP800-38B.pdf. 750 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 751 provably repairing the SSH authenticated encryption 752 scheme: A case study of the Encode-then-Encrypt-and-MAC 753 paradigm", ACM Transactions on Information and System Secu 754 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 755 TISSEC04/. 757 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 758 than Real: Security Challenges in Virtual Machine Based 759 Computing Environments", Proceedings of the 10th Workshop 760 on Hot Topics in Operating Systems http:// 761 www.stanford.edu/~talg/papers/HOTOS05/ 762 virtual-harder-hotos05.pdf. 764 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 765 Proceedings of the 9th Annual Workshop on Selected Areas 766 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 767 proposedmodes/ccm/ccm-ad1.pdf, 2002. 769 [MODES] Dworkin, M., "NIST Special Publication 800-38: 770 Recommendation for Block Cipher Modes of Operation", U.S. 771 National Institute of Standards and Technology http:// 772 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 774 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 775 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 776 '04, http://eprint.iacr.org/2004/193, December 2004. 778 [R02] Rogaway, P., "Authenticated encryption with Associated- 779 Data", ACM Conference on Computer and Communication 780 Security (CCS'02), pp. 98-107, ACM Press, 781 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 783 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 784 Hashing for Message Authentication", RFC 2104, 785 February 1997. 787 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 788 Requirements for Security", BCP 106, RFC 4086, June 2005. 790 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 791 (GCM) in IPsec Encapsulating Security Payload (ESP)", 792 RFC 4106, June 2005. 794 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 795 Key Management", BCP 107, RFC 4107, June 2005. 797 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 798 RFC 4303, December 2005. 800 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 801 Mode with IPsec Encapsulating Security Payload (ESP)", 802 RFC 4309, December 2005. 804 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 805 Transform Carrying Roll-Over Counter for the Secure Real- 806 time Transport Protocol (SRTP)", RFC 4771, January 2007. 808 Author's Address 810 David A. McGrew 811 Cisco Systems, Inc. 812 510 McCarthy Blvd. 813 Milpitas, CA 95035 814 US 816 Phone: (408) 525 8651 817 Email: mcgrew@cisco.com 818 URI: http://www.mindspring.com/~dmcgrew/dam.htm 820 Kevin M. Igoe 821 NSA/CSS Commercial Solutions Center 822 National Security Agency 823 EMail: kmigoe@nsa.gov 825 Acknowledgement 827 Funding for the RFC Editor function is provided by the IETF 828 Administrative Support Activity (IASA).