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