idnits 2.17.1 draft-ietf-avtcore-srtp-ekt-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4309 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 1204, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5649 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group D. McGrew 3 Internet-Draft F. Andreasen 4 Intended status: Standards Track D. Wing 5 Expires: January 10, 2013 Cisco 6 K. Fischer 7 Siemens Enterprise Communications 8 July 9, 2012 10 Encrypted Key Transport for Secure RTP 11 draft-ietf-avtcore-srtp-ekt-00 13 Abstract 15 Encrypted Key Transport (EKT) is an extension to Secure Real-time 16 Transport Protocol (SRTP) that provides for the secure transport of 17 SRTP master keys, Rollover Counters, and other information, within 18 SRTP or SRTCP. This facility enables SRTP to work for decentralized 19 conferences with minimal control. 21 This note defines EKT, and also describes how to use it with SDP 22 Security Descriptions, DTLS-SRTP, and MIKEY. These other key 23 management protocols provide an EKT key to everyone in a session, and 24 EKT coordinates the keys within the session. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 10, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Conventions Used In This Document . . . . . . . . . . . . 5 63 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 64 2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Packet Processing and State Machine . . . . . . . . . . . 8 66 2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 67 2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . . 10 68 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 12 70 2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 13 71 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 72 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 73 2.6. Timing and Reliability Consideration . . . . . . . . . . . 14 74 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 16 75 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 16 76 3.2. Relationship between EKT and SDP Security Descriptions . . 17 77 3.3. Overview of Combined EKT and SDP Security Description 78 Operation . . . . . . . . . . . . . . . . . . . . . . . . 19 79 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 19 80 3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 19 81 3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 20 82 3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 20 83 3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 20 84 3.5.1. Generating the Initial Offer - Unicast Streams . . . . 21 85 3.5.2. Generating the Initial Answer - Unicast Streams . . . 22 86 3.5.3. Processing of the Initial Answer - Unicast Streams . . 23 87 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 24 88 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 24 89 3.8. Backwards Compatibility Considerations . . . . . . . . . . 25 90 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 27 92 4.1. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 27 93 4.1.1. Scaling to Large Groups . . . . . . . . . . . . . . . 29 94 4.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 30 95 4.2.1. Generating the Initial Offer . . . . . . . . . . . . . 30 96 4.2.2. Generating the Initial Answer . . . . . . . . . . . . 31 97 4.2.3. Processing the Initial Answer . . . . . . . . . . . . 31 98 4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 32 99 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 33 100 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 34 101 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 36 102 5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 36 103 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 37 104 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 37 105 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 37 106 6. Using EKT for interoperability between key management 107 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 108 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 40 109 7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 41 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 112 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 114 11.1. Normative References . . . . . . . . . . . . . . . . . . . 46 115 11.2. Informative References . . . . . . . . . . . . . . . . . . 47 116 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with 117 Security Descriptions . . . . . . . . . . . . . . . . 48 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 120 1. Introduction 122 RTP is designed to allow decentralized groups with minimal control to 123 establish sessions, such as for multimedia conferences. 124 Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many 125 minimal-control scenarios, because it requires that SSRC values and 126 other data be coordinated among all of the participants in a session. 127 For example, if a participant joins a session that is already in 128 progress, the SRTP rollover counter (ROC) of each SRTP source in the 129 session needs to be provided to that participant. 131 The inability of SRTP to work in the absence of central control was 132 well understood during the design of that protocol; that omission was 133 considered less important than optimizations such as bandwidth 134 conservation. Additionally, in many situations SRTP is used in 135 conjunction with a signaling system that can provide most of the 136 central control needed by SRTP. However, there are several cases in 137 which conventional signaling systems cannot easily provide all of the 138 coordination required. It is also desirable to eliminate the layer 139 violations that occur when signaling systems coordinate certain SRTP 140 parameters, such as SSRC values and ROCs. 142 This document defines Encrypted Key Transport (EKT) for SRTP, an 143 extension to SRTP that fits within the SRTP framework and reduces the 144 amount of signaling control that is needed in an SRTP session. EKT 145 securely distributes the SRTP master key and other information for 146 each SRTP source, using SRTCP or SRTP to transport that information. 147 With this method, SRTP entities are free to choose SSRC values as 148 they see fit, and to start up new SRTP sources with new SRTP master 149 keys (see Section 2.2) within a session without coordinating with 150 other entities via signaling or other external means. This fact 151 allows to reinstate the RTP collision detection and repair mechanism, 152 which is nullified by the current SRTP specification because of the 153 need to control SSRC values closely. An SRTP endpoint using EKT can 154 generate new keys whenever an existing SRTP master key has been 155 overused, or start up a new SRTP source to replace an old SRTP source 156 that has reached the packet-count limit. EKT also solves the problem 157 in which the burst loss of the N initial SRTP packets can confuse an 158 SRTP receiver, when the initial RTP sequence number is greater than 159 or equal to 2^16 - N. These features can simplify many architectures 160 that implement SRTP. 162 EKT provides a way for an SRTP session participant, either a sender 163 or a receiver, to securely transport its SRTP master key and current 164 SRTP rollover counter to the other participants in the session. This 165 data, possibly in conjunction with additional data provided by an 166 external signaling protocol, furnishes the information needed by the 167 receiver to instantiate an SRTP/SRTCP receiver context. 169 EKT does not control the manner in which the SSRC and master key are 170 generated; it is only concerned with their secure transport. Those 171 values may be generated on demand by the SRTP endpoint, or may be 172 dictated by an external mechanism such as a signaling agent or a 173 secure group controller. 175 EKT is not intended to replace external key establishment mechanisms 176 such as SDP Security Descriptions [RFC4568], DTLS-SRTP [RFC5764], or 177 MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with 178 those methods, and it relieves them of the burden of tightly 179 coordinating every SRTP source among every SRTP participant. 181 This document is organized as follows. The complete normative 182 definition of EKT is contained in Section 2. It mainly consists of 183 packet processing algorithms (Section 2.2) and cryptographic 184 definitions (Section 2.3) . Section 3, Section 4, and Section 5 185 define the use of EKT with SDP Security Descriptions, DTLS-SRTP, and 186 MIKEY, respectively. Section 7 provides a design rationale. 187 Section 6 explains how EKT can interwork with keying in call 188 signaling. Security Considerations are discussed in Section 8, and 189 IANA considerations are provided in Section 9. 191 1.1. History 193 RFC Editor Note: please remove this section prior to publication as 194 an RFC. 196 This version is substantially revised from earlier versions, in order 197 to make it possible for the EKT data to be removed from a packet 198 without affecting the ability of the receiver to correctly process 199 the data that is present in that packet. This capability facilitates 200 interoperability between SRTP implementations with different SRTP key 201 management methods. The changes also greatly simplify the EKT 202 processing rules, and make the EKT data that must be carried in SRTP 203 and/or SRTCP packets somewhat larger. 205 1.2. Conventions Used In This Document 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 2. Encrypted Key Transport 213 In EKT, an SRTP master key is encrypted with a key encrypting key and 214 the resulting ciphertext is transported in selected SRTCP or in 215 selected SRTP packets. The key encrypting key is called an EKT key. 216 A single such key suffices for a single SRTP session, regardless of 217 the number of participants in that session. However, there can be 218 multiple EKT keys used within a particular session. 220 EKT defines a new method of providing SRTP master keys to an 221 endpoint. In order to convey the ciphertext of the SRTP master key, 222 and other additional information, an additional EKT field is added to 223 SRTP or SRTCP packets. When added to SRTCP, the EKT field appears at 224 the end of the packet, after the authentication tag, if that tag is 225 present, or after the MKI or the SRTCP index otherwise. When added 226 to SRTP, the EKT field appears at the end of the packet, after the 227 authentication tag, if that tag is present, or after the MKI or the 228 ciphertext of the encrypted portion of the packet otherwise. 230 2.1. EKT Field Formats 232 The EKT Field uses one of the two formats defined below. These two 233 formats can always be unambiguously distinguished on receipt by 234 examining the final bit of the EKT Field, which is also the final bit 235 of the SRTP or SRTCP packet. The first format is the Full EKT Field 236 (or Full_EKT_Field), and the second is the Short EKT Field (or 237 Short_EKT_Field). The formats are defined as 239 EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || ISN 241 EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext) 243 Full_EKT_Field = EKT_Ciphertext || SPI || '1' 245 Short_EKT_Field = Reserved || '0' 247 Figure 1: EKT data formats 249 Here || denotes concatenation, and '1' and '0' denote single one and 250 zero bits, respectively. These fields and data elements are defined 251 as follows: 253 EKT_Plaintext: The data that is input to the EKT encryption 254 operation. This data never appears on the wire, and is used only 255 in computations internal to EKT. 257 EKT_Ciphertext: The data that is output from the EKT encryption 258 operation, which is performed as as defined in Section 2.3. This 259 field is included in SRTP and SRTCP packets when EKT is in use. 260 The length of this field is variable, and is equal to the 261 ciphertext size N defined in Section 2.3. Note that the length of 262 the field is inferable from the SPI field, since the particular 263 EKT cipher used by the sender of a packet can be inferred from 264 that field. 266 Rollover Counter (ROC): The length of this field is fixed at 32 267 bits. It is included in the EKT plaintext, but does not appear on 268 the wire. On the sender side, this field is set to the current 269 value of the SRTP rollover counter in the SRTP context associated 270 with the SSRC in the SRTP or SRTCP packet. 272 Initial Sequence Number (ISN): The length of this field is fixed at 273 16 bits. It is included the EKT plaintext, but does not appear on 274 the wire. If this field is nonzero, then it indicates the RTP 275 sequence number of the initial RTP packet that is protected using 276 the SRTP master key conveyed (in encrypted form) by the EKT 277 Ciphertext field of this packet. If this field is zero, it 278 indicates that the initial RTP packet protected using the SRTP 279 master key conveyed in this packet preceded, or was concurrent 280 with, the last roll-over of the RTP sequence number. 282 Security Parameter Index (SPI): The length of this field is fixed at 283 15 bits. This field is included in SRTP and SRTCP packets when 284 EKT is in use. It indicates the appropriate EKT key and other 285 parameters for the receiver to use when processing the packet. It 286 is an "index" into a table of possibilities (which are established 287 via signaling or some other out-of-band means), much like the 288 IPsec Security Parameter Index [RFC4301]. The parameters that are 289 identified by this field are: 291 * The EKT key used to process the packet. 293 * The EKT cipher used to process the packet. 295 * The Secure RTP parameters associated with the SRTP Master Key 296 carried by the packet and the SSRC value in the packet. 297 Section 8.2. of [RFC3711] summarizes the parameters defined by 298 that specification. 300 * The Master Salt associated with the Master Key. (This value is 301 part of the parameters mentioned above, but we call it out for 302 emphasis.) The Master Salt is communicated separately, via 303 signaling, typically along with the EKT key. 305 Together, these data elements assoicated with an instance of EKT 306 are called an EKT parameter set. Within each SRTP session, each 307 distinct EKT parameter set that may be used MUST be associated 308 with a distinct SPI value, to avoid ambiguity. 310 Reserved: MUST be all zeros on transmission, and MUST be ignored on 311 reception. 313 Examples of the Full_EKT_Field and Short_EKT_Field formats are shown 314 in (Figure 2) and (Figure 3), respectively. These figures show the 315 on-the-wire data. The Ciphertext field holds encrypted data, and 316 thus has no apparent inner structure. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 : : 322 : EKT Ciphertext : 323 : : 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Security Parameter Index |1| 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: An example of the Full EKT Field format 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+ 333 | Reserved |0| 334 +-+-+-+-+-+-+-+-+ 336 Figure 3: An example of the Short EKT Field format 338 2.2. Packet Processing and State Machine 340 At any given time, each SRTP/SRTCP source has associated with it a 341 single EKT parameter set. This parameter set is used to process all 342 outbound packets, and is called the outbound parameter set. There 343 may be other EKT parameter sets that are used by other SRTP/SRTCP 344 sources in the same session. All of these EKT parameter sets SHOULD 345 be stored by all of the participants in an SRTP session, for use in 346 processing inbound SRTCP traffic. 348 2.2.1. Outbound Processing 350 When an SRTP or SRTCP packet is to be sent, the EKT field for that 351 packet is created as follows, or uses an equivalent set of steps. 353 The creation of the EKT field MUST precede the normal SRTP or SRTCP 354 packet processing, so that the ROC used in EKT is the same as the one 355 used in the SRTP or SRTCP processing. 357 First, the sender decides whether to use the Full or Short format. 358 When sending EKT with SRTP, the Full format SHOULD be used on the 359 initial SRTP packet in a session and after each rekeying event. When 360 sending EKT with SRTCP, the Full format MUST be used. Not all SRTP 361 or SRTCP packets need to include the EKT key, but it SHOULD be 362 included with some regularity, e.g., every second or every ten 363 seconds, though it need not be sent on a regular schedule. 365 If the Short format is used, an all-zero Reserved octet is appended 366 to the packet. Otherwise, processing continues as follows. 368 The Rollover Counter field in the packet is set to the current value 369 of the SRTP rollover counter (represented as an unsigned integer in 370 network byte order). 372 The Initial Sequence Number field is set to zero, if the initial RTP 373 packet protected using the current SRTP master key for this source 374 preceded, or was concurrent with, the last roll-over of the RTP 375 sequence number. Otherwise, that field is set to the value of the 376 RTP sequence number of the initial RTP packet that was or will be 377 protected by that key. When the SRTP master key corresponding to a 378 source is changed, the new key SHOULD be communicated in advance via 379 EKT. (Note that the ISN field allows the receiver to know when it 380 should start using the new key to process SRTP packets.) This 381 enables the rekeying event to be communicated before any RTP packets 382 are protected with the new key. The rekeying event MUST NOT change 383 the value of ROC (otherwise, the current value of the ROC would not 384 be known to late joiners of existing sessions). 386 The Security Parameter Index field is set to the value of the 387 Security Parameter Index that is associated with the outbound 388 parameter set. 390 The EKT_Plaintext field is computed from the SRTP Master Key, SSRC, 391 ROC, and ISN fields, as shown in Figure 1. 393 The EKT_Ciphertext field is set to the ciphertext created by 394 encrypting the EKT_Plaintext with the EKT cipher, using the KEK as 395 the encryption key. The encryption process is detailed in 396 Section 2.3. Implementations MAY cache the value of this field to 397 avoid recomputing it for each packet that is sent. 399 2.2.2. Inbound Processing 401 When an SRTP or SRTCP packet containing and EKT field is received, it 402 is processed as follows, or uses an equivalent set of steps. Inbound 403 EKT processing MUST take place prior to the usual SRTP or SRTCP 404 processing. 406 1. The final bit is checked to determine which EKT format is in use. 407 If the packet contains a Short EKT Tag, then the EKT Tag is 408 stripped off of the packet, and then the normal SRTP or SRTCP 409 processing is applied. If the packet contains a Full EKT Tag, 410 then processing continues as described below. 412 2. The Security Parameter Index (SPI) field is checked to determine 413 which EKT parameter set should be used when processing the 414 packet. If multiple parameter sets have been defined for the 415 SRTP session, then the one that is associated with the value of 416 the SPI field in the packet is used. This parameter set is 417 called the matching parameter set below. If there is no matching 418 SPI, then the verification function MUST return an indication of 419 authentication failure, and the steps described below are not 420 performed. 422 3. The EKT_Ciphertext is decrypted using the EKT_Key and EKT_Cipher 423 in the matching parameter set, as described in Section 2.3. If 424 the EKT decryption operation returns an authentication failure, 425 then the packet processing halts with an indication of failure. 426 Otherwise, the resulting EKT_Plaintext is parsed as described in 427 Figure 1, to recover the SRTP Master Key, SSRC, ROC, and ISN 428 fields. 430 4. The SSRC field output from the decryption operation is compared 431 to the SSRC field from the SRTP header. If the values of the two 432 fields do not match, then packet processing halts with an 433 indication of failure. Otherwise, it continues as follows. 435 5. If the ROC from the EKT_Plaintext is less than the ROC in the 436 SRTP context, then packet processing halts. Otherwise, the ROC 437 in the SRTP context is set to the value of the ROC from the 438 EKT_Plaintext, and the SRTP Master Key from the EKT_Plaintext is 439 accepted as the SRTP master key corresponding to the SRTP source 440 that sent the packet. If an MKI is present in the packet, then 441 the master key corresponds to the particular SSRC and MKI 442 combination. If there is no SRTP crypto context corresponding to 443 the SSRC in the packet, then a new crypto context is created. If 444 the crypto context is not new, then the rollover counter in the 445 context MUST NOT be set to a value lower than its current value. 446 (If the replay protection step described above is performed, it 447 ensures that this requirement is satisfied.) 449 6. If the Initial Sequence Number field is nonzero, then the initial 450 sequence number for the SRTP master key is set to the packet 451 index created by appending that field to the current rollover 452 counter and treating the result as a 48-bit unsigned integer. 453 The initial sequence number for the master key is equivalent to 454 the "From" value of the pair of indices (Section 8.1.1 455 of [RFC3711]) that can be associated with a master key. 457 7. The newly accepted SRTP master key, the SRTP parameters from the 458 matching parameter set, the SSRC from the packet, and the MKI 459 from the packet, if one is present, are stored in the crypto 460 context associated with the SRTP source. The SRTP Key Derivation 461 algorithm is run in order to compute the SRTP encryption and 462 authentication keys, and those keys are stored for use in SRTP 463 processing of inbound packets. The Key Derivation algorithm 464 takes as input the newly accepted SRTP master key, along with the 465 Master Salt from the matching parameter set. 467 Implementation note: the receiver may want to retain old 468 master keys for some brief period of time, so that out of 469 order packets can be processed. 471 8. At this point, EKT processing has successfully completed, and the 472 normal SRTP or SRTCP processing takes place. 474 Implementation note: the value of the EKT Ciphertext field is 475 identical in successive packets protected by the same EKT 476 parameter set and the same SRTP master key and ROC. This 477 ciphertext value MAY be cached by an SRTP receiver to minimize 478 computational effort by noting when the SRTP master key is 479 unchanged and avoiding repeating Steps 2, 3, 4 5, and 6. 481 2.3. Ciphers 483 EKT uses an authenticated cipher to encrypt the SRTP master keys, 484 ROC, and ISN. We first specify the interface to the cipher, in order 485 to abstract the interface away from the details of that function. We 486 then define the cipher that is used in EKT by default. This cipher 487 MUST be implemented, but another cipher that conforms to this 488 interface MAY be used, in which case its use MUST be coordinated by 489 external means (e.g., call signaling). 491 An EKT cipher consists of an encryption function and a decryption 492 function. The encryption function E(K, P) takes the following 493 inputs: 495 o a secret key K with a length of L bytes, and 497 o a plaintext value P with a length of M bytes. 499 The encryption function returns a ciphertext value C whose length is 500 N bytes, where N is at least M. The decryption function D(K, C) takes 501 the following inputs: 503 o a secret key K with a length of L bytes, and 505 o a ciphertext value C with a length of N bytes. 507 The decryption function returns a plaintext value P that is M bytes 508 long, or returns an indication that the decryption operation failed 509 because the ciphertext was invalid (i.e. it was not generated by the 510 encryption of plaintext with the key K). 512 These functions have the property that D(K, E(K, P)) = P for all 513 values of K and P. Each cipher also has a limit T on the number of 514 times that it can be used with any fixed key value. For each key, 515 the encryption function MUST NOT be invoked on more than T distinct 516 values of P, and the decryption function MUST NOT be invoked on more 517 than T distinct values of C. 519 The length of the EKT Plaintext is ten bytes, plus the length of the 520 SRTP Master Key. 522 Security requirements for EKT ciphers are discussed in Section 8. 524 2.3.1. The Default Cipher 526 The default EKT Cipher is the Advanced Encryption Standard (AES) 527 [FIPS197] Key Wrap with Padding [RFC5649] algorithm, which can be 528 used with plaintexts larger than 16 bytes in length, and is thus 529 suitable for keys of any size. It requires a plaintext length M that 530 is at least eight bytes, and it returns a ciphertext with a length of 531 N = M + 8 bytes. It can be used with key sizes of L = 16, 24, and 532 32, and its use with those key sizes is indicated as AESKW_128, 533 AESKW_192, and AESKW_256, respectively. The key size determines the 534 length of the AES key used by the Key Wrap algorithm. With this 535 cipher, T=2^48. 537 When AES-128 is used in SRTP and/or SRTCP, AESKW_128 SHOULD be used 538 in EKT. In this case, the EKT Plaintext is 26 bytes long, the EKT 539 Ciphertext is 40 bytes long, and the Full EKT field is 42 bytes long. 541 When AES-192 is used in SRTP and/or SRTCP, AESKW_192 SHOULD be used 542 in EKT. In this case, the EKT Plaintext is 34 bytes long, the EKT 543 Ciphertext is 48 bytes long, and the Full EKT field is 50 bytes long. 545 When AES-256 is used in SRTP and/or SRTCP, AESKW_256 SHOULD be used 546 in EKT. In this case, the EKT Plaintext is 42 bytes long, the EKT 547 Ciphertext is 56 bytes long, and the Full EKT field is 58 bytes long. 549 2.3.2. Other EKT Ciphers 551 Other specifications may extend this one by defining other EKT 552 ciphers per Section 9. This section defines how those ciphers 553 interact with this specification. 555 An EKT cipher determines how the EKT Ciphertext field is written, and 556 how it is processed when it is read. This field is opaque to the 557 other aspects of EKT processing. EKT ciphers are free to use this 558 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 559 an input. The values of the parameters L, M, N, and T MUST be 560 defined by each EKT cipher, and those values MUST be inferable from 561 the EKT parameter set. 563 2.4. Synchronizing Operation 565 A participant in a session MAY opt to use a particular EKT key to 566 protect outbound packets after it accepts that EKT key for protecting 567 inbound traffic. In this case, the fact that one participant has 568 changed to using a new EKT key for outbound traffic can trigger other 569 participants to switch to using the same key. 571 An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT 572 key has been changed. This will ensure that the set of participants 573 able to decrypt the traffic will be limited to those who know the 574 current EKT key. 576 EKT can be transported over SRTCP, but some of the information that 577 it conveys is used for SRTP processing; some elements of the EKT 578 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 579 packets can be lost and both SRTP and SRTCP packets may be delivered 580 out of order. This can lead to various race conditions if EKT is 581 transported over SRTCP but not SRTP, which we review below. 583 When joining an SRTP session, SRTP packets may be received before any 584 EKT over SRTCP packets, which implies the crypto context has not been 585 established, unless other external signaling mechanism has done so. 586 Rather than automatically discarding such SRTP packets, the receiver 587 MAY want to provisionally place them in a jitter buffer and delay 588 discarding them until playout time. 590 When an SRTP source using EKT over SRTCP performs a rekeying 591 operation, there is a race between the actual rekeying signaled via 592 SRTCP and the SRTP packets secured by the new keying material. If 593 the SRTP packets are received first, they will fail authentication; 594 alternatively, if authentication is not being used, they will decrypt 595 to unintelligible random-looking plaintext. (Note, however, that 596 [RFC3711] says that SRTP "SHOULD NOT be used without message 597 authentication".) In order to address this problem, the rekeying 598 event can be sent before packets using the new SRTP master key are 599 sent (by use of the ISN field). Another solution involves using an 600 MKI at the expense of added overhead in each SRTP packet. 601 Alternatively, receivers MAY want to delay discarding packets from 602 known SSRCs that fail authentication in anticipation of receiving a 603 rekeying event via EKT (SRTCP) shortly. 605 The ROC signaled via EKT over SRTCP may be off by one when it is 606 received by the other party(ies) in the session. In order to deal 607 with this, receivers should simply follow the SRTP packet index 608 estimation procedures defined in Section 3.3.1 [RFC3711]. 610 2.5. Transport 612 EKT MUST be used over SRTCP, whenever RTCP is in use. EKT MAY be 613 used over SRTP. When EKT over SRTP is used in an SRTP session in 614 which SRTCP is available, then EKT MUST be used for both SRTP and 615 SRTCP. 617 The packet processing, state machine, and Authentication Tag format 618 for EKT over SRTP are nearly identical to that for EKT over SRTCP. 619 Differences are highlighted in Section 2.2.1 and Section 2.2.2. 621 2.6. Timing and Reliability Consideration 623 SRTCP communicates the master key and ROC for the SRTP session. 624 Thus, as explained above, if SRTP packets are received prior to the 625 corresponding SRTCP (EKT) packet, a race condition occurs. From an 626 EKT point of view, it is therefore desirable for an SRTP sender to 627 send an EKT packet containing the Base Authentication Tag as soon as 628 possible, and in no case any later than when the initial SRTP packet 629 is sent. It is RECOMMENDED that the Base Authentication Tag be 630 transmitted 3 times (to accomodate packet loss) and to provide a 631 reliable indication to the receiver that the sender is now using the 632 EKT key. If the Base Authentication Tag sent in SRTCP, the SRTCP 633 timing rules associated with the profile under which it runs (e.g., 634 RTP/SAVP or RTP/SAVPF) MUST be obeyed. Subject to that constraint, 635 SRTP senders using EKT over SRTCP SHOULD send an SRTCP packet as soon 636 as possible after joining a session. Note that there is no need for 637 SRTP receivers to do so. Also note, that per RFC 3550, Section 6.2, 638 it is permissible to send a compound RTCP packet immediately after 639 joining a unicast session (but not a multicast session). 641 SRTCP is not reliable and hence SRTCP packets may be lost. This is 642 obviously a problem for endpoints joining an SRTP session and 643 receiving SRTP traffic (as opposed to SRTCP), or for endpoints 644 receiving SRTP traffic following a rekeying event. To reduce the 645 impact of lost packets, SRTP senders using EKT over SRTCP SHOULD send 646 SRTCP packets as often as allowed by the profile under which they 647 operate. 649 3. Use of EKT with SDP Security Descriptions 651 The SDP Security Descriptions (SDESC) [RFC4568] specification defines 652 a generic framework for negotiating security parameters for media 653 streams negotiated via the Session Description Protocol by use of a 654 new SDP "crypto" attribute and the Offer/Answer procedures defined in 655 [RFC3264]. In addition to the general framework, SDES also defines 656 how to use that framework specifically to negotiate security 657 parameters for Secure RTP. Below, we first provide a brief recap of 658 the crypto attribute when used for SRTP and we then explain how it is 659 complementary to EKT. In the rest of this Section, we provide 660 extensions to the crypto attribute and associated offer/answer 661 procedures to define its use with EKT. 663 3.1. SDP Security Descriptions Recap 665 The SRTP crypto attribute defined for SDESC contains a tag followed 666 by three types of parameters (refer to [RFC4568] for details): 668 o Crypto-suite. Identifies the encryption and authentication 669 transform 671 o Key parameters. SRTP keying material and parameters. 673 o Session parameters. Additional (optional) SRTP parameters such as 674 Key Derivation Rate, Forward Error Correction Order, use of 675 unencrypted SRTP, and other parameters defined by SDESC. 677 The crypto attributes in the example SDP in Figure 4 illustrate these 678 parameters. 680 v=0 681 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 682 s=SRTP Discussion 683 i=A discussion of Secure RTP 684 u=http://www.example.com/seminars/srtp.pdf 685 e=marge@example.com (Marge Simpson) 686 c=IN IP4 192.0.2.12 687 t=2873397496 2873404696 688 m=audio 49170 RTP/SAVP 0 689 a=crypto:1 AES_CM_128_HMAC_SHA1_80 690 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 691 FEC_ORDER=FEC_SRTP 692 a=crypto:2 F8_128_HMAC_SHA1_80 693 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 694 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 695 FEC_ORDER=FEC_SRTP 697 Figure 4: SDP Security Descriptions example 699 For legibility the SDP shows line breaks that are not present on the 700 wire. 702 The first crypto attribute has the tag "1" and uses the crypto-suite 703 AES_CM_128_HMAC_SHA1_80. The "inline" parameter provides the SRTP 704 master key and salt, the master key lifetime (number of packets), and 705 the (optional) Master Key Identifier (MKI) whose value is "1" and has 706 a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER 707 session parameter indicates the order of Forward Error Correction 708 used (FEC is applied before SRTP processing by the sender of the SRTP 709 media). 711 The second crypto attribute has the tag "2" and uses the crypto-suite 712 F8_128_HMAC_SHA1_80. It includes two SRTP master keys and associated 713 salts. The first one is used with the MKI value 1, whereas the 714 second one is used with the MKI value 2. Finally, the FEC_ORDER 715 session parameter indicates the order of Forward Error Correction 716 used. 718 3.2. Relationship between EKT and SDP Security Descriptions 720 SDP Security Descriptions [RFC4568] define a generic framework for 721 negotiating security parameters for media streams negotiated via the 722 Session Description Protocol by use of the Offer/Answer procedures 723 defined in [RFC3264]. In addition to the general framework, SDESC 724 also defines how to use it specifically to negotiate security 725 parameters for Secure RTP. 727 EKT and SDESC are complementary. SDESC can negotiate several of the 728 SRTP security parameters (e.g., cipher and use of Master Key 729 Identifier/MKI) as well as SRTP master keys. SDESC, however, does 730 not negotiate SSRCs and their associated Rollover Counter (ROC). 731 Instead, SDESC relies on a so-called "late binding", where a newly 732 observed SSRC will have its crypto context initialized to a ROC value 733 of zero. Clearly, this does not work for participants joining an 734 SRTP session that has been established for a while and hence has a 735 non-zero ROC. It is impossible to use SDESC to join an SRTP session 736 that is already in progress. In this case, EKT on the endpoint 737 running SDP Security can provide the additional signaling necessary 738 to communicate the ROC (Section 6.4.1 of [RFC4568]). The use of EKT 739 solves this problem by communicating the ROC associated with the SSRC 740 in the media plane. 742 SDP Security Descriptions negotiates different SRTP master keys in 743 the send and receive direction. The offer contains the master key 744 used by the offerer to send media, and the answer contains the master 745 key used by the answerer to send media. Consequently, if media is 746 received by the offerer prior to the answer being received, the 747 offerer does not know the master key being used. Use of SDP security 748 preconditions can solve this problem, however it requires an 749 additional round-trip as well as a more complicated state machine. 750 EKT solves this problem by simply sending the master key used in the 751 media plane thereby avoiding the need for security preconditions. 753 If multiple crypto-suites were offered, the offerer also will not 754 know which of the crypto-suites offered was selected until the answer 755 is received. EKT solves this problem by using a correlator, the 756 Security Parameter Index (SPI), which uniquely identifies each crypto 757 attribute in the offer. 759 One of the primary call signaling protocols using offer/answer is the 760 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 761 message to initiate a media session and typically includes an offer 762 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 763 which potentially can lead to multiple answers being received. 764 SDESC, however, does not properly support this scenario, mainly 765 because SDP and RTP/RTCP does not contain sufficient information to 766 allow for correlation of an incoming RTP/RTCP packet with a 767 particular answer SDP. Note that extensions providing this 768 correlation do exist (e.g., Interactive Connectivity Establishment 769 (ICE)). SDESC addresses this point-to-multipoint problem by moving 770 each answer to a separate RTP transport address thereby turning a 771 point-to-multipoint scenario into multiple point-to-point scenarios. 772 There are however significant disadvantages to doing so. As long as 773 the crypto attribute in the answer does not contain any declarative 774 parameters that differ from those in the offer, EKT solves this 775 problem by use of the SPI correlator and communication of the 776 answerer's SRTP master key in EKT. 778 As can be seen from the above, the combination of EKT and SDESC 779 provides a better solution to SRTP negotiation for offer/answer than 780 either of them alone. SDESC negotiates the various SRTP crypto 781 parameters (which EKT does not), whereas EKT addresses the 782 shortcomings of SDESC. 784 3.3. Overview of Combined EKT and SDP Security Description Operation 786 We define three session extension parameters to SDESC to communicate 787 the EKT cipher, EKT key, and Security Parameter Index to the peer. 788 The original SDESC parameters are used as defined in [RFC4568], 789 however the procedures associated with the SRTP master key differ 790 slightly, since both SDESC and EKT communicate an SRTP master key. 791 In particular, the SRTP master key communicated via SDESC is used 792 only if there is currently no crypto context established for the SSRC 793 in question. This will be the case when an entity has received only 794 the offer or answer, but has yet to receive a valid EKT message from 795 the peer. Once a valid EKT message is received for the SSRC, the 796 crypto context is initialized accordingly, and the SRTP master key 797 will then be derived from the EKT message. Subsequent offer/answer 798 exchanges do not change this: The most recent SRTP master key 799 negotiated via EKT will be used, or, if none is available for the 800 SSRC in question, the most recent SRTP master key negotiated via 801 offer/answer will be used. Note that with these rules, once a valid 802 EKT message has been received for a given SSRC, rekeying for that 803 SSRC can only be done via EKT. The associated SRTP crypto parameters 804 however can be changed via SDESC. 806 3.4. EKT Extensions to SDP Security Descriptions 808 In order to use EKT and SDESC in conjunction with each other, the 809 following new SDES session parameters are defined. These MUST NOT 810 appear more than once in a given crypto attribute: 812 EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key 814 EKT_Key: The EKT key used to encrypt the SRTP Master Key 816 EKT_SPI: The EKT Security Parameter Index 818 Below are details on each of these attributes. 820 3.4.1. EKT_Cipher 822 The (optional) EKT_Cipher parameter defines the EKT cipher used to 823 encrypt the EKT key with in SRTCP packets. The default value is 824 "AESKW_128" in accordance with Section 2.3.1. For the AES Key Wrap 825 cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are 826 defined for values of L=16, 24, and 32 respectively. In the Offer/ 827 Answer model, the EKT_Cipher parameter is a negotiated parameter. 829 3.4.2. EKT_Key 831 The (mandatory) EKT_Key parameter is the key K used to encrypt the 832 SRTP Master Key in SRTCP packets. The value is base64 encoded as 833 described in Section 4 [RFC4648]. When base64 decoding the key, 834 padding characters (i.e., one or two "=" at the end of the base64 835 encoded data) are discarded (see [RFC4648] for details). Base64 836 encoding assumes that the base64 encoding input is an integral number 837 of octets. If a given EKT cipher requires the use of a key with a 838 length that is not an integral number of octets, said cipher MUST 839 define a padding scheme that results in the base64 input being an 840 integral number of octets. For example, if the length defined was 841 250 bits, then 6 padding bits would be needed, which could be defined 842 to be the last 6 bits in a 256 bit input. In the Offer/Answer model, 843 the EKT_Key parameter is a negotiated parameter. 845 3.4.3. EKT_SPI 847 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 848 It is encoded as an ASCII string representing the hexadecimal value 849 of the Security Parameter Index. The SPI identifies the *offer* 850 crypto attribute (including the EKT Key and Cipher) being used for 851 the associated SRTP session. A crypto attribute corresponds to an 852 EKT Parameter Set and hence the SPI effectively identifies a 853 particular EKT parameter set. Note that the scope of the SPI is the 854 SRTP session, which may or may not be limited to the scope of the 855 associated SIP dialog. In particular, if one of the participants in 856 an SRTP session is an SRTP translator, the scope of the SRTP session 857 is not limited to the scope of a single SIP dialog. However, if all 858 of the participants in the session are endpoints or mixers, the scope 859 of the SRTP session will correspond to a single SIP dialog. In the 860 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 862 3.5. Offer/Answer Procedures 864 In this section, we provide the offer/answer procedures associated 865 with use of the three new SDESC parameters defined in Section 866 Section 3.4. Since SDESC is defined only for unicast streams, we 867 provide only offer/answer procedures for unicast streams here as 868 well. 870 3.5.1. Generating the Initial Offer - Unicast Streams 872 When the initial offer is generated, the offerer MUST follow the 873 steps defined in [RFC4568] Section 7.1.1 as well as the following 874 steps. 876 For each unicast media line using SDESC and where use of EKT is 877 desired, the offerer MUST include one EKT_Key parameter and one 878 EKT_SPI parameter in at least one "crypto" attribute (see [RFC4568]). 879 The EKT_SPI parameter serves to identify the EKT parameter set used 880 for a particular SRTCP packet. Consequently, within a single media 881 line, a given EKT_SPI value MUST NOT be used with multiple crypto 882 attributes. Note that the EKT parameter set to use for the session 883 is not yet established at this point; each offered crypto attribute 884 contains a candidate EKT parameter set. Furthermore, if the media 885 line refers to an existing SRTP session, then any SPI values used for 886 EKT parameter sets in that session MUST NOT be remapped to any 887 different EKT parameter sets. When an offer describes an SRTP 888 session that is already in progress, the offer SHOULD use an EKT 889 parameter set (incl. EKT_SPI and EKT_KEY) that is already in use. 891 If an EKT_Cipher other than the default cipher is to be used, then 892 the EKT_Cipher parameter MUST be included as well. 894 If a given crypto attribute includes more than one set of SRTP key 895 parameters (SRTP master key, salt, lifetime, MKI), they MUST all use 896 the same salt. (EKT requires a single shared salt between all the 897 participants in the direct SRTP session). 899 Important Note: The scope of the offer/answer exchange is the SIP 900 dialog(s) established as a result of the INVITE, however the scope 901 of EKT is the direct SRTP session, i.e., all the participants that 902 are able to receive SRTP and SRTCP packets directly. If an SRTP 903 session spans multiple SIP dialogs, the EKT parameter sets MUST be 904 synchronized between all the SIP dialogs where SRTP and SRTCP 905 packets can be exchanged. In the case where the SIP entity 906 operates as an RTP mixer (and hence re-originates SRTP and SRTCP 907 packets with its own SSRC), this is not an issue, unless the mixer 908 receives traffic from the various participants on the same 909 destination IP address and port, in which case further 910 coordination of SPI values and crypto parameters may be needed 911 between the SIP dialogs (note that SIP forking with multiple early 912 media senders is an example of this). However if it operates as 913 an RTP translator, synchronized negotiation of the EKT parameter 914 sets on *all* the involved SIP dialogs will be needed. This is 915 non-trivial in a variety of use cases, and hence use of the 916 combined SDES/EKT mechanism with RTP translators should be 917 considered very carefully. It should be noted, that use of SRTP 918 with RTP translators in general should be considered very 919 carefully as well. 921 The EKT session parameters can either be included as optional or 922 mandatory parameters, however within a given crypto attribute, they 923 MUST all be either optional or mandatory. 925 3.5.2. Generating the Initial Answer - Unicast Streams 927 When the initial answer is generated, the answerer MUST follow the 928 steps defined in [RFC4568] Section 7.1.2 as well as the following 929 steps. 931 For each unicast media line using SDESC, the answerer examines the 932 associated crypto attribute(s) for the presence of EKT parameters. 933 If mandatory EKT parameters are included with a "crypto" attribute, 934 the answerer MUST support those parameters in order to accept that 935 offered crypto attribute. If optional EKT parameters are included 936 instead, the answerer MAY accept the offered crypto attribute without 937 using EKT. However, doing so will prevent the offerer from 938 processing any packets received before the answer. If neither 939 optional nor mandatory EKT parameters are included with a crypto 940 attribute, and that crypto attribute is accepted in the answer, EKT 941 MUST NOT be used. If a given a crypto attribute includes a mixture 942 of optional and mandatory EKT parameters, or an incomplete set of 943 mandatory EKT parameters, that crypto attribute MUST be considered 944 invalid. 946 When EKT is used with SDESC, the offerer and answerer MUST use the 947 same SRTP master salt. Thus, the SRTP key parameter(s) in the answer 948 crypto attribute MUST use the same master salt as the one accepted 949 from the offer. 951 When the answerer accepts the offered media line and EKT is being 952 used, the crypto attribute included in the answer MUST include the 953 same EKT parameter values as found in the accepted crypto attribute 954 from the offer (however, if the default EKT cipher is being used, it 955 may be omitted). Furthermore, the EKT parameters included MUST be 956 mandatory (i.e., no "-" prefix). 958 Acceptance of a crypto attribute with EKT parameters leads to 959 establishment of the EKT parameter set for the corresponding SRTP 960 session. Consequently, the answerer MUST send packets in accordance 961 with that particular EKT parameter set only. If the answerer wants 962 to enable the offerer to process SRTP packets received by the offerer 963 before it receives the answer, the answerer MUST NOT include any 964 declarative session parameters that either were not present in the 965 offered crypto attribute, or were present but with a different value. 967 Otherwise, the offerer's view of the EKT parameter set would differ 968 from the answerer's until the answer is received. Similarly, unless 969 the offerer and answerer has other means for correlating an answer 970 with a particular SRTP session, the answer SHOULD NOT include any 971 declarative session parameters that either were not present in the 972 offered crypto attribute, or were present but with a different value. 973 If this recommendation is not followed and the offerer receives 974 multiple answers (e.g., due to SIP forking), the offerer may not be 975 able to process incoming media stream packets correctly. 977 3.5.3. Processing of the Initial Answer - Unicast Streams 979 When the offerer receives the answer, it MUST perform the steps in 980 [RFC4568] Section 7.1.3 as well as the following steps for each SRTP 981 media stream it offered with one or more crypto lines containing EKT 982 parameters in it. 984 If the answer crypto line contains EKT parameters, and the 985 corresponding crypto line from the offer contained the same EKT 986 values, use of EKT has been negotiated successfully and MUST be used 987 for the media stream. When determining whether the values match, 988 optional and mandatory parameters MUST be considered equal. 989 Furthermore, if the default EKT cipher is being used, it MAY be 990 either present or absent in the offer and/or answer. 992 If the answer crypto line does not contain EKT parameters, then EKT 993 MUST NOT be used for the corresponding SRTP session. Note that if 994 the accepted crypto attribute contained mandatory EKT parameters in 995 the offer, and the crypto attribute in the answer does not contain 996 EKT parameters, then negotiation has failed (Section 5.1.3 of 997 [RFC4568]). 999 If the answer crypto line contains EKT parameters but the 1000 corresponding offered crypto line did not, or if the parameters don't 1001 match or are invalid, then the offerer MUST consider the crypto line 1002 invalid (see Section 7.1.3 of [RFC4568] for further operation). 1004 The EKT parameter set is established when the answer is received, 1005 however there are a couple of special cases to consider here. First 1006 of all, if an SRTCP packet is received prior to the answer, then the 1007 EKT parameter set is established provisionally based on the SPI 1008 included. Once the answer (which may include declarative session 1009 parameters) is received, the EKT parameter set is fully established. 1010 The second case involves receipt of multiple answers due to SIP 1011 forking. In this case, there will be multiple EKT parameter sets; 1012 one for each SRTP session. As mentioned earlier, reliable 1013 correlation of SIP dialogs to SRTP sessions requires extensions, and 1014 hence if one or more of the answers include declarative session 1015 parameters, it may be difficult to fully establish the EKT parameter 1016 set for each SRTP session. In the absence of a specific correlation 1017 mechanism, it is RECOMMENDED, that such correlation be done based on 1018 the signaled receive IP-address in the SDP and the observed source 1019 IP-address in incoming SRTP/SRTCP packets, and, if necessary, the 1020 signaled receive UDP port and the observed source UDP port. 1022 3.6. SRTP-Specific Use Outside Offer/Answer 1024 Security Descriptions use for SRTP is not defined outside offer/ 1025 answer and hence neither does Security Descriptions with EKT. 1027 3.7. Modifying the Session 1029 When a media stream using the SRTP security descriptions has been 1030 established, and a new offer/answer exchange is performed, the 1031 offerer and answerer MUST follow the steps in Section 7.1.4 of 1032 [RFC4568] as well as the following steps. SDESC allows for all 1033 parameters of the session to be modified, and the EKT session 1034 parameters are no exception to that, however, there are a few 1035 additional rules to be adhered to when using EKT. 1037 It is permissible to start a session without the use of EKT, and then 1038 subsequently start using EKT, however the converse is not. Thus, 1039 once use of EKT has been negotiated on a particular media stream, EKT 1040 MUST continue to be used on that media stream in all subsequent 1041 offer/answer exchanges. 1043 The reason for this is that both SDESC and EKT communicate the SRTP 1044 Master Key with EKT Master Keys taking precedence. Reverting back to 1045 an SDESC-controlled master key in a synchronized manner is difficult. 1047 Once EKT is being used, the salt for the direct SRTP session MUST NOT 1048 be changed. Thus, a new offer/answer which does not create a new 1049 SRTP session (e.g., because it reuses the same IP address and port) 1050 MUST use the same salt for all crypto attributes as is currently used 1051 for the direct SRTP session. 1053 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1054 value to a different EKT parameter set until 2^32 other mappings have 1055 been used within the SRTP session. In practice, this requirements is 1056 most easily met by using a monotonically increasing SPI value (modulo 1057 2^32 and starting with zero) per direct SRTP session. Note that a 1058 direct SRTP session may span multiple SIP dialogs, and in such cases 1059 coordination of SPI values across those SIP dialogs will be required. 1060 In the simple point-to-point unicast case without translators, the 1061 requirement simply applies within each media line in the SDP. In the 1062 point-to-multipoint case, the requirement applies across all the 1063 associated SIP dialogs. 1065 3.8. Backwards Compatibility Considerations 1067 Backwards compatibility can be achieved in a couple of ways. First 1068 of all, SDESC allows for session parameters to be prefixed with "-" 1069 to indicate that they are optional. If the answerer does not support 1070 the EKT session parameters, such optional parameters will simply be 1071 ignored. When the answer is received, absence of the parameters will 1072 indicate that EKT is not being used. Receipt of SRTCP packets prior 1073 to receipt of such an answer will obviously be problematic (as is 1074 normally the case for SDESC without EKT). 1076 Alternatively, SDESC allows for multiple crypto lines to be included 1077 for a particular media stream. Thus, two crypto lines that differ in 1078 their use of EKT parameters (presence in one, absence in the other) 1079 can be used as a way to negotiate use of EKT. When the answer is 1080 received, the accepted crypto attribute will indicate whether EKT is 1081 being used or not. 1083 3.9. Grammar 1085 The ABNF [RFC5234] syntax for the one new SDP Security Descriptions 1086 session parameter, EKT, comprising three parts is shown in Figure 5. 1088 ekt = "EKT=" cipher "|" key "|" spi 1089 cipher = cipher-extension / "AES_128" / "AESKW_128" / 1090 "AESKW_192" / "AESKW_256" 1091 cipher-extension = 1*(ALPHA / DIGIT / "_") 1092 key = 1*(base64) ; See Section 4 of [RFC4648] 1093 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1094 spi = 4HEXDIG ; See [RFC5234] 1096 Figure 5: ABNF for the EKT session parameters 1098 Using the example from Figure 5 with the EKT extensions to SDP 1099 Security Descriptions results in the following example SDP: 1101 v=0 1102 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1103 s=SRTP Discussion 1104 i=A discussion of Secure RTP 1105 u=http://www.example.com/seminars/srtp.pdf 1106 e=marge@example.com (Marge Simpson) 1107 c=IN IP4 192.0.2.12 1108 t=2873397496 2873404696 1109 m=audio 49170 RTP/SAVP 0 1110 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1111 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1112 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1113 a=crypto:2 F8_128_HMAC_SHA1_80 1114 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1115 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1116 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1118 For legibility the SDP shows line breaks that are not present on the 1119 wire. 1121 4. Use of EKT with DTLS-SRTP Key Transport 1123 This document defines an extension to DTLS-SRTP called Key Transport. 1124 Using EKT with the DTLS-SRTP Key Transport extensions allows securely 1125 transporting SRTP keying material from one DTLS-SRTP peer to another, 1126 so the same SRTP keying material can be used by those peers and so 1127 those peers can process EKT keys. This combination of protocols is 1128 valuable because it combines the advantages of DTLS (strong 1129 authentication of the endpoint and flexibility) with the advantages 1130 of EKT (allowing secure multiparty RTP with loose coordination and 1131 efficient communication of per-source keys). 1133 4.1. EKT Extensions to DTLS-SRTP 1135 This document adds a new TLS negotiated extension called "ekt". This 1136 adds a new TLS content type, EKT, and a new negotiated extension EKT. 1137 The negotiated extension MUST only be requested in conjunction with 1138 the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server 1139 indicates its support for EKT by including "dtls-srtp-ekt" in its SDP 1140 and "ekt" in its TLS ServerHello message. If a DTLS client includes 1141 "ekt" in its ClientHello, but does not receive "ekt" in the 1142 ServerHello, the DTLS client MUST NOT send DTLS packets with the 1143 "ekt" content-type. 1145 Using the syntax described in DTLS [I-D.ietf-tls-rfc4347-bis], the 1146 following structures are used: 1148 enum { 1149 ekt_key(0), 1150 ekt_key_ack(1), 1151 ekt_key_error(254), 1152 (255) 1153 } SRTPKeyTransportType; 1155 struct { 1156 SRTPKeyTransportType keytrans_type; 1157 uint24 length; 1158 uint16 message_seq; 1159 uint24 fragment_offset; 1160 uint24 fragment_length; 1161 select (SRTPKeyTransportType) { 1162 case ekt_key: 1163 EKTkey; 1164 }; 1165 } KeyTransport; 1167 enum { 1168 AES_128(0), 1169 AESKW_128(1), 1170 AESKW_192(2), 1171 AESKW_256(3), 1172 } ektcipher; 1174 struct { 1175 ektcipher EKT_Cipher; 1176 uint EKT_Key_Value<1..256>; 1177 uint EKT_Master_Salt<1..256>; 1178 uint16 EKT_SPI; 1179 } EKTkey; 1181 Figure 6: Additional TLS Data Structures 1183 The diagram below shows a message flow of DTLS client and DTLS server 1184 using the DTLS-SRTP Key Transport extension. SRTP packets exchanged 1185 prior to the ekt_message are encrypted using the SRTP master key 1186 derived from the normal DTLS-SRTP key derivation function. After the 1187 ekt_key message, they can be encrypted using the EKT key. 1189 Editor's note: do we need reliability for the ekt_key messages? 1190 Client Server 1192 ClientHello + use_srtp + EKT 1193 --------> 1194 ServerHello + use_srtp + EKT 1195 Certificate* 1196 ServerKeyExchange* 1197 CertificateRequest* 1198 <-------- ServerHelloDone 1199 Certificate* 1200 ClientKeyExchange 1201 CertificateVerify* 1202 [ChangeCipherSpec] 1203 Finished --------> 1204 [ChangeCipherSpec] 1205 <-------- Finished 1206 SRTP packets <-------> SRTP packets 1207 SRTP packets <-------> SRTP packets 1208 ekt_key --------> 1209 SRTP packets <-------> SRTP packets 1210 SRTP packets <-------> SRTP packets 1212 Figure 7: Handshake Message Flow 1214 4.1.1. Scaling to Large Groups 1216 In certain scenarios it is useful to perform DTLS-SRTP with a device 1217 that is not the RTP peer. A common scenario is multicast, where it 1218 is necessary to distribute the DTLS-SRTP (and EKT distribution) to 1219 several devices. To allow for this, a new SDP attribute, dtls-srtp- 1220 host, is defined which follows the general syntax specified in 1221 Section 5.13 of [RFC4566]. When signaled, it indicates this host 1222 controls the EKT keying for all group members. For the dtls-srtp- 1223 host attribute: 1225 o the name is the ASCII string "dtls-srtp-host" (lowercase) 1227 o the value is the IP address and port number used for DTLS-SRTP 1229 o This is a media-level attribute and MUST NOT appear at the session 1230 level 1232 The formal description of the attribute is defined by the following 1233 ABNF [RFC5234] syntax: 1235 attribute = "a=dtls-srtp-host:" 1236 dtls-srtp-host-info *(SP dtls-srtp-host-info) 1237 host-info = nettype space addrtype space 1238 connection-address space port CRLF 1240 Multiple IP/port pairs are provided for IPv6/IPv4 interworking, and 1241 to allow failover. The receiving host SHOULD attempt to use them in 1242 the order provided. 1244 An example of SDP containing the dtls-srtp-host attribute: 1246 v=0 1247 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1248 s=SRTP Discussion 1249 i=A discussion of Secure RTP 1250 u=http://www.example.com/seminars/srtp.pdf 1251 e=marge@example.com (Marge Simpson) 1252 c=IN IP4 192.0.2.12 1253 t=2873397496 2873404696 1254 m=audio 49170 UDP/TLS/RTP/SAVP 0 1255 a=fingerprint:SHA-1 1256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1257 a=dtls-srtp-ekt 1258 a=dtls-srtp-host:IN IP4 192.0.2.13 56789 1260 For legibility the SDP shows line breaks that are not present on the 1261 wire. 1263 4.2. Offer/Answer Considerations 1265 This section describes Offer/Answer considerations for the use of EKT 1266 together with DTLS-SRTP for unicast and multicast streams. The 1267 offerer and answerer MUST follow the procedures specified in 1268 [RFC5764] as well as the following ones. 1270 As most DTLS-SRTP processing is performed on the media channel, 1271 rather than in SDP, there is little processing performed in SDP other 1272 than informational and to redirect DTLS-SRTP to an alternate host. 1273 Advertising support for the extension is necessary in SDP because in 1274 some cases it is required to establish an SRTP call. For example, a 1275 mixer may be able to only support SRTP listeners if those listeners 1276 implement DTLS Key Transport (because it lacks the CPU cycles 1277 necessary to encrypt SRTP uniquely for each listener). 1279 4.2.1. Generating the Initial Offer 1281 The initial offer contains a new SDP attribute, "dtls-srtp-ekt", 1282 which contains no value. This indicates the offerer is capable of 1283 supporting DTLS-SRTP with EKT extensions, and indicates the desire to 1284 use the "ekt" extension during the DTLS-SRTP handshake. If the 1285 offerer wants another host to perform DTLS-SRTP-EKT processing, it 1286 also includes the dtls-srtp-host attribute in its offer 1287 (Section 4.1). 1289 An example of SDP containing the dtls-srtp-ekt attribute:: 1291 v=0 1292 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1293 s=SRTP Discussion 1294 i=A discussion of Secure RTP 1295 u=http://www.example.com/seminars/srtp.pdf 1296 e=marge@example.com (Marge Simpson) 1297 c=IN IP4 192.0.2.12 1298 t=2873397496 2873404696 1299 m=audio 49170 UDP/TLS/RTP/SAVP 0 1300 a=fingerprint:SHA-1 1301 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1302 a=dtls-srtp-ekt 1304 For legibility the SDP shows line breaks that are not present on the 1305 wire. 1307 4.2.2. Generating the Initial Answer 1309 Upon receiving the initial offer, the presence of the dtls-srtp-ekt 1310 attribute indicates a desire to receive the EKT extension in the 1311 DTLS-SRTP handshake. The presence of the dtls-srtp-host attribute 1312 indicates an alternate host to send the DTLS-SRTP handshake (instead 1313 of the host on the c/m lines). DTLS messages should be constructed 1314 according to those two attributes. 1316 The SDP answer SHOULD contain the dtls-srtp-ekt attribute to indicate 1317 the answerer understands dtls-srtp. It should only contain the dtls- 1318 srtp-host attribute if the answerer also wishes to offload its DTLS- 1319 SRTP processing to another host. 1321 4.2.3. Processing the Initial Answer 1323 The presence of the dtls-srtp-ekt attribute indicates a desire by the 1324 answerer to perform DTLS-SRTP with EKT extensions, and the dtls-srtp- 1325 host attribute indicates an alternate host for DTLS-SRTP processing. 1327 After successful negotiation of the key_transport extension, the DTLS 1328 client and server MAY exchange SRTP packets, encrypted using the KDF 1329 described in [RFC5764]. This is normal and expected, even if Key 1330 Transport was negotiated by both sides, as neither side may (yet) 1331 have a need to alter the SRTP key. However, it is also possible that 1332 one (or both) peers will immediately send new_srtp_key message before 1333 sending any SRTP, and also possible that SRTP, encrypted with an 1334 unknown key, may be received before the new_srtp_key message is 1335 received. 1337 4.2.4. Modifying the Session 1339 As DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel (media 1340 channel) rather than signaling, no special processing for modifying 1341 the session is necessary. 1343 5. Use of EKT with MIKEY 1345 The advantages outlined in Section 1 are useful in some scenarios in 1346 which MIKEY is used to establish SRTP sessions. In this section, we 1347 briefly review MIKEY and related work, and discuss these scenarios. 1349 An SRTP sender or a group controller can use MIKEY to establish a 1350 SRTP cryptographic context. This capability includes the 1351 distribution of a TEK generation key (TGK) or the TEK itself, 1352 security policy payload, crypto session bundle ID (CSB_ID) and a 1353 crypto session ID (CS_ID). The TEK directly maps to an SRTP master 1354 key, whereas the TGK is used along with the CSB_ID and a CS_ID to 1355 generate a TEK. The CS_ID is used to generate multiple TEKs (SRTP 1356 master keys) from a single TGK. For a media stream in SDP, MIKEY 1357 allocates two consecutive numbers for the crypto session IDs, so that 1358 each direction uses a different SRTP master key (see [RFC4567]). 1360 The MIKEY specification [RFC3830] defines three modes to exchange 1361 keys, associated parameters and to protect the MIKEY message: pre- 1362 shared key, public-key encryption and Diffie-Hellman key exchange. 1363 In the first two modes the MIKEY initiator only chooses and 1364 distributes the TGK or TEK, whereas in the third mode both MIKEY 1365 entities (the initiator and responder) contribute to the keys. All 1366 three MIKEY modes have in common that for establishing a SRTP session 1367 the exchanged key is valid for the send and receive direction. 1368 Especially for group communications it is desirable to update the 1369 SRTP master key individually per direction. EKT provides this 1370 property by distributing the SRTP master key within the SRTP/SRTCP 1371 packet. 1373 MIKEY already supports synchronization of ROC values between the 1374 MIKEY initiator and responder. The SSRC / ROC value pair is part of 1375 the MIKEY Common Header payload. This allows providing the current 1376 ROC value to late joiners of a session. However, in some scenarios a 1377 key management based ROC synchronization is not sufficient. For 1378 example, in mobile and wireless environments, members may go in and 1379 out of coverage and may miss a sequence number overrun. In point-to- 1380 multipoint translator scenarios it is desirable to not require the 1381 group controller to track the ROC values of each member, but to 1382 provide the ROC value by the originator of the SRTP packet. A better 1383 alternative to synchronize the ROC values is to send them directly 1384 via SRTP/SRTCP, as EKT does. A separate SRTP extension is being 1385 proposed [RFC4771] to include the ROC as part of a modified 1386 authentication tag. Unlike EKT, this extension uses only SRTP and 1387 not SRTCP as its transport and does not allow updating the SRTP 1388 master key. 1390 Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP 1391 streams. Each sender of a stream sends the associated SSRC within 1392 the MIKEY message to the other party. If a SRTP session participant 1393 starts a new SRTP source or a new participant is added to a group, 1394 subsequent SDP offer/answer and MIKEY exchanges are necessary to 1395 update the SSRC values. EKT improves these scenarios by updating the 1396 keys and SSRC values without coordination on the signaling channel. 1397 With EKT, SRTP can handle early media, since the EKT SPI allows the 1398 receiver to identify the cryptographic keys and parameters used by 1399 the source. 1401 The MIKEY specification [RFC3830] suggests the use of unicast for 1402 rekeying. This method does not scale well to large groups or 1403 interactive groups. The EKT extension of SRTP/SRTCP provides a 1404 solution for rekeying the SRTP master key and for ROC/SSRC 1405 synchronization. EKT is not a substitution for MIKEY, but rather a 1406 complementary addition to address the above described limitations of 1407 MIKEY. 1409 In the next section we provide an extension to MIKEY for support of 1410 EKT. EKT can be used only with the pre-shared key or public-key 1411 encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode 1412 is not suitable in conjunction with EKT, because it is not possible 1413 to establish one common EKT key over multiple EKT entities. 1414 Additional MIKEY modes specified in separate documents are not 1415 considered for EKT. 1417 5.1. EKT extensions to MIKEY 1419 In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI 1420 must be negotiated in the MIKEY message exchange. 1422 For EKT we specify a new SRTP Policy Type in the Security Policy (SP) 1423 payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload 1424 contains a set of policies. Each policy consists of a number Policy 1425 Param TLVs. 1427 Prot type | Value 1428 ------------------- 1429 EKT | TBD (will be requested from IANA) 1431 For legibility the SDP shows line breaks that are not present on the 1432 wire. 1434 Figure 8: EKT Security Policy 1436 The EKT Security Policy has one parameter representing the EKT 1437 cipher. 1439 Type | Meaning | Possible values 1440 ---------------------------------------------------- 1441 0 | EKT cipher | see below 1443 Figure 9: EKT Security Policy Parameters 1445 EKT cipher | Value 1446 ------------------- 1447 AES_128 | 0 1448 AESKW_128 | 1 1449 AESKW_192 | 2 1450 AESKW_256 | 3 1452 Figure 10: EKT Cipher Parameters 1454 AES_128 is the default value for the EKT cipher. 1456 The two mandatory EKT parameters (EKT_Key and EKT_SPI) are 1457 transported in the MIKEY KEMAC payload within one separate Key Data 1458 sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC 1459 payload carries the TEK Generation Key (TGK) or the Traffic 1460 Encryption Key (TEK). One or more TGKs or TEKs are carried in 1461 individual Key Data sub-payloads within the KEMAC payload. The KEMAC 1462 payload is encrypted as part of MIKEY. The Key Data sub- payload, 1463 specified in Section 6.13 of [RFC3830], has the following format: 1465 1 2 3 1466 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 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Next Payload | Type | KV | Key data length | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 : Key data : 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 : Salt length (optional) ! Salt data (optional) : 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 : KV data (optional) : 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 Figure 11: Key Data Sub-Payload of MIKEY 1479 These fields are described below: 1481 Type: 4 bits in length, indicates the type of key included in the 1482 payload. We define Type = TBD (will be requested from IANA) to 1483 indicate transport of the EKT key. 1485 KV: (4 bits): indicates the type of key validity period specified. 1486 KV=1 is currently specified as an SPI. We use that value to 1487 indicate the KV_data contains the ETK_SPI for the key type 1488 EKT_Key. KV_data would be 16 bits in length, but it is also 1489 possible to interpret the length from the 'Key data len' field. 1490 KV data MUST NOT be optional for the key type EKT_Key when KV = 1. 1492 Salt length, Salt Data: These optional fields SHOULD be omitted for 1493 the key type EKT_Key, if the SRTP master salt is already present 1494 in the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload 1495 MUST contain a SRTP master salt, if the SRTP master salt is not 1496 already present in the TGK or TEK Key Data sub-payload. 1498 KV Data: length determined by Key Data Length field. 1500 5.2. Offer/Answer considerations 1502 This section describes Offer/Answer considerations for the use of EKT 1503 together with MIKEY for unicast streams. The offerer and answerer 1504 MUST follow the procedures specified in [RFC3830] and [RFC4567] as 1505 well as the following ones. 1507 5.2.1. Generating the Initial Offer 1509 If it is intended to use MIKEY together with EKT, the offerer MUST 1510 include at least one MIKEY key-mgmt attribute with one EKT_Key Key 1511 Data sub-payload and the EKT_Cipher Security Policy payload. MIKEY 1512 can be used on session or media level. On session level, MIKEY 1513 provides the keys for multiple SRTP sessions in the SDP offer. The 1514 EKT SPI references a EKT parameter set including the Secure RTP 1515 parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is 1516 used on session level, it is only possible to use one EKT SPI value. 1517 Therefore, the session-level MIKEY message MUST contain one SRTP 1518 Security Policy payload only, which is valid for all related SRTP 1519 media lines. If MIKEY is used on media level, different SRTP 1520 Security Policy parameters (and consequently different EKT SPI 1521 values) can be used for each media line. If MIKEY is used on session 1522 and media level, the medial level content overrides the session level 1523 content. 1525 EKT requires a single shared SRTP master salt between all 1526 participants in the direct SRTP session. If a MIKEY key-mgmt 1527 attribute contains more than one TGK or TEK Key Data sub-payload, all 1528 the sub-payloads MUST contain the same master salt value. 1529 Consequently, the EKT_Key Key Data sub-payload MAY also contain the 1530 same salt or MAY omit the salt value. If the SRTP master salt is not 1531 present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub- 1532 payload MUST contain a master salt. 1534 5.2.2. Generating the Initial Answer 1536 For each media line in the offer using MIKEY, provided on session or/ 1537 and on media level, the answerer examines the related MIKEY key-mgmt 1538 attributes for the presence of EKT parameters. In order to accept 1539 the offered key-mgmt attribute, the MIKEY message MUST contain one 1540 EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy 1541 payload. The answerer examines also the existence of a SRTP master 1542 salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple 1543 salts are available, all values MUST be equal. If the salt values 1544 differ or no salt is present, the key-mgmt attribute MUST be 1545 considered as invalid. 1547 The MIKEY responder message in the SDP answer does not contain a 1548 MIKEY KEMAC or Security Policy payload and consequently does not 1549 contain any EKT parameters. If the key-mgmt attribute for a media 1550 line was accepted by the answerer, the EKT parameter set of the 1551 offerer is valid for both directions of the SRTP session. 1553 5.2.3. Processing the Initial Answer 1555 On reception of the answer, the offerer examines if EKT has been 1556 accepted for the offered media lines. If a MIKEY key-mgmt attribute 1557 is received containing a valid MIKEY responder message, EKT has been 1558 successfully negotiated. On receipt of a MIKEY error message, EKT 1559 negotiation has failed. For example, this may happen if an EKT 1560 extended MIKEY initiator message is sent to a MIKEY entity not 1561 supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is 1562 returned to indicate that the EKT_Cipher Security Policy payload or 1563 the EKT_Key sub-payload is not supported. In this case, the offerer 1564 may send a second SDP offer with a MIKEY key-mgmt attribute without 1565 the additional EKT extensions. 1567 This behavior can be improved by defining an additional key-mgmt 1568 prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. 1569 One attribute offers MIKEY together with EKT and the other one offers 1570 MIKEY without EKT. This is for further discussion. 1572 5.2.4. Modifying the Session 1574 Once a SRTP stream has been established, a new offer/answer exchange 1575 can modify the session including the EKT parameters. If the EKT key 1576 or EKT cipher is modified (i.e., a new EKT parameter set is created) 1577 the offerer MUST also provide a new EKT SPI value. The offerer MUST 1578 NOT remap an existing EKT SPI value to a new EKT parameter set. 1579 Similar, a modification of the SRTP Security Policy leads to a new 1580 EKT parameter set and requires a fresh EKT SPI, even the EKT key or 1581 cipher did not change. 1583 Once EKT is being used, the SRTP master salt for the SRTP session 1584 MUST NOT be changed. The salt in the Key Data sub-payloads within 1585 the subsequent offers MUST be the same as the one already used. 1587 After EKT has been successfully negotiated for a session and a SRTP 1588 master key has been transported by EKT, it is difficult to switch 1589 back to a pure MIKEY based key exchange in a synchronized way. 1590 Therefore, once EKT is being used for a session, EKT MUST be used 1591 also in all subsequent offer/answer exchanges for that session. 1593 6. Using EKT for interoperability between key management systems 1595 A media gateway (MGW) can provide interoperability between an SRTP- 1596 EKT endpoint and a non-EKT SRTP endpoint. When doing this function, 1597 the MGW can perform non-cryptographic transformations on SRTP packets 1598 outlined above. However, there are some uses of cryptography that 1599 will be required for that gateway. If a new SRTP master key is 1600 communicated to the MGW (via EKT from the EKT leg, or via Security 1601 Descriptions from the Security Descriptions leg), the MGW needs to 1602 convert that information for the other leg, and that process will 1603 incur some cryptographic operations. Specifically, if the new key 1604 arrived via EKT, that must be decrypted and then sent in Security 1605 Descriptions; likewise, if a new key arrives via Security 1606 Descriptions that must be encrypted via EKT and sent in SRTP/SRTCP. 1608 Additional non-normative information can be found in Appendix A. 1610 7. Design Rationale 1612 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1613 "persistent transport-level identifier for an RTP source" since 1614 "receivers require the CNAME to keep track of each participant." EKT 1615 works in much the same way, using SRTCP to carry information needed 1616 for the proper processing of the SRTP traffic. 1618 With EKT, SRTP gains the ability to synchronize the creation of 1619 cryptographic contexts across all of the participants in a single 1620 session. This feature provides some, but not all, of the 1621 functionality that is present in IKE phase two (but not phase one). 1622 Importantly, EKT does not provide a way to indicate SRTP options. 1624 With EKT, external signaling mechanisms provide the SRTP options and 1625 the EKT Key, but need not provide the key(s) for each individual SRTP 1626 source. EKT provides a separation between the signaling mechanisms 1627 and the details of SRTP. The signaling system need not coordinate 1628 all SRTP streams, nor predict in advance how many streams will be 1629 present, nor communicate SRTP-level information (e.g., rollover 1630 counters) of current sessions. 1632 EKT is especially useful for multi-party sessions, and for the case 1633 where multiple RTP sessions are sent to the same destination 1634 transport address (see the example in the definition of "RTP session" 1635 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1636 multiple endpoints at the same time) can cause multiple RTP sessions 1637 to be sent to the same transport address, making EKT useful for use 1638 with SIP. 1640 EKT can also be used in conjunction with a scalable group-key 1641 management system like GDOI [RFC3547]. Such a system provides a 1642 secure entity authentication method and a way to revoke group 1643 membership, both of which are out of scope of EKT. 1645 It is natural to use SRTCP to transport encrypted keying material for 1646 SRTP, as it provides a secure control channel for (S)RTP. However, 1647 there are several different places in SRTCP in which the encrypted 1648 SRTP master key and ROC could be conveyed. We briefly review some of 1649 the alternatives in order to motivate the particular choice used in 1650 this specification. One alternative is to have those values carried 1651 as a new SDESC item or RTCP packet. This would require that the 1652 normal SRTCP encryption be turned off for the packets containing that 1653 SDESC item, since on the receiver's side, SRTCP processing completes 1654 before the RTCP processing starts. This tension between encryption 1655 and the desire for RTCP privacy is highly undesirable. Additionally, 1656 this alternative makes SRTCP dependent upon the parsing of the RTCP 1657 compound packet, which adds complexity. It is simpler to carry the 1658 encrypted key in a new SRTCP field. One way to do this and to be 1659 backwards compatible with the existing specification is to define a 1660 new crypto function that incorporates the encrypted key. We define a 1661 new authentication transform because EKT relies on the normal SRTCP 1662 authentication to provide implicit authentication of the encrypted 1663 key. 1665 An SRTP packet containing an SSRC that has not been seen will be 1666 discarded. This practice may induce a burst of packet loss at the 1667 outset of an SRTP stream, due to the loss or reorder of the first 1668 SRTCP packet with the EKT containing the key and rollover counter for 1669 that stream. However, this practice matches the conservative RTP 1670 memory-allocation strategy; many existing applications accept this 1671 risk of initial packet loss. Alternatively, implementations may wish 1672 to delay discarding such packets for a short period of time as 1673 described in Section 2.4. 1675 The main motivation for the use of the variable-length format is 1676 bandwidth conservation. If EKT is used of SRTP, there will be a loss 1677 of bandwidth due to the additional 24 bytes in each RTP packet. For 1678 some applications, this bandwidth loss is significant. 1680 7.1. Alternatives 1682 In its current design, EKT requires that the Master Salt be 1683 established out of band. That requirement is undesirable. In an 1684 offer/answer environment, it forces the answerer to re-use the same 1685 Master Salt value used by the offerer. The Master Salt value could 1686 be carried in EKT packets though that would consume yet more 1687 bandwidth. 1689 In some scenarios, two SRTP sessions may be combined into a single 1690 session. When using EKT in such sessions, it is desirable to have an 1691 SPI value that is larger than 15 bits, so that collisions between SPI 1692 values in use in the two different sessions are unlikely (since each 1693 collision would confuse the members of one of the sessions.) 1695 An alternative that addresses both of these needs is as follows: the 1696 SPI value can be lengthed from 15 bits to 63 bits, and the Master 1697 Salt can be identical to, or constructed from, the SPI value. SRTP 1698 conventionally uses a 14-byte Master Salt, but shorter values are 1699 acceptable. This alternative would add six bytes to each EKT packet; 1700 that overhead may be a reasonable tradeoff for addressing the 1701 problems outlined above. 1703 8. Security Considerations 1705 With EKT, each SRTP sender and receiver can generate distinct SRTP 1706 master keys. This property avoids any security concern over the re- 1707 use of keys, by empowering the SRTP layer to create keys on demand. 1708 Note that the inputs of EKT are the same as for SRTP with key- 1709 sharing: a single key is provided to protect an entire SRTP session. 1710 However, EKT provides complete security, even in the absence of 1711 further out-of-band coordination of SSRCs, and even when SSRC values 1712 collide. 1714 In order to avoid potential security issues, the SRTP authentication 1715 tag length used by the base authentication method MUST be at least 1716 ten octets. 1718 The presence of the SSRC in the EKT_Plaintext ensures that an 1719 attacker cannot substitute an EKT_Ciphertext from one SRTP stream 1720 into another SRTP stream, even if those two streams are using the 1721 same SRTP master key. This is important because some applications 1722 may use the same master key for multiple streams. 1724 An attacker who strips a Full_EKT_Field from an SRTP packet may 1725 prevent the intended receiver of that packet from being able to 1726 decrypt it. This is a minor denail of service vulnerability. 1727 Similarly, an attacker who adds a Full_EKT_Field can disrupt service. 1729 An attacker could send packets containing either Short EKT Tag or 1730 Full EKT Tag, in an attempt to consume additional CPU resources of 1731 the receiving system. In the case of the Short EKT Tag, this field 1732 is stripped and normal SRTP or SRTCP processing is performed. In the 1733 case of the Full EKT Tag, the attacker would have to have guessed or 1734 otherwise determined the SPI being used by the receiving system. If 1735 an invalid SPI is provided by the attacker, processing stops. If a 1736 valid SPI is provided by the attacker, the receiving system will 1737 decrypt the EKT ciphertext and return an authentication failure (Step 1738 3 of Section 2.2.2). 1740 An attacker learns from EKT when SRTP Master Keys change. 1742 The EKT Cipher MUST be at least as strong as the encryption and 1743 authentication operations used in SRTP. 1745 Part of the EKT_Plaintext is known, or easily guessable to an 1746 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 1747 In practice, this requirement does not impose any restrictions on our 1748 choices, since the ciphers in use provide high security even when 1749 much plaintext is known. 1751 An EKT cipher MUST resist attacks in which both ciphertexts and 1752 plaintexts can be adaptively chosen. For each randomly chosen key, 1753 the encryption and decryption functions cannot be distinguished from 1754 a random permutation and its inverse with non-negligible advantage. 1755 This must be true even for adversaries that can query both the 1756 encryption and decryption functions adaptively. The advantage is 1757 defined as the difference between the probability that the adversary 1758 will identify the cipher as such and the probability that the 1759 adversary will identify the random permutation as the cipher, when 1760 each case is equally likely. 1762 9. IANA Considerations 1764 IANA is requested to register EKT into the SRTP Session Parameter 1765 registry [iana-sdp-sdesc]. 1767 IANA is requested to register dtls-srtp-ekt and dtls-srtp-host into 1768 the att-field table of the SDP Attributes registry [iana-sdp-attr]. 1770 We request the following IANA assignments from existing MIKEY IANA 1771 tables: 1773 o From the Key Data payload name spaces, a value to indicate the 1774 type as the 'EKT_Key'. 1776 o From the Security Policy table name space, a new value to be 1777 assigned for 'EKT' (see Figure 8). 1779 Furthermore, we need the following two new IANA registries created, 1780 populated with the initial values in this document. New values for 1781 both of these registries can be defined via Specification Required 1782 [RFC5226]. 1784 o EKT parameter type (initially populated with the list from 1785 Figure 9) 1787 o EKT cipher (initially populated with the list from Figure 10) 1789 10. Acknowledgements 1791 Thanks to Lakshminath Dondeti for assistance with earlier versions of 1792 this document. Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond 1793 for fruitful discussions and comments. Thanks to Romain Biehlmann 1794 for his encouragement to add support DTLS-SRTP-EKT key servers for 1795 multicast. Thanks to Felix Wyss for his review and comments 1796 regarding ciphers. 1798 11. References 1800 11.1. Normative References 1802 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1803 Information Processing Standard. 1805 [I-D.ietf-tls-rfc4347-bis] 1806 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1807 Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work 1808 in progress), July 2011. 1810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1811 Requirement Levels", BCP 14, RFC 2119, March 1997. 1813 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1814 A., Peterson, J., Sparks, R., Handley, M., and E. 1815 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1816 June 2002. 1818 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1819 with Session Description Protocol (SDP)", RFC 3264, 1820 June 2002. 1822 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1823 Jacobson, "RTP: A Transport Protocol for Real-Time 1824 Applications", STD 64, RFC 3550, July 2003. 1826 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1827 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1828 RFC 3711, March 2004. 1830 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1831 Information Type for the General Extension Payload in 1832 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1834 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1835 Description Protocol", RFC 4566, July 2006. 1837 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1838 Carrara, "Key Management Extensions for Session 1839 Description Protocol (SDP) and Real Time Streaming 1840 Protocol (RTSP)", RFC 4567, July 2006. 1842 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1843 Description Protocol (SDP) Security Descriptions for Media 1844 Streams", RFC 4568, July 2006. 1846 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1847 Encodings", RFC 4648, October 2006. 1849 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1850 Transform Carrying Roll-Over Counter for the Secure Real- 1851 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1853 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1854 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1855 May 2008. 1857 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1858 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1860 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1861 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1862 September 2009. 1864 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1865 Security (DTLS) Extension to Establish Keys for the Secure 1866 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1868 11.2. Informative References 1870 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1871 Group Domain of Interpretation", RFC 3547, July 2003. 1873 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1874 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1875 August 2004. 1877 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1878 Internet Protocol", RFC 4301, December 2005. 1880 [iana-sdp-attr] 1881 IANA, "SDP Parameters", 2011, . 1884 [iana-sdp-sdesc] 1885 IANA, "SDP Security Descriptions", 2011, . 1889 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security 1890 Descriptions 1892 Today, SDP Security Descriptions [RFC4568] is used for distributing 1893 SRTP keys in several different IP PBX systems and is expected to be 1894 used by 3GPP's Long Term Evolution (LTE). The IP PBX systems are 1895 typically used within a single enterprise, and LTE is used within the 1896 confines of a mobile operator's network. A Session Border Controller 1897 is a reasonable solution to interwork between Security Descriptions 1898 in one network and DTLS-SRTP in another network. For example, a 1899 mobile operator (or an Enterprise) could operate Security 1900 Descriptions within their network and DTLS-SRTP towards the Internet. 1902 However, due to the way Security Descriptions and DTLS-SRTP manage 1903 their SRTP keys, such an SBC has to authenticate, decrypt, re- 1904 encrypt, and re-authenticate the SRTP (and SRTCP) packets in one 1905 direction, as shown in Figure 12, below. This is computationally 1906 expensive. 1908 RFC4568 endpoint SBC DTLS-SRTP endpoint 1909 | | | 1910 1. |---key=A------------->| | 1911 2. | |<-DTLS-SRTP handshake->| 1912 3. |<--key=B--------------| | 1913 4. | |<--SRTP, encrypted w/B-| 1914 5. |<-SRTP, encrypted w/B-| | 1915 6. |-SRTP, encrypted w/A->| | 1916 7. | (decrypt, re-encrypt) | 1917 8. | |-SRTP, encrypted w/C-->| 1918 | | | 1920 Figure 12: Interworking Security Descriptions and DTLS-SRTP 1922 The message flow is as follows (similar steps occur with SRTCP): 1924 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 1925 key to the SBC, using a=crypto in its SDP. 1927 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1928 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1929 B) and to the DTLS-SRTP endpoint (key C). 1931 3. The SBC communicates the SRTP encryption key (key B) to the 1932 Security Descriptions endpoint (using a=crypto). (There is no 1933 way, with DTLS-SRTP, to communicate the Security Descriptions key 1934 to the DTLS-SRTP key endpoint.) 1936 4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1937 B. This is received by the SBC. 1939 5. The received SRTP packet is simply forwarded; the SBC does not 1940 need to do anything with this packet as its key (key B) was 1941 already communicated in step 3. 1943 6. The Security Descriptions endpoint sends an SRTP packet, 1944 encrypted with its key A. 1946 7. The SBC has to authenticate and decrypt the SRTP packet (using 1947 key A), and re-encrypt it and generate an HMAC (using key C). 1949 8. The SBC sends the new SRTP packet. 1951 If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the 1952 computationally expensive operation so the SBC does not need not 1953 perform any per-packet operations on the SRTP (or SRTCP) packets in 1954 either direction. With EKT the SBC can simply forward the SRTP (and 1955 SRTCP) packets in both directions without per-packet HMAC or 1956 cryptographic operations. 1958 To accomplish this interworking, DTLS-SRTP EKT must be supported on 1959 the DTLS-SRTP endpoint, which allows the SBC to transport the 1960 Security Description key to the EKT endpoint and send the DTLS-SRTP 1961 key to the Security Descriptions endpoint. This works equally well 1962 for both incoming and outgoing calls. An abbreviated message flow is 1963 shown in Figure 13, below. 1965 RFC4568 endpoint SBC DTLS-SRTP endpoint 1966 | | | 1967 1. |---key=A------------->| | 1968 2. | |<-DTLS-SRTP handshake->| 1969 3. |<--key=B--------------| | 1970 4. | |--new_srtp_key:A------>| 1971 5. | |<--SRTP, encrypted w/B-| 1972 5. |<-SRTP, encrypted w/B-| | 1973 6. |-SRTP, encrypted w/A->| | 1974 7. | |-SRTP, encrypted w/A-->| 1975 | | | 1977 Figure 13: Interworking Security Descriptions and EKT 1979 The message flow is as follows (similar steps occur with SRTCP): 1981 1. Security Descriptions endpoint discloses its SRTP key to the SBC 1982 (a=crypto). 1984 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1985 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1986 B) and to the DTLS-SRTP endpoint (key C). 1988 3. The SBC communicates the SRTP encryption key (key B) to the 1989 Security Descriptions endpoint. 1991 4. The SBC uses the EKT to indicate that SRTP packets will be 1992 encrypted with 'key A' towards the DTLS-SRTP endpoint. 1994 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1995 B. This is received by the SBC. 1997 6. The received SRTP packet is simply forwarded; the SBC does not 1998 need to do anything with this packet as its key (key B) was 1999 communicated in step 3. 2001 7. The Security Descriptions endpoint sends an SRTP packet, 2002 encrypted with its key A. 2004 8. The received SRTP packet is simply forwarded; the SBC does not 2005 need to do anything with this packet as its key (key A) was 2006 communicated in step 4. 2008 Authors' Addresses 2010 David A. McGrew 2011 Cisco Systems, Inc. 2012 510 McCarthy Blvd. 2013 Milpitas, CA 95035 2014 US 2016 Phone: (408) 525 8651 2017 Email: mcgrew@cisco.com 2018 URI: http://www.mindspring.com/~dmcgrew/dam.htm 2020 Flemming Andreason 2021 Cisco Systems, Inc. 2022 499 Thornall Street 2023 Edison, NJ 08837 2024 US 2026 Email: fandreas@cisco.com 2028 Dan Wing 2029 Cisco Systems, Inc. 2030 510 McCarthy Blvd. 2031 Milpitas, CA 95035 2032 US 2034 Phone: (408) 853 4197 2035 Email: dwing@cisco.com 2037 Kai Fischer 2038 Siemens Enterprise Communications GmbH & Co. KG 2039 Hofmannstr. 51 2040 Munich, Bavaria 81739 2041 Germany 2043 Email: kai.fischer@siemens-enterprise.com