| blob | 6633f0083dd58ddbe4412a10f50ac308e4e94f11 |
7 Internet Engineering Task Force (IETF) D. McGrew
8 Request for Comments: 5764 Cisco Systems
9 Category: Standards Track E. Rescorla
10 ISSN: 2070-1721 RTFM, Inc.
11 May 2010
14 Datagram Transport Layer Security (DTLS) Extension to Establish Keys
15 for the Secure Real-time Transport Protocol (SRTP)
17 Abstract
19 This document describes a Datagram Transport Layer Security (DTLS)
20 extension to establish keys for Secure RTP (SRTP) and Secure RTP
21 Control Protocol (SRTCP) flows. DTLS keying happens on the media
22 path, independent of any out-of-band signalling channel present.
24 Status of This Memo
26 This is an Internet Standards Track document.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 5741.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc5764.
38 Copyright Notice
40 Copyright (c) 2010 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
58 McGrew & Rescorla Standards Track [Page 1]
59 \f
60 RFC 5764 SRTP Extension for DTLS May 2010
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
73 than English.
75 Table of Contents
77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
78 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
79 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
80 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
81 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
82 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
83 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
84 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
85 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
86 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
87 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
88 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
89 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
90 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
91 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
92 5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
93 6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
95 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
96 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
97 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
98 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
99 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
100 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
101 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
106 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
107 Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
108 Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24
114 McGrew & Rescorla Standards Track [Page 2]
115 \f
116 RFC 5764 SRTP Extension for DTLS May 2010
119 1. Introduction
121 The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality,
122 message authentication, and replay protection to RTP data and RTP
123 Control (RTCP) traffic. SRTP does not provide key management
124 functionality, but instead depends on external key management to
125 exchange secret master keys, and to negotiate the algorithms and
126 parameters for use with those keys.
128 Datagram Transport Layer Security (DTLS) [RFC4347] is a channel
129 security protocol that offers integrated key management, parameter
130 negotiation, and secure data transfer. Because DTLS data transfer
131 protocol is generic, it is less highly optimized for use with RTP
132 than is SRTP, which has been specifically tuned for that purpose.
134 This document describes DTLS-SRTP, a SRTP extension for DTLS that
135 combines the performance and encryption flexibility benefits of SRTP
136 with the flexibility and convenience of DTLS-integrated key and
137 association management. DTLS-SRTP can be viewed in two equivalent
138 ways: as a new key management method for SRTP, and a new RTP-specific
139 data format for DTLS.
141 The key points of DTLS-SRTP are that:
143 o application data is protected using SRTP,
145 o the DTLS handshake is used to establish keying material,
146 algorithms, and parameters for SRTP,
148 o a DTLS extension is used to negotiate SRTP algorithms, and
150 o other DTLS record-layer content types are protected using the
151 ordinary DTLS record format.
153 The remainder of this memo is structured as follows. Section 2
154 describes conventions used to indicate normative requirements.
155 Section 3 provides an overview of DTLS-SRTP operation. Section 4
156 specifies the DTLS extensions, while Section 5 discusses how RTP and
157 RTCP are transported over a DTLS-SRTP channel. Section 6 describes
158 use with multi-party sessions. Section 7 and Section 9 describe
159 Security and IANA considerations.
161 2. Conventions Used In This Document
163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
165 document are to be interpreted as described in [RFC2119].
170 McGrew & Rescorla Standards Track [Page 3]
171 \f
172 RFC 5764 SRTP Extension for DTLS May 2010
175 3. Overview of DTLS-SRTP Operation
177 DTLS-SRTP is defined for point-to-point media sessions, in which
178 there are exactly two participants. Each DTLS-SRTP session contains
179 a single DTLS association (called a "connection" in TLS jargon), and
180 either two SRTP contexts (if media traffic is flowing in both
181 directions on the same host/port quartet) or one SRTP context (if
182 media traffic is only flowing in one direction). All SRTP traffic
183 flowing over that pair in a given direction uses a single SRTP
184 context. A single DTLS-SRTP session only protects data carried over
185 a single UDP source and destination port pair.
187 The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP
188 flow the peers do a DTLS handshake on the same source and destination
189 port pair to establish a DTLS association. Which side is the DTLS
190 client and which side is the DTLS server must be established via some
191 out-of-band mechanism such as SDP. The keying material from that
192 handshake is fed into the SRTP stack. Once that association is
193 established, RTP packets are protected (becoming SRTP) using that
194 keying material.
196 RTP and RTCP traffic is usually sent on two separate UDP ports. When
197 symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions
198 are needed, one for the RTP port, one for the RTCP port. When RTP
199 flows are not symmetric, four unidirectional DTLS-SRTP sessions are
200 needed (for inbound and outbound RTP, and inbound and outbound RTCP).
202 Symmetric RTP [RFC4961] is the case in which there are two RTP
203 sessions that have their source and destination ports and addresses
204 reversed, in a manner similar to the way that a TCP connection uses
205 its ports. Each participant has an inbound RTP session and an
206 outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP
207 session can protect both of the RTP sessions. It is RECOMMENDED that
208 symmetric RTP be used with DTLS-SRTP.
210 RTP and RTCP traffic MAY be multiplexed on a single UDP port
211 [RFC5761]. In this case, both RTP and RTCP packets may be sent over
212 the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
213 needed. This improves the cryptographic performance of DTLS, but may
214 cause problems when RTCP and RTP are subject to different network
215 treatment (e.g., for bandwidth reservation or scheduling reasons).
217 Between a single pair of participants, there may be multiple media
218 sessions. There MUST be a separate DTLS-SRTP session for each
219 distinct pair of source and destination ports used by a media session
220 (though the sessions can share a single DTLS session and hence
221 amortize the initial public key handshake!).
226 McGrew & Rescorla Standards Track [Page 4]
227 \f
228 RFC 5764 SRTP Extension for DTLS May 2010
231 A DTLS-SRTP session may be indicated by an external signaling
232 protocol like SIP. When the signaling exchange is integrity-
233 protected (e.g., when SIP Identity protection via digital signatures
234 is used), DTLS-SRTP can leverage this integrity guarantee to provide
235 complete security of the media stream. A description of how to
236 indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to
237 authenticate the endpoints using fingerprints can be found in
238 [RFC5763].
240 In a naive implementation, when there are multiple media sessions,
241 there is a new DTLS session establishment (complete with public key
242 cryptography) for each media channel. For example, a videophone may
243 be sending both an audio stream and a video stream, each of which
244 would use a separate DTLS session establishment exchange, which would
245 proceed in parallel. As an optimization, the DTLS-SRTP
246 implementation SHOULD use the following strategy: a single DTLS
247 association is established, and all other DTLS associations wait
248 until that connection is established before proceeding with their
249 handshakes. This strategy allows the later sessions to use DTLS
250 session resumption, which allows the amortization of the expensive
251 public key cryptography operations over multiple DTLS handshakes.
253 The SRTP keys used to protect packets originated by the client are
254 distinct from the SRTP keys used to protect packets originated by the
255 server. All of the RTP sources originating on the client for the
256 same channel use the same SRTP keys, and similarly, all of the RTP
257 sources originating on the server for the same channel use the same
258 SRTP keys. The SRTP implementation MUST ensure that all of the
259 synchronization source (SSRC) values for all of the RTP sources
260 originating from the same device over the same channel are distinct,
261 in order to avoid the "two-time pad" problem (as described in Section
262 9.1 of RFC 3711). Note that this is not an issue for separate media
263 streams (on different host/port quartets) that use independent keying
264 material even if an SSRC collision occurs.
266 4. DTLS Extensions for SRTP Key Establishment
268 4.1. The use_srtp Extension
270 In order to negotiate the use of SRTP data protection, clients
271 include an extension of type "use_srtp" in the DTLS extended client
272 hello. This extension MUST only be used when the data being
273 transported is RTP or RTCP [RFC3550]. The "extension_data" field of
274 this extension contains the list of acceptable SRTP protection
275 profiles, as indicated below.
282 McGrew & Rescorla Standards Track [Page 5]
283 \f
284 RFC 5764 SRTP Extension for DTLS May 2010
287 Servers that receive an extended hello containing a "use_srtp"
288 extension can agree to use SRTP by including an extension of type
289 "use_srtp", with the chosen protection profile in the extended server
290 hello. This process is shown below.
292 Client Server
294 ClientHello + use_srtp -------->
295 ServerHello + use_srtp
296 Certificate*
297 ServerKeyExchange*
298 CertificateRequest*
299 <-------- ServerHelloDone
300 Certificate*
301 ClientKeyExchange
302 CertificateVerify*
303 [ChangeCipherSpec]
304 Finished -------->
305 [ChangeCipherSpec]
306 <-------- Finished
307 SRTP packets <-------> SRTP packets
309 Note that '*' indicates messages that are not always sent in DTLS.
310 The CertificateRequest, client and server Certificates, and
311 CertificateVerify will be sent in DTLS-SRTP.
313 Once the "use_srtp" extension is negotiated, the RTP or RTCP
314 application data is protected solely using SRTP. Application data is
315 never sent in DTLS record-layer "application_data" packets. Rather,
316 complete RTP or RTCP packets are passed to the DTLS stack, which
317 passes them to the SRTP stack, which protects them appropriately.
318 Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means
319 that RTP and RTCP packets may both be passed to the DTLS stack.
320 Because the DTLS layer does not process the packets, it does not need
321 to distinguish them. The SRTP stack can use the procedures of
322 [RFC5761] to distinguish RTP from RTCP.
324 When the "use_srtp" extension is in effect, implementations must not
325 place more than one application data "record" per datagram. (This is
326 only meaningful from the perspective of DTLS because SRTP is
327 inherently oriented towards one payload per packet, but this is
328 stated purely for clarification.)
330 Data other than RTP/RTCP (i.e., TLS control messages) MUST use
331 ordinary DTLS framing and MUST be placed in separate datagrams from
332 SRTP data.
338 McGrew & Rescorla Standards Track [Page 6]
339 \f
340 RFC 5764 SRTP Extension for DTLS May 2010
343 A DTLS-SRTP handshake establishes one or more SRTP crypto contexts;
344 however, they all have the same SRTP Protection Profile and Master
345 Key Identifier (MKI), if any. MKIs are used solely to distinguish
346 the keying material and protection profiles between distinct
347 handshakes, for instance, due to rekeying. When an MKI is
348 established in a DTLS-SRTP session, it MUST apply for all of the
349 SSRCs within that session -- though a single endpoint may negotiate
350 multiple DTLS-SRTP sessions due, for instance, to forking. (Note
351 that RFC 3711 allows packets within the same session but with
352 different SSRCs to use MKIs differently; in contrast, DTLS-SRTP
353 requires that MKIs and the keys that they are associated with have
354 the same meaning and are uniform across the entire SRTP session.)
356 4.1.1. use_srtp Extension Definition
358 The client MUST fill the extension_data field of the "use_srtp"
359 extension with an UseSRTPData value (see Section 9 for the
360 registration):
362 uint8 SRTPProtectionProfile[2];
364 struct {
365 SRTPProtectionProfiles SRTPProtectionProfiles;
366 opaque srtp_mki<0..255>;
367 } UseSRTPData;
369 SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
371 The SRTPProtectionProfiles list indicates the SRTP protection
372 profiles that the client is willing to support, listed in descending
373 order of preference. The srtp_mki value contains the SRTP Master Key
374 Identifier (MKI) value (if any) that the client will use for his SRTP
375 packets. If this field is of zero length, then no MKI will be used.
377 Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>"
378 indicates a variable-length value with a length between 0 and 255
379 (inclusive). Thus, the MKI may be up to 255 bytes long.
381 If the server is willing to accept the use_srtp extension, it MUST
382 respond with its own "use_srtp" extension in the ExtendedServerHello.
383 The extension_data field MUST contain a UseSRTPData value with a
384 single SRTPProtectionProfile value that the server has chosen for use
385 with this connection. The server MUST NOT select a value that the
386 client has not offered. If there is no shared profile, the server
387 SHOULD NOT return the use_srtp extension at which point the
388 connection falls back to the negotiated DTLS cipher suite. If that
389 is not acceptable, the server SHOULD return an appropriate DTLS
390 alert.
394 McGrew & Rescorla Standards Track [Page 7]
395 \f
396 RFC 5764 SRTP Extension for DTLS May 2010
399 4.1.2. SRTP Protection Profiles
401 A DTLS-SRTP SRTP Protection Profile defines the parameters and
402 options that are in effect for the SRTP processing. This document
403 defines the following SRTP protection profiles.
405 SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
406 SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
407 SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
408 SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};
410 The following list indicates the SRTP transform parameters for each
411 protection profile. The parameters cipher_key_length,
412 cipher_salt_length, auth_key_length, and auth_tag_length express the
413 number of bits in the values to which they refer. The
414 maximum_lifetime parameter indicates the maximum number of packets
415 that can be protected with each single set of keys when the parameter
416 profile is in use. All of these parameters apply to both RTP and
417 RTCP, unless the RTCP parameters are separately specified.
419 All of the crypto algorithms in these profiles are from [RFC3711].
421 SRTP_AES128_CM_HMAC_SHA1_80
422 cipher: AES_128_CM
423 cipher_key_length: 128
424 cipher_salt_length: 112
425 maximum_lifetime: 2^31
426 auth_function: HMAC-SHA1
427 auth_key_length: 160
428 auth_tag_length: 80
429 SRTP_AES128_CM_HMAC_SHA1_32
430 cipher: AES_128_CM
431 cipher_key_length: 128
432 cipher_salt_length: 112
433 maximum_lifetime: 2^31
434 auth_function: HMAC-SHA1
435 auth_key_length: 160
436 auth_tag_length: 32
437 RTCP auth_tag_length: 80
438 SRTP_NULL_HMAC_SHA1_80
439 cipher: NULL
440 cipher_key_length: 0
441 cipher_salt_length: 0
442 maximum_lifetime: 2^31
443 auth_function: HMAC-SHA1
444 auth_key_length: 160
445 auth_tag_length: 80
450 McGrew & Rescorla Standards Track [Page 8]
451 \f
452 RFC 5764 SRTP Extension for DTLS May 2010
455 SRTP_NULL_HMAC_SHA1_32
456 cipher: NULL
457 cipher_key_length: 0
458 cipher_salt_length: 0
459 maximum_lifetime: 2^31
460 auth_function: HMAC-SHA1
461 auth_key_length: 160
462 auth_tag_length: 32
463 RTCP auth_tag_length: 80
465 With all of these SRTP Parameter profiles, the following SRTP options
466 are in effect:
468 o The TLS PseudoRandom Function (PRF) is used to generate keys to
469 feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2
470 [DTLS1.2] is in use, the PRF is the one associated with the cipher
471 suite. Note that this specification is compatible with DTLS 1.0
472 or DTLS 1.2
474 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are
475 not re-derived based on the SRTP sequence number.
477 o The key derivation procedures from Section 4.3 with the AES-CM PRF
478 from RFC 3711 are used.
480 o For all other parameters (in particular, SRTP replay window size
481 and FEC order), the default values are used.
483 If values other than the defaults for these parameters are required,
484 they can be enabled by writing a separate specification specifying
485 SDP syntax to signal them.
487 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection
488 Profiles between the DTLS-SRTP session that protects an RTP flow and
489 the DTLS-SRTP session that protects the associated RTCP flow (in
490 those cases in which the RTP and RTCP are not multiplexed over a
491 common port). In particular, identical ciphers SHOULD be used.
493 New SRTPProtectionProfile values must be defined according to the
494 "Specification Required" policy as defined by RFC 5226 [RFC5226].
495 See Section 9 for IANA Considerations.
497 4.1.3. srtp_mki value
499 The srtp_mki value MAY be used to indicate the capability and desire
500 to use the SRTP Master Key Identifier (MKI) field in the SRTP and
501 SRTCP packets. The MKI field indicates to an SRTP receiver which key
502 was used to protect the packet that contains that field. The
506 McGrew & Rescorla Standards Track [Page 9]
507 \f
508 RFC 5764 SRTP Extension for DTLS May 2010
511 srtp_mki field contains the value of the SRTP MKI which is associated
512 with the SRTP master keys derived from this handshake. Each SRTP
513 session MUST have exactly one master key that is used to protect
514 packets at any given time. The client MUST choose the MKI value so
515 that it is distinct from the last MKI value that was used, and it
516 SHOULD make these values unique for the duration of the TLS session.
518 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,
519 the server MUST either (assuming it accepts the extension at all):
521 1. include a matching "srtp_mki" value in its "use_srtp" extension
522 to indicate that it will make use of the MKI, or
523 2. return an empty "srtp_mki" value to indicate that it cannot make
524 use of the MKI.
526 If the client detects a nonzero-length MKI in the server's response
527 that is different than the one the client offered, then the client
528 MUST abort the handshake and SHOULD send an invalid_parameter alert.
529 If the client and server agree on an MKI, all SRTP packets protected
530 under the new security parameters MUST contain that MKI.
532 Note that any given DTLS-SRTP session only has a single active MKI
533 (if any). Thus, at any given time, a set of endpoints will generally
534 only be using one MKI (the major exception is during rehandshakes).
536 4.2. Key Derivation
538 When SRTP mode is in effect, different keys are used for ordinary
539 DTLS record protection and SRTP packet protection. These keys are
540 generated using a TLS exporter [RFC5705] to generate
542 2 * (SRTPSecurityParams.master_key_len +
543 SRTPSecurityParams.master_salt_len) bytes of data
545 which are assigned as shown below. The per-association context value
546 is empty.
548 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
549 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
550 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
551 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
553 The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The
554 "EXTRACTOR" prefix is for historical compatibility.)
556 The four keying material values (the master key and master salt for
557 each direction) are provided as inputs to the SRTP key derivation
558 mechanism, as shown in Figure 1 and detailed below. By default, the
562 McGrew & Rescorla Standards Track [Page 10]
563 \f
564 RFC 5764 SRTP Extension for DTLS May 2010
567 mechanism defined in Section 4.3 of [RFC3711] is used, unless another
568 key derivation mechanism is specified as part of an SRTP Protection
569 Profile.
571 The client_write_SRTP_master_key and client_write_SRTP_master_salt
572 are provided to one invocation of the SRTP key derivation function,
573 to generate the SRTP keys used to encrypt and authenticate packets
574 sent by the client. The server MUST only use these keys to decrypt
575 and to check the authenticity of inbound packets.
577 The server_write_SRTP_master_key and server_write_SRTP_master_salt
578 are provided to one invocation of the SRTP key derivation function,
579 to generate the SRTP keys used to encrypt and authenticate packets
580 sent by the server. The client MUST only use these keys to decrypt
581 and to check the authenticity of inbound packets.
583 TLS master
584 secret label
585 | |
586 v v
587 +---------------+
588 | TLS extractor |
589 +---------------+
590 | +------+ SRTP
591 +-> client_write_SRTP_master_key ----+--->| SRTP |-> client
592 | | +->| KDF | write
593 | | | +------+ keys
594 | | |
595 +-> server_write_SRTP_master_key -- | | +------+ SRTCP
596 | \ \--->|SRTCP |-> client
597 | \ +->| KDF | write
598 | | | +------+ keys
599 +-> client_write_SRTP_master_salt ---|-+
600 | |
601 | | +------+ SRTP
602 | +--->| SRTP |-> server
603 +-> server_write_SRTP_master_salt -+-|--->| KDF | write
604 | | +------+ keys
605 | |
606 | | +------+ SRTCP
607 | +--->|SRTCP |-> server
608 +----->| KDF | write
609 +------+ keys
611 Figure 1: The derivation of the SRTP keys.
618 McGrew & Rescorla Standards Track [Page 11]
619 \f
620 RFC 5764 SRTP Extension for DTLS May 2010
623 When both RTCP and RTP use the same source and destination ports,
624 then both the SRTP and SRTCP keys are needed. Otherwise, there are
625 two DTLS-SRTP sessions, one of which protects the RTP packets and one
626 of which protects the RTCP packets; each DTLS-SRTP session protects
627 the part of an SRTP session that passes over a single source/
628 destination transport address pair, as shown in Figure 2, independent
629 of which SSRCs are used on that pair. When a DTLS-SRTP session is
630 protecting RTP, the SRTCP keys derived from the DTLS handshake are
631 not needed and are discarded. When a DTLS-SRTP session is protecting
632 RTCP, the SRTP keys derived from the DTLS handshake are not needed
633 and are discarded.
635 Client Server
636 (Sender) (Receiver)
637 (1) <----- DTLS ------> src/dst = a/b and b/a
638 ------ SRTP ------> src/dst = a/b, uses client write keys
640 (2) <----- DTLS ------> src/dst = c/d and d/c
641 ------ SRTCP -----> src/dst = c/d, uses client write keys
642 <----- SRTCP ------ src/dst = d/c, uses server write keys
644 Figure 2: A DTLS-SRTP session protecting RTP (1) and another one
645 protecting RTCP (2), showing the transport addresses and keys used.
647 4.3. Key Scope
649 Because of the possibility of packet reordering, DTLS-SRTP
650 implementations SHOULD store multiple SRTP keys sets during a rekey
651 in order to avoid the need for receivers to drop packets for which
652 they lack a key.
654 4.4. Key Usage Limitations
656 The maximum_lifetime parameter in the SRTP protection profile
657 indicates the maximum number of packets that can be protected with
658 each single encryption and authentication key. (Note that, since RTP
659 and RTCP are protected with independent keys, those protocols are
660 counted separately for the purposes of determining when a key has
661 reached the end of its lifetime.) Each profile defines its own
662 limit. When this limit is reached, a new DTLS session SHOULD be used
663 to establish replacement keys, and SRTP implementations MUST NOT use
664 the existing keys for the processing of either outbound or inbound
665 traffic.
674 McGrew & Rescorla Standards Track [Page 12]
675 \f
676 RFC 5764 SRTP Extension for DTLS May 2010
679 5. Use of RTP and RTCP over a DTLS-SRTP Channel
681 5.1. Data Protection
683 Once the DTLS handshake has completed, the peers can send RTP or RTCP
684 over the newly created channel. We describe the transmission process
685 first followed by the reception process.
687 Within each RTP session, SRTP processing MUST NOT take place before
688 the DTLS handshake completes.
690 5.1.1. Transmission
692 DTLS and TLS define a number of record content types. In ordinary
693 TLS/DTLS, all data is protected using the same record encoding and
694 mechanisms. When the mechanism described in this document is in
695 effect, this is modified so that data written by upper-level protocol
696 clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
697 rather than the standard TLS record encoding.
699 When a user of DTLS wishes to send an RTP packet in SRTP mode, it
700 delivers it to the DTLS implementation as an ordinary application
701 data write (e.g., SSL_write()). The DTLS implementation then invokes
702 the processing described in RFC 3711, Sections 3 and 4. The
703 resulting SRTP packet is then sent directly on the wire as a single
704 datagram with no DTLS framing. This provides an encapsulation of the
705 data that conforms to and interoperates with SRTP. Note that the RTP
706 sequence number rather than the DTLS sequence number is used for
707 these packets.
709 5.1.2. Reception
711 When DTLS-SRTP is used to protect an RTP session, the RTP receiver
712 needs to demultiplex packets that are arriving on the RTP port.
713 Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If
714 these are the only types of packets present, the type of a packet can
715 be determined by looking at its first byte.
717 The process for demultiplexing a packet is as follows. The receiver
718 looks at the first byte of the packet. If the value of this byte is
719 0 or 1, then the packet is STUN. If the value is in between 128 and
720 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
721 RTP are being multiplexed over the same destination port). If the
722 value is between 20 and 63 (inclusive), the packet is DTLS. This
723 process is summarized in Figure 3.
730 McGrew & Rescorla Standards Track [Page 13]
731 \f
732 RFC 5764 SRTP Extension for DTLS May 2010
735 +----------------+
736 | 127 < B < 192 -+--> forward to RTP
737 | |
738 packet --> | 19 < B < 64 -+--> forward to DTLS
739 | |
740 | B < 2 -+--> forward to STUN
741 +----------------+
743 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
744 Here the field B denotes the leading byte of the packet.
746 If other packet types are to be multiplexed as well, implementors
747 and/or designers SHOULD ensure that they can be demultiplexed from
748 these three packet types.
750 In some cases, there will be multiple DTLS-SRTP associations for a
751 given SRTP endpoint. For instance, if Alice makes a call that is SIP
752 forked to both Bob and Charlie, she will use the same local host/port
753 pair for both of them, as shown in Figure 4, where XXX and YYY
754 represent different DTLS-SRTP associations. (The SSRCs shown are the
755 ones for data flowing to Alice.)
757 Bob (192.0.2.1:6666)
758 /
759 /
760 / SSRC=1
761 / DTLS-SRTP=XXX
762 /
763 v
764 Alice (192.0.2.0:5555)
765 ^
766 \
767 \ SSRC=2
768 \ DTLS-SRTP=YYY
769 \
770 \
771 Charlie (192.0.2.2:6666)
773 Figure 4: RTP sessions with SIP forking.
775 Because DTLS operates on the host/port quartet, the DTLS association
776 will still complete correctly, with the foreign host/port pair being
777 used, to distinguish the associations. However, in RTP the source
778 host/port is not used and sessions are identified by the destination
779 host/port and the SSRC. Thus, some mechanism is needed to determine
780 which SSRCs correspond to which DTLS associations. The following
781 method SHOULD be used.
786 McGrew & Rescorla Standards Track [Page 14]
787 \f
788 RFC 5764 SRTP Extension for DTLS May 2010
791 For each local host/port pair, the DTLS-SRTP implementation maintains
792 a table listing all the SSRCs it knows about and the DTLS-SRTP
793 associations they correspond to. Initially, this table is empty.
794 When an SRTP packet is received for a given RTP endpoint (destination
795 IP/port pair), the following procedure is used:
797 1. If the SSRC is already known for that endpoint, then the
798 corresponding DTLS-SRTP association and its keying material is
799 used to decrypt and verify the packet.
800 2. If the SSRC is not known, then the receiver tries to decrypt it
801 with the keying material corresponding to each DTLS-SRTP
802 association for that endpoint.
803 3. If the decryption and verification succeeds (the authentication
804 tag verifies), then an entry is placed in the table mapping the
805 SSRC to that association.
806 4. If the decryption and verification fails, then the packet is
807 silently discarded.
808 5. When a DTLS-SRTP association is closed (for instance, because the
809 fork is abandoned), its entries MUST be removed from the mapping
810 table.
812 The average cost of this algorithm for a single SSRC is the
813 decryption and verification time of a single packet times the number
814 of valid DTLS-SRTP associations corresponding to a single receiving
815 port on the host. In practice, this means the number of forks; so in
816 the case shown in Figure 4, that would be two. This cost is only
817 incurred once for any given SSRC, since afterwards that SSRC is
818 placed in the map table and looked up immediately. As with normal
819 RTP, this algorithm allows new SSRCs to be introduced by the source
820 at any time. They will automatically be mapped to the correct DTLS
821 association.
823 Note that this algorithm explicitly allows multiple SSRCs to be sent
824 from the same address/port pair. One way in which this can happen is
825 an RTP translator. This algorithm will automatically assign the
826 SSRCs to the correct associations. Note that because the SRTP
827 packets are cryptographically protected, such a translator must
828 either share keying material with one endpoint or refrain from
829 modifying the packets in a way which would cause the integrity check
830 to fail. This is a general property of SRTP and is not specific to
831 DTLS-SRTP.
833 There are two error cases that should be considered. First, if an
834 SSRC collision occurs, then only the packets from the first source
835 will be processed. When the packets from the second source arrive,
836 the DTLS association with the first source will be used for
837 decryption and verification, which will fail, and the packet will be
838 discarded. This is consistent with [RFC3550], which permits the
842 McGrew & Rescorla Standards Track [Page 15]
843 \f
844 RFC 5764 SRTP Extension for DTLS May 2010
847 receiver to keep the packets from one source and discard those from
848 the other. Of course the RFC 3550 SSRC collision detection and
849 handling procedures MUST also be followed.
851 Second, there may be cases where a malfunctioning source is sending
852 corrupt packets that cannot be decrypted and verified. In this case,
853 the SSRC will never be entered into the mapping table because the
854 decryption and verification always fails. Receivers MAY keep records
855 of unmapped SSRCs that consistently fail decryption and verification
856 and abandon attempts to process them once they reach some limit.
857 That limit MUST be large enough to account for the effects of
858 transmission errors. Entries MUST be pruned from this table when the
859 relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD
860 time out faster than that (we do not offer a hard recommendation but
861 10 to 30 seconds seems appropriate) in order to allow for the
862 possibility that the peer implementation has been corrected.
864 5.2. Rehandshake and Rekey
866 Rekeying in DTLS is accomplished by performing a new handshake over
867 the existing DTLS channel. That is, the handshake messages are
868 protected by the existing DTLS cipher suite. This handshake can be
869 performed in parallel with data transport, so no interruption of the
870 data flow is required. Once the handshake is finished, the newly
871 derived set of keys is used to protect all outbound packets, both
872 DTLS and SRTP.
874 Because of packet reordering, packets protected by the previous set
875 of keys can appear on the wire after the handshake has completed. To
876 compensate for this fact, receivers SHOULD maintain both sets of keys
877 for some time in order to be able to decrypt and verify older
878 packets. The keys should be maintained for the duration of the
879 maximum segment lifetime (MSL).
881 If an MKI is used, then the receiver should use the corresponding set
882 of keys to process an incoming packet. If no matching MKI is
883 present, the packet MUST be rejected. Otherwise, when a packet
884 arrives after the handshake completed, a receiver SHOULD use the
885 newly derived set of keys to process that packet unless there is an
886 MKI. (If the packet was protected with the older set of keys, this
887 fact will become apparent to the receiver as an authentication
888 failure will occur.) If the authentication check on the packet fails
889 and no MKI is being used, then the receiver MAY process the packet
890 with the older set of keys. If that authentication check indicates
891 that the packet is valid, the packet should be accepted; otherwise,
892 the packet MUST be discarded and rejected.
898 McGrew & Rescorla Standards Track [Page 16]
899 \f
900 RFC 5764 SRTP Extension for DTLS May 2010
903 Receivers MAY use the SRTP packet sequence number to aid in the
904 selection of keys. After a packet has been received and
905 authenticated with the new key set, any packets with sequence numbers
906 that are greater will also have been protected with the new key set.
908 6. Multi-Party RTP Sessions
910 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only
911 to protect unicast RTP sessions. This does not preclude its use with
912 RTP mixers. For example, a conference bridge may use DTLS-SRTP to
913 secure the communication to and from each of the participants in a
914 conference. However, because each flow between an endpoint and a
915 mixer has its own key, the mixer has to decrypt and then reencrypt
916 the traffic for each recipient.
918 A future specification may describe methods for sharing a single key
919 between multiple DTLS-SRTP associations thus allowing conferencing
920 systems to avoid the decrypt/reencrypt stage. However, any system in
921 which the media is modified (e.g., for level balancing or
922 transcoding) will generally need to be performed on the plaintext and
923 will certainly break the authentication tag, and therefore will
924 require a decrypt/reencrypt stage.
926 7. Security Considerations
928 The use of multiple data protection framings negotiated in the same
929 handshake creates some complexities, which are discussed here.
931 7.1. Security of Negotiation
933 One concern here is that attackers might be able to implement a bid-
934 down attack forcing the peers to use ordinary DTLS rather than SRTP.
935 However, because the negotiation of this extension is performed in
936 the DTLS handshake, it is protected by the Finished messages.
937 Therefore, any bid-down attack is automatically detected, which
938 reduces this to a denial-of-service attack -- which can be mounted by
939 any attacker who can control the channel.
941 7.2. Framing Confusion
943 Because two different framing formats are used, there is concern that
944 an attacker could convince the receiver to treat an SRTP-framed RTP
945 packet as a DTLS record (e.g., a handshake message) or vice versa.
946 This attack is prevented by using different keys for Message
947 Authentication Code (MAC) verification for each type of data.
948 Therefore, this type of attack reduces to being able to forge a
949 packet with a valid MAC, which violates a basic security invariant of
950 both DTLS and SRTP.
954 McGrew & Rescorla Standards Track [Page 17]
955 \f
956 RFC 5764 SRTP Extension for DTLS May 2010
959 As an additional defense against injection into the DTLS handshake
960 channel, the DTLS record type is included in the MAC. Therefore, an
961 SRTP record would be treated as an unknown type and ignored. (See
962 Section 6 of [RFC5246].)
964 7.3. Sequence Number Interactions
966 As described in Section 5.1.1, the SRTP and DTLS sequence number
967 spaces are distinct. This means that it is not possible to
968 unambiguously order a given DTLS control record with respect to an
969 SRTP packet. In general, this is relevant in two situations: alerts
970 and rehandshake.
972 7.3.1. Alerts
974 Because DTLS handshake and change_cipher_spec messages share the same
975 sequence number space as alerts, they can be ordered correctly.
976 Because DTLS alerts are inherently unreliable and SHOULD NOT be
977 generated as a response to data packets, reliable sequencing between
978 SRTP packets and DTLS alerts is not an important feature. However,
979 implementations that wish to use DTLS alerts to signal problems with
980 the SRTP encoding SHOULD simply act on alerts as soon as they are
981 received and assume that they refer to the temporally contiguous
982 stream. Such implementations MUST check for alert retransmission and
983 discard retransmitted alerts to avoid overreacting to replay attacks.
985 7.3.2. Renegotiation
987 Because the rehandshake transition algorithm specified in Section 5.2
988 requires trying multiple sets of keys if no MKI is used, it slightly
989 weakens the authentication. For instance, if an n-bit MAC is used
990 and k different sets of keys are present, then the MAC is weakened by
991 log_2(k) bits to n - log_2(k). In practice, since the number of keys
992 used will be very small and the MACs in use are typically strong (the
993 default for SRTP is 80 bits), the decrease in security involved here
994 is minimal.
996 Another concern here is that this algorithm slightly increases the
997 work factor on the receiver because it needs to attempt multiple
998 validations. However, again, the number of potential keys will be
999 very small (and the attacker cannot force it to be larger) and this
1000 technique is already used for rollover counter management, so the
1001 authors do not consider this to be a serious flaw.
1010 McGrew & Rescorla Standards Track [Page 18]
1011 \f
1012 RFC 5764 SRTP Extension for DTLS May 2010
1015 7.4. Decryption Cost
1017 An attacker can impose computational costs on the receiver by sending
1018 superficially valid SRTP packets that do not decrypt correctly. In
1019 general, encryption algorithms are so fast that this cost is
1020 extremely small compared to the bandwidth consumed. The SSRC-DTLS
1021 mapping algorithm described in Section 5.1.2 gives the attacker a
1022 slight advantage here because he can force the receiver to do more
1023 then one decryption per packet. However, this advantage is modest
1024 because the number of decryptions that the receiver does is limited
1025 by the number of associations he has corresponding to a given
1026 destination host/port, which is typically quite small. For
1027 comparison, a single 1024-bit RSA private key operation (the typical
1028 minimum cost to establish a DTLS-SRTP association) is hundreds of
1029 times as expensive as decrypting an SRTP packet.
1031 Implementations can detect this form of attack by keeping track of
1032 the number of SRTP packets that are observed with unknown SSRCs and
1033 that fail the authentication tag check. If under such attack,
1034 implementations SHOULD prioritize decryption and verification of
1035 packets that either have known SSRCs or come from source addresses
1036 that match those of peers with which it has DTLS-SRTP associations.
1038 8. Session Description for RTP/SAVP over DTLS
1040 This specification defines new tokens to describe the protocol used
1041 in SDP media descriptions ("m=" lines and their associated
1042 parameters). The new values defined for the proto field are:
1044 o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
1045 DTLS with the Datagram Congestion Control Protocol (DCCP), then
1046 the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
1047 respectively.
1049 o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
1050 UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
1051 respectively.
1053 The "fmt" parameter SHALL be as defined for RTP/SAVP.
1055 See [RFC5763] for how to use offer/answer with DTLS-SRTP.
1057 This document does not specify how to protect RTP data transported
1058 over TCP. Potential approaches include carrying the RTP over TLS
1059 over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that
1060 in this document over TCP, either via TLS or DTLS, with DTLS being
1061 used for consistency between reliable and unreliable transports. In
1066 McGrew & Rescorla Standards Track [Page 19]
1067 \f
1068 RFC 5764 SRTP Extension for DTLS May 2010
1071 the latter case, it would be necessary to profile DTLS so that
1072 fragmentation and retransmissions no longer occurred. In either
1073 case, a new document would be required.
1075 9. IANA Considerations
1077 This document adds a new extension for DTLS, in accordance with
1078 [RFC5246]:
1079 enum { use_srtp (14) } ExtensionType;
1081 This extension MUST only be used with DTLS, and not with TLS
1082 [RFC4572], which specifies that TLS can be used over TCP but does not
1083 address TCP for RTP/SAVP.
1085 Section 4.1.2 requires that all SRTPProtectionProfile values be
1086 defined by RFC 5226 "Specification Required". IANA has created a
1087 DTLS SRTPProtectionProfile registry initially populated with values
1088 from Section 4.1.2 of this document. Future values MUST be allocated
1089 via the "Specification Required" profile of [RFC5226].
1091 This specification updates the "Session Description Protocol (SDP)
1092 Parameters" registry as defined in Section 8.2.2 of [RFC4566].
1093 Specifically, it adds the following values to the table for the
1094 "proto" field.
1096 Type SDP Name Reference
1097 ---- ------------------ ---------
1098 proto UDP/TLS/RTP/SAVP [RFC5764]
1099 proto DCCP/TLS/RTP/SAVP [RFC5764]
1101 proto UDP/TLS/RTP/SAVPF [RFC5764]
1102 proto DCCP/TLS/RTP/SAVPF [RFC5764]
1104 IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS
1105 Extractor Label Registry to correspond to this specification.
1107 10. Acknowledgments
1109 Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen,
1110 Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing,
1111 and Ben Campbell for input, discussions, and guidance. Pasi Eronen
1112 provided Figure 1.
1122 McGrew & Rescorla Standards Track [Page 20]
1123 \f
1124 RFC 5764 SRTP Extension for DTLS May 2010
1127 11. References
1129 11.1. Normative References
1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1132 Requirement Levels", BCP 14, RFC 2119, March 1997.
1134 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
1135 and K. Norrman, "The Secure Real-time Transport
1136 Protocol (SRTP)", RFC 3711, March 2004.
1138 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
1139 Layer Security", RFC 4347, April 2006.
1141 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
1142 (RTCP)", BCP 131, RFC 4961, July 2007.
1144 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
1145 Security (TLS) Protocol Version 1.2", RFC 5246,
1146 August 2008.
1148 [RFC5705] Rescorla, E., "Keying Material Exporters for
1149 Transport Layer Security (TLS)", RFC 5705,
1150 March 2010.
1152 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP
1153 Data and Control Packets on a Single Port",
1154 RFC 5761, April 2010.
1156 11.2. Informative References
1158 [DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport
1159 Layer Security version 1.2", Work in Progress,
1160 October 2009.
1162 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
1163 Jacobson, "RTP: A Transport Protocol for Real-Time
1164 Applications", STD 64, RFC 3550, July 2003.
1166 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
1167 Session Description Protocol", RFC 4566, July 2006.
1169 [RFC4572] Lennox, J., "Connection-Oriented Media Transport
1170 over the Transport Layer Security (TLS) Protocol in
1171 the Session Description Protocol (SDP)", RFC 4572,
1172 July 2006.
1178 McGrew & Rescorla Standards Track [Page 21]
1179 \f
1180 RFC 5764 SRTP Extension for DTLS May 2010
1183 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile
1184 for Real-time Transport Control Protocol (RTCP)-
1185 Based Feedback (RTP/SAVPF)", RFC 5124,
1186 February 2008.
1188 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
1189 Writing an IANA Considerations Section in RFCs",
1190 BCP 26, RFC 5226, May 2008.
1192 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
1193 "Session Traversal Utilities for NAT (STUN)",
1194 RFC 5389, October 2008.
1196 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla,
1197 "Framework for Establishing a Secure Real-time
1198 Transport Protocol (SRTP) Security Context Using
1199 Datagram Transport Layer Security (DTLS)", RFC 5763,
1200 May 2010.
1202 [SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not
1203 Mandate a Single Security Mechanism", Work in
1204 Progress, January 2010.
1234 McGrew & Rescorla Standards Track [Page 22]
1235 \f
1236 RFC 5764 SRTP Extension for DTLS May 2010
1239 Appendix A. Overview of DTLS
1241 This section provides a brief overview of Datagram TLS (DTLS) for
1242 those who are not familiar with it. DTLS is a channel security
1243 protocol based on the well-known Transport Layer Security (TLS)
1244 [RFC5246] protocol. Where TLS depends on a reliable transport
1245 channel (typically TCP), DTLS has been adapted to support unreliable
1246 transports such as UDP. Otherwise, DTLS is nearly identical to TLS
1247 and generally supports the same cryptographic mechanisms.
1249 Each DTLS association begins with a handshake exchange (shown below)
1250 during which the peers authenticate each other and negotiate
1251 algorithms, modes, and other parameters and establish shared keying
1252 material, as shown below. In order to support unreliable transport,
1253 each side maintains retransmission timers to provide reliable
1254 delivery of these messages. Once the handshake is completed,
1255 encrypted data may be sent.
1257 Client Server
1259 ClientHello -------->
1260 ServerHello
1261 Certificate*
1262 ServerKeyExchange*
1263 CertificateRequest*
1264 <-------- ServerHelloDone
1265 Certificate*
1266 ClientKeyExchange
1267 CertificateVerify*
1268 [ChangeCipherSpec]
1269 Finished -------->
1270 [ChangeCipherSpec]
1271 <-------- Finished
1272 Application Data <-------> Application Data
1274 '*' indicates messages that are not always sent.
1276 Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).
1278 Application data is protected by being sent as a series of DTLS
1279 "records". These records are independent and can be processed
1280 correctly even in the face of loss or reordering. In DTLS-SRTP, this
1281 record protocol is replaced with SRTP [RFC3711]
1290 McGrew & Rescorla Standards Track [Page 23]
1291 \f
1292 RFC 5764 SRTP Extension for DTLS May 2010
1295 Appendix B. Performance of Multiple DTLS Handshakes
1297 Standard practice for security protocols such as TLS, DTLS, and SSH,
1298 which do inline key management, is to create a separate security
1299 association for each underlying network channel (TCP connection, UDP
1300 host/port quartet, etc.). This has dual advantages of simplicity and
1301 independence of the security contexts for each channel.
1303 Three concerns have been raised about the overhead of this strategy
1304 in the context of RTP security. The first concern is the additional
1305 performance overhead of doing a separate public key operation for
1306 each channel. The conventional procedure here (used in TLS and DTLS)
1307 is to establish a master context that can then be used to derive
1308 fresh traffic keys for new associations. In TLS/DTLS, this is called
1309 "session resumption" and can be transparently negotiated between the
1310 peers.
1312 The second concern is network bandwidth overhead for the
1313 establishment of subsequent connections and for rehandshake (for
1314 rekeying) for existing connections. In particular, there is a
1315 concern that the channels will have very narrow capacity requirements
1316 allocated entirely to media that will be overflowed by the
1317 rehandshake. Measurements of the size of the rehandshake (with
1318 resumption) in TLS indicate that it is about 300-400 bytes if a full
1319 selection of cipher suites is offered. (The size of a full handshake
1320 is approximately 1-2 kilobytes larger because of the certificate and
1321 keying material exchange.)
1323 The third concern is the additional round-trips associated with
1324 establishing the second, third, ... channels. In TLS/DTLS, these can
1325 all be done in parallel, but in order to take advantage of session
1326 resumption they should be done after the first channel is
1327 established. For two channels, this provides a ladder diagram
1328 something like this (parenthetical numbers are media channel numbers)
1346 McGrew & Rescorla Standards Track [Page 24]
1347 \f
1348 RFC 5764 SRTP Extension for DTLS May 2010
1351 Alice Bob
1352 -------------------------------------------
1353 <- ClientHello (1)
1354 ServerHello (1) ->
1355 Certificate (1)
1356 ServerHelloDone (1)
1357 <- ClientKeyExchange (1)
1358 ChangeCipherSpec (1)
1359 Finished (1)
1360 ChangeCipherSpec (1)->
1361 Finished (1)->
1362 <--- Channel 1 ready
1364 <- ClientHello (2)
1365 ServerHello (2) ->
1366 ChangeCipherSpec(2)->
1367 Finished(2) ->
1368 <- ChangeCipherSpec (2)
1369 Finished (2)
1370 <--- Channel 2 ready
1372 Figure 6: Parallel DTLS-SRTP negotiations.
1374 So, there is an additional 1 RTT (round-trip time) after Channel 1 is
1375 ready before Channel 2 is ready. If the peers are potentially
1376 willing to forego resumption, they can interlace the handshakes, like
1377 so:
1402 McGrew & Rescorla Standards Track [Page 25]
1403 \f
1404 RFC 5764 SRTP Extension for DTLS May 2010
1407 Alice Bob
1408 -------------------------------------------
1409 <- ClientHello (1)
1410 ServerHello (1) ->
1411 Certificate (1)
1412 ServerHelloDone (1)
1413 <- ClientKeyExchange (1)
1414 ChangeCipherSpec (1)
1415 Finished (1)
1416 <- ClientHello (2)
1417 ChangeCipherSpec (1)->
1418 Finished (1)->
1419 <--- Channel 1 ready
1420 ServerHello (2) ->
1421 ChangeCipherSpec(2)->
1422 Finished(2) ->
1423 <- ChangeCipherSpec (2)
1424 Finished (2)
1425 <--- Channel 2 ready
1427 Figure 7: Interlaced DTLS-SRTP negotiations.
1429 In this case, the channels are ready contemporaneously, but if a
1430 message in handshake (1) is lost, then handshake (2) requires either
1431 a full rehandshake or that Alice be clever and queue the resumption
1432 attempt until the first handshake completes. Note that just dropping
1433 the packet works as well, since Bob will retransmit.
1435 Authors' Addresses
1437 David McGrew
1438 Cisco Systems
1439 510 McCarthy Blvd.
1440 Milpitas, CA 95305
1441 USA
1443 EMail: mcgrew@cisco.com
1446 Eric Rescorla
1447 RTFM, Inc.
1448 2064 Edgewood Drive
1449 Palo Alto, CA 94303
1450 USA
1452 EMail: ekr@rtfm.com
1458 McGrew & Rescorla Standards Track [Page 26]
1459 \f