idnits 2.17.1 draft-jones-perc-dtls-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (February 23, 2016) is 2984 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'ChangeCipherSpec' is mentioned on line 275, but not defined -- Looks like a reference, but probably isn't: '16' on line 509 -- Looks like a reference, but probably isn't: '2' on line 536 == Missing Reference: 'TBD' is mentioned on line 549, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet-Draft Cisco 4 Intended status: Standards Track February 23, 2016 5 Expires: August 26, 2016 7 DTLS Tunnel between Media Distribution Device and Key Management 8 Function to Facilitate Key Exchange 9 draft-jones-perc-dtls-tunnel-00 11 Abstract 13 This document defines a DTLS tunneling protocol for use in multimedia 14 conferences that enables a Media Distribution Device (MDD) to 15 facilitate key exchange between an endpoint in a conference and the 16 Key Management Function (KMF) responsible for key distribution. The 17 protocol is designed to ensure that key material used for end-to-end 18 encryption and authentication is inaccessible to the MDD, while key 19 material used for hop-by-hop encryption and authentication is 20 accessible to the MDD. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 26, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 58 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 60 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 9 62 5.2. Media Distribution Device Tunneling Procedures . . . . . 9 63 5.3. Key Management Function Tunneling Procedures . . . . . . 11 64 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 An objective of the work in the Privacy-Enhanced RTP Conferencing 74 (PERC) working group is to ensure that endpoints in a multimedia 75 conference have access to the end-to-end (E2E) key material used to 76 encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] 77 packets, while the Media Distribution Device (MDD) does not. At the 78 same time, the MDD needs access to key material used for hop-by-hop 79 (HBH) encryption and authentication. 81 The procedures in this document depend on two important media 82 security specifications, namely DTLS-SRTP [RFC5764] and 83 [I-D.ietf-avtcore-srtp-ekt]. 85 DTLS-SRTP [RFC5764] defines a set of procedures for establishing 86 encryption and authentication keys between two entities (e.g., an 87 endpoint and the MDD). [I-D.ietf-avtcore-srtp-ekt] defines a DTLS 88 [RFC6347] extension that build on DTLS-SRTP to allow an entity to 89 transmit a key encrypting key (the "EKT key") to its peer. The EKT 90 key is used to securely convey an SRTP [RFC3711] master key to the 91 peer via an SRTP packet. Together, these procedures would meet the 92 needs of PERC, but care has to be taken to ensure that the MDD does 93 not gain access to the E2E media encryption and authentication key 94 material. 96 To prevent the MDD from gaining access to the E2E key material, this 97 specification defines a set of procedures for tunneling the DTLS 98 signaling from the endpoint through the MDD to the Key Management 99 Function (KMF). To accomplish this, a DTLS association is first 100 established between the MDD and KMF ("tunnel"). DTLS packets 101 received from the endpoint are encapsulated inside the tunnel as data 102 to be sent to the KMF. Likewise, DTLS messages received inside the 103 tunnel are extracted and forwarded to the endpoint. In effect, the 104 DTLS association for the DTLS-SRTP procedures is established between 105 the endpoint and the KMF, with the MDD simply forwarding packets 106 between the two entities. 108 Following the existing DTLS-SRTP procedures, the endpoint and KMF 109 will arrive at a selected cipher and key material, which are used for 110 HBH encryption and authentication by both the endpoint and the MDD. 111 However, since the MDD would not have direct access to this 112 information, the KMF will share this information with the MDD via the 113 tunneling protocol defined in this document. 115 The EKT procedures are used to convey the an EKT key that is shared 116 among all participants in a conference. It is the responsibility of 117 the KMF to send the EKT key for the conference to the endpoint via 118 the DTLS association established between the endpoint and the KMF. 119 The endpoint can then securely transmit its SRTP master keys to other 120 endpoints via SRTP following the procedures in 121 [I-D.ietf-avtcore-srtp-ekt]. 123 By establishing this DTLS tunnel between the MDD and KMF and 124 implementing the protocol defined in this document, it is possible 125 for the MDD to facilitate the establishment of a secure DTLS 126 association between an endpoint and the KMF in order for the endpoint 127 to receive E2E key material and to derive the HBH key material. At 128 the same time, the KMF can securely provide the HBH key material to 129 the MDD. 131 2. Conventions Used In This Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119] 136 when they appear in ALL CAPS. These words may also appear in this 137 document in lower case as plain English words, absent their normative 138 meanings. 140 3. Tunneling Concept 142 A DTLS association (tunnel) established between the MDD and the KMF. 143 This tunnel is used to relay DTLS messages between the endpoint and 144 KMF, as depicted in Figure 1: 146 +------------------------------+ 147 +-----+ | Switching MDD | 148 | | | | 149 | KMF |<===============>|<============+ (Tunnels DTLS) | 150 | | DTLS | v | 151 +-----+ Tunnel +------------------------------+ 152 ^ 153 | 154 | DTLS (DLTS-SRTP and EKT) 155 | 156 v 157 +----------+ 158 | Endpoint | 159 +----------+ 161 Figure 1: DTLS Tunnel to KMF 163 The three entities involved in this communication flow are the 164 endpoint, the MDD, and the KMF. The behavior of each entity is 165 described in Section 5. 167 The KMF is a logical function whose location is not dictated by this 168 document. The KMF might be co-resident with an enterprise key 169 management server, reside in one of the endpoints participating in 170 the conference, or exist elsewhere. What is important is that the 171 KMF is not co-resident with the MDD, as otherwise the MDD will be 172 able to gain access to the E2E key material. 174 4. Example Message Flows 176 This section provides some example message flows to help clarify the 177 procedures described later in this document. 179 Figure 2 shows the establishment of the DTLS tunnel between the MDD 180 and the KMF. The MDD might establish a single tunnel for all 181 communication between itself and the KMF, a single tunnel for each 182 conference, or one tunnel per endpoint. Regardless of how many 183 tunnels the MDD chooses to establish, they are each established in 184 the same way. 186 Endpoint MDD KMF 187 | | | 188 | |------------------------>| 189 | | ClientHello | 190 | | | 191 | |<------------------------| 192 | | HelloVerifyRequest | 193 | | | 194 | |------------------------>| 195 | | ClientHello | 196 | | | 197 | |<------------------------| 198 | | ServerHello | 199 | | Certificate | 200 | | ServerKeyExchange* | 201 | | CertificateRequest | 202 | | ServerHelloDone | 203 | | | 204 | |------------------------>| 205 | | Certificate | 206 | | ClientKeyExchange | 207 | | CertificateVerify | 208 | | [ChangeCipherSpec] | 209 | | Finished | 210 | | | 211 | |<------------------------| 212 | | [ChangeCipherSpec] | 213 | | Finished | 214 | | | 215 | |<=======================>| 216 | | DTLS Tunnel Established | 217 | | | 219 Figure 2: Establishing a DTLS Tunnel 221 Note that the ServerKeyExchange(*) message is transmitted as required 222 per [RFC5246]. 224 The above flow is almost identical to Figure 1 of [RFC6347], with the 225 only significant change being that, since both client and server 226 certificates must be exchanged, those messages are present and non- 227 optional. 229 Once the tunnel is established, it is possible for the MDD to tunnel 230 DTLS messages between the endpoint and the KMF. Figure 3 shows a 231 message flow wherein the endpoint uses DTLS-SRTP to establish the HBH 232 cipher and key material, the KMF provides the MDD with the HBH cipher 233 and key material, and the KMF sends the E2E key material to the 234 endpoint. The tunneled messages are shown with the name of the 235 tunneling protocol message used within parentheses. Tunneled DTLS 236 messages are always carried within the data structure "dtls_message", 237 but the message type is shown in the figure to illustrate which 238 message is sent at which point in the exchange. 240 Endpoint MDD KMF 241 | | | 242 |------------------------>|========================>| 243 | ClientHello + use_srtp | (SupportedProfiles) | 244 | + EKT | ClientHello + use_srtp | 245 | | + EKT | 246 | | | 247 |<------------------------|<========================| 248 | HelloVerifyRequest | (Empty) | 249 | | HelloVerifyRequest | 250 | | | 251 |------------------------>|========================>| 252 | ClientHello + use_srtp | (Empty) | 253 | + EKT | ClientHello + use_srtp | 254 | | + EKT | 255 | | | 256 |<------------------------|<========================| 257 | ServerHello + use+srtp | (Empty) | 258 | + EKT | ServerHello + use+srtp | 259 | Certificate | + EKT | 260 | ServerKeyExchange* | Certificate | 261 | CertificateRequest | ServerKeyExchange* | 262 | ServerHelloDone | CertificateRequest | 263 | | ServerHelloDone | 264 | | | 265 |------------------------>|========================>| 266 | Certificate | (Empty) | 267 | ClientKeyExchange | Certificate | 268 | CertificateVerify | ClientKeyExchange | 269 | [ChangeCipherSpec] | CertificateVerify | 270 | Finished | [ChangeCipherSpec] | 271 | | Finished | 272 | | | 273 |<------------------------|<========================| 274 | [ChangeCipherSpec] | (SRTPKeyInformation) | 275 | Finished | [ChangeCipherSpec] | 276 | | Finished | 277 | | | 278 |<------------------------|<========================| 279 | ekt_key | (Empty) | 280 | | ekt_key | 281 | | | 282 |------------------------>|========================>| 283 | ekt_key_ack | (Empty) | 284 | | ekt_key_ack | 285 | | | 287 Figure 3: Sample DTLS-SRTP and EKT Exchange via a Tunnel 289 Note that the ServerKeyExchange(*) message is transmitted as required 290 per [RFC5246]. 292 Each of these tunneled messages on the right-hand side of Figure 3 is 293 a message of type "DTLSTunnelMessage" (see Section 6). Each message 294 contains the following information: 296 * Protocol version 297 * Association ID 298 * Conference ID 299 * Message type (Empty, SupportedProfiles, or SRTPKeyInformation) 300 * Type-specific content 301 * DTLS message being tunneled 303 Of particular interest are the "SupportedProfiles" and 304 "SRTPKeyInformation" messages. 306 The "SupportedProfiles" message allows the MDD to tell the KMF which 307 protection profiles it uses. The KMF will need to select a common 308 profile supported by both the endpoint and the MDD to ensure that 309 hop-by-hop operations can be successfully performed. 311 The "SRTPKeyInformation" message contains the KMF-selected cipher and 312 derived key material for those hop-by-hop operations. The derivation 313 of the hop-by-hop key material is performed independently by both the 314 endpoint and the KMF per [RFC5764]. The MDD would extract this 315 information when the message is received and use it for hop-by-hop 316 encryption and authentication operations. 318 The end-to-end key material is provided by the KMF to the endpoint 319 via the "ekt_key" message as per [I-D.ietf-avtcore-srtp-ekt]. While 320 the EKT message passes through the MDD, it is encrypted and, 321 therefore, inaccessible to the MDD. The endpoint does not send an 322 ekt_key message to the KMF, since only the KMF provides an EKT Key 323 for use in the conference. 325 5. Tunneling Procedures 327 The following sub-sections explain in detail the expected behavior of 328 the endpoint, the media distribution device (MDD), and the key 329 management function (KMF). 331 It is important to note that the tunneling protocol described in this 332 document is not an extension to TLS (@!RFC5246) or DTLS (@!RFC6347). 333 Rather, it is a protocol that carries endpoint- or MDD-generated DTLS 334 messages as data inside of the DTLS tunnel established between the 335 MDD and KMF. 337 5.1. Endpoint Procedures 339 The endpoint's role is actually quite simple: it follows the 340 procedures outlined in [RFC5764] without any changes to the 341 procedures defined in that specification in order to establish the 342 keys used for HBH encryption and authentication. Additionally, it 343 uses the procedures defined in [I-D.ietf-avtcore-srtp-ekt] to receive 344 an EKT key to facilitate securing media end-to-end. 346 The endpoint initiates signaling to establish the DTLS association 347 and expects the KMF to act as the DTLS server. The endpoint MUST 348 verify the KMF's server certificate. The endpoint MUST also provide 349 its certificate to the MDD for verification as a part of the DTLS 350 handshake. 352 The endpoint exchanges EKT [I-D.ietf-avtcore-srtp-ekt] messages over 353 the DTLS association between itself and the KMF in order to receive 354 the EKT key. The EKT key is used by the endpoint to securely 355 transmit the SRTP master key used for end-to-end media encryption and 356 authentication. 358 Since the DTLS association is established between the endpoint and 359 the KMF, no entity along the path, including the MDD, will have 360 access to the key material used for E2E encryption and 361 authentication. 363 5.2. Media Distribution Device Tunneling Procedures 365 The MDD, acting as a client, establishes a DTLS association between 366 itself and the KMF, acting as a server, for the purpose of 367 facilitating key exchange between an endpoint and the KMF. To 368 differentiate this DTLS association from the one initiated by the 369 endpoint, this association is called a "tunnel". A tunnel may be 370 established when the first endpoint attempts to establish a DTLS 371 association with the KMF, or the tunnel may be established in advance 372 and independent of communication with an endpoint. 374 A tunnel allows the MDD to relay DTLS messages for any number of 375 endpoints. The MDD cannot see the plaintext contents of the 376 encrypted exchanges between the KMF and an endpoint, but the protocol 377 does enable the KMF to provide the HBH key material to the MDD for 378 each of the individual DTLS associations. 380 The MDD may establish a single DTLS tunnel to the KMF or it may 381 establish more than one. However, the MDD MUST ensure that all DTLS 382 messages received by the endpoint for the same DTLS association are 383 transmitted over the same tunnel. 385 When a DTLS message is received by the MDD from an endpoint, it 386 blindly forwards that message to the KMF encapsulated in a 387 "DTLSTunnelMessage" using the message type "Empty" (see Section 6) in 388 all cases except the initial message for each association (as 389 explained below). To uniquely identify a distinct endpoint- 390 originated DTLS association, the MDD assigns a tunnel-unique 391 "association identifier" for the association and includes a 392 "conference identifier" known to both the MDD and the KMF. 394 The association identifier is necessary since multiple DTLS messages 395 from multiple endpoints might be relayed over the same tunnel. By 396 uniquely assigning an association identifier, the MDD can determine 397 which message received from the KMF needs to be forwarded to which 398 endpoint. 400 The conference identifier is necessary to allow the KMF to provide 401 the endpoint with the correct E2E key material for the conference the 402 endpoint is attempting to join. It is important to note that merely 403 receiving the conference identifier is not an indication of 404 authorization. Through some means defined outside the scope of this 405 document, it is expected that the KMF will know for which conferences 406 the endpoint is authorized to receive E2E key material. 408 Editor's Note: If we enhance EKT so that the endpoint can convey a 409 conference identifier or other information (e.g., a participant ID 410 in the form of a UUID assigned to the endpoint for the conference) 411 that allows the KMF to associate an endpoint and a particular 412 conference, we could relieve the MDD of having to provide a 413 conference ID as a part of the tunneling protocol. Modifying EKT 414 to enable the endpoint to convey this information should be 415 preferred. 417 All messages for a given DTLS association MUST be sent via the same 418 tunnel and MUST include the same association identifier. The MDD 419 MUST forward all messages received from either the endpoint or the 420 KMF to ensure proper communication between those two entities. 422 When forwarding the first message received for a new endpoint- 423 originated DTLS association (the "ClientHello + use_srtp + ekt"), the 424 MDD relays the message inside a message of type "SupportedProfiles". 425 This allows the MDD to advertise to the KMF which SRTP protection 426 profiles it supports for HBH operations. 428 When the MDD receives a message from the KMF of type 429 "SRTPKeyInformation", it extracts the cipher and key material 430 conveyed in that message in order to perform HBH encryption and 431 authentication for RTP/RTCP packets sent to and from the endpoint. 432 Since the HBH cipher and key material will be different for each 433 endpoint, the MDD uses the association identifier to ensure the key 434 material is associated with the correct endpoint. 436 5.3. Key Management Function Tunneling Procedures 438 The KMF MUST be prepared to establish one or more tunnels (DTLS 439 associations) with the MDD for the purpose of relaying DTLS messages 440 between an endpoint and the KMF. The KMF does not initiate a tunnel. 441 Rather, the KMF acts as a server and the MDD acts as a client to 442 establish a tunnel. 444 When the MDD relays a DTLS message from an endpoint via a tunnel, the 445 MDD will include an association identifier that is unique per 446 endpoint-originated DTLS association relayed via that tunnel. The 447 association identifier remains constant for the life of the DTLS 448 association. Since the same association identifier value might be 449 used on different tunnels between the MDD and KMF, the KMF identifies 450 each endpoint-originated distinct DTLS association by the association 451 identifier and the tunnel over which the DTLS association was 452 established. The KMF MUST use the same association identifier in 453 messages it sends to the endpoint and MUST send all messages for a 454 given DTLS association via the same tunnel. This is to ensure that 455 the MDD can properly relay messages to the correct endpoint. 457 The KMF extracts tunneled DTLS messages and acts on those messages as 458 if the endpoint had established the DTLS association directly with 459 the KMF. The KMF MUST use a certificate expected by the endpoint. 460 How the endpoint learns of the KMF's certificate or certificate 461 fingerprint is outside the scope of this document. 463 The endpoint MUST provide a certificate to the KMF for validation. 464 How the KMF is able to determine that a certificate belongs to a 465 particular endpoint is outside the scope of this document. 467 When sending a message to the endpoint, the KMF encapsulates the 468 message in the DTLSTunnelMessage.dtls_message field of the tunnel 469 protocol. Messages are normally tunneled using the message type 470 "Empty", except when the KMF provides cipher and key material for HBH 471 encryption and authentication (explained below). 473 The KMF acts as the server in the DTLS-SRTP exchanges with the 474 endpoint, so the KMF will dictate to the endpoint which cipher to 475 employ for HBH operations. The selected cipher is conveyed in the 476 ExtendedServerHello message (per [RFC5764]) to the endpoint, which is 477 merely tunneled through the MDD and otherwise ignored by the MDD. 479 Once the SRTP master key and salt values for HBH encryption and 480 authentication are derived by the KMF, those values and the selected 481 cipher are conveyed to the MDD when the KMF transmits the Finished 482 message to the endpoint. The Finished message is encapsulated inside 483 the tunnel in a message of type "SRTPKeyInformation". 485 After sending the Finished message, the KMF will send an ekt_key 486 message to the endpoint containing the EKT key used in the 487 conference. 489 6. Tunneling Protocol 491 The protocol syntax for the DTLS tunnel established between the MDD 492 and KMF is shown below. The syntax is borrowed from [RFC5246]. 494 enum { 495 empty(0), 496 supported_profiles(1), 497 srtp_key_information(2), 498 (255) 499 } KMFMessageType; 501 struct { 502 uint8 major; 503 uint8 minor; 504 } ProtocolVersion; 506 struct { 507 ProtocolVersion version; /* Defined as {0x01, 0x00} */ 508 opaque association_id[16]; /* MDD-defined */ 509 opaque conference_id[16]; /* Conference identifier */ 510 KMFMessageType type; /* Types defined above */ 511 select(KMFMessageType) { 512 case empty: Empty; 513 /* Used for most tunneled messages */ 514 case supported_profiles: SupportedProfiles; 515 /* MDD->KMF only; supported profiles */ 516 case srtp_key_information: SRTPKeyInformation; 517 /* KMF->MDD only; HBH cipher and key info */ 518 } body; 519 opaque dtls_message<0..2^16-1>; 520 /* Encapsulated DTLS message */ 521 } DTLSTunnelMessage; 523 struct { } Empty; 525 /* Much of the following is borrowed from RFC 5764 */ 527 uint8 SRTPProtectionProfile[2]; 528 SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>; 530 struct { 531 SRTPProtectionProfiles SRTPProtectionProfiles; 532 opaque srtp_mki<0..255>; 533 } SupportedProfiles; 535 struct { 536 uint8 protection_profile[2]; 537 opaque client_write_SRTP_master_key<1..2^16-1>; 538 opaque server_write_SRTP_master_key<1..2^16-1>; 539 opaque client_write_SRTP_master_salt<1..2^16-1>; 540 opaque server_write_SRTP_master_salt<1..2^16-1>; 541 } SRTPKeyInformation; 543 7. IANA Considerations 545 There are no IANA considerations for this document. 547 8. Security Considerations 549 [TBD] 551 9. Acknowledgments 553 The author would like to thank David Benham for reviewing this 554 document and providing constructive comments. 556 10. Normative References 558 [I-D.ietf-avtcore-srtp-ekt] 559 Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key 560 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03 561 (work in progress), October 2014. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 565 RFC2119, March 1997, 566 . 568 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 569 Jacobson, "RTP: A Transport Protocol for Real-Time 570 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 571 July 2003, . 573 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 574 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 575 RFC 3711, DOI 10.17487/RFC3711, March 2004, 576 . 578 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 579 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 580 RFC5246, August 2008, 581 . 583 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 584 Security (DTLS) Extension to Establish Keys for the Secure 585 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 586 10.17487/RFC5764, May 2010, 587 . 589 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 590 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 591 January 2012, . 593 Author's Address 595 Paul Jones 596 Cisco 597 7025 Kit Creek Rd. 598 Research Trianle Park, North Carolina 27709 599 USA 601 Phone: +1 919 476 2048 602 Email: paulej@packetizer.com