idnits 2.17.1 draft-ietf-avt-dtls-srtp-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 489 has weird spacing: '... secret labe...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2009) is 5498 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: 'ChangeCipherSpec' is mentioned on line 1045, but not defined -- Looks like a reference, but probably isn't: '2' on line 305 == Missing Reference: 'RFC-XXXX' is mentioned on line 923, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-tls-extractor-03 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-01 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-05 == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-01 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 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 4 Intended status: Standards Track E. Rescorla 5 Expires: September 1, 2009 RTFM, Inc. 6 February 28, 2009 8 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for 9 Secure Real-time Transport Protocol (SRTP) 10 draft-ietf-avt-dtls-srtp-07.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 1, 2009. 45 Copyright Notice 47 Copyright (c) 2009 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 in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes a Datagram Transport Layer Security (DTLS) 59 extension to establish keys for secure RTP (SRTP) and secure RTP 60 Control Protocol (SRTCP) flows. DTLS keying happens on the media 61 path, independent of any out-of-band signalling channel present. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 67 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 5 68 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 6 69 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 6 70 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 8 71 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 9 72 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 10 73 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 11 74 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 13 76 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13 77 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13 78 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 14 79 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 14 80 5.2. Rehandshake and Re-key . . . . . . . . . . . . . . . . . . 17 81 6. Multi-party RTP Sessions . . . . . . . . . . . . . . . . . . . 17 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 18 84 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 18 85 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18 86 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 19 87 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 19 88 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19 89 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 20 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 94 11.2. Informational References . . . . . . . . . . . . . . . . . 22 95 Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23 96 Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 The Secure RTP profile (SRTP) [RFC3711] can provide confidentiality, 102 message authentication, and replay protection to RTP data and RTP 103 Control (RTCP) traffic. SRTP does not provide key management 104 functionality, but instead depends on external key management to 105 exchange secret master keys, and to negotiate the algorithms and 106 parameters for use with those keys. 108 Datagram Transport Layer Security (DTLS) [RFC4347] is a channel 109 security protocol that offers integrated key management, parameter 110 negotiation, and secure data transfer. Because DTLS data transfer 111 protocol is generic, it is less highly optimized for use with RTP 112 than is SRTP, which has been specifically tuned for that purpose. 114 This document describes DTLS-SRTP, a SRTP extension for DTLS which 115 combines the performance and encryption flexibility benefits of SRTP 116 with the flexibility and convenience of DTLS integrated key and 117 association management. DTLS-SRTP can be viewed in two equivalent 118 ways: as a new key management method for SRTP, and a new RTP- 119 specific data format for DTLS. 121 The key points of DTLS-SRTP are that: 122 o application data is protected using SRTP, 123 o the DTLS handshake is used to establish keying material, 124 algorithms, and parameters for SRTP, 125 o a DTLS extension is used to negotiate SRTP algorithms, and 126 o other DTLS record layer content types are protected using the 127 ordinary DTLS record format. 129 The remainder of this memo is structured as follows. Section 2 130 describes conventions used to indicate normative requirements. 131 Section 3 provides an overview of DTLS-SRTP operation. Section 4 132 specifies the DTLS extensions, while Section 5 discusses how RTP and 133 RTCP are transported over a DTLS-SRTP channel. Section 6 describes 134 use with multi-party sessions. Section 7 and Section 9 describe 135 Security and IANA considerations. 137 2. Conventions Used In This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Overview of DTLS-SRTP Operation 145 DTLS-SRTP is defined for point-to-point media sessions, in which 146 there are exactly two participants. Each DTLS-SRTP session contains 147 a single DTLS association (called a "connection" in TLS jargon), and 148 either two SRTP contexts (if media traffic is flowing in both 149 directions on the same host/port quartet) or one SRTP context (if 150 media traffic is only flowing in one direction). All SRTP traffic 151 flowing over that pair in a given direction uses a single SRTP 152 context. A single DTLS-SRTP session only protects data carried over 153 a single UDP source and destination port pair. 155 The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP 156 flow the peers do a DTLS handshake on the same source and destination 157 port pair to establish a DTLS association. Which side is the DTLS 158 client and which side is the DTLS server must be established via some 159 out of band mechanism such as SDP. The keying material from that 160 handshake is fed into the SRTP stack. Once that association is 161 established, RTP packets are protected (becoming SRTP) using that 162 keying material. 164 RTP and RTCP traffic is usually sent on two separate UDP ports. When 165 symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions 166 are needed, one for the RTP port, one for the RTCP port. When RTP 167 flows are not symmetric, four unidirectional DTLS-SRTP sessions are 168 needed (for inbound and outbound RTP, and inbound and outbound RTCP). 170 Symmetric RTP [RFC4961] is the case in which there are two RTP 171 sessions that have their source and destination ports and addresses 172 reversed, in a manner similar to the way that a TCP connection uses 173 its ports. Each participant has an inbound RTP session and an 174 outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP 175 session can protect both of the RTP sessions. It is RECOMMENDED that 176 symmetric RTP be used with DTLS-SRTP. 178 RTP and RTCP traffic MAY be multiplexed on a single UDP port 179 [I-D.ietf-avt-rtp-and-rtcp-mux] In this case, both RTP and RTCP 180 packets may be sent over the same DTLS-SRTP session, halving the 181 number of DTLS-SRTP sessions needed. This improves the cryptographic 182 performance of DTLS, but may cause problems when RTCP and RTP are 183 subject to different network treatment (e.g., for bandwidth 184 reservation or scheduling reasons.) 186 Between a single pair of participants, there may be multiple media 187 sessions. There MUST be a separate DTLS-SRTP session for each 188 distinct pair of source and destination ports used by a media session 189 (though the sessions can share a single DTLS session and hence 190 amortize the initial public key handshake!). 192 A DTLS-SRTP session may be indicated by an external signaling 193 protocol like SIP. When the signaling exchange is integrity- 194 protected (e.g when SIP Identity protection via digital signatures is 195 used), DTLS-SRTP can leverage this integrity guarantee to provide 196 complete security of the media stream. A description of how to 197 indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to 198 authenticate the endpoints using fingerprints can be found in 199 [I-D.ietf-sip-dtls-srtp-framework]. 201 In a naive implementation, when there are multiple media sessions, 202 there is a new DTLS session establishment (complete with public key 203 cryptography) for each media channel. For example, a videophone may 204 be sending both an audio stream and a video stream, each of which 205 would use a separate DTLS session establishment exchange, which would 206 proceed in parallel. As an optimization, the DTLS-SRTP 207 implementation SHOULD use the following strategy: a single DTLS 208 association is established, and all other DTLS associations wait 209 until that connection is established before proceeding with their 210 handshakes. This strategy allows the later sessions to use DTLS 211 session resumption, which allows the amortization of the expensive 212 public key cryptography operations over multiple DTLS handshakes. 214 The SRTP keys used to protect packets originated by the client are 215 distinct from the SRTP keys used to protect packets originated by the 216 server. All of the RTP sources originating on the client for the 217 same channel use the same SRTP keys, and similarly, all of the RTP 218 sources originating on the server for the same channel use the same 219 SRTP keys. The SRTP implementation MUST ensure that all of the SSRC 220 values for all of the RTP sources originating from the same device 221 over the same channel are distinct, in order to avoid the "two-time 222 pad" problem (as described in Section 9.1 of RFC 3711). Note that 223 this is not an issue for separate media streams (on different host/ 224 port quartets) which use independent keying material even if an SSRC 225 collision occurs. 227 4. DTLS Extensions for SRTP Key Establishment 229 4.1. The use_srtp Extension 231 In order to negotiate the use of SRTP data protection, clients 232 include an extension of type "use_srtp" in the DTLS extended client 233 hello. This extension MUST only be used when the data being 234 transported is RTP or RTCP [RFC3550]. The "extension_data" field of 235 this extension contains the list of acceptable SRTP protection 236 profiles, as indicated below. 238 Servers that receive an extended hello containing a "use_srtp" 239 extension can agree to use SRTP by including an extension of type 240 "use_srtp", with the chosen protection profile in the extended server 241 hello. This process is shown below. 243 Client Server 245 ClientHello + use_srtp --------> 246 ServerHello + use_srtp 247 Certificate* 248 ServerKeyExchange* 249 CertificateRequest* 250 <-------- ServerHelloDone 251 Certificate* 252 ClientKeyExchange 253 CertificateVerify* 254 [ChangeCipherSpec] 255 Finished --------> 256 [ChangeCipherSpec] 257 <-------- Finished 258 SRTP packets <-------> SRTP packets 260 Note that '*' indicates messages which are not always sent in DTLS. 261 The CertificateRequest, client and server Certificates, and 262 CertificateVerify will be sent in DTLS-SRTP. 264 Once the "use_srtp" extension is negotiated, the RTP or RTCP 265 application data is protected solely using SRTP. Application data is 266 never sent in DTLS record-layer "application_data" packets. Rather, 267 complete RTP or RTCP packets are passed to the DTLS stack which 268 passes them to the SRTP stack which protects them appropriately. 269 Note that if RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is 270 in use, this means that RTP and RTCP packets may both be passed to 271 the DTLS stack. Because the DTLS layer does not process the packets, 272 it does not need to distinguish them. The SRTP stack can use the 273 procedures of [I-D.ietf-avt-rtp-and-rtcp-mux] to distinguish RTP from 274 RTCP. 276 When the "use_srtp" extension is in effect, implementations must not 277 place more than one application data "record" per datagram. (This is 278 only meaningful from the perspective of DTLS because SRTP is 279 inherently oriented towards one payload per packet, but is stated 280 purely for clarification.) 282 Data other than RTP/RTCP (i.e., TLS control messages) MUST use 283 ordinary DTLS framing and MUST be placed in separate datagrams from 284 SRTP data. 286 A DTLS-SRTP handshake establishes one or more SRTP crypto contexts, 287 however they all have the same SRTP Protection Profile and MKI (if 288 any). MKIs are used solely to distinguish the keying material and 289 protection profiles between distinct handshakes, for instance due to 290 rekeying. When an MKI is established in a DTLS-SRTP session, it MUST 291 apply for all of the SSRCs within that session---though a single 292 endpoint may negotiate multiple DTLS-SRTP sessions due, for instance, 293 to forking. (Note that RFC 3711 allows packets within the same 294 session but with different SSRCs to use MKIs differently; in 295 contrast, DTLS-SRTP requires that MKIs and the keys that they are 296 associated with have the same meaning and are uniform across the 297 entire SRTP session.) 299 4.1.1. use_srtp Extension Definition 301 The client MUST fill the extension_data field of the "use_srtp" 302 extension with an UseSRTPData value (see Section 9 for the 303 registration): 305 uint8 SRTPProtectionProfile[2]; 307 struct { 308 SRTPProtectionProfiles SRTPProtectionProfiles; 309 opaque srtp_mki<0..255>; 310 } UseSRTPData; 312 SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>; 314 The SRTPProtectionProfiles list indicates the SRTP protection 315 profiles that the client is willing to support, listed in descending 316 order of preference. The srtp_mki value contains the SRTP 317 MasterKeyIdentifier (MKI) value (if any) which the client will use 318 for his SRTP packets. If this field is of zero length, then no MKI 319 will be used. 321 Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" 322 indicates a variable length value with a length between 0 and 255 323 (inclusive). Thus, the MKI may be up to 255 bytes long. 325 If the server is willing to accept the use_srtp extension, it MUST 326 respond with its own "use_srtp" extension in the ExtendedServerHello. 327 The extension_data field MUST contain a UseSRTPData value with a 328 single SRTPProtectionProfile value which the server has chosen for 329 use with this connection. The server MUST NOT select a value which 330 the client has not offered. If there is no shared profile, the 331 server SHOULD NOT return the use_srtp extension at which point the 332 connection falls back to the negotiated DTLS cipher suite. If that 333 is not acceptable the server SHOULD return an appropriate DTLS alert. 335 4.1.2. SRTP Protection Profiles 337 A DTLS-SRTP SRTP Protection Profile defines the parameters and 338 options that are in effect for the SRTP processing. This document 339 defines the following SRTP protection profiles. 341 SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01}; 342 SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02}; 343 SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05}; 344 SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06}; 346 The following list indicates the SRTP transform parameters for each 347 protection profile. The parameters cipher_key_length, 348 cipher_salt_length, auth_key_length, and auth_tag_length express the 349 number of bits in the values to which they refer. The 350 maximum_lifetime parameter indicates the maximum number of packets 351 that can be protected with each single set of keys when the parameter 352 profile is in use. All of these parameters apply to both RTP and 353 RTCP, unless the RTCP parameters are separately specified. 355 All of the crypto algorithms in these profiles are from [RFC3711]. 357 SRTP_AES128_CM_HMAC_SHA1_80 358 cipher: AES_128_CM 359 cipher_key_length: 128 360 cipher_salt_length: 112 361 maximum_lifetime: 2^31 362 auth_function: HMAC-SHA1 363 auth_key_length: 160 364 auth_tag_length: 80 365 SRTP_AES128_CM_HMAC_SHA1_32 366 cipher: AES_128_CM 367 cipher_key_length: 128 368 cipher_salt_length: 112 369 maximum_lifetime: 2^31 370 auth_function: HMAC-SHA1 371 auth_key_length: 160 372 auth_tag_length: 32 373 RTCP auth_tag_length: 80 374 SRTP_NULL_HMAC_SHA1_80 375 cipher: NULL 376 cipher_key_length: 0 377 cipher_salt_length: 0 378 maximum_lifetime: 2^31 379 auth_function: HMAC-SHA1 380 auth_key_length: 160 381 auth_tag_length: 80 382 SRTP_NULL_HMAC_SHA1_32 383 cipher: NULL 384 cipher_key_length: 0 385 cipher_salt_length: 0 386 maximum_lifetime: 2^31 387 auth_function: HMAC-SHA1 388 auth_key_length: 160 389 auth_tag_length: 32 390 RTCP auth_tag_length: 80 392 With all of these SRTP Parameter profiles, the following SRTP options 393 are in effect: 395 o The TLS PseudoRandom Function (PRF) is used to generate keys to 396 feed into the SRTP KDF. When DTLS 1.2 [I-D.ietf-tls-rfc4347-bis] 397 is in use, the PRF is the one associated with the cipher suite. 398 Note that this specification is compatible with DTLS 1.0 or DTLS 399 1.2 400 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 401 not re-derived based on the SRTP sequence number. 402 o The key derivation procedures from Section 4.3 with the AES-CM PRF 403 from RFC 3711 is used. 404 o For all other parameters, (in particular, SRTP replay window size 405 and FEC order) the default values are used. 407 If values other than the defaults for these parameters are required, 408 they can be enabled by writing a separate specification specifying 409 SDP syntax to signal them. 411 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection 412 Profiles between the DTLS-SRTP session that protects an RTP flow and 413 the DTLS-SRTP session that protects the associated RTCP flow (in 414 those case in which the RTP and RTCP are not multiplexed over a 415 common port). In particular, identical ciphers SHOULD be used. 417 New SRTPProtectionProfile values must be defined according to the 418 "Specification Required" policy as defined by RFC 5226 [RFC5226]. 419 See Section 9 for IANA Considerations. 421 4.1.3. srtp_mki value 423 The srtp_mki value MAY be used to indicate the capability and desire 424 to use the SRTP Master Key Indicator (MKI) field in the SRTP and 425 SRTCP packets. The MKI field indicates to an SRTP receiver which key 426 was used to protect the packet that contains that field. The 427 srtp_mki field contains the value of the SRTP MKI which is associated 428 with the SRTP master keys derived from this handshake. Each SRTP 429 session MUST have exactly one master key that is used to protect 430 packets at any given time. The client MUST choose the MKI value so 431 that it is distinct from the last MKI value that was used, and it 432 SHOULD make these values unique for the duration of the TLS session. 434 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, 435 the server MUST either (assuming it accepts the extension at all): 437 1. include a matching "srtp_mki" value in its "use_srtp" extension 438 to indicate that it will make use of the MKI, or 439 2. return an empty "srtp_mki" value to indicate that it cannot make 440 use of the MKI. 442 If the client detects a nonzero-length MKI in the server's response 443 that is different than the one the client offered then the client 444 MUST abort the handshake and SHOULD send an invalid_parameter alert. 445 If the client and server agree on an MKI, all SRTP packets protected 446 under the new security parameters MUST contain that MKI. 448 Note that any given DTLS-SRTP session only has a single active MKI 449 (if any). Thus, at any given time, a set of endpoints will generally 450 only be using one MKI (the major exception is during rehandshakes). 452 4.2. Key Derivation 454 When SRTP mode is in effect, different keys are used for ordinary 455 DTLS record protection and SRTP packet protection. These keys are 456 generated using a TLS exporter [I-D.ietf-tls-extractor] to generate 2 457 * (SRTPSecurityParams.master_key_len + 458 SRTPSecurityParams.master_salt_len) bytes of data, which are assigned 459 as shown below. The per-association context value is empty. 461 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 462 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 463 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 464 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 466 The exporter label for this usage is "EXTRACTOR-dtls_srtp". [The 467 "EXTRACTOR" prefix is for historical compatibility.] 469 The four keying material values (the master key and master salt for 470 each direction) are provided as inputs to the SRTP key derivation 471 mechanism, as shown in Figure 1 and detailed below. By default, the 472 mechanism defined in Section 4.3 of [RFC3711] is used, unless another 473 key derivation mechanism is specified as part of an SRTP Protection 474 Profile. 476 The client_write_SRTP_master_key and client_write_SRTP_master_salt 477 are provided to one invocation of the SRTP key derivation function, 478 to generate the SRTP keys used to encrypt and authenticate packets 479 sent by the client. The server MUST only use these keys to decrypt 480 and to check the authenticity of inbound packets. 482 The server_write_SRTP_master_key and server_write_SRTP_master_salt 483 are provided to one invocation of the SRTP key derivation function, 484 to generate the SRTP keys used to encrypt and authenticate packets 485 sent by the server. The client MUST only use these keys to decrypt 486 and to check the authenticity of inbound packets. 488 TLS master 489 secret label 490 | | 491 v v 492 +---------------+ 493 | TLS extractor | 494 +---------------+ 495 | +------+ SRTP 496 +-> client_write_SRTP_master_key ----+--->| SRTP |-> client 497 | | +->| KDF | write 498 | | | +------+ keys 499 | | | 500 +-> server_write_SRTP_master_key -- | | +------+ SRTCP 501 | \ \--->|SRTCP |-> client 502 | \ +->| KDF | write 503 | | | +------+ keys 504 +-> client_write_SRTP_master_salt ---|-+ 505 | | 506 | | +------+ SRTP 507 | +--->| SRTP |-> server 508 +-> server_write_SRTP_master_salt -+-|--->| KDF | write 509 | | +------+ keys 510 | | 511 | | +------+ SRTCP 512 | +--->|SRTCP |-> server 513 +----->| KDF | write 514 +------+ keys 516 Figure 1: The derivation of the SRTP keys. 518 When both RTCP and RTP use the same source and destination ports, 519 then both the SRTP and SRTCP keys are needed. Otherwise, there are 520 two DTLS-SRTP sessions, one of which protects the RTP packets and one 521 of which protects the RTCP packets; each DTLS-SRTP session protects 522 the part of an SRTP session that passes over a single source/ 523 destination transport address pair, as shown in Figure 2, independent 524 of which SSRCs are used on that pair. When a DTLS-SRTP session is 525 protecting RTP, the SRTCP keys derived from the DTLS handshake are 526 not needed and are discarded. When a DTLS-SRTP session is protecting 527 RTCP, the SRTP keys derived from the DTLS handshake are not needed 528 and are discarded. 530 Client Server 531 (Sender) (Receiver) 532 (1) <----- DTLS ------> src/dst = a/b and b/a 533 ------ SRTP ------> src/dst = a/b, uses client write keys 535 (2) <----- DTLS ------> src/dst = c/d and d/c 536 ------ SRTCP -----> src/dst = c/d, uses client write keys 537 <----- SRTCP ------ src/dst = d/c, uses server write keys 539 Figure 2: A DTLS-SRTP session protecting RTP (1) and another one 540 protecting RTCP (2), showing the transport addresses and keys used. 542 4.3. Key Scope 544 Because of the possibility of packet reordering, DTLS-SRTP 545 implementations SHOULD store multiple SRTP keys sets during a re-key 546 in order to avoid the need for receivers to drop packets for which 547 they lack a key. 549 4.4. Key Usage Limitations 551 The maximum_lifetime parameter in the SRTP protection profile 552 indicates the maximum number of packets that can be protected with 553 each single encryption and authentication key. (Note that, since RTP 554 and RTCP are protected with independent keys, those protocols are 555 counted separately for the purposes of determining when a key has 556 reached the end of its lifetime.) Each profile defines its own 557 limit. When this limit is reached, a new DTLS session SHOULD be used 558 to establish replacement keys, and SRTP implementations MUST NOT use 559 the existing keys for the processing of either outbound or inbound 560 traffic. 562 5. Use of RTP and RTCP over a DTLS-SRTP Channel 564 5.1. Data Protection 566 Once the DTLS handshake has completed the peers can send RTP or RTCP 567 over the newly created channel. We describe the transmission process 568 first followed by the reception process. 570 Within each RTP session, SRTP processing MUST NOT take place before 571 the DTLS handshake completes. 573 5.1.1. Transmission 575 DTLS and TLS define a number of record content types. In ordinary 576 TLS/DTLS, all data is protected using the same record encoding and 577 mechanisms. When the mechanism described in this document is in 578 effect, this is modified so that data written by upper level protocol 579 clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP 580 rather than the standard TLS record encoding. 582 When a user of DTLS wishes to send an RTP packet in SRTP mode it 583 delivers it to the DTLS implementation as an ordinary application 584 data write (e.g., SSL_write()). The DTLS implementation then invokes 585 the processing described in RFC 3711 Sections 3 and 4. The resulting 586 SRTP packet is then sent directly on the wire as a single datagram 587 with no DTLS framing. This provides an encapsulation of the data 588 that conforms to and interoperates with SRTP. Note that the RTP 589 sequence number rather than the DTLS sequence number is used for 590 these packets. 592 5.1.2. Reception 594 When DTLS-SRTP is used to protect an RTP session, the RTP receiver 595 needs to demultiplex packets that are arriving on the RTP port. 596 Arriving packets may be of types RTP, DTLS, or 597 STUN[I-D.ietf-behave-rfc3489bis]. If these are the only types of 598 packets present, the type of a packet can be determined by looking at 599 its first byte. 601 The process for demultiplexing a packet is as follows. The receiver 602 looks at the first byte of the packet. If the value of this byte is 603 0 or 1, then the packet is STUN. If the value is in between 128 and 604 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 605 RTP are being multiplexed over the same destination port). If the 606 value is between 20 and 63 (inclusive), the packet is DTLS. This 607 processes is summarized in Figure 3. 609 +----------------+ 610 | 127 < B < 192 -+--> forward to RTP 611 | | 612 packet --> | 19 < B < 64 -+--> forward to DTLS 613 | | 614 | B < 2 -+--> forward to STUN 615 +----------------+ 617 Figure 3: The DTLS-SRTP receiver's packet demultiplexing 618 algorithm. Here the field B denotes the leading byte of the packet. 620 If other packet types are to be multiplexed as well, implementors 621 and/or designers SHOULD ensure that they can be demultiplexed from 622 these three packet types. 624 In some cases there will be multiple DTLS-SRTP associations for a 625 given SRTP endpoint. For instance, if Alice makes a call which is 626 SIP forked to both Bob and Charlie, she will use the same local host/ 627 port pair for both of them, as shown in Figure 4. (The SSRCs shown 628 are the ones for data flowing to Alice). 630 Bob (192.0.2.1:6666) 631 / 632 / 633 / SSRC=1 634 / DTLS-SRTP=XXX 635 / 636 v 637 Alice (192.0.2.0:5555) 638 ^ 639 \ 640 \ SSRC=2 641 \ DTLS-SRTP=YYY 642 \ 643 \ 644 Charlie (192.0.2.2:6666) 646 Figure 4: RTP sessions with SIP forking 648 Because DTLS operates on the host/port quartet, the DTLS association 649 will still complete correctly, with the foreign host/port pair being 650 used to distinguish the associations. However, in RTP the source 651 host/port is not used and sessions are identified by the destination 652 host/port and the SSRC. Thus, some mechanism is needed to determine 653 which SSRCs correspond to which DTLS associations. The following 654 method SHOULD be used. 656 For each local host/port pair, the DTLS-SRTP implementation maintains 657 a table listing all the SSRCs it knows about and the DTLS-SRTP 658 associations they correspond to. Initially, this table is empty. 659 When an SRTP packet is received for a given RTP endpoint (destination 660 IP/port pair), the following procedure is used: 662 1. If the SSRC is already known for that endpoint, then the 663 corresponding DTLS-SRTP association and its keying material is 664 used to decrypt and verify the packet. 665 2. If the SSRC is not known, then the receiver tries to decrypt it 666 with the keying material corresponding to each DTLS-SRTP 667 association for that endpoint. 669 3. If the decryption and verification succeeds (the authentication 670 tag verifies) then an entry is placed in the table mapping the 671 SSRC to that association. 672 4. If the decryption and verification fails, then the packet is 673 silently discarded. 674 5. When a DTLS-SRTP association is closed (for instance because the 675 fork is abandoned) its entries MUST be removed from the mapping 676 table. 678 The average cost of this algorithm for a single SSRC is the 679 decryption and verification time of a single packet times the number 680 of valid DTLS-SRTP associations corresponding to a single receiving 681 port on the host. In practice, this means the number of forks, so in 682 the case shown in Figure 4, that would be two. This cost is only 683 incurred once for any given SSRC, since afterwards that SSRC is 684 placed in the map table and looked up immediately. As with normal 685 RTP, this algorithm allows new SSRCs to be introduced by the source 686 at any time. They will automatically be mapped to the correct DTLS 687 association. 689 Note that this algorithm explicitly allows multiple SSRCs to be sent 690 from the same address/port pair. One way in which this can happen is 691 an RTP translator. This algorithm will automatically assign the 692 SSRCs to the correct associations. Note that because the SRTP 693 packets are cryptographically protected, such a translator must 694 either share keying material with one endpoint or refrain from 695 modifying the packets in a way which would cause the integrity check 696 to fail. This is a general property of SRTP and is not specific to 697 DTLS-SRTP. 699 There are two error cases that should be considered. First, if an 700 SSRC collision occurs, then only the packets from the first source 701 will be processed. When the packets from the second source arrive, 702 the DTLS association with the first source will be used for 703 decryption and verification, which will fail, and the packet will be 704 discarded. This is consistent with [RFC3550], which permits the 705 receiver to keep the packets from one source and discard those from 706 the other. Of course the RFC 3550 SSRC collision detection and 707 handling procedures MUST also be followed. 709 Second, there may be cases where a malfunctioning source is sending 710 corrupt packets which cannot be decrypted and verified. In this 711 case, the SSRC will never be entered into the mapping table, because 712 the decryption and verification always fails. Receivers MAY keep 713 records of unmapped SSRCs which consistently fail decryption and 714 verification and abandon attempts to process them once they reach 715 some limit. That limit MUST be large enough to account for the 716 effects of transmission errors. Entries MUST be pruned from this 717 table when the relevant SRTP endpoint is deleted (e.g., the call 718 ends) and SHOULD time out faster than that (we do not offer a hard 719 recommendation but 10 to 30 seconds seems appropriate) in order to 720 allow for the possibility that the peer implementation has been 721 corrected. 723 5.2. Rehandshake and Re-key 725 Rekeying in DTLS is accomplished by performing a new handshake over 726 the existing DTLS channel. I.e., the handshake messages are 727 protected by the existing DTLS cipher suite. This handshake can be 728 performed in parallel with data transport, so no interruption of the 729 data flow is required. Once the handshake is finished, the newly 730 derived set of keys is used to protect all outbound packets, both 731 DTLS and SRTP. 733 Because of packet reordering, packets protected by the previous set 734 of keys can appear on the wire after the handshake has completed. To 735 compensate for this fact, receivers SHOULD maintain both sets of keys 736 for some time in order to be able to decrypt and verify older 737 packets. The keys should be maintained for the duration of the 738 maximum segment lifetime (MSL). 740 If an MKI is used, then the receiver should use the corresponding set 741 of keys to process an incoming packet. If no matching MKI is 742 present, the packet MUST be rejected. Otherwise, when a packet 743 arrives after the handshake completed, a receiver SHOULD use the 744 newly derived set of keys to process that packet unless there is an 745 MKI (If the packet was protected with the older set of keys, this 746 fact will become apparent to the receiver as an authentication 747 failure will occur.) If the authentication check on the packet fails 748 and no MKI is being used, then the receiver MAY process the packet 749 with the older set of keys. If that authentication check indicates 750 that the packet is valid, the packet should be accepted; otherwise, 751 the packet MUST be discarded and rejected. 753 Receivers MAY use the SRTP packet sequence number to aid in the 754 selection of keys. After a packet has been received and 755 authenticated with the new key set, any packets with sequence numbers 756 that are greater will also have been protected with the new key set. 758 6. Multi-party RTP Sessions 760 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only 761 to protect unicast RTP sessions. This does not preclude its use with 762 RTP mixers. For example, a conference bridge may use DTLS-SRTP to 763 secure the communication to and from each of the participants in a 764 conference. However, because each flow between an endpoint and a 765 mixer has its own key, the mixer has to decrypt and then reencrypt 766 the traffic for each recipient. 768 A future specification may describe methods for sharing a single key 769 between multiple DTLS-SRTP associations which would allow 770 conferencing systems to avoid the decrypt/reencrypt stage. However, 771 any system in which the media is modified (e.g., for level balancing 772 or transcoding) will generally need to be performed on the plaintext 773 and will certainly break the authentication tag and therefore will 774 require a decrypt/reencrypt stage. 776 7. Security Considerations 778 The use of multiple data protection framings negotiated in the same 779 handshake creates some complexities, which are discussed here. 781 7.1. Security of Negotiation 783 One concern here is that attackers might be able to implement a bid- 784 down attack forcing the peers to use ordinary DTLS rather than SRTP. 785 However, because the negotiation of this extension is performed in 786 the DTLS handshake, it is protected by the Finished messages. 787 Therefore, any bid-down attack is automatically detected, which 788 reduces this to a denial of service attack - which any attacker who 789 can control the channel can always mount. 791 7.2. Framing Confusion 793 Because two different framing formats are used, there is concern that 794 an attacker could convince the receiver to treat an SRTP-framed RTP 795 packet as a DTLS record (e.g., a handshake message) or vice versa. 796 This attack is prevented by using different keys for MAC verification 797 for each type of data. Therefore, this type of attack reduces to 798 being able to forge a packet with a valid MAC, which violates a basic 799 security invariant of both DTLS and SRTP. 801 As an additional defense against injection into the DTLS handshake 802 channel, the DTLS record type is included in the MAC. Therefore, an 803 SRTP record would be treated as an unknown type and ignored. (See 804 Section 6 of [RFC5246]). 806 7.3. Sequence Number Interactions 808 As described in Section 5.1.1, the SRTP and DTLS sequence number 809 spaces are distinct. This means that it is not possible to 810 unambiguously order a given DTLS control record with respect to an 811 SRTP packet. In general, this is relevant in two situations: alerts 812 and rehandshake. 814 7.3.1. Alerts 816 Because DTLS handshake and change_cipher_spec messages share the same 817 sequence number space as alerts, they can be ordered correctly. 818 Because DTLS alerts are inherently unreliable and SHOULD NOT be 819 generated as a response to data packets, reliable sequencing between 820 SRTP packets and DTLS alerts is not an important feature. However, 821 implementations which wish to use DTLS alerts to signal problems with 822 the SRTP encoding SHOULD simply act on alerts as soon as they are 823 received and assume that they refer to the temporally contiguous 824 stream. Such implementations MUST check for alert retransmission and 825 discard retransmitted alerts to avoid overreacting to replay attacks. 827 7.3.2. Renegotiation 829 Because the rehandshake transition algorithm specified in Section 5.2 830 requires trying multiple sets of keys if no MKI is used, it slightly 831 weakens the authentication. For instance, if an n-bit MAC is used 832 and k different sets of keys are present, then the MAC is weakened by 833 log_2(k) bits to n - log_2(k). In practice, since the number of keys 834 used will be very small and the MACs in use are typically strong (the 835 default for SRTP is 80 bits) the decrease in security involved here 836 is minimal. 838 Another concern here is that this algorithm slightly increases the 839 work factor on the receiver because it needs to attempt multiple 840 validations. However, again, the number of potential keys will be 841 very small (and the attacker cannot force it to be larger) and this 842 technique is already used for rollover counter management, so the 843 authors do not consider this to be a serious flaw. 845 7.4. Decryption Cost 847 An attacker can impose computational costs on the receiver by sending 848 superficially valid SRTP packets which do not decrypt correctly. In 849 general, encryption algorithms are so fast that this cost is 850 extremely small compared to the bandwidth consumed. The SSRC-DTLS 851 mapping algorithm described in Section 5.1.2 gives the attacker a 852 slight advantage here because he can force the receiver to do more 853 then one decryption per packet. However, this advantage is modest 854 because the number of decryptions that the receiver does is limited 855 by the number of associations he has corresponding to a given 856 destination host/port, which is typically quite small. For 857 comparison, a single 1024-bit RSA private key operation (the typical 858 minimum cost to establish a DTLS-SRTP association) is hundreds of 859 times as expensive as decrypting an SRTP packet. 861 Implementations can detect this form of attack by keeping track of 862 the number of SRTP packets observed with unknown SSRCs which fail the 863 authentication tag check. If under such attack, implementations 864 SHOULD prioritize decryption and verification of packets which either 865 have known SSRCs or come from source addresses which match those of 866 peers with which it has DTLS-SRTP associations. 868 8. Session Description for RTP/SAVP over DTLS 870 This specification defines new tokens to describe the protocol used 871 in SDP media descriptions ('m' lines and their associated 872 parameters). The new values defined for the proto field are: 873 o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over 874 DTLS with DCCP, then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/ 875 TLS/RTP/SAVPF respectively. 876 o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with 877 UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF 878 respectively. 880 The "fmt" parameter SHALL be as defined for RTP/SAVP. 882 See [I-D.ietf-sip-dtls-srtp-framework] for how to use offer/answer 883 with DTLS-SRTP. 885 This document does not specify how to protect RTP data transported 886 over TCP. Potential approaches include carrying the RTP over TLS 887 over TCP (see [I-D.ietf-avt-srtp-not-mandatory]) or using a mechanism 888 similar to that in this document over TCP, either via TLS or DTLS, 889 with DTLS being used for consistency between reliable and unreliable 890 transports. In the latter case, it would be necessary to profile 891 DTLS so that fragmentation and retransmissions no longer occurred. 892 In either case, a new document would be required. 894 9. IANA Considerations 896 This document adds a new extension for DTLS, in accordance with 897 [RFC5246]: 898 enum { use_srtp (??) } ExtensionType; 900 [[ NOTE: This value needs to be assigned by IANA ]] 902 This extension MUST only be used with DTLS, and not with TLS 903 [RFC4572] which specifies that TLS can be used over TCP but does not 904 address TCP for RTP/SAVP. 906 Section 4.1.2 requires that all SRTPProtectionProfile values be 907 defined by RFC 5226 Specification Required. IANA will create/(has 908 created) a DTLS SRTPProtectionProfile registry initially populated 909 with values from Section 4.1.2 of this document. Future values MUST 910 be allocated via the "Specification Required" profile of [RFC5226] 912 This specification updates the "Session Description Protocol (SDP) 913 Parameters" registry as defined in section 8.2.2 of RFC 4566 914 [RFC4566]. Specifically it adds the following values to the table 915 for the "proto" field. 917 Type SDP Name Reference 918 ---- ------------------ --------- 919 proto UDP/TLS/RTP/SAVP [RFC-XXXX] 920 proto DCCP/TLS/RTP/SAVP [RFC-XXXX] 922 proto UDP/TLS/RTP/SAVPF [RFC-XXXX] 923 proto DCCP/TLS/RTP/SAVPF [RFC-XXXX] 925 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 926 this specification. 928 IANA should register/has registered the "EXTRACTOR-dtls_srtp". value 929 in the TLS Extractor Label Registry to correspond to this 930 specification. 932 10. Acknowledgments 934 Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, 935 Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, 936 and Ben Campbell for input, discussions, and guidance. Pasi Eronen 937 provided Figure 1. 939 11. References 941 11.1. Normative References 943 [I-D.ietf-avt-rtp-and-rtcp-mux] 944 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 945 Control Packets on a Single Port", 946 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 947 August 2007. 949 [I-D.ietf-tls-extractor] 950 Rescorla, E., "Keying Material Extractors for Transport 951 Layer Security (TLS)", draft-ietf-tls-extractor-03 (work 952 in progress), November 2008. 954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 955 Requirement Levels", BCP 14, RFC 2119, March 1997. 957 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 958 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 959 RFC 3711, March 2004. 961 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 962 Security", RFC 4347, April 2006. 964 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 965 BCP 131, RFC 4961, July 2007. 967 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 968 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 970 11.2. Informational References 972 [I-D.ietf-avt-srtp-not-mandatory] 973 Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a 974 Single Security Mechanism", 975 draft-ietf-avt-srtp-not-mandatory-01 (work in progress), 976 November 2008. 978 [I-D.ietf-behave-rfc3489bis] 979 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 980 "Session Traversal Utilities for (NAT) (STUN)", 981 draft-ietf-behave-rfc3489bis-18 (work in progress), 982 July 2008. 984 [I-D.ietf-sip-dtls-srtp-framework] 985 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 986 for Establishing an SRTP Security Context using DTLS", 987 draft-ietf-sip-dtls-srtp-framework-05 (work in progress), 988 October 2008. 990 [I-D.ietf-tls-rfc4347-bis] 991 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 992 Security version 1.2", draft-ietf-tls-rfc4347-bis-01 (work 993 in progress), November 2008. 995 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 996 Jacobson, "RTP: A Transport Protocol for Real-Time 997 Applications", STD 64, RFC 3550, July 2003. 999 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1000 Description Protocol", RFC 4566, July 2006. 1002 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1003 Transport Layer Security (TLS) Protocol in the Session 1004 Description Protocol (SDP)", RFC 4572, July 2006. 1006 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1007 Real-time Transport Control Protocol (RTCP)-Based Feedback 1008 (RTP/SAVPF)", RFC 5124, February 2008. 1010 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1011 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1012 May 2008. 1014 Appendix A. Overview of DTLS 1016 This section provides a brief overview of Datagram TLS (DTLS) for 1017 those who are not familiar with it. DTLS is a channel security 1018 protocol based on the well-known Transport Layer Security (TLS) 1019 [RFC5246] protocol. Where TLS depends on a reliable transport 1020 channel (typically TCP), DTLS has been adapted to support unreliable 1021 transports such as UDP. Otherwise, DTLS is nearly identical to TLS 1022 and generally supports the same cryptographic mechanisms. 1024 Each DTLS association begins with a handshake exchange (shown below) 1025 during which the peers authenticate each other and negotiate 1026 algorithms, modes, and other parameters and establish shared keying 1027 material, as shown below. In order to support unreliable transport, 1028 each side maintains retransmission timers to provide reliable 1029 delivery of these messages. Once the handshake is completed, 1030 encrypted data may be sent. 1032 Client Server 1034 ClientHello --------> 1035 ServerHello 1036 Certificate* 1037 ServerKeyExchange* 1038 CertificateRequest* 1039 <-------- ServerHelloDone 1040 Certificate* 1041 ClientKeyExchange 1042 CertificateVerify* 1043 [ChangeCipherSpec] 1044 Finished --------> 1045 [ChangeCipherSpec] 1046 <-------- Finished 1047 Application Data <-------> Application Data 1049 '*' indicates messages which are not always sent. 1051 Application data is protected by being sent as a series of DTLS 1052 "records". These records are independent and which can be processed 1053 correctly even in the face of loss or reordering. In DTLS-SRTP, this 1054 record protocol is replaced with SRTP [RFC3711] 1056 Appendix B. Performance of Multiple DTLS Handshakes 1058 Standard practice for security protocols such as TLS, DTLS, and SSH 1059 which do inline key management is to create a separate security 1060 association for each underlying network channel (TCP connection, UDP 1061 host/port quartet, etc.). This has dual advantages of simplicity and 1062 independence of the security contexts for each channel. 1064 Three concerns have been raised about the overhead of this strategy 1065 in the context of RTP security. The first concern is the additional 1066 performance overhead of doing a separate public key operation for 1067 each channel. The conventional procedure here (used in TLS and DTLS) 1068 is to establish a master context which can then be used to derive 1069 fresh traffic keys for new associations. In TLS/DTLS this is called 1070 "session resumption" and can be transparently negotiated between the 1071 peers. 1073 The second concern is network bandwidth overhead for the 1074 establishment of subsequent connections and for rehandshake (for 1075 rekeying) for existing connections. In particular, there is a 1076 concern that the channels will have very narrow capacity requirements 1077 allocated entirely to media which will be overflowed by the 1078 rehandshake. Measurements of the size of the rehandshake (with 1079 resumption) in TLS indicate that it is about 300-400 bytes if a full 1080 selection of cipher suites is offered. (the size of a full handshake 1081 is approximately 1-2k larger because of the certificate and keying 1082 material exchange). 1084 The third concern is the additional round-trips associated with 1085 establishing the 2nd, 3rd, ... channels. In TLS/DTLS these can all 1086 be done in parallel but in order to take advantage of session 1087 resumption they should be done after the first channel is 1088 established. For two channels this provides a ladder diagram 1089 something like this (parenthetical #s are media channel #s) 1091 Alice Bob 1092 ------------------------------------------- 1093 <- ClientHello (1) 1094 ServerHello (1) -> 1095 Certificate (1) 1096 ServerHelloDone (1) 1097 <- ClientKeyExchange (1) 1098 ChangeCipherSpec (1) 1099 Finished (1) 1100 ChangeCipherSpec (1)-> 1101 Finished (1)-> 1102 <--- Channel 1 ready 1104 <- ClientHello (2) 1105 ServerHello (2) -> 1106 ChangeCipherSpec(2)-> 1107 Finished(2) -> 1108 <- ChangeCipherSpec (2) 1109 Finished (2) 1110 <--- Channel 2 ready 1112 So, there is an additional 1 RTT after Channel 1 is ready before 1113 Channel 2 is ready. If the peers are potentially willing to forego 1114 resumption they can interlace the handshakes, like so: 1116 Alice Bob 1117 ------------------------------------------- 1118 <- ClientHello (1) 1119 ServerHello (1) -> 1120 Certificate (1) 1121 ServerHelloDone (1) 1122 <- ClientKeyExchange (1) 1123 ChangeCipherSpec (1) 1124 Finished (1) 1125 <- ClientHello (2) 1126 ChangeCipherSpec (1)-> 1127 Finished (1)-> 1128 <--- Channel 1 ready 1129 ServerHello (2) -> 1130 ChangeCipherSpec(2)-> 1131 Finished(2) -> 1132 <- ChangeCipherSpec (2) 1133 Finished (2) 1134 <--- Channel 2 ready 1136 In this case the channels are ready contemporaneously, but if a 1137 message in handshake (1) is lost then handshake (2) requires either a 1138 full rehandshake or that Alice be clever and queue the resumption 1139 attempt until the first handshake completes. Note that just dropping 1140 the packet works as well since Bob will retransmit. 1142 Authors' Addresses 1144 David McGrew 1145 Cisco Systems 1146 510 McCarthy Blvd. 1147 Milpitas, CA 95305 1148 USA 1150 Email: mcgrew@cisco.com 1152 Eric Rescorla 1153 RTFM, Inc. 1154 2064 Edgewood Drive 1155 Palo Alto, CA 94303 1156 USA 1158 Email: ekr@rtfm.com