idnits 2.17.1 draft-ietf-avt-srtp-ekt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Initial Sequence Number field is set to zero, if the initial RTP packet protected using the current SRTP master key for this source preceded, or was concurrent with, the last roll-over of the RTP sequence number. Otherwise, that field is set to the value of the RTP sequence number of the initial RTP packet that was or will be protected by that key. When the SRTP master key corresponding to a source is changed, the new key SHOULD be communicated in advance via EKT. (Note that the ISN field allows the receiver to know when it should start using the new key to process SRTP packets.) This enables the rekeying event to be communicated before any RTP packets are protected with the new key. The rekeying event MUST not change the value of ROC (otherwise, the current value of the ROC would not be known to late joiners of existing sessions). -- The document date (July 12, 2010) is 5037 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: 'SRTP' is mentioned on line 680, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1268, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-03 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 13, 2011 Cisco Systems, Inc. 6 K. Fischer 7 Siemens Enterprise Networks GmbH 8 & Co KG 9 July 12, 2010 11 Encrypted Key Transport for Secure RTP 12 draft-ietf-avt-srtp-ekt-01 14 Abstract 16 SRTP Encrypted Key Transport (EKT) is an extension to SRTP that 17 provides for the secure transport of SRTP master keys, Rollover 18 Counters, and other information, within SRTP or SRTCP. This facility 19 enables SRTP to work for decentralized conferences with minimal 20 control, and to handle situations caused by early media. 22 This note defines EKT, and also describes how to use it with SDP 23 Security Descriptions, DTLS-SRTP Key Transport (KTR), and MIKEY. 24 These other key management protocols provide an EKT key to everyone 25 in a session, and EKT coordinates the keys within the session. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on January 13, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Conventions Used In This Document . . . . . . . . . . . . 5 69 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 70 2.1. Authentication Tag Format . . . . . . . . . . . . . . . . 7 71 2.2. Packet Processing and State Machine . . . . . . . . . . . 8 72 2.2.1. Outbound (Tag Generation) . . . . . . . . . . . . . . 9 73 2.2.2. Inbound (Tag Verification) . . . . . . . . . . . . . . 10 74 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 14 76 2.3.2. The AES Key Wrap Cipher . . . . . . . . . . . . . . . 14 77 2.3.3. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 15 78 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 15 79 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 16 80 2.6. Timing and Reliability Consideration . . . . . . . . . . . 16 81 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 18 82 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 18 83 3.2. Relationship between EKT and SDP Security Descriptions . . 19 84 3.3. Overview of Combined EKT and SDP Security Description 85 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21 86 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 21 87 3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 21 88 3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 22 89 3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 22 90 3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 22 91 3.5.1. Generating the Initial Offer - Unicast Streams . . . . 23 92 3.5.2. Generating the Initial Answer - Unicast Streams . . . 24 93 3.5.3. Processing of the Initial Answer - Unicast Streams . . 25 94 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 26 95 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 26 96 3.8. Backwards Compatibility Considerations . . . . . . . . . . 27 97 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 29 99 4.1. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 29 100 4.1.1. Scaling to Large Groups . . . . . . . . . . . . . . . 31 101 4.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 32 102 4.2.1. Generating the Initial Offer . . . . . . . . . . . . . 32 103 4.2.2. Generating the Initial Answer . . . . . . . . . . . . 33 104 4.2.3. Processing the Initial Answer . . . . . . . . . . . . 33 105 4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 33 106 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 35 107 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 36 108 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 38 109 5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 38 110 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 39 111 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 39 112 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 39 113 6. Interworking with Other SRTP Key Management Systems . . . . . 41 114 6.1. Security Descriptions . . . . . . . . . . . . . . . . . . 41 115 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 44 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 49 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 50 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 124 1. Introduction 126 RTP is designed to allow decentralized groups with minimal control to 127 establish sessions, e.g. for multimedia conferences. Unfortunately, 128 Secure RTP (SRTP, [RFC3711]) cannot be used in many minimal-control 129 scenarios, because it requires that SSRC values and other data be 130 coordinated among all of the participants in a session. For example, 131 if a participant joins a session that is already in progress, the 132 SRTP rollover counter (ROC) of each SRTP source in the session needs 133 to be provided to that participant. 135 The inability of SRTP to work in the absence of central control was 136 well understood during the design of that protocol; that omission was 137 considered less important than optimizations such as bandwidth 138 conservation. Additionally, in many situations SRTP is used in 139 conjunction with a signaling system that can provide most of the 140 central control needed by SRTP. However, there are several cases in 141 which conventional signaling systems cannot easily provide all of the 142 coordination required. It is also desirable to eliminate the layer 143 violations that occur when signaling systems coordinate certain SRTP 144 parameters, such as SSRC values and ROCs. 146 This document defines Encrypted Key Transport (EKT) for SRTP, an 147 extension to SRTP that fits within the SRTP framework and reduces the 148 amount of signaling control that is needed in an SRTP session. EKT 149 securely distributes the SRTP master key and other information for 150 each SRTP source, using SRTCP or SRTP to transport that information. 151 With this method, SRTP entities are free to choose SSRC values as 152 they see fit, and to start up new SRTP sources with new SRTP master 153 keys (see Section 2.2) within a session without coordinating with 154 other entities via signaling or other external means. This fact 155 allows to reinstate the RTP collision detection and repair mechanism, 156 which is nullified by the current SRTP specification because of the 157 need to control SSRC values closely. An SRTP endpoint using EKT can 158 generate new keys whenever an existing SRTP master key has been 159 overused, or start up a new SRTP source to replace an old SRTP source 160 that has reached the packet-count limit. EKT also solves the problem 161 in which the burst loss of the N initial SRTP packets can confuse an 162 SRTP receiver, when the initial RTP sequence number is greater than 163 or equal to 2^16 - N. These features simplify many architectures that 164 implement SRTP. 166 EKT provides a way for an SRTP session participant, either sender or 167 receiver, to securely transport its SRTP master key and current SRTP 168 rollover counter to the other participants in the session. This 169 data, possibly in conjunction with additional data provided by an 170 external signaling protocol, furnishes the information needed by the 171 receiver to instantiate an SRTP/SRTCP receiver context. 173 EKT does not control the manner in which the SSRC and master key are 174 generated; it is concerned only with their secure transport. Those 175 values may be generated on demand by the SRTP endpoint, or may be 176 dictated by an external mechanism such as a signaling agent or a 177 secure group controller. 179 EKT is not intended to replace external key establishment mechanisms 180 such as DTLS-SRTP [RFC5764], SDP Security Descriptions [RFC4568], or 181 MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with 182 those methods, and it relieves them of the burden of tightly 183 coordinating every SRTP source among every SRTP participant. 185 This document is organized as follows. A complete normative 186 definition of EKT is provided in Section 2. It consists of packet 187 processing algorithms (Section 2.2) and cryptographic definitions 188 (Section 2.3) . In Section 3, the use of EKT with SDP Security 189 Descriptions is defined, and in Section 4 its use with DTLS-SRTP Key 190 Transport is defined. In Section 5 we outline the use of EKT with 191 MIKEY. Section 7 provides a design rationale. Security 192 Considerations are provided in Section 8, and IANA considerations are 193 provided in Section 9. 195 1.1. Conventions Used In This Document 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 2. Encrypted Key Transport 203 In EKT, an SRTP master key is encrypted with a Key Encrypting Key 204 (KEK), and the resulting ciphertext is transported in every SRTCP 205 packet, or in selected SRTP packets. A single KEK suffices for a 206 single SRTP session, regardless of the number of participants in the 207 session. However, there can be multiple KEKs used within a 208 particular session. We use terms "KEK" or "EKT key" to mean the same 209 thing; the latter term is used when describing the relation of EKT to 210 external key management. 212 In order to convey the ciphertext of the SRTP master key, and other 213 additional information, the Authentication Tag field is subdivided as 214 defined in Section 2.1. EKT defines new SRTP and SRTCP 215 authentication functions, which uses this format. It incorporates a 216 conventional authentication function, which is called the base 217 authentication function in this specification. Any authentication 218 function, such as the default one of HMAC-SHA1 with a 160-bit key and 219 an 80-bit authentication tag, can be used as a base authentication 220 function. EKT also defines a new method of providing SRTP master 221 keys to an endpoint. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 : Base Authentication Tag : 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 : Encrypted Master Key : 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Rollover Counter | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Initial Sequence Number | Security Parameter Index |1| 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 : Base Authentication Tag : 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Reserved |0| 241 +-+-+-+-+-+-+-+-+ 243 Figure 1: The EKT Authentication Tag format. 245 2.1. Authentication Tag Format 247 EKT uses the Authentication Tag format shown in Figure 1. The top 248 diagram shows the format in the case that the final bit is set to 249 one, in which case all of the EKT fields are present. The bottom 250 diagram shows the format in the case that the final bit is set to 251 zero, in which case the Encrypted Master Key, Rollover Counter, 252 Initial Sequence Number, and Security Parameter Index fields are 253 absent, and the Reserved field is present; the latter field MUST be 254 set to the all-zero value. These two cases can always be 255 unambiguously distinguished by the final bit, or by checking to see 256 if the final byte in the packet has the all-zero value. 258 The Authentication Tag field contains the following sub-fields: 260 Base Authentication Tag This field contains the authentication tag 261 computed by the base authentication function. The value of this 262 field is used to check the authenticity of the packet. 264 Encrypted Master Key The length of this field is variable, and is 265 equal to the ciphertext size N defined in Section 2.3. Note that 266 the length of the field is inferable from the SPI field, since the 267 particular EKT cipher used by the sender of a packet is inferable 268 from that field. The Encrypted Master Key field is included 269 outside of the authenticated portion of the SRTCP packet, 270 immediately following the Authentication Tag. It contains the 271 ciphertext value resulting from the encryption of the SRTP master 272 key corresponding to the SSRC contained in the packet. The 273 encryption and decryption of this value is done using a cipher as 274 defined in Section 2.3. 276 Rollover Counter The length of this field is fixed at 32 bits. This 277 field is set to the current value of the SRTP rollover counter in 278 the SRTP context associated with the SSRC in the SRTCP packet. 279 This field immediately follows the Encrypted Master Key field. 281 Initial Sequence Number (ISN) The length of this field is fixed at 282 16 bits. If this field is nonzero, then it indicates the RTP 283 sequence number of the initial RTP packet that is protected using 284 the SRTP master key conveyed (in encrypted form) by the Encrypted 285 Master Key field of this packet. If this field is zero, it 286 indicates that the initial RTP packet protected using the SRTP 287 master key conveyed in this packet preceded, or was concurrent 288 with, the last roll-over of the RTP sequence number. The ISN 289 field follows the Rollover Counter field. 291 Security Parameter Index (SPI) The length of this field is fixed at 292 16 bits. This field indicates the appropriate Key Encrypting Key 293 and other parameters for the receiver to use when processing the 294 packet. It is an "index" into a table of possibilities (which are 295 established via signaling or some other out-of-band means), much 296 like the IPsec Security Parameter Index [RFC4301]. The parameters 297 that are identified by this field are: 299 The Key Encrypting Key used to process the packet. 301 The EKT cipher used to process the packet. 303 The Secure RTP parameters associated with the SRTP Master Key 304 carried by the packet and the SSRC value in the packet. 305 Section 8.2. of [RFC3711] summarizes the parameters defined by 306 that specification. 308 The Master Salt associated with the Master Key. (This value is 309 part of the parameters mentioned above, but we call it out for 310 emphasis.) The Master Salt is communicated separately, via 311 signaling, typically along with the EKT Key Encrypting Key. 313 Together, these elements are called an EKT parameter set. Within 314 each SRTP session, each distinct EKT parameter set that may be 315 used MUST be associated with a distinct SPI value, to avoid 316 ambiguity. The SPI field follows the Initial Sequence Number. 317 Since it appears at the end of the packet, and has a fixed length, 318 it is always possible to unambiguously parse this field. 320 The final bit of the EKT Authentication Tag format is a flag that 321 indicates the presence or absence of the Encrypted Master Key, 322 Rollover Counter, Initial Sequence Number, and Security Parameter 323 Index fields, as shown in Figure 1. 325 2.2. Packet Processing and State Machine 327 At any given time, each SRTP/SRTCP source has associated with it a 328 single EKT parameter set. This parameter set is used to process all 329 outbound packets, and is called the outbound parameter set. There 330 may be other EKT parameter sets that are used by other SRTP/SRTCP 331 sources in the same session. All of these EKT parameter sets SHOULD 332 be stored by all of the participants in an SRTP session, for use in 333 processing inbound SRTCP traffic. 335 We next review SRTP authentication and show how the EKT 336 authentication method is built on top of a base authentication 337 method. An SRTP or SRTCP authentication method consists of a tag- 338 generation function and a verification function. The tag-generation 339 function takes as input a secret key, the data to be authenticated, 340 and the packet index. It provides an authentication tag as its sole 341 output, and is used in the processing of outbound packets. The 342 verification function takes as input a secret key, the data to be 343 authenticated, the packet index, and the authentication tag. It 344 returns an indication of whether or not the data, index, and tag are 345 valid or not. It is used in the processing of inbound packets. EKT 346 defines a tag-generation function in terms of the base tag-generation 347 function, and defines a verification function in terms of the base 348 verification function. The tag-generation function is used to 349 process outbound packets, and the verification function is used to 350 process inbound packets. 352 2.2.1. Outbound (Tag Generation) 354 When an SRTP or SRTCP packet needs to be sent, the EKT tag generation 355 function works as follows. The Rollover Counter field in the packet 356 is set to the current value of the SRTP rollover counter (represented 357 as an unsigned integer in network byte order). 359 The Initial Sequence Number field is set to zero, if the initial RTP 360 packet protected using the current SRTP master key for this source 361 preceded, or was concurrent with, the last roll-over of the RTP 362 sequence number. Otherwise, that field is set to the value of the 363 RTP sequence number of the initial RTP packet that was or will be 364 protected by that key. When the SRTP master key corresponding to a 365 source is changed, the new key SHOULD be communicated in advance via 366 EKT. (Note that the ISN field allows the receiver to know when it 367 should start using the new key to process SRTP packets.) This 368 enables the rekeying event to be communicated before any RTP packets 369 are protected with the new key. The rekeying event MUST not change 370 the value of ROC (otherwise, the current value of the ROC would not 371 be known to late joiners of existing sessions). 373 The Security Parameter Index field is set to the value of the 374 Security Parameter Index that is associated with the outbound 375 parameter set. 377 The Encrypted Master Key field is set to the ciphertext created by 378 encrypting the SRTP master key with the EKT cipher, using the KEK as 379 the encryption key. The encryption process is detailed in 380 Section 2.3. Implementations MAY cache the value of this field to 381 avoid recomputing it for each packet that is sent. 383 2.2.1.1. Base Authentication Tag 385 The Base Authentication Tag field is computed using the base tag- 386 generation function as follows. It can only be computed after all of 387 the other fields have been set. The authenticated input consists of 388 the following elements, in order: 390 the SRTP or SRTCP authenticated portion, 392 a string of zero bits whose length exactly matches that of the 393 Base Authentication Tag field, 395 the Encrypted Master Key field, 397 the Rollover Counter field, 399 the Initial Sequence Number field, and 401 the Security Parameter Index field. 403 Implementation note: the string of zero bits is included in the 404 authenticated input in order to allow implementations to compute 405 the base authentication tag using a single pass of the base 406 authentication function. Implementations MAY write zeros into the 407 Base Authentication Tag field prior to computing that function, on 408 the sending side. 410 2.2.2. Inbound (Tag Verification) 412 The EKT verification function proceeds as follows (see Figure 2), or 413 uses an equivalent set of steps. Recall that the verification 414 function is a component of SRTP and SRTCP processing. When a packet 415 does not pass the verification step, the function indicates this fact 416 to the SRTCP packet processing function when it returns control to 417 that function. 419 1. The Security Parameter Index field is checked to determine which 420 EKT parameter set should be used when processing the packet. If 421 multiple parameter sets been defined for the SRTP session, then 422 the one that is associated with the Security Parameter Index 423 value that matches the Security Parameter Index field in the 424 packet is used. This parameter set is called the matching 425 parameter set below. If there is no matching SPI, then the 426 verification function MUST return an indication of authentication 427 failure, and the steps described below are not performed. 429 2. If there is already an SRTP crypto context associated with the 430 SSRC in the packet, and replay protection is in use, then the 431 receiver performs the replay check described in Section 3.3.2 of 432 [RFC3711]. If the EKT fields are conveyed in an RTCP packet, 433 then the packet index used in that check is formed from the 434 Rollover Counter and the Initial Sequence Number fields in that 435 packet. If the EKT fields are conveyed in an SRTP packet, then 436 the packet index used in that check is formed from the EKT 437 Rollover Counter field and the RTP Sequence Number in that 438 packet. 440 3. The Encrypted Master Key field is decrypted using the EKT 441 cipher's decryption function. That field is used as the 442 ciphertext input, and the Key Encrypting Key in the matching 443 parameter set is used as the decryption key. The decryption 444 process is detailed in Section 2.3. The plaintext resulting from 445 this decryption is provisionally accepted as the SRTP master key 446 corresponding to the SSRC in the packet. If an MKI is present in 447 the packet, then the provisional key corresponds to the 448 particular SSRC and MKI combination. A provisional key MUST be 449 used only to process one single packet. A provisional SRTP or 450 SRTCP authentication key is generated from the provisional master 451 key, and the SRTP master salt from the matching parameter set, 452 using the SRTP key derivation algorithm (see Section 4.3 of 453 [RFC3711]). 455 4. An authentication check is performed on the packet, using the 456 provisional SRTP or SRTCP authentication key. This key is 457 provided to the base authentication function (see Figure 2), 458 which is evaluated as described in Section 2.2.1.1. If the Base 459 Authentication Tag field matches the tag computed by the base 460 authentication function, then the packet passes the check. 462 Implementation note: a receiver MAY copy the Base 463 Authentication Tag field into temporary storage, then write 464 zeros into that field, prior to computing the base 465 authentication tag value. This step allows the base 466 authentication function to be computed in a single pass over 467 the data in the packet. 469 5. If the base authentication check using the provisional key fails, 470 then the provisional key MUST be discarded and it MUST NOT affect 471 any subsequent processing. The verification function MUST return 472 an indication of authentication failure, and the steps described 473 below are not performed. 475 6. Otherwise, if the base authentication check is passed, the 476 provisional key is also accepted as the SRTP master key 477 corresponding to the SRTP source that sent the packet. If an MKI 478 is present in the packet, then the master key corresponds to the 479 particular SSRC and MKI combination. If there is no SRTP crypto 480 context corresponding to the SSRC in the packet, then a new 481 crypto context is created. The rollover counter in the context 482 is set to the value of the Rollover Counter field. If the crypto 483 context is not new, then the rollover counter in the context MUST 484 NOT be set to a value lower than its current value. (If the 485 replay protection step described above is performed, it ensures 486 that this requirement is satisfied.) 488 7. If the Initial Sequence Number field is nonzero, then the initial 489 sequence number for the SRTP master key is set to the packet 490 index created by appending that field to the current rollover 491 counter and treating the result as a 48-bit unsigned integer. 492 The initial sequence number for the master key is equivalent to 493 the "From" value of the < From, To > pair of indices (Section 494 8.1.1 of [RFC3711]) that can be associated with a master key. 496 8. The newly accepted SRTP master key, the SRTP parameters from the 497 matching parameter set, the SSRC from the packet, and the MKI 498 from the packet, if one is present, are stored in the crypto 499 context associated with the SRTP source. The SRTP Key Derivation 500 algorithm is run in order to compute the SRTP encryption and 501 authentication keys, and those keys are stored for use in SRTP 502 processing of inbound packets. The Key Derivation algorithm 503 takes as input the newly accepted SRTP master key, along with the 504 Master Salt from the matching parameter set. 506 Implementation note: the receiver may want to retain old 507 master keys for some brief period of time, so that out-of- 508 order packets can be processed. 510 9. The verification function then returns an indication that the 511 packet passed the verification. 513 Implementation note: the value of the Encrypted Master Key 514 field is identical in successive packets protected by the same 515 KEK and SRTP master key. This value MAY be cached by an SRTP 516 receiver to minimize computational effort, by allowing it to 517 recognize when the SRTP master key is unchanged, and thus 518 avoid repeating Steps 2, 6, and 7. 520 +------- Encrypted Master Key 521 | 522 v 523 +------------+ 524 | Decryption | 525 | Function |<-------------------------- Key Encrypting Key 526 +------------+ 527 | +----------------+ EKT 528 +--------+-- provisional ---->| SRTCP |<-- master 529 | master key | Key Derivation | salt 530 | +----------------+ 531 | | 532 | provisional SRTCP authentication key 533 | | 534 | v 535 | +----------------+ 536 | authenticated portion --> | Base SRTCP | 537 | authentication tag -----> | Verification | 538 | +----------------+ 539 | | 540 | +----------------+ +---+ 541 | | return FAIL |<- FAIL -| ? | 542 | +----------------+ +---+ 543 | | 544 | +----------------+ | 545 +------->| set master key,|<- PASS ---+ 546 | ROC, and MKI | 547 +----------------+ 548 | 549 v 550 +----------------+ 551 | return PASS | 552 +----------------+ 554 Figure 2: EKT inbound processing. 556 2.3. Ciphers 558 EKT uses a cipher to encrypt the SRTP master keys. We first specify 559 the interface to the cipher, in order to abstract the interface away 560 from the details of that function. We then define the cipher that is 561 used in EKT by default. This cipher MUST be implemented, but another 562 cipher that conforms to this interface MAY be used, in which case its 563 use MUST be coordinated by external means (e.g. call signaling). 565 An EKT cipher consists of an encryption function and a decryption 566 function. The encryption function E(K, P) takes the following 567 inputs: 569 a secret key K with a length of L bytes, and 571 a plaintext value P with a length of M bytes. 573 The encryption function returns a ciphertext value C whose length is 574 N bytes, where N is at least M. The decryption function D(K, C) takes 575 the following inputs: 577 a secret key K with a length of L bytes, and 579 a ciphertext value C with a length of N bytes. 581 The decryption function returns a plaintext value P that is M bytes 582 long. These functions have the property that D(K, E(K, P)) = P for 583 all values of K and P. Each cipher also has a limit T on the number 584 of times that it can be used with any fixed key value. For each key, 585 the encryption function MUST NOT be invoked on more than T distinct 586 values of P, and the decryption function MUST NOT be invoked on more 587 than T distinct values of C. 589 An EKT cipher MUST resist attacks in which both ciphertexts and 590 plaintexts can be adaptively chosen. For each randomly chosen key, 591 the encryption and decryption functions cannot be distinguished from 592 a random permutation and its inverse with non-negligible advantage. 593 This must be true even for adversaries that can query both the 594 encryption and decryption functions adaptively. The advantage is 595 defined as the difference between the probability that the adversary 596 will identify the cipher as such and the probability that the 597 adversary will identify the random permutation as the cipher, when 598 each case is equally likely. 600 2.3.1. The Default Cipher 602 The default cipher is the Advanced Encryption Standard (AES) 603 [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its 604 parameters are fixed at L=16, M=16, and T=2^48. Note that M matches 605 the size of the SRTP master keys used by the default SRTP key 606 derivation function; if an SRTP cipher with a different SRTP master 607 key length is to be used with EKT, then another EKT cipher must be 608 used. ECB is the simplest mode of operation of a block cipher, in 609 which the block cipher is used in its raw form. 611 2.3.2. The AES Key Wrap Cipher 613 The AES Key Wrap [RFC3394] defines a cipher that can be used with 614 plaintexts larger than 16 bytes in length. It requires a plaintext 615 length M that is a multiple of eight bytes, and it returns a 616 ciphertext with a length of N = M + 8 bytes. It can be used with key 617 sizes of L = 16, 24, and 32. The key size determines the length of 618 the AES key used by the Key Wrap algorithm. With this cipher, 619 T=2^48. 621 2.3.3. Other EKT Ciphers 623 Other specification MAY extend this one by defining other EKT 624 ciphers. This section defines how those ciphers interact with this 625 specification. 627 An EKT cipher determines how the Encrypted Master Key field is 628 written, and how it is processed when it is read. This field is 629 opaque to the other aspects of EKT processing. EKT ciphers are free 630 to use this field in any way, but they SHOULD NOT use other EKT or 631 SRTP fields as an input. The values of the parameters L, M, N, and T 632 MUST be defined by each EKT cipher, and those values MUST be 633 inferable from the EKT parameter set. 635 2.4. Synchronizing Operation 637 A participant in a session MAY opt to use a particular EKT key to 638 protect outbound packets after it accepts that EKT key for protecting 639 inbound traffic. In this case, the fact that one participant has 640 changed to using a new EKT key for outbound traffic can trigger other 641 participants to switch to using the same key. 643 An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT 644 key has been changed. This will ensure that the set of participants 645 able to decrypt the traffic will be limited to those who know the 646 current EKT key. 648 EKT can be transported over SRTCP, but some of the information that 649 it conveys is used for SRTP processing; some elements of the EKT 650 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 651 packets can be lost and both SRTP and SRTCP packets may be delivered 652 out-of-order. This can lead to various race conditions, which we 653 review below. 655 When joining an SRTP session, SRTP packets may be received before any 656 EKT over SRTCP packets, which implies the crypto context has not been 657 established, unless other external signaling mechanism has done so. 658 Rather than automatically discarding such SRTP packets, the receiver 659 MAY want to provisionally place them in a jitter buffer and delay 660 discarding them until playout time. 662 When an SRTP source using EKT over SRTCP performs a rekeying 663 operation, there is a race between the actual rekeying signaled via 664 SRTCP and the SRTP packets secured by the new keying material. If 665 the SRTP packets are received first, they will fail authentication; 666 alternatively, if authentication is not being used, they will decrypt 667 to unintelligible random-looking plaintext. (Note, however, that 668 [RFC3711] says that SRTP "SHOULD NOT be used without message 669 authentication".) In order to address this problem, the rekeying 670 event can be sent before packets using the new SRTP master key are 671 sent (by use of the ISN field). Another solution involves using an 672 MKI at the expense of added overhead in each SRTP packet. 673 Alternatively, receivers MAY want to delay discarding packets from 674 known SSRCs that fail authentication in anticipation of receiving a 675 rekeying event via EKT (SRTCP) shortly. 677 The ROC signaled via EKT over SRTCP may be off by one when it is 678 received by the other party(ies) in the session. In order to deal 679 with this, receivers should simply follow the SRTP packet index 680 estimation procedures defined in [SRTP] Section 3.3.1. 682 2.5. Transport 684 EKT MUST be used over SRTCP, whenever RTCP is in use. EKT MAY be 685 used over SRTP. When EKT over SRTP is used in an SRTP session in 686 which SRTCP is available, then EKT MUST be used for both SRTP and 687 SRTCP. 689 The packet processing, state machine, and Authentication Tag format 690 for EKT over SRTP are nearly identical to that for EKT over SRTCP. 691 Differences are highlighted in Section 2.2.1 and Section 2.2.2. 693 2.6. Timing and Reliability Consideration 695 SRTCP communicates the master key and ROC for the SRTP session. 696 Thus, as explained above, if SRTP packets are received prior to the 697 corresponding SRTCP (EKT) packet, a race condition occurs. From an 698 EKT point of view, it is therefore desirable for an SRTP sender to 699 send an EKT packet as soon as possible, and in no case any later than 700 when the initial SRTP packet is sent. SRTCP however MUST obey the 701 timing rules associated with the profile under which it runs (e.g. 702 RTP/SAVP or RTP/SAVPF). Subject to that constraint, SRTP senders 703 using EKT over SRTCP SHOULD send an SRTCP packet as soon as possible 704 after joining a session. Note that there is no need for SRTP 705 receivers to do so. Also note, that per RFC 3550, Section 6.2, it is 706 permissible to send a compound RTCP packet immediately after joining 707 a unicast session (but not a multicast session). 709 SRTCP is not reliable and hence SRTCP packets may be lost. This is 710 obviously a problem for endpoints joining an SRTP session and 711 receiving SRTP traffic (as opposed to SRTCP), or for endpoints 712 receiving SRTP traffic following a rekeying event. To reduce the 713 impact of lost packets, SRTP senders using EKT over SRTCP SHOULD send 714 SRTCP packets as often as allowed by the profile under which they 715 operate. 717 3. Use of EKT with SDP Security Descriptions 719 The SDP Security Descriptions (SDES) [RFC4568] specification defines 720 a generic framework for negotiating security parameters for media 721 streams negotiated via the Session Description Protocol by use of a 722 new SDP "crypto" attribute and the Offer/Answer procedures defined in 723 [RFC3264]. In addition to the general framework, SDES also defines 724 how to use that framework specifically to negotiate security 725 parameters for Secure RTP. Below, we first provide a brief recap of 726 the crypto attribute when used for SRTP and we then explain how it is 727 complementary to EKT. In the rest of this Section, we provide 728 extensions to the crypto attribute and associated offer/answer 729 procedures to define its use with EKT. 731 3.1. SDP Security Descriptions Recap 733 The SRTP crypto attribute defined for SDP Security Descriptions 734 contains a tag followed by three types of parameters (refer to 735 [RFC4568] for details): 737 Crypto-suite. Identifies the encryption and authentication 738 transform 740 Key parameters. SRTP keying material and parameters. 742 Session parameters. Additional (optional) SRTP parameters such as 743 Key Derivation Rate, Forward Error Correction Order, use of 744 unencrypted SRTP, etc. 746 The crypto attributes in the example SDP in Figure 3 illustrate these 747 parameters. 749 v=0 750 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 751 s=SRTP Discussion 752 i=A discussion of Secure RTP 753 u=http://www.example.com/seminars/srtp.pdf 754 e=marge@example.com (Marge Simpson) 755 c=IN IP4 192.0.2.12 756 t=2873397496 2873404696 757 m=audio 49170 RTP/SAVP 0 758 a=crypto:1 AES_CM_128_HMAC_SHA1_80 759 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 760 FEC_ORDER=FEC_SRTP 761 a=crypto:2 F8_128_HMAC_SHA1_80 762 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 763 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 764 FEC_ORDER=FEC_SRTP 766 Figure 3: SDP Security Descriptions example. Line breaks are 767 included for formatting purposes only. 769 The first crypto attribute has the tag "1" and uses the crypto-suite 770 "AES_CM_128_HMAC_SHA1_80". The "inline" parameter provides the SRTP 771 master key and salt, the master key lifetime (number of packets), and 772 the (optional) Master Key Identifier (MKI) whose value is "1" and has 773 a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER 774 session parameter indicates the order of Forward Error Correction 775 used (FEC is applied before SRTP processing by the sender of the SRTP 776 media). 778 The second crypto attribute has the tag "2" and uses the crypto-suite 779 "F8_128_HMAC_SHA1_80". It includes two SRTP master keys and 780 associated salts. The first one is used with the MKI value 1, 781 whereas the second one is used with the MKI value 2. Finally, the 782 FEC_ORDER session parameter indicates the order of Forward Error 783 Correction used. 785 3.2. Relationship between EKT and SDP Security Descriptions 787 SDP Security Descriptions [RFC4568] define a generic framework for 788 negotiating security parameters for media streams negotiated via the 789 Session Description Protocol by use of the Offer/Answer procedures 790 defined in [RFC3264]. In addition to the general framework, SDP 791 Security Descriptions (SDES) also defines how to use it specifically 792 to negotiate security parameters for Secure RTP. 794 EKT and SDESC are complementary. SDP Security Descriptions can 795 negotiate several of the SRTP security parameters (e.g. cipher and 796 use of Master Key Identifier/MKI) as well as SRTP master keys. SDP 797 Security Descriptions however does not negotiate SSRCs and their 798 associated Rollover Counter (ROC). Instead, SDES relies on a so- 799 called "late binding", where a newly observed SSRC will have its 800 crypto context initialized to a ROC value of zero. Clearly, this 801 does not work for participants joining an SRTP session that has been 802 established for a while and hence has a non-zero ROC. It is 803 impossible to use SDES to join an SRTP session that is already in 804 progress. In this case, EKT on the endpoint running SDP Security can 805 provide the additional signaling necessary to communicate the ROC 806 (Section 6.4.1 of [RFC4568]). The use of EKT solves this problem by 807 communicating the ROC associated with the SSRC in the media plane. 809 SDP Security Descriptions negotiates different SRTP master keys in 810 the send and receive direction. The offer contains the master key 811 used by the offerer to send media, and the answer contains the master 812 key used by the answerer to send media. Consequently, if media is 813 received by the offerer prior to the answer being received, the 814 offerer does not know the master key being used. Use of SDP security 815 preconditions can solve this problem, however it requires an 816 additional round-trip as well as a more complicated state machine. 817 EKT solves this problem by simply sending the master key used in the 818 media plane thereby avoiding the need for security preconditions. 820 If multiple crypto-suites were offered, the offerer also will not 821 know which of the crypto-suites offered was selected until the answer 822 is received. EKT solves this problem by using a correlator, the 823 Security Parameter Index (SPI), which uniquely identifies each crypto 824 attribute in the offer. 826 One of the primary call signaling protocols using offer/answer is the 827 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 828 message to initiate a media session and typically includes an offer 829 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 830 which potentially can lead to multiple answers being received. SDP 831 Security Descriptions however does not properly support this 832 scenario, mainly because SDP and RTP/RTCP does not contain sufficient 833 information to allow for correlation of an incoming RTP/RTCP packet 834 with a particular answer SDP. Note that extensions providing this 835 correlation do exist, e.g. Interactive Connectivity Establishment 836 (ICE). SDP Security Descriptions addresses this point-to-multipoint 837 problem by moving each answer to a separate RTP transport address 838 thereby turning a point-to-multipoint scenario into multiple point- 839 to-point scenarios. There are however significant disadvantages to 840 doing so. As long as the crypto attribute in the answer does not 841 contain any declarative parameters that differ from those in the 842 offer, EKT solves this problem by use of the SPI correlator and 843 communication of the answerer's SRTP master key in EKT. 845 As can be seen from the above, the combination of EKT and SDES 846 provides a better solution to SRTP negotiation for offer/answer than 847 either of them alone. SDES negotiates the various SRTP crypto 848 parameters (which EKT does not), whereas EKT addresses the 849 shortcomings of SDES. 851 3.3. Overview of Combined EKT and SDP Security Description Operation 853 We define three session extension parameters to SDES to communicate 854 the EKT cipher, EKT key, and Security Parameter Index to the peer. 855 The original SDES parameters are used as defined in [RFC4568], 856 however the procedures associated with the SRTP master key differ 857 slightly, since both SDES and EKT communicate an SRTP master key. In 858 particular, the SRTP master key communicated via SDES is used only if 859 there is currently no crypto context established for the SSRC in 860 question. This will be the case when an entity has received only the 861 offer or answer, but has yet to receive a valid EKT message from the 862 peer. Once a valid EKT message is received for the SSRC, the crypto 863 context is initialized accordingly, and the SRTP master key will then 864 be derived from the EKT message. Subsequent offer/answer exchanges 865 do not change this: The most recent SRTP master key negotiated via 866 EKT will be used, or, if none is available for the SSRC in question, 867 the most recent SRTP master key negotiated via offer/answer will be 868 used. Note that with these rules, once a valid EKT message has been 869 received for a given SSRC, rekeying for that SSRC can only be done 870 via EKT. The associated SRTP crypto parameters however can be 871 changed via SDES. 873 3.4. EKT Extensions to SDP Security Descriptions 875 In order to use EKT and SDES in conjunction, we now define the 876 following new SDES session parameters, each of which MUST NOT appear 877 more than once in a given crypto attribute: 879 EKT_Cipher The EKT cipher used to encrypt the SRTP Master Key 881 EKT_Key The EKT key used to encrypt the SRTP Master Key 883 EKT_SPI The EKT Security Parameter Index 885 Below, we provide additional detail on each of these attributes. 887 3.4.1. EKT_Cipher 889 The (optional) EKT_Cipher parameter parameter defines the EKT cipher 890 used to encrypt the EKT key with in SRTCP packets. The default value 891 is "AES_128" in accordance with Section 2.3.1. For the AES Key Wrap 892 cipher (see Section 2.3.2, the values "AESKW_128", "AESKW_192", and 893 "AESKW_256" are defined for values of L=16, 24, and 32 respectively. 894 In the Offer/Answer model, the EKT_Cipher parameter is a negotiated 895 parameter. 897 3.4.2. EKT_Key 899 The (mandatory) EKT_Key parameter is the key K used to encrypt the 900 SRTP Master Key in SRTCP packets. The value is base64 encoded (see 901 [RFC3548], Section 3). When base64 decoding the key, padding 902 characters (i.e., one or two "=" at the end of the base64 encoded 903 data) are discarded (see [RFC3548] for details). Base64 encoding 904 assumes that the base64 encoding input is an integral number of 905 octets. If a given EKT cipher requires the use of a key with a 906 length that is not an integral number of octets, said cipher MUST 907 define a padding scheme that results in the base64 input being an 908 integral number of octets. For example, if the length defined was 909 250 bits, then 6 padding bits would be needed, which could be defined 910 to be the last 6 bits in a 256 bit input. In the Offer/Answer model, 911 the EKT_Key parameter is a negotiated parameter. 913 3.4.3. EKT_SPI 915 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 916 It is encoded as an ASCII string representing the hexadecimal value 917 of the Security Parameter Index. The SPI identifies the *offer* 918 crypto attribute (including the EKT Key and Cipher) being used for 919 the associated SRTP session. A crypto attribute corresponds to an 920 EKT Parameter Set and hence the SPI effectively identifies a 921 particular EKT parameter set. Note that the scope of the SPI is the 922 SRTP session, which may or may not be limited to the scope of the 923 associated SIP dialog. In particular, if one of the participants in 924 an SRTP session is an SRTP translator, the scope of the SRTP session 925 is not limited to the scope of a single SIP dialog. However, if all 926 of the participants in the session are endpoints or mixers, the scope 927 of the SRTP session will correspond to a single SIP dialog. In the 928 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 930 3.5. Offer/Answer Procedures 932 In this section, we provide the offer/answer procedures associated 933 with use of the three new SDES parameters defined in Section 934 Section 3.4. Since SDES is defined only for unicast streams, we 935 provide only offer/answer procedures for unicast streams here as 936 well. 938 3.5.1. Generating the Initial Offer - Unicast Streams 940 When the initial offer is generated, the offerer MUST follow the 941 steps defined in [RFC4568] Section 7.1.1 as well as the following 942 steps. 944 For each unicast media line using SDES and where use of EKT is 945 desired, the offerer MUST include one EKT_Key parameter and one 946 EKT_SPI parameter in at least one "crypto" attribute (see [RFC4568]). 947 The EKT_SPI parameter serves to identify the EKT parameter set used 948 for a particular SRTCP packet. Consequently, within a single media 949 line, a given EKT_SPI value MUST NOT be used with multiple crypto 950 attributes. Note that the EKT parameter set to use for the session 951 is not yet established at this point; each offered crypto attribute 952 contains a candidate EKT parameter set. Furthermore, if the media 953 line refers to an existing SRTP session, then any SPI values used for 954 EKT parameter sets in that session MUST NOT be remapped to any 955 different EKT parameter sets. When an offer describes an SRTP 956 session that is already in progress, the offer SHOULD use an EKT 957 parameter set (incl. EKT_SPI and EKT_KEY) that is already in use. 959 If an EKT_Cipher other than the default cipher is to be used, then 960 the EKT_Cipher parameter MUST be included as well. 962 If a given crypto attribute includes more than one set of SRTP key 963 parameters (SRTP master key, salt, lifetime, MKI), they MUST all use 964 the same salt. (EKT requires a single shared salt between all the 965 participants in the direct SRTP session). 967 Important Note: The scope of the offer/answer exchange is the SIP 968 dialog(s) established as a result of the INVITE, however the scope of 969 EKT is the direct SRTP session, i.e. all the participants that are 970 able to receive SRTP and SRTCP packets directly. If an SRTP session 971 spans multiple SIP dialogs, the EKT parameter sets MUST be 972 synchronized between all the SIP dialogs where SRTP and SRTCP packets 973 can be exchanged. In the case where the SIP entity operates as an 974 RTP mixer (and hence re-originates SRTP and SRTCP packets with its 975 own SSRC), this is not an issue, unless the mixer receives traffic 976 from the various participants on the same destination IP address and 977 port, in which case further coordination of SPI values and crypto 978 parameters may be needed between the SIP dialogs (note that SIP 979 forking with multiple early media senders is an example of this). 980 However if it operates as an RTP translator, synchronized negotiation 981 of the EKT parameter sets on *all* the involved SIP dialogs will be 982 needed. This is non-trivial in a variety of use cases, and hence use 983 of the combined SDES/EKT mechanism with RTP translators should be 984 considered very carefully. It should be noted, that use of SRTP with 985 RTP translators in general should be considered very carefully as 986 well. 988 The EKT session parameters can either be included as optional or 989 mandatory parameters, however within a given crypto attribute, they 990 MUST all be either optional or mandatory. 992 3.5.2. Generating the Initial Answer - Unicast Streams 994 When the initial answer is generated, the answerer MUST follow the 995 steps defined in [RFC4568] Section 7.1.2 as well as the following 996 steps. 998 For each unicast media line using SDES, the answerer examines the 999 associated crypto attribute(s) for the presence of EKT parameters. 1000 If mandatory EKT parameters are included with a "crypto" attribute, 1001 the answerer MUST support those parameters in order to accept that 1002 offered crypto attribute. If optional EKT parameters are included 1003 instead, the answerer MAY accept the offered crypto attribute without 1004 using EKT. However, doing so will prevent the offerer from 1005 processing any packets received before the answer. If neither 1006 optional nor mandatory EKT parameters are included with a crypto 1007 attribute, and that crypto attribute is accepted in the answer, EKT 1008 MUST NOT be used. If a given a crypto attribute includes a mixture 1009 of optional and mandatory EKT parameters, or an incomplete set of 1010 mandatory EKT parameters, that crypto attribute MUST be considered 1011 invalid. 1013 When EKT is used with SDES, the offerer and answerer MUST use the 1014 same SRTP master salt. Thus, the SRTP key parameter(s) in the answer 1015 crypto attribute MUST use the same master salt as the one accepted 1016 from the offer. 1018 When the answerer accepts the offered media line and EKT is being 1019 used, the crypto attribute included in the answer MUST include the 1020 same EKT parameter values as found in the accepted crypto attribute 1021 from the offer (however, if the default EKT cipher is being used, it 1022 may be omitted). Furthermore, the EKT parameters included MUST be 1023 mandatory (i.e. no "-" prefix). 1025 Acceptance of a crypto attribute with EKT parameters leads to 1026 establishment of the EKT parameter set for the corresponding SRTP 1027 session. Consequently, the answerer MUST send packets in accordance 1028 with that particular EKT parameter set only. If the answerer wants 1029 to enable the offerer to process SRTP packets received by the offerer 1030 before it receives the answer, the answerer MUST NOT include any 1031 declarative session parameters that either were not present in the 1032 offered crypto attribute, or were present but with a different value. 1033 Otherwise, the offerer's view of the EKT parameter set would differ 1034 from the answerer's until the answer is received. Similarly, unless 1035 the offerer and answerer has other means for correlating an answer 1036 with a particular SRTP session, the answer SHOULD NOT include any 1037 declarative session parameters that either were not present in the 1038 offered crypto attribute, or were present but with a different value. 1039 If this recommendation is not followed and the offerer receives 1040 multiple answers (e.g. due to SIP forking), the offerer may not be 1041 able to process incoming media stream packets correctly. 1043 3.5.3. Processing of the Initial Answer - Unicast Streams 1045 When the offerer receives the answer, it MUST perform the steps in 1046 [RFC4568] Section 7.1.3 as well as the following steps for each SRTP 1047 media stream it offered with one or more crypto lines containing EKT 1048 parameters in it. 1050 If the answer crypto line contains EKT parameters, and the 1051 corresponding crypto line from the offer contained the same EKT 1052 values, use of EKT has been negotiated successfully and MUST be used 1053 for the media stream. When determining whether the values match, 1054 optional and mandatory parameters MUST be considered equal. 1055 Furthermore, if the default EKT cipher is being used, it MAY be 1056 either present or absent in the offer and/or answer. 1058 If the answer crypto line does not contain EKT parameters, then EKT 1059 MUST NOT be used for the corresponding SRTP session. Note that per 1060 [RFC4568] Section 5.1.3, if the accepted crypto attribute contained 1061 mandatory EKT parameters in the offer, and the crypto attribute in 1062 the answer does not contain EKT parameters, then negotiation has 1063 failed. 1065 If the answer crypto line contains EKT parameters but the 1066 corresponding offered crypto line did not, or if the parameters don't 1067 match or are invalid, then the offerer MUST consider the crypto line 1068 invalid (see [RFC4568] Section 7.1.3 for further operation). 1070 The EKT parameter set is established when the answer is received, 1071 however there are a couple of special cases to consider here. First 1072 of all, if an SRTCP packet is received prior to the answer, then the 1073 EKT parameter set is established provisionally based on the SPI 1074 included. Once the answer (which may include declarative session 1075 parameters) is received, the EKT parameter set is fully established. 1076 The second case involves receipt of multiple answers due to SIP 1077 forking. In this case, there will be multiple EKT parameter sets; 1078 one for each SRTP session. As mentioned earlier, reliable 1079 correlation of SIP dialogs to SRTP sessions requires extensions, and 1080 hence if one or more of the answers include declarative session 1081 parameters, it may be difficult to fully establish the EKT parameter 1082 set for each SRTP session. In the absence of a specific correlation 1083 mechanism, it is RECOMMENDED, that such correlation be done based on 1084 the signaled receive IP-address in the SDP and the observed source 1085 IP-address in incoming SRTP/SRTCP packets, and, if necessary, the 1086 signaled receive UDP port and the observed source UDP port. 1088 3.6. SRTP-Specific Use Outside Offer/Answer 1090 Security Descriptions use for SRTP is not defined outside offer/ 1091 answer and hence neither does Security Descriptions with EKT. 1093 3.7. Modifying the Session 1095 When a media stream using the SRTP security descriptions has been 1096 established, and a new offer/answer exchange is performed, the 1097 offerer and answerer MUST follow the steps in [RFC4568] Section 7.1.4 1098 as well as the following steps. SDES allows for all parameters of 1099 the session to be modified, and the EKT session parameters are no 1100 exception to that, however, there are a few additional rules to be 1101 adhered to when using EKT. 1103 It is permissible to start a session without the use of EKT, and then 1104 subsequently start using EKT, however the converse is not. Thus, 1105 once use of EKT has been negotiated on a particular media stream, EKT 1106 MUST continue to be used on that media stream in all subsequent 1107 offer/answer exchanges. 1109 The reason for this is that both SDES and EKT communicate the SRTP 1110 Master Key with EKT Master Keys taking precedence. Reverting back to 1111 an SDES controlled master key in a synchronized manner is difficult. 1113 Once EKT is being used, the salt for the direct SRTP session MUST NOT 1114 be changed. Thus, a new offer/answer which does not create a new 1115 SRTP session (e.g. because it reuses the same IP address and port) 1116 MUST use the same salt for all crypto attributes as is currently used 1117 for the direct SRTP session. 1119 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1120 value to a different EKT parameter set until 2^32 other mappings have 1121 been used within the SRTP session. In practice, this requirements is 1122 most easily met by using a monotonically increasing SPI value (modulo 1123 2^32 and starting with zero) per direct SRTP session. Note that a 1124 direct SRTP session may span multiple SIP dialogs, and in such cases 1125 coordination of SPI values across those SIP dialogs will be required. 1126 In the simple point-to-point unicast case without translators, the 1127 requirement simply applies within each media line in the SDP. In the 1128 point-to-multipoint case, the requirement applies across all the 1129 associated SIP dialogs. 1131 3.8. Backwards Compatibility Considerations 1133 Backwards compatibility can be achieved in a couple of ways. First 1134 of all, SDES allows for session parameters to be prefixed with "-" to 1135 indicate that they are optional. If the answerer does not support 1136 the EKT session parameters, such optional parameters will simply be 1137 ignored. When the answer is received, absence of the parameters will 1138 indicate that EKT is not being used. Receipt of SRTCP packets prior 1139 to receipt of such an answer will obviously be problematic (as is 1140 normally the case for SDES without EKT). 1142 Alternatively, SDES allows for multiple crypto lines to be included 1143 for a particular media stream. Thus, two crypto lines that differ in 1144 their use of EKT parameters (presence in one, absence in the other) 1145 can be used as a way to negotiate use of EKT. When the answer is 1146 received, the accepted crypto attribute will indicate whether EKT is 1147 being used or not. 1149 3.9. Grammar 1151 The Augmented Backus-Naur Form (ABNF) syntax [RFC4234] for the three 1152 new SDES session parameters is as in Figure 4. 1154 EKT = EKT_Cipher "|" EKT_Key "|" EKT_SPI 1155 EKT_Cipher = "EKT=" EKT_Cipher_Name 1156 EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128" 1157 ; "AESKW_192" and 1158 ; "AESKW_256" defined in 1159 ; this document. 1160 EKT_Key = 1*(base64) ; See Section 3 in RFC3548 1161 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1162 EKT_SPI = 4HEXDIG ; See RFC4234 1164 Figure 4: ABNF for the EKT session parameters. 1166 Using the example from Figure 4 with the EKT extensions to SDP 1167 Security Descriptions results in the following example SDP: 1169 v=0 1170 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1171 s=SRTP Discussion 1172 i=A discussion of Secure RTP 1173 u=http://www.example.com/seminars/srtp.pdf 1174 e=marge@example.com (Marge Simpson) 1175 c=IN IP4 192.0.2.12 1176 t=2873397496 2873404696 1177 m=audio 49170 RTP/SAVP 0 1178 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1179 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1180 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1181 a=crypto:2 F8_128_HMAC_SHA1_80 1182 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1183 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1184 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1186 4. Use of EKT with DTLS-SRTP Key Transport 1188 Using EKT with the DTLS-SRTP Key Transport extensions described in 1189 this document allows securely transporting SRTP keying material from 1190 one DTLS-SRTP peer to another, so the same SRTP keying material can 1191 be used by multiple DTLS-SRTP peers. This extension can be used to 1192 establish EKT keys. This combination of protocols is valuable 1193 because it combines the advantages of DTLS (strong authentication of 1194 the endpoint, flexibility) with the advantages of EKT (allowing 1195 secure multiparty RTP with loose coordination and efficient 1196 communication of per-source keys). 1198 4.1. EKT Extensions to DTLS-SRTP 1200 This document adds a new TLS negotiated extension called "ekt". This 1201 adds a new TLS content type, EKT, and a new negotiated extension EKT. 1202 The negotiated extension MUST only be requested in conjunction with 1203 the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server 1204 indicates its support for EKT by including "dtls-srtp-ekt" in its SDP 1205 and "ekt" in its TLS ServerHello message. If a DTLS client includes 1206 "ekt" in its ClientHello, but does not receive "ekt" in the 1207 ServerHello, the DTLS client MUST NOT send DTLS packets with the 1208 "ekt" content-type. 1210 Using the syntax described in DTLS [I-D.ietf-tls-rfc4347-bis], the 1211 following structures are used: 1213 enum { 1214 ekt_key(0), 1215 ekt_key_ack(1), 1216 ekt_key_error(254), 1217 (255) 1218 } SRTPKeyTransportType; 1220 struct { 1221 SRTPKeyTransportType keytrans_type; 1222 uint24 length; 1223 uint16 message_seq; 1224 uint24 fragment_offset; 1225 uint24 fragment_length; 1226 select (SRTPKeyTransportType) { 1227 case ekt_key: EKTkey; 1228 }; 1229 } KeyTransport; 1231 enum { 1232 AES_128(0), 1233 AESKW_128(1), 1234 AESKW_192(2), 1235 AESKW_256(3), 1236 } ektcipher; 1238 struct { 1239 ektcipher EKT_Cipher; 1240 uint EKT_Key_Value<1..256>; 1241 uint EKT_Master_Salt<1..256>; 1242 uint16 EKT_SPI; 1243 } EKTkey; 1245 Figure 5: Additional TLS Data Structure 1247 A message flow showing a DTLS client and DTLS server using the EKT 1248 extension. The first set of SRTP packets, if present, are encrypted 1249 using the normal DTLS-SRTP key derivation function. The second set 1250 of SRTP packets, after the ekt_key message, can be encrypted using 1251 the EKT key. 1253 Editor's note: do we need reliability for the ekt_key messages? 1254 Client Server 1256 ClientHello + use_srtp + EKT 1257 --------> 1258 ServerHello + use_srtp + EKT 1259 Certificate* 1260 ServerKeyExchange* 1261 CertificateRequest* 1262 <-------- ServerHelloDone 1263 Certificate* 1264 ClientKeyExchange 1265 CertificateVerify* 1266 [ChangeCipherSpec] 1267 Finished --------> 1268 [ChangeCipherSpec] 1269 <-------- Finished 1270 SRTP packets <-------> SRTP packets 1271 ekt_key --------> 1272 SRTP packets <-------> SRTP packets 1274 Figure 6: Handshake Message Flow 1276 4.1.1. Scaling to Large Groups 1278 In certain scenarios it is useful to perform DTLS-SRTP with a device 1279 that is not the RTP peer. A common scenario is multicast, where it 1280 is necessary to distribute the DTLS-SRTP (and EKT distribution) to 1281 several devices. To allow for this, a new SDP attribute, dtls-srtp- 1282 host, is defined which follows the general syntax specified in 1283 Section 5.13 of [RFC4566]. For the dtls-srtp-host attribute: 1285 o the name is the ASCII string "dtls-srtp-host" (lowercase) 1287 o the value is the IP address and port number used for DTLS-SRTP 1289 o This is a media-level attribute and MUST NOT appear ats the 1290 session level 1292 The formal description of the attribute is defined by the following 1293 ABNF [RFC5234] syntax: 1295 attribute = "a=dtls-srtp-host:" 1296 dtls-srtp-host-info *(SP dtls-srtp-host-info) 1297 host-info = nettype space addrtype space 1298 connection-address space port CRLF 1300 Multiple IP/port pairs are provided for IPv6/IPv4 interworking, and 1301 to allow failover. The receiving host SHOULD attempt to use them in 1302 the order provided. 1304 An example of SDP containing the dtls-srtp-host attribute: 1306 v=0 1307 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1308 s=SRTP Discussion 1309 i=A discussion of Secure RTP 1310 u=http://www.example.com/seminars/srtp.pdf 1311 e=marge@example.com (Marge Simpson) 1312 c=IN IP4 192.0.2.12 1313 t=2873397496 2873404696 1314 m=audio 49170 UDP/TLS/RTP/SAVP 0 1315 a=fingerprint:SHA-1 \ 1316 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1317 a=dtls-srtp-ekt 1318 a=dtls-srtp-host:IN IP4 192.0.2.13 56789 1320 4.2. Offer/Answer Considerations 1322 This section describes Offer/Answer considerations for the use of EKT 1323 together with DTLS-SRTP for unicast and multicast streams. The 1324 offerer and answerer MUST follow the procedures specified in 1325 [RFC5764] as well as the following ones. 1327 As most DTLS-SRTP processing is performed on the media channel, 1328 rather than in SDP, there is little processing performed in SDP other 1329 than informational and to redirect DTLS-SRTP to an alternate host. 1330 Advertising support for the extension is necessary in SDP because in 1331 some cases it is required to establish an SRTP call. For example, a 1332 mixer may be able to only support SRTP listeners if those listeners 1333 implement DTLS Key Transport (because it lacks the CPU cycles 1334 necessary to encrypt SRTP uniquely for each listener). 1336 4.2.1. Generating the Initial Offer 1338 sThe initial offer contains a new SDP attribute, "dtls-srtp-ekt", 1339 which contains no value. This indicates the offerer is capable of 1340 supporting DTLS-SRTP with EKT extensions. This is purely 1341 informationa; the DTLS-SRTP handshake is where the DTLS client 1342 attempts to invoke the EKT extensions (as described in Section 4.1). 1344 If the offerer wants another host to perform DTLS-SRTP-EKT 1345 processing, it SHOULD include the dtls-srtp-host attribute in its 1346 offer (Section 4.1). 1348 An example of SDP containing the dtls-srtp-ekt attribute: 1350 v=0 1351 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1352 s=SRTP Discussion 1353 i=A discussion of Secure RTP 1354 u=http://www.example.com/seminars/srtp.pdf 1355 e=marge@example.com (Marge Simpson) 1356 c=IN IP4 192.0.2.12 1357 t=2873397496 2873404696 1358 m=audio 49170 UDP/TLS/RTP/SAVP 0 1359 a=fingerprint:SHA-1 \ 1360 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1361 a=dtls-srtp-ekt 1363 4.2.2. Generating the Initial Answer 1365 Upon receiving the initial offer, the presence of the dtls-srtp-ekt 1366 attribute indicates a desire to receive the EKT extension in the 1367 DTLS-SRTP message, and the dtls-srtp-host attribute indicates an 1368 alternate host to receive the DTLS-SRTP handshake. DTLS messages 1369 should be constructed according to those attributes. 1371 The SDP answer SHOULD contain the dtls-srtp-ekt attribute to indicate 1372 the answerer understands dtls-srtp. It should only contain the dtls- 1373 srtp-host attribute if the answerer also wishes to offload its DTLS- 1374 SRTP processing to another host. 1376 4.2.3. Processing the Initial Answer 1378 The presence of the dtls-srtp-ekt attribute indicates a desire by the 1379 answerer to perform DTLS-SRTP with EKT extensions, and the dtls-srtp- 1380 host attribute indicates an alternate host for DTLS-SRTP processing. 1382 After successful negotiation of the key_transport extension, the DTLS 1383 client and server MAY exchange SRTP packets, encrypted using the KDF 1384 described in [RFC5764]. This is normal and expected, even if Key 1385 Transport was negotiated by both sides, as neither side may (yet) 1386 have a need to alter the SRTP key. However, it is also possible that 1387 one (or both) peers will immediately send new_srtp_key message before 1388 sending any SRTP, and also possible that SRTP, encrypted with an 1389 unknown key, may be received before the new_srtp_key message is 1390 received. 1392 4.2.4. Modifying the Session 1394 As most DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel 1395 (media channel) rather than signaling, no special processing for 1396 modifying the session is necessary. 1398 5. Use of EKT with MIKEY 1400 The advantages outlined in Section 1 are useful in some scenarios in 1401 which MIKEY is used to establish SRTP sessions. In this section, we 1402 briefly review MIKEY and related work, and discuss these scenarios. 1404 An SRTP sender or a group controller can use MIKEY to establish a 1405 SRTP cryptographic context. This capability includes the 1406 distribution of a TEK generation key (TGK) or the TEK itself, 1407 security policy payload, crypto session bundle ID (CSB_ID) and a 1408 crypto session ID (CS_ID). The TEK directly maps to an SRTP master 1409 key, whereas the TGK is used along with the CSB_ID and a CS_ID to 1410 generate a TEK. The CS_ID is used to generate multiple TEKs (SRTP 1411 master keys) from a single TGK. For a media stream in SDP, MIKEY 1412 allocates two consecutive numbers for the crypto session IDs, so that 1413 each direction uses a different SRTP master key (see [RFC4567]). 1415 The MIKEY specification [RFC3830] defines three modes to exchange 1416 keys, associated parameters and to protect the MIKEY message: pre- 1417 shared key, public-key encryption and Diffie-Hellman key exchange. 1418 In the first two modes the MIKEY initiator only chooses and 1419 distributes the TGK or TEK, whereas in the third mode both MIKEY 1420 entities (the initiator and responder) contribute to the keys. All 1421 three MIKEY modes have in common that for establishing a SRTP session 1422 the exchanged key is valid for the send and receive direction. 1423 Especially for group communications it is desirable to update the 1424 SRTP master key individually per direction. EKT provides this 1425 property by distributing the SRTP master key within the SRTP/SRTCP 1426 packet. 1428 MIKEY already supports synchronization of ROC values between the 1429 MIKEY initiator and responder. The SSRC / ROC value pair is part of 1430 the MIKEY Common Header payload. This allows providing the current 1431 ROC value to late joiners of a session. However, in some scenarios a 1432 key management based ROC synchronization is not sufficient. For 1433 example, in mobile and wireless environments, members may go in and 1434 out of coverage and may miss a sequence number overrun. In point-to- 1435 multipoint translator scenarios it is desirable to not require the 1436 group controller to track the ROC values of each member, but to 1437 provide the ROC value by the originator of the SRTP packet. A better 1438 alternative to synchronize the ROC values is to send them directly 1439 via SRTP/SRTCP, as EKT does. A separate SRTP extension is being 1440 proposed [RFC4771] to include the ROC as part of a modified 1441 authentication tag. Unlike EKT, this extension uses only SRTP and 1442 not SRTCP as its transport and does not allow updating the SRTP 1443 master key. 1445 Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP 1446 streams. Each sender of a stream sends the associated SSRC within 1447 the MIKEY message to the other party. If a SRTP session participant 1448 starts a new SRTP source or a new participant is added to a group, 1449 subsequent SDP offer/answer and MIKEY exchanges are necessary to 1450 update the SSRC values. EKT improves these scenarios by updating the 1451 keys and SSRC values without coordination on the signaling channel. 1452 With EKT, SRTP can handle early media, since the EKT SPI allows the 1453 receiver to identify the cryptographic keys and parameters used by 1454 the source. 1456 The MIKEY specification [RFC3830] suggests the use of unicast for 1457 rekeying. This method does not scale well to large groups or 1458 interactive groups. The EKT extension of SRTP/SRTCP provides a 1459 solution for rekeying the SRTP master key and for ROC/SSRC 1460 synchronization. EKT is not a substitution for MIKEY, but rather a 1461 complementary addition to address the above described limitations of 1462 MIKEY. 1464 In the next section we provide an extension to MIKEY for support of 1465 EKT. EKT can be used only with the pre-shared key or public-key 1466 encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode 1467 is not suitable in conjunction with EKT, because it is not possible 1468 to establish one common EKT key over multiple EKT entities. 1469 Additional MIKEY modes specified in separate documents are not 1470 considered for EKT. 1472 5.1. EKT extensions to MIKEY 1474 In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI 1475 must be negotiated in the MIKEY message exchange. 1477 For EKT we specify a new SRTP Policy Type in the Security Policy (SP) 1478 payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload 1479 contains a set of policies. Each policy consists of a number Policy 1480 Param TLVs. 1482 Prot type | Value 1483 ------------------- 1484 EKT | TBD (will be requested from IANA) 1486 Figure 7: EKT Security Policy 1488 The EKT Security Policy has one parameter representing the EKT 1489 cipher. 1491 Type | Meaning | Possible values 1492 ---------------------------------------------------- 1493 0 | EKT cipher | see below 1495 Figure 8: EKT Security Policy Parameters 1497 EKT cipher | Value 1498 ------------------- 1499 AES_128 | 0 1500 AESKW_128 | 1 1501 AESKW_192 | 2 1502 AESKW_256 | 3 1504 Figure 9: EKT Cipher Parameters 1506 AES_128 is the default value for the EKT cipher. 1508 The two mandatory EKT parameters (EKT_Key and EKT_SPI) are 1509 transported in the MIKEY KEMAC payload within one separate Key Data 1510 sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC 1511 payload carries the TEK Generation Key (TGK) or the Traffic 1512 Encryption Key (TEK). One or more TGKs or TEKs are carried in 1513 individual Key Data sub-payloads within the KEMAC payload. The KEMAC 1514 payload is encrypted as part of MIKEY. The Key Data sub- payload, 1515 specified in Section 6.13 of [RFC3830], has the following format: 1517 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 ! Next Payload ! Type ! KV ! Key data len ! 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 ! Key data ~ 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 ! Salt len (optional) ! Salt data (optional) ~ 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 ! KV data (optional) ~ 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 Figure 10: Key Data Sub-Payload of MIKEY 1531 The Type field, 4 bits in length, indicates the type of key included 1532 in the payload. We define Type = TBD (will be requested from IANA) 1533 to indicate transport of the EKT key. 1535 The optional fields 'Salt len' and 'Salt data' SHOULD be omitted for 1536 the key type EKT_Key, if the SRTP master salt is already present in 1537 the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload MUST 1538 contain a SRTP master salt, if the SRTP master salt is not already 1539 present in the TGK or TEK Key Data sub-payload. 1541 KV (4 bits): indicates the type of key validity period specified. 1542 KV=1 is currently specified as an SPI. We use that value to indicate 1543 the KV_data contains the ETK_SPI for the key type EKT_Key. KV_data 1544 would be 16 bits in length, but it is also possible to interpret the 1545 length from the 'Key data len' field. KV data MUST NOT be optional 1546 for the key type EKT_Key when KV = 1. 1548 5.2. Offer/Answer considerations 1550 This section describes Offer/Answer considerations for the use of EKT 1551 together with MIKEY for unicast streams. The offerer and answerer 1552 MUST follow the procedures specified in [RFC3830] and [RFC4567] as 1553 well as the following ones. 1555 5.2.1. Generating the Initial Offer 1557 If it is intended to use MIKEY together with EKT, the offerer MUST 1558 include at least one MIKEY key-mgmt attribute with one EKT_Key Key 1559 Data sub-payload and the EKT_Cipher Security Policy payload. MIKEY 1560 can be used on session or media level. On session level, MIKEY 1561 provides the keys for multiple SRTP sessions in the SDP offer. The 1562 EKT SPI references a EKT parameter set including the Secure RTP 1563 parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is 1564 used on session level, it is only possible to use one EKT SPI value. 1565 Therefore, the session-level MIKEY message MUST contain one SRTP 1566 Security Policy payload only, which is valid for all related SRTP 1567 media lines. If MIKEY is used on media level, different SRTP 1568 Security Policy parameters (and consequently different EKT SPI 1569 values) can be used for each media line. If MIKEY is used on session 1570 and media level, the medial level content overrides the session level 1571 content. 1573 EKT requires a single shared SRTP master salt between all 1574 participants in the direct SRTP session. If a MIKEY key-mgmt 1575 attribute contains more than one TGK or TEK Key Data sub-payload, all 1576 the sub-payloads MUST contain the same master salt value. 1577 Consequently, the EKT_Key Key Data sub-payload MAY also contain the 1578 same salt or MAY omit the salt value. If the SRTP master salt is not 1579 present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub- 1580 payload MUST contain a master salt. 1582 5.2.2. Generating the Initial Answer 1584 For each media line in the offer using MIKEY, provided on session or/ 1585 and on media level, the answerer examines the related MIKEY key-mgmt 1586 attributes for the presence of EKT parameters. In order to accept 1587 the offered key-mgmt attribute, the MIKEY message MUST contain one 1588 EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy 1589 payload. The answerer examines also the existence of a SRTP master 1590 salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple 1591 salts are available, all values MUST be equal. If the salt values 1592 differ or no salt is present, the key-mgmt attribute MUST be 1593 considered as invalid. 1595 The MIKEY responder message in the SDP answer does not contain a 1596 MIKEY KEMAC or Security Policy payload and consequently does not 1597 contain any EKT parameters. If the key-mgmt attribute for a media 1598 line was accepted by the answerer, the EKT parameter set of the 1599 offerer is valid for both directions of the SRTP session. 1601 5.2.3. Processing the Initial Answer 1603 On reception of the answer, the offerer examines if EKT has been 1604 accepted for the offered media lines. If a MIKEY key-mgmt attribute 1605 is received containing a valid MIKEY responder message, EKT has been 1606 successfully negotiated. On receipt of a MIKEY error message, EKT 1607 negotiation has failed. For example, this may happen if an EKT 1608 extended MIKEY initiator message is sent to a MIKEY entity not 1609 supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is 1610 returned to indicate that the EKT_Cipher Security Policy payload or 1611 the EKT_Key sub-payload is not supported. In this case, the offerer 1612 may send a second SDP offer with a MIKEY key-mgmt attribute without 1613 the additional EKT extensions. 1615 This behavior can be improved by defining an additional key-mgmt 1616 prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. 1617 One attribute offers MIKEY together with EKT and the other one offers 1618 MIKEY without EKT. This is for further discussion. 1620 5.2.4. Modifying the Session 1622 Once a SRTP stream has been established, a new offer/answer exchange 1623 can modify the session including the EKT parameters. If the EKT key 1624 or EKT cipher is modified, i.e. a new EKT parameter set is created, 1625 the offerer MUST also provide a new EKT SPI value. The offerer MUST 1626 NOT remap an existing EKT SPI value to a new EKT parameter set. 1627 Similar, a modification of the SRTP Security Policy leads to a new 1628 EKT parameter set and requires a fresh EKT SPI, even the EKT key or 1629 cipher did not change. 1631 Once EKT is being used, the SRTP master salt for the SRTP session 1632 MUST NOT be changed. The salt in the Key Data sub-payloads within 1633 the subsequent offers MUST be the same as the one already used. 1635 After EKT has been successfully negotiated for a session and a SRTP 1636 master key has been transported by EKT, it is difficult to switch 1637 back to a pure MIKEY based key exchange in a synchronized way. 1638 Therefore, once EKT is being used for a session, EKT MUST be used 1639 also in all subsequent offer/answer exchanges for that session. 1641 6. Interworking with Other SRTP Key Management Systems 1643 6.1. Security Descriptions 1645 Today, Security Descriptions [RFC4568] is used for distributing SRTP 1646 keys in several different IP PBX systems and is expected to be used 1647 by 3GPP's Long Term Evolution (LTE). The IP PBX systems are 1648 typically used within a single enterprise, and LTE is used within the 1649 confines of a mobile operator's network. A Session Border Controller 1650 is a reasonable solution to interwork between Security Descriptions 1651 in one network and DTLS-SRTP in another network. For example, a 1652 mobile operator (or an Enterprise) could operate Security 1653 Descriptions within their network and DTLS-SRTP towards the Internet. 1655 However, due to the way Security Descriptions and DTLS-SRTP manage 1656 their SRTP keys, such an SBC has to authenticate, decrypt, re- 1657 encrypt, and re-authenticate the SRTP (and SRTCP) packets in one 1658 direction, as shown in Figure 11, below. This is computationally 1659 expensive. 1661 RFC4568 endpoint SBC 1662 DTLS-SRTP endpoint 1663 | | | 1664 1. |---key=A------------->| | 1665 2. | |<-DTLS-SRTP handshake->| 1666 3. |<--key=B--------------| | 1667 4. | |<--SRTP, encrypted w/B-| 1668 5. |<-SRTP, encrypted w/B-| | 1669 6. |-SRTP, encrypted w/A->| | 1670 7. | (decrypt, re-encrypt) | 1671 8. | |-SRTP, encrypted w/C-->| 1672 | | | 1674 Figure 11: Interworking Security Descriptions and DTLS-SRTP 1676 The message flow is as follows (similar steps occur with SRTCP): 1678 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 1679 key to the SBC, using a=crypto in its SDP. 1681 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1682 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1683 B) and to the DTLS-SRTP endpoint (key C). 1685 3. The SBC communicates the SRTP encryption key (key B) to the 1686 Security Descriptions endpoint (using a=crypto). (There is no 1687 way, with DTLS-SRTP, to communicate the Security Descriptions key 1688 to the DTLS-SRTP key endpoint.) 1690 4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1691 B. This is received by the SBC. 1693 5. The received SRTP packet is simply forwarded; the SBC does not 1694 need to do anything with this packet as its key (key B) was 1695 already communicated in step 3. 1697 6. The Security Descriptions endpoint sends an SRTP packet, 1698 encrypted with its key A. 1700 7. The SBC has to authenticate and decrypt the SRTP packet (using 1701 key A), and re-encrypt it and generate an HMAC (using key C). 1703 8. The SBC sends the new SRTP packet. 1705 If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the 1706 computationally expensive operation so the SBC does not need not 1707 perform any per-packet operations on the SRTP (or SRTCP) packets in 1708 either direction. With EKT the SBC can simply forward the SRTP (and 1709 SRTCP) packets in both directions without per-packet HMAC or 1710 cryptographic operations. 1712 To accomplish this interworking, DTLS-SRTP EKT must be supported on 1713 the DTLS-SRTP endpoint, which allows the SBC to transport the 1714 Security Description key to the EKT endpoint and send the DTLS-SRTP 1715 key to the Security Descriptions endpoint. This works equally well 1716 for both incoming and outgoing calls. An abbreviated message flow is 1717 shown in Figure 12, below. 1719 RFC4568 endpoint SBC 1720 DTLS-SRTP endpoint 1721 | | | 1722 1. |---key=A------------->| | 1723 2. | |<-DTLS-SRTP handshake->| 1724 3. |<--key=B--------------| | 1725 4. | |--new_srtp_key:A------>| 1726 5. | |<--SRTP, encrypted w/B-| 1727 5. |<-SRTP, encrypted w/B-| | 1728 6. |-SRTP, encrypted w/A->| | 1729 7. | |-SRTP, encrypted w/A-->| 1730 | | | 1732 Figure 12: Interworking Security Descriptions and EKT 1734 The message flow is as follows (similar steps occur with SRTCP): 1736 1. Security Descriptions endpoint discloses its SRTP key to the SBC 1737 (a=crypto). 1739 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1740 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1741 B) and to the DTLS-SRTP endpoint (key C). 1743 3. The SBC communicates the SRTP encryption key (key B) to the 1744 Security Descriptions endpoint. 1746 4. The SBC uses the EKT to indicate that SRTP packets will be 1747 encrypted with 'key A' towards the DTLS-SRTP endpoint. 1749 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1750 B. This is received by the SBC. 1752 6. The received SRTP packet is simply forwarded; the SBC does not 1753 need to do anything with this packet as its key (key B) was 1754 communicated in step 3. 1756 7. The Security Descriptions endpoint sends an SRTP packet, 1757 encrypted with its key A. 1759 8. The received SRTP packet is simply forwarded; the SBC does not 1760 need to do anything with this packet as its key (key A) was 1761 communicated in step 4. 1763 7. Design Rationale 1765 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1766 "persistent transport-level identifier for an RTP source" since 1767 "receivers require the CNAME to keep track of each participant." EKT 1768 works in much the same way, using SRTCP to carry information needed 1769 for the proper processing of the SRTP traffic. 1771 With EKT, SRTP gains the ability to synchronize the creation of 1772 cryptographic contexts across all of the participants in a single 1773 session. This feature provides some, but not all, of the 1774 functionality that is present in IKE phase two (but not phase one). 1775 Importantly, EKT does not provide a way to indicate SRTP options. 1777 With EKT, external signaling mechanisms provide the SRTP options and 1778 the EKT Key, but need not provide the key(s) for each individual SRTP 1779 source. EKT provides a separation between the signaling mechanisms 1780 and the details of SRTP. The signaling system need not coordinate 1781 all SRTP streams, nor predict in advance how many streams will be 1782 present, nor communicate SRTP-level information (e.g. rollover 1783 counters) of current sessions. 1785 EKT is especially useful for multi-party sessions, and for the case 1786 where multiple RTP sessions are sent to the same destination 1787 transport address (see the example in the definition of "RTP session" 1788 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1789 multiple endpoints at the same time) can cause multiple RTP sessions 1790 to be sent to the same transport address, making EKT useful for use 1791 with SIP. 1793 EKT can also be used in conjunction with a scalable group-key 1794 management system like GDOI. Such a system provides a secure entity 1795 authentication method and a way to revoke group membership, both of 1796 which are out of scope of EKT. 1798 It is natural to use SRTCP to transport encrypted keying material for 1799 SRTP, as it provides a secure control channel for (S)RTP. However, 1800 there are several different places in SRTCP in which the encrypted 1801 SRTP master key and ROC could be conveyed. We briefly review some of 1802 the alternatives in order to motivate the particular choice used in 1803 this specification. One alternative is to have those values carried 1804 as a new SDES item or RTCP packet. This would require that the 1805 normal SRTCP encryption be turned off for the packets containing that 1806 SDES item, since on the receiver's side, SRTCP processing completes 1807 before the RTCP processing starts. This tension between encryption 1808 and the desire for RTCP privacy is highly undesirable. Additionally, 1809 this alternative makes SRTCP dependent upon the parsing of the RTCP 1810 compound packet, which adds complexity. It is simpler to carry the 1811 encrypted key in a new SRTCP field. One way to do this and to be 1812 backwards compatible with the existing specification is to define a 1813 new crypto function that incorporates the encrypted key. We define a 1814 new authentication transform because EKT relies on the normal SRTCP 1815 authentication to provide implicit authentication of the encrypted 1816 key. 1818 An SRTP packet containing an SSRC that has not been seen will be 1819 discarded. This practice may induce a burst of packet loss at the 1820 outset of an SRTP stream, due to the loss or reorder of the first 1821 SRTCP packet with the EKT containing the key and rollover counter for 1822 that stream. However, this practice matches the conservative RTP 1823 memory-allocation strategy; many existing applications accept this 1824 risk of initial packet loss. Alternatively, implementations may wish 1825 to delay discarding such packets for a short period of time as 1826 described in Section 2.4. 1828 When EKT is carried in SRTCP, it adds eight additional bytes to each 1829 SRTCP packet, plus the length of the Encrypted Master Key field. 1830 Using the SRTP and EKT defaults, the total overhead is 24 bytes. 1831 This overhead does not detract from the total bandwidth used by SRTP, 1832 since it is included in the RTCP bandwidth computation. However, it 1833 will cause the control protocol to issue packets less frequently. 1835 The main motivation for the use of the variable-length format is 1836 bandwidth conservation. If EKT is used of SRTP, there will be a loss 1837 of bandwidth due to the additional 24 bytes in each RTP packet. For 1838 some applications, this bandwidth loss is significant. 1840 8. Security Considerations 1842 With EKT, each SRTP sender and receiver can generate distinct SRTP 1843 master keys. This property avoids any security concern over the re- 1844 use of keys, by empowering the SRTP layer to create keys on demand. 1845 Note that the inputs of EKT are the same as for SRTP with key- 1846 sharing: a single key is provided to protect an entire SRTP session. 1847 However, EKT provides complete security, even in the absence of 1848 further out-of-band coordination of SSRCs, and even when SSRC values 1849 collide. 1851 EKT uses encrypted key transport with implicit authentication. A 1852 strong cipher is used to ensure the confidentiality of the master 1853 keys as they are transported. The authenticity of the master keys is 1854 ensured by the base authentication check, which uses the plaintext 1855 form of that key. If the base authentication function and the cipher 1856 cannot be defeated by a particular attacker, then that attacker will 1857 be unable to defeat the implicit authentication. 1859 In order to avoid potential security issues, the SRTP authentication 1860 tag length used by the base authentication method MUST be at least 1861 ten octets. 1863 9. IANA Considerations 1865 This section registers with IANA the following SRTP session 1866 parameters for SDP Security Descriptions [RFC4568]: 1868 EKT_KEY 1870 EKT_CIPHER 1872 EKT_SPI 1874 The definition of these parameters is provided in Section 3.4. 1876 We request the following IANA assignments from existing MIKEY IANA 1877 tables: 1879 From the Key Data payload name spaces, a value to indicate the 1880 type as the 'EKT_Key'. 1882 From the Security Policy table name space, a new value to be 1883 assigned for 'EKT' (see Figure 7). 1885 Furthermore, we need a set of unique parameters: 1887 EKT parameter type (see Figure 8) 1889 EKT cipher (see Figure 9) 1891 10. Acknowledgements 1893 Thanks to Rob Raymond, Nermeen Ismail, and Kai Fischer for fruitful 1894 discussions and comments. 1896 11. References 1898 11.1. Normative References 1900 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1901 Information Processing Standard. 1903 [I-D.ietf-tls-rfc4347-bis] 1904 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1905 Security version 1.2", draft-ietf-tls-rfc4347-bis-03 (work 1906 in progress), October 2009. 1908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1909 Requirement Levels", BCP 14, RFC 2119, March 1997. 1911 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1912 A., Peterson, J., Sparks, R., Handley, M., and E. 1913 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1914 June 2002. 1916 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1917 with Session Description Protocol (SDP)", RFC 3264, 1918 June 2002. 1920 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1921 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1923 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1924 Encodings", RFC 3548, July 2003. 1926 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1927 Jacobson, "RTP: A Transport Protocol for Real-Time 1928 Applications", STD 64, RFC 3550, July 2003. 1930 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1931 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1932 RFC 3711, March 2004. 1934 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1935 Specifications: ABNF", RFC 4234, October 2005. 1937 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1938 Information Type for the General Extension Payload in 1939 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1941 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1942 Description Protocol", RFC 4566, July 2006. 1944 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1945 Carrara, "Key Management Extensions for Session 1946 Description Protocol (SDP) and Real Time Streaming 1947 Protocol (RTSP)", RFC 4567, July 2006. 1949 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1950 Description Protocol (SDP) Security Descriptions for Media 1951 Streams", RFC 4568, July 2006. 1953 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1954 Transform Carrying Roll-Over Counter for the Secure Real- 1955 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1957 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1958 Security (DTLS) Extension to Establish Keys for the Secure 1959 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1961 11.2. Informative References 1963 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1964 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1965 August 2004. 1967 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1968 Internet Protocol", RFC 4301, December 2005. 1970 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1971 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1973 Authors' Addresses 1975 David A. McGrew 1976 Cisco Systems, Inc. 1977 510 McCarthy Blvd. 1978 Milpitas, CA 95035 1979 US 1981 Phone: (408) 525 8651 1982 Email: mcgrew@cisco.com 1983 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1985 Flemming Andreason 1986 Cisco Systems, Inc. 1987 499 Thornall Street 1988 Edison, NJ 08837 1989 US 1991 Email: fandreas@cisco.com 1993 Dan Wing 1994 Cisco Systems, Inc. 1995 510 McCarthy Blvd. 1996 Milpitas, CA 95035 1997 US 1999 Phone: (408) 853 4197 2000 Email: dwing@cisco.com 2002 Kai Fischer 2003 Siemens Enterprise Networks GmbH & Co KG 2004 Otto-Hahn-Ring 6 2005 Munich, Bavaria 81739 2006 Germany 2008 Email: Kai.Fischer@siemens.com