idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ack' is mentioned on line 651, but not defined == Missing Reference: 'EKTKey' is mentioned on line 649, 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-07 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-02 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Mattsson 5 Expires: May 3, 2018 Ericsson AB 6 D. McGrew 7 D. Wing 8 F. Andreason 9 Cisco Systems 10 October 30, 2017 12 Encrypted Key Transport for DTLS and Secure RTP 13 draft-ietf-perc-srtp-ekt-diet-06 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 May 3, 2018. 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 . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Packet Processing and State Machine . . . . . . . . . . . 7 64 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 65 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 66 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 67 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 12 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.2.1. Negotiating an EKT Cipher . . . . . . . . . . . . . . 16 77 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16 78 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 79 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 83 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 84 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21 85 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 9.2. Informative References . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 Real-time Transport Protocol (RTP) is designed to allow decentralized 95 groups with minimal control to establish sessions, such as for 96 multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) 97 cannot be used in many minimal-control scenarios, because it requires 98 that synchronization source (SSRC) values and other data be 99 coordinated among all of the participants in a session. For example, 100 if a participant joins a session that is already in progress, that 101 participant needs to be told the SRTP keys along with the SSRC, 102 rollover counter (ROC) and other details of the other SRTP sources. 104 The inability of SRTP to work in the absence of central control was 105 well understood during the design of the protocol; the omission was 106 considered less important than optimizations such as bandwidth 107 conservation. Additionally, in many situations SRTP is used in 108 conjunction with a signaling system that can provide the central 109 control needed by SRTP. However, there are several cases in which 110 conventional signaling systems cannot easily provide all of the 111 coordination required. It is also desirable to eliminate the layer 112 violations that occur when signaling systems coordinate certain SRTP 113 parameters, such as SSRC values and ROCs. 115 This document defines Encrypted Key Transport (EKT) for SRTP and 116 reduces the amount of external signaling control that is needed in a 117 SRTP session with multiple receivers. EKT securely distributes the 118 SRTP master key and other information for each SRTP source. With 119 this method, SRTP entities are free to choose SSRC values as they see 120 fit, and to start up new SRTP sources with new SRTP master keys (see 121 Section 2.2) within a session without coordinating with other 122 entities via external signaling or other external means. 124 EKT provides a way for an SRTP session participant, either a sender 125 or receiver, to securely transport its SRTP master key and current 126 SRTP rollover counter to the other participants in the session. This 127 data furnishes the information needed by the receiver to instantiate 128 an SRTP/SRTCP receiver context. 130 EKT can be used in conferences where the central media distributor or 131 conference bridge can not decrypt the media, such as the type defined 132 for [I-D.ietf-perc-private-media-framework]. It can also be used for 133 large scale conferences where the conference bridge or media 134 distributor can decrypt all the media but wishes to encrypt the media 135 it is sending just once then send the same encrypted media to a large 136 number of participants. This reduces the amount of CPU time needed 137 for encryption and can be used for some optimization to media sending 138 that use source specific multicast. 140 EKT does not control the manner in which the SSRC is generated; it is 141 only concerned with their secure transport. 143 EKT is not intended to replace external key establishment mechanisms. 144 Instead, it is used in conjunction with those methods, and it 145 relieves those methods of the burden to deliver the context for each 146 SRTP source to every SRTP participant. 148 2. Overview 150 This specification defines a way for the server in a DTLS-SRTP 151 negotiation to provide an ekt_key to the client during the DTLS 152 handshake. This ekt_key can be used to encrypt the SRTP master key 153 used to encrypt the media the endpoint sends. This specification 154 also defines a way to send the encrypted SRTP master key along with 155 the SRTP packet. Endpoints that receive this and know the ekt_key 156 can use the ekt_key to decrypt the SRTP master key then use the SRTP 157 master key to decrypt the SRTP packet. 159 One way to use this is used is described in the architecture defined 160 by [I-D.ietf-perc-private-media-framework]. Each participants in the 161 conference call forms a DTLS-SRTP connection to a common key 162 distributor that gives all the endpoints the same ekt_key. Then each 163 endpoint picks there own SRTP master key for the media they send. 164 When sending media, the endpoint also includes the SRTP master key 165 encrypted with the ekt_key. This allows all the endpoints to decrypt 166 the media. 168 3. Conventions Used In This Document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 4. Encrypted Key Transport 176 EKT defines a new method of providing SRTP master keys to an 177 endpoint. In order to convey the ciphertext corresponding to the 178 SRTP master key, and other additional information, an additional EKT 179 field is added to SRTP packets. The EKT field appears at the end of 180 the SRTP packet. The EKT field appears after the optional 181 authentication tag if one is present, otherwise the EKT field appears 182 after the ciphertext portion of the packet. 184 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 185 Identifier) or with SRTP's [RFC3711], as those SRTP 186 features duplicate some of the functions of EKT. Senders MUST NOT 187 include MKI when using EKT. Receivers SHOULD simply ignore any MKI 188 field received if EKT is in use. 190 4.1. EKT Field Formats 192 The EKT Field uses the format defined below for the FullEKTField and 193 ShortEKTField. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 : : 199 : EKT Ciphertext : 200 : : 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Security Parameter Index | Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |0 0 0 0 0 0 1 0| 205 +-+-+-+-+-+-+-+-+ 207 Figure 1: Full EKT Field format 209 0 1 2 3 4 5 6 7 210 +-+-+-+-+-+-+-+-+ 211 |0 0 0 0 0 0 0 0| 212 +-+-+-+-+-+-+-+-+ 214 Figure 2: Short EKT Field format 216 The following shows the syntax of the EKTField expressed in ABNF 217 [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP 218 packet. The EKTPlaintext is the concatenation of 219 SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The 220 EKTCiphertext is computed by encrypting the EKTPlaintext using the 221 EKTKey. Future extensions to the EKTField MUST conform to the syntax 222 of ExtensionEKTField. 224 BYTE = %x00-FF 226 EKTMsgTypeFull = %x02 227 EKTMsgTypeShort = %x00 228 EKTMsgTypeExtension = %x03-FF 230 EKTMsgLength = 2BYTE; 232 SRTPMasterKeyLength = BYTE 233 SRTPMasterKey = 1*256BYTE 234 SSRC = 4BYTE; SSRC from RTP 235 ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC 237 EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 239 EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 240 SPI = 2BYTE 242 FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull 244 ShortEKTField = EKTMsgTypeShort 246 ExtensionData = 1*1024BYTE 247 ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 249 EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 251 Figure 3: EKTField Syntax 253 These fields and data elements are defined as follows: 255 EKTPlaintext: The data that is input to the EKT encryption operation. 256 This data never appears on the wire, and is used only in computations 257 internal to EKT. This is the concatenation of the SRTP Master Key, 258 the SSRC, and the ROC. 260 EKTCiphertext: The data that is output from the EKT encryption 261 operation, described in Section 4.4. This field is included in SRTP 262 packets when EKT is in use. The length of EKTCiphertext can be 263 larger than the length of the EKTPlaintext that was encrypted. 265 SRTPMasterKey: On the sender side, the SRTP Master Key associated 266 with the indicated SSRC. 268 SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This 269 depends on the cipher suite negotiated for SRTP using SDP Offer/ 270 Answer [RFC3264] for the SRTP. 272 SSRC: On the sender side, this field is the SSRC for this SRTP 273 source. The length of this field is 32 bits. 275 Rollover Counter (ROC): On the sender side, this field is set to the 276 current value of the SRTP rollover counter in the SRTP context 277 associated with the SSRC in the SRTP or SRTCP packet. The length of 278 this field is 32 bits. 280 Security Parameter Index (SPI): This field indicates the appropriate 281 EKT Key and other parameters for the receiver to use when processing 282 the packet. The length of this field is 16 bits. The parameters 283 identified by this field are: 285 o The EKT cipher used to process the packet. 287 o The EKT Key used to process the packet. 289 o The SRTP Master Salt associated with any Master Key encrypted with 290 this EKT Key. The Master Salt is communicated separately, via 291 signaling, typically along with the EKTKey. 293 Together, these data elements are called an EKT parameter set. Each 294 distinct EKT parameter set that is used MUST be associated with a 295 distinct SPI value to avoid ambiguity. 297 EKTMsgLength: All EKT message other that ShortEKTField have a length 298 as second from the last element. This is the length in octets of 299 either the FullEKTField/ExtensionEKTField including this length field 300 and the following message type. 302 Message Type: The last byte is used to indicate the type of the 303 EKTField. This MUST be 2 in the FullEKTField format and 0 in 304 ShortEKTField format. Values less than 64 are mandatory to 305 understand while other values are optional to understand. A receiver 306 SHOULD discard the whole EKTField if it contains any message type 307 value that is less than 64 and that is not understood. Message type 308 values that are 64 or greater but not implemented or understood can 309 simply be ignored. 311 4.2. Packet Processing and State Machine 313 At any given time, each SRTP/SRTCP source has associated with it a 314 single EKT parameter set. This parameter set is used to process all 315 outbound packets, and is called the outbound parameter set for that 316 SSRC. There may be other EKT parameter sets that are used by other 317 SRTP/SRTCP sources in the same session, including other SRTP/SRTCP 318 sources on the same endpoint (e.g., one endpoint with voice and video 319 might have two EKT parameter sets, or there might be multiple video 320 sources on an endpoint each with their own EKT parameter set). All 321 of the received EKT parameter sets SHOULD be stored by all of the 322 participants in an SRTP session, for use in processing inbound SRTP 323 and SRTCP traffic. 325 Either the FullEKTField or ShortEKTField is appended at the tail end 326 of all SRTP packets. The decision on which to send is specified in 327 Section 4.7. 329 4.2.1. Outbound Processing 331 See Section 4.7 which describes when to send an SRTP packet with a 332 FullEKTField. If a FullEKTField is not being sent, then a 333 ShortEKTField is sent so the receiver can correctly determine how to 334 process the packet. 336 When an SRTP packet is sent with a FullEKTField, the EKTField for 337 that packet is created as follows, or uses an equivalent set of 338 steps. The creation of the EKTField MUST precede the normal SRTP 339 packet processing. 341 1. The Security Parameter Index (SPI) field is set to the value of 342 the Security Parameter Index that is associated with the outbound 343 parameter set. 345 2. The EKTPlaintext field is computed from the SRTP Master Key, 346 SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP 347 Master Key, and SSRC used in EKT processing SHOULD be the same as 348 the one used in the SRTP processing. 350 3. The EKTCiphertext field is set to the ciphertext created by 351 encrypting the EKTPlaintext with the EKT cipher, using the EKTKey 352 as the encryption key. The encryption process is detailed in 353 Section 4.4. 355 4. Then the FullEKTField is formed using the EKTCiphertext and the 356 SPI associated with the EKTKey used above. Also appended are the 357 Length and Message Type using the FullEKTField format. 359 * Note: the value of the EKTCiphertext field is identical in 360 successive packets protected by the same EKTKey and SRTP 361 master key. This value MAY be cached by an SRTP sender to 362 minimize computational effort. 364 The computed value of the FullEKTField is written into the 365 packet. 367 When a packet is sent with the Short EKT Field, the ShortEKFField is 368 simply appended to the packet. 370 4.2.2. Inbound Processing 372 When receiving a packet on a RTP stream, the following steps are 373 applied for each received packet. 375 1. The final byte is checked to determine which EKT format is in 376 use. When an SRTP or SRTCP packet contains a ShortEKTField, the 377 ShortEKTField is removed from the packet then normal SRTP or 378 SRTCP processing occurs. If the packet contains a FullEKTField, 379 then processing continues as described below. The reason for 380 using the last byte of the packet to indicate the type is that 381 the length of the SRTP or SRTCP part is not known until the 382 decryption has occurred. At this point in the processing, there 383 is no easy way to know where the EKT field would start. However, 384 the whole UDP packet has been received so instead of the starting 385 at the front of the packet, the parsing works backwards off the 386 end of the packet and thus the type is put at the very end of the 387 packet. 389 2. The Security Parameter Index (SPI) field is used to find which 390 EKT parameter set to be used when processing the packet. If 391 there is no matching SPI, then the verification function MUST 392 return an indication of authentication failure, and the steps 393 described below are not performed. The EKT parameter set 394 contains the EKTKey, EKTCipher, and SRTP Master Salt. 396 3. The EKTCiphertext authentication is checked and it is decrypted, 397 as described in Section 4.4, using the EKTKey and EKTCipher found 398 in the previous step. If the EKT decryption operation returns an 399 authentication failure, then the packet processing stops. 401 4. The resulting EKTPlaintext is parsed as described in Section 4.1, 402 to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP 403 Master Salt that is associated with the EKTKey is also retrieved. 404 If the value of the srtp_master_salt sent as part of the EKTkey 405 is longer than needed by SRTP, then it is truncated by taking the 406 first N bytes from the srtp_master_salt field. 408 5. If the SSRC in the EKTPlaintext does not match the SSRC of the 409 SRTP packet, then all the information from this EKTPlaintext MUST 410 be discarded and the following steps in this list are not done. 412 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 413 step are saved in a map indexed by the SSRC found in the 414 EKTPlaintext and can be used for any future crypto operations on 415 the inbound packets with that SSRC. If the SRTP Master Key 416 recovered from the EKTPlaintext is longer than needed by SRTP 417 transform in use, the first bytes are used. If the SRTP Master 418 Key recovered from the EKTPlaintext is shorter than needed by 419 SRTP transform in use, then the bytes received replace the first 420 bytes in the existing key but the other bytes after that remain 421 the same as the old key. This allows for replacing just half the 422 key for transforms such as [I-D.ietf-perc-double]. Outbound 423 packets SHOULD continue to use the old SRTP Master Key for 250 ms 424 after sending any new key. This gives all the receivers in the 425 system time to get the new key before they start receiving media 426 encrypted with the new key. 428 7. At this point, EKT processing has successfully completed, and the 429 normal SRTP or SRTCP processing takes place including replay 430 protection. 432 4.3. Implementation Notes 434 The value of the EKTCiphertext field is identical in successive 435 packets protected by the same EKT parameter set and the same SRTP 436 master key, and ROC. This ciphertext value MAY be cached by an SRTP 437 receiver to minimize computational effort by noting when the SRTP 438 master key is unchanged and avoiding repeating the above steps. 440 The receiver may want to have a sliding window to retain old SRTP 441 master keys (and related context) for some brief period of time, so 442 that out of order packets can be processed as well as packets sent 443 during the time keys are changing. 445 When receiving a new EKTKey, implementations need to use the ekt_ttl 446 to create a time after which this key cannot be used and they also 447 need to create a counter that keeps track of how many times the keys 448 has been used to encrypt data to ensure it does not exceed the T 449 value for that cipher. If either of these limits are exceeded, the 450 key can no longer be used for encryption. At this point 451 implementation need to either use the call signaling to renegotiation 452 a new session or need to terminate the existing session. Terminating 453 the session is a reasonable implementation choice because these 454 limits should not be exceeded except under an attack or error 455 condition. 457 4.4. Ciphers 459 EKT uses an authenticated cipher to encrypt and authenticate the 460 EKTPlaintext. This specification defines the interface to the 461 cipher, in order to abstract the interface away from the details of 462 that function. This specification also defines the default cipher 463 that is used in EKT. The default cipher described in Section 4.4.1 464 MUST be implemented, but another cipher that conforms to this 465 interface MAY be used. 467 An EKTCipher consists of an encryption function and a decryption 468 function. The encryption function E(K, P) takes the following 469 inputs: 471 o a secret key K with a length of L bytes, and 473 o a plaintext value P with a length of M bytes. 475 The encryption function returns a ciphertext value C whose length is 476 N bytes, where N may be larger than M. The decryption function D(K, 477 C) takes the following inputs: 479 o a secret key K with a length of L bytes, and 481 o a ciphertext value C with a length of N bytes. 483 The decryption function returns a plaintext value P that is M bytes 484 long, or returns an indication that the decryption operation failed 485 because the ciphertext was invalid (i.e. it was not generated by the 486 encryption of plaintext with the key K). 488 These functions have the property that D(K, E(K, P)) = P for all 489 values of K and P. Each cipher also has a limit T on the number of 490 times that it can be used with any fixed key value. The EKTKey MUST 491 NOT be used for encryption more that T times. Note that if the same 492 FullEKTField is retransmitted 3 times, that only counts as 1 493 encryption. 495 Security requirements for EKT ciphers are discussed in Section 6. 497 4.4.1. Ciphers 499 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 500 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 501 length M that is at least one octet, and it returns a ciphertext with 502 a length of N = M + (M mod 8) + 8 octets. It can be used with key 503 sizes of L = 16, and L = 32 octets, and its use with those key sizes 504 is indicated as AESKW128, or AESKW256, respectively. The key size 505 determines the length of the AES key used by the Key Wrap algorithm. 506 With this cipher, T=2^48. 508 +----------+----+------+ 509 | Cipher | L | T | 510 +----------+----+------+ 511 | AESKW128 | 16 | 2^48 | 512 | AESKW256 | 32 | 2^48 | 513 +----------+----+------+ 515 Table 1: EKT Ciphers 517 As AES-128 is the mandatory to implement transform in SRTP, AESKW128 518 MUST be implemented for EKT and AESKW256 MAY be implemented. 520 4.4.2. Defining New EKT Ciphers 522 Other specifications may extend this document by defining other 523 EKTCiphers as described in Section 7. This section defines how those 524 ciphers interact with this specification. 526 An EKTCipher determines how the EKTCiphertext field is written, and 527 how it is processed when it is read. This field is opaque to the 528 other aspects of EKT processing. EKT ciphers are free to use this 529 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 530 an input. The values of the parameters L, and T MUST be defined by 531 each EKTCipher. The cipher MUST provide integrity protection. 533 4.5. Synchronizing Operation 535 If a source has its EKTKey changed by the key management, it MUST 536 also change its SRTP master key, which will cause it to send out a 537 new FullEKTField. This ensures that if key management thought the 538 EKTKey needs changing (due to a participant leaving or joining) and 539 communicated that to a source, the source will also change its SRTP 540 master key, so that traffic can be decrypted only by those who know 541 the current EKTKey. 543 4.6. Transport 545 EKT SHOULD be used over SRTP, and other specification MAY define how 546 to use it over SRTCP. SRTP is preferred because it shares fate with 547 transmitted media, because SRTP rekeying can occur without concern 548 for RTCP transmission limits, and to avoid SRTCP compound packets 549 with RTP translators and mixers. 551 4.7. Timing and Reliability Consideration 553 A system using EKT learns the SRTP master keys distributed with 554 FullEKTFields sent with the SRTP, rather than with call signaling. A 555 receiver can immediately decrypt an SRTP packet, provided the SRTP 556 packet contains a Full EKT Field. 558 This section describes how to reliably and expediently deliver new 559 SRTP master keys to receivers. 561 There are three cases to consider. The first case is a new sender 562 joining a session which needs to communicate its SRTP master key to 563 all the receivers. The second case is a sender changing its SRTP 564 master key which needs to be communicated to all the receivers. The 565 third case is a new receiver joining a session already in progress 566 which needs to know the sender's SRTP master key. 568 The three cases are: 570 New sender: 571 A new sender SHOULD send a packet containing the FullEKTField as 572 soon as possible, always before or coincident with sending its 573 initial SRTP packet. To accommodate packet loss, it is 574 RECOMMENDED that three consecutive packets contain the Full EKT 575 Field be transmitted. 577 Rekey: 578 By sending EKT over SRTP, the rekeying event shares fate with the 579 SRTP packets protected with that new SRTP master key. To 580 accommodate packet loss, it is RECOMMENDED that three consecutive 581 packets contain the FullEKTField be transmitted. 583 New receiver: 584 When a new receiver joins a session it does not need to 585 communicate its sending SRTP master key (because it is a 586 receiver). When a new receiver joins a session the sender is 587 generally unaware of the receiver joining the session. Thus, 588 senders SHOULD periodically transmit the FullEKTField. That 589 interval depends on how frequently new receivers join the session, 590 the acceptable delay before those receivers can start processing 591 SRTP packets, and the acceptable overhead of sending the FullEKT 592 Field. If sending audio and video, the RECOMMENDED frequency is 593 the same as the rate of intra coded video frames. If only sending 594 audio, the RECOMMENDED frequency is every 100ms. 596 5. Use of EKT with DTLS-SRTP 598 This document defines an extension to DTLS-SRTP called SRTP EKT Key 599 Transport which enables secure transport of EKT keying material from 600 the DTLS-SRTP peer in the server role to the client. This allows 601 those peers to process EKT keying material in SRTP (or SRTCP) and 602 retrieve the embedded SRTP keying material. This combination of 603 protocols is valuable because it combines the advantages of DTLS, 604 which has strong authentication of the endpoint and flexibility, 605 along with allowing secure multiparty RTP with loose coordination and 606 efficient communication of per-source keys. 608 5.1. DTLS-SRTP Recap 610 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 611 to exchange keying material, algorithms, and parameters for SRTP. 612 The SRTP flow operates over the same transport as the DTLS-SRTP 613 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 614 performance and encryption flexibility benefits of SRTP with the 615 flexibility and convenience of DTLS-integrated key and association 616 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 617 key management method for SRTP, and a new RTP-specific data format 618 for DTLS. 620 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 622 This document defines a new TLS negotiated extension 623 supported_ekt_ciphers and a new TLS handshake message type ekt_key. 624 The extension negotiates the cipher to be used in encrypting and 625 decrypting EKTCiphertext values, and the handshake message carries 626 the corresponding key. 628 The diagram below shows a message flow of DTLS 1.3 client and server 629 using EKT configured using the DTLS extensions described in this 630 section. (The initial cookie exchange and other normal DTLS messages 631 are omitted.) 632 Client Server 634 ClientHello 635 + use_srtp 636 + supported_ekt_ciphers 637 --------> 639 ServerHello 640 {EncryptedExtensions} 641 + use_srtp 642 + supported_ekt_ciphers 643 {... Finished} 644 <-------- 646 {... Finished} --------> 648 [Ack] 649 <-------- [EKTKey] 651 [Ack] --------> 653 |SRTP packets| <-------> |SRTP packets| 654 + + 656 {} Messages protected using DTLS handshake keys 658 [] Messages protected using DTLS application traffic keys 660 <> Messages protected using the EKTKey and EKT cipher 662 || Messages protected using the SRTP Master Key sent in 663 a Full EKT Tag 665 Figure 4 667 In the context of a multi-party SRTP session in which each endpoint 668 performs a DTLS handshake as a client with a central DTLS server, the 669 extensions defined in this session allow the DTLS server to set a 670 common EKT key among all participants. Each endpoint can then use 671 EKT tags encrypted with that common key to inform other endpoint of 672 the keys it is using to protect SRTP packet. This avoids the need 673 for many individual DTLS handshakes among the endpoints, at the cost 674 of preventing endpoints from directly authenticating one another. 676 Client A Server Client B 678 <----DTLS Handshake----> 679 <--------EKTKey--------- 680 <----DTLS Handshake----> 681 ---------EKTKey--------> 683 -------------SRTP Packet + EKT Tag-------------> 684 <------------SRTP Packet + EKT Tag-------------- 686 5.2.1. Negotiating an EKT Cipher 688 To indicate its support for EKT, a DTLS-SRTP client includes in its 689 ClientHello an extension of type supported_ekt_ciphers listing the 690 EKT ciphers the client supports in preference order, with the most 691 preferred version first. If the server agrees to use EKT, then it 692 includes a supported_ekt_ciphers extension in its ServerHello 693 containing a cipher selected from among those advertised by the 694 client. 696 The extension_data field of this extension contains an "EKTCipher" 697 value, encoded using the syntax defined in [RFC5246]: 699 enum { 700 reserved(0), 701 aeskw_128(1), 702 aeskw_256(2), 703 } EKTCipherType; 705 struct { 706 select (Handshake.msg_type) { 707 case client_hello: 708 EKTCipherType supported_ciphers<1..255>; 710 case server_hello: 711 EKTCipherType selected_cipher; 712 }; 713 } EKTCipher; 715 5.2.2. Establishing an EKT Key 717 Once a client and server have concluded a handshake that negotiated 718 an EKT cipher, the server MUST provide to the client a key to be used 719 when encrypting and decrypting EKTCiphertext values. EKT keys are 720 sent in encrypted handshake records, using handshake type 721 ekt_key(TBD). The body of the handshake message contains an EKTKey 722 structure: 724 [[ NOTE: RFC Editor, please replace "TBD" above with the code point 725 assigend by IANA ]] 727 struct { 728 opaque ekt_key_value<1..256>; 729 opaque srtp_master_salt<1..256>; 730 uint16 ekt_spi; 731 uint24 ekt_ttl; 732 } EKTKey; 734 The contents of the fields in this message are as follows: 736 ekt_key_value 737 The EKT Key that the recipient should use when generating 738 EKTCiphertext values 740 srtp_master_salt 741 The SRTP Master Salt to be used with any Master Key encrypted with 742 this EKT Key 744 ekt_spi 745 The SPI value to be used to reference this EKT Key and SRTP Master 746 Salt in EKT tags (along with the EKT cipher negotiated in the 747 handshake) 749 ekt_ttl 750 The maximum amount of time, in seconds, that this EKT Key can be 751 used. The ekt_key_value in this message MUST NOT be used for 752 encrypting or decrypting information after the TTL expires. 754 If the server did not provide a supported_ekt_ciphers extension in 755 its ServerHello, then EKTKey messages MUST NOT be sent by either the 756 client or the server. 758 When an EKTKey is received and processed successfully, the recipient 759 MUST respond with an Ack handshake message as described in Section 7 760 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be 761 retransmitted following the rules in Secton 4.2.4 of [RFC6347]. 763 Note: To be clear, EKT can be used with versions of DTLS prior to 764 1.3. The only difference is that in a pre-1.3 TLS stacks will not 765 have built-in support for generating and processing Ack messages. 767 If an EKTKey message is received that cannot be processed, then the 768 recipient MUST respond with an appropriate DTLS alert. 770 5.3. Offer/Answer Considerations 772 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 773 the DTLS handshake level and does not change the [RFC3264] Offer / 774 Answer messaging. 776 5.4. Sending the DTLS EKTKey Reliably 778 The DTLS EKTKey message is sent using the retransmissions specified 779 in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished 780 with an Ack message or an alert is received. 782 6. Security Considerations 784 EKT inherits the security properties of the DTLS-SRTP (or other) 785 keying it uses. 787 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 788 master keys. This property avoids any security concern over the re- 789 use of keys, by empowering the SRTP layer to create keys on demand. 790 Note that the inputs of EKT are the same as for SRTP with key- 791 sharing: a single key is provided to protect an entire SRTP session. 792 However, EKT remains secure even when SSRC values collide. 794 SRTP master keys MUST be randomly generated, and [RFC4086] offers 795 some guidance about random number generation. SRTP master keys MUST 796 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 797 be derived from other SRTP master keys. 799 The EKT Cipher includes its own authentication/integrity check. For 800 an attacker to successfully forge a FullEKTField, it would need to 801 defeat the authentication mechanisms of the EKT Cipher authentication 802 mechanism. 804 The presence of the SSRC in the EKTPlaintext ensures that an attacker 805 cannot substitute an EKTCiphertext from one SRTP stream into another 806 SRTP stream. 808 An attacker who tampers with the bits in FullEKTField can prevent the 809 intended receiver of that packet from being able to decrypt it. This 810 is a minor denial of service vulnerability. Similarly the attacker 811 could take an old FullEKTField from the same session and attach it to 812 the packet. The FullEKTField would correctly decode and pass 813 integrity but the key extracted from the FullEKTField , when used to 814 decrypt the SRTP payload, would be wrong and the SRTP integrity check 815 would fail. Note that the FullEKTField only changes the decryption 816 key and does not change the encryption key. None of these are 817 considered significant attacks as any attacker that can modify the 818 packets in transit and cause the integrity check to fail. 820 An attacker could send packets containing a Full EKT Field, in an 821 attempt to consume additional CPU resources of the receiving system 822 by causing the receiving system will decrypt the EKT ciphertext and 823 detect an authentication failure. In some cases, caching the 824 previous values of the Ciphertext as described in Section 4.3 helps 825 mitigate this issue. 827 Each EKT cipher specifies a value T that is the maximum number of 828 times a given key can be used. An endpoint MUST NOT encrypt more 829 than T different Full EKT Field using the same EKTKey. In addition, 830 the EKTKey MUST NOT be used beyond the lifetime provided by the TTL 831 described in Figure 4. 833 The confidentiality, integrity, and authentication of the EKT cipher 834 MUST be at least as strong as the SRTP cipher and at least as strong 835 as the DTLS-SRTP ciphers. 837 Part of the EKTPlaintext is known, or easily guessable to an 838 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 839 In practice, this requirement does not impose any restrictions on our 840 choices, since the ciphers in use provide high security even when 841 much plaintext is known. 843 An EKT cipher MUST resist attacks in which both ciphertexts and 844 plaintexts can be adaptively chosen and adversaries that can query 845 both the encryption and decryption functions adaptively. 847 In some systems, when a member of a conference leaves the 848 conferences, the conferences is rekeyed so that member no longer has 849 the key. When changing to a new EKTKey, it is possible that the 850 attacker could block the EKTKey message getting to a particular 851 endpoint and that endpoint would keep sending media encrypted using 852 the old key. To mitigate that risk, the lifetime of the EKTKey 853 SHOULD be limited using the ekt_ttl. 855 7. IANA Considerations 857 7.1. EKT Message Types 859 IANA is requested to create a new table for "EKT Messages Types" in 860 the "Real-Time Transport Protocol (RTP) Parameters" registry. The 861 initial values in this registry are: 863 +--------------+-------+---------------+ 864 | Message Type | Value | Specification | 865 +--------------+-------+---------------+ 866 | Short | 0 | RFCAAAA | 867 | Full | 2 | RFCAAAA | 868 | Reserved | 63 | RFCAAAA | 869 | Reserved | 255 | RFCAAAA | 870 +--------------+-------+---------------+ 872 Table 2: EKT Messages Types 874 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 875 this specification. 877 New entries to this table can be added via "Specification Required" 878 as defined in [RFC5226]. When requesting a new value, the requestor 879 needs to indicate if it is mandatory to understand or not. If it is 880 mandatory to understand, IANA needs to allocate a value less than 64, 881 if it is not mandatory to understand, a value greater than or equal 882 to 64 needs to be allocated. IANA SHOULD prefer allocation of even 883 values over odd ones until the even code points are consumed to avoid 884 conflicts with pre standard versions of EKT that have been deployed. 886 All new EKT messages MUST be defined to have a length as second from 887 the last element. 889 7.2. EKT Ciphers 891 IANA is requested to create a new table for "EKT Ciphers" in the 892 "Real-Time Transport Protocol (RTP) Parameters" registry. The 893 initial values in this registry are: 895 +----------+-------+---------------+ 896 | Name | Value | Specification | 897 +----------+-------+---------------+ 898 | AESKW128 | 1 | RFCAAAA | 899 | AESKW256 | 2 | RFCAAAA | 900 | Reserved | 255 | RFCAAAA | 901 +----------+-------+---------------+ 903 Table 3: EKT Cipher Types 905 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 906 this specification. 908 New entries to this table can be added via "Specification Required" 909 as defined in [RFC5226]. The expert SHOULD ensure the specification 910 defines the values for L and T as required in Section 4.4 of RFCAAA. 911 Allocated values MUST be in the range of 1 to 254. 913 7.3. TLS Extensions 915 IANA is requested to add supported_ekt_ciphers as a new extension 916 name to the "ExtensionType Values" table of the "Transport Layer 917 Security (TLS) Extensions" registry with a reference to this 918 specification and allocate a value of TBD to for this. 920 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 922 Considerations for this type of extension are described in Section 5 923 of [RFC4366] and requires "IETF Consensus". 925 7.4. TLS Handshake Type 927 IANA is requested to add ekt_key as a new entry in the "TLS 928 HandshakeType Registry" table of the "Transport Layer Security (TLS) 929 Parameters" registry with a reference to this specification, a DTLS- 930 OK value of "Y", and allocate a value of TBD to for this content 931 type. 933 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 935 This registry was defined in Section 12 of [RFC5246] and requires 936 "Standards Action". 938 8. Acknowledgements 940 Thank you to Russ Housley provided detailed review and significant 941 help with crafting text for this document. Thanks to David Benham, 942 Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul 943 Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean 944 Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, 945 comments, and contributions to this document. 947 9. References 949 9.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, 953 DOI 10.17487/RFC2119, March 1997, . 956 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 957 with Session Description Protocol (SDP)", RFC 3264, 958 DOI 10.17487/RFC3264, June 2002, . 961 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 962 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 963 RFC 3711, DOI 10.17487/RFC3711, March 2004, 964 . 966 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 967 IANA Considerations Section in RFCs", RFC 5226, 968 DOI 10.17487/RFC5226, May 2008, . 971 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 972 Specifications: ABNF", STD 68, RFC 5234, 973 DOI 10.17487/RFC5234, January 2008, . 976 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 977 (TLS) Protocol Version 1.2", RFC 5246, 978 DOI 10.17487/RFC5246, August 2008, . 981 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 982 (AES) Key Wrap with Padding Algorithm", RFC 5649, 983 DOI 10.17487/RFC5649, September 2009, . 986 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 987 Security (DTLS) Extension to Establish Keys for the Secure 988 Real-time Transport Protocol (SRTP)", RFC 5764, 989 DOI 10.17487/RFC5764, May 2010, . 992 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 993 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 994 January 2012, . 996 9.2. Informative References 998 [I-D.ietf-perc-double] 999 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 1000 Double Encryption Procedures", draft-ietf-perc-double-07 1001 (work in progress), September 2017. 1003 [I-D.ietf-perc-private-media-framework] 1004 Jones, P., Benham, D., and C. Groves, "A Solution 1005 Framework for Private Media in Privacy Enhanced RTP 1006 Conferencing", draft-ietf-perc-private-media-framework-04 1007 (work in progress), July 2017. 1009 [I-D.ietf-tls-dtls13] 1010 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1011 Datagram Transport Layer Security (DTLS) Protocol Version 1012 1.3", draft-ietf-tls-dtls13-02 (work in progress), October 1013 2017. 1015 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1016 "Randomness Requirements for Security", BCP 106, RFC 4086, 1017 DOI 10.17487/RFC4086, June 2005, . 1020 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1021 and T. Wright, "Transport Layer Security (TLS) 1022 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1023 . 1025 Authors' Addresses 1027 Cullen Jennings 1028 Cisco Systems 1030 Email: fluffy@iii.ca 1032 John Mattsson 1033 Ericsson AB 1035 Email: john.mattsson@ericsson.com 1037 David A. McGrew 1038 Cisco Systems 1040 Email: mcgrew@cisco.com 1042 Dan Wing 1043 Cisco Systems 1045 Email: dwing@cisco.com 1046 Flemming Andreason 1047 Cisco Systems 1049 Email: fandreas@cisco.com