idnits 2.17.1 draft-ietf-avt-dtls-srtp-06.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 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1157. 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 452 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 (October 29, 2008) is 5658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1006, but not defined -- Looks like a reference, but probably isn't: '2' on line 274 == Missing Reference: 'RFC-XXXX' is mentioned on line 884, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-tls-extractor-02 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-00 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 11 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: May 2, 2009 RTFM, Inc. 6 October 29, 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-06.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 May 2, 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) [RFC3711] 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 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 combines the performance and encryption flexibility benefits of SRTP 98 with the flexibility and convenience of DTLS 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 is 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. This strategy allows the later sessions to use DTLS 193 session resumption, which allows the amortization of the expensive 194 public key cryptography operations over multiple DTLS handshakes. 196 The SRTP keys used to protect packets originated by the client are 197 distinct from the SRTP keys used to protect packets originated by the 198 server. All of the RTP sources originating on the client for the 199 same channel use the same SRTP keys, and similarly, all of the RTP 200 sources originating on the server for the same channel use the same 201 SRTP keys. The SRTP implementation MUST ensure that all of the SSRC 202 values for all of the RTP sources originating from the same device 203 over the same channel are distinct, in order to avoid the "two-time 204 pad" problem (as described in Section 9.1 of RFC 3711). Note that 205 this is not an issue for separate media streams (on different host/ 206 port quartets) which use independent keying material even if an SSRC 207 collision occurs. 209 4. DTLS Extensions for SRTP Key Establishment 211 4.1. The use_srtp Extension 213 In order to negotiate the use of SRTP data protection, clients 214 include an extension of type "use_srtp" in the DTLS extended client 215 hello. This extension MUST only be used when the data being 216 transported is RTP or RTCP [RFC3550]. The "extension_data" field of 217 this extension contains the list of acceptable SRTP protection 218 profiles, as indicated below. 220 Servers that receive an extended hello containing a "use_srtp" 221 extension can agree to use SRTP by including an extension of type 222 "use_srtp", with the chosen protection profile in the extended server 223 hello. This process is shown below. 225 Client Server 227 ClientHello + use_srtp --------> 228 ServerHello + use_srtp 229 Certificate* 230 ServerKeyExchange* 231 CertificateRequest* 232 <-------- ServerHelloDone 233 Certificate* 234 ClientKeyExchange 235 CertificateVerify* 236 [ChangeCipherSpec] 237 Finished --------> 238 [ChangeCipherSpec] 239 <-------- Finished 240 SRTP packets <-------> SRTP packets 242 Note that '*' indicates messages which are not always sent in DTLS. 243 The CertificateRequest, client and server Certificates, and 244 CertificateVerify will be sent in DTLS-SRTP. 246 Once the "use_srtp" extension is negotiated, the RTP or RTCP 247 application data is protected solely using SRTP. Application data is 248 never sent in DTLS record-layer "application_data" packets. Rather, 249 complete RTP or RTCP packets are passed to the DTLS stack which 250 passes them to the SRTP stack which protects them appropriately. 251 Note that if RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is 252 in use, this means that RTP and RTCP packets may both be passed to 253 the DTLS stack. Because the DTLS layer does not process the packets, 254 it does not need to distinguish them. The SRTP stack can use the 255 procedures of [I-D.ietf-avt-rtp-and-rtcp-mux] to distinguish RTP from 256 RTCP. 258 When the "use_srtp" extension is in effect, implementations must not 259 place more than one application data "record" per datagram. (This is 260 only meaningful from the perspective of DTLS because SRTP is 261 inherently oriented towards one payload per packet, but is stated 262 purely for clarification.) 264 Data other than RTP/RTCP (i.e., TLS control messages) MUST use 265 ordinary DTLS framing and MUST be placed in separate datagrams from 266 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 [I-D.ietf-tls-rfc4347-bis] 366 is in use, the PRF is the one associated with the cipher suite. 367 Note that this specification is compatible with DTLS 1.0 or DTLS 368 1.2 369 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 370 not re-derived based on the SRTP sequence number. 371 o The key derivation procedures from Section 4.3 with the AES-CM PRF 372 from RFC 3711 is used. 373 o For all other parameters, (in particular, SRTP replay window size 374 and FEC order) the default values are used. 376 If values other than the defaults for these parameters are required, 377 they can be enabled by writing a separate specification specifying 378 SDP syntax to signal them. 380 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection 381 Profiles between the DTLS-SRTP session that protects an RTP flow and 382 the DTLS-SRTP session that protects the associated RTCP flow (in 383 those case in which the RTP and RTCP are not multiplexed over a 384 common port). In particular, identical ciphers SHOULD be used. 386 New SRTPProtectionProfile values must be defined according to the 387 "Specification Required" policy as defined by RFC 5226 [RFC5226]. 388 See Section 9 for IANA Considerations. 390 4.1.3. srtp_mki value 392 The srtp_mki value MAY be used to indicate the capability and desire 393 to use the SRTP Master Key Indicator (MKI) field in the SRTP and 394 SRTCP packets. The MKI field indicates to an SRTP receiver which key 395 was used to protect the packet that contains that field. The 396 srtp_mki field contains the value of the SRTP MKI which is associated 397 with the SRTP master keys derived from this handshake. Each SRTP 398 session MUST have exactly one master key that is used to protect 399 packets at any given time. The client MUST choose the MKI value so 400 that it is distinct from the last MKI value that was used, and it 401 SHOULD make these values unique for the duration of the TLS session. 403 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, 404 the server MUST either (assuming it accepts the extension at all): 406 1. include a matching "srtp_mki" value in its "use_srtp" extension 407 to indicate that it will make use of the MKI, or 408 2. return an empty "srtp_mki" value to indicate that it cannot make 409 use of the MKI. 411 If the client detects a nonzero-length MKI in the server's response 412 that is different than the one the client offered then the client 413 MUST abort the handshake and SHOULD send an invalid_parameter alert. 414 If the client and server agree on an MKI, all SRTP packets protected 415 under the new security parameters MUST contain that MKI. 417 4.2. Key Derivation 419 When SRTP mode is in effect, different keys are used for ordinary 420 DTLS record protection and SRTP packet protection. These keys are 421 generated using a TLS extractor [I-D.ietf-tls-extractor] to generate 422 2 * (SRTPSecurityParams.master_key_len + 423 SRTPSecurityParams.master_salt_len) bytes of data, which are assigned 424 as shown below. The per-association context value is empty. 426 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 427 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 428 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 429 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 431 The extractor label for this usage is "EXTRACTOR-dtls_srtp". 433 The four keying material values are provided as inputs to the SRTP 434 key derivation mechanism, as shown in Figure 1 and detailed below. 435 By default, the mechanism defined in Section 4.3 of [RFC3711] is 436 used, unless another key derivation mechanism is specified as part of 437 an SRTP Protection Profile. 439 The client_write_SRTP_master_key and client_write_SRTP_master_salt 440 are provided to one invocation of the SRTP key derivation function, 441 to generate the SRTP keys used to encrypt and authenticate packets 442 sent by the client. The server MUST only use these keys to decrypt 443 and to check the authenticity of inbound packets. 445 The server_write_SRTP_master_key and server_write_SRTP_master_salt 446 are provided to one invocation of the SRTP key derivation function, 447 to generate the SRTP keys used to encrypt and authenticate packets 448 sent by the server. The client MUST only use these keys to decrypt 449 and to check the authenticity of inbound packets. 451 TLS master 452 secret label 453 | | 454 v v 455 +---------------+ 456 | TLS extractor | 457 +---------------+ 458 | +------+ SRTP 459 +-> client_write_SRTP_master_key ----+--->| SRTP |-> client 460 | | +->| KDF | write 461 | | | +------+ keys 462 | | | 463 +-> server_write_SRTP_master_key -- | | +------+ SRTCP 464 | \ \--->|SRTCP |-> client 465 | \ +->| KDF | write 466 | | | +------+ keys 467 +-> client_write_SRTP_master_salt ---|-+ 468 | | 469 | | +------+ SRTP 470 | +--->| SRTP |-> server 471 +-> server_write_SRTP_master_salt -+-|--->| KDF | write 472 | | +------+ keys 473 | | 474 | | +------+ SRTCP 475 | +--->|SRTCP |-> server 476 +----->| KDF | write 477 +------+ keys 479 Figure 1: 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 needed. Otherwise, there are 483 two DTLS-SRTP sessions, one of which protects the RTP packets and one 484 of which protects the RTCP packets; each DTLS-SRTP session protects 485 the part of an SRTP session that passes over a single source/ 486 destination transport address pair, as shown in Figure 2. When a 487 DTLS-SRTP session is protecting RTP, the SRTCP keys derived from the 488 DTLS handshake are not needed and are discarded. When a DTLS-SRTP 489 session is protecting RTCP, the SRTP keys derived from the DTLS 490 handshake are 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 2: 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 written by upper level protocol 541 clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP 542 rather than 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 an ordinary application 546 data write (e.g., SSL_write()). The DTLS implementation then invokes 547 the 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 559 STUN[I-D.ietf-behave-rfc3489bis]. If these are the only types of 560 packets present, the type of a packet can be determined by looking at 561 its first byte. 563 The process for demultiplexing a packet is as follows. The receiver 564 looks at the first byte of the packet. If the value of this byte is 565 0 or 1, then the packet is STUN. If the value is in between 128 and 566 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 567 RTP are being multiplexed over the same destination port). If the 568 value is between 20 and 63 (inclusive), the packet is DTLS. This 569 processes is summarized in Figure 3. 571 +----------------+ 572 | 127 < B < 192 -+--> forward to RTP 573 | | 574 packet --> | 19 < B < 64 -+--> forward to DTLS 575 | | 576 | B < 2 -+--> forward to STUN 577 +----------------+ 579 Figure 3: The DTLS-SRTP receiver's packet demultiplexing 580 algorithm. Here the field B denotes the leading byte of the packet. 582 If other packet types are to be multiplexed as well, implementors 583 and/or designers SHOULD ensure that they can be demultiplexed from 584 these three packet types. 586 In some cases there will be multiple DTLS-SRTP associations for a 587 given SRTP endpoint. For instance, if Alice makes a call which is 588 SIP forked to both Bob and Charlie, she will use the same local host/ 589 port pair for both of them, as shown in Figure 4. (The SSRCs shown 590 are the ones for data flowing to Alice). 592 Bob (192.0.2.1:6666) 593 / 594 / 595 / SSRC=1 596 / DTLS-SRTP=XXX 597 / 598 v 599 Alice (192.0.2.0:5555) 600 ^ 601 \ 602 \ SSRC=2 603 \ DTLS-SRTP=YYY 604 \ 605 \ 606 Charlie (192.0.2.2:6666) 608 Figure 4: RTP sessions with SIP forking 610 Because DTLS operates on the host/port quartet, the DTLS association 611 will still complete correctly, with the foreign host/port pair being 612 used to distinguish the associations. However, in RTP the source 613 host/port is not used and sessions are identified by the destination 614 host/port and the SSRC. Thus, some mechanism is needed to determine 615 which SSRCs correspond to which DTLS associations. The following 616 method SHOULD be used. 618 For each local host/port pair, the DTLS-SRTP implementation maintains 619 a table listing all the SSRCs it knows about and the DTLS-SRTP 620 associations they correspond to. Initially, this table is empty. 621 When an SRTP packet is received for a given RTP endpoint (destination 622 IP/port pair), the following procedure is used: 624 1. If the SSRC is already known for that endpoint, then the 625 corresponding DTLS-SRTP association and its keying material is 626 used to decrypt and verify the packet. 627 2. If the SSRC is not known, then the receiver tries to decrypt it 628 with the keying material corresponding to each DTLS-SRTP 629 association for that endpoint. 630 3. If the decryption and verification succeeds (the authentication 631 tag verifies) then an entry is placed in the table mapping the 632 SSRC to that association. 634 4. If the decryption and verification fails, then the packet is 635 silently discarded. 636 5. When a DTLS-SRTP association is closed (for instance because the 637 fork is abandoned) its entries MUST be removed from the mapping 638 table. 640 The average cost of this algorithm for a single SSRC is the 641 decryption and verification time of a single packet times the number 642 of valid DTLS-SRTP associations corresponding to a single receiving 643 port on the host. In practice, this means the number of forks, so in 644 the case shown in Figure 4, that would be two. This cost is only 645 incurred once for any given SSRC, since afterwards that SSRC is 646 placed in the map table and looked up immediately. As with normal 647 RTP, this algorithm allows new SSRCs to be introduced by the source 648 at any time. They will automatically be mapped to the correct DTLS 649 association. 651 Note that this algorithm explicitly allows multiple SSRCs to be sent 652 from the same address/port pair. One way in which this can happen is 653 an RTP translator. This algorithm will automatically assign the 654 SSRCs to the correct associations. Note that because the SRTP 655 packets are cryptographically protected, such a translator must 656 either share keying material with one endpoint or refrain from 657 modifying the packets in a way which would cause the integrity check 658 to fail. This is a general property of SRTP and is not specific to 659 DTLS-SRTP. 661 There are two error cases that should be considered. First, if an 662 SSRC collision occurs, then only the packets from the first source 663 will be processed. When the packets from the second source arrive, 664 the DTLS association with the first source will be used for 665 decryption and verification, which will fail, and the packet will be 666 discarded. This is consistent with [RFC3550], which permits the 667 receiver to keep the packets from one source and discard those from 668 the other. Of course the RFC 3550 SSRC collision detection and 669 handling procedures MUST also be followed. 671 Second, there may be cases where a malfunctioning source is sending 672 corrupt packets which cannot be decrypted and verified. In this 673 case, the SSRC will never be entered into the mapping table, because 674 the decryption and verification always fails. Receivers MAY keep 675 records of unmapped SSRCs which consistently fail decryption and 676 verification and abandon attempts to process them once they reach 677 some limit. That limit MUST be large enough to account for the 678 effects of transmission errors. Entries MUST be pruned from this 679 table when the relevant SRTP endpoint is deleted (e.g., the call 680 ends) and SHOULD time out faster than that (we do not offer a hard 681 recommendation but 10 to 30 seconds seems appropriate) in order to 682 allow for the possibility that the peer implementation has been 683 corrected. 685 5.2. Rehandshake and Re-key 687 Rekeying in DTLS is accomplished by performing a new handshake over 688 the existing DTLS channel. I.e., the handshake messages are 689 protected by the existing DTLS cipher suite. This handshake can be 690 performed in parallel with data transport, so no interruption of the 691 data flow is required. Once the handshake is finished, the newly 692 derived set of keys is used to protect all outbound packets, both 693 DTLS and SRTP. 695 Because of packet reordering, packets protected by the previous set 696 of keys can appear on the wire after the handshake has completed. To 697 compensate for this fact, receivers SHOULD maintain both sets of keys 698 for some time in order to be able to decrypt and verify older 699 packets. The keys should be maintained for the duration of the 700 maximum segment lifetime (MSL). 702 If an MKI is used, then the receiver should use the corresponding set 703 of keys to process an incoming packet. Otherwise, when a packet 704 arrives after the handshake completed, a receiver SHOULD use the 705 newly derived set of keys to process that packet unless there is an 706 MKI (If the packet was protected with the older set of keys, this 707 fact will become apparent to the receiver as an authentication 708 failure will occur.) If the authentication check on the packet fails 709 and no MKI is being used, then the receiver MAY process the packet 710 with the older set of keys. If that authentication check indicates 711 that the packet is valid, the packet should be accepted; otherwise, 712 the packet MUST be discarded and rejected. 714 Receivers MAY use the SRTP packet sequence number to aid in the 715 selection of keys. After a packet has been received and 716 authenticated with the new key set, any packets with sequence numbers 717 that are greater will also have been protected with the new key set. 719 6. Multi-party RTP Sessions 721 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only 722 to protect unicast RTP sessions. This does not preclude its use with 723 RTP mixers. For example, a conference bridge may use DTLS-SRTP to 724 secure the communication to and from each of the participants in a 725 conference. However, because each flow between an endpoint and a 726 mixer has its own key, the mixer has to decrypt and then reencrypt 727 the traffic for each recipient. 729 A future specification may describe methods for sharing a single key 730 between multiple DTLS-SRTP associations which would allow 731 conferencing systems to avoid the decrypt/reencrypt stage. However, 732 any system in which the media is modified (e.g., for level balancing 733 or transcoding) will generally need to be performed on the plaintext 734 and will certainly break the authentication tag and therefore will 735 require a decrypt/reencrypt stage. 737 7. Security Considerations 739 The use of multiple data protection framings negotiated in the same 740 handshake creates some complexities, which are discussed here. 742 7.1. Security of Negotiation 744 One concern here is that attackers might be able to implement a bid- 745 down attack forcing the peers to use ordinary DTLS rather than SRTP. 746 However, because the negotiation of this extension is performed in 747 the DTLS handshake, it is protected by the Finished messages. 748 Therefore, any bid-down attack is automatically detected, which 749 reduces this to a denial of service attack - which any attacker who 750 can control the channel can always mount. 752 7.2. Framing Confusion 754 Because two different framing formats are used, there is concern that 755 an attacker could convince the receiver to treat an SRTP-framed RTP 756 packet as a DTLS record (e.g., a handshake message) or vice versa. 757 This attack is prevented by using different keys for MAC verification 758 for each type of data. Therefore, this type of attack reduces to 759 being able to forge a packet with a valid MAC, which violates a basic 760 security invariant of both DTLS and SRTP. 762 As an additional defense against injection into the DTLS handshake 763 channel, the DTLS record type is included in the MAC. Therefore, an 764 SRTP record would be treated as an unknown type and ignored. (See 765 Section 6 of [RFC5246]). 767 7.3. Sequence Number Interactions 769 As described in Section 5.1.1, the SRTP and DTLS sequence number 770 spaces are distinct. This means that it is not possible to 771 unambiguously order a given DTLS control record with respect to an 772 SRTP packet. In general, this is relevant in two situations: alerts 773 and rehandshake. 775 7.3.1. Alerts 777 Because DTLS handshake and change_cipher_spec messages share the same 778 sequence number space as alerts, they can be ordered correctly. 779 Because DTLS alerts are inherently unreliable and SHOULD NOT be 780 generated as a response to data packets, reliable sequencing between 781 SRTP packets and DTLS alerts is not an important feature. However, 782 implementations which wish to use DTLS alerts to signal problems with 783 the SRTP encoding SHOULD simply act on alerts as soon as they are 784 received and assume that they refer to the temporally contiguous 785 stream. Such implementations MUST check for alert retransmission and 786 discard retransmitted alerts to avoid overreacting to replay attacks. 788 7.3.2. Renegotiation 790 Because the rehandshake transition algorithm specified in Section 5.2 791 requires trying multiple sets of keys if no MKI is used, it slightly 792 weakens the authentication. For instance, if an n-bit MAC is used 793 and k different sets of keys are present, then the MAC is weakened by 794 log_2(k) bits to n - log_2(k). In practice, since the number of keys 795 used will be very small and the MACs in use are typically strong (the 796 default for SRTP is 80 bits) the decrease in security involved here 797 is minimal. 799 Another concern here is that this algorithm slightly increases the 800 work factor on the receiver because it needs to attempt multiple 801 validations. However, again, the number of potential keys will be 802 very small (and the attacker cannot force it to be larger) and this 803 technique is already used for rollover counter management, so the 804 authors do not consider this to be a serious flaw. 806 7.4. Decryption Cost 808 An attacker can impose computational costs on the receiver by sending 809 superficially valid SRTP packets which do not decrypt correctly. In 810 general, encryption algorithms are so fast that this cost is 811 extremely small compared to the bandwidth consumed. The SSRC-DTLS 812 mapping algorithm described in Section 5.1.2 gives the attacker a 813 slight advantage here because he can force the receiver to do more 814 then one decryption per packet. However, this advantage is modest 815 because the number of decryptions that the receiver does is limited 816 by the number of associations he has corresponding to a given 817 destination host/port, which is typically quite small. For 818 comparison, a single 1024-bit RSA private key operation (the typical 819 minimum cost to establish a DTLS-SRTP association) is hundreds of 820 times as expensive as decrypting an SRTP packet. 822 Implementations can detect this form of attack by keeping track of 823 the number of SRTP packets observed with unknown SSRCs which fail the 824 authentication tag check. If under such attack, implementations 825 SHOULD prioritize decryption and verification of packets which either 826 have known SSRCs or come from source addresses which match those of 827 peers with which it has DTLS-SRTP associations. 829 8. Session Description for RTP/SAVP over DTLS 831 This specification defines new tokens to describe the protocol used 832 in SDP media descriptions ('m' lines and their associated 833 parameters). The new values defined for the proto field are: 834 o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over 835 DTLS with DCCP, then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/ 836 TLS/RTP/SAVPF respectively. 837 o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with 838 UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF 839 respectively. 841 The "fmt" parameter SHALL be as defined for RTP/SAVP. 843 See [I-D.ietf-sip-dtls-srtp-framework] for how to use offer/answer 844 with DTLS-SRTP. 846 This document does not specify how to protect RTP data transported 847 over TCP. Potential approaches include carrying the RTP over TLS 848 over TCP (see [I-D.ietf-avt-srtp-not-mandatory]) or using a mechanism 849 similar to that in this document over TCP, either via TLS or DTLS, 850 with DTLS being used for consistency between reliable and unreliable 851 transports. In the latter case, it would be necessary to profile 852 DTLS so that fragmentation and retransmissions no longer occurred. 853 In either case, a new document would be required. 855 9. IANA Considerations 857 This document adds a new extension for DTLS, in accordance with 858 [RFC5246]: 859 enum { use_srtp (??) } ExtensionType; 861 [[ NOTE: This value needs to be assigned by IANA ]] 863 This extension MUST only be used with DTLS, and not with TLS 864 [RFC4572] which specifies that TLS can be used over TCP but does not 865 address TCP for RTP/SAVP. 867 Section 4.1.2 requires that all SRTPProtectionProfile values be 868 defined by RFC 5226 Specification Required. IANA will create/(has 869 created) a DTLS SRTPProtectionProfile registry initially populated 870 with values from Section 4.1.2 of this document. Future values MUST 871 be allocated via the "Specification Required" profile of [RFC5226] 873 This specification updates the "Session Description Protocol (SDP) 874 Parameters" registry as defined in section 8.2.2 of RFC 4566 875 [RFC4566]. Specifically it adds the following values to the table 876 for the "proto" field. 878 Type SDP Name Reference 879 ---- ------------------ --------- 880 proto UDP/TLS/RTP/SAVP [RFC-XXXX] 881 proto DCCP/TLS/RTP/SAVP [RFC-XXXX] 883 proto UDP/TLS/RTP/SAVPF [RFC-XXXX] 884 proto DCCP/TLS/RTP/SAVPF [RFC-XXXX] 886 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 887 this specification. 889 IANA should register/has registered the "EXTRACTOR-dtls_srtp". value 890 in the TLS Extractor Label Registry to correspond to this 891 specification. 893 10. Acknowledgments 895 Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, 896 Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, 897 and Ben Campbell for input, discussions, and guidance. Pasi Eronen 898 provided Figure 1. 900 11. References 902 11.1. Normative References 904 [I-D.ietf-avt-rtp-and-rtcp-mux] 905 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 906 Control Packets on a Single Port", 907 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 908 August 2007. 910 [I-D.ietf-tls-extractor] 911 Rescorla, E., "Keying Material Extractors for Transport 912 Layer Security (TLS)", draft-ietf-tls-extractor-02 (work 913 in progress), September 2008. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 919 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 920 RFC 3711, March 2004. 922 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 923 Security", RFC 4347, April 2006. 925 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 926 BCP 131, RFC 4961, July 2007. 928 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 929 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 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-04 (work in progress), 949 October 2008. 951 [I-D.ietf-tls-rfc4347-bis] 952 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 953 Security version 1.2", draft-ietf-tls-rfc4347-bis-00 (work 954 in progress), June 2008. 956 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 957 Jacobson, "RTP: A Transport Protocol for Real-Time 958 Applications", STD 64, RFC 3550, July 2003. 960 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 961 Description Protocol", RFC 4566, July 2006. 963 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 964 Transport Layer Security (TLS) Protocol in the Session 965 Description Protocol (SDP)", RFC 4572, July 2006. 967 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 968 Real-time Transport Control Protocol (RTCP)-Based Feedback 969 (RTP/SAVPF)", RFC 5124, February 2008. 971 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 972 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 973 May 2008. 975 Appendix A. Overview of DTLS 977 This section provides a brief overview of Datagram TLS (DTLS) for 978 those who are not familiar with it. DTLS is a channel security 979 protocol based on the well-known Transport Layer Security (TLS) 980 [RFC5246] protocol. Where TLS depends on a reliable transport 981 channel (typically TCP), DTLS has been adapted to support unreliable 982 transports such as UDP. Otherwise, DTLS is nearly identical to TLS 983 and generally supports the same cryptographic mechanisms. 985 Each DTLS association begins with a handshake exchange (shown below) 986 during which the peers authenticate each other and negotiate 987 algorithms, modes, and other parameters and establish shared keying 988 material, as shown below. In order to support unreliable transport, 989 each side maintains retransmission timers to provide reliable 990 delivery of these messages. Once the handshake is completed, 991 encrypted data may be sent. 993 Client Server 995 ClientHello --------> 996 ServerHello 997 Certificate* 998 ServerKeyExchange* 999 CertificateRequest* 1000 <-------- ServerHelloDone 1001 Certificate* 1002 ClientKeyExchange 1003 CertificateVerify* 1004 [ChangeCipherSpec] 1005 Finished --------> 1006 [ChangeCipherSpec] 1007 <-------- Finished 1008 Application Data <-------> Application Data 1009 '*' indicates messages which are not always sent. 1011 Application data is protected by being sent as a series of DTLS 1012 "records". These records are independent and which can be processed 1013 correctly even in the face of loss or reordering. In DTLS-SRTP, this 1014 record protocol is replaced with SRTP [RFC3711] 1016 Appendix B. Performance of Multiple DTLS Handshakes 1018 Standard practice for security protocols such as TLS, DTLS, and SSH 1019 which do inline key management is to create a separate security 1020 association for each underlying network channel (TCP connection, UDP 1021 host/port quartet, etc.). This has dual advantages of simplicity and 1022 independence of the security contexts for each channel. 1024 Three concerns have been raised about the overhead of this strategy 1025 in the context of RTP security. The first concern is the additional 1026 performance overhead of doing a separate public key operation for 1027 each channel. The conventional procedure here (used in TLS and DTLS) 1028 is to establish a master context which can then be used to derive 1029 fresh traffic keys for new associations. In TLS/DTLS this is called 1030 "session resumption" and can be transparently negotiated between the 1031 peers. 1033 The second concern is network bandwidth overhead for the 1034 establishment of subsequent connections and for rehandshake (for 1035 rekeying) for existing connections. In particular, there is a 1036 concern that the channels will have very narrow capacity requirements 1037 allocated entirely to media which will be overflowed by the 1038 rehandshake. Measurements of the size of the rehandshake (with 1039 resumption) in TLS indicate that it is about 300-400 bytes if a full 1040 selection of cipher suites is offered. (the size of a full handshake 1041 is approximately 1-2k larger because of the certificate and keying 1042 material exchange). 1044 The third concern is the additional round-trips associated with 1045 establishing the 2nd, 3rd, ... channels. In TLS/DTLS these can all 1046 be done in parallel but in order to take advantage of session 1047 resumption they should be done after the first channel is 1048 established. For two channels this provides a ladder diagram 1049 something like this (parenthetical #s are media channel #s) 1050 Alice Bob 1051 ------------------------------------------- 1052 <- ClientHello (1) 1053 ServerHello (1) -> 1054 Certificate (1) 1055 ServerHelloDone (1) 1056 <- ClientKeyExchange (1) 1057 ChangeCipherSpec (1) 1058 Finished (1) 1059 ChangeCipherSpec (1)-> 1060 Finished (1)-> 1061 <--- Channel 1 ready 1063 <- ClientHello (2) 1064 ServerHello (2) -> 1065 ChangeCipherSpec(2)-> 1066 Finished(2) -> 1067 <- ChangeCipherSpec (2) 1068 Finished (2) 1069 <--- Channel 2 ready 1071 So, there is an additional 1 RTT after Channel 1 is ready before 1072 Channel 2 is ready. If the peers are potentially willing to forego 1073 resumption they can interlace the handshakes, like so: 1075 Alice Bob 1076 ------------------------------------------- 1077 <- ClientHello (1) 1078 ServerHello (1) -> 1079 Certificate (1) 1080 ServerHelloDone (1) 1081 <- ClientKeyExchange (1) 1082 ChangeCipherSpec (1) 1083 Finished (1) 1084 <- ClientHello (2) 1085 ChangeCipherSpec (1)-> 1086 Finished (1)-> 1087 <--- Channel 1 ready 1088 ServerHello (2) -> 1089 ChangeCipherSpec(2)-> 1090 Finished(2) -> 1091 <- ChangeCipherSpec (2) 1092 Finished (2) 1093 <--- Channel 2 ready 1095 In this case the channels are ready contemporaneously, but if a 1096 message in handshake (1) is lost then handshake (2) requires either a 1097 full rehandshake or that Alice be clever and queue the resumption 1098 attempt until the first handshake completes. Note that just dropping 1099 the packet works as well since Bob will retransmit. 1101 Authors' Addresses 1103 David McGrew 1104 Cisco Systems 1105 510 McCarthy Blvd. 1106 Milpitas, CA 95305 1107 USA 1109 Email: mcgrew@cisco.com 1111 Eric Rescorla 1112 RTFM, Inc. 1113 2064 Edgewood Drive 1114 Palo Alto, CA 94303 1115 USA 1117 Email: ekr@rtfm.com 1119 Full Copyright Statement 1121 Copyright (C) The IETF Trust (2008). 1123 This document is subject to the rights, licenses and restrictions 1124 contained in BCP 78, and except as set forth therein, the authors 1125 retain all their rights. 1127 This document and the information contained herein are provided on an 1128 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1129 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1130 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1131 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1132 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1133 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1135 Intellectual Property 1137 The IETF takes no position regarding the validity or scope of any 1138 Intellectual Property Rights or other rights that might be claimed to 1139 pertain to the implementation or use of the technology described in 1140 this document or the extent to which any license under such rights 1141 might or might not be available; nor does it represent that it has 1142 made any independent effort to identify any such rights. Information 1143 on the procedures with respect to rights in RFC documents can be 1144 found in BCP 78 and BCP 79. 1146 Copies of IPR disclosures made to the IETF Secretariat and any 1147 assurances of licenses to be made available, or the result of an 1148 attempt made to obtain a general license or permission for the use of 1149 such proprietary rights by implementers or users of this 1150 specification can be obtained from the IETF on-line IPR repository at 1151 http://www.ietf.org/ipr. 1153 The IETF invites any interested party to bring to its attention any 1154 copyrights, patents or patent applications, or other proprietary 1155 rights that may cover technology that may be required to implement 1156 this standard. Please address the information to the IETF at 1157 ietf-ipr@ietf.org.