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