idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-05.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 (June 29, 2017) is 2493 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: December 31, 2017 Ericsson 6 D. McGrew 7 D. Wing 8 F. Andreasen 9 Cisco 10 June 29, 2017 12 Encrypted Key Transport for DTLS and Secure RTP 13 draft-ietf-perc-srtp-ekt-diet-05 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 December 31, 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 . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 21 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 9.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 Note that when used in PERC [I-D.ietf-perc-private-media-framework], 732 the Server is actually split between the Media Distrbutor and Key 733 Distributor. The messages in the above figure that are "SRTP 734 packets" will not got to the Key Distributor but the oter packets 735 will be relayed by the Media Distributor to the Key Distributor. 737 5.3. Offer/Answer Considerations 739 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 740 the DTLS handshake level and does not change the [RFC3264] Offer / 741 Answer messaging. 743 5.4. Sending the DTLS EKT_Key Reliably 745 The DTLS ekt_key is sent using the retransmissions specified in 746 Section 4.2.4. of DTLS [RFC6347]. 748 6. Security Considerations 750 EKT inherits the security properties of the DTLS-SRTP (or other) 751 keying it uses. 753 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 754 master keys. This property avoids any security concern over the re- 755 use of keys, by empowering the SRTP layer to create keys on demand. 756 Note that the inputs of EKT are the same as for SRTP with key- 757 sharing: a single key is provided to protect an entire SRTP session. 758 However, EKT remains secure even when SSRC values collide. 760 SRTP master keys MUST be randomly generated, and [RFC4086] offers 761 some guidance about random number generation. SRTP master keys MUST 762 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 763 be derived from other SRTP master keys. 765 The EKT Cipher includes its own authentication/integrity check. For 766 an attacker to successfully forge a FullEKTField, it would need to 767 defeat the authentication mechanisms of the EKT Cipher authentication 768 mechanism. 770 The presence of the SSRC in the EKTPlaintext ensures that an attacker 771 cannot substitute an EKTCiphertext from one SRTP stream into another 772 SRTP stream. 774 An attacker who tampers with the bits in FullEKTField can prevent the 775 intended receiver of that packet from being able to decrypt it. This 776 is a minor denial of service vulnerability. Similarly the attacker 777 could take an old FullEKTField from the same session and attach it to 778 the packet. The FullEKTField would correctly decode and pass 779 integrity but the key extracted from the FullEKTField , when used to 780 decrypt the SRTP payload, would be wrong and the SRTP integrity check 781 would fail. Note that the FullEKTField only changes the decryption 782 key and does not change the encryption key. None of these are 783 considered significant attacks as any attacker that can modify the 784 packets in transit and cause the integrity check to fail. 786 An attacker could send packets containing a Full EKT Field, in an 787 attempt to consume additional CPU resources of the receiving system 788 by causing the receiving system will decrypt the EKT ciphertext and 789 detect an authentication failure. In some cases, caching the 790 previous values of the Ciphertext as described in Section 4.3 helps 791 mitigate this issue. 793 Each EKT cipher specifies a value T that is the maximum number of 794 times a given key can be used. An endpoint MUST NOT encrypt more 795 than T different Full EKT Field using the same EKTKey. In addition, 796 the EKTKey MUST NOT be used beyond the lifetime provided by the TTL 797 described in Section 5.2. 799 The confidentiality, integrity, and authentication of the EKT cipher 800 MUST be at least as strong as the SRTP cipher and at least as strong 801 as the DTLS-SRTP ciphers. 803 Part of the EKTPlaintext is known, or easily guessable to an 804 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 805 In practice, this requirement does not impose any restrictions on our 806 choices, since the ciphers in use provide high security even when 807 much plaintext is known. 809 An EKT cipher MUST resist attacks in which both ciphertexts and 810 plaintexts can be adaptively chosen and adversaries that can query 811 both the encryption and decryption functions adaptively. 813 In some systems, when a member of a conference leaves the 814 conferences, the conferences is rekeyed so that member no longer has 815 the key. When changing to a new EKTKey, it is possible that the 816 attacker could block the EKTKey message getting to a particular 817 endpoint and that endpoint would keep sending media encrypted using 818 the old key. To mitigate that risk, the lifetime of the EKTKey 819 SHOULD be limited using the ekt_ttl. 821 7. IANA Considerations 823 7.1. EKT Message Types 825 IANA is requested to create a new table for "EKT Messages Types" in 826 the "Real-Time Transport Protocol (RTP) Parameters" registry. The 827 initial values in this registry are: 829 +--------------+-------+---------------+ 830 | Message Type | Value | Specification | 831 +--------------+-------+---------------+ 832 | Short | 0 | RFCAAAA | 833 | | | | 834 | Full | 2 | RFCAAAA | 835 | | | | 836 | Reserved | 63 | RFCAAAA | 837 | | | | 838 | Reserved | 255 | RFCAAAA | 839 +--------------+-------+---------------+ 841 Table 2: EKT Messages Types 843 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 844 this specification. 846 New entries to this table can be added via "Specification Required" 847 as defined in [RFC5226]. When requesting a new value, the requestor 848 needs to indicate if it is mandatory to understand or not. If it is 849 mandatory to understand, IANA needs to allocate a value less than 64, 850 if it is not mandatory to understand, a value greater than or equal 851 to 64 needs to be allocated. IANA SHOULD prefer allocation of even 852 values over odd ones until the even code points are consumed to avoid 853 conflicts with pre standard versions of EKT that have been deployed. 855 All new EKT messages MUST be defined to have a length as second from 856 the last element. 858 7.2. EKT Ciphers 860 IANA is requested to create a new table for "EKT Ciphers" in the 861 "Real-Time Transport Protocol (RTP) Parameters" registry. The 862 initial values in this registry are: 864 +----------+-------+---------------+ 865 | Name | Value | Specification | 866 +----------+-------+---------------+ 867 | AESKW128 | 1 | RFCAAAA | 868 | | | | 869 | AESKW256 | 2 | RFCAAAA | 870 | | | | 871 | Reserved | 255 | RFCAAAA | 872 +----------+-------+---------------+ 874 Table 3: EKT Cipher Types 876 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 877 this specification. 879 New entries to this table can be added via "Specification Required" 880 as defined in [RFC5226]. The expert SHOULD ensure the specification 881 defines the values for L and T as required in Section 4.4 of RFCAAA. 882 Allocated values MUST be in the range of 1 to 254. 884 7.3. TLS Extensions 886 IANA is requested to add "srtp_ekt_key_transport" as an new extension 887 name to the "ExtensionType Values" table of the "Transport Layer 888 Security (TLS) Extensions" registry with a reference to this 889 specification and allocate a value of TBD to for this. Note to RFC 890 Editor: TBD will be allocated by IANA. 892 Considerations for this type of extension are described in Section 5 893 of [RFC4366] and requires "IETF Consensus". 895 7.4. TLS Content Type 897 IANA is requested to add "srtp_ekt_message" as an new descriptions 898 name to the "TLS ContentType Registry" table of the "Transport Layer 899 Security (TLS) Extensions" registry with a reference to this 900 specification, a DTLS-OK value of "Y", and allocate a value of TBD to 901 for this content type. Note to RFC Editor: TBD will be allocated by 902 IANA. 904 This registry was defined in Section 12 of [RFC5246] and requires 905 "Standards Action". 907 8. Acknowledgements 909 Thank you to Russ Housley provided detailed review and significant 910 help with crafting text for this document. Thanks to David Benham, 911 Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul 912 Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean 913 Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, 914 comments, and contributions to this document. 916 9. References 918 9.1. Normative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 926 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 927 RFC 3711, DOI 10.17487/RFC3711, March 2004, 928 . 930 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 931 "Randomness Requirements for Security", BCP 106, RFC 4086, 932 DOI 10.17487/RFC4086, June 2005, 933 . 935 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 936 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 937 DOI 10.17487/RFC5226, May 2008, 938 . 940 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 941 Specifications: ABNF", STD 68, RFC 5234, 942 DOI 10.17487/RFC5234, January 2008, 943 . 945 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 946 (TLS) Protocol Version 1.2", RFC 5246, 947 DOI 10.17487/RFC5246, August 2008, 948 . 950 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 951 (AES) Key Wrap with Padding Algorithm", RFC 5649, 952 DOI 10.17487/RFC5649, September 2009, 953 . 955 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 956 Security (DTLS) Extension to Establish Keys for the Secure 957 Real-time Transport Protocol (SRTP)", RFC 5764, 958 DOI 10.17487/RFC5764, May 2010, 959 . 961 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 962 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 963 January 2012, . 965 9.2. Informative References 967 [I-D.ietf-perc-double] 968 Jennings, C., Jones, P., and A. Roach, "SRTP Double 969 Encryption Procedures", draft-ietf-perc-double-02 (work in 970 progress), October 2016. 972 [I-D.ietf-perc-private-media-framework] 973 Jones, P., Benham, D., and C. Groves, "A Solution 974 Framework for Private Media in Privacy Enhanced RTP 975 Conferencing", draft-ietf-perc-private-media-framework-02 976 (work in progress), October 2016. 978 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 979 with Session Description Protocol (SDP)", RFC 3264, 980 DOI 10.17487/RFC3264, June 2002, 981 . 983 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 984 and T. Wright, "Transport Layer Security (TLS) 985 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 986 . 988 Authors' Addresses 990 Cullen Jennings 991 Cisco Systems 992 Calgary, AB 993 Canada 995 Email: fluffy@iii.ca 997 John Mattsson (editor) 998 Ericsson AB 999 SE-164 80 Stockholm 1000 Sweden 1002 Phone: +46 10 71 43 501 1003 Email: john.mattsson@ericsson.com 1005 David A. McGrew 1006 Cisco Systems 1007 510 McCarthy Blvd. 1008 Milpitas, CA 95035 1009 US 1011 Phone: (408) 525 8651 1012 Email: mcgrew@cisco.com 1013 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1015 Dan Wing 1016 Cisco Systems 1017 510 McCarthy Blvd. 1018 Milpitas, CA 95035 1019 US 1021 Phone: (408) 853 4197 1022 Email: dwing@cisco.com 1024 Flemming Andreason 1025 Cisco Systems 1026 499 Thornall Street 1027 Edison, NJ 08837 1028 US 1030 Email: fandreas@cisco.com