idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders MUST not include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. -- The document date (April 28, 2017) is 2554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 718, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** 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-02 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-02 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PERC Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Mattsson, Ed. 5 Expires: October 30, 2017 Ericsson 6 D. McGrew 7 D. Wing 8 F. Andreasen 9 Cisco 10 April 28, 2017 12 Encrypted Key Transport for DTLS and Secure RTP 13 draft-ietf-perc-srtp-ekt-diet-04 15 Abstract 17 Encrypted Key Transport (EKT) is an extension to DTLS and Secure 18 Real-time Transport Protocol (SRTP) that provides for the secure 19 transport of SRTP master keys, rollover counters, and other 20 information within SRTP. This facility enables SRTP for 21 decentralized conferences by distributing a common key to all of the 22 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 October 30, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 13 74 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 75 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 76 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17 77 5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 81 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 20 83 7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 20 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 9.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 Real-time Transport Protocol (RTP) is designed to allow decentralized 93 groups with minimal control to establish sessions, such as for 94 multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711]) 95 cannot be used in many minimal-control scenarios, because it requires 96 that synchronization source (SSRC) values and other data be 97 coordinated among all of the participants in a session. For example, 98 if a participant joins a session that is already in progress, that 99 participant needs to be told the SRTP keys along with the SSRC, 100 rollover counter (ROC) and other details of the other SRTP sources. 102 The inability of SRTP to work in the absence of central control was 103 well understood during the design of the protocol; the omission was 104 considered less important than optimizations such as bandwidth 105 conservation. Additionally, in many situations SRTP is used in 106 conjunction with a signaling system that can provide the central 107 control needed by SRTP. However, there are several cases in which 108 conventional signaling systems cannot easily provide all of the 109 coordination required. It is also desirable to eliminate the layer 110 violations that occur when signaling systems coordinate certain SRTP 111 parameters, such as SSRC values and ROCs. 113 This document defines Encrypted Key Transport (EKT) for SRTP and 114 reduces the amount of external signaling control that is needed in a 115 SRTP session with multiple receivers. EKT securely distributes the 116 SRTP master key and other information for each SRTP source. With 117 this method, SRTP entities are free to choose SSRC values as they see 118 fit, and to start up new SRTP sources with new SRTP master keys (see 119 Section 2.2) within a session without coordinating with other 120 entities via external signaling or other external means. 122 EKT provides a way for an SRTP session participant, either a sender 123 or receiver, to securely transport its SRTP master key and current 124 SRTP rollover counter to the other participants in the session. This 125 data furnishes the information needed by the receiver to instantiate 126 an SRTP/SRTCP receiver context. 128 EKT can be used in conferences where the central media distributor or 129 conference bridge can not decrypt the media, such as the type defined 130 for [I-D.ietf-perc-private-media-framework]. It can also be used for 131 large scale conferences where the conference bridge or media 132 distributor can decrypt all the media but wishes to encrypt the media 133 it is sending just once then send the same encrypted media to a large 134 number of participants. This reduces the amount of CPU time needed 135 for encryption and can be used for some optimization to media sending 136 that use source specific multicast. 138 EKT does not control the manner in which the SSRC is generated; it is 139 only concerned with their secure transport. 141 EKT is not intended to replace external key establishment mechanisms. 142 Instead, it is used in conjunction with those methods, and it 143 relieves those methods of the burden to deliver the context for each 144 SRTP source to every SRTP participant. 146 2. Overview 148 This specification defines a way for the server in a DTLS-SRTP 149 negotiation to provide an ekt_key to the client during the DTLS 150 handshake. This ekt_key can be used to encrypt the SRTP master key 151 used to encrypt the media the endpoint sends. This specification 152 also defines a way to send the encrypted SRTP master key along with 153 the SRTP packet. Endpoints that receive this and know the ekt_key 154 can use the ekt_key to decrypt the SRTP master key then use the SRTP 155 master key to decrypt the SRTP packet. 157 One way to use this is used is described in the architecture defined 158 by [I-D.ietf-perc-private-media-framework]. Each participants in the 159 conference call forms a DTLS-SRTP connection to a common key 160 distributor that gives all the endpoints the same ekt_key. Then each 161 endpoint picks there own SRTP master key for the media they send. 162 When sending media, the endpoint also includes the SRTP master key 163 encrypted with the ekt_key. This allows all the endpoints to decrypt 164 the media. 166 3. Conventions Used In This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 4. Encrypted Key Transport 174 EKT defines a new method of providing SRTP master keys to an 175 endpoint. In order to convey the ciphertext corresponding to the 176 SRTP master key, and other additional information, an additional EKT 177 field is added to SRTP packets. The EKT field appears at the end of 178 the SRTP packet. The EKT field appears after the optional 179 authentication tag if one is present, otherwise the EKT field appears 180 after the ciphertext portion of the packet. 182 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 183 Identifier) or with SRTP's [RFC3711], as those SRTP 184 features duplicate some of the functions of EKT. Senders MUST not 185 include MKI when using EKT. Receivers SHOULD simply ignore any MKI 186 field received if EKT is in use. 188 4.1. EKT Field Formats 190 The EKT Field uses the format defined below for the FullEKTField and 191 ShortEKTField. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 : : 197 : EKT Ciphertext : 198 : : 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Security Parameter Index | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |0 0 0 0 0 0 1 0| 203 +-+-+-+-+-+-+-+-+ 205 Figure 1: Full EKT Field format 207 0 1 2 3 4 5 6 7 208 +-+-+-+-+-+-+-+-+ 209 |0 0 0 0 0 0 0 0| 210 +-+-+-+-+-+-+-+-+ 212 Figure 2: Short EKT Field format 214 The following shows the syntax of the EKTField expressed in ABNF 215 [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP 216 packet. The EKTPlaintext is the concatenation of 217 SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The 218 EKTCiphertext is computed by encrypting the EKTPlaintext using the 219 EKTKey. Future extensions to the EKTField MUST conform to the syntax 220 of ExtensionEKTField. 222 BYTE = %x00-FF 224 EKTMsgTypeFull = %x02 225 EKTMsgTypeShort = %x00 226 EKTMsgTypeExtension = %x03-FF 228 EKTMsgLength = 2BYTE; 230 SRTPMasterKeyLength = BYTE 231 SRTPMasterKey = 1*256BYTE 232 SSRC = 4BYTE; SSRC from RTP 233 ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC 235 EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 237 EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 238 SPI = 2BYTE 240 FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull 242 ShortEKTField = EKTMsgTypeShort 244 ExtensionData = 1*1024BYTE 245 ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 247 EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 249 Figure 3: EKTField Syntax 251 These fields and data elements are defined as follows: 253 EKTPlaintext: The data that is input to the EKT encryption 254 operation. This data never appears on the wire, and is used only 255 in computations internal to EKT. This is the concatenation of the 256 SRTP Master Key, the SSRC, and the ROC. 258 EKTCiphertext: The data that is output from the EKT encryption 259 operation, described in Section 4.4. This field is included in 260 SRTP packets when EKT is in use. The length of EKTCiphertext can 261 be larger than the length of the EKTPlaintext that was encrypted. 263 SRTPMasterKey: On the sender side, the SRTP Master Key associated 264 with the indicated SSRC. 266 SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This 267 depends on the cipher suite negotiated for SRTP using [RFC3264] 268 SDP Offer/Answer for the SRTP. 270 SSRC: On the sender side, this field is the SSRC for this SRTP 271 source. The length of this field is 32 bits. 273 Rollover Counter (ROC): On the sender side, this field is set to the 274 current value of the SRTP rollover counter in the SRTP context 275 associated with the SSRC in the SRTP or SRTCP packet. The length 276 of this field is 32 bits. 278 Security Parameter Index (SPI): This field indicates the appropriate 279 EKT Key and other parameters for the receiver to use when 280 processing the packet. The length of this field is 16 bits. The 281 parameters identified by this field are: 283 * The EKT cipher used to process the packet. 285 * The EKT Key used to process the packet. 287 * The SRTP Master Salt associated with any Master Key encrypted 288 with this EKT Key. The Master Salt is communicated separately, 289 via signaling, typically along with the EKTKey. 291 Together, these data elements are called an EKT parameter set. 292 Each distinct EKT parameter set that is used MUST be associated 293 with a distinct SPI value to avoid ambiguity. 295 EKTMsgLength: All EKT message other that ShortEKTField have a length 296 as second from the last element. This is the length in octets of 297 either the FullEKTField/ExtensionEKTField including this length 298 field and the following message type. 300 Message Type: The last byte is used to indicate the type of the 301 EKTField. This MUST be 2 in the FullEKTField format and 0 in 302 ShortEKTField format. Values less than 64 are mandatory to 303 understand while other values are optional to understand. A 304 receiver SHOULD discard the whole EKTField if it contains any 305 message type value that is less than 64 and that is not 306 understood. Message type values that are 64 or greater but not 307 implemented or understood can simply be ignored. 309 4.2. Packet Processing and State Machine 311 At any given time, each SRTP/SRTCP source has associated with it a 312 single EKT parameter set. This parameter set is used to process all 313 outbound packets, and is called the outbound parameter set for that 314 SSRC. There may be other EKT parameter sets that are used by other 315 SRTP/SRTCP sources in the same session, including other SRTP/SRTCP 316 sources on the same endpoint (e.g., one endpoint with voice and video 317 might have two EKT parameter sets, or there might be multiple video 318 sources on an endpoint each with their own EKT parameter set). All 319 of the received EKT parameter sets SHOULD be stored by all of the 320 participants in an SRTP session, for use in processing inbound SRTP 321 and SRTCP traffic. 323 Either the FullEKTField or ShortEKTField is appended at the tail end 324 of all SRTP packets. The decision on which to send is specified in 325 Section 4.7. 327 4.2.1. Outbound Processing 329 See Section 4.7 which describes when to send an SRTP packet with a 330 FullEKTField. If a FullEKTField is not being sent, then a 331 ShortEKTField is sent so the receiver can correctly determine how to 332 process the packet. 334 When an SRTP packet is sent with a FullEKTField, the EKTField for 335 that packet is created as follows, or uses an equivalent set of 336 steps. The creation of the EKTField MUST precede the normal SRTP 337 packet processing. 339 1. The Security Parameter Index (SPI) field is set to the value of 340 the Security Parameter Index that is associated with the outbound 341 parameter set. 343 2. The EKTPlaintext field is computed from the SRTP Master Key, 344 SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP 345 Master Key, and SSRC used in EKT processing SHOULD be the same as 346 the one used in the SRTP processing. 348 3. The EKTCiphertext field is set to the ciphertext created by 349 encrypting the EKTPlaintext with the EKT cipher, using the EKTKey 350 as the encryption key. The encryption process is detailed in 351 Section 4.4. 353 4. Then the FullEKTField is formed using the EKTCiphertext and the 354 SPI associated with the EKTKey used above. Also appended are the 355 Length and Message Type using the FullEKTField format. 357 Note: the value of the EKTCiphertext field is identical in 358 successive packets protected by the same EKTKey and SRTP 359 master key. This value MAY be cached by an SRTP sender to 360 minimize computational effort. 362 The computed value of the FullEKTField is written into the 363 packet. 365 When a packet is sent with the Short EKT Field, the ShortEKFField is 366 simply appended to the packet. 368 4.2.2. Inbound Processing 370 When receiving a packet on a RTP stream, the following steps are 371 applied for each received packet. 373 1. The final byte is checked to determine which EKT format is in 374 use. When an SRTP or SRTCP packet contains a ShortEKTField, the 375 ShortEKTField is removed from the packet then normal SRTP or 376 SRTCP processing occurs. If the packet contains a FullEKTField, 377 then processing continues as described below. The reason for 378 using the last byte of the packet to indicate the type is that 379 the length of the SRTP or SRTCP part is not known until the 380 decryption has occurred. At this point in the processing, there 381 is no easy way to know where the EKT field would start. However, 382 the whole UDP packet has been received so instead of the starting 383 at the front of the packet, the parsing works backwards off the 384 end of the packet and thus the type is put at the very end of the 385 packet. 387 2. The Security Parameter Index (SPI) field is used to find which 388 EKT parameter set to be used when processing the packet. If 389 there is no matching SPI, then the verification function MUST 390 return an indication of authentication failure, and the steps 391 described below are not performed. The EKT parameter set 392 contains the EKTKey, EKTCipher, and SRTP Master Salt. 394 3. The EKTCiphertext authentication is checked and it is decrypted, 395 as described in Section 4.4, using the EKTKey and EKTCipher found 396 in the previous step. If the EKT decryption operation returns an 397 authentication failure, then the packet processing stops. 399 4. The resulting EKTPlaintext is parsed as described in Section 4.1, 400 to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP 401 Master Salt that is associated with the EKTKey is also retrieved. 402 If the value of the srtp_master_salt sent as part of the EKTkey 403 is longer than needed by SRTP, then it is truncated by taking the 404 first N bytes from the srtp_master_salt field. 406 5. If the SSRC in the EKTPlaintext does not match the SSRC of the 407 SRTP packet, then all the information from this EKTPlaintext MUST 408 be discarded and the following steps in this list are not done. 410 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 411 step are saved in a map indexed by the SSRC found in the 412 EKTPlaintext and can be used for any future crypto operations on 413 the inbound packets with that SSRC. If the SRTP Master Key 414 recovered from the EKTPlaintext is longer than needed by SRTP 415 transform in use, the first bytes are used. If the SRTP Master 416 Key recovered from the EKTPlaintext is shorter than needed by 417 SRTP transform in use, then the bytes received replace the first 418 bytes in the existing key but the other bytes after that remain 419 the same as the old key. This allows for replacing just half the 420 key for transforms such as [I-D.ietf-perc-double]. Outbound 421 packets SHOULD continue to use the old SRTP Master Key for 250 ms 422 after sending any new key. This gives all the receivers in the 423 system time to get the new key before they start receiving media 424 encrypted with the new key. 426 7. At this point, EKT processing has successfully completed, and the 427 normal SRTP or SRTCP processing takes place including replay 428 protection. 430 4.3. Implementation Notes 432 The value of the EKTCiphertext field is identical in successive 433 packets protected by the same EKT parameter set and the same SRTP 434 master key, and ROC. This ciphertext value MAY be cached by an SRTP 435 receiver to minimize computational effort by noting when the SRTP 436 master key is unchanged and avoiding repeating the above steps. 438 The receiver may want to have a sliding window to retain old SRTP 439 master keys (and related context) for some brief period of time, so 440 that out of order packets can be processed as well as packets sent 441 during the time keys are changing. 443 When receiving a new EKTKey, implementations need to use the ekt_ttl 444 to create a time after which this key cannot be used and they also 445 need to create a counter that keeps track of how many times the keys 446 has been used to encrypt data to ensure it does not exceed the T 447 value for that cipher. If either of these limits are exceeded, the 448 key can no longer be used for encryption. At this point 449 implementation need to either use the call signaling to renegotiation 450 a new session or need to terminate the existing session. Terminating 451 the session is a reasonable implementation choice because these 452 limits should not be exceeded except under an attack or error 453 condition. 455 4.4. Ciphers 457 EKT uses an authenticated cipher to encrypt and authenticate the 458 EKTPlaintext. This specification defines the interface to the 459 cipher, in order to abstract the interface away from the details of 460 that function. This specification also defines the default cipher 461 that is used in EKT. The default cipher described in Section 4.4.1 462 MUST be implemented, but another cipher that conforms to this 463 interface MAY be used. 465 An EKTCipher consists of an encryption function and a decryption 466 function. The encryption function E(K, P) takes the following 467 inputs: 469 o a secret key K with a length of L bytes, and 471 o a plaintext value P with a length of M bytes. 473 The encryption function returns a ciphertext value C whose length is 474 N bytes, where N may be larger than M. The decryption function D(K, 475 C) takes the following inputs: 477 o a secret key K with a length of L bytes, and 479 o a ciphertext value C with a length of N bytes. 481 The decryption function returns a plaintext value P that is M bytes 482 long, or returns an indication that the decryption operation failed 483 because the ciphertext was invalid (i.e. it was not generated by the 484 encryption of plaintext with the key K). 486 These functions have the property that D(K, E(K, P)) = P for all 487 values of K and P. Each cipher also has a limit T on the number of 488 times that it can be used with any fixed key value. The EKTKey MUST 489 NOT be used for encryption more that T times. Note that if the same 490 FullEKTField is retransmitted 3 times, that only counts as 1 491 encryption. 493 Security requirements for EKT ciphers are discussed in Section 6. 495 4.4.1. Ciphers 497 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 498 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 499 length M that is at least one octet, and it returns a ciphertext with 500 a length of N = M + (M mod 8) + 8 octets. It can be used with key 501 sizes of L = 16, and L = 32 octets, and its use with those key sizes 502 is indicated as AESKW128, or AESKW256, respectively. The key size 503 determines the length of the AES key used by the Key Wrap algorithm. 504 With this cipher, T=2^48. 506 +----------+----+------+ 507 | Cipher | L | T | 508 +----------+----+------+ 509 | AESKW128 | 16 | 2^48 | 510 | | | | 511 | AESKW256 | 32 | 2^48 | 512 +----------+----+------+ 514 Table 1: EKT Ciphers 516 As AES-128 is the mandatory to implement transform in SRTP [RFC3711], 517 AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. 519 4.4.2. Defining New EKT Ciphers 521 Other specifications may extend this document by defining other 522 EKTCiphers as described in Section 7. This section defines how those 523 ciphers interact with this specification. 525 An EKTCipher determines how the EKTCiphertext field is written, and 526 how it is processed when it is read. This field is opaque to the 527 other aspects of EKT processing. EKT ciphers are free to use this 528 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 529 an input. The values of the parameters L, and T MUST be defined by 530 each EKTCipher. The cipher MUST provide integrity protection. 532 4.5. Synchronizing Operation 534 If a source has its EKTKey changed by the key management, it MUST 535 also change its SRTP master key, which will cause it to send out a 536 new FullEKTField. This ensures that if key management thought the 537 EKTKey needs changing (due to a participant leaving or joining) and 538 communicated that to a source, the source will also change its SRTP 539 master key, so that traffic can be decrypted only by those who know 540 the current EKTKey. 542 4.6. Transport 544 EKT SHOULD be used over SRTP, and other specification MAY define how 545 to use it over SRTCP. SRTP is preferred because it shares fate with 546 transmitted media, because SRTP rekeying can occur without concern 547 for RTCP transmission limits, and to avoid SRTCP compound packets 548 with RTP translators and mixers. 550 4.7. Timing and Reliability Consideration 552 A system using EKT learns the SRTP master keys distributed with 553 FullEKTFields sent with the SRTP, rather than with call signaling. A 554 receiver can immediately decrypt an SRTP packet, provided the SRTP 555 packet contains a Full EKT Field. 557 This section describes how to reliably and expediently deliver new 558 SRTP master keys to receivers. 560 There are three cases to consider. The first case is a new sender 561 joining a session which needs to communicate its SRTP master key to 562 all the receivers. The second case is a sender changing its SRTP 563 master key which needs to be communicated to all the receivers. The 564 third case is a new receiver joining a session already in progress 565 which needs to know the sender's SRTP master key. 567 The three cases are: 569 New sender: A new sender SHOULD send a packet containing the 570 FullEKTField as soon as possible, always before or coincident with 571 sending its initial SRTP packet. To accommodate packet loss, it 572 is RECOMMENDED that three consecutive packets contain the Full EKT 573 Field be transmitted. 575 Rekey: By sending EKT over SRTP, the rekeying event shares fate with 576 the SRTP packets protected with that new SRTP master key. To 577 accommodate packet loss, it is RECOMMENDED that three consecutive 578 packets contain the FullEKTField be transmitted. 580 New receiver: When a new receiver joins a session it does not need 581 to communicate its sending SRTP master key (because it is a 582 receiver). When a new receiver joins a session the sender is 583 generally unaware of the receiver joining the session. Thus, 584 senders SHOULD periodically transmit the FullEKTField. That 585 interval depends on how frequently new receivers join the session, 586 the acceptable delay before those receivers can start processing 587 SRTP packets, and the acceptable overhead of sending the FullEKT 588 Field. If sending audio and video, the RECOMMENDED frequency is 589 the same as the rate of intra coded video frames. If only sending 590 audio, the RECOMMENDED frequency is every 100ms. 592 5. Use of EKT with DTLS-SRTP 594 This document defines an extension to DTLS-SRTP called SRTP EKT Key 595 Transport which enables secure transport of EKT keying material from 596 one DTLS-SRTP peer to another. This allows those peers to process 597 EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP 598 keying material. This combination of protocols is valuable because 599 it combines the advantages of DTLS, which has strong authentication 600 of the endpoint and flexibility, along with allowing secure 601 multiparty RTP with loose coordination and efficient communication of 602 per-source keys. 604 5.1. DTLS-SRTP Recap 606 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 607 to exchange keying material, algorithms, and parameters for SRTP. 608 The SRTP flow operates over the same transport as the DTLS-SRTP 609 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 610 performance and encryption flexibility benefits of SRTP with the 611 flexibility and convenience of DTLS-integrated key and association 612 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 613 key management method for SRTP, and a new RTP-specific data format 614 for DTLS. 616 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 618 This document defines a new TLS negotiated extension called 619 "srtp_ekt_key_transport"and a new TLS content type called EKTMessage. 621 Using the syntax described in DTLS [RFC6347], the following 622 structures are used: 624 enum { 625 reserved(0), 626 aeskw_128(1), 627 aeskw_256(2), 628 } EKTCipherType; 630 struct { 631 EKTCipherType ekt_ciphers<1..255>; 632 } SupportedEKTCiphers; 634 struct { 635 EKTCipherType ekt_cipher; 636 uint ekt_key_value<1..256>; 637 uint srtp_master_salt<1..256>; 638 uint16 ekt_spi; 639 uint24 ekt_ttl; 640 } EKTkey; 642 enum { 643 ekt_key(0), 644 ekt_key_ack(1), 645 ekt_key_error(254), 646 (255) 647 } EKTMessageType; 649 struct { 650 EKTMessageType ekt_message_type; 651 select (EKTMessage.ekt_message_type) { 652 case ekt_key: 653 EKTKey; 654 } message; 655 } EKTMessage; 657 Figure 4: Additional TLS Data Structures 659 If a DTLS client includes "srtp_ekt_key_transport" in its 660 ClientHello, then a DTLS server that supports this extensions will 661 includes "srtp_ekt_key_transport" in its ServerHello message. If a 662 DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but 663 does not receive "srtp_ekt_key_transport" in the ServerHello, the 664 DTLS client MUST NOT send DTLS EKTMessage messages. Also, the 665 "srtp_ekt_key_transport" in the ServerHello MUST select one and only 666 one EKTCipherType from the list provided by the client in the 667 "srtp_ekt_key_transport" in the ClientHello. 669 When a DTLS client sends the "srtp_ekt_key_transport" in its 670 ClientHello message, it MUST include the SupportedEKTCiphers as the 671 extension_data for the extension, listing the EKTCipherTypes the 672 client is willing to use in preference order, with the most preferred 673 version first. When the server responds in the 674 "srtp_ekt_key_transport" in its ServerHello message, it MUST include 675 a SupportedEKTCiphers list that selects a single EKTCipherType to use 676 (selected from the list provided by the client) or it returns an 677 empty list to indicate there is no matching EKTCipherType in the 678 clients list that the server is also willing to use. The value to be 679 used in the EKTCipherType for future extensions that define new 680 ciphers is the value from the "EKT Ciphers Type" IANA registry 681 defined in Section 7.2. 683 The figure above defines the contents for a new TLS content type 684 called EKTMessage which is registered in Section 7.4. The EKTMessage 685 above is used as the opaque fragment in the TLSPlaintext structure 686 defined in Section 6.2.1 of [RFC5246] and the "srtp_ekt_message" as 687 the content type. The "srtp_ekt_message" content type is defined and 688 registered in Section 7.3. 690 ekt_ttl: The maximum amount of time, in seconds, that this 691 ekt_key_value can be used. The ekt_key_value in this message MUST 692 NOT be used for encrypting or decrypting information after the TTL 693 expires. 695 When the Server wishes to provide a new EKT Key, it can send 696 EKTMessage containing an EKTKey with the new key information. The 697 client MUST respond with an EKTMessage of type ekt_key_ack, if the 698 EKTKey was successfully processed and stored or respond with the the 699 ekt_key_error EKTMessage otherwise. 701 The diagram below shows a message flow of DTLS client and DTLS server 702 using the DTLS-SRTP Key Transport extension. 704 Client Server 706 ClientHello + use_srtp + srtp_ekt_key_trans 707 --------> 708 ServerHello+use_srtp+srtp_ekt_key_trans 709 Certificate* 710 ServerKeyExchange* 711 CertificateRequest* 712 <-------- ServerHelloDone 713 Certificate* 714 ClientKeyExchange 715 CertificateVerify* 716 [ChangeCipherSpec] 717 Finished --------> 718 [ChangeCipherSpec] 719 <-------- Finished 720 ekt_key <-------- 721 ekt_key_ack --------> 722 SRTP packets <-------> SRTP packets 723 SRTP packets <-------> SRTP packets 724 ekt_key (rekey) <------- 725 ekt_key_ack --------> 726 SRTP packets <-------> SRTP packets 727 SRTP packets <-------> SRTP packets 729 Figure 5: DTLS/SRTP Message Flow 731 5.3. Offer/Answer Considerations 733 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 734 the DTLS handshake level and does not change the [RFC3264] Offer / 735 Answer messaging. 737 5.4. Sending the DTLS EKT_Key Reliably 739 The DTLS ekt_key is sent using the retransmissions specified in 740 Section 4.2.4. of DTLS [RFC6347]. 742 6. Security Considerations 744 EKT inherits the security properties of the DTLS-SRTP (or other) 745 keying it uses. 747 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 748 master keys. This property avoids any security concern over the re- 749 use of keys, by empowering the SRTP layer to create keys on demand. 750 Note that the inputs of EKT are the same as for SRTP with key- 751 sharing: a single key is provided to protect an entire SRTP session. 752 However, EKT remains secure even when SSRC values collide. 754 SRTP master keys MUST be randomly generated, and [RFC4086] offers 755 some guidance about random number generation. SRTP master keys MUST 756 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 757 be derived from other SRTP master keys. 759 The EKT Cipher includes its own authentication/integrity check. For 760 an attacker to successfully forge a FullEKTField, it would need to 761 defeat the authentication mechanisms of the EKT Cipher authentication 762 mechanism. 764 The presence of the SSRC in the EKTPlaintext ensures that an attacker 765 cannot substitute an EKTCiphertext from one SRTP stream into another 766 SRTP stream. 768 An attacker who tampers with the bits in FullEKTField can prevent the 769 intended receiver of that packet from being able to decrypt it. This 770 is a minor denial of service vulnerability. Similarly the attacker 771 could take an old FullEKTField from the same session and attach it to 772 the packet. The FullEKTField would correctly decode and pass 773 integrity but the key extracted from the FullEKTField , when used to 774 decrypt the SRTP payload, would be wrong and the SRTP integrity check 775 would fail. Note that the FullEKTField only changes the decryption 776 key and does not change the encryption key. None of these are 777 considered significant attacks as any attacker that can modify the 778 packets in transit and cause the integrity check to fail. 780 An attacker could send packets containing a Full EKT Field, in an 781 attempt to consume additional CPU resources of the receiving system 782 by causing the receiving system will decrypt the EKT ciphertext and 783 detect an authentication failure. In some cases, caching the 784 previous values of the Ciphertext as described in Section 4.3 helps 785 mitigate this issue. 787 Each EKT cipher specifies a value T that is the maximum number of 788 times a given key can be used. An endpoint MUST NOT encrypt more 789 than T different Full EKT Field using the same EKTKey. In addition, 790 the EKTKey MUST NOT be used beyond the lifetime provided by the TTL 791 described in Section 5.2. 793 The confidentiality, integrity, and authentication of the EKT cipher 794 MUST be at least as strong as the SRTP cipher and at least as strong 795 as the DTLS-SRTP ciphers. 797 Part of the EKTPlaintext is known, or easily guessable to an 798 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 800 In practice, this requirement does not impose any restrictions on our 801 choices, since the ciphers in use provide high security even when 802 much plaintext is known. 804 An EKT cipher MUST resist attacks in which both ciphertexts and 805 plaintexts can be adaptively chosen and adversaries that can query 806 both the encryption and decryption functions adaptively. 808 In some systems, when a member of a conference leaves the 809 conferences, the conferences is rekeyed so that member no longer has 810 the key. When changing to a new EKTKey, it is possible that the 811 attacker could block the EKTKey message getting to a particular 812 endpoint and that endpoint would keep sending media encrypted using 813 the old key. To mitigate that risk, the lifetime of the EKTKey 814 SHOULD be limited using the ekt_ttl. 816 7. IANA Considerations 818 7.1. EKT Message Types 820 IANA is requested to create a new table for "EKT Messages Types" in 821 the "Real-Time Transport Protocol (RTP) Parameters" registry. The 822 initial values in this registry are: 824 +--------------+-------+---------------+ 825 | Message Type | Value | Specification | 826 +--------------+-------+---------------+ 827 | Short | 0 | RFCAAAA | 828 | | | | 829 | Full | 2 | RFCAAAA | 830 | | | | 831 | Reserved | 63 | RFCAAAA | 832 | | | | 833 | Reserved | 255 | RFCAAAA | 834 +--------------+-------+---------------+ 836 Table 2: EKT Messages Types 838 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 839 this specification. 841 New entries to this table can be added via "Specification Required" 842 as defined in [RFC5226]. When requesting a new value, the requestor 843 needs to indicate if it is mandatory to understand or not. If it is 844 mandatory to understand, IANA needs to allocate a value less than 64, 845 if it is not mandatory to understand, a value greater than or equal 846 to 64 needs to be allocated. IANA SHOULD prefer allocation of even 847 values over odd ones until the even code points are consumed to avoid 848 conflicts with pre standard versions of EKT that have been deployed. 850 All new EKT messages MUST be defined to have a length as second from 851 the last element. 853 7.2. EKT Ciphers 855 IANA is requested to create a new table for "EKT Ciphers" in the 856 "Real-Time Transport Protocol (RTP) Parameters" registry. The 857 initial values in this registry are: 859 +----------+-------+---------------+ 860 | Name | Value | Specification | 861 +----------+-------+---------------+ 862 | AESKW128 | 1 | RFCAAAA | 863 | | | | 864 | AESKW256 | 2 | RFCAAAA | 865 | | | | 866 | Reserved | 255 | RFCAAAA | 867 +----------+-------+---------------+ 869 Table 3: EKT Cipher Types 871 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 872 this specification. 874 New entries to this table can be added via "Specification Required" 875 as defined in [RFC5226]. The expert SHOULD ensure the specification 876 defines the values for L and T as required in Section 4.4 of RFCAAA. 877 Allocated values MUST be in the range of 1 to 254. 879 7.3. TLS Extensions 881 IANA is requested to add "srtp_ekt_key_transport" as an new extension 882 name to the "ExtensionType Values" table of the "Transport Layer 883 Security (TLS) Extensions" registry with a reference to this 884 specification and allocate a value of TBD to for this. Note to RFC 885 Editor: TBD will be allocated by IANA. 887 Considerations for this type of extension are described in Section 5 888 of [RFC4366] and requires "IETF Consensus". 890 7.4. TLS Content Type 892 IANA is requested to add "srtp_ekt_message" as an new descriptions 893 name to the "TLS ContentType Registry" table of the "Transport Layer 894 Security (TLS) Extensions" registry with a reference to this 895 specification, a DTLS-OK value of "Y", and allocate a value of TBD to 896 for this content type. Note to RFC Editor: TBD will be allocated by 897 IANA. 899 This registry was defined in Section 12 of [RFC5246] and requires 900 "Standards Action". 902 8. Acknowledgements 904 Thank you to Russ Housley provided detailed review and significant 905 help with crafting text for this document. Thanks to David Benham, 906 Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul 907 Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean 908 Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, 909 comments, and contributions to this document. 911 9. References 913 9.1. Normative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 921 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 922 RFC 3711, DOI 10.17487/RFC3711, March 2004, 923 . 925 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 926 "Randomness Requirements for Security", BCP 106, RFC 4086, 927 DOI 10.17487/RFC4086, June 2005, 928 . 930 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 931 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 932 DOI 10.17487/RFC5226, May 2008, 933 . 935 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 936 Specifications: ABNF", STD 68, RFC 5234, 937 DOI 10.17487/RFC5234, January 2008, 938 . 940 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 941 (TLS) Protocol Version 1.2", RFC 5246, 942 DOI 10.17487/RFC5246, August 2008, 943 . 945 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 946 (AES) Key Wrap with Padding Algorithm", RFC 5649, 947 DOI 10.17487/RFC5649, September 2009, 948 . 950 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 951 Security (DTLS) Extension to Establish Keys for the Secure 952 Real-time Transport Protocol (SRTP)", RFC 5764, 953 DOI 10.17487/RFC5764, May 2010, 954 . 956 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 957 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 958 January 2012, . 960 9.2. Informative References 962 [I-D.ietf-perc-double] 963 Jennings, C., Jones, P., and A. Roach, "SRTP Double 964 Encryption Procedures", draft-ietf-perc-double-02 (work in 965 progress), October 2016. 967 [I-D.ietf-perc-private-media-framework] 968 Jones, P., Benham, D., and C. Groves, "A Solution 969 Framework for Private Media in Privacy Enhanced RTP 970 Conferencing", draft-ietf-perc-private-media-framework-02 971 (work in progress), October 2016. 973 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 974 with Session Description Protocol (SDP)", RFC 3264, 975 DOI 10.17487/RFC3264, June 2002, 976 . 978 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 979 and T. Wright, "Transport Layer Security (TLS) 980 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 981 . 983 Authors' Addresses 984 Cullen Jennings 985 Cisco Systems 986 Calgary, AB 987 Canada 989 Email: fluffy@iii.ca 991 John Mattsson (editor) 992 Ericsson AB 993 SE-164 80 Stockholm 994 Sweden 996 Phone: +46 10 71 43 501 997 Email: john.mattsson@ericsson.com 999 David A. McGrew 1000 Cisco Systems 1001 510 McCarthy Blvd. 1002 Milpitas, CA 95035 1003 US 1005 Phone: (408) 525 8651 1006 Email: mcgrew@cisco.com 1007 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1009 Dan Wing 1010 Cisco Systems 1011 510 McCarthy Blvd. 1012 Milpitas, CA 95035 1013 US 1015 Phone: (408) 853 4197 1016 Email: dwing@cisco.com 1018 Flemming Andreason 1019 Cisco Systems 1020 499 Thornall Street 1021 Edison, NJ 08837 1022 US 1024 Email: fandreas@cisco.com