idnits 2.17.1 draft-ietf-avt-dtls-srtp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1114. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1138. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the server is willing to accept the use_srtp extension, it MUST respond with its own "use_srtp" extension in the ExtendedServerHello. The extension_data field MUST contain a UseSRTPData value with a single SRTPProtectionProfile value which the server has chosen for use with this connection. The server MUST NOT select a value which the client has not offered. If there is no shared profile, the server SHOULD not return the use_srtp extension at which point the connection falls back to the negotiated DTLS cipher suite. If that is not acceptable the server SHOULD return an appropriate DTLS alert. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2008) is 5760 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) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 985 -- Looks like a reference, but probably isn't: 'RFC-XXXX' on line 876 == Outdated reference: A later version (-07) exists of draft-ietf-tls-extractor-01 ** Obsolete normative reference: RFC 4346 (ref. '4') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (ref. '5') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (ref. '6') (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-01 == Outdated reference: A later version (-01) exists of draft-mcgrew-srtp-big-aes-00 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '11') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '14') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (ref. '15') (Obsoleted by RFC 8122) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 12 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: January 13, 2009 Network Resonance 6 July 12, 2008 8 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for 9 Secure Real-time Transport Protocol (SRTP) 10 draft-ietf-avt-dtls-srtp-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes a Datagram Transport Layer Security (DTLS) 44 extension to establish keys for secure RTP (SRTP) and secure RTP 45 Control Protocol (SRTCP) flows. DTLS keying happens on the media 46 path, independent of any out-of-band signalling channel present. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 52 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4 53 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5 54 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5 55 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 6 56 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 7 57 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9 58 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12 61 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 12 62 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 12 63 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 12 64 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13 65 5.2. Rehandshake and Re-key . . . . . . . . . . . . . . . . . . 15 66 6. Multi-party RTP Sessions . . . . . . . . . . . . . . . . . . . 16 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17 69 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17 70 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 17 71 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 17 72 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18 73 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 18 74 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 18 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 79 11.2. Informational References . . . . . . . . . . . . . . . . . 21 80 Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 21 81 Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . . . 25 85 1. Introduction 87 The Secure RTP profile (SRTP) [6] can provide confidentiality, 88 message authentication, and replay protection to RTP data and RTP 89 Control (RTCP) traffic. SRTP does not provide key management 90 functionality, but instead depends on external key management to 91 exchange secret master keys, and to negotiate the algorithms and 92 parameters for use with those keys. 94 Datagram Transport Layer Security (DTLS) [5] is a channel security 95 protocol that offers integrated key management, parameter 96 negotiation, and secure data transfer. Because DTLS's data transfer 97 protocol is generic, it is less highly optimized for use with RTP 98 than is SRTP, which has been specifically tuned for that purpose. 100 This document describes DTLS-SRTP, an SRTP extension for DTLS which 101 combine the performance and encryption flexibility benefits of SRTP 102 with the flexibility and convenience of DTLS's integrated key and 103 association management. DTLS-SRTP can be viewed in two equivalent 104 ways: as a new key management method for SRTP, and a new RTP- 105 specific data format for DTLS. 107 The key points of DTLS-SRTP are that: 108 o application data is protected using SRTP, 109 o the DTLS handshake is used to establish keying material, 110 algorithms, and parameters for SRTP, 111 o a DTLS extension used to negotiate SRTP algorithms, and 112 o other DTLS record layer content types are protected using the 113 ordinary DTLS record format. 115 The remainder of this memo is structured as follows. Section 2 116 describes conventions used to indicate normative requirements. 117 Section 3 provides an overview of DTLS-SRTP operation. Section 4 118 specifies the DTLS extensions, while Section 5 discusses how RTP and 119 RTCP are transported over a DTLS-SRTP channel. Section 6 describes 120 use with multi-party sessions. Section 7 and Section 9 describe 121 Security and IANA considerations. 123 2. Conventions Used In This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [3]. 129 3. Overview of DTLS-SRTP Operation 131 DTLS-SRTP is defined for point-to-point media sessions, in which 132 there are exactly two participants. Each DTLS-SRTP session contains 133 a single DTLS association (called a "connection" in TLS jargon), and 134 an SRTP context. A single DTLS-SRTP session only protects data 135 carried over a single UDP source and destination port pair. 137 The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP 138 flow the peers do a DTLS handshake on the same source and destination 139 port pair to establish a DTLS association. The keying material from 140 that handshake is fed into the SRTP stack. Once that association is 141 established, RTP packets are protected (becoming SRTP) using that 142 keying material. 144 RTP and RTCP traffic is usually sent on two separate UDP ports. When 145 symmetric RTP [7] is used, two bidirectional DTLS-SRTP sessions are 146 needed, one for the RTP port, one for the RTCP port. When RTP flows 147 are not symmetric, four unidirectional DTLS-SRTP sessions are needed 148 (for inbound and outbound RTP, and inbound and outbound RTCP). 150 Symmetric RTP [7] is the case in which there are two RTP sessions 151 that have their source and destination ports and addresses reversed, 152 in a manner similar to the way that a TCP connection uses its ports. 153 Each participant has an inbound RTP session and an outbound RTP 154 session. When symmetric RTP is used, a single DTLS-SRTP session can 155 protect both of the RTP sessions. It is RECOMMENDED that symmetric 156 RTP be used with DTLS-SRTP. 158 RTP and RTCP traffic MAY be multiplexed on a single UDP port [1] In 159 this case, both RTP and RTCP packets may be sent over the same DTLS- 160 SRTP session, halving the number of DTLS-SRTP sessions needed This 161 improves the cryptographic performance of DTLS, but may cause 162 problems when RTCP and RTP are subject to different network treatment 163 (e.g., for bandwidth reservation or scheduling reasons.) 165 Between a single pair of participants, there may be multiple media 166 sessions. There MUST be a separate DTLS-SRTP session for each 167 distinct pair of source and destination ports used by a media session 168 (though the sessions can share a single DTLS session and hence 169 amortize the initial public key handshake!). 171 A DTLS-SRTP session MAY be indicated by an external signaling 172 protocol like SIP. When the signaling exchange is integrity- 173 protected (e.g when SIP Identity protection via digital signatures is 174 used), DTLS-SRTP can leverage this integrity guarantee to provide 175 complete security of the media stream. A description of how to 176 indicate DTLS-SRTP sessions in SIP and SDP [14], and how to 177 authenticate the endpoints using fingerprints can be found in [9]. 179 In a naive implementation, when there are multiple media sessions, 180 there is a new DTLS session establishment (complete with public key 181 cryptography) for each media channel. For example, a videophone may 182 be sending both an audio stream and a video stream, each of which 183 would use a separate DTLS session establishment exchange, which would 184 proceed in parallel. As an optimization, the DTLS-SRTP 185 implementation SHOULD use the following strategy: a single DTLS 186 association is established, and all other DTLS associations wait 187 until that connection is established before proceeding with their 188 handshakes establishment exchanges. This strategy allows the later 189 sessions to use DTLS session resumption, which allows the 190 amortization of the expensive public key cryptography operations over 191 multiple DTLS handshakes. 193 The SRTP keys used to protect packets originated by the client are 194 distinct from the SRTP keys used to protect packets originated by the 195 server. All of the RTP sources originating on the client for the 196 same channel use the same SRTP keys, and similarly, all of the RTP 197 sources originating on the server for the same channel use the same 198 SRTP keys. The SRTP implementation MUST ensure that all of the SSRC 199 values for all of the RTP sources originating from the same device 200 over the same channel are distinct, in order to avoid the "two-time 201 pad" problem (as described in Section 9.1 of RFC 3711). Note that 202 this is not an issue for separate media streams (on different host/ 203 port quartets) which use independent keying material even if an SSRC 204 collision occurs. 206 4. DTLS Extensions for SRTP Key Establishment 208 4.1. The use_srtp Extension 210 In order to negotiate the use of SRTP data protection, clients 211 include an extension of type "use_srtp" in the DTLS extended client 212 hello. This extension MUST only be used when the data being 213 transported is RTP and RTCP [12]. The "extension_data" field of this 214 extension contains the list of acceptable SRTP protection profiles, 215 as indicated below. 217 Servers that receive an extended hello containing a "use_srtp" 218 extension can agree to use SRTP by including an extension of type 219 "use_srtp", with the chosen protection profile in the extended server 220 hello. This process is shown below. 222 Client Server 224 ClientHello + use_srtp --------> 225 ServerHello + use_srtp 226 Certificate* 227 ServerKeyExchange* 228 CertificateRequest* 229 <-------- ServerHelloDone 230 Certificate* 231 ClientKeyExchange 232 CertificateVerify* 233 [ChangeCipherSpec] 234 Finished --------> 235 [ChangeCipherSpec] 236 <-------- Finished 237 SRTP packets <-------> SRTP packets 239 Note that '*' indicates messages which are not always sent in DTLS. 240 The CertificateRequest, client Certificate, and CertificateVerify 241 will be sent in DTLS-SRTP. 243 Once the "use_srtp" extension is negotiated, the RTP or RTCP 244 application data is protected solely using SRTP. Application data is 245 never sent in DTLS record-layer "application_data" packets. Rather, 246 complete RTP or RTCP packets are passed to the DTLS stack which 247 passes them to the SRTP stack which protects them appropriately. 248 Note that if RTP/RTCP multiplexing [1] is in use, this means that RTP 249 and RTCP packets may both be passed to the DTLS stack. Because the 250 DTLS layer does not process the packets, it does need to distinguish 251 them. The SRTP stack can use the procedures of [1] to distinguish 252 RTP from RTCP. 254 When the "use_srtp" extension is in effect, implementations MUST NOT 255 place more than one application data "record" per datagram. (This is 256 only meaningful from the perspective of DTLS because SRTP is 257 inherently oriented towards one payload per packet, but is stated 258 purely for clarification.) 260 Records of type other than "application_data" MUST use ordinary DTLS 261 framing. 263 4.1.1. use_srtp Extension Definition 265 The client MUST fill the extension_data field of the "use_srtp" 266 extension with an UseSRTPData value (see Section 9 for the 267 registration): 269 uint8 SRTPProtectionProfile[2]; 271 struct { 272 SRTPProtectionProfiles SRTPProtectionProfiles; 273 opaque srtp_mki<0..255>; 274 } UseSRTPData; 276 SRTPProtectionProfile SRTPProtectionProfiles<2^16-1>; 278 The SRTPProtectionProfiles list indicates the SRTP protection 279 profiles that the client is willing to support, listed in descending 280 order of preference. The srtp_mki value contains the SRTP 281 MasterKeyIdentifier (MKI) value (if any) which the client will use 282 for his SRTP packets. If this field is of zero length, then no MKI 283 will be used. 285 Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" 286 indicates a variable length value with a length between 0 and 255 287 (inclusive). Thus, the MKI may be up to 255 bytes long. 289 If the server is willing to accept the use_srtp extension, it MUST 290 respond with its own "use_srtp" extension in the ExtendedServerHello. 291 The extension_data field MUST contain a UseSRTPData value with a 292 single SRTPProtectionProfile value which the server has chosen for 293 use with this connection. The server MUST NOT select a value which 294 the client has not offered. If there is no shared profile, the 295 server SHOULD not return the use_srtp extension at which point the 296 connection falls back to the negotiated DTLS cipher suite. If that 297 is not acceptable the server SHOULD return an appropriate DTLS alert. 299 4.1.2. SRTP Protection Profiles 301 A DTLS-SRTP SRTP Protection Profile defines the parameters and 302 options that are in effect for the SRTP processing. This document 303 defines the following SRTP protection profiles. 305 SRTPProtectionProfile SRTP_AES128_CM_SHA1_80 = {0x00, 0x01}; 306 SRTPProtectionProfile SRTP_AES128_CM_SHA1_32 = {0x00, 0x02}; 307 SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03}; 308 SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04}; 309 SRTPProtectionProfile SRTP_NULL_SHA1_80 = {0x00, 0x05}; 310 SRTPProtectionProfile SRTP_NULL_SHA1_32 = {0x00, 0x06}; 312 The following list indicates the SRTP transform parameters for each 313 protection profile. The parameters cipher_key_length, 314 cipher_salt_length, auth_key_length, and auth_tag_length express the 315 number of bits in the values to which they refer. The 316 maximum_lifetime parameter indicates the maximum number of packets 317 that can be protected with each single set of keys when the parameter 318 profile is in use. All of these parameters apply to both RTP and 319 RTCP, unless the RTCP parameters are separately specified. 321 All of the crypto algorithms in these profiles are from [13], except 322 for the AES256_CM cipher, which is specified in [10]. 324 SRTP_AES128_CM_HMAC_SHA1_80 325 cipher: AES_128_CM 326 cipher_key_length: 128 327 cipher_salt_length: 112 328 maximum_lifetime: 2^31 329 auth_function: HMAC-SHA1 330 auth_key_length: 160 331 auth_tag_length: 80 332 SRTP_AES128_CM_HMAC_SHA1_32 333 cipher: AES_128_CM 334 cipher_key_length: 128 335 cipher_salt_length: 112 336 maximum_lifetime: 2^31 337 auth_function: HMAC-SHA1 338 auth_key_length: 160 339 auth_tag_length: 32 340 RTCP auth_tag_length: 80 341 SRTP_AES256_CM_HMAC_SHA1_80 342 cipher: AES_256_CM 343 cipher_key_length: 256 344 cipher_salt_length: 112 345 maximum_lifetime: 2^31 346 auth_function: HMAC-SHA1 347 auth_key_length: 160 348 auth_tag_length: 80 349 SRTP_AES256_CM_HMAC_SHA1_32 350 cipher: AES_256_CM 351 cipher_key_length: 256 352 cipher_salt_length: 112 353 maximum_lifetime: 2^31 354 auth_function: HMAC-SHA1 355 auth_key_length: 160 356 auth_tag_length: 32 357 RTCP auth_tag_length: 80 358 SRTP_NULL_HMAC_SHA1_80 359 cipher: NULL 360 cipher_key_length: 0 361 cipher_salt_length: 0 362 maximum_lifetime: 2^31 363 auth_function: HMAC-SHA1 364 auth_key_length: 160 365 auth_tag_length: 80 366 SRTP_NULL_HMAC_SHA1_32 367 cipher: NULL 368 cipher_key_length: 0 369 cipher_salt_length: 0 370 maximum_lifetime: 2^31 371 auth_function: HMAC-SHA1 372 auth_key_length: 160 373 auth_tag_length: 32 374 RTCP auth_tag_length: 80 376 With all of these SRTP Parameter profiles, the following SRTP options 377 are in effect: 379 o The TLS Key Derivation Function (KDF) is used to generate keys to 380 feed into the SRTP KDF. 381 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 382 not re-derived based on the SRTP sequence number. 383 o For all other parameters, (in particular, SRTP replay window size 384 and FEC order) the default values are used. 386 If values other than the defaults for these parameters are required, 387 they can be enabled by writing a separate specification specifying 388 SDP syntax to signal them. 390 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection 391 Profiles between the DTLS-SRTP session that protects an RTP flow and 392 the DTLS-SRTP session that protects the associated RTCP flow (in 393 those case in which the RTP and RTCP are not multiplexed over a 394 common port). In particular, identical ciphers SHOULD be used. 396 New SRTPProtectionProfile values must be defined by RFC 2434 397 Standards Action. See Section 9 for IANA Considerations. 399 4.1.3. srtp_mki value 401 The srtp_mki value MAY be used to indicate the capability and desire 402 to use the SRTP Master Key Indicator (MKI) field in the SRTP and 403 SRTCP packets. The MKI field indicates to an SRTP receiver which key 404 was used to protect the packet that contains that field. The 405 srtp_mki field contains the value of the SRTP MKI which is associated 406 with the SRTP master keys derived from this handshake. Each SRTP 407 session MUST have exactly one master key that is used to protect 408 packets at any given time. The client MUST choose the MKI value so 409 that it is distinct from the last MKI value that was used, and it 410 SHOULD make these values unique for the duration of the TLS session. 412 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, 413 the server MUST either (assuming it accepts the extension at all): 415 1. include a matching "srtp_mki" value in its "use_srtp" extension 416 to indicate that it will make use of the MKI, or 417 2. return an empty "srtp_mki" value to indicate that it cannot make 418 use of the MKI. 420 If the client detects a nonzero-length MKI in the server's response 421 that is different than the one the client offered MUST abort the 422 handshake and SHOULD send an invalid_parameter alert. If the client 423 and server agree on an MKI, all SRTP packets protected under the new 424 security parameters MUST contain that MKI. 426 4.2. Key Derivation 428 When SRTP mode is in effect, different keys are used for ordinary 429 DTLS record protection and SRTP packet protection. These keys are 430 generated using a TLS extractor [2] to generate 2 * 431 (SRTPSecurityParams.master_key_len + 432 SRTPSecurityParams.master_salt_len) bytes of data, which are assigned 433 as shown below. 435 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 436 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 437 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 438 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 440 The extractor label for this usage is "EXTRACTOR-dtls_srtp". 442 The four keying material values are provided as inputs to the SRTP 443 key derivation mechanism, as shown in Figure 5 and detailed below. 444 By default, the mechanism defined in Section 4.3 of [13] is used, 445 unless another key derivation mechanism is specified as part of an 446 SRTP Protection Profile. 448 The client_write_SRTP_master_key and client_write_SRTP_master_salt 449 are provided to one invocation of the SRTP key derivation function, 450 to generate the SRTP keys used to encrypt and authenticate packets 451 sent by the client. The server MUST only use these keys to decrypt 452 and to check the authenticity of inbound packets. 454 The server_write_SRTP_master_key and server_write_SRTP_master_salt 455 are provided to one invocation of the SRTP key derivation function, 456 to generate the SRTP keys used to encrypt and authenticate packets 457 sent by the server. The client MUST only use these keys to decrypt 458 and to check the authenticity of inbound packets. 460 +------- TLS master secret 461 | 462 v +-> client_write_MAC_secret 463 +-----+ | 464 | TLS |--+-> server_write_MAC_secret 465 | KDF | | 466 +-----+ +-> client_write_key 467 | 468 +-> server_write_key 469 | +------+ SRTP 470 +-> client_write_SRTP_master_key ----->| SRTP |-> client 471 | +--->| KDF | write 472 +-> server_write_SRTP_master_key --|-+ +------+ keys 473 | | | 474 +-> client_write_SRTP_master_salt -+ | +------+ SRTP 475 | +->| SRTP |-> server 476 +-> server_write_SRTP_master_salt ----->| KDF | write 477 +------+ keys 479 Figure 5: The derivation of the SRTP keys. 481 When both RTCP and RTP use the same source and destination ports, 482 then both the SRTP and SRTCP keys are need. Otherwise, there are two 483 DTLS-SRTP sessions, one of which protects the RTP packets and one of 484 which protects the RTCP packets; each DTLS-SRTP session protects the 485 part of an SRTP session that passes over a single source/destination 486 transport address pair, as shown in Figure 6. When a DTLS-SRTP 487 session is protecting RTP, the SRTCP keys derived from the DTLS 488 handshake are not needed and are discarded. When a DTLS-SRTP session 489 is protecting RTCP, the SRTP keys derived from the DTLS handshake are 490 not needed and are discarded. 492 Client Server 493 (Sender) (Receiver) 494 (1) <----- DTLS ------> src/dst = a/b and b/a 495 ------ SRTP ------> src/dst = a/b, uses client write keys 497 (2) <----- DTLS ------> src/dst = c/d and d/c 498 ------ SRTCP -----> src/dst = c/d, uses client write keys 499 <----- SRTCP ------ src/dst = d/c, uses server write keys 501 Figure 6: A DTLS-SRTP session protecting RTP (1) and another one 502 protecting RTCP (2), showing the transport addresses and keys used. 504 4.3. Key Scope 506 Because of the possibility of packet reordering, DTLS-SRTP 507 implementations SHOULD store multiple SRTP keys sets during a re-key 508 in order to avoid the need for receivers to drop packets for which 509 they lack a key. 511 4.4. Key Usage Limitations 513 The maximum_lifetime parameter in the SRTP protection profile 514 indicates the maximum number of packets that can be protected with 515 each single encryption and authentication key. (Note that, since RTP 516 and RTCP are protected with independent keys, those protocols are 517 counted separately for the purposes of determining when a key has 518 reached the end of its lifetime.) Each profile defines its own 519 limit. When this limit is reached, a new DTLS session SHOULD be used 520 to establish replacement keys, and SRTP implementations MUST NOT use 521 the existing keys for the processing of either outbound or inbound 522 traffic. 524 5. Use of RTP and RTCP over a DTLS-SRTP Channel 526 5.1. Data Protection 528 Once the DTLS handshake has completed the peers can send RTP or RTCP 529 over the newly created channel. We describe the transmission process 530 first followed by the reception process. 532 Within each RTP session, SRTP processing MUST NOT take place before 533 the DTLS handshake completes. 535 5.1.1. Transmission 537 DTLS and TLS define a number of record content types. In ordinary 538 TLS/DTLS, all data is protected using the same record encoding and 539 mechanisms. When the mechanism described in this document is in 540 effect, this is modified so that data of type "application_data" 541 (used to transport data traffic) is encrypted using SRTP rather than 542 the standard TLS record encoding. 544 When a user of DTLS wishes to send an RTP packet in SRTP mode it 545 delivers it to the DTLS implementation as a single write of type 546 "application_data". The DTLS implementation then invokes the 547 processing described in RFC 3711 Sections 3 and 4. The resulting 548 SRTP packet is then sent directly on the wire as a single datagram 549 with no DTLS framing. This provides an encapsulation of the data 550 that conforms to and interoperates with SRTP. Note that the RTP 551 sequence number rather than the DTLS sequence number is used for 552 these packets. 554 5.1.2. Reception 556 When DTLS-SRTP is used to protect an RTP session, the RTP receiver 557 needs to demultiplex packets that are arriving on the RTP port. 558 Arriving packets may be of types RTP, DTLS, or STUN[8]. If these are 559 the only types of packets present, the type of a packet can be 560 determined by looking at its first byte. 562 The process for demultiplexing a packet is as follows. The receiver 563 looks at the first byte of the packet. If the value of this byte is 564 0 or 1, then the packet is STUN. If the value is in between 128 and 565 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 566 RTP are being multiplexed over the same destination port). If the 567 value is between 20 and 63 (inclusive), the packet is DTLS. This 568 processes is summarized in Figure 7. 570 +----------------+ 571 | 127 < B < 192 -+--> forward to RTP 572 | | 573 packet --> | 19 < B < 64 -+--> forward to DTLS 574 | | 575 | B < 2 -+--> forward to STUN 576 +----------------+ 578 Figure 7: The DTLS-SRTP receiver's packet demultiplexing 579 algorithm. Here the field B denotes the leading byte of the packet. 581 If other packet types are to be multiplexed as well, implementors 582 and/or designers SHOULD ensure that they can be demultiplexed from 583 these three packet types. 585 In some cases there will be multiple DTLS-SRTP associations for a 586 given SRTP endpoint. For instance, if Alice makes a call which is 587 SIP forked to both Bob and Charlie, she will use the same local host/ 588 port pair for both of them, as shown in Figure 8. (The SSRCs shown 589 are the ones for data flowing to Alice). 591 Bob (192.0.2.1:6666) 592 / 593 / 594 / SSRC=1 595 / DTLS-SRTP=XXX 596 / 597 v 598 Alice (192.0.2.0:5555) 599 ^ 600 \ 601 \ SSRC=2 602 \ DTLS-SRTP=YYY 603 \ 604 \ 605 Charlie (192.0.2.1:6666) 607 Figure 8: RTP sessions with SIP forking 609 Because DTLS operates on the host/port quartet, the DTLS association 610 will still complete correctly, with the foreign host/port pair being 611 used to distinguish the associations. However, in RTP the source 612 host/port is not used and sessions are identified by the destination 613 host/port and the SSRC. Thus, some mechanism is needed to determine 614 which SSRCs correspond to which DTLS associations. The following 615 method SHOULD be used. 617 For each local host/port pair, the DTLS-SRTP implementation maintains 618 a table listing all the SSRCs it knows about and the DTLS-SRTP 619 associations they correspond to. Initially, this table is empty. 620 When an SRTP packet is received for a given RTP endpoint (destination 621 IP/port pair), the following procedure is used: 623 1. If the SSRC is already known for that endpoint, then the 624 corresponding DTLS-SRTP association and its keying material is 625 used to decrypt and verify the packet. 626 2. If the SSRC is not known, then the receiver tries to decrypt it 627 with the keying material corresponding to each DTLS-SRTP 628 association for that endpoint. 629 3. If the decryption and verification succeeds (the authentication 630 tag verifies) then an entry is placed in the table mapping the 631 SSRC to that association. 632 4. If the decryption and verification fails, then the packet is 633 silently discarded. 634 5. When a DTLS-SRTP association is closed (for instance because the 635 fork is abandoned) its entries MUST be removed from the mapping 636 table. 638 The average cost of this algorithm for a single SSRC is the 639 decryption and verification time of a single packet times the number 640 valid DTLS-SRTP associations corresponding to a single receiving port 641 on the host. In practice, this means the number of forks, so in the 642 case shown in Figure 8, that would be two. This cost is only 643 incurred once for any given SSRC, since afterwards that SSRC is 644 placed in the map table and looked up immediately. As with normal 645 RTP, this algorithm allows new SSRCs to be introduced by the source 646 at any time. They will automatically be mapped to the correct DTLS 647 association. 649 Note that this algorithm explicitly allows multiple SSRCs to be sent 650 from the same address/port pair. One way in which this can happen is 651 an RTP translator. This algorithm will automatically assign the 652 SSRCs to the correct associations. Note that because the SRTP 653 packets are cryptographically protected, such a translator must 654 either share keying material with one endpoint in or refrain from 655 modifying the packets in a way which would cause the integrity check 656 to fail. This is a general property of SRTP and is not specific to 657 DTLS-SRTP. 659 There are two error cases that should be considered. First, if an 660 SSRC collision occurs, then only the packets from the first source 661 will be processed. When the packets from the second source arrive, 662 the DTLS association with the first source will be used for 663 decryption and verification, which will fail, and the packet will be 664 discarded. This is consistent with [12], which permits the receiver 665 to keep the packets from one source and discard those from the other. 666 Of course the RFC 3550 SSRC collision detection and handling 667 procedures MUST also be followed. 669 Second, there may be cases where a malfunctioning source is sending 670 corrupt packets which cannot be decrypted and verified. In this 671 case, the SSRC will never be entered into the mapping table, because 672 the decryption and verification always fails. Receivers MAY keep 673 records of unmapped SSRCs which consistently fail decryption and 674 verification and abandon attempts to process them once they reach 675 some limit. That limit MUST be large enough to account for the 676 effects of transmission errors. Entries MUST be pruned from this 677 table when the relevant SRTP endpoint is deleted (e.g., the call 678 ends) and SHOULD time out faster than that (we do not offer a hard 679 recommendation but 10 to 30 seconds seems appropriate) to allow in 680 order to allow for the possibility that the peer implementation has 681 been corrected. 683 5.2. Rehandshake and Re-key 685 Rekeying in DTLS is accomplished by performing a new handshake over 686 the existing DTLS channel. This handshake can be performed in 687 parallel with data transport, so no interruption of the data flow is 688 required. Once the handshake is finished, the newly derived set of 689 keys is used to protect all outbound packets, both DTLS and SRTP. 691 Because of packet reordering, packets protected by the previous set 692 of keys can appear on the wire after the handshake has completed. To 693 compensate for this fact, receivers SHOULD maintain both sets of keys 694 for some time in order to be able to decrypt and verify older 695 packets. The keys should be maintained for the duration of the 696 maximum segment lifetime (MSL). 698 If an MKI is used, then the receiver should use the corresponding set 699 of keys to process an incoming packet. Otherwise, when a packet 700 arrives after the handshake completed, a receiver SHOULD use the 701 newly derived set of keys to process that packet unless there is an 702 MKI (If the packet was protected with the older set of keys, this 703 fact will become apparent to the receiver as an authentication 704 failure will occur.) If the authentication check on the packet fails 705 and no MKI is being used, then the receiver MAY process the packet 706 with the older set of keys. If that authentication check indicates 707 that the packet is valid, the packet should be accepted; otherwise, 708 the packet MUST be discarded and rejected. 710 Receivers MAY use the SRTP packet sequence number to aid in the 711 selection of keys. After a packet has been received and 712 authenticated with the new key set, any packets with sequence numbers 713 that are greater will also have been protected with the new key set. 715 6. Multi-party RTP Sessions 717 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only 718 to protect unicast RTP sessions. This does not preclude its use with 719 RTP mixers. For example, a conference bridge may use DTLS-SRTP to 720 secure the communication to and from each of the participants in a 721 conference. However, because each flow between an endpoint and a 722 mixer has its own key, the mixer has to decrypt and then reencrypt 723 the traffic for each recipient. 725 A future specification may describe methods for sharing a single key 726 between multiple DTLS-SRTP associations which would allow 727 conferencing systems to avoid the decrypt/reencrypt stage. However, 728 any system in which the media is modified (e.g., for level balancing 729 or transcoding) will generally need to be performed on the plaintext 730 and will certainly break the authentication tag and therefore will 731 require a decrypt/reencrypt stage. 733 7. Security Considerations 735 The use of multiple data protection framings negotiated in the same 736 handshake creates some complexities, which are discussed here. 738 7.1. Security of Negotiation 740 One concern here is that attackers might be able to implement a bid- 741 down attack forcing the peers to use ordinary DTLS rather than SRTP. 742 However, because the negotiation of this extension is performed in 743 the DTLS handshake, it is protected by the Finished messages. 744 Therefore, any bid-down attack is automatically detected, which 745 reduces this to a denial of service attack - which any attacker who 746 can control the channel can always mount. 748 7.2. Framing Confusion 750 Because two different framing formats are used, there is concern that 751 an attacker could convince the receiver to treat an SRTP-framed RTP 752 packet as a DTLS record (e.g., a handshake message) or vice versa. 753 This attack is prevented by using different keys for MAC verification 754 for each type of data. Therefore, this type of attack reduces to 755 being able to forge a packet with a valid MAC, which violates a basic 756 security invariant of both DTLS and SRTP. 758 As an additional defense against injection into the DTLS handshake 759 channel, the DTLS record type is included in the MAC. Therefore, an 760 SRTP record would be treated as an unknown type and ignored. (See 761 Section 6 of [4]). 763 7.3. Sequence Number Interactions 765 As described in Section 5.1.1, the SRTP and DTLS sequence number 766 spaces are distinct. This means that it is not possible to 767 unambiguously order a given DTLS control record with respect to an 768 SRTP packet. In general, this is relevant in two situations: alerts 769 and rehandshake. 771 7.3.1. Alerts 773 Because DTLS handshake and change_cipher_spec messages share the same 774 sequence number space as alerts, they can be ordered correctly. 775 Because DTLS alerts are inherently unreliable and SHOULD NOT be 776 generated as a response to data packets, reliable sequencing between 777 SRTP packets and DTLS alerts is not an important feature. However, 778 implementations which wish to use DTLS alerts to signal problems with 779 the SRTP encoding SHOULD simply act on alerts as soon as they are 780 received and assume that they refer to the temporally contiguous 781 stream. Such implementations MUST check for alert retransmission and 782 discard retransmitted alerts to avoid overreacting to replay attacks. 784 7.3.2. Renegotiation 786 Because the rehandshake transition algorithm specified in Section 787 Section 5.2 requires trying multiple sets of keys if no MKI is used, 788 it slightly weakens the authentication. For instance, if an n-bit 789 MAC is used and k different sets of keys are present, then the MAC is 790 weakened by log_2(k) bits to n - log_2(k). In practice, since the 791 number of keys used will be very small and the MACs in use are 792 typically strong (the default for SRTP is 80 bits) the decrease in 793 security involved here is minimal. 795 Another concern here is that this algorithm slightly increases the 796 work factor on the receiver because it needs to attempt multiple 797 validations. However, again, the number of potential keys will be 798 very small (and the attacker cannot force it to be larger) and this 799 technique is already used for rollover counter management, so the 800 authors do not consider this to be a serious flaw. 802 7.4. Decryption Cost 804 An attacker can impose computational costs on the receiver by sending 805 superficially valid SRTP packets which do not decrypt correctly. In 806 general, encryption algorithms are so fast that this cost is 807 extremely small compared to the bandwidth consumed. The SSRC-DTLS 808 mapping algorithm described in Section 5.1.2 gives the attacker a 809 slight advantage here because he can force the receiver to do more 810 then one decryption per packet. However, this advantage is modest 811 because the number of decryptions that the receiver does is limited 812 by the number of associations he has corresponding to a given 813 destination host/port, which is typically quite small. For 814 comparison, a single 1024-bit RSA private key operation (the typical 815 minimum cost to establish a DTLS-SRTP association) is hundreds of 816 times as expensive as decrypting an SRTP packet. 818 Implementations can detect this form of attack by keeping track of 819 the number of SRTP packets observed with unknown SSRCs which fail the 820 authentication tag check. If under such attack, implementations 821 SHOULD prioritize decryption and verification of packets which either 822 have known SSRCs or come from source addresses which match those of 823 peers with which it has DTLS-SRTP associations. 825 8. Session Description for RTP/SAVP over DTLS 827 This specification defines new tokens to describe the protocol used 828 in SDP media descriptions ('m' lines and their associated 829 parameters). The new values defined for the proto field are: 830 o When a RTP/SAVP or RTP/SAVPF [16] stream is transported over DTLS 831 with DCCP, then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/ 832 RTP/SAVPF respectively. 833 o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with 834 UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF 835 respectively. 836 o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with 837 TCP, the token SHALL be TCP/TLS/RTP/SAVP or TCP/TLS/RTP/SAVPF 838 respectively. Note that even though TCP is being used, the PDUs 839 carried over the TCP connection are the same as would be carried 840 over DCCP or UDP. 842 The "fmt" parameter SHALL be as defined for RTP/SAVP. 844 See [9] for how to use offer/answer with DTLS-SRTP. 846 9. IANA Considerations 848 This document a new extension for DTLS, in accordance with [6]: 849 enum { use_srtp (??) } ExtensionType; 851 [[ NOTE: This value needs to be assigned by IANA ]] 853 This extension MUST only be used with DTLS, and not with TLS [15] 854 specifies that TLS can be used over TCP but does not address TCP for 855 RTP/SAVP. 857 Section 4.1.2 requires that all SRTPProtectionProfile values be 858 defined by RFC 2434 Standards Action. IANA SHOULD create a DTLS 859 SRTPProtectionProfile registry initially populated with values from 860 Section 4.1.2 of this document. Future values MUST be allocated via 861 Standards Action as described in [11] 863 This specification updates the "Session Description Protocol (SDP) 864 Parameters" registry as defined in Appendix B of RFC 4566 [14]. 865 Specifically it adds the following values to the table for the 866 "proto" field. 868 Type SDP Name Reference 869 ---- ------------------ --------- 870 proto TCP/TLS/RTP/SAVP [RFC-XXXX] 871 proto UDP/TLS/RTP/SAVP [RFC-XXXX] 872 proto DCCP/TLS/RTP/SAVP [RFC-XXXX] 874 proto TCP/TLS/RTP/SAVPF [RFC-XXXX] 875 proto UDP/TLS/RTP/SAVPF [RFC-XXXX] 876 proto DCCP/TLS/RTP/SAVPF [RFC-XXXX] 878 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 879 this specification. 881 10. Acknowledgments 883 Special thanks to Flemming Andreasen, Francois Audet, Jason Fischl, 884 Cullen Jennings, Colin Perkins, and Dan Wing, for input, discussions, 885 and guidance. 887 11. References 889 11.1. Normative References 891 [1] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 892 Control Packets on a Single Port", 893 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 894 August 2007. 896 [2] Rescorla, E., "Keying Material Extractors for Transport Layer 897 Security (TLS)", draft-ietf-tls-extractor-01 (work in 898 progress), February 2008. 900 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 901 Levels", BCP 14, RFC 2119, March 1997. 903 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 904 Protocol Version 1.1", RFC 4346, April 2006. 906 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 907 Security", RFC 4347, April 2006. 909 [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 910 T. Wright, "Transport Layer Security (TLS) Extensions", 911 RFC 4366, April 2006. 913 [7] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 914 BCP 131, RFC 4961, July 2007. 916 11.2. Informational References 918 [8] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 919 Traversal Utilities for (NAT) (STUN)", 920 draft-ietf-behave-rfc3489bis-15 (work in progress), 921 February 2008. 923 [9] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 924 Establishing an SRTP Security Context using DTLS", 925 draft-ietf-sip-dtls-srtp-framework-01 (work in progress), 926 February 2008. 928 [10] McGrew, D., "The use of AES-192 and AES-256 in Secure RTP", 929 draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006. 931 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 932 Considerations Section in RFCs", BCP 26, RFC 2434, 933 October 1998. 935 [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 936 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 937 RFC 3550, July 2003. 939 [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 940 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 941 RFC 3711, March 2004. 943 [14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 944 Description Protocol", RFC 4566, July 2006. 946 [15] Lennox, J., "Connection-Oriented Media Transport over the 947 Transport Layer Security (TLS) Protocol in the Session 948 Description Protocol (SDP)", RFC 4572, July 2006. 950 [16] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real- 951 time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 952 SAVPF)", RFC 5124, February 2008. 954 Appendix A. Overview of DTLS 956 This section provides a brief overview of Datagram TLS (DTLS) for 957 those who are not familiar with it. DTLS is a channel security 958 protocol based on the well-known Transport Layer Security (TLS) [4] 959 protocol. Where TLS depends on a reliable transport channel 960 (typically TCP), DTLS has been adapted to support unreliable 961 transports such as UDP. Otherwise, DTLS is nearly identical to TLS 962 and generally supports the same cryptographic mechanisms. 964 Each DTLS association begins with a handshake exchange (shown below) 965 during which the peers authenticated each other and negotiate 966 algorithms, modes, and other parameters and establish shared keying 967 material, as shown below. In order to support unreliable transport, 968 each side maintains retransmission timers to provide reliable 969 delivery of these messages. Once the handshake is completed, 970 encrypted data may be sent. 972 Client Server 974 ClientHello --------> 975 ServerHello 976 Certificate* 977 ServerKeyExchange* 978 CertificateRequest* 979 <-------- ServerHelloDone 980 Certificate* 981 ClientKeyExchange 982 CertificateVerify* 983 [ChangeCipherSpec] 984 Finished --------> 985 [ChangeCipherSpec] 986 <-------- Finished 987 Application Data <-------> Application Data 989 '*' indicates messages which are not always sent. 991 Application data is protected by being sent as a series of DTLS 992 "records". These records are independent and which can be processed 993 correctly even in the face of loss or reordering. In DTLS-SRTP, this 994 record protocol is replaced with SRTP [13] 996 Appendix B. Performance of Multiple DTLS Handshakes 998 Standard practice for security protocols such as TLS, DTLS, and SSH 999 which do inline key management is to create a separate security 1000 association for each underlying network channel (TCP connection, UDP 1001 host/port quartet, etc.). This has dual advantages of simplicity and 1002 independence of the security contexts for each channel. 1004 Three concerns have been raised about the overhead of this strategy 1005 in the context of RTP security. The first concern is the additional 1006 performance overhead of doing a separate public key operation for 1007 each channel. The conventional procedure here (used in TLS and DTLS) 1008 is to establish a master context which can then be used to derive 1009 fresh traffic keys for new associations. In TLS/DTLS this is called 1010 "session resumption" and can be transparently negotiated between the 1011 peers. 1013 The second concern is network bandwidth overhead for the 1014 establishment of subsequent connections and for rehandshake (for 1015 rekeying) for existing connections. In particular, there is a 1016 concern that the channels will have very narrow capacity requirements 1017 allocated entirely to media which will be overflowed by the 1018 rehandshake. Measurements of the size of the rehandshake (with 1019 resumption) in TLS indicate that it is about 300-400 bytes if a full 1020 selection of cipher suites is offered. (the size of a full handshake 1021 is approximately 1-2k larger because of the certificate and keying 1022 material exchange). 1024 The third concern is the additional round-trips associated with 1025 establishing the 2nd, 3rd, ... channels. In TLS/DTLS these can all 1026 be done in parallel but in order to take advantage of session 1027 resumption they should be done after the first channel is 1028 established. For two channels this provides a ladder diagram 1029 something like this (parenthetical #s are media channel #s) 1031 Alice Bob 1032 ------------------------------------------- 1033 <- ClientHello (1) 1034 ServerHello (1) -> 1035 Certificate (1) 1036 ServerHelloDone (1) 1037 <- ClientKeyExchange (1) 1038 ChangeCipherSpec (1) 1039 Finished (1) 1040 ChangeCipherSpec (1)-> 1041 Finished (1)-> 1042 <--- Channel 1 ready 1044 <- ClientHello (2) 1045 ServerHello (2) -> 1046 ChangeCipherSpec(2)-> 1047 Finished(2) -> 1048 <- ChangeCipherSpec (2) 1049 Finished (2) 1050 <--- Channel 2 ready 1052 So, there is an additional 1 RTT after Channel 1 is ready before 1053 Channel 2 is ready. If the peers are potentially willing to forego 1054 resumption they can interlace the handshakes, like so: 1056 Alice Bob 1057 ------------------------------------------- 1058 <- ClientHello (1) 1059 ServerHello (1) -> 1060 Certificate (1) 1061 ServerHelloDone (1) 1062 <- ClientKeyExchange (1) 1063 ChangeCipherSpec (1) 1064 Finished (1) 1065 <- ClientHello (2) 1066 ChangeCipherSpec (1)-> 1067 Finished (1)-> 1068 <--- Channel 1 ready 1069 ServerHello (2) -> 1070 ChangeCipherSpec(2)-> 1071 Finished(2) -> 1072 <- ChangeCipherSpec (2) 1073 Finished (2) 1074 <--- Channel 2 ready 1076 In this case the channels are ready contemporaneously, but if a 1077 message in handshake (1) is lost then handshake (2) requires either a 1078 full rehandshake or that Alice be clever and queue the resumption 1079 attempt until the first handshake completes. Note that just dropping 1080 the packet works as well since Bob will retransmit. 1082 Authors' Addresses 1084 David McGrew 1085 Cisco Systems 1086 510 McCarthy Blvd. 1087 Milpitas, CA 95305 1088 USA 1090 Email: mcgrew@cisco.com 1092 Eric Rescorla 1093 Network Resonance 1094 2064 Edgewood Drive 1095 Palo Alto, CA 94303 1096 USA 1098 Email: ekr@networkresonance.com 1100 Full Copyright Statement 1102 Copyright (C) The IETF Trust (2008). 1104 This document is subject to the rights, licenses and restrictions 1105 contained in BCP 78, and except as set forth therein, the authors 1106 retain all their rights. 1108 This document and the information contained herein are provided on an 1109 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1110 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1111 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1112 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1113 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1114 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1116 Intellectual Property 1118 The IETF takes no position regarding the validity or scope of any 1119 Intellectual Property Rights or other rights that might be claimed to 1120 pertain to the implementation or use of the technology described in 1121 this document or the extent to which any license under such rights 1122 might or might not be available; nor does it represent that it has 1123 made any independent effort to identify any such rights. Information 1124 on the procedures with respect to rights in RFC documents can be 1125 found in BCP 78 and BCP 79. 1127 Copies of IPR disclosures made to the IETF Secretariat and any 1128 assurances of licenses to be made available, or the result of an 1129 attempt made to obtain a general license or permission for the use of 1130 such proprietary rights by implementers or users of this 1131 specification can be obtained from the IETF on-line IPR repository at 1132 http://www.ietf.org/ipr. 1134 The IETF invites any interested party to bring to its attention any 1135 copyrights, patents or patent applications, or other proprietary 1136 rights that may cover technology that may be required to implement 1137 this standard. Please address the information to the IETF at 1138 ietf-ipr@ietf.org. 1140 Acknowledgment 1142 Funding for the RFC Editor function is provided by the IETF 1143 Administrative Support Activity (IASA).