idnits 2.17.1 draft-mcgrew-srtp-aero-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 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) == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-10 == Outdated reference: A later version (-01) exists of draft-mcgrew-aero-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group D. McGrew 3 Internet-Draft D. Wing 4 Intended status: Standards Track Cisco 5 Expires: April 24, 2014 J. Foley 6 Cisco Systems 7 October 21, 2013 9 Using Authenticated Encryption with Replay prOtection (AERO) in SRTP 10 draft-mcgrew-srtp-aero-01 12 Abstract 14 Authenticated Encryption with Replay prOtection (AERO) is a 15 cryptographic technique that provides all of the security services 16 that are used in the Secure Real-time Transport Protocol (SRTP). 17 This note describes how to use AERO in SRTP. AERO has minimal data 18 expansion, avoids the need to manage implicit state, and provides 19 strong misuse resistance. These properties make it an ideal 20 cryptographic transform for SRTP, as it enables SRTP to easily handle 21 multiple senders sharing the same key, multiple receivers with late- 22 joiners in a session, decentralized conferences with minimal control, 23 and mixers that selectively forward RTP traffic. RTP architectures 24 that utilize AERO can use the normal SSRC collision detection 25 mechanism, and can ignore problematic SRTP artifacts such as the 26 Roll-Over Counter (ROC) and Initial Sequence Number. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 64 1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. SRTP AERO . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. SRTP crypto suites . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. AERO_AES_128_XCB_80 . . . . . . . . . . . . . . . . . . . 10 74 4.2. AERO_AES_128_XCB_32 . . . . . . . . . . . . . . . . . . . 10 75 4.3. AERO_AES_256_XCB_128 . . . . . . . . . . . . . . . . . . . 11 76 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. Comparison to other approaches . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 6.1. SSRC collisions . . . . . . . . . . . . . . . . . . . . . 13 80 6.2. Key scope . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 RTP is designed to allow decentralized groups with minimal control to 91 establish sessions, such as for multimedia conferences. 92 Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many 93 minimal-control scenarios, because it requires that SSRC values and 94 other data be coordinated among all of the participants in a session. 95 For example, if a participant joins a session that is already in 96 progress, the SRTP Roll-Over Counter (ROC) of each SRTP source in the 97 session needs to be provided to that participant. 99 The inability of SRTP to work in the absence of central control was 100 well understood during the design of that protocol; that omission was 101 considered less important than optimizations such as bandwidth 102 conservation. Additionally, in many situations SRTP is used in 103 conjunction with a signaling system that can provide much of the 104 central control needed by SRTP. However, there are several cases in 105 which conventional signaling systems cannot easily provide all of the 106 coordination required. It is also desirable to eliminate the layer 107 violations that occur when signaling systems coordinate certain SRTP 108 parameters, such as SSRC values and ROCs. 110 These issues are due to the particular cryptographic techniques used 111 in SRTP, specifically a partially-implicit sequence number that is 112 utilized for counter mode encryption, for replay protection, and for 113 determining when re-keying should occur. Authenticated Encryption 114 with Replay prOtection (AERO) [I-D.mcgrew-aero] is a cryptographic 115 technique that provides confidentiality, authentication, and replay 116 protection; it is a stateful and self-synchronizing authenticated 117 encryption method. It has minimal data expansion, avoids the need to 118 manage implicit state, and provides strong misuse resistance. This 119 document defines how AERO can be used in SRTP as a replacement for 120 the default transforms of [RFC3711] in a way that avoids all of the 121 issues identified above. 123 This document is organized as follows. Packet processing and 124 contexts are described in Section 2 and Section 3. A rationale for 125 the design is offered in Section 5. Security Considerations are 126 provided in Section 6, and IANA considerations are provided in 127 Section 7. 129 1.1. Conventions Used In This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 1.2. History 137 This section describes the evolution of this document as an Internet 138 Draft, and it should be removed by the RFC Editor prior to 139 publication as an RFC. 141 This is the initial version of this note. As it uses a cryptographic 142 technique that was published recently, it may evolve over time as 143 that technique is reviewed and experience is gained in its usage. 144 Thus, while we encourage the implementation of the crypto suites 145 specified in this note as the best way to obtain experience with 146 their use in RTP architectures, we also expect that there may be 147 changes to these crypto suites over time. 149 2. SRTP AERO 151 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile 152 of the Real-time Transport Protocol (RTP) that can provide 153 confidentiality, message authentication, and replay protection to the 154 RTP traffic and to the control traffic for RTP, the Real-time 155 Transport Control Protocol (RTCP). SRTP provides a framework for the 156 encryption and message authentication of RTP and RTCP streams. 157 Default cryptographic transforms are defined in [RFC3711], while the 158 framework supports the addition of new cryptographic transforms. 160 The note describes how to use Authenticated Encryption with Replay 161 prOtection (AERO) [I-D.mcgrew-aero] in SRTP, which we refer to as 162 SRTP-AERO. All three security services - confidentiality, message 163 authentication, and replay protection - are always provided with 164 SRTP-AERO; none of those services is optional. The SRTP framework 165 includes provisions for separate encryption and authentication 166 transforms; when AERO is used, it is considered an encryption 167 transform and there MUST NOT be a separate authentication transform. 169 This description mainly consists of how AERO encryption inputs and 170 outputs are mapped to RTP and SRTP packets, respectively, how AERO 171 decryption inputs and outputs are mapped to SRTP and RTP packets, 172 respectively, and how the AERO context is stored in the SRTP context. 173 A similar description is provided for SRTCP. The security 174 considerations are different from those in [RFC3711] (and are rather 175 less stringent). 177 With SRTP-AERO, the normal RTP SSRC collision detection and repair 178 process can be followed. This is in contrast to SRTP with the 179 default transforms, which relies on external mechanisms to coordinate 180 SSRC values. 182 AERO is an Authenticated Encryption with Associated Data (AEAD) 183 method, and thus SRTP-AERO processing is similar to that of 184 [I-D.ietf-avtcore-srtp-aes-gcm]. 186 2.1. Encryption 188 To protect an RTP packet using AERO, the inputs to the encryption 189 operation are as follows: 191 The associated data A is set to the RTP header, including the CSRC 192 identifiers (if present), and the RTP header extension (if 193 present). (In Figure 1 of [RFC3711], this consists of the part of 194 the Authenticated Portion of the packet that does not overlap with 195 the Encrypted Portion.) 196 The plaintext is set to the RTP payload, RTP padding, and RTP pad 197 count. (In Figure 1 of [RFC3711], this is the Encrypted Portion.) 199 The secret key K is set to the AERO key in the SRTP context. 201 The ciphertext returned by that operation replaces the plaintext in 202 the RTP packet. Note that the ciphertext will be longer than the 203 plaintext. 205 AERO does not include a separate authentication tag, and thus this 206 field is omitted from the SRTP packet; it MUST NOT be present. This 207 omission simplifies this specification (see Section 5). 209 A Master Key Indicator (MKI) field MAY be present after the 210 ciphertext; this field is optional in [RFC3711] and its usage is 211 unchanged by this specification. 213 2.2. Decryption 215 To decrypt an SRTP packet using AERO, the inputs to the decryption 216 operation are as follows: 218 The associated data A is set as in SRTP encryption Section 2.1. 220 The ciphertext C is set as follows. It starts and the end of the 221 RTP header extension, if that field is present. If it is not, 222 then it starts at the end of the last CSRC identifier, if any CSRC 223 identifiers are present. Otherwise, it starts at the end of the 224 SSRC identifier. If an MKI is in use, then the ciphertext ends at 225 the start of the MKI. Otherwise, the ciphertext ends at the end 226 of the RTP packet. 228 The secret key K is set to the AERO key in the SRTP context. 230 If the decryption operation returns the symbol FAIL, then the SRTP 231 packet is either a forgery attempt or a replay, and the packet MUST 232 be discarded from further processing and the event MAY be logged. 233 Otherwise, an RTP packet is formed from the SRTP packet and the 234 plaintext returned by the decryption operation, by replacing the 235 ciphertext with the plaintext, and discarding the MKI field if one is 236 present. 238 Steps 2 and the replay checking in Step 5 of the decryption 239 processing in Section 3.4 of [RFC3711] SHOULD NOT be performed, since 240 it is unnecessary. The SRTP packet index used in Step 3 to determine 241 the master key and salt SHOULD be set to the sequence number returned 242 by the AERO decryption operation. 244 2.3. Contexts 246 The AERO context is stored in the transform-dependent parameters of 247 the SRTP context, as the SRTP encryption transform. That is, the 248 identifier for the encryption algorithm describes the particular AERO 249 algorithm that is in use. 251 When AERO is used, an SRTP implementation MAY omit the following 252 transform-independent parameters: 254 the ROC, 256 the replay list maintained by an SRTP/SRTCP receiver, and 258 the identifier for the message authentication algorithm. 260 The ROC and replay list are not needed because AERO provides replay 261 protection, and the message authentication algorithm identifier is 262 not needed because AERO provides that security service. 264 3. Secure RTCP 266 The use of AERO in SRTCP follows that in SRTP. 268 3.1. Encryption 270 To protect an RTCP packet using AERO, the inputs to the encryption 271 operation are as follows: 273 The associated data A is set to the RTCP header, including all of 274 the fields starting with the Version and up to and including the 275 SSRC of the sender. 277 The plaintext is set to the remaining part of the RTCP packet. 279 The secret key K is set to the AERO key in the SRTCP context. 281 The ciphertext returned by that operation replaces the plaintext in 282 the RTCP packet. Note that the ciphertext will be longer than the 283 plaintext. 285 AERO does not include a separate authentication tag, and thus this 286 field is omitted from the SRTCP packet; it MUST NOT be present (see 287 Section 5 for the rationale). 289 A Master Key Indicator (MKI) field MAY be present after the 290 ciphertext; this field is optional in [RFC3711] and its usage is 291 unchanged by this specification. 293 The "E" flag and the SRTCP index MUST NOT be included in the SRTCP 294 packet. 296 3.2. Decryption 298 To decrypt an SRTCP packet using AERO, the inputs to the decryption 299 operation are as follows: 301 The associated data A is set as in SRTCP encryption Section 2.1. 303 The ciphertext C consists of all of the data after the associated 304 data, to the end of the packet. 306 The secret key K is set to the AERO key in the SRTCP context. 308 If the decryption operation returns the symbol FAIL, then the SRTCP 309 packet is either a forgery attempt or a replay, and the packet MUST 310 be discarded from further processing and the event MAY be logged. 311 Otherwise, an RTCP packet is formed from the SRTCP packet and the 312 plaintext returned by the decryption operation, by replacing the 313 ciphertext with the plaintext, and discarding the MKI field if one is 314 present. 316 4. SRTP crypto suites 318 This section defines some crypto suites for use in SRTP, which can be 319 signaled by DTLS-SRTP [RFC5764], SDP Security Descriptions [RFC4568] 320 or MIKEY [RFC3830]. The use of these crypto suites in SDP Security 321 Descriptions is straightforward; the particular crypto suite to be 322 used is specified by the "crypto-suite" parameter. Their use in 323 DTLS-SRTP is similarly straightforward; each crypto suite is 324 described by an SRTP Protection Profile (as in Section 4.1.2 of 325 [RFC5764]). For MIKEY, the use of a particular crypto suite is 326 specified by both the MIKEY "encryption algorithm" parameter and the 327 "session encryption key length" parameter, as noted below. 329 4.1. AERO_AES_128_XCB_80 331 The AERO_AES_128_XCB_80 crypto suite uses the AERO_AES_128_XCB 332 algorithm defined in [I-D.mcgrew-aero], with a sequence number length 333 T of 72 bits. It provides authentication strength equivalent to an 334 ideal message authentication code with a 70-bit tag. The data 335 expansion is 80 bits; the ciphertext will be at most 80 bits longer 336 than the plaintext. The master-key length is 128 bits and has a 337 default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP 338 packets, whichever comes first (see page 39 [RFC3711]). 340 The SRTP and SRTCP encryption key lengths are 128 bits. The master 341 salt value is 112 bits in length and the session salt value is 112 342 bits in length. The pseudo-random function (PRF) is the default SRTP 343 pseudo-random function that uses AES Counter Mode with a 128-bit key 344 length. 346 The length of the base64-decoded key and salt value for this crypto 347 suite MUST be 30 characters (i.e., 240 bits); otherwise, the crypto 348 attribute is considered invalid. 350 To signal the use of AERO_AES_128_XCB_80 with MIKEY, the following 351 MIKEY SRTP Policy Parameters MUST be used: 353 An encryption algorithm parameter of TBD Section 7 355 A session encryption key length of 128 bits. 357 An authentication tag length of 80 bits. 359 4.2. AERO_AES_128_XCB_32 361 This crypto suite is identical to AERO_AES_128_XCB_80, except that it 362 uses a sequence number length T of 24 bits. Its authentication 363 strength is about 24 bits, and its data overhead is at most 32 bits. 365 To signal the use of AERO_AES_128_XCB_32 with MIKEY, the following 366 MIKEY SRTP Policy Parameters MUST be used: 368 An encryption algorithm parameter of TBD Section 7 370 A session encryption key length of 128 bits. 372 An authentication tag length of 32 bits. 374 4.3. AERO_AES_256_XCB_128 376 The AERO_AES_256_XCB_128 crypto suite uses the AERO_AES_256_XCB 377 algorithm defined in [I-D.mcgrew-aero], with a sequence number length 378 T of 128 bits. It provides authentication strength equivalent to an 379 ideal message authentication code with a 121-bit tag. The data 380 expansion is 128 bits; the ciphertext will be exactly 128 bits longer 381 than the plaintext. The master-key length is 128 bits and has a 382 default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP 383 packets, whichever comes first (see page 39 [RFC3711]). 385 The SRTP and SRTCP encryption key lengths are 256 bits. The master 386 salt value is 112 bits in length and the session salt value is 112 387 bits in length. The pseudo-random function (PRF) is the 388 AES_256_CM_PRF key derivation function [RFC6188] which uses AES 389 Counter Mode with a 256-bit key length. 391 The length of the base64-decoded key and salt value for this crypto 392 suite MUST be 46 characters (i.e., 368 bits); otherwise, the crypto 393 attribute is considered invalid. 395 To signal the use of AERO_AES_128_XCB_80 with MIKEY, the following 396 MIKEY SRTP Policy Parameters MUST be used: 398 An encryption algorithm parameter of TBD Section 7 400 A session encryption key length of 256 bits. 402 An authentication tag length of 128 bits. 404 5. Rationale 406 There is no need to allow the SRTP or SRTCP Authentication Tag fields 407 to be present, and thus it is forbidden instead of being optional. 408 Compatibility with [RFC4771], which uses this field as a means of 409 conveying the Roll-Over Counter (ROC), is not needed because AERO 410 removes any need for the ROC. Omitting this field simplifies 411 implementations and avoids confusion. 413 The SSRC field serves as a Sender Identifier, and meets the 414 requirements described in Section 3.5 of [I-D.mcgrew-aero]. 416 5.1. Comparison to other approaches 418 There are other approaches that have been used to address the issues 419 identified in Section 1. In this section, we compare them to SRTP 420 AERO. 422 With the SRTP Integrity Transform Carrying Roll-Over Counter 423 [RFC4771], the sender periodically includes the ROC in the SRTP 424 authentication tag, in which case the authentication process is 425 altered so that the ROC is authenticated. This approach addresses 426 synchronization issues that are due to multiple receivers, such as 427 the problem of "late joiners" in a session. However, it does not 428 address any of the issues that are due to multiple senders using the 429 same encryption key. It also does not change the need for misuse 430 resistance. 432 With SRTP Encrypted Key Transport (EKT) [SRTP-EKT], the sender 433 periodically includes additional data about the session in its 434 outbound packets. This data includes the value of the master key 435 being used for that SRTP source, encrypted under a master key that is 436 used for all sources in the session. EKT address the issues that 437 arise in multiple-sender sessions by providing a way that each source 438 can use a distinct master key. EKT also includes the initial RTP 439 sequence number, to aid receivers in establishing the appropriate 440 SRTP packet index for the first packet in a session. EKT is more 441 complex than SRTP-AERO, as it requires a separate authenticated 442 encryption method for protecting the data that is conveyed, and it 443 adds complexities to the packet processing rules. It also adds data 444 overhead to SRTP and SRTCP packets in a way that is non-uniform, with 445 some packets growing by a single byte, and others growing by over 24 446 bytes. In contrast, SRTP-AERO has data overhead that is constant, 447 and need not be greater than a single byte at equivalent security 448 levels. 450 6. Security Considerations 452 6.1. SSRC collisions 454 With SRTP-AERO, SSRC collisions do not undermine security; instead, 455 there is a limited and quantifiable loss of confidentiality, which is 456 described in Section 11.4 of [I-D.mcgrew-aero]. In essence, if there 457 is an SSRC collision between two senders, then the attacker will be 458 able to detect the event that both senders encrypt two distinct 459 packets that happen to have exactly the same plaintext and associated 460 data values. Even if an SSRC collision occurs, it is unlikely that 461 the RTP sequence number, the RTP timestamp, and the plaintexts will 462 all be identical. Thus, in many setting the unpredictability of the 463 RTP header and payload provide additional protection even in the 464 unlikely occurrence of an SSRC collision. 466 An SSRC collision will not undermine authentication. 468 The normal RTP mechanism for detection and correction of SSRC 469 collisions MUST be used. In practice, if an SRTP or SRTCP sender 470 receives a valid SRTP or SRTCP packet that it did not itself 471 originate, which has an SSRC value equal to its own, then it MUST 472 stop using that SSRC value, and select a new SSRC value at random. A 473 packet is valid only if its AERO decryption does not return FAIL. 475 6.2. Key scope 477 With SRTP-AERO, a single master key MAY be used with multiple SRTP 478 sources or multiple SRTP receivers within a single session. 479 Scenarios in which there may be multiple sources in a single session 480 include multicast SRTP, as well as an RTP mixer that retransmits 481 packets from one selected source to an entire set of sources. In 482 this latter case, a set of participants in a session can all use a 483 single SRTP master key, and a mixer can selectively retransmit 484 packets, e.g. from the "loudest talker", without re-encrypting the 485 packets. 487 A single master key MUST NOT be used across distinct SRTP sessions. 488 This property is not specific to AERO, but instead is general to all 489 uses of SRTP, and it follows from the fact that RTP and RTCP 490 receivers have no way of distinguishing between the packets from one 491 session and those from another. This fact would allow an attacker to 492 substitute packets from one session to another, if both sessions were 493 using the same master key. 495 7. IANA Considerations 497 This section registers with IANA the following SRTP crypto-suite 498 parameters for SDP Security Descriptions [RFC4568]: 500 o SRTP_AERO_128_XCB_80 502 o SRTP_AERO_128_XCB_32 504 o SRTP_AERO_256_XCB_128 506 They are specified in Section 4 of this note. 508 We also request the IANA assignment of the following values to the 509 DTLS SRTPProtectionProfile registry: 511 SRTP_AERO_128_XCB_80 = { TBD1, TBD2 } 513 SRTP_AERO_128_XCB_32 = { TBD3, TBD4 } 515 SRTP_AERO_256_XCB_128 = { TBD5, TBD6 } 517 We also request the following IANA assignment from the MIKEY registry 518 of SRTP policy parameters: 520 o An Encryption Algorithm parameter value of TBD. 522 This value indicates the use AERO_AES_XCB in SRTP, and corresponds to 523 either SRTP_AERO_128_XCB_80, SRTP_AERO_128_XCB_32, and 524 SRTP_AERO_256_XCB_128. 526 8. Acknowledgements 528 Thanks are due to Nermeen Ismail for insightful discussions on the 529 use of SRTP in telepresence environments. 531 9. References 533 9.1. Normative References 535 [I-D.ietf-avtcore-srtp-aes-gcm] 536 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 537 Encryption in Secure RTP (SRTP)", 538 draft-ietf-avtcore-srtp-aes-gcm-10 (work in progress), 539 September 2013. 541 [I-D.mcgrew-aero] 542 McGrew, D. and J. Foley, "Authenticated Encryption with 543 Replay prOtection (AERO)", draft-mcgrew-aero-00 (work in 544 progress), October 2013. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 550 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 551 RFC 3711, March 2004. 553 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 554 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 555 August 2004. 557 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 558 Description Protocol (SDP) Security Descriptions for Media 559 Streams", RFC 4568, July 2006. 561 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 562 Transform Carrying Roll-Over Counter for the Secure Real- 563 time Transport Protocol (SRTP)", RFC 4771, January 2007. 565 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 566 Security (DTLS) Extension to Establish Keys for the Secure 567 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 569 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 570 RTP", RFC 6188, March 2011. 572 9.2. Informative References 574 [SRTP-EKT] 575 McGrew, D., Andreason, F., Wing, D., and K. Fisher, 576 "Encrypted Key Transport for Secure RTP", Internet Draft; 577 Work In Progress. . 579 Authors' Addresses 581 David A. McGrew 582 Cisco Systems, Inc. 583 510 McCarthy Blvd. 584 Milpitas, CA 95035 585 US 587 Phone: (408) 525 8651 588 Email: mcgrew@cisco.com 589 URI: http://www.mindspring.com/~dmcgrew/dam.htm 591 Dan Wing 592 Cisco Systems, Inc. 593 510 McCarthy Blvd. 594 Milpitas, CA 95035 595 US 597 Phone: (408) 853 4197 598 Email: dwing@cisco.com 600 John Foley 601 Cisco Systems 602 7025-2 Kit Creek Road 603 Research Triangle Park, NC 14987 604 US 606 Email: foleyj@cisco.com