idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 17, 2018) is 2015 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ack' is mentioned on line 675, but not defined == Missing Reference: 'EKTKey' is mentioned on line 673, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-09 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-07 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-28 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Mattsson 5 Expires: April 20, 2019 Ericsson AB 6 D. McGrew 7 Cisco Systems 8 D. Wing 10 F. Andreason 11 Cisco Systems 12 October 17, 2018 14 Encrypted Key Transport for DTLS and Secure RTP 15 draft-ietf-perc-srtp-ekt-diet-09 17 Abstract 19 Encrypted Key Transport (EKT) is an extension to DTLS (Datagram 20 Transport Layer Security) and Secure Real-time Transport Protocol 21 (SRTP) that provides for the secure transport of SRTP master keys, 22 rollover counters, and other information within SRTP. This facility 23 enables SRTP for decentralized conferences by distributing a common 24 key to all of the conference endpoints. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Conventions Used In This Document . . . . . . . . . . . . . . 4 63 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 64 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Packet Processing and State Machine . . . . . . . . . . . 7 66 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 67 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 68 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 69 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 72 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 73 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.7. Timing and Reliability Consideration . . . . . . . . . . 13 75 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 76 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 77 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 78 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 16 79 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16 80 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 81 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 20 85 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 86 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21 87 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 91 9.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 Real-time Transport Protocol (RTP) is designed to allow decentralized 97 groups with minimal control to establish sessions, such as for 98 multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) 99 cannot be used in many minimal-control scenarios, because it requires 100 that synchronization source (SSRC) values and other data be 101 coordinated among all of the participants in a session. For example, 102 if a participant joins a session that is already in progress, that 103 participant needs to be told the SRTP keys along with the SSRC, 104 rollover counter (ROC) and other details of the other SRTP sources. 106 The inability of SRTP to work in the absence of central control was 107 well understood during the design of the protocol; the omission was 108 considered less important than optimizations such as bandwidth 109 conservation. Additionally, in many situations SRTP is used in 110 conjunction with a signaling system that can provide the central 111 control needed by SRTP. However, there are several cases in which 112 conventional signaling systems cannot easily provide all of the 113 coordination required. It is also desirable to eliminate the layer 114 violations that occur when signaling systems coordinate certain SRTP 115 parameters, such as SSRC values and ROCs. 117 This document defines Encrypted Key Transport (EKT) for SRTP and 118 reduces the amount of external signaling control that is needed in a 119 SRTP session with multiple receivers. EKT securely distributes the 120 SRTP master key and other information for each SRTP source. With 121 this method, SRTP entities are free to choose SSRC values as they see 122 fit, and to start up new SRTP sources with new SRTP master keys 123 within a session without coordinating with other entities via 124 external signaling or other external means. 126 EKT provides a way for an SRTP session participant, to securely 127 transport its SRTP master key and current SRTP rollover counter to 128 the other participants in the session. This data furnishes the 129 information needed by the receiver to instantiate an SRTP/SRTCP 130 receiver context. 132 EKT can be used in conferences where the central media distributor or 133 conference bridge cannot decrypt the media, such as the type defined 134 for [I-D.ietf-perc-private-media-framework]. It can also be used for 135 large scale conferences where the conference bridge or media 136 distributor can decrypt all the media but wishes to encrypt the media 137 it is sending just once and then send the same encrypted media to a 138 large number of participants. This reduces the amount of CPU time 139 needed for encryption and can be used for some optimization to media 140 sending that use source specific multicast. 142 EKT does not control the manner in which the SSRC is generated; it is 143 only concerned with their secure transport. 145 EKT is not intended to replace external key establishment mechanisms. 146 Instead, it is used in conjunction with those methods, and it 147 relieves those methods of the burden to deliver the context for each 148 SRTP source to every SRTP participant. 150 2. Overview 152 This specification defines a way for the server in a DTLS-SRTP 153 negotiation, see Section 5, to provide an EKTKey to the client during 154 the DTLS handshake. The EKTKey thus obtained can be used to encrypt 155 the SRTP master key that is used to encrypt the media sent by the 156 endpoint. This specification also defines a way to send the 157 encrypted SRTP master key (with the EKTKey) along with the SRTP 158 packet, see Section 4. Endpoints that receive this and know the 159 EKTKey can use the EKTKey to decrypt the SRTP master key which can 160 then be used to decrypt the SRTP packet. 162 One way to use this is described in the architecture defined by 163 [I-D.ietf-perc-private-media-framework]. Each participant in the 164 conference forms a DTLS-SRTP connection to a common key distributor 165 that distributes the same EKTKey to all the endpoints. Then each 166 endpoint picks its own SRTP master key for the media they send. When 167 sending media, the endpoint also includes the SRTP master key 168 encrypted with the EKTKey in the SRTP packet. This allows all the 169 endpoints to decrypt the media. 171 3. Conventions Used In This Document 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 4. Encrypted Key Transport 181 EKT defines a new method of providing SRTP master keys to an 182 endpoint. In order to convey the ciphertext corresponding to the 183 SRTP master key, and other additional information, an additional 184 field, called EKTField, is added to the SRTP packets. The EKTField 185 appears at the end of the SRTP packet. It appears after the optional 186 authentication tag if one is present, otherwise the EKTField appears 187 after the ciphertext portion of the packet. 189 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 190 Identifier) or with SRTP's [RFC3711], as those SRTP 191 features duplicate some of the functions of EKT. Senders MUST NOT 192 include MKI when using EKT. Receivers SHOULD simply ignore any MKI 193 field received if EKT is in use. 195 4.1. EKTField Formats 197 The EKTField uses the format defined in Figure 1 for the FullEKTField 198 and ShortEKTField. 200 0 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 : : 204 : EKT Ciphertext : 205 : : 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Security Parameter Index | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |0 0 0 0 0 0 1 0| 210 +-+-+-+-+-+-+-+-+ 212 Figure 1: FullEKTField format 214 0 1 2 3 4 5 6 7 215 +-+-+-+-+-+-+-+-+ 216 |0 0 0 0 0 0 0 0| 217 +-+-+-+-+-+-+-+-+ 219 Figure 2: ShortEKTField format 221 The following shows the syntax of the EKTField expressed in ABNF 222 [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP 223 packet. The EKTPlaintext is the concatenation of 224 SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The 225 EKTCiphertext is computed by encrypting the EKTPlaintext using the 226 EKTKey. Future extensions to the EKTField MUST conform to the syntax 227 of ExtensionEKTField. 229 BYTE = %x00-FF 231 EKTMsgTypeFull = %x02 232 EKTMsgTypeShort = %x00 233 EKTMsgTypeExtension = %x03-FF 235 EKTMsgLength = 2BYTE; 237 SRTPMasterKeyLength = BYTE 238 SRTPMasterKey = 1*256BYTE 239 SSRC = 4BYTE; SSRC from RTP 240 ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC 242 EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 244 EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 245 SPI = 2BYTE 247 FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull 249 ShortEKTField = EKTMsgTypeShort 251 ExtensionData = 1*1024BYTE 252 ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 254 EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 256 Figure 3: EKTField Syntax 258 These fields and data elements are defined as follows: 260 EKTPlaintext: The data that is input to the EKT encryption operation. 261 This data never appears on the wire, and is used only in computations 262 internal to EKT. This is the concatenation of the SRTP Master Key 263 and its length, the SSRC, and the ROC. 265 EKTCiphertext: The data that is output from the EKT encryption 266 operation, described in Section 4.4. This field is included in SRTP 267 packets when EKT is in use. The length of EKTCiphertext can be 268 larger than the length of the EKTPlaintext that was encrypted. 270 SRTPMasterKey: On the sender side, the SRTP Master Key associated 271 with the indicated SSRC. 273 SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This 274 depends on the cipher suite negotiated for SRTP using SDP Offer/ 275 Answer [RFC3264] for the SRTP. 277 SSRC: On the sender side, this is the SSRC for this SRTP source. The 278 length of this field is 32 bits. 280 Rollover Counter (ROC): On the sender side, this is set to the 281 current value of the SRTP rollover counter in the SRTP/SRTCP context 282 associated with the SSRC in the SRTP or SRTCP packet. The length of 283 this field is 32 bits. 285 Security Parameter Index (SPI): This field indicates the appropriate 286 EKTKey and other parameters for the receiver to use when processing 287 the packet. The length of this field is 16 bits. The parameters 288 identified by this field are: 290 o The EKT cipher used to process the packet. 292 o The EKTKey used to process the packet. 294 o The SRTP Master Salt associated with any master key encrypted with 295 this EKT Key. The master salt is communicated separately, via 296 signaling, typically along with the EKTKey. 298 Together, these data elements are called an EKT parameter set. Each 299 distinct EKT parameter set that is used MUST be associated with a 300 distinct SPI value to avoid ambiguity. 302 EKTMsgLength: All EKT messages types other than the ShortEKTField 303 have a length as second from the last element. This is the length in 304 octets of either the FullEKTField/ExtensionEKTField including this 305 length field and the following EKT Message Type. 307 Message Type: The last byte is used to indicate the type of the 308 EKTField. This MUST be 2 for the FullEKTField format and 0 in 309 ShortEKTField format. Values less than 64 are mandatory to 310 understand while other values are optional to understand. A receiver 311 SHOULD discard the whole EKTField if it contains any message type 312 value that is less than 64 and that is not understood. Message type 313 values that are 64 or greater but not implemented or understood can 314 simply be ignored. 316 4.2. Packet Processing and State Machine 318 At any given time, each SRTP/SRTCP source has associated with it a 319 single EKT parameter set. This parameter set is used to process all 320 outbound packets, and is called the outbound parameter set for that 321 SSRC. There may be other EKT parameter sets that are used by other 322 SRTP/SRTCP sources in the same session, including other SRTP/SRTCP 323 sources on the same endpoint (e.g., one endpoint with voice and video 324 might have two EKT parameter sets, or there might be multiple video 325 sources on an endpoint each with their own EKT parameter set). All 326 of the received EKT parameter sets SHOULD be stored by all of the 327 participants in an SRTP session, for use in processing inbound SRTP 328 and SRTCP traffic. 330 Either the FullEKTField or ShortEKTField is appended at the tail end 331 of all SRTP packets. The decision on which to send when is specified 332 in Section 4.7. 334 4.2.1. Outbound Processing 336 See Section 4.7 which describes when to send an SRTP packet with a 337 FullEKTField. If a FullEKTField is not being sent, then a 338 ShortEKTField is sent so the receiver can correctly determine how to 339 process the packet. 341 When an SRTP packet is sent with a FullEKTField, the EKTField for 342 that packet is created as follows, or uses an equivalent set of 343 steps. The creation of the EKTField MUST precede the normal SRTP 344 packet processing. 346 1. The Security Parameter Index (SPI) field is set to the value of 347 the Security Parameter Index that is associated with the outbound 348 parameter set. 350 2. The EKTPlaintext field is computed from the SRTP Master Key, 351 SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP 352 Master Key, and SSRC used in EKT processing SHOULD be the same as 353 the one used in the SRTP processing. 355 3. The EKTCiphertext field is set to the ciphertext created by 356 encrypting the EKTPlaintext with the EKTCipher using the EKTKey 357 as the encryption key. The encryption process is detailed in 358 Section 4.4. 360 4. Then the FullEKTField is formed using the EKTCiphertext and the 361 SPI associated with the EKTKey used above. Also appended are the 362 Length and Message Type using the FullEKTField format. 364 * Note: the value of the EKTCiphertext field is identical in 365 successive packets protected by the same EKTKey and SRTP 366 master key. This value MAY be cached by an SRTP sender to 367 minimize computational effort. 369 The computed value of the FullEKTField is written into the SRTP 370 packet. 372 When a packet is sent with the ShortEKTField, the ShortEKFField is 373 simply appended to the packet. 375 Outbound packets SHOULD continue to use the old SRTP Master Key for 376 250 ms after sending any new key. This gives all the receivers in 377 the system time to get the new key before they start receiving media 378 encrypted with the new key. 380 4.2.2. Inbound Processing 382 When receiving a packet on a RTP stream, the following steps are 383 applied for each SRTP received packet. 385 1. The final byte is checked to determine which EKT format is in 386 use. When an SRTP or SRTCP packet contains a ShortEKTField, the 387 ShortEKTField is removed from the packet then normal SRTP or 388 SRTCP processing occurs. If the packet contains a FullEKTField, 389 then processing continues as described below. The reason for 390 using the last byte of the packet to indicate the type is that 391 the length of the SRTP or SRTCP part is not known until the 392 decryption has occurred. At this point in the processing, there 393 is no easy way to know where the EKTField would start. However, 394 the whole UDP packet has been received, so instead of the 395 starting at the front of the packet, the parsing works backwards 396 at the end of the packet and thus the type is placed at the very 397 end of the packet. 399 2. The Security Parameter Index (SPI) field is used to find the 400 right EKT parameter set to be used for processing the packet. If 401 there is no matching SPI, then the verification function MUST 402 return an indication of authentication failure, and the steps 403 described below are not performed. The EKT parameter set 404 contains the EKTKey, EKTCipher, and the SRTP Master Salt. 406 3. The EKTCiphertext is authenticated and decrypted, as described in 407 Section 4.4, using the EKTKey and EKTCipher found in the previous 408 step. If the EKT decryption operation returns an authentication 409 failure, then EKT processing MUST be aborted. The receiver 410 SHOULD discard the whole UDP packet. 412 4. The resulting EKTPlaintext is parsed as described in Section 4.1, 413 to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP 414 Master Salt that is associated with the EKTKey is also retrieved. 415 If the value of the srtp_master_salt sent as part of the EKTkey 416 is longer than needed by SRTP, then it is truncated by taking the 417 first N bytes from the srtp_master_salt field. 419 5. If the SSRC in the EKTPlaintext does not match the SSRC of the 420 SRTP packet received, then all the information from this 421 EKTPlaintext MUST be discarded and the following steps in this 422 list are skipped. 424 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 425 steps are saved in a map indexed by the SSRC found in the 426 EKTPlaintext and can be used for any future crypto operations on 427 the inbound packets with that SSRC. 429 * Unless the transform specifies other acceptable key lengths, 430 the length of the SRTP Master Key MUST be the same as the 431 master key length for the SRTP transform in use. If this is 432 not the case, then the receiver MUST abort EKT processing and 433 SHOULD discared the whole UDP packet. 435 * If the length of the SRTP Master Key is less than the master 436 key length for the SRTP transform in use, and the transform 437 specifies that this length is acceptable, then the SRTP Master 438 Key value is used to replace the first bytes in the existing 439 master key. The other bytes remain the same as in the old 440 key. For example, the Double GCM transform 441 [I-D.ietf-perc-double] allows replacement of the first, "end 442 to end" half of the master key. 444 7. At this point, EKT processing has successfully completed, and the 445 normal SRTP or SRTCP processing takes place. 447 4.3. Implementation Notes 449 The value of the EKTCiphertext field is identical in successive 450 packets protected by the same EKT parameter set and the same SRTP 451 master key, and ROC. SRTP senders and receivers MAY cache an 452 EKTCiphertext value to optimize processing in cases where the master 453 key hasn't changed. Instead of encrypting and decrypting, senders 454 can simply copy the pre-computed value and receivers can compare a 455 received EKTCiphertext to the known value. 457 Section 4.2.1 recommends that SRTP senders continue using an old key 458 for some time after sending a new key in an EKT tag. Receivers that 459 wish to avoid packet loss due to decryption failures MAY perform 460 trial decryption with both the old key and the new key, keeping the 461 result of whichever decryption succeeds. Note that this approach is 462 only compatible with SRTP transforms that include integrity 463 protection. 465 When receiving a new EKTKey, implementations need to use the ekt_ttl 466 field (see Section 5.2.2) to create a time after which this key 467 cannot be used and they also need to create a counter that keeps 468 track of how many times the key has been used to encrypt data to 469 ensure it does not exceed the T value for that cipher (see ). If 470 either of these limits are exceeded, the key can no longer be used 471 for encryption. At this point implementation need to either use the 472 call signaling to renegotiate a new session or need to terminate the 473 existing session. Terminating the session is a reasonable 474 implementation choice because these limits should not be exceeded 475 except under an attack or error condition. 477 4.4. Ciphers 479 EKT uses an authenticated cipher to encrypt and authenticate the 480 EKTPlaintext. This specification defines the interface to the 481 cipher, in order to abstract the interface away from the details of 482 that function. This specification also defines the default cipher 483 that is used in EKT. The default cipher described in Section 4.4.1 484 MUST be implemented, but another cipher that conforms to this 485 interface MAY be used. 487 An EKTCipher consists of an encryption function and a decryption 488 function. The encryption function E(K, P) takes the following 489 inputs: 491 o a secret key K with a length of L bytes, and 493 o a plaintext value P with a length of M bytes. 495 The encryption function returns a ciphertext value C whose length is 496 N bytes, where N may be larger than M. The decryption function D(K, 497 C) takes the following inputs: 499 o a secret key K with a length of L bytes, and 501 o a ciphertext value C with a length of N bytes. 503 The decryption function returns a plaintext value P that is M bytes 504 long, or returns an indication that the decryption operation failed 505 because the ciphertext was invalid (i.e. it was not generated by the 506 encryption of plaintext with the key K). 508 These functions have the property that D(K, E(K, P)) = P for all 509 values of K and P. Each cipher also has a limit T on the number of 510 times that it can be used with any fixed key value. The EKTKey MUST 511 NOT be used for encryption more that T times. Note that if the same 512 FullEKTField is retransmitted 3 times, that only counts as 1 513 encryption. 515 Security requirements for EKT ciphers are discussed in Section 6. 517 4.4.1. Ciphers 519 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 520 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 521 length M that is at least one octet, and it returns a ciphertext with 522 a length of N = M + (M mod 8) + 8 octets. 523 It can be used with key sizes of L = 16, and L = 32 octets, and its 524 use with those key sizes is indicated as AESKW128, or AESKW256, 525 respectively. The key size determines the length of the AES key used 526 by the Key Wrap algorithm. With this cipher, T=2^48. 528 +----------+----+------+ 529 | Cipher | L | T | 530 +----------+----+------+ 531 | AESKW128 | 16 | 2^48 | 532 | AESKW256 | 32 | 2^48 | 533 +----------+----+------+ 535 Table 1: EKT Ciphers 537 As AES-128 is the mandatory to implement transform in SRTP, AESKW128 538 MUST be implemented for EKT and AESKW256 MAY be implemented. 540 4.4.2. Defining New EKT Ciphers 542 Other specifications may extend this document by defining other 543 EKTCiphers as described in Section 7. This section defines how those 544 ciphers interact with this specification. 546 An EKTCipher determines how the EKTCiphertext field is written, and 547 how it is processed when it is read. This field is opaque to the 548 other aspects of EKT processing. EKT ciphers are free to use this 549 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 550 an input. The values of the parameters L, and T MUST be defined by 551 each EKTCipher. The cipher MUST provide integrity protection. 553 4.5. Synchronizing Operation 555 If a source has its EKTKey changed by the key management, it MUST 556 also change its SRTP master key, which will cause it to send out a 557 new FullEKTField. This ensures that if key management thought the 558 EKTKey needs changing (due to a participant leaving or joining) and 559 communicated that to a source, the source will also change its SRTP 560 master key, so that traffic can be decrypted only by those who know 561 the current EKTKey. 563 4.6. Transport 565 This document defines the use of EKT with SRTP. Its use with SRTCP 566 would be similar, but is reserved for a future specification. SRTP 567 is preferred for transmitting key material because it shares fate 568 with the transmitted media, because SRTP rekeying can occur without 569 concern for RTCP transmission limits, and because it avoids the need 570 for SRTCP compound packets with RTP translators and mixers. 572 4.7. Timing and Reliability Consideration 574 A system using EKT learns the SRTP master keys distributed with the 575 FullEKTField sent with the SRTP, rather than with call signaling. A 576 receiver can immediately decrypt an SRTP packet, provided the SRTP 577 packet contains a FullEKTField. 579 This section describes how to reliably and expediently deliver new 580 SRTP master keys to receivers. 582 There are three cases to consider. The first case is a new sender 583 joining a session, which needs to communicate its SRTP master key to 584 all the receivers. The second case is a sender changing its SRTP 585 master key which needs to be communicated to all the receivers. The 586 third case is a new receiver joining a session already in progress 587 which needs to know the sender's SRTP master key. 589 The three cases are: 591 New sender: 592 A new sender SHOULD send a packet containing the FullEKTField as 593 soon as possible, always before or coincident with sending its 594 initial SRTP packet. To accommodate packet loss, it is 595 RECOMMENDED that three consecutive packets contain the 596 FullEKTField be transmitted. If the sender does not send a 597 FullEKTField in its initial packets and receivers have not 598 otherwise been provisioned with a decryption key, then decryption 599 will fail and SRTP packets will be dropped until the the receives 600 a FullEKTField from the sender. 602 Rekey: 603 By sending EKT tag over SRTP, the rekeying event shares fate with 604 the SRTP packets protected with that new SRTP master key. To 605 accommodate packet loss, it is RECOMMENDED that three consecutive 606 packets contain the FullEKTField be transmitted. 608 New receiver: 609 When a new receiver joins a session it does not need to 610 communicate its sending SRTP master key (because it is a 611 receiver). When a new receiver joins a session, the sender is 612 generally unaware of the receiver joining the session. Thus, 613 senders SHOULD periodically transmit the FullEKTField. That 614 interval depends on how frequently new receivers join the session, 615 the acceptable delay before those receivers can start processing 616 SRTP packets, and the acceptable overhead of sending the 617 FullEKTField. If sending audio and video, the RECOMMENDED 618 frequency is the same as the rate of intra coded video frames. If 619 only sending audio, the RECOMMENDED frequency is every 100ms. 621 5. Use of EKT with DTLS-SRTP 623 This document defines an extension to DTLS-SRTP called SRTP EKTKey 624 Transport which enables secure transport of EKT keying material from 625 the DTLS-SRTP peer in the server role to the client. This allows 626 those peers to process EKT keying material in SRTP (or SRTCP) and 627 retrieve the embedded SRTP keying material. This combination of 628 protocols is valuable because it combines the advantages of DTLS, 629 which has strong authentication of the endpoint and flexibility, 630 along with allowing secure multiparty RTP with loose coordination and 631 efficient communication of per-source keys. 633 5.1. DTLS-SRTP Recap 635 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 636 to exchange keying material, algorithms, and parameters for SRTP. 637 The SRTP flow operates over the same transport as the DTLS-SRTP 638 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 639 performance and encryption flexibility benefits of SRTP with the 640 flexibility and convenience of DTLS-integrated key and association 641 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 642 key management method for SRTP, and a new RTP-specific data format 643 for DTLS. 645 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 647 This document defines a new TLS negotiated extension 648 supported_ekt_ciphers and a new TLS handshake message type ekt_key. 649 The extension negotiates the cipher to be used in encrypting and 650 decrypting EKTCiphertext values, and the handshake message carries 651 the corresponding key. 653 Figure 4 shows a message flow of DTLS 1.3 client and server using EKT 654 configured using the DTLS extensions described in this section. (The 655 initial cookie exchange and other normal DTLS messages are omitted.) 656 Client Server 658 ClientHello 659 + use_srtp 660 + supported_ekt_ciphers 661 --------> 663 ServerHello 664 {EncryptedExtensions} 665 + use_srtp 666 + supported_ekt_ciphers 667 {... Finished} 668 <-------- 670 {... Finished} --------> 672 [Ack] 673 <-------- [EKTKey] 675 [Ack] --------> 677 |SRTP packets| <-------> |SRTP packets| 678 + + 680 {} Messages protected using DTLS handshake keys 682 [] Messages protected using DTLS application traffic keys 684 <> Messages protected using the EKTKey and EKT cipher 686 || Messages protected using the SRTP Master Key sent in 687 a Full EKT Tag 689 Figure 4 691 In the context of a multi-party SRTP session in which each endpoint 692 performs a DTLS handshake as a client with a central DTLS server, the 693 extensions defined in this document allow the DTLS server to set a 694 common EKTKey for all participants. Each endpoint can then use EKT 695 tags encrypted with that common key to inform other endpoint of the 696 keys it uses to protect SRTP packets. This avoids the need for many 697 individual DTLS handshakes among the endpoints, at the cost of 698 preventing endpoints from directly authenticating one another. 700 Client A Server Client B 702 <----DTLS Handshake----> 703 <--------EKTKey--------- 704 <----DTLS Handshake----> 705 ---------EKTKey--------> 707 -------------SRTP Packet + EKT Tag-------------> 708 <------------SRTP Packet + EKT Tag-------------- 710 5.2.1. Negotiating an EKTCipher 712 To indicate its support for EKT, a DTLS-SRTP client includes in its 713 ClientHello an extension of type supported_ekt_ciphers listing the 714 ciphers used for EKT by the client supports in preference order, with 715 the most preferred version first. If the server agrees to use EKT, 716 then it includes a supported_ekt_ciphers extension in its ServerHello 717 containing a cipher selected from among those advertised by the 718 client. 720 The extension_data field of this extension contains an "EKTCipher" 721 value, encoded using the syntax defined in [RFC5246]: 723 enum { 724 reserved(0), 725 aeskw_128(1), 726 aeskw_256(2), 727 } EKTCipherType; 729 struct { 730 select (Handshake.msg_type) { 731 case client_hello: 732 EKTCipherType supported_ciphers<1..255>; 734 case server_hello: 735 EKTCipherType selected_cipher; 736 }; 737 } EKTCipher; 739 5.2.2. Establishing an EKT Key 741 Once a client and server have concluded a handshake that negotiated 742 an EKTCipher, the server MUST provide to the client a key to be used 743 when encrypting and decrypting EKTCiphertext values. EKTKeys are 744 sent in encrypted handshake records, using handshake type 745 ekt_key(TBD). The body of the handshake message contains an EKTKey 746 structure: 748 [[ NOTE: RFC Editor, please replace "TBD" above with the code point 749 assigned by IANA ]] 751 struct { 752 opaque ekt_key_value<1..256>; 753 opaque srtp_master_salt<1..256>; 754 uint16 ekt_spi; 755 uint24 ekt_ttl; 756 } EKTKey; 758 The contents of the fields in this message are as follows: 760 ekt_key_value 761 The EKTKey that the recipient should use when generating 762 EKTCiphertext values 764 srtp_master_salt 765 The SRTP Master Salt to be used with any Master Key encrypted with 766 this EKT Key 768 ekt_spi 769 The SPI value to be used to reference this EKTKey and SRTP Master 770 Salt in EKT tags (along with the EKT cipher negotiated in the 771 handshake) 773 ekt_ttl 774 The maximum amount of time, in seconds, that this EKTKey can be 775 used. The ekt_key_value in this message MUST NOT be used for 776 encrypting or decrypting information after the TTL expires. 778 If the server did not provide a supported_ekt_ciphers extension in 779 its ServerHello, then EKTKey messages MUST NOT be sent by the client 780 or the server. 782 When an EKTKey is received and processed successfully, the recipient 783 MUST respond with an Ack handshake message as described in Section 7 784 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be 785 retransmitted following the rules in Section 4.2.4 of [RFC6347]. 787 Note: To be clear, EKT can be used with versions of DTLS prior to 788 1.3. The only difference is that in a pre-1.3 TLS stacks will not 789 have built-in support for generating and processing Ack messages. 791 If an EKTKey message is received that cannot be processed, then the 792 recipient MUST respond with an appropriate DTLS alert. 794 5.3. Offer/Answer Considerations 796 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 797 the DTLS handshake level and does not change the [RFC3264] Offer / 798 Answer messaging. 800 5.4. Sending the DTLS EKTKey Reliably 802 The DTLS EKTKey message is sent using the retransmissions specified 803 in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished 804 with an Ack message or an alert is received. 806 6. Security Considerations 808 EKT inherits the security properties of the the key management 809 protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP 810 extension defined in this document. 812 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 813 master keys. This property avoids any security concern over the re- 814 use of keys, by empowering the SRTP layer to create keys on demand. 815 Note that the inputs of EKT are the same as for SRTP with key- 816 sharing: a single key is provided to protect an entire SRTP session. 817 However, EKT remains secure even when SSRC values collide. 819 SRTP master keys MUST be randomly generated, and [RFC4086] offers 820 some guidance about random number generation. SRTP master keys MUST 821 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 822 be derived from other SRTP master keys. 824 The EKT Cipher includes its own authentication/integrity check. For 825 an attacker to successfully forge a FullEKTField, it would need to 826 defeat the authentication mechanisms of the EKT Cipher authentication 827 mechanism. 829 The presence of the SSRC in the EKTPlaintext ensures that an attacker 830 cannot substitute an EKTCiphertext from one SRTP stream into another 831 SRTP stream. 833 An attacker who tampers with the bits in FullEKTField can prevent the 834 intended receiver of that packet from being able to decrypt it. This 835 is a minor denial of service vulnerability. Similarly the attacker 836 could take an old FullEKTField from the same session and attach it to 837 the packet. The FullEKTField would correctly decode and pass 838 integrity checks. However, the key extracted from the FullEKTField , 839 when used to decrypt the SRTP payload, would be wrong and the SRTP 840 integrity check would fail. Note that the FullEKTField only changes 841 the decryption key and does not change the encryption key. None of 842 these are considered significant attacks as any attacker that can 843 modify the packets in transit and cause the integrity check to fail. 845 An attacker could send packets containing a FullEKTField, in an 846 attempt to consume additional CPU resources of the receiving system 847 by causing the receiving system to decrypt the EKT ciphertext and 848 detect an authentication failure. In some cases, caching the 849 previous values of the Ciphertext as described in Section 4.3 helps 850 mitigate this issue. 852 In a similar vein, EKT has no replay protection, so an attacker could 853 implant improper keys in receivers by capturing EKTCiphertext values 854 encrypted with a given EKTKey and replaying them in a different 855 context, e.g., from a different sender. When the underlying SRTP 856 transform provides integrity protection, this attack will just result 857 in packet loss. If it does not, then it will result in random data 858 being fed to RTP payload processing. An attacker that is in a 859 position to mount these attacks, however, could achieve the same 860 effects more easily without attacking EKT. 862 Each EKT cipher specifies a value T that is the maximum number of 863 times a given key can be used. An endpoint MUST NOT encrypt more 864 than T different FullEKTField values using the same EKTKey. In 865 addition, the EKTKey MUST NOT be used beyond the lifetime provided by 866 the TTL described in Section 5.2. 868 The confidentiality, integrity, and authentication of the EKT cipher 869 MUST be at least as strong as the SRTP cipher and at least as strong 870 as the DTLS-SRTP ciphers. 872 Part of the EKTPlaintext is known, or easily guessable to an 873 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 874 In practice, this requirement does not impose any restrictions on our 875 choices, since the ciphers in use provide high security even when 876 much plaintext is known. 878 An EKT cipher MUST resist attacks in which both ciphertexts and 879 plaintexts can be adaptively chosen and adversaries that can query 880 both the encryption and decryption functions adaptively. 882 In some systems, when a member of a conference leaves the 883 conferences, the conferences is rekeyed so that member no longer has 884 the key. When changing to a new EKTKey, it is possible that the 885 attacker could block the EKTKey message getting to a particular 886 endpoint and that endpoint would keep sending media encrypted using 887 the old key. To mitigate that risk, the lifetime of the EKTKey MUST 888 be limited using the ekt_ttl. 890 7. IANA Considerations 892 7.1. EKT Message Types 894 IANA is requested to create a new table for "EKT Messages Types" in 895 the "Real-Time Transport Protocol (RTP) Parameters" registry. The 896 initial values in this registry are: 898 +--------------+-------+---------------+ 899 | Message Type | Value | Specification | 900 +--------------+-------+---------------+ 901 | Short | 0 | RFCAAAA | 902 | Full | 2 | RFCAAAA | 903 | Reserved | 63 | RFCAAAA | 904 | Reserved | 255 | RFCAAAA | 905 +--------------+-------+---------------+ 907 Table 2: EKT Messages Types 909 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 910 this specification. 912 New entries to this table can be added via "Specification Required" 913 as defined in [RFC8126]. When requesting a new value, the requestor 914 needs to indicate if it is mandatory to understand or not. If it is 915 mandatory to understand, IANA needs to allocate a value less than 64, 916 if it is not mandatory to understand, a value greater than or equal 917 to 64 needs to be allocated. IANA SHOULD prefer allocation of even 918 values over odd ones until the even code points are consumed to avoid 919 conflicts with pre standard versions of EKT that have been deployed. 921 All new EKT messages MUST be defined to have a length as second from 922 the last element. 924 7.2. EKT Ciphers 926 IANA is requested to create a new table for "EKT Ciphers" in the 927 "Real-Time Transport Protocol (RTP) Parameters" registry. The 928 initial values in this registry are: 930 +----------+-------+---------------+ 931 | Name | Value | Specification | 932 +----------+-------+---------------+ 933 | AESKW128 | 1 | RFCAAAA | 934 | AESKW256 | 2 | RFCAAAA | 935 | Reserved | 255 | RFCAAAA | 936 +----------+-------+---------------+ 938 Table 3: EKT Cipher Types 940 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 941 this specification. 943 New entries to this table can be added via "Specification Required" 944 as defined in [RFC8126]. The expert SHOULD ensure the specification 945 defines the values for L and T as required in Section 4.4 of RFCAAAA. 946 Allocated values MUST be in the range of 1 to 254. 948 7.3. TLS Extensions 950 IANA is requested to add supported_ekt_ciphers as a new extension 951 name to the "TLS ExtensionType Values" table of the "Transport Layer 952 Security (TLS) Extensions" registry with a reference to this 953 specification and allocate a value of TBD to for this. 955 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 957 7.4. TLS Handshake Type 959 IANA is requested to add ekt_key as a new entry in the "TLS 960 HandshakeType Registry" table of the "Transport Layer Security (TLS) 961 Parameters" registry with a reference to this specification, a DTLS- 962 OK value of "Y", and allocate a value of TBD to for this content 963 type. 965 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 967 8. Acknowledgements 969 Thank you to Russ Housley provided detailed review and significant 970 help with crafting text for this document. Thanks to David Benham, 971 Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul 972 Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean 973 Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, 974 comments, and contributions to this document. 976 9. References 978 9.1. Normative References 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, 982 DOI 10.17487/RFC2119, March 1997, 983 . 985 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 986 with Session Description Protocol (SDP)", RFC 3264, 987 DOI 10.17487/RFC3264, June 2002, 988 . 990 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 991 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 992 RFC 3711, DOI 10.17487/RFC3711, March 2004, 993 . 995 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 996 Specifications: ABNF", STD 68, RFC 5234, 997 DOI 10.17487/RFC5234, January 2008, 998 . 1000 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1001 (TLS) Protocol Version 1.2", RFC 5246, 1002 DOI 10.17487/RFC5246, August 2008, 1003 . 1005 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1006 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1007 DOI 10.17487/RFC5649, September 2009, 1008 . 1010 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1011 Security (DTLS) Extension to Establish Keys for the Secure 1012 Real-time Transport Protocol (SRTP)", RFC 5764, 1013 DOI 10.17487/RFC5764, May 2010, 1014 . 1016 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1017 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1018 January 2012, . 1020 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1021 Writing an IANA Considerations Section in RFCs", BCP 26, 1022 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1023 . 1025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1026 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1027 May 2017, . 1029 9.2. Informative References 1031 [I-D.ietf-perc-double] 1032 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 1033 Double Encryption Procedures", draft-ietf-perc-double-09 1034 (work in progress), May 2018. 1036 [I-D.ietf-perc-private-media-framework] 1037 Jones, P., Benham, D., and C. Groves, "A Solution 1038 Framework for Private Media in Privacy Enhanced RTP 1039 Conferencing", draft-ietf-perc-private-media-framework-07 1040 (work in progress), September 2018. 1042 [I-D.ietf-tls-dtls13] 1043 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1044 Datagram Transport Layer Security (DTLS) Protocol Version 1045 1.3", draft-ietf-tls-dtls13-28 (work in progress), July 1046 2018. 1048 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1049 "Randomness Requirements for Security", BCP 106, RFC 4086, 1050 DOI 10.17487/RFC4086, June 2005, 1051 . 1053 Authors' Addresses 1055 Cullen Jennings 1056 Cisco Systems 1058 Email: fluffy@iii.ca 1060 John Mattsson 1061 Ericsson AB 1063 Email: john.mattsson@ericsson.com 1065 David A. McGrew 1066 Cisco Systems 1068 Email: mcgrew@cisco.com 1069 Dan Wing 1071 Email: dwing-ietf@fuggles.com 1073 Flemming Andreason 1074 Cisco Systems 1076 Email: fandreas@cisco.com