idnits 2.17.1 draft-ietf-avt-dtls-srtp-01.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 914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 938. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the server is willing to accept the use_srtp extension, it MUST respond with its own "use_srtp" extension in the ExtendedServerHello. The extension_data field MUST contain a UseSRTPData value with a single SRTPProtectionProfile value which the server has chosen for use with this connection. The server MUST NOT select a value which the client has not offered. If there is no shared profile, the server SHOULD not return the use_srtp extension at which point the connection falls back to the negotiated DTLS cipher suite. If that is not acceptable the server SHOULD return an appropriate DTLS alert. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2007) is 5998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 228 ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (ref. '4') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (ref. '5') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (ref. '6') (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: A later version (-04) exists of draft-fischl-mmusic-sdp-dtls-03 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-13 == Outdated reference: A later version (-01) exists of draft-mcgrew-srtp-big-aes-00 == Outdated reference: A later version (-01) exists of draft-rescorla-tls-extractor-00 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 20, 2008 Network Resonance 6 November 17, 2007 8 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for 9 Secure Real-time Transport Protocol (SRTP) 10 draft-ietf-avt-dtls-srtp-01.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 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a Datagram Transport Layer Security (DTLS) 44 extension to establish keys for secure RTP (SRTP) and secure RTP 45 Control Protocol (SRTCP) flows. DTLS keying happens on the media 46 path, independent of any out-of-band signalling channel present. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 52 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4 53 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5 54 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5 55 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 6 56 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 7 57 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9 58 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12 61 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 12 62 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 12 63 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 12 64 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13 65 5.2. Rehandshake and Re-key . . . . . . . . . . . . . . . . . . 13 66 6. Multi-party RTP Sessions . . . . . . . . . . . . . . . . . . . 14 67 6.1. SIP Forking . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 15 70 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 15 71 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 15 72 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 16 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 10.2. Informational References . . . . . . . . . . . . . . . . . 17 79 Appendix A. Performance of Multiple DTLS Handshakes . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 81 Intellectual Property and Copyright Statements . . . . . . . . . . 21 83 1. Introduction 85 The Secure RTP profile (SRTP) [6] can provide confidentiality, 86 message authentication, and replay protection to RTP data and RTP 87 Control (RTCP) traffic. SRTP does not provide key management 88 functionality, but instead depends on external key management to 89 exchange secret master keys, and to negotiate the algorithms and 90 parameters for use with those keys. 92 Datagram Transport Layer Security (DTLS) [5] is a channel security 93 protocol that offers integrated key management, parameter 94 negotiation, and secure data transfer. Because DTLS's data transfer 95 protocol is generic, it is less highly optimized for use with RTP 96 than is SRTP, which has been specifically tuned for that purpose. 98 This document describes DTLS-SRTP, an SRTP extension for DTLS which 99 combine the performance and encryption flexibility benefits of SRTP 100 with the flexibility and convenience of DTLS's integrated key and 101 association management. DTLS-SRTP can be viewed in two equivalent 102 ways: as a new key management method for SRTP, and a new RTP- 103 specific data format for DTLS. 105 The key points of DTLS-SRTP are that: 106 o application data is protected using SRTP, 107 o the DTLS handshake is used to establish keying material, 108 algorithms, and parameters for SRTP, 109 o a DTLS extension used to negotiate SRTP algorithms, and 110 o other DTLS record layer content types are protected using the 111 ordinary DTLS record format. 113 The remainder of this memo is structured as follows. Section 2 114 describes conventions used to indicate normative requirements. 115 Section 3 provides an overview of DTLS-SRTP operation. Section 4 116 specifies the DTLS extensions, while Section 5 discusses how RTP and 117 RTCP are transported over a DTLS-SRTP channel. Section 6 describes 118 use with multi-party sessions. Section 7 and Section 8 describe 119 Security and IANA considerations. 121 2. Conventions Used In This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [1]. 127 3. Overview of DTLS-SRTP Operation 129 DTLS-SRTP is defined for point-to-point media sessions, in which 130 there are exactly two participants. Each DTLS-SRTP session contains 131 a single DTLS association (called a "connection" in TLS jargon), and 132 an SRTP context. A single DTLS-SRTP session only protects data 133 carried over a single UDP source and destination port pair. 135 The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP 136 flow the peers do a DTLS handshake on the same source and destination 137 port pair to establish a DTLS association. The keying material from 138 that handshake is fed into the SRTP stack. Once that association is 139 established, RTP packets are protected (becoming SRTP) using that 140 keying material. 142 RTP and RTCP traffic is usually sent on two separate UDP ports. When 143 symmetric RTP [9] is used, two bidirectional DTLS-SRTP sessions are 144 needed, one for the RTP port, one for the RTCP port. When RTP flows 145 are not symmetric, four unidirectional DTLS-SRTP sessions are needed 146 (for inbound and outbound RTP, and inbound and outbound RTCP). 148 Symmetric RTP [9] is the case in which there are two RTP sessions 149 that have their source and destination ports and addresses reversed, 150 in a manner similar to the way that a TCP connection uses its ports. 151 Each participant has an inbound RTP session and an outbound RTP 152 session. When symmetric RTP is used, a single DTLS-SRTP session can 153 protect both of the RTP sessions. 155 RTP and RTCP traffic MAY be multiplexed on a single UDP port [7]. In 156 this case, both RTP and RTCP packets may be sent over the same DTLS- 157 SRTP session, halving the number of DTLS-SRTP sessions needed. It is 158 RECOMMENDED that symmetric RTP is used, with RTP and RTCP multiplexed 159 on a single UDP port; this requires only a single DTLS-SRTP session. 161 Between a single pair of participants, there may be multiple media 162 sessions. There MUST be a separate DTLS-SRTP session for each 163 distinct pair of source and destination ports used by a media session 164 (though the sessions can share a single DTLS session and hence 165 amortize the initial public key handshake!). 167 A DTLS-SRTP session MAY be indicated by an external signaling 168 protocol like SIP. When the signaling exchange is integrity- 169 protected (e.g when SIP Identity protection via digital signatures is 170 used), DTLS-SRTP can leverage this integrity guarantee to provide 171 complete security of the media stream. A description of how to 172 indicate DTLS-SRTP sessions in SIP and SDP, and how to authenticate 173 the endpoints using fingerprints can be found in [12] and [11]. 175 In a naive implementation, when there are multiple media sessions, 176 there is a new DTLS session establishment (complete with public key 177 cryptography) for each media channel. For example, a videophone may 178 be sending both an audio stream and a video stream, each of which 179 would use a separate DTLS session establishment exchange, which would 180 proceed in parallel. As an optimization, the DTLS-SRTP 181 implementation SHOULD use the following strategy: a single DTLS 182 connection is established, and all other DTLS sessions wait until 183 that connection is established before proceeding with their session 184 establishment exchanges. This strategy allows the later sessions to 185 use the DTLS session re-start, which allows the amortization of the 186 expensive public key cryptography operations over multiple DTLS 187 session establishment instances. 189 The SRTP keys used to protect packets originated by the client are 190 distinct from the SRTP keys used to protect packets originated by the 191 server. All of the RTP sources originating on the client use the 192 same SRTP keys, and similarly, all of the RTP sources originating on 193 the server over the same channel use the same SRTP keys. The SRTP 194 implementation MUST ensure that all of the SSRC values for all of the 195 RTP sources originating from the same device are distinct, in order 196 to avoid the "two-time pad" problem (as described in Section 9.1 of 197 RFC 3711). 199 4. DTLS Extensions for SRTP Key Establishment 201 4.1. The use_srtp Extension 203 In order to negotiate the use of SRTP data protection, clients 204 include an extension of type "use_srtp" in the DTLS extended client 205 hello. This extension MUST only be used when the data being 206 transported is RTP and RTCP [3]. The "extension_data" field of this 207 extension contains the list of acceptable SRTP protection profiles, 208 as indicated below. 210 Servers that receive an extended hello containing a "use_srtp" 211 extension can agree to use SRTP by including an extension of type 212 "use_srtp", with the chosen protection profile in the extended server 213 hello. This process is shown below. 215 Client Server 217 ClientHello + use_srtp --------> 218 ServerHello + use_srtp 219 Certificate* 220 ServerKeyExchange* 221 CertificateRequest* 222 <-------- ServerHelloDone 223 Certificate* 224 ClientKeyExchange 225 CertificateVerify* 226 [ChangeCipherSpec] 227 Finished --------> 228 [ChangeCipherSpec] 229 <-------- Finished 230 SRTP packets <-------> SRTP packets 232 Note that '*' indicates messages which are not always sent in DTLS. 233 The CertificateRequest, client Certificate, and CertificateVerify 234 will be sent in DTLS-SRTP. 236 Once the "use_srtp" extension is negotiated, the RTP or RTCP 237 application data is protected solely using SRTP. Application data is 238 never sent in DTLS record-layer "application_data" packets. Rather, 239 complete RTP or RTCP packets are passed to the DTLS stack which 240 passes them to the SRTP stack which protects them appropriately. 241 Note that if RTP/RTCP multiplexing [10] is in use, this means that 242 RTP and RTCP packets may both be passed to the DTLS stack. Because 243 the DTLS layer does not process the packets, it does need to 244 distinguish them. The SRTP stack can use the procedures of [10] to 245 distinguish RTP from RTCP. 247 When the "use_srtp" extension is in effect, implementations MUST NOT 248 place more than one "record" per datagram. (This is only meaningful 249 from the perspective of DTLS because SRTP is inherently oriented 250 towards one payload per packet, but is stated purely for 251 clarification.) 253 Records of type other than "application_data" MUST use ordinary DTLS 254 framing. 256 4.1.1. use_srtp Extension Definition 258 The client MUST fill the extension_data field of the "use_srtp" 259 extension with an UseSRTPData value (see Section 8 for the 260 registration): 262 uint8 SRTPProtectionProfile[2]; 264 struct { 265 SRTPProtectionProfiles SRTPProtectionProfiles; 266 uint8 srtp_mki<0..255>; 267 } UseSRTPData; 269 SRTPProtectionProfile SRTPProtectionProfiles<2^16-1>; 271 The SRTPProtectionProfiles list indicates the SRTP protection 272 profiles that the client is willing to support, listed in descending 273 order of preference. The srtp_mki value contains the SRTP 274 MasterKeyIdentifier (MKI) value (if any) which the client will use 275 for his SRTP messages. If this field is of zero length, then no MKI 276 will be used. 278 If the server is willing to accept the use_srtp extension, it MUST 279 respond with its own "use_srtp" extension in the ExtendedServerHello. 280 The extension_data field MUST contain a UseSRTPData value with a 281 single SRTPProtectionProfile value which the server has chosen for 282 use with this connection. The server MUST NOT select a value which 283 the client has not offered. If there is no shared profile, the 284 server SHOULD not return the use_srtp extension at which point the 285 connection falls back to the negotiated DTLS cipher suite. If that 286 is not acceptable the server SHOULD return an appropriate DTLS alert. 288 4.1.2. SRTP Protection Profiles 290 A DTLS-SRTP SRTP Protection Profile defines the parameters and 291 options that are in effect for the SRTP processing. This document 292 defines the following SRTP protection profiles. 294 SRTPProtectionProfile SRTP_AES128_CM_SHA1_80 = {0x00, 0x01}; 295 SRTPProtectionProfile SRTP_AES128_CM_SHA1_32 = {0x00, 0x02}; 296 SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03}; 297 SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04}; 298 SRTPProtectionProfile SRTP_NULL_SHA1_80 = {0x00, 0x05}; 299 SRTPProtectionProfile SRTP_NULL_SHA1_32 = {0x00, 0x06}; 301 The following list indicates the SRTP transform parameters for each 302 protection profile. The parameters cipher_key_length, 303 cipher_salt_length, auth_key_length, and auth_tag_length express the 304 number of bits in the values to which they refer. The 305 maximum_lifetime parameter indicates the maximum number of packets 306 that can be protected with each single set of keys when the parameter 307 profile is in use. All of these parameters apply to both RTP and 308 RTCP, unless the RTCP parameters are separately specified. 310 All of the crypto algorithms in these profiles are from [7], except 311 for the AES256_CM cipher, which is specified in [14]. 313 SRTP_AES128_CM_HMAC_SHA1_80 314 cipher: AES_128_CM 315 cipher_key_length: 128 316 cipher_salt_length: 112 317 maximum_lifetime: 2^31 318 auth_function: HMAC-SHA1 319 auth_key_length: 160 320 auth_tag_length: 80 321 SRTP_AES128_CM_HMAC_SHA1_32 322 cipher: AES_128_CM 323 cipher_key_length: 128 324 cipher_salt_length: 112 325 maximum_lifetime: 2^31 326 auth_function: HMAC-SHA1 327 auth_key_length: 160 328 auth_tag_length: 32 329 RTCP auth_tag_length: 80 330 SRTP_AES256_CM_HMAC_SHA1_80 331 cipher: AES_128_CM 332 cipher_key_length: 128 333 cipher_salt_length: 112 334 maximum_lifetime: 2^31 335 auth_function: HMAC-SHA1 336 auth_key_length: 160 337 auth_tag_length: 80 338 SRTP_AES256_CM_HMAC_SHA1_32 339 cipher: AES_128_CM 340 cipher_key_length: 128 341 cipher_salt_length: 112 342 maximum_lifetime: 2^31 343 auth_function: HMAC-SHA1 344 auth_key_length: 160 345 auth_tag_length: 32 346 RTCP auth_tag_length: 80 347 SRTP_NULL_HMAC_SHA1_80 348 cipher: NULL 349 cipher_key_length: 0 350 cipher_salt_length: 0 351 maximum_lifetime: 2^31 352 auth_function: HMAC-SHA1 353 auth_key_length: 160 354 auth_tag_length: 80 355 SRTP_NULL_HMAC_SHA1_32 356 cipher: NULL 357 cipher_key_length: 0 358 cipher_salt_length: 0 359 maximum_lifetime: 2^31 360 auth_function: HMAC-SHA1 361 auth_key_length: 160 362 auth_tag_length: 32 363 RTCP auth_tag_length: 80 365 With all of these SRTP Parameter profiles, the following SRTP options 366 are in effect: 368 o The TLS Key Derivation Function (KDF) is used to generate keys to 369 feed into the SRTP KDF. 370 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 371 not re-derived based on the SRTP sequence number. 372 o For all other parameters, the default values are used. 374 All SRTP parameters that are not determined by the SRTP Protection 375 Profile MAY be established via the signaling system. In particular, 376 the relative order of Forward Error Correction and SRTP processing, 377 and a suggested SRTP replay window size SHOULD be established in this 378 manner. An example of how these parameters can be defined for SDP by 379 is contained in [8]. If they are not otherwise signalled, they take 380 on their default values from [7]. 382 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection 383 Profiles between the DTLS-SRTP session that protects an RTP flow and 384 the DTLS-SRTP session that protects the associated RTCP flow (in 385 those case in which the RTP and RTCP are not multiplexed over a 386 common port). In particular, identical ciphers SHOULD be used. 388 New SRTPProtectionProfile values must be defined by RFC 2434 389 Standards Action. See Section 8 for IANA Considerations. 391 4.1.3. srtp_mki value 393 The srtp_mki value MAY be used to indicate the capability and desire 394 to use the SRTP Master Key Indicator (MKI) field in the SRTP and 395 SRTCP packets. The MKI field indicates to an SRTP receiver which key 396 was used to protect the packet that contains that field. The 397 srtp_mki field contains the value of the SRTP MKI which is associated 398 with the SRTP master keys derived from this handshake. Each SRTP 399 session MUST have exactly one master key that is used to protect 400 packets at any given time. The client MUST choose the MKI value so 401 that it is distinct from the last MKI value that was used, and it 402 SHOULD make these values unique. 404 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, 405 the server MUST either (assuming it accepts the extension at all): 407 1. include a matching "srtp_mki" value in its "use_srtp" extension 408 to indicate that it will make use of the MKI, or 409 2. return an empty "srtp_mki" value to indicate that it cannot make 410 use of the MKI. 412 If the client detects a nonzero-length MKI in the server's response 413 that is different than the one the client offered MUST abort the 414 handshake and SHOULD send an invalid_parameter alert. If the client 415 and server agree on an MKI, all SRTP packets protected under the new 416 security parameters MUST contain that MKI. 418 4.2. Key Derivation 420 When SRTP mode is in effect, different keys are used for ordinary 421 DTLS record protection and SRTP packet protection. These keys are 422 generated using a TLS extractor [15] to generate 2 * 423 (SRTPSecurityParams.master_key_len + 424 SRTPSecurityParams.master_salt_len) bytes of data, which are assigned 425 as shown below. 427 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 428 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; 429 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 430 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; 432 The extractor label for this usage is "dtls_srtp". 434 The four keying material values are provided as inputs to the SRTP 435 key derivation mechanism, as shown in Figure 5 and detailed below. 436 By default, the mechanism defined in Section 4.3 of [7] is used, 437 unless another key derivation mechanism is specified as part of an 438 SRTP Protection Profile. 440 The client_write_SRTP_master_key and client_write_SRTP_master_salt 441 are provided to one invocation of the SRTP key derivation function, 442 to generate the SRTP keys used to encrypt and authenticate packets 443 sent by the client. The server MUST only use these keys to decrypt 444 and to check the authenticity of inbound packets. 446 The server_write_SRTP_master_key and server_write_SRTP_master_salt 447 are provided to one invocation of the SRTP key derivation function, 448 to generate the SRTP keys used to encrypt and authenticate packets 449 sent by the server. The client MUST only use these keys to decrypt 450 and to check the authenticity of inbound packets. 452 +------- TLS master secret 453 | 454 v +-> client_write_MAC_secret 455 +-----+ | 456 | TLS |--+-> server_write_MAC_secret 457 | KDF | | 458 +-----+ +-> client_write_key 459 | 460 +-> server_write_key 461 | +------+ SRTP 462 +-> client_write_SRTP_master_key ----->| SRTP |-> client 463 | +--->| KDF | write 464 +-> server_write_SRTP_master_key --|-+ +------+ keys 465 | | | 466 +-> client_write_SRTP_master_salt -+ | +------+ SRTP 467 | +->| SRTP |-> server 468 +-> server_write_SRTP_master_salt ----->| KDF | write 469 +------+ keys 471 Figure 5: The derivation of the SRTP keys. 473 When both RTCP and RTP use the same source and destination ports, 474 then both the SRTP and SRTCP keys are need. Otherwise, there are two 475 DTLS-SRTP sessions, one of which protects the RTP packets and one of 476 which protects the RTCP packets; each DTLS-SRTP session protects the 477 part of an SRTP session that passes over a single source/destination 478 transport address pair, as shown in Figure 6. When a DTLS-SRTP 479 session is protecting RTP, the SRTCP keys derived from the DTLS 480 handshake are not needed and are discarded. When a DTLS-SRTP session 481 is protecting RTCP, the SRTP keys derived from the DTLS handshake are 482 not needed and are discarded. 484 Client Server 485 (Sender) (Receiver) 486 (1) <----- DTLS ------> src/dst = a/b and b/a 487 ------ SRTP ------> src/dst = a/b, uses client write keys 489 (2) <----- DTLS ------> src/dst = c/d and d/c 490 ------ SRTCP -----> src/dst = c/d, uses client write keys 491 <----- SRTCP ------ src/dst = d/c, uses server write keys 493 Figure 6: A DTLS-SRTP session protecting RTP (1) and another one 494 protecting RTCP (2), showing the transport addresses and keys used. 496 4.3. Key Scope 498 Because of the possibility of packet reordering, DTLS-SRTP 499 implementations SHOULD store multiple SRTP keys sets during a re-key 500 in order to avoid the need for receivers to drop packets for which 501 they lack a key. 503 4.4. Key Usage Limitations 505 The maximum_lifetime parameter in the SRTP protection profile 506 indicates the maximum number of packets that can be protected with 507 each single encryption and authentication key. (Note that, since RTP 508 and RTCP are protected with independent keys, those protocols are 509 counted separately for the purposes of determining when a key has 510 reached the end of its lifetime.) Each profile defines its own 511 limit. When this limit is reached, a new DTLS session SHOULD be used 512 to establish replacement keys, and SRTP implementations MUST NOT use 513 the existing keys for the processing of either outbound or inbound 514 traffic. 516 5. Use of RTP and RTCP over a DTLS-SRTP Channel 518 5.1. Data Protection 520 Once the DTLS handshake has completed the peers can send RTP or RTCP 521 over the newly created channel. We describe the transmission process 522 first followed by the reception process. 524 Within each RTP session, SRTP processing MUST NOT take place before 525 the DTLS handshake completes. 527 5.1.1. Transmission 529 DTLS and TLS define a number of record content types. In ordinary 530 TLS/DTLS, all data is protected using the same record encoding and 531 mechanisms. When the mechanism described in this document is in 532 effect, this is modified so that data of type "application_data" 533 (used to transport data traffic) is encrypted using SRTP rather than 534 the standard TLS record encoding. 536 When a user of DTLS wishes to send an RTP packet in SRTP mode it 537 delivers it to the DTLS implementation as a single write of type 538 "application_data". The DTLS implementation then invokes the 539 processing described in RFC 3711 Sections 3 and 4. The resulting 540 SRTP packet is then sent directly on the wire as a single datagram 541 with no DTLS framing. This provides an encapsulation of the data 542 that conforms to and interoperates with SRTP. Note that the RTP 543 sequence number rather than the DTLS sequence number is used for 544 these packets. 546 5.1.2. Reception 548 When DTLS-SRTP is used to protect an RTP session, the RTP receiver 549 needs to demultiplex packets that are arriving on the RTP port. 550 Arriving packets may be of types RTP, DTLS, or STUN[13]. The type of 551 a packet can be determined by looking at its first byte. 553 The process for demultiplexing a packet is as follows. The receiver 554 looks at the first byte of the packet. If the value of this byte is 555 0 or 1, then the packet is STUN. If the value is in between 128 and 556 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 557 RTP are being multiplexed over the same destination port). If the 558 value is between 20 and 63 (inclusive), the packet is DTLS. This 559 processes is summarized in Figure 7. 561 +----------------+ 562 | 127 < B < 192 -+--> forward to RTP 563 | | 564 packet --> | 19 < B < 64 -+--> forward to DTLS 565 | | 566 | B < 2 -+--> forward to STUN 567 +----------------+ 569 Figure 7: The DTLS-SRTP receiver's packet demultiplexing 570 algorithm. Here the field B denotes the leading byte of the packet. 572 5.2. Rehandshake and Re-key 574 Rekeying in DTLS is accomplished by performing a new handshake over 575 the existing DTLS channel. This handshake can be performed in 576 parallel with data transport, so no interruption of the data flow is 577 required. Once the handshake is finished, the newly derived set of 578 keys is used to protect all outbound packets, both DTLS and SRTP. 580 Because of packet reordering, packets protected by the previous set 581 of keys can appear on the wire after the handshake has completed. To 582 compensate for this fact, receivers SHOULD maintain both sets of keys 583 for some time in order to be able to decrypt and verify older 584 packets. The keys should be maintained for the duration of the 585 maximum segment lifetime (MSL). 587 If an MKI is used, then the receiver should use the corresponding set 588 of keys to process an incoming packet. Otherwise, when a packet 589 arrives after the handshake completed, a receiver SHOULD use the 590 newly derived set of keys to process that packet unless there is an 591 MKI (If the packet was protected with the older set of keys, this 592 fact will become apparent to the receiver as an authentication 593 failure will occur.) If the authentication check on the packet fails 594 and no MKI is being used, then the receiver MAY process the packet 595 with the older set of keys. If that authentication check indicates 596 that the packet is valid, the packet should be accepted; otherwise, 597 the packet MUST be discarded and rejected. 599 Receivers MAY use the SRTP packet sequence number to aid in the 600 selection of keys. After a packet has been received and 601 authenticated with the new key set, any packets with sequence numbers 602 that are greater will also have been protected with the new key set. 604 6. Multi-party RTP Sessions 606 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only 607 to protect RTP flow in which there are exactly two participants. 608 This does not preclude its use with RTP mixers. For example, a 609 conference bridge may use DTLS-SRTP to secure the communication to 610 and from each of the participants in a conference. However, because 611 each flow between an endpoint and a mixer has its own key, the mixer 612 has to decrypt and then reencrypt the traffic for each recipient. 614 A future specification may describe methods for sharing a single key 615 between multiple DTLS-SRTP associations which would allow 616 conferencing systems to avoid the decrypt/reencrypt stage. However, 617 any system in which the media is modified (e.g., for level balancing 618 or transcoding) will generally need to be performed on the plaintext 619 and will certainly break the authentication tag and therefore will 620 require a decrypt/reencrypt stage. 622 6.1. SIP Forking 624 When SIP parallel forking occurs while establishing an RTP flow a 625 situation may arise in which two or more sources are sending RTP 626 packets to a single RTP destination transport address. When this 627 situation arises and DTLS-SRTP is in use, the receiver MUST use the 628 source transport IP address and port of each packet to distinguish 629 between the senders, and treat the flow of packets from each distinct 630 source transport address as a distinct DTLS-SRTP session for the 631 purposes of the DTLS association. 633 When SIP forking occurs, the following method can be used to 634 correlate each answer to the corresponding DTLS-SRTP session. If the 635 answers have different certificates then fingerprints in the answers 636 can be used to correlate the SIP dialogs with the associated DTLS 637 session. Note that two forks with the same certificate cannot be 638 distinguished at the DTLS level, but this problem is a generic 639 problem with SIP forking and should be solved at a higher level. 641 7. Security Considerations 643 The use of multiple data protection framings negotiated in the same 644 handshake creates some complexities, which are discussed here. 646 7.1. Security of Negotiation 648 One concern here is that attackers might be able to implement a bid- 649 down attack forcing the peers to use ordinary DTLS rather than SRTP. 650 However, because the negotiation of this extension is performed in 651 the DTLS handshake, it is protected by the Finished messages. 652 Therefore, any bid-down attack is automatically detected, which 653 reduces this to a denial of service attack - which any attacker who 654 can control the channel can always mount. 656 7.2. Framing Confusion 658 Because two different framing formats are used, there is concern that 659 an attacker could convince the receiver to treat an SRTP-framed RTP 660 packet as a DTLS record (e.g., a handshake message) or vice versa. 661 This attack is prevented by using different keys for MAC verification 662 for each type of data. Therefore, this type of attack reduces to 663 being able to forge a packet with a valid MAC, which violates a basic 664 security invariant of both DTLS and SRTP. 666 As an additional defense against injection into the DTLS handshake 667 channel, the DTLS record type is included in the MAC. Therefore, an 668 SRTP record would be treated as an unknown type and ignored. (See 669 Section 6 of [4]). 671 7.3. Sequence Number Interactions 673 As described in Section 5.1.1, the SRTP and DTLS sequence number 674 spaces are distinct. This means that it is not possible to 675 unambiguously order a given DTLS control record with respect to an 676 SRTP packet. In general, this is relevant in two situations: alerts 677 and rehandshake. 679 7.3.1. Alerts 681 Because DTLS handshake and change_cipher_spec messages share the same 682 sequence number space as alerts, they can be ordered correctly. 683 Because DTLS alerts are inherently unreliable and SHOULD NOT be 684 generated as a response to data packets, reliable sequencing between 685 SRTP packets and DTLS alerts is not an important feature. However, 686 implementations which wish to use DTLS alerts to signal problems with 687 the SRTP encoding SHOULD simply act on alerts as soon as they are 688 received and assume that they refer to the temporally contiguous 689 stream. Such implementations MUST check for alert retransmission and 690 discard retransmitted alerts to avoid overreacting to replay attacks. 692 7.3.2. Renegotiation 694 Because the rehandshake transition algorithm specified in Section 695 Section 5.2 requires trying multiple sets of keys if no MKI is used, 696 it slightly weakens the authentication. For instance, if an n-bit 697 MAC is used and k different sets of keys are present, then the MAC is 698 weakened by log_2(k) bits to n - log_2(k). In practice, since the 699 number of keys used will be very small and the MACs in use are 700 typically strong (the default for SRTP is 80 bits) the decrease in 701 security involved here is minimal. 703 Another concern here is that this algorithm slightly increases the 704 work factor on the receiver because it needs to attempt multiple 705 validations. However, again, the number of potential keys will be 706 very small (and the attacker cannot force it to be larger) and this 707 technique is already used for rollover counter management, so the 708 authors do not consider this to be a serious flaw. 710 8. IANA Considerations 712 This document a new extension for DTLS, in accordance with [6]: 713 enum { use_srtp (??) } ExtensionType; 715 [[ NOTE: This value needs to be assigned by IANA ]] 717 This extension MUST only be used with DTLS, and not with TLS. 719 Section 4.1.2 requires that all SRTPProtectionProfile values be 720 defined by RFC 2434 Standards Action. IANA SHOULD create a DTLS 721 SRTPProtectionProfile registry initially populated with values from 722 Section 4.1.2 of this document. Future values MUST be allocated via 723 Standards Action as described in [2] 725 9. Acknowledgments 727 Special thanks to Flemming Andreasen, Francois Audet, Jason Fischl, 728 Cullen Jennings, Colin Perkins, and Dan Wing, for input, discussions, 729 and guidance. 731 10. References 733 10.1. Normative References 735 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 736 Levels", BCP 14, RFC 2119, March 1997. 738 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 739 Considerations Section in RFCs", BCP 26, RFC 2434, 740 October 1998. 742 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 743 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 744 RFC 3550, July 2003. 746 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 747 Protocol Version 1.1", RFC 4346, April 2006. 749 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 750 Security", RFC 4347, April 2006. 752 [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 753 T. Wright, "Transport Layer Security (TLS) Extensions", 754 RFC 4366, April 2006. 756 [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 757 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 758 RFC 3711, March 2004. 760 [8] Andreasen, F., Baugher, M., and D. Wing, "Session Description 761 Protocol (SDP) Security Descriptions for Media Streams", 762 RFC 4568, July 2006. 764 [9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 765 BCP 131, RFC 4961, July 2007. 767 10.2. Informational References 769 [10] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 770 Control Packets on a Single Port", 771 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 772 August 2007. 774 [11] Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol 775 for Protection of Media Traffic Established with the Session 776 Initiation Protocol", draft-fischl-sipping-media-dtls-03 (work 777 in progress), July 2007. 779 [12] Fischl, J. and H. Tschofenig, "Session Description Protocol 780 (SDP) Indicators for Datagram Transport Layer Security 781 (DTLS)", draft-fischl-mmusic-sdp-dtls-03 (work in progress), 782 July 2007. 784 [13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 785 Traversal Utilities for (NAT) (STUN)", 786 draft-ietf-behave-rfc3489bis-13 (work in progress), 787 November 2007. 789 [14] McGrew, D., "The use of AES-192 and AES-256 in Secure RTP", 790 draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006. 792 [15] Rescorla, E., "Keying Material Extractors for Transport Layer 793 Security (TLS)", draft-rescorla-tls-extractor-00 (work in 794 progress), January 2007. 796 Appendix A. Performance of Multiple DTLS Handshakes 798 Standard practice for security protocols such as TLS, DTLS, and SSH 799 which do inline key management is to create a separate security 800 association for each underlying network channel (TCP connection, UDP 801 host/port quartet, etc.). This has dual advantages of simplicity and 802 independence of the security contexts for each channel. 804 Three concerns have been raised about the overhead of this strategy 805 in the context of RTP security. The first concern is the additional 806 performance overhead of doing a separate public key operation for 807 each channel. The conventional procedure here (used in TLS and DTLS) 808 is to establish a master context which can then be used to derive 809 fresh traffic keys for new associations. In TLS/DTLS this is called 810 "session resumption" and can be transparently negotiated between the 811 peers. 813 The second concern is network bandwidth overhead for the 814 establishment of subsequent connections and for rehandshake (for 815 rekeying) for existing connections. In particular, there is a 816 concern that the channels will have very narrow capacity requirements 817 allocated entirely to media which will be overflowed by the 818 rehandshake. Measurements of the size of the rehandshake (with 819 resumption) in TLS indicate that it is about 300-400 bytes if a full 820 selection of cipher suites is offered. (the size of a full handshake 821 is approximately 1-2k larger because of the certificate and keying 822 material exchange). 824 The third concern is the additional round-trips associated with 825 establishing the 2nd, 3rd, ... channels. In TLS/DTLS these can all 826 be done in parallel but in order to take advantage of session 827 resumption they should be done after the first channel is 828 established. For two channels this provides a ladder diagram 829 something like this (parenthetical #s are media channel #s) 831 Alice Bob 832 ------------------------------------------- 833 <- ClientHello (1) 834 ServerHello (1) -> 835 Certificate (1) 836 ServerHelloDone (1) 837 <- ClientKeyExchange (1) 838 ChangeCipherSpec (1) 839 Finished (1) 840 ChangeCipherSpec (1)-> 841 Finished (1)-> 842 <--- Channel 1 ready 844 <- ClientHello (2) 845 ServerHello (2) -> 846 ChangeCipherSpec(2)-> 847 Finished(2) -> 848 <- ChangeCipherSpec (2) 849 Finished (2) 850 <--- Channel 2 ready 852 So, there is an additional 1 RTT after Channel 1 is ready before 853 Channel 2 is ready. If the peers are potentially willing to forego 854 resumption they can interlace the handshakes, like so: 856 Alice Bob 857 ------------------------------------------- 858 <- ClientHello (1) 859 ServerHello (1) -> 860 Certificate (1) 861 ServerHelloDone (1) 862 <- ClientKeyExchange (1) 863 ChangeCipherSpec (1) 864 Finished (1) 865 <- ClientHello (2) 866 ChangeCipherSpec (1)-> 867 Finished (1)-> 868 <--- Channel 1 ready 869 ServerHello (2) -> 870 ChangeCipherSpec(2)-> 871 Finished(2) -> 872 <- ChangeCipherSpec (2) 873 Finished (2) 874 <--- Channel 2 ready 876 In this case the channels are ready contemporaneously, but if a 877 message in handshake (1) is lost then handshake (2) requires either a 878 full rehandshake or that Alice be clever and queue the resumption 879 attempt until the first handshake completes. Note that just dropping 880 the packet works as well since Bob will retransmit. 882 Authors' Addresses 884 David McGrew 885 Cisco Systems 886 510 McCarthy Blvd. 887 Milpitas, CA 95305 888 USA 890 Email: mcgrew@cisco.com 892 Eric Rescorla 893 Network Resonance 894 2064 Edgewood Drive 895 Palo Alto, CA 94303 896 USA 898 Email: ekr@networkresonance.com 900 Full Copyright Statement 902 Copyright (C) The IETF Trust (2007). 904 This document is subject to the rights, licenses and restrictions 905 contained in BCP 78, and except as set forth therein, the authors 906 retain all their rights. 908 This document and the information contained herein are provided on an 909 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 910 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 911 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 912 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 913 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 916 Intellectual Property 918 The IETF takes no position regarding the validity or scope of any 919 Intellectual Property Rights or other rights that might be claimed to 920 pertain to the implementation or use of the technology described in 921 this document or the extent to which any license under such rights 922 might or might not be available; nor does it represent that it has 923 made any independent effort to identify any such rights. Information 924 on the procedures with respect to rights in RFC documents can be 925 found in BCP 78 and BCP 79. 927 Copies of IPR disclosures made to the IETF Secretariat and any 928 assurances of licenses to be made available, or the result of an 929 attempt made to obtain a general license or permission for the use of 930 such proprietary rights by implementers or users of this 931 specification can be obtained from the IETF on-line IPR repository at 932 http://www.ietf.org/ipr. 934 The IETF invites any interested party to bring to its attention any 935 copyrights, patents or patent applications, or other proprietary 936 rights that may cover technology that may be required to implement 937 this standard. Please address the information to the IETF at 938 ietf-ipr@ietf.org. 940 Acknowledgment 942 Funding for the RFC Editor function is provided by the IETF 943 Administrative Support Activity (IASA).