idnits 2.17.1 draft-jennings-perc-srtp-ekt-diet-01.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 == Line 390 has weird spacing: '...ngth of lengt...' == Line 392 has weird spacing: '...ansform tran...' -- The document date (April 20, 2016) is 2928 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 562, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PERC Working Group J. Mattsson, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. McGrew 5 Expires: October 22, 2016 D. Wing 6 F. Andreasen 7 C. Jennings 8 Cisco 9 April 20, 2016 11 Encrypted Key Transport for Secure RTP 12 draft-jennings-perc-srtp-ekt-diet-01 14 Abstract 16 IMPORTANT: This draft is just a cut down version of draft-ietf- 17 avtcore-srtp-ekt-03 to help discussion about the key parts of EKT for 18 the PERC WG. Any changes decided here would need to be synchronized 19 with the draft-ietf-avtcore-srtp-ekt draft. Nearly all the text here 20 came from draft-ietf-avtcore-srtp-ekt and the authors of that draft. 22 Encrypted Key Transport (EKT) is an extension to Secure Real-time 23 Transport Protocol (SRTP) that provides for the secure transport of 24 SRTP master keys, Rollover Counters, and other information within 25 SRTP. This facility enables SRTP to work for decentralized 26 conferences with minimal control by allowing a common key to be used 27 across multiple endpoints. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 22, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions Used In This Document . . . . . . . . . . . . 4 65 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 66 2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Packet Processing and State Machine . . . . . . . . . . . 6 68 2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 6 69 2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 7 70 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . 9 72 2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 9 73 2.4. Synchronizing 74 Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 75 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10 76 2.6. Timing and Reliability Consideration . . . . . . . . . . 10 77 3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 11 78 3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 11 79 3.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 11 80 3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 81 4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . . . 13 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 9.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 RTP is designed to allow decentralized groups with minimal control to 94 establish sessions, such as for multimedia conferences. 95 Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many 96 minimal-control scenarios, because it requires that SSRC values and 97 other data be coordinated among all of the participants in a session. 98 For example, if a participant joins a session that is already in 99 progress, that participant needs to be told the SRTP keys (and SSRC, 100 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 most of the 107 central control needed by SRTP. However, there are several cases in 108 which 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 that is shared with multiple receivers. EKT securely 116 distributes the SRTP master key and other information for each SRTP 117 source. With this method, SRTP entities are free to choose SSRC 118 values as they see fit, and to start up new SRTP sources (SSRC) with 119 new SRTP master keys (see Section 2.2) within a session without 120 coordinating with other entities via external signaling or other 121 external means. 123 EKT provides a way for an SRTP session participant, either a sender 124 or receiver, to securely transport its SRTP master key and current 125 SRTP rollover counter to the other participants in the session. This 126 data furnishes the information needed by the receiver to instantiate 127 an SRTP/SRTCP receiver context. 129 EKT does not control the manner in which the SSRC is generated; it is 130 only concerned with their secure transport. 132 EKT is not intended to replace external key establishment mechanisms, 133 Instead, it is used in conjunction with those methods, and it 134 relieves them of the burden of tightly coordinating every SRTP source 135 (SSRC) among every SRTP participant. 137 1.1. Conventions Used In This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Encrypted Key Transport 145 EKT defines a new method of providing SRTP master keys to an 146 endpoint. In order to convey the ciphertext of the SRTP master key, 147 and other additional information, an additional EKT field is added to 148 SRTP packets. When added to SRTP, the EKT field appears at the end 149 of the SRTP packet, after the authentication tag (if that tag is 150 present), or after the ciphertext of the encrypted portion of the 151 packet otherwise. 153 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 154 Identifier) or with SRTP's [RFC3711], as those SRTP 155 features duplicate some of the functions of EKT. 157 2.1. EKT Field Formats 159 The EKT Field uses the format defined below for the Full_EKT_Field 160 and Short_EKT_Field. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 : : 166 : EKT Ciphertext : 167 : : 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Security Parameter Index |1| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: Full EKT Field format 174 0 1 2 3 4 5 6 7 175 +-+-+-+-+-+-+-+-+ 176 |0 0 0 0 0 0 0|0| 177 +-+-+-+-+-+-+-+-+ 179 Figure 2: Short EKT Field format 181 EKT_Plaintext = SRTP_Master_Key || SSRC || ROC 183 EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext) 185 Full_EKT_Field = EKT_Ciphertext || SPI || '1' 187 Short_EKT_Field = '00000000' 189 Figure 3: EKT data formats 191 These fields and data elements are defined as follows: 193 EKT_Plaintext: The data that is input to the EKT encryption 194 operation. This data never appears on the wire, and is used only 195 in computations internal to EKT. This is the concatenation of the 196 SRTP Master Key, the SSRC, and the ROC. 198 EKT_Ciphertext: The data that is output from the EKT encryption 199 operation, described in Section 2.3. This field is included in 200 SRTP packets when EKT is in use. The length of this field is 201 variable, and is equal to the ciphertext size N defined in 202 Section 2.3. Note that the length of the field is inferable from 203 the SPI field, since the SPI will indicate the cipher being used 204 and thus the size. 206 SRTP_Master_Key: On the sender side, the SRTP Master Key associated 207 with the indicated SSRC. The length of this field depends on the 208 cipher suite negotiated during call setup for SRTP or SRTCP. 210 SSRC: On the sender side, this field is the SSRC for this SRTP 211 source. The length of this field is 32 bits. 213 Rollover Counter (ROC): On the sender side, this field is set to the 214 current value of the SRTP rollover counter in the SRTP context 215 associated with the SSRC in the SRTP or SRTCP packet. The length 216 of this field is 32 bits. 218 Security Parameter Index (SPI): This field indicates the appropriate 219 EKT Key and other parameters for the receiver to use when 220 processing the packet. Each time a different EKT Key is received, 221 it will have a different SPI. The length of this field is 15 222 bits. The parameters identified by this field are: 224 * The EKT cipher used to process the packet. 226 * The EKT Key used to process the packet. 228 * The SRTP Master Salt associated with any Master Key encrypted 229 with this EKT Key. 231 Together, these data elements are called an EKT parameter set. 232 Within each SRTP session, each distinct EKT parameter set that may 233 be used MUST be associated with a distinct SPI value, to avoid 234 ambiguity. 236 Final bit: The last bit is used to indicate the type of the Field. 237 This MUST be 1 in the Full EKT Field format and 0 in Short EKT 238 Field. 240 2.2. Packet Processing and State Machine 242 At any given time, each SRTP/SRTCP source (SSRC) has associated with 243 it a single EKT parameter set. This parameter set is used to process 244 all outbound packets, and is called the outbound parameter set for 245 that SSRC. There may be other EKT parameter sets that are used by 246 other SRTP/SRTCP sources in the same session, including other SRTP/ 247 SRTCP sources on the same endpoint (e.g., one endpoint with voice and 248 video might have two EKT parameter sets, or there might be multiple 249 video sources on an endpoint each with their own EKT parameter set). 250 All of the received EKT parameter sets SHOULD be stored by all of the 251 participants in an SRTP session, for use in processing inbound SRTP 252 and SRTCP traffic. 254 All SRTP master keys MUST NOT be re-used, MUST be randomly generated 255 according to [RFC4086], and MUST NOT be equal to or derived from 256 other SRTP master keys. 258 Either the Full_EKT_Field or Short_EKT_Field is appended at the tail 259 end of all the SRTP packet. 261 2.2.1. Outbound Processing 263 See Section 2.6 which describes when to send an EKT packet with a 264 Full EKT Field. If a Full EKT Field is not being sent, then a Short 265 EKT Field needs to be sent so the receiver can correctly determine 266 how to process the packet. 268 When an SRTP packet is to be sent with a Full EKT Field, the EKT 269 field for that packet is created as follows, or uses an equivalent 270 set of steps. The creation of the EKT field MUST precede the normal 271 SRTP packet processing. 273 1. The Security Parameter Index field is set to the value of the 274 Security Parameter Index that is associated with the outbound 275 parameter set. 277 2. The EKT_Plaintext field is computed from the SRTP Master Key, 278 SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP 279 Master Key, and SSRC used in EKT processing SHOULD be the same as 280 the one used in the SRTP processing. 282 3. The EKT_Ciphertext field is set to the ciphertext created by 283 encrypting the EKT_Plaintext with the EKT cipher, using the EKT 284 Key as the encryption key. The encryption process is detailed in 285 Section 2.3. 287 4. Then the Full EKT Field is formed using the EKT Ciphertext and 288 the SPI associated with the EKT Key used above. The computed 289 value of the Full EKT Field is written into the packet. 291 When a packet is sent with the Short EKT Field, the Short EKF Field 292 is simply appended to the packet. 294 2.2.2. Inbound Processing 296 Inbound EKT processing MUST take place prior to the usual SRTP or 297 SRTCP processing. The following steps show processing as packets are 298 received in order. 300 1. The final bit is checked to determine which EKT format is in use. 301 When an SRTP or SRTCP packet contains a Short EKT Field, the 302 Short EKT Field is removed from the packet then normal SRTP or 303 SRTCP processing occurs. If the packet contains a Full EKT 304 Field, then processing continues as described below. 306 2. The combination of the SSRC and the Security Parameter Index 307 (SPI) field is used to find which EKT parameter set should be 308 used when processing the packet. If there is no matching SPI, 309 then the verification function MUST return an indication of 310 authentication failure, and the steps described below are not 311 performed. EKT parameter set contains the EKT Key, EKT Cipher, 312 and SRTP Master Salt. 314 3. The EKT Ciphertext authentication is checked and it is decrypted, 315 as described in Section 2.3, using the EKT Key and EKT Cipher 316 found in the previous step. If the EKT decryption operation 317 returns an authentication failure, then the packet processing 318 stops. 320 4. The resulting EKT Plaintext is parsed as described in 321 Section 2.1, to recover the SRTP Master Key, SSRC, and ROC 322 fields. The Master Salt that is assocted with the EKT Keys used 323 to do the decription is also retreived. 325 5. The SRTP Master Key, ROC, and Master Salt from the prevous step 326 are saved in a map indexed by the SSRC found in the EKT Plaintext 327 and used for any future inbound or about crypto operations on 328 packets with the that SSRC. 330 6. At this point, EKT processing has successfully completed, and the 331 normal SRTP or SRTCP processing takes place including replay 332 protection. 334 Implementation note: the receiver may want to have a sliding window 335 to retain old SRTP master keys (and related context) for some brief 336 period of time, so that out of order packets can be processed as well 337 as packets sent during the time keys are changing. 339 2.3. Ciphers 341 EKT uses an authenticated cipher to encrypt and authenticate the EKT 342 Plaintext. We first specify the interface to the cipher, in order to 343 abstract the interface away from the details of that function. We 344 then define the cipher that is used in EKT by default. The default 345 cipher described in Section 2.3.1 MUST be implemented, but another 346 cipher that conforms to this interface MAY be used, in which case its 347 use MUST be coordinated by external means (e.g., key management). 349 An EKT cipher consists of an encryption function and a decryption 350 function. The encryption function E(K, P) takes the following 351 inputs: 353 o a secret key K with a length of L bytes, and 355 o a plaintext value P with a length of M bytes. 357 The encryption function returns a ciphertext value C whose length is 358 N bytes, where N is at least M. The decryption function D(K, C) 359 takes the following inputs: 361 o a secret key K with a length of L bytes, and 363 o a ciphertext value C with a length of N bytes. 365 The decryption function returns a plaintext value P that is M bytes 366 long, or returns an indication that the decryption operation failed 367 because the ciphertext was invalid (i.e. it was not generated by the 368 encryption of plaintext with the key K). 370 These functions have the property that D(K, E(K, P)) = P for all 371 values of K and P. Each cipher also has a limit T on the number of 372 times that it can be used with any fixed key value. For each key, 373 the encryption function MUST NOT be invoked on more than T distinct 374 values of P, and the decryption function MUST NOT be invoked on more 375 than T distinct values of C. 377 Security requirements for EKT ciphers are discussed in Section 5. 379 2.3.1. The Default Cipher 381 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 382 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 383 length M that is at least one octet, and it returns a ciphertext with 384 a length of N = M + 8 octets. It can be used with key sizes of L = 385 16, and 32 octets, and its use with those key sizes is indicated as 386 AESKW_128, or AESKW_256, respectively. The key size determines the 387 length of the AES key used by the Key Wrap algorithm. With this 388 cipher, T=2^48. 390 length of length of 391 SRTP EKT EKT EKT length of 392 transform transform plaintext ciphertext Full EKT Field 393 --------- ------------ --------- ---------- -------------- 394 AES-128 AESKW_128 26 40 42 395 AES-256 AESKW_256 42 56 58 397 Figure 4: AESKW Table 399 As AES-128 is the mandatory to implement transform in SRTP [RFC3711], 400 AESKW_128 MUST be implemented for EKT. 402 For all the SRTP transforms listed in the table, the corresponding 403 EKT transform MUST be used, unless a stronger EKT transform is 404 negotiated by key management. 406 2.3.2. Other EKT Ciphers 408 Other specifications may extend this one by defining other EKT 409 ciphers per Section 7. This section defines how those ciphers 410 interact with this specification. 412 An EKT cipher determines how the EKT Ciphertext field is written, and 413 how it is processed when it is read. This field is opaque to the 414 other aspects of EKT processing. EKT ciphers are free to use this 415 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 416 an input. The values of the parameters L, M, N, and T MUST be 417 defined by each EKT cipher, and those values MUST be inferable from 418 the EKT parameter set. 420 2.4. Synchronizing Operation 422 If a source has its EKT key changed by the key management, it MUST 423 also change its SRTP master key, which will cause it to send out a 424 new Full EKT Field. This ensures that if key management thought the 425 EKT key needs changing (due to a participant leaving or joining) and 426 communicated that in key management to a source, the source will also 427 change its SRTP master key, so that traffic can be decrypted only by 428 those who know the current EKT key. 430 2.5. Transport 432 EKT SHOULD be used over SRTP, and other specification MAY define how 433 to use it over SRTCP. SRTP is preferred because it shares fate with 434 transmitted media, because SRTP rekeying can occur without concern 435 for RTCP transmission limits, and to avoid SRTCP compound packets 436 with RTP translators and mixers. 438 2.6. Timing and Reliability Consideration 440 A system using EKT learns the SRTP master keys distributed with Full 441 EKT Fields send with the SRTP, rather than with call signaling. A 442 receiver can immediately decrypt an SRTP provided the SRTP packet 443 contains a Full EKT Field. 445 This section describes how to reliably and expediently deliver new 446 SRTP master keys to receivers. 448 There are three cases to consider. The first case is a new sender 449 joining a session which needs to communicate its SRTP master key to 450 all the receivers. The second case is a sender changing its SRTP 451 master key which needs to be communicated to all the receivers. The 452 third case is a new receiver joining a session already in progress 453 which needs to know the sender's SRTP master key. 455 New sender: A new sender SHOULD send a packet containing the Full EKT 456 Field as soon as possible, always before or coincident with sending 457 its initial SRTP packet. To accommodate packet loss, it is 458 RECOMMENDED that three consecutive packets contain the Full EKT Field 459 be transmitted. 461 Rekey: By sending EKT over SRTP, the rekeying event shares fate with 462 the SRTP packets protected with that new SRTP master key. 464 New receiver: When a new receiver joins a session it does not need to 465 communicate its sending SRTP master key (because it is a receiver). 466 When a new receiver joins a session the sender is generally unaware 467 of the receiver joining the session. Thus, senders SHOULD 468 periodically transmit the Full EKT Field. That interval depends on 469 how frequently new receivers join the session, the acceptable delay 470 before those receivers can start processing SRTP packets, and the 471 acceptable overhead of sending the Full EKT Field. The RECOMMENDED 472 frequency is the same as the key frame frequency if sending video and 473 every 100ms for audio. 475 3. Use of EKT with DTLS-SRTP 477 This document defines an extension to DTLS-SRTP called Key Transport. 478 The EKT with the DTLS-SRTP Key Transport enables secure transport of 479 EKT keying material from one DTLS-SRTP peer to another. This enables 480 those peers to process EKT keying material in SRTP (or SRTCP) and 481 retrieve the embedded SRTP keying material. This combination of 482 protocols is valuable because it combines the advantages of DTLS 483 (strong authentication of the endpoint and flexibility) with the 484 advantages of EKT (allowing secure multiparty RTP with loose 485 coordination and efficient communication of per-source keys). 487 3.1. DTLS-SRTP Recap 489 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 490 to exchange keying material, algorithms, and parameters for SRTP. 491 The SRTP flow operates over the same transport as the DTLS-SRTP 492 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 493 performance and encryption flexibility benefits of SRTP with the 494 flexibility and convenience of DTLS-integrated key and association 495 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 496 key management method for SRTP, and a new RTP-specific data format 497 for DTLS. 499 3.2. EKT Extensions to DTLS-SRTP 501 This document adds a new TLS negotiated extension called "ekt". This 502 adds a new TLS content type, EKT, and a new negotiated extension EKT. 503 The DTLS server includes "ekt" in its TLS ServerHello message. If a 504 DTLS client includes "ekt" in its ClientHello, but does not receive 505 "ekt" in the ServerHello, the DTLS client MUST NOT send DTLS packets 506 with the "ekt" content-type. 508 Using the syntax described in DTLS [RFC6347], the following 509 structures are used: 511 enum { 512 ekt_key(0), 513 ekt_key_ack(1), 514 ekt_key_error(254), 515 (255) 516 } SRTPKeyTransportType; 518 struct { 519 SRTPKeyTransportType keytrans_type; 520 uint24 length; 521 uint16 message_seq; 522 uint24 fragment_offset; 523 uint24 fragment_length; 524 select (SRTPKeyTransportType) { 525 case ekt_key: 526 EKTkey; 527 }; 528 } KeyTransport; 530 enum { 531 RESERVED(0), 532 AESKW_128(1), 533 AESKW_256(3), 534 } ektcipher; 536 struct { 537 ektcipher EKT_Cipher; 538 uint EKT_Key_Value<1..256>; 539 uint EKT_Master_Salt<1..256>; 540 uint16 EKT_SPI; 541 } EKTkey; 543 Figure 5: Additional TLS Data Structures 545 The diagram below shows a message flow of DTLS client and DTLS server 546 using the DTLS-SRTP Key Transport extension. 548 Client Server 550 ClientHello + use_srtp + EKT 551 --------> 552 ServerHello + use_srtp + EKT 553 Certificate* 554 ServerKeyExchange* 555 CertificateRequest* 556 <-------- ServerHelloDone 557 Certificate* 558 ClientKeyExchange 559 CertificateVerify* 560 [ChangeCipherSpec] 561 Finished --------> 562 [ChangeCipherSpec] 563 <-------- Finished 564 ekt_key --------> 565 SRTP packets <-------> SRTP packets 566 SRTP packets <-------> SRTP packets 567 ekt_key (rekey) --------> 568 SRTP packets <-------> SRTP packets 569 SRTP packets <-------> SRTP packets 571 Figure 6: Handshake Message Flow 573 3.3. Offer/Answer Considerations 575 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 576 the DTLS handshake level and does not change the [RFC3264] Offer / 577 Answer messaging. 579 4. Sending the DTLS EKT_Key Reliably 581 The DTLS ekt_key is sent using the retransmiions specified in 582 Section 4.2.4. of DTLS [RFC6347]. 584 5. Security Considerations 586 EKT inherits the security properties of the DTLS-SRTP (or other) 587 keying it uses. 589 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 590 master keys. This property avoids any security concern over the re- 591 use of keys, by empowering the SRTP layer to create keys on demand. 592 Note that the inputs of EKT are the same as for SRTP with key- 593 sharing: a single key is provided to protect an entire SRTP session. 594 However, EKT remains secure even when SSRC values collide. 596 The EKT Cipher includes its own authentication/integrity check. For 597 an attacker to successfully forge a full EKT packet, it would need to 598 defeat the authentication mechanisms of the EKT Cipher authentication 599 mechanism. 601 The presence of the SSRC in the EKT_Plaintext ensures that an 602 attacker cannot substitute an EKT_Ciphertext from one SRTP stream 603 into another SRTP stream. 605 An attacker who tampers with the bits in Full_EKT_Field can prevent 606 the intended receiver of that packet from being able to decrypt it. 607 This is a minor denial of service vulnerability. 609 An attacker could send packets containing a Full EKT Field, in an 610 attempt to consume additional CPU resources of the receiving system 611 by causing the receiving system will decrypt the EKT ciphertext and 612 detect an authentication failure 614 EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) 615 needs to roll over. EKT does not extend SRTP's rollover counter 616 (ROC), and like SRTP itself EKT cannot properly handle a ROC 617 rollover. Thus even if using EKT, new (master or session) keys need 618 to be established after 2^48 packets are transmitted in a single SRTP 619 stream as described in Section 3.3.1 of [RFC3711]. Due to the 620 relatively low packet rates of typical RTP sessions, this is not 621 expected to be a burden. 623 The confidentiality, integrity, and authentication of the EKT cipher 624 MUST be at least as strong as the SRTP cipher. 626 Part of the EKT_Plaintext is known, or easily guessable to an 627 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 628 In practice, this requirement does not impose any restrictions on our 629 choices, since the ciphers in use provide high security even when 630 much plaintext is known. 632 An EKT cipher MUST resist attacks in which both ciphertexts and 633 plaintexts can be adaptively chosen and adversaries that can query 634 both the encryption and decryption functions adaptively. 636 6. Open Issues 638 What length should the SPI be? 640 Should we limit the number of saved SPI for a given SSRC? Or limit 641 the lifetime of old ones after a new one is received? At some level 642 this may not matter because even if the a SRTP packet is injected 643 with an old value, it will be discards by the RTP stack for being 644 old. It is more important that new things are encrypted with the 645 most recent EKT Key. 647 How many bits to differentiate different types of packets and allow 648 for extensibility? 650 Given the amount of old EKT deployed, should the Full EKT use a a 651 different code point than the "1" at the end? 653 Do we need AES-192? 655 7. IANA Considerations 657 No IANA actions are required. 659 8. Acknowledgements 661 Thanks to David Benham, Eddy Lem, Felix Wyss, Jonathan Lennox, Kai 662 Fischer, Lakshminath Dondeti, Magnus Westerlund, Michael Peck, 663 Nermeen Ismail, Paul Jones, Rob Raymond, and Yi Cheng for fruitful 664 discussions, comments, and contributions to this document. 666 This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03 667 and most of the text here came from that draft. 669 9. References 671 9.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 675 RFC2119, March 1997, 676 . 678 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 679 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 680 RFC 3711, DOI 10.17487/RFC3711, March 2004, 681 . 683 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 684 "Randomness Requirements for Security", BCP 106, RFC 4086, 685 DOI 10.17487/RFC4086, June 2005, 686 . 688 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 689 (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 690 10.17487/RFC5649, September 2009, 691 . 693 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 694 Security (DTLS) Extension to Establish Keys for the Secure 695 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 696 10.17487/RFC5764, May 2010, 697 . 699 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 700 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 701 January 2012, . 703 9.2. Informative References 705 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 706 with Session Description Protocol (SDP)", RFC 3264, DOI 707 10.17487/RFC3264, June 2002, 708 . 710 Authors' Addresses 712 John Mattsson (editor) 713 Ericsson AB 714 SE-164 80 Stockholm 715 Sweden 717 Phone: +46 10 71 43 501 718 Email: john.mattsson@ericsson.com 720 David A. McGrew 721 Cisco Systems 722 510 McCarthy Blvd. 723 Milpitas, CA 95035 724 US 726 Phone: (408) 525 8651 727 Email: mcgrew@cisco.com 728 URI: http://www.mindspring.com/~dmcgrew/dam.htm 730 Dan Wing 731 Cisco Systems 732 510 McCarthy Blvd. 733 Milpitas, CA 95035 734 US 736 Phone: (408) 853 4197 737 Email: dwing@cisco.com 738 Flemming Andreason 739 Cisco Systems 740 499 Thornall Street 741 Edison, NJ 08837 742 US 744 Email: fandreas@cisco.com 746 Cullen Jennings 747 Cisco Systems 748 Calgary, AB 749 Canada 751 Email: fluffy@iii.ca