idnits 2.17.1 draft-ietf-avt-srtp-aes-gcm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 8 characters in excess of 72. ** There are 4 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 (July 6, 2009) is 5407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3711' is mentioned on line 248, but not defined == Unused Reference: 'CCM' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 701, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). 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: Standards Track July 6, 2009 5 Expires: July 7, 2010 7 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 8 draft-ietf-avt-srtp-aes-gcm-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 7, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines how AES-GCM, AES-CCM, and other Authenticated 47 Encryption with Associated Data (AEAD) algorithms, can be used to 48 provide confidentiality and data authentication mechanisms in the 49 SRTP protocol. 51 Table of Contents 53 1. Introduction.....................................................2 54 1.1. Conventions Used In This Document...........................3 55 1.2. AEAD processing for SRTP....................................4 56 1.2.1. AEAD Authentication versus SRTP Authentication.........4 57 1.2.2. Initialization Vectors for SRTP........................5 58 1.2.3. Initialization Vectors for SRTCP.......................5 59 1.2.4. Format for SRTP Packet.................................6 60 1.2.5. Packet Format for SRTCP................................7 61 1.2.5.1. Encrypted SRTCP packets...........................7 62 1.2.5.2. Unencrypted SRTCP packets.........................7 63 2. AEAD parameters for SRTP and SRTCP...............................9 64 2.1. Generic AEAD Parameter Constraints..........................9 65 2.2. AES-GCM for SRTP/SRTCP.....................................10 66 2.3. AES-CCM for SRTP/SRTCP.....................................11 67 3. Security Considerations.........................................12 68 4. IANA Considerations.............................................13 69 5. Acknowledgements................................................13 70 6. References......................................................13 71 6.1. Normative References.......................................13 72 6.2. Informative References.....................................14 74 1. Introduction 76 The Secure Real-time Transport Protocol (SRTP) is a profile of the 77 Real-time Transport Protocol (RTP), which can provide 78 confidentiality, message authentication, and replay protection to the 79 RTP traffic and to the control traffic for RTP, the Real-time 80 Transport Control Protocol (RTCP). 82 SRTP/SRTCP assumes that both the sender and recipient have a shared 83 secret master key and a shared secret master salt. As described in 84 sections 4.3.1 and 4.3.3 of [RFC3711], a Key Derivation Function is 85 applied to these secret values to obtain separate encryption keys, 86 authentication keys and salting keys for SRTP and for SRTCP. (Note: 87 As will be explained below, AEAD SRTP/SRTCP does not make use of 88 these authentication keys.) 90 Authenticated encryption [BN00] is a form of encryption that, in 91 addition to providing confidentiality for the plaintext that is 92 encrypted, provides a way to check its integrity and authenticity. 93 Authenticated Encryption with Associated Data, or AEAD [R02], adds 94 the ability to check the integrity and authenticity of some 95 Associated Data (AD), also called "additional authenticated data", 96 that is not encrypted. This specification makes use of the interface 97 to a generic AEAD algorithm as defined in [RFC5116]. 99 The Advanced Encryption Standard (AES) is a block cipher that 100 provides a high level of security, and can accept different key 101 sizes. Two families of AEAD algorithm families, AES Galois/Counter 102 Mode (AES-GCM) and AES Cipher Block Chaining/Counter Mode (AES/CCM), 103 are based upon AES. This specification makes use of the AES versions 104 that use 128-bit and 256-bit keys, which we call AES-128 and AES-256, 105 respectively. 107 The Galois/Counter Mode (GCM) of operation and the Counter with CBC 108 MAC (CCM) mode are AEAD modes of operation for block ciphers. Both 109 use counter mode to encrypt the data, an operation that can be 110 efficiently pipelined. Further, GCM authentication uses operations 111 that are particularly well suited to efficient implementation in 112 harware, making it especially appealing for high-speed 113 implementations, or for implementations in an efficient and compact 114 circuit. CCM is well suited for use in compact software 115 implementations. This specification uses GCM and CCM with both 116 AES-128 and AES-256. 118 In summary, this document defines how to use AEAD algorithms, 119 particularly AES-GCM and AES-CCM, to provide confidentiality and 120 message authentication within SRTP and SRTCP packets. 122 1.1. Conventions Used In This Document 124 The following terms have very specific meanings in the context of 125 this RFC: 127 Crypto Context. For the purposes of this document a security 128 association is the outcome of any process which results in 129 authentication of each patricpant in the SRTP session and in their 130 possesion of a shared secret master key and a shared secret master 131 salt. Details of how the crypto context is established are 132 outside the scope of this document. 134 Instantiation. Once keys have been established, an instance of 135 the AEAD algorithm is created using the appropriate key. In a 136 point-to-point scenario, each participant in the SRTP/SRTCP 137 session will need four instantiations of the AEAD algorithm; one 138 for inbound SRTP traffic, one for outbound SRTP traffic source, 139 one for inbound SRTCP traffic, and one for outbound SRTCP traffic 140 source. Within a given crypto context, all of the encryption keys 141 are derived from the crypto context's shared secret master key and 142 all of the encryption salts are derived from the crypto context's 143 shared secret master salt. 145 Invocation. SRTP/SRTCP data streams are broken into packets. 146 Each packet is processed by a single invocation of the appropriate 147 instantiation of the AEAD algorithm. 149 Each AEAD instantiation has its own invocation counter which is 150 incremented each time that particular instantiation is invoked. As 151 we shall see below, the invocation counter is used to insure each 152 invocation gets a unique initialization vector. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 1.2. AEAD processing for SRTP 160 We first define how to use a generic AEAD algorithm in SRTP, then we 161 describe the specific use of the AES-128-GCM and AES-256-GCM 162 algorithms. 164 The use of an AEAD algorithm is defined by expressing the AEAD 165 encryption algorithm inputs in terms of SRTP fields and data 166 structures. The AEAD encryption inputs are as follows: 168 Key. This input is the SRTP encryption key (SRTP_encr_key) 169 produced from the shared secret master key using the key 170 derivation process. (Note that the SRTP_auth_key is not used). 172 Associated Data. This is data that is to be authenticated but not 173 encrypted. In SRTP, the associated data consists of the entire 174 RTP header, including the list of CSRC identifiers (if present) 175 and the RTP header extension (if present), as shown in Figure 2. 177 Plaintext. This is data that is to be both authenticated and 178 encrypted. In SRTP this consists of the RTP payload, and the RTP 179 padding and RTP pad count fields (if the latter two fields are 180 present), as shown in Figure 2. The padding service provided by 181 RTP is not needed by the AEAD encryption algorithm, so the RTP 182 padding and RTP pad count fields SHOULD be omitted. 184 Initialization Vector (IV). Each SRTP/SRTCP packet has its own 185 12-octet initialization vector. Construction of this IV is 186 covered in more detail below. 188 The AEAD encryption algorithm accepts these four inputs and returns a 189 Ciphertext field. 191 1.2.1. AEAD Authentication versus SRTP Authentication 193 The reader is reminded that in addition to providing confidentiality 194 for the plaintext that is encrypted, an AEAD algorithm also provides 195 a way to check the data integrity and authenticity of the plaintext 196 and associated data. The AEAD integrity check is incorporated into 197 the ciphertext field by RFC 5116, thus AEAD does not make use of the 198 optional SRTP Authentication Tag field. (Note that this means that 199 the cipher text will be longer than the plain text by precisely the 200 length of the AEAD authentication tag.) 202 The AEAD message authentication mechanism MUST be the primary message 203 authentication mechanism for AEAD SRTP. Additional SRTP 204 authentication mechanisms SHOULD NOT be used with any AEAD algorithm 205 and the optional SRTP Authentication Tag SHOULD NOT be present. 207 Rationale. Some applications use the Authentication Tag as a 208 means of conveying additional information, notably [RFC4771]. 209 This document retains the Authentication Tag field primarily to 210 preserve compatibility with these applications. 212 1.2.2. Initialization Vectors for SRTP 214 The initialization vector for an SRTP packet is formed from the 215 4-octet Synchronization Source identifier (SSRC), 4-octet Rollover 216 Counter (ROC), the 2-octet RTP Sequence Number (SEQ), and a 12-octet 217 SRTP session encryption salt produced by the SRTP Key Derivation 218 Function (KDF) as shown in figure 1. (The concatenation of the ROC 219 and SEQ serves as a 6-octet invocation counter.) First, a 2-octet 220 string consisting of zeroes is prepended to the 4-octet SSRC, then 221 the 4-octet ROC appended and 2-octet SEQ is appended to that octet 222 string. The resulting 12-octet string is bitwise exclusive-ored into 223 salt; the output of that process is the IV. The IV is always exactly 224 12 octets in length. 226 0 0 0 0 0 0 0 0 0 0 1 1 227 0 1 2 3 4 5 6 7 8 9 0 1 228 +--+--+--+--+--+--+--+--+--+--+--+--+ 229 |00|00| SSRC | ROC | SEQ |---+ 230 +--+--+--+--+--+--+--+--+--+--+--+--+ | 231 | 232 +--+--+--+--+--+--+--+--+--+--+--+--+ | 233 | Encryption Salt |->(+) 234 +--+--+--+--+--+--+--+--+--+--+--+--+ | 235 | 236 +--+--+--+--+--+--+--+--+--+--+--+--+ | 237 | Initialization Vector |<--+ 238 +--+--+--+--+--+--+--+--+--+--+--+--+ 240 Figure 1: SRTP Initialization Vector formation. 242 1.2.3. Initialization Vectors for SRTCP 244 The initialization vector for an SRTCP packet is formed from the 245 4-octet Synchronization Source identifier (SSRC), 31-bit SRTCP Index 246 (packed zero-filled, right justified into a 4-octet field), and a 247 12-octet SRTP session encryption salt produced by the SRTP Key 248 Derivation Function (KDF) as described in [RFC3711]. (The 31-bit 249 SRTCP index serves as the invocation counter.) First a 12-octet 250 string is formed by concatenating in order 2-octets of zeroes, the 251 4-octet SSRC, 2 more zero octets, and the 4-octet SRTCP index. The 252 resulting 12-octet string is bitwise exclusive-ored into salt; the 253 output of that process is the IV. The process is illustrated in 254 Figure 3. The IV is always exactly 12 octets in length. 256 0 0 0 0 0 0 0 0 0 0 1 1 257 0 1 2 3 4 5 6 7 8 9 0 1 258 +--+--+--+--+--+--+--+--+--+--+--+--+ 259 |00|00| SSRC |00|00|SRTCP Index|---+ 260 +--+--+--+--+--+--+--+--+--+--+--+--+ | 261 | 262 +--+--+--+--+--+--+--+--+--+--+--+--+ | 263 | Encryption Salt |->(+) 264 +--+--+--+--+--+--+--+--+--+--+--+--+ | 265 | 266 +--+--+--+--+--+--+--+--+--+--+--+--+ | 267 | Initialization Vector |<--+ 268 +--+--+--+--+--+--+--+--+--+--+--+--+ 270 Figure 2: SRTCP Initialization Vector formation. 272 1.2.4. Format for SRTP Packet 274 All SRTP packets MUST be authenticated and encrypted. Figure 3 below 275 shows which fields of AEAD SRTP packet are to be treated as 276 plaintext, which are to be treated as additional authenticated data, 277 and which fields are to be treated as additional authenticated data. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 A |V=2|P|X| CC |M| Packet Type | sequence number | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 A | timestamp | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 A | synchronization source (SSRC) identifier | 287 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 288 A | contributing source (CSRC) identifiers (optional) | 289 A | .... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 A | RTP extension (OPTIONAL) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 P | payload ... | 294 P | +-------------------------------+ 295 P | | RTP padding | RTP pad count | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 X : authentication tag (NOT RECOMMENDED) : 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 P = Plaintext (to be encrypted and authenticated) 301 A = Associated Data (to be authenticated only) 302 X = neither encrypted nor authenticated 304 Note: The RTP padding and RP pasdding count fields are optional 305 and are not recommended 307 Figure 3: AEAD inputs from an SRTP packet. 309 1.2.5. Packet Format for SRTCP 311 Unlike SRTP, SRTCP packet encryption is optional (but authentication 312 is mandatory). A sender can select which pakets to encrypt, and 313 indicates this choice with a 1-bit encryption flag (located in the 314 leftmost bit of the 32-bit word that contains the SRTCP index) 316 1.2.5.1. Encrypted SRTCP packets 318 When the encryption flag is set to 1, the first 8-octets, the 319 encrytion flag and SRTCP index are treated as AAD and eight octets 320 and the encryption flag are treated as plaintext. Figure 4 below 321 shows how fields of an RTCP packet are to be treated when the 322 encryption flag is set to 1. 324 1.2.5.2. Unencrypted SRTCP packets 326 When the encryption flag is set to 0, all of the data up to and 327 including the SRTCP index is treated as AAD. Figure 5 shows how the 328 fields of an RTCP packet are to be treated when the encryption flag 329 is set to 0. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 A |V=2|P| RC | Packet Type | length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 A | synchronization source (SSRC) of Sender | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 P | sender info | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 P | report block 1 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 P | report block 2 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 P | ... | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 P |V=2|P| SC | Packet Type | length | 347 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 348 P | SSRC/CSRC_1 | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 P | SDES items | 351 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 352 P | ... | 353 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 354 A |1| SRTCP index | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 X | SRTCP MKI (optional)index | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 X : authentication tag (NOT RECOMMENDED) : 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 P = Plaintext (to be encrypted and authenticated) 362 A = Associated Data (to be authenticated only) 363 X = neither encrypted nor authenticated 365 Figure 4: AEAD inputs for an encrypted SRTCP packet. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 A |V=2|P| RC | Packet Type | length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 A | synchronization source (SSRC) of Sender | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 A | sender info | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 A | report block 1 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 A | report block 2 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 A | ... | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 A |V=2|P| SC | Packet Type | length | 383 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 384 A | SSRC/CSRC_1 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 A | SDES items | 387 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 388 A | ... | 389 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 390 A |0| SRTCP index | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 X | SRTCP MKI (optional)index | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 X : authentication tag (NOT RECOMMENDED) : 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 A = Associated Data (to be authenticated only) 398 X = neither encrypted nor authenticated 400 Figure 5: AEAD inputs for an unencrypted SRTCP packet. 402 2. AEAD parameters for SRTP and SRTCP 404 In general, any AEAD algorithm can accept inputs with varying 405 lengths, but each algorithm can accept only a limited range of 406 lengths for a specific parameter. In this section, we describe the 407 constraints on the parameter lengths that any AEAD algorithm must 408 support to be used in AEAD-SRTP. Additionally we specify a complete 409 parameter set for two specific AEAD algorithms, namely AES-GCM and 410 AES-CCM. 412 2.1. Generic AEAD Parameter Constraints 414 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 415 constraints listed below: 417 PARAMETER Meaning Value 419 A_MAX maximum additional MUST be at least 12 octets 420 authenticated data 421 length 422 N_MIN minimum nonce (IV) MUST be no more than 12 octets 423 length 424 N_MAX maximum nonce (IV) MUST be at least 12 octets 425 length 426 C_MAX maximum ciphertext MUST be at most 2^16-40 octets 427 length per invocation SHOULD be at least 2232 429 The upper bound on C_MAX is obtained by subtracting away a 20-octet 430 IP header, an 8-octet UDP header, and a 12-octet RTP header out of 431 the largest possible IP packet, the total length of which is 2^16 432 octets. 434 Similarly the lower bound on C_MAX is based on the maximum 435 transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many 436 RTP applications use very short payloads (for example, the G.729 437 codec used in VoIP can be as short as 20 octets), implementations 438 that only support a maximum ciphertext length smaller than 2232 439 octets are permitted under this RFC. However, in the interest of 440 maximizing interoperability between various AEAD implementations, the 441 use of C_MAX values less than 2232 is discouraged. 443 For sake of clarity we specify two additional parameters: 445 Authentication Tag Length MUST be either 8, 12, or 16 446 octets 447 Maximum number of invocations MUST be at most 2^48 for SRTP 448 for a given instantiation MUST be at most 2^31 for SRTCP 450 The reader is reminded that the plaintext is shorter than the 451 ciphertext by exactly the length of the AEAD authentication tag. 453 2.2. AES-GCM for SRTP/SRTCP 455 AES-GCM is a family of AEAD algorithms built around the AES block 456 cipher algorithm. AES-GCM uses AES counter mode for encryption and 457 Galois Message Authentication Code (GMAC) for authentication. A 458 detailed description of the AES-GCM family can be found in 459 [RFC5116]. The following members of the AES-GCM family may be used 460 with SRTP/SRTCP: 462 Table 1: AES-GCM algorithms for SRTP/SRTCP 463 Name Key Size Auth. Tag Size Reference 464 ================================================================ 465 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 466 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 467 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 468 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 469 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 470 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 472 Any implementation of AES-GCM SRTP MUST support both 473 AEAD-AES-128-GCM-8 and AEAD-AES-256-GCM-8, ant it MAY support the 474 four other variants shown in the table. 476 In addition to the invocation counter used in the formation of IVs, 477 each instantiation of AES-GCM has a block counter which is 478 incremented each time AES is called to produce a 16-octet output 479 block. The block counter is reset to "1" each time AES-GCM is 480 invoked. 482 1 1 1 1 1 1 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 484 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 485 | | salt | | salt xor | block | 486 | salt | xor | salt | invocation | counter | 487 | | ssrc | | counter | | 488 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 490 Figure 5: AES Inputs for Counter Mode Encryption in GCM 492 2.3. AES-CCM for SRTP/SRTCP 494 AES-CCM is another family of AEAD algorithms built around the AES 495 block cipher algorithm. AES-GCM uses AES counter mode for encryption 496 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 497 for authentication. A detailed description of the AES-CCM family can 498 be found in [RFC5116]. The following members of the AES-CCM family 499 may be used with SRTP/SRTCP: 501 Table 2: AES-CCM algorithms for SRTP/SRTCP 502 Name Key Size Auth. Tag Size Reference 503 ================================================================ 504 AEAD_AES_128_CCM 16 octets 16 octets [RFC5116] 505 AEAD_AES_256_CCM 32 octets 16 octets [RFC5116] 507 Any implementation of AES-CCM SRTP/SRTCP MUST support both 508 AEAD-AES-128-CCM and AEAD-AES-256-CCM. 510 In addition to the invocation counter used in the formation of 511 IVs, each instantiation of AES-CCM has a block counter which is 512 incremented each time AES is called to produce a 16-octet output 513 block. The block counter is reset to "0" each time AES-CCM is 514 invoked. 516 AES-CCM uses a flag octet that conveys information about the length 517 of the authentication tag, length of the block counter, and presence 518 of additional authenticated data. For AES-CCM in SRTP/SRTCP, the 519 flag octet has the hex value 5A if an 8-octet authentication tag is 520 used, 6A if a 12-octet authentication tag is used, and 7A if a 521 16-octet authentication tag is used. The flag octet is one of the 522 inputs to AES during the counter mode encryption of the plaintext 523 (see Figure 6) 525 1 1 1 1 1 1 526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 527 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 528 | | | salt | | salt xor | block | 529 |Flag| salt | xor | salt | invocation | counter | 530 | | | ssrc | | counter | | 531 ----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 533 Figure 6: AES Inputs for Counter Mode Encryption in CCM 535 3. Security Considerations 537 We require that the AEAD authentication tag must be at least 8 538 octets, significantly reducing the probability of an adversary 539 successfully introducing fraudulent data. The goal of an 540 authentication tag is to minimize the probability of a successful 541 forgery occurring anywhere in the network we are attempting to 542 defend. There are three relevant factors: how low we wish the 543 probability of successful forgery to be (prob_success), how many 544 attempts the adversary can make (N_tries) and the size of the 545 authentication tag in bits (N_tag_bits). Then 547 prob_success < expected number of successes 548 = N_tries * 2^-N_tag_bits. 550 The table below summarizes the relationship between the 551 authentication tag size, the probability of success, and the maximum 552 numbers of forgery attempts that can be permitted on our network. 554 |==================+========================================| 555 | Authentication | Probability any Successful Forgeries | 556 | Tag Size |-------------+-------------+------------| 557 | (octets) | 2^-10 | 2^-20 | 2^-30 | 558 |==================+=============+=============+============| 559 | 4 | 2^22 tries | 2^12 tries | 2^2 tries | 560 |==================+=============+=============+============| 561 | 8 | 2^54 tries | 2^44 tries | 2^34 tries | 562 |==================+=============+=============+============| 563 | 12 | 2^86 tries | 2^76 tries | 2^66 tries | 564 |==================+=============+=============+============| 565 | 16 | 2^118 tries | 2^108 tries | 2^98 tries | 566 |==================+=============+=============+============| 568 Table 1: Maximum allowable number of forgery attempts for 569 a given tag size and probability of success. 571 4. IANA Considerations 573 RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to 574 a particular AEAD algorithm in SRTP. In order to allow SDP to signal 575 the use of the algorithms defined in this document, IANA will 576 register the following crypto suites into the subregistry for SRTP 577 crypto suites under the SRTP transport of the SDP Security 578 Descriptions: 580 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 581 "AEAD_AES_256_GCM" / 582 "AEAD_AES_128_GCM_8" / 583 "AEAD_AES_256_GCM_8" / 584 "AEAD_AES_128_GCM_12" / 585 "AEAD_AES_256_GCM_12" / 586 "AEAD_AES_128_CCM" / 587 "AEAD_AES_256_CCM" / 588 srtp-crypto-suite-ext 590 draft-ietf-avt-dtls-srtp-05 defines a DTLS-SRTP "SRTP Protection 591 Profile"; it also corresponds to the use of an AEAD algorithm in 592 SRTP. In order to allow the use of the algorithms defined in this 593 document in DTLS-SRTP, IANA will also register the following SRTP 594 Protection Profiles: 596 SRTP_AEAD_AES_128_GCM 597 SRTP_AEAD_AES_256_GCM 598 SRTP_AEAD_AES_128_GCM_8 599 SRTP_AEAD_AES_256_GCM_8 600 SRTP_AEAD_AES_128_GCM_12 601 SRTP_AEAD_AES_256_GCM_12 602 SRTP_AEAD_AES_128_CCM 603 SRTP_AEAD_AES_256_CCM 605 5. Acknowledgements 607 The author would like to thank Kevin Igoe and many other reviewers 608 who provided valuable comments on earlier drafts of this document. 610 6. References 612 6.1. Normative References 614 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 615 Mode for Authentication and Confidentiality", U.S. 617 National Institute of Standards and Technology http:// 618 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 620 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 621 Recommendation for Block Cipher Modes of Operation: 622 Galois/Counter Mode (GCM) and GMAC.", U.S. National 623 Institute of Standards and Technology http:// 624 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [RFC5116] McGrew, D., "An Interface and Algorithms for 630 Authenticated Encryption with Associated Data", RFC 5116, 631 January 2008. 632 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 633 Algorithms with the Encrypted Payload of the Internet Key Exchange 634 version 2 (IKEv2) Protocol", RFC 5282, August 2008. 636 6.2. Informative References 638 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 639 Relations among notions and analysis of the generic 640 composition paradigm", Proceedings of ASIACRYPT 2000, 641 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 642 www-cse.ucsd.edu/users/mihir/papers/oem.html. 644 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 645 and Key Establishment", Springer, 2003 . 647 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 648 CryptoToolkit/modes/800-38_Series_Publications/ 649 SP800-38B.pdf. 651 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 652 provably repairing the SSH authenticated encryption 653 scheme: A case study of the Encode-then-Encrypt-and-MAC 654 paradigm", ACM Transactions on Information and System Secu 655 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 656 TISSEC04/. 658 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 659 than Real: Security Challenges in Virtual Machine Based 660 Computing Environments", Proceedings of the 10th Workshop 661 on Hot Topics in Operating Systems http:// 662 www.stanford.edu/~talg/papers/HOTOS05/ 663 virtual-harder-hotos05.pdf. 665 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 666 Proceedings of the 9th Annual Workshop on Selected Areas 667 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 668 proposedmodes/ccm/ccm-ad1.pdf, 2002. 670 [MODES] Dworkin, M., "NIST Special Publication 800-38: 671 Recommendation for Block Cipher Modes of Operation", U.S. 672 National Institute of Standards and Technology http:// 673 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 675 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 676 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 677 '04, http://eprint.iacr.org/2004/193, December 2004. 679 [R02] Rogaway, P., "Authenticated encryption with Associated- 680 Data", ACM Conference on Computer and Communication 681 Security (CCS'02), pp. 98-107, ACM Press, 682 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 684 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 685 Hashing for Message Authentication", RFC 2104, 686 February 1997. 688 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 689 Requirements for Security", BCP 106, RFC 4086, June 2005. 691 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 692 (GCM) in IPsec Encapsulating Security Payload (ESP)", 693 RFC 4106, June 2005. 695 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 696 Key Management", BCP 107, RFC 4107, June 2005. 698 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 699 RFC 4303, December 2005. 701 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 702 Mode with IPsec Encapsulating Security Payload (ESP)", 703 RFC 4309, December 2005. 705 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 706 Transform Carrying Roll-Over Counter for the Secure Real- 707 time Transport Protocol (SRTP)", RFC 4771, January 2007. 709 Author's Address 711 David A. McGrew 712 Cisco Systems, Inc. 713 510 McCarthy Blvd. 714 Milpitas, CA 95035 715 US 717 Phone: (408) 525 8651 718 Email: mcgrew@cisco.com 719 URI: http://www.mindspring.com/~dmcgrew/dam.htm 721 Acknowledgement 723 Funding for the RFC Editor function is provided by the IETF 724 Administrative Support Activity (IASA).