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