idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-02.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 31, 2016) is 2728 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 642, 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) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PERC Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Mattsson, Ed. 5 Expires: May 4, 2017 Ericsson 6 D. McGrew 7 D. Wing 8 F. Andreasen 9 Cisco 10 October 31, 2016 12 Encrypted Key Transport for Secure RTP 13 draft-ietf-perc-srtp-ekt-diet-02 15 Abstract 17 Encrypted Key Transport (EKT) is an extension to Secure Real-time 18 Transport Protocol (SRTP) that provides for the secure transport of 19 SRTP master keys, rollover counters, and other information within 20 SRTP. This facility enables SRTP for decentralized conferences by 21 distributing a common key to all of the conference 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 May 4, 2017. 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 . . . . . . . . . . . . . . . . . 8 64 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.3.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.3.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 10 67 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 10 68 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.6. Timing and Reliability Consideration . . . . . . . . . . 11 70 3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 12 71 3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12 72 3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 12 73 3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 15 74 3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 15 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17 78 5.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 17 79 5.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 18 80 5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 7.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Real-time Transport Protocol (RTP) is designed to allow decentralized 90 groups with minimal control to establish sessions, such as for 91 multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711]) 92 cannot be used in many minimal-control scenarios, because it requires 93 that synchronization source (SSRC) values and other data be 94 coordinated among all of the participants in a session. For example, 95 if a participant joins a session that is already in progress, that 96 participant needs to be told the SRTP keys along with the SSRC, roll 97 over counter (ROC) and other details of the other SRTP sources. 99 The inability of SRTP to work in the absence of central control was 100 well understood during the design of the protocol; the omission was 101 considered less important than optimizations such as bandwidth 102 conservation. Additionally, in many situations SRTP is used in 103 conjunction with a signaling system that can provide the central 104 control needed by SRTP. However, there are several cases in which 105 conventional signaling systems cannot easily provide all of the 106 coordination required. It is also desirable to eliminate the layer 107 violations that occur when signaling systems coordinate certain SRTP 108 parameters, such as SSRC values and ROCs. 110 This document defines Encrypted Key Transport (EKT) for SRTP and 111 reduces the amount of external signaling control that is needed in a 112 SRTP session with multiple receivers. EKT securely distributes the 113 SRTP master key and other information for each SRTP source. With 114 this method, SRTP entities are free to choose SSRC values as they see 115 fit, and to start up new SRTP sources with new SRTP master keys (see 116 Section 2.2) within a session without coordinating with other 117 entities via external signaling or other external means. 119 EKT provides a way for an SRTP session participant, either a sender 120 or receiver, to securely transport its SRTP master key and current 121 SRTP rollover counter to the other participants in the session. This 122 data furnishes the information needed by the receiver to instantiate 123 an SRTP/SRTCP receiver context. 125 EKT does not control the manner in which the SSRC is generated; it is 126 only concerned with their secure transport. 128 EKT is not intended to replace external key establishment mechanisms. 129 Instead, it is used in conjunction with those methods, and it 130 relieves those methods of the burden to deliver the context for each 131 SRTP source to every SRTP participant. 133 1.1. Conventions Used In This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 2. Encrypted Key Transport 141 EKT defines a new method of providing SRTP master keys to an 142 endpoint. In order to convey the ciphertext corresponding to the 143 SRTP master key, and other additional information, an additional EKT 144 field is added to SRTP packets. When added to SRTP, the EKT field 145 appears at the end of the SRTP packet, after the authentication tag 146 (if that tag is present), or after the ciphertext of the encrypted 147 portion of the packet otherwise. 149 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 150 Identifier) or with SRTP's [RFC3711], as those SRTP 151 features duplicate some of the functions of EKT. 153 2.1. EKT Field Formats 155 The EKT Field uses the format defined below for the FullEKTField and 156 ShortEKTField. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 : : 162 : EKT Ciphertext : 163 : : 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Security Parameter Index | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |0 0 0 0 0 0 1 0| 168 +-+-+-+-+-+-+-+-+ 170 Figure 1: Full EKT Field format 172 0 1 2 3 4 5 6 7 173 +-+-+-+-+-+-+-+-+ 174 |0 0 0 0 0 0 0 0| 175 +-+-+-+-+-+-+-+-+ 177 Figure 2: Short EKT Field format 179 The following shows the syntax of the EKTField expressed in ABNF 180 [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP 181 packet. The EKTCiphertext is computed by encrypting the EKTPlaintext 182 using the EKTKey. Future extensions to the EKTField MUST conform to 183 the syntax of ExtensionEKTField. 185 BYTE = %x00-FF 187 EKTMsgTypeFull = %x02 188 EKTMsgTypeShort = %x00 189 EKTMsgTypeExtension = %x03-FF 191 EKTMsgLength = 2BYTE; 193 SRTPMasterKeyLength = BYTE 194 SRTPMasterKey = 1*256BYTE 195 SSRC = 4BYTE; SSRC from RTP 196 ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC 198 EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 200 EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 201 SPI = 2BYTE 203 FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull 205 ShortEKTField = EKTMsgTypeShort 207 ExtensionData = 1*1024BYTE 208 ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 210 EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 212 Figure 3: EKTField Syntax 214 These fields and data elements are defined as follows: 216 EKTPlaintext: The data that is input to the EKT encryption 217 operation. This data never appears on the wire, and is used only 218 in computations internal to EKT. This is the concatenation of the 219 SRTP Master Key, the SSRC, and the ROC. 221 EKTCiphertext: The data that is output from the EKT encryption 222 operation, described in Section 2.3. This field is included in 223 SRTP packets when EKT is in use. 225 SRTPMasterKey: On the sender side, the SRTP Master Key associated 226 with the indicated SSRC. 228 SRTPMasterKeyLength: The length of the SRTPMasterKey. This depends 229 on the cipher suite negotiated for SRTP using [RFC3264] SDP Offer/ 230 Answer for the SRTP. 232 SSRC: On the sender side, this field is the SSRC for this SRTP 233 source. The length of this field is 32 bits. 235 Rollover Counter (ROC): On the sender side, this field is set to the 236 current value of the SRTP rollover counter in the SRTP context 237 associated with the SSRC in the SRTP or SRTCP packet. The length 238 of this field is 32 bits. 240 Security Parameter Index (SPI): This field indicates the appropriate 241 EKT Key and other parameters for the receiver to use when 242 processing the packet. The length of this field is 16 bits. The 243 parameters identified by this field are: 245 * The EKT cipher used to process the packet. 247 * The EKT Key used to process the packet. 249 * The SRTP Master Salt associated with any Master Key encrypted 250 with this EKT Key. The Master Salt is communicated separately, 251 via signaling, typically along with the EKTKey. 253 Together, these data elements are called an EKT parameter set. 254 Each distinct EKT parameter set that is used MUST be associated 255 with a distinct SPI value to avoid ambiguity. 257 EKTMsgLength All EKT message other that ShortEKTField must have a 258 length as second from the last element. This is the length in 259 octets of either the FullEKTField/ExtensionEKTField including this 260 length field and the following message type. 262 Message Type The last byte is used to indicate the type of the 263 EKTField. This MUST be 2 in the FullEKTField format and 0 in 264 ShortEKTField format. Values less than 64 are mandatory to 265 understand and the whole EKTField SHOULD be discarded if it 266 contains message type value that is less than 64 and is not 267 implemented. 269 2.2. Packet Processing and State Machine 271 At any given time, each SRTP/SRTCP source has associated with it a 272 single EKT parameter set. This parameter set is used to process all 273 outbound packets, and is called the outbound parameter set for that 274 SSRC. There may be other EKT parameter sets that are used by other 275 SRTP/SRTCP sources in the same session, including other SRTP/SRTCP 276 sources on the same endpoint (e.g., one endpoint with voice and video 277 might have two EKT parameter sets, or there might be multiple video 278 sources on an endpoint each with their own EKT parameter set). All 279 of the received EKT parameter sets SHOULD be stored by all of the 280 participants in an SRTP session, for use in processing inbound SRTP 281 and SRTCP traffic. 283 Either the FullEKTField or ShortEKTField is appended at the tail end 284 of all SRTP packets. 286 2.2.1. Outbound Processing 288 See Section 2.6 which describes when to send an EKT packet with a 289 FullEKTField. If a FullEKTField is not being sent, then a 290 ShortEKTField needs to be sent so the receiver can correctly 291 determine how to process the packet. 293 When an SRTP packet is to be sent with a FullEKTField, the EKTField 294 for that packet is created as follows, or uses an equivalent set of 295 steps. The creation of the EKTField MUST precede the normal SRTP 296 packet processing. 298 1. The Security Parameter Index (SPI) field is set to the value of 299 the Security Parameter Index that is associated with the outbound 300 parameter set. 302 2. The EKTPlaintext field is computed from the SRTP Master Key, 303 SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP 304 Master Key, and SSRC used in EKT processing SHOULD be the same as 305 the one used in the SRTP processing. 307 3. The EKTCiphertext field is set to the ciphertext created by 308 encrypting the EKTPlaintext with the EKT cipher, using the EKTKey 309 as the encryption key. The encryption process is detailed in 310 Section 2.3. 312 4. Then the FullEKTField is formed using the EKTCiphertext and the 313 SPI associated with the EKTKey used above. Also appended are the 314 Length and EKTMEsgTypeFull elements. 316 Note: the value of the EKT Ciphertext field is identical in 317 successive packets protected by the same EKTKey and SRTP 318 master key. This value MAY be cached by an SRTP sender to 319 minimize computational effort. 321 The computed value of the FullEKTField is written into the 322 packet. 324 When a packet is sent with the Short EKT Field, the ShortEKFField is 325 simply appended to the packet. 327 2.2.2. Inbound Processing 329 When receiving a packet on a RTP stream where EKT was negotiated, the 330 following steps are applied for each received packet. 332 1. The final byte is checked to determine which EKT format is in 333 use. When an SRTP or SRTCP packet contains a ShortEKTField, the 334 ShortEKTField is removed from the packet then normal SRTP or 335 SRTCP processing occurs. If the packet contains a FullEKTField, 336 then processing continues as described below. 338 2. The Security Parameter Index (SPI) field is used to find which 339 EKT parameter set to be used when processing the packet. If 340 there is no matching SPI, then the verification function MUST 341 return an indication of authentication failure, and the steps 342 described below are not performed. The EKT parameter set 343 contains the EKTKey, EKTCipher, and SRTP Master Salt. 345 3. The EKTCiphertext authentication is checked and it is decrypted, 346 as described in Section 2.3, using the EKTKey and EKTCipher found 347 in the previous step. If the EKT decryption operation returns an 348 authentication failure, then the packet processing stops. 350 4. The resulting EKTPlaintext is parsed as described in Section 2.1, 351 to recover the SRTP Master Key, SSRC, and ROC fields. The Master 352 Salt that is associated with the EKTKey is also retrieved. If 353 the value of the srtp_master_salt sent as part of the EKTkey is 354 longer than needed by SRTP, then it is truncated by taking the 355 first N bytes from the srtp_master_salt field. 357 5. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 358 step are saved in a map indexed by the SSRC found in the 359 EKTPlaintext and can be used for any future crypto operations on 360 the inbound packets with that SSRC. Outbound packets SHOULD 361 continue to use the old SRTP Master Key for 250 ms after sending 362 any new key. This gives all the receivers in the system time to 363 get the new key before they start receiving media encrypted with 364 the new key. 366 6. At this point, EKT processing has successfully completed, and the 367 normal SRTP or SRTCP processing takes place including replay 368 protection. 370 2.2.2.1. Implementation Notes for Inbound Processing 372 The value of the EKTCiphertext field is identical in successive 373 packets protected by the same EKT parameter set and the same SRTP 374 master key, and ROC. This ciphertext value MAY be cached by an SRTP 375 receiver to minimize computational effort by noting when the SRTP 376 master key is unchanged and avoiding repeating the above steps. 378 The receiver may want to have a sliding window to retain old SRTP 379 master keys (and related context) for some brief period of time, so 380 that out of order packets can be processed as well as packets sent 381 during the time keys are changing. 383 2.3. Ciphers 385 EKT uses an authenticated cipher to encrypt and authenticate the 386 EKTPlaintext. We first specify the interface to the cipher, in order 387 to abstract the interface away from the details of that function. We 388 then define the cipher that is used in EKT by default. The default 389 cipher described in Section 2.3.1 MUST be implemented, but another 390 cipher that conforms to this interface MAY be used, in which case its 391 use MUST be coordinated by external means (e.g., key management). 393 An EKTCipher consists of an encryption function and a decryption 394 function. The encryption function E(K, P) takes the following 395 inputs: 397 o a secret key K with a length of L bytes, and 399 o a plaintext value P with a length of M bytes. 401 The encryption function returns a ciphertext value C whose length is 402 N bytes, where N may be larger than M. The decryption function D(K, 403 C) takes the following inputs: 405 o a secret key K with a length of L bytes, and 407 o a ciphertext value C with a length of N bytes. 409 The decryption function returns a plaintext value P that is at least 410 M bytes long, or returns an indication that the decryption operation 411 failed because the ciphertext was invalid (i.e. it was not generated 412 by the encryption of plaintext with the key K). 414 These functions have the property that D(K, E(K, P)) = ( P 415 concatenated with optional padding) for all values of K and P. Each 416 cipher also has a limit T on the number of times that it can be used 417 with any fixed key value. The EKTKey MUST NOT be used more that T 418 times. 420 Security requirements for EKT ciphers are discussed in Section 4. 422 2.3.1. Ciphers 424 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 425 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 426 length M that is at least one octet, and it returns a ciphertext with 427 a length of N = M + (M mod 8) + 8 octets. It can be used with key 428 sizes of L = 16, and L = 32 octets, and its use with those key sizes 429 is indicated as AESKW128, or AESKW256, respectively. The key size 430 determines the length of the AES key used by the Key Wrap algorithm. 431 With this cipher, T=2^48. 433 +----------+----+------+ 434 | Cipher | L | T | 435 +----------+----+------+ 436 | AESKW128 | 16 | 2^48 | 437 | | | | 438 | AESKW256 | 32 | 2^48 | 439 +----------+----+------+ 441 Table 1: EKT Ciphers 443 As AES-128 is the mandatory to implement transform in SRTP [RFC3711], 444 AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. 446 2.3.2. Defining New EKT Ciphers 448 Other specifications may extend this document by defining other 449 EKTCiphers as described in Section 5. This section defines how those 450 ciphers interact with this specification. 452 An EKTCipher determines how the EKTCiphertext field is written, and 453 how it is processed when it is read. This field is opaque to the 454 other aspects of EKT processing. EKT ciphers are free to use this 455 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 456 an input. The values of the parameters L, and T MUST be defined by 457 each EKTCipher. 459 2.4. Synchronizing Operation 461 If a source has its EKTKey changed by the key management, it MUST 462 also change its SRTP master key, which will cause it to send out a 463 new FullEKTField. This ensures that if key management thought the 464 EKTKey needs changing (due to a participant leaving or joining) and 465 communicated that to a source, the source will also change its SRTP 466 master key, so that traffic can be decrypted only by those who know 467 the current EKTKey. 469 2.5. Transport 471 EKT SHOULD be used over SRTP, and other specification MAY define how 472 to use it over SRTCP. SRTP is preferred because it shares fate with 473 transmitted media, because SRTP rekeying can occur without concern 474 for RTCP transmission limits, and to avoid SRTCP compound packets 475 with RTP translators and mixers. 477 2.6. Timing and Reliability Consideration 479 A system using EKT learns the SRTP master keys distributed with 480 FullEKTFields sent with the SRTP, rather than with call signaling. A 481 receiver can immediately decrypt an SRTP packet, provided the SRTP 482 packet contains a Full EKT Field. 484 This section describes how to reliably and expediently deliver new 485 SRTP master keys to receivers. 487 There are three cases to consider. The first case is a new sender 488 joining a session which needs to communicate its SRTP master key to 489 all the receivers. The second case is a sender changing its SRTP 490 master key which needs to be communicated to all the receivers. The 491 third case is a new receiver joining a session already in progress 492 which needs to know the sender's SRTP master key. 494 The three cases are: 496 New sender: A new sender SHOULD send a packet containing the 497 FullEKTField as soon as possible, always before or coincident with 498 sending its initial SRTP packet. To accommodate packet loss, it 499 is RECOMMENDED that three consecutive packets contain the Full EKT 500 Field be transmitted. 502 Rekey: By sending EKT over SRTP, the rekeying event shares fate with 503 the SRTP packets protected with that new SRTP master key. To 504 accommodate packet loss, it is RECOMMENDED that three consecutive 505 packets contain the FullEKTField be transmitted. 507 New receiver: When a new receiver joins a session it does not need 508 to communicate its sending SRTP master key (because it is a 509 receiver). When a new receiver joins a session the sender is 510 generally unaware of the receiver joining the session. Thus, 511 senders SHOULD periodically transmit the FullEKTField. That 512 interval depends on how frequently new receivers join the session, 513 the acceptable delay before those receivers can start processing 514 SRTP packets, and the acceptable overhead of sending the FullEKT 515 Field. If sending audio and video, the RECOMMENDED frequency is 516 the same as the rate of intra coded video frames. If only sending 517 audio, the RECOMMENDED frequency is every 100ms. 519 3. Use of EKT with DTLS-SRTP 521 This document defines an extension to DTLS-SRTP called SRTP EKT Key 522 Transport which enables secure transport of EKT keying material from 523 one DTLS-SRTP peer to another. This allows those peers to process 524 EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP 525 keying material. This combination of protocols is valuable because 526 it combines the advantages of DTLS, which has strong authentication 527 of the endpoint and flexibility, along with allowing secure 528 multiparty RTP with loose coordination and efficient communication of 529 per-source keys. 531 3.1. DTLS-SRTP Recap 533 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 534 to exchange keying material, algorithms, and parameters for SRTP. 535 The SRTP flow operates over the same transport as the DTLS-SRTP 536 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 537 performance and encryption flexibility benefits of SRTP with the 538 flexibility and convenience of DTLS-integrated key and association 539 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 540 key management method for SRTP, and a new RTP-specific data format 541 for DTLS. 543 3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 545 This document defines a new TLS negotiated extension called 546 "srtp_ekt_key_transport"and a new TLS content type called EKTMessage. 548 Using the syntax described in DTLS [RFC6347], the following 549 structures are used: 551 enum { 552 reserved(0), 553 aeskw_128(1), 554 aeskw_256(3), 555 } EKTCipherType; 557 struct { 558 EKTCipherType ekt_ciphers<0..254>; 559 } SupportedEKTCiphers; 561 struct { 562 EKTCipherType ekt_cipher; 563 uint ekt_key_value<1..256>; 564 uint srtp_master_salt<1..256>; 565 uint16 ekt_spi; 566 uint24 ekt_ttl; 567 } EKTkey; 569 enum { 570 ekt_key(0), 571 ekt_key_ack(1), 572 ekt_key_error(254), 573 (255) 574 } EKTMessageType; 576 struct { 577 EKTMessageType ekt_message_type; 578 select (EKTMessage.ekt_message_type) { 579 case ekt_key: 580 EKTKey; 581 } message; 582 } EKTMessage; 584 Figure 4: Additional TLS Data Structures 586 If a DTLS client includes "srtp_ekt_key_transport" in its 587 ClientHello, then a DTLS server that supports this extensions will 588 includes "srtp_ekt_key_transport" in its ServerHello message. If a 589 DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but 590 does not receive "srtp_ekt_key_transport" in the ServerHello, the 591 DTLS client MUST NOT send DTLS EKTMessage messages. 593 When a DTLS client sends the "srtp_ekt_key_transport" in its 594 ClientHello message, it MUST include the SupportedEKTCiphers as the 595 extension_data for the extension, listing the EKTCipherTypes the 596 client is willing to use in preference order, with the most preferred 597 version first. When the server responds in the 598 "srtp_ekt_key_transport" in its ServerHello message, it must include 599 a SupportedEKTCiphers list that selects a single EKTCipherType to use 600 (selected from the list provided by the client) or it returns an 601 empty list to indicate there is no matching EKTCipherType in the 602 clients list that the server is also willing to use. The value to be 603 used in the EKTCipherType for future extensions that define new 604 ciphers is the value from the "EKT Ciphers Type" IANA registry 605 defined in Section 5.2. 607 The figure above defines the contents for a new TLS content type 608 called EKTMessage which is registered in Section 5.4. The EKTMessage 609 above is used as the opaque fragment in the TLSPlaintext structure 610 defined in Section 6.2.1 of [RFC5246] and the "srtp_ekt_message" as 611 the content type. The "srtp_ekt_message" content type is defined and 612 registered in Section 5.3. 614 ekt_ttl: The maximum amount of time, in seconds, that this 615 ekt_key_value can be used. The ekt_key_value in this message MUST 616 NOT be used for encrypting or decrypting information after the TTL 617 expires. 619 When the Server wishes to provide a new EKT Key, it can send 620 EKTMessage containing an EKTKey with the new key information. The 621 client MUST respond with an EKTMessage of type ekt_key_ack, if the 622 EKTKey was successfully processed and stored or respond with the the 623 ekt_key_error EKTMessage otherwise. 625 The diagram below shows a message flow of DTLS client and DTLS server 626 using the DTLS-SRTP Key Transport extension. 628 Client Server 630 ClientHello + use_srtp + srtp_ekt_key_trans 631 --------> 632 ServerHello+use_srtp+srtp_ekt_key_trans 633 Certificate* 634 ServerKeyExchange* 635 CertificateRequest* 636 <-------- ServerHelloDone 637 Certificate* 638 ClientKeyExchange 639 CertificateVerify* 640 [ChangeCipherSpec] 641 Finished --------> 642 [ChangeCipherSpec] 643 <-------- Finished 644 ekt_key <-------- 645 ekt_key_ack --------> 646 SRTP packets <-------> SRTP packets 647 SRTP packets <-------> SRTP packets 648 ekt_key (rekey) <------- 649 ekt_key_ack --------> 650 SRTP packets <-------> SRTP packets 651 SRTP packets <-------> SRTP packets 653 Figure 5: DTLS/SRTP Message Flow 655 3.3. Offer/Answer Considerations 657 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 658 the DTLS handshake level and does not change the [RFC3264] Offer / 659 Answer messaging. 661 3.4. Sending the DTLS EKT_Key Reliably 663 The DTLS ekt_key is sent using the retransmissions specified in 664 Section 4.2.4. of DTLS [RFC6347]. 666 4. Security Considerations 668 EKT inherits the security properties of the DTLS-SRTP (or other) 669 keying it uses. 671 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 672 master keys. This property avoids any security concern over the re- 673 use of keys, by empowering the SRTP layer to create keys on demand. 674 Note that the inputs of EKT are the same as for SRTP with key- 675 sharing: a single key is provided to protect an entire SRTP session. 676 However, EKT remains secure even when SSRC values collide. 678 SRTP master keys MUST be randomly generated, and [RFC4086] offers 679 some guidance about random number generation. SRTP master keys MUST 680 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 681 be derived from other SRTP master keys. 683 The EKT Cipher includes its own authentication/integrity check. For 684 an attacker to successfully forge a full EKT packet, it would need to 685 defeat the authentication mechanisms of the EKT Cipher authentication 686 mechanism. 688 The presence of the SSRC in the EKTPlaintext ensures that an attacker 689 cannot substitute an EKTCiphertext from one SRTP stream into another 690 SRTP stream. 692 An attacker who tampers with the bits in FullEKTField can prevent the 693 intended receiver of that packet from being able to decrypt it. This 694 is a minor denial of service vulnerability. 696 An attacker could send packets containing a Full EKT Field, in an 697 attempt to consume additional CPU resources of the receiving system 698 by causing the receiving system will decrypt the EKT ciphertext and 699 detect an authentication failure. In some cases, caching the 700 previous values of the Ciphertext as described in Section 2.2.2.1 701 helps mitigate this issue. 703 Each EKT cipher specifies a value T that is the maximum number of 704 times a given key can be used. An endpoint MUST NOT send more than T 705 Full EKT Field using the same EKTKey. In addition, the EKTKey MUST 706 NOT be used beyond the lifetime provided by the TTL described in 707 Section 3.2. 709 The confidentiality, integrity, and authentication of the EKT cipher 710 MUST be at least as strong as the SRTP cipher and at least as strong 711 as the DTLS-SRTP ciphers. 713 Part of the EKTPlaintext is known, or easily guessable to an 714 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 715 In practice, this requirement does not impose any restrictions on our 716 choices, since the ciphers in use provide high security even when 717 much plaintext is known. 719 An EKT cipher MUST resist attacks in which both ciphertexts and 720 plaintexts can be adaptively chosen and adversaries that can query 721 both the encryption and decryption functions adaptively. 723 In some systems, when a member of a conference leaves the 724 conferences, the conferences is rekeyed so that member no longer has 725 the key. When changing to a new EKTKey, it is possible that the 726 attacker could block the EKTKey message getting to a particular 727 endpoint and that endpoint would keep sending media encrypted using 728 the old key. To mitigate that risk, the lifetime of the EKTKey 729 SHOULD be limited using the ekt_ttl. 731 5. IANA Considerations 733 5.1. EKT Message Types 735 IANA is requested to create a new registry for "EKT Messages Types". 736 The initial values in this registry are: 738 +--------------+-------+---------------+ 739 | Message Type | Value | Specification | 740 +--------------+-------+---------------+ 741 | Short | 0 | RFCAAAA | 742 | | | | 743 | Full | 2 | RFCAAAA | 744 | | | | 745 | Reserved | 63 | RFCAAAA | 746 | | | | 747 | Reserved | 255 | RFCAAAA | 748 +--------------+-------+---------------+ 750 Table 2: EKT Messages Types 752 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 753 this specification. 755 New entries to this table can be added via "Specification Required" 756 as defined in [RFC5226]. When requesting a new value, the requestor 757 needs to indicate if it is mandatory to understand or not. If it is 758 mandatory to understand, IANA needs to allocate a value less than 64, 759 if it is not mandatory to understand, a value greater than or equal 760 to 64 needs to be allocated. IANA SHOULD prefer allocation of even 761 values over odd ones until the even code points are consumed to avoid 762 conflicts with pre standard versions of EKT that have been deployed. 764 5.2. EKT Ciphers 766 IANA is requested to create a new registry for "EKT Ciphers". The 767 initial values in this registry are: 769 +----------+-------+---------------+ 770 | Name | Value | Specification | 771 +----------+-------+---------------+ 772 | AESKW128 | 1 | RFCAAAA | 773 | | | | 774 | AESKW256 | 3 | RFCAAAA | 775 | | | | 776 | Reserved | 255 | RFCAAAA | 777 +----------+-------+---------------+ 779 Table 3: EKT Cipher Types 781 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 782 this specification. 784 New entries to this table can be added via "Specification Required" 785 as defined in [RFC5226]. The expert SHOULD ensure the specification 786 defines the values for L and T as required in Section 2.3 of RFCAAA. 787 Allocated values MUST be in the range of 1 to 254. 789 5.3. TLS Extensions 791 IANA is requested to add "srtp_ekt_key_transport" as an new extension 792 name to the "ExtensionType Values" table of the "Transport Layer 793 Security (TLS) Extensions" registry with a reference to this 794 specification and allocate a value of TBD to for this. Note to RFC 795 Editor: TBD will be allocated by IANA. 797 Considerations for this type of extension are described in Section 5 798 of [RFC4366] and requires "IETF Consensus". 800 5.4. TLS Content Type 802 IANA is requested to add "srtp_ekt_message" as an new descriptions 803 name to the "TLS ContentType Registry" table of the "Transport Layer 804 Security (TLS) Extensions" registry with a reference to this 805 specification, a DTLS-OK value of "Y", and allocate a value of TBD to 806 for this content type. Note to RFC Editor: TBD will be allocated by 807 IANA. 809 This registry was defined in Section 12 of [RFC5246] and requires 810 "Standards Action". 812 6. Acknowledgements 814 Thank you to Russ Housley provided detailed review and significant 815 help with crafting text for this document. Thanks to David Benham, 816 Eddy Lem, Felix Wyss, Jonathan Lennox, Kai Fischer, Lakshminath 817 Dondeti, Magnus Westerlund, Michael Peck, Nermeen Ismail, Paul Jones, 818 Rob Raymond, and Yi Cheng for fruitful discussions, comments, and 819 contributions to this document. 821 This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03 822 and much of the text here came from that draft. 824 7. References 826 7.1. Normative References 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, 830 DOI 10.17487/RFC2119, March 1997, 831 . 833 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 834 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 835 RFC 3711, DOI 10.17487/RFC3711, March 2004, 836 . 838 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 839 "Randomness Requirements for Security", BCP 106, RFC 4086, 840 DOI 10.17487/RFC4086, June 2005, 841 . 843 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 844 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 845 DOI 10.17487/RFC5226, May 2008, 846 . 848 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 849 Specifications: ABNF", STD 68, RFC 5234, 850 DOI 10.17487/RFC5234, January 2008, 851 . 853 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 854 (TLS) Protocol Version 1.2", RFC 5246, 855 DOI 10.17487/RFC5246, August 2008, 856 . 858 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 859 (AES) Key Wrap with Padding Algorithm", RFC 5649, 860 DOI 10.17487/RFC5649, September 2009, 861 . 863 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 864 Security (DTLS) Extension to Establish Keys for the Secure 865 Real-time Transport Protocol (SRTP)", RFC 5764, 866 DOI 10.17487/RFC5764, May 2010, 867 . 869 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 870 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 871 January 2012, . 873 7.2. Informative References 875 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 876 with Session Description Protocol (SDP)", RFC 3264, 877 DOI 10.17487/RFC3264, June 2002, 878 . 880 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 881 and T. Wright, "Transport Layer Security (TLS) 882 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 883 . 885 Authors' Addresses 887 Cullen Jennings 888 Cisco Systems 889 Calgary, AB 890 Canada 892 Email: fluffy@iii.ca 894 John Mattsson (editor) 895 Ericsson AB 896 SE-164 80 Stockholm 897 Sweden 899 Phone: +46 10 71 43 501 900 Email: john.mattsson@ericsson.com 901 David A. McGrew 902 Cisco Systems 903 510 McCarthy Blvd. 904 Milpitas, CA 95035 905 US 907 Phone: (408) 525 8651 908 Email: mcgrew@cisco.com 909 URI: http://www.mindspring.com/~dmcgrew/dam.htm 911 Dan Wing 912 Cisco Systems 913 510 McCarthy Blvd. 914 Milpitas, CA 95035 915 US 917 Phone: (408) 853 4197 918 Email: dwing@cisco.com 920 Flemming Andreason 921 Cisco Systems 922 499 Thornall Street 923 Edison, NJ 08837 924 US 926 Email: fandreas@cisco.com