idnits 2.17.1 draft-mcgrew-srtp-ekt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5402 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 612, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1284, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-02 ** 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) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft F. Andreasen 4 Intended status: Standards Track D. Wing 5 Expires: January 13, 2010 Cisco Systems, Inc. 6 L. Dondeti 7 QUALCOMM 8 July 12, 2009 10 Encrypted Key Transport for Secure RTP 11 draft-mcgrew-srtp-ekt-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 13, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 SRTP Encrypted Key Transport (EKT) is an extension to SRTP that 50 provides for the secure transport of SRTP master keys, Rollover 51 Counters, and other information, within SRTCP. This facility enables 52 SRTP to work for decentralized conferences with minimal control, and 53 to handle situations caused by SIP forking and early media. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions Used In This Document . . . . . . . . . . . . 5 59 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 60 2.1. Authentication Tag Format . . . . . . . . . . . . . . . . 6 61 2.2. Packet Processing and State Machine . . . . . . . . . . . 8 62 2.2.1. Outbound (Tag Generation) . . . . . . . . . . . . . . 8 63 2.2.2. Inbound (Tag Verification) . . . . . . . . . . . . . . 10 64 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 13 66 2.3.2. The AES Key Wrap Cipher . . . . . . . . . . . . . . . 13 67 2.3.3. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 14 68 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 14 69 2.5. Timing and Reliability Consideration . . . . . . . . . . . 15 70 3. Interworking with Other SRTP Key Management Systems . . . . . 16 71 3.1. Security Descriptions . . . . . . . . . . . . . . . . . . 16 72 4. EKT and SDP Security Descriptions . . . . . . . . . . . . . . 19 73 4.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 19 74 4.2. Relationship between EKT and SDP Security Descriptions . . 20 75 4.3. Overview of Combined EKT and SDP Security Description 76 Operation . . . . . . . . . . . . . . . . . . . . . . . . 22 77 4.4. EKT Extensions to SDP Security Descriptions . . . . . . . 22 78 4.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 22 79 4.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 23 80 4.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 23 81 4.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 23 82 4.5.1. Generating the Initial Offer - Unicast Streams . . . . 24 83 4.5.2. Generating the Initial Answer - Unicast Streams . . . 25 84 4.5.3. Processing of the Initial Answer - Unicast Streams . . 26 85 4.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 27 86 4.7. Modifying the Session . . . . . . . . . . . . . . . . . . 27 87 4.8. Backwards Compatibility Considerations . . . . . . . . . . 28 88 4.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 5. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 29 90 5.1. DTLS-SRTP Extension . . . . . . . . . . . . . . . . . . . 29 91 6. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 32 92 6.1. EKT transform attribute mapping in MIKEY . . . . . . . . . 32 93 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 35 94 8. RTP Transport . . . . . . . . . . . . . . . . . . . . . . . . 37 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 100 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 103 1. Introduction 105 RTP is designed to allow decentralized groups with minimal control to 106 establish sessions, e.g. for multimedia conferences. Unfortunately, 107 Secure RTP (SRTP, [RFC3711]) cannot be used in many minimal-control 108 scenarios, because it requires that SSRC values and other data be 109 coordinated among all of the participants in a session. For example, 110 if a participant joins a session that is already in progress, the 111 SRTP rollover counter (ROC) of each SRTP source in the session needs 112 to be provided to that participant. 114 The inability of SRTP to work in the absence of central control was 115 well understood during the design of that protocol; that omission was 116 considered less important than optimizations such as bandwidth 117 conservation. Additionally, in many situations SRTP is used in 118 conjunction with a signaling system that can provide most of the 119 central control needed by SRTP. However, there are several cases in 120 which conventional signaling systems cannot easily provide all of the 121 coordination required. It is also desirable to eliminate the layer 122 violations that occur when signaling systems coordinate certain SRTP 123 parameters, such as SSRC values and ROCs. 125 This document defines Encrypted Key Transport (EKT) for SRTP, an 126 extension to SRTP that fits within the SRTP framework and reduces the 127 amount of signaling control that is needed in an SRTP session. EKT 128 securely distributes the SRTP master key and other information for 129 each SRTP source, using SRTCP to transport that information. With 130 this method, SRTP entities are free to choose SSRC values as they see 131 fit, and to start up new SRTP sources with new SRTP master keys (see 132 Section 2.2) within a session without coordinating with other 133 entities via signaling or other external means. This fact allows to 134 reinstate the RTP collision detection and repair mechanism, which is 135 nullified by the current SRTP specification because of the need to 136 control SSRC values closely. An SRTP endpoint using EKT can generate 137 new keys whenever an existing SRTP master key has been overused, or 138 start up a new SRTP source to replace an old SRTP source that has 139 reached the packet-count limit. EKT also solves the problem in which 140 the burst loss of the N initial SRTP packets can confuse an SRTP 141 receiver, when the initial RTP sequence number is greater than or 142 equal to 2^16 - N. These features simplify many architectures that 143 implement SRTP. 145 EKT provides a way for an SRTP session participant, either sender or 146 receiver, to securely transport its SRTP master key and current SRTP 147 rollover counter to the other participants in the session. This 148 data, possibly in conjunction with additional data provided by an 149 external signaling protocol, furnishes the information needed by the 150 receiver to instantiate an SRTP/SRTCP receiver context. 152 EKT does not control the manner in which the SSRC and master key are 153 generated; it is concerned only with their secure transport. Those 154 values may be generated on demand by the SRTP endpoint, or may be 155 dictated by an external mechanism such as a signaling agent or a 156 secure group controller. 158 EKT is not intended to replace external key establishment mechanisms 159 such as DTLS-SRTP Key Transport 160 [I-D.wing-avt-dtls-srtp-key-transport], SDP Security Descriptions 161 [RFC4568], or MIKEY [RFC3830]. Instead, it is used in conjunction 162 with those methods, and it relieves them of the burden of tightly 163 coordinating every SRTP source among every SRTP participant. 165 This document is organized as follows. A complete normative 166 definition of EKT is provided in Section 2. It consists of packet 167 processing algorithms (Section 2.2) and cryptographic definitions 168 (Section 2.3) . In Section 4, the use of EKT with SDP Security 169 Descriptions is defined. In Section 6 we outline the use of EKT with 170 MIKEY. Section 7 provides a design rationale. Security 171 Considerations are provided in Section 9, and IANA considerations are 172 provided in Section 10. 174 1.1. Conventions Used In This Document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 2. Encrypted Key Transport 182 In EKT, an SRTP master key is encrypted with a Key Encrypting Key 183 (KEK), and the resulting ciphertext is transported in every SRTCP 184 packet. A single KEK suffices for a single SRTP session, regardless 185 of the number of participants in the session. However, there can be 186 multiple KEKs used within a particular session. 188 In order to convey the ciphertext of the SRTP master key, and other 189 additional information, the SRTCP Authentication Tag field is 190 subdivided as defined in Section 2.1. EKT defines a new SRTCP 191 authentication function, which uses this format. It incorporates a 192 conventional SRTCP authentication function, which is called the base 193 authentication function in this specification. Any SRTCP 194 authentication function, such as the default one of HMAC-SHA1 with a 195 160-bit key and an 80-bit authentication tag, can be used as a base 196 authentication function. EKT also defines a new method of providing 197 SRTP master keys to an endpoint. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 : Base Authentication Tag : 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 : Encrypted Master Key : 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Rollover Counter | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Initial Sequence Number | Security Parameter Index |1| 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 : Base Authentication Tag : 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Reserved |0| 217 +-+-+-+-+-+-+-+-+ 219 Figure 1: The EKT Authentication Tag format. 221 2.1. Authentication Tag Format 223 EKT uses the Authentication Tag format shown in Figure 1. The top 224 diagram shows the format in the case that the final bit is set to 225 one, in which case all of the EKT fields are present. The bottom 226 diagram shows the format in the case that the final bit is set to 227 zero, in which case the Encrypted Master Key, Rollover Counter, 228 Initial Sequence Number, and Security Parameter Index fields are 229 absent, and the Reserved field is present; the latter field MUST be 230 set to the all-zero value. These two cases can always be 231 unambiguously distinguished by the final bit, or by checking to see 232 if the final byte in the packet has the all-zero value. 234 The Authentication Tag field contains the following sub-fields: 236 Base Authentication Tag This field contains the authentication tag 237 computed by the base authentication function. The value of this 238 field is used to check the authenticity of the packet. 240 Encrypted Master Key The length of this field is variable, and is 241 equal to the ciphertext size N defined in Section 2.3. Note that 242 the length of the field is inferable from the SPI field, since the 243 particular EKT cipher used by the sender of a packet is inferable 244 from that field. The Encrypted Master Key field is included 245 outside of the authenticated portion of the SRTCP packet, 246 immediately following the Authentication Tag. It contains the 247 ciphertext value resulting from the encryption of the SRTP master 248 key corresponding to the SSRC contained in the packet. The 249 encryption and decryption of this value is done using a cipher as 250 defined in Section 2.3. 252 Rollover Counter The length of this field is fixed at 32 bits. This 253 field is set to the current value of the SRTP rollover counter in 254 the SRTP context associated with the SSRC in the SRTCP packet. 255 This field immediately follows the Encrypted Master Key field. 257 Initial Sequence Number (ISN) The length of this field is fixed at 258 16 bits. If this field is nonzero, then it indicates the RTP 259 sequence number of the initial RTP packet that is protected using 260 the SRTP master key conveyed (in encrypted form) by the Encrypted 261 Master Key field of this packet. If this field is zero, it 262 indicates that the initial RTP packet protected using the SRTP 263 master key conveyed in this packet preceded, or was concurrent 264 with, the last roll-over of the RTP sequence number. The ISN 265 field follows the Rollover Counter field. 267 Security Parameter Index (SPI) The length of this field is fixed at 268 16 bits. This field indicates the appropriate Key Encrypting Key 269 and other parameters for the receiver to use when processing the 270 packet. It is an "index" into a table of possibilities (which are 271 established via signaling or some other out-of-band means), much 272 like the IPsec Security Parameter Index [RFC4301]. The parameters 273 that are identified by this field are: 275 The Key Encrypting Key used to process the packet. 277 The EKT cipher used to process the packet. 279 The Secure RTP parameters associated with the SRTP Master Key 280 carried by the packet and the SSRC value in the packet. 281 Section 8.2. of [RFC3711] summarizes the parameters defined by 282 that specification. 284 Together, these elements are called an EKT parameter set. Within 285 each SRTP session, each distinct EKT parameter set that may be 286 used MUST be associated with a distinct SPI value, to avoid 287 ambiguity. The SPI field follows the Initial Sequence Number. 288 Since it is the last field in the packet, and has a fixed length, 289 it is always possible to unambiguously parse this field. 291 2.2. Packet Processing and State Machine 293 At any given time, each SRTP/SRTCP source has associated with it a 294 single EKT parameter set. This parameter set is used to process all 295 outbound packets, and is called the outbound parameter set. There 296 may be other EKT parameter sets that are used by other SRTP/SRTCP 297 sources in the same session. All of these EKT parameter sets SHOULD 298 be stored by all of the participants in an SRTP session, for use in 299 processing inbound SRTCP traffic. 301 We next review the SRTCP authentication method and show how the EKT 302 authentication method is built on top of the base method. An SRTCP 303 authentication method consists of a tag-generation function and a 304 verification function. The tag-generation function takes as input a 305 secret key, the data to be authenticated, and the SRTCP packet index. 306 It provides an authentication tag as its sole output, and is used in 307 the processing of outbound packets. The verification function takes 308 as input a secret key, the data to be authenticated, the SRTCP packet 309 index, and the authentication tag. It returns an indication of 310 whether or not the data, index, and tag are valid or not. It is used 311 in the processing of inbound packets. EKT defines a tag-generation 312 function in terms of the base tag-generation function, and defines a 313 verification function in terms of the base verification function. 314 The tag-generation function is used to process outbound packets, and 315 the verification function is used to process inbound packets. 317 2.2.1. Outbound (Tag Generation) 319 When an SRTCP packet needs to be sent, the EKT tag generation 320 function works as follows. Given an RTCP packet, the Rollover 321 Counter field in the SRTCP packet is set to the current value of the 322 SRTP rollover counter (represented as an unsigned integer in network 323 byte order). 325 The Initial Sequence Number field is set to zero, if the initial RTP 326 packet protected using the current SRTP master key for this source 327 preceded, or was concurrent with, the last roll-over of the RTP 328 sequence number. Otherwise, that field is set to the value of the 329 RTP sequence number of the initial RTP packet that was or will be 330 protected by that key. When the SRTP master key corresponding to a 331 source is changed, the new key SHOULD be communicated in advance via 332 EKT. (Note that the ISN field allows the receiver to know when it 333 should start using the new key to process SRTP packets.) This 334 enables the rekeying event to be communicated before any RTP packets 335 are protected with the new key. The rekeying event MUST not change 336 the value of ROC (otherwise, the current value of the ROC would not 337 be known to late joiners of existing sessions). 339 The Security Parameter Index field is set to the value of the 340 Security Parameter Index that is associated with the outbound 341 parameter set. 343 The Encrypted Master Key field is set to the ciphertext created by 344 encrypting the SRTP master key with the EKT cipher, using the KEK as 345 the encryption key. The encryption process is detailed in 346 Section 2.3. Implementations MAY cache the value of this field to 347 avoid recomputing it for each packet that is sent. 349 2.2.1.1. Base Authentication Tag 351 The Base Authentication Tag field is computed using the base tag- 352 generation function as follows. It can only be computed after all of 353 the other fields have been set. The authenticated input consists of 354 the following elements, in order: 356 the SRTCP authenticated portion, 358 a string of zero bits whose length exactly matches that of the 359 Base Authentication Tag field, 361 the Encrypted Master Key field, 363 the Rollover Counter field, 365 the Initial Sequence Number field, and 367 the Security Parameter Index field. 369 Implementation note: the string of zero bits is included in the 370 authenticated input in order to allow implementations to compute 371 the base authentication tag using a single pass of the base 372 authentication function. Implementations MAY write zeros into the 373 Base Authentication Tag field prior to computing that function, on 374 the sending side. 376 2.2.2. Inbound (Tag Verification) 378 The EKT verification function proceeds as follows (see Figure 2), or 379 uses an equivalent set of steps. Recall that the verification 380 function is a component of SRTCP processing. When a packet does not 381 pass the verification step, the function indicates this fact to the 382 SRTCP packet processing function when it returns control to that 383 function. 385 1. The Security Parameter Index field is checked to determine which 386 EKT parameter set should be used when processing the packet. If 387 multiple parameter sets been defined for the SRTP session, then 388 the one that is associated with the Security Parameter Index 389 value that matches the Security Parameter Index field in the 390 packet is used. This parameter set is called the matching 391 parameter set below. If there is no matching SPI, then the 392 verification function MUST return an indication of authentication 393 failure, and the steps described below are not performed. 395 2. The Encrypted Master Key field is decrypted using the EKT 396 cipher's decryption function. That field is used as the 397 ciphertext input, and the Key Encrypting Key in the matching 398 parameter set is used as the decryption key. The decryption 399 process is detailed in Section 2.3. The plaintext resulting from 400 this decryption is provisionally accepted as the SRTP master key 401 corresponding to the SSRC in the packet. If an MKI is present in 402 the packet, then the provisional key corresponds to the 403 particular SSRC and MKI combination. A provisional key MUST be 404 used only to process one single packet. A provisional SRTCP 405 authentication key is generated from the provisional master key, 406 and the SRTP master salt from the matching parameter set, using 407 the SRTP key derivation algorithm (see Section 4.3 of [RFC3711]). 409 3. An authentication check is performed on the packet, using the 410 provisional SRTCP authentication key. This key is provided to 411 the base SRTCP authentication function (see Figure 2), which is 412 evaluated as described in Section 2.2.1.1. If the Base 413 Authentication Tag field matches the tag computed by the base 414 authentication function, then the packet passes the check. 416 Implementation note: an SRTP receiver MAY copy the Base 417 Authentication Tag field into temporary storage, then write 418 zeros into that field, prior to computing the base 419 authentication tag value. This step allows the base 420 authentication function to be computed in a single pass. 422 4. If the base authentication check using the provisional key fails, 423 then the provisional key MUST be discarded and it MUST NOT affect 424 any subsequent processing. The verification function MUST return 425 an indication of authentication failure, and the steps described 426 below are not performed. 428 5. Otherwise, if the base authentication check is passed, the 429 provisional key is also accepted as the SRTP master key 430 corresponding to the SRTP source that sent the packet. If an MKI 431 is present in the packet, then the master key corresponds to the 432 particular SSRC and MKI combination. If there is no SRTP crypto 433 context corresponding to the SSRC in the packet, then a new 434 crypto context is created. The rollover counter in the context 435 is set to the value of the Rollover Counter field. 437 6. If the Initial Sequence Number field is nonzero, then the initial 438 sequence number for the SRTP master key is set to the packet 439 index created by appending that field to the current rollover 440 counter and treating the result as a 48-bit unsigned integer. 441 The initial sequence number for the master key is equivalent to 442 the "From" value of the < From, To > pair of indices (Section 443 8.1.1 of [RFC3711]) that can be associated with a master key. 445 7. The newly accepted SRTP master key, the SRTP parameters from the 446 matching parameter set, the SSRC from the packet, and the MKI 447 from the packet, if one is present, are stored in the crypto 448 context associated with the SRTP source. The SRTP Key Derivation 449 algorithm is run in order to compute the SRTP encryption and 450 authentication keys, and those keys are stored for use in SRTP 451 processing of inbound packets. 453 8. The verification function then returns an indication that the 454 packet passed the verification. 456 Implementation note: the value of the Encrypted Master Key 457 field is identical in successive packets protected by the same 458 KEK and SRTP master key. This value MAY be cached by an SRTP 459 receiver to minimize computational effort, by allowing it to 460 recognize when the SRTP master key is unchanged, and thus 461 avoid repeating Steps 2, 6, and 7. 463 +------- Encrypted Master Key 464 | 465 v 466 +------------+ 467 | Decryption | 468 | Function |<-------------------------- Key Encrypting Key 469 +------------+ 470 | +----------------+ EKT 471 +--------+-- provisional ---->| SRTCP |<-- master 472 | master key | Key Derivation | salt 473 | +----------------+ 474 | | 475 | provisional SRTCP authentication key 476 | | 477 | v 478 | +----------------+ 479 | authenticated portion --> | Base SRTCP | 480 | authentication tag -----> | Verification | 481 | +----------------+ 482 | | 483 | +----------------+ +---+ 484 | | return FAIL |<- FAIL -| ? | 485 | +----------------+ +---+ 486 | | 487 | +----------------+ | 488 +------->| set master key,|<- PASS ---+ 489 | ROC, and MKI | 490 +----------------+ 491 | 492 v 493 +----------------+ 494 | return PASS | 495 +----------------+ 497 Figure 2: EKT inbound processing. 499 2.3. Ciphers 501 EKT uses a cipher to encrypt the SRTP master keys. We first specify 502 the interface to the cipher, in order to abstract the interface away 503 from the details of that function. We then define the cipher that is 504 used in EKT by default. This cipher MUST be implemented, but another 505 cipher that conforms to this interface MAY be used, in which case its 506 use MUST be coordinated by external means (e.g. call signaling). 508 An EKT cipher consists of an encryption function and a decryption 509 function. The encryption function E(K, P) takes the following 510 inputs: 512 a secret key K with a length of L bytes, and 514 a plaintext value P with a length of M bytes. 516 The encryption function returns a ciphertext value C whose length is 517 N bytes, where N is at least M. The decryption function D(K, C) takes 518 the following inputs: 520 a secret key K with a length of L bytes, and 522 a ciphertext value C with a length of N bytes. 524 The decryption function returns a plaintext value P that is M bytes 525 long. These functions have the property that D(K, E(K, P)) = P for 526 all values of K and P. Each cipher also has a limit T on the number 527 of times that it can be used with any fixed key value. For each key, 528 the encryption function MUST NOT be invoked on more than T distinct 529 values of P, and the decryption function MUST NOT be invoked on more 530 than T distinct values of C. 532 An EKT cipher MUST resist attacks in which both ciphertexts and 533 plaintexts can be adaptively chosen. For each randomly chosen key, 534 the encryption and decryption functions cannot be distinguished from 535 a random permutation and its inverse with non-negligible advantage. 536 This must be true even for adversaries that can query both the 537 encryption and decryption functions adaptively. The advantage is 538 defined as the difference between the probability that the adversary 539 will identify the cipher as such and the probability that the 540 adversary will identify the random permutation as the cipher, when 541 each case is equally likely. 543 2.3.1. The Default Cipher 545 The default cipher is the Advanced Encryption Standard (AES) 546 [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its 547 parameters are fixed at L=16, M=16, and T=2^48. Note that M matches 548 the size of the SRTP master keys used by the default SRTP key 549 derivation function; if an SRTP cipher with a different SRTP master 550 key length is to be used with EKT, then another EKT cipher must be 551 used. ECB is the simplest mode of operation of a block cipher, in 552 which the block cipher is used in its raw form. 554 2.3.2. The AES Key Wrap Cipher 556 The AES Key Wrap [RFC3394] defines a cipher that can be used with 557 plaintexts larger than 16 bytes in length. It requires a plaintext 558 length M that is a multiple of eight bytes, and it returns a 559 ciphertext with a length of N = M + 8 bytes. It can be used with key 560 sizes of L = 16, 24, and 32. The key size determines the length of 561 the AES key used by the Key Wrap algorithm. With this cipher, 562 T=2^48. 564 2.3.3. Other EKT Ciphers 566 Other specification MAY extend this one by defining other EKT 567 ciphers. This section defines how those ciphers interact with this 568 specification. 570 An EKT cipher determines how the Encrypted Master Key field is 571 written, and how it is processed when it is read. This field is 572 opaque to the other aspects of EKT processing. EKT ciphers are free 573 to use this field in any way, but they SHOULD NOT use other EKT or 574 SRTP fields as an input. The values of the parameters L, M, N, and T 575 MUST be defined by each EKT cipher, and those values MUST be 576 inferable from the EKT parameter set. 578 2.4. Synchronizing Operation 580 EKT is transported over SRTCP, but some of the information that it 581 conveys is used for SRTP processing; some elements of the EKT 582 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 583 packets can be lost and both SRTP and SRTCP packets may be delivered 584 out-of-order. This can lead to various race conditions, which we 585 review below. 587 When joining an SRTP session, SRTP packets may be received before any 588 SRTCP (EKT) packets, which implies the crypto context has not been 589 established, unless other external signaling mechanism has done so. 590 Rather than automatically discarding such SRTP packets, the receiver 591 MAY want to provisionally place them in a jitter buffer and delay 592 discarding them until playout time. 594 When an SRTP source using EKT performs a rekeying operation, there is 595 a race between the actual rekeying signaled via SRTCP and the SRTP 596 packets secured by the new keying material. If the SRTP packets are 597 received first, they will fail authentication; alternatively, if 598 authentication is not being used, they will decrypt to unintelligible 599 random-looking plaintext. (Note, however, that [RFC3711] says that 600 SRTP "SHOULD NOT be used without message authentication".) In order 601 to address this problem, the rekeying event can be sent before 602 packets using the new SRTP master key are sent (by use of the ISN 603 field). Another solution involves using an MKI at the expense of 604 added overhead in each SRTP packet. Alternatively, receivers MAY 605 want to delay discarding packets from known SSRCs that fail 606 authentication in anticipation of receiving a rekeying event via EKT 607 (SRTCP) shortly. 609 The ROC signaled via EKT over SRTCP may be off by one when it is 610 received by the other party(ies) in the session. In order to deal 611 with this, receivers should simply follow the SRTP packet index 612 estimation procedures defined in [SRTP] Section 3.3.1. 614 2.5. Timing and Reliability Consideration 616 SRTCP communicates the master key and ROC for the SRTP session. 617 Thus, as explained above, if SRTP packets are received prior to the 618 corresponding SRTCP (EKT) packet, a race condition occurs. From an 619 EKT point of view, it is therefore desirable for an SRTP sender to 620 send an SRTCP packet as soon as possible, and in no case any later 621 than when the initial SRTP packet is sent. SRTCP however MUST obey 622 the timing rules associated with the profile under which it runs 623 (e.g. RTP/SAVP or RTP/SAVPF). Subject to that constraint, SRTP 624 senders SHOULD send an SRTCP packet as soon as possible after joining 625 a session. Note that there is no need for SRTP receivers to do so. 626 Also note, that per RFC 3550, Section 6.2, it is permissible to send 627 a compound RTCP packet immediately after joining a unicast session 628 (but not a multicast session). 630 SRTCP is not reliable and hence SRTCP packets may be lost. This is 631 obviously a problem for endpoints joining an SRTP session and 632 receiving SRTP traffic (as opposed to SRTCP), or for endpoints 633 receiving SRTP traffic following a rekeying event. To reduce the 634 impact of lost packets, SRTP senders SHOULD send SRTCP packets as 635 often as allowed by the profile under which they operate. 637 3. Interworking with Other SRTP Key Management Systems 639 3.1. Security Descriptions 641 Today, Security Descriptions [RFC4568] is used for distributing SRTP 642 keys in several different IP PBX systems and is expected to be used 643 by 3GPP's Long Term Evolution (LTE). The IP PBX systems are 644 typically used within a single enterprise, and LTE is used within the 645 confines of a mobile operator's network. A Session Border Controller 646 is a reasonable solution to interwork between Security Descriptions 647 in one network and DTLS-SRTP in another network. For example, a 648 mobile operator (or an Enterprise) could operate Security 649 Descriptions within their network and DTLS-SRTP towards the Internet. 651 However, due to the way Security Descriptions and DTLS-SRTP manage 652 their SRTP keys, such an SBC has to authenticate, decrypt, re- 653 encrypt, and re-authenticate the SRTP (and SRTCP) packets in one 654 direction, as shown in Figure 3, below. This is computationally 655 expensive. 657 RFC4568 endpoint SBC 658 DTLS-SRTP endpoint 659 | | | 660 1. |---key=A------------->| | 661 2. | |<-DTLS-SRTP handshake->| 662 3. |<--key=B--------------| | 663 4. | |<--SRTP, encrypted w/B-| 664 5. |<-SRTP, encrypted w/B-| | 665 6. |-SRTP, encrypted w/A->| | 666 7. | (decrypt, re-encrypt) | 667 8. | |-SRTP, encrypted w/C-->| 668 | | | 670 Figure 3: Interworking Security Descriptions and DTLS-SRTP 672 The message flow is as follows (similar steps occur with SRTCP): 674 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 675 key to the SBC, using a=crypto in its SDP. 677 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 678 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 679 B) and to the DTLS-SRTP endpoint (key C). 681 3. The SBC communicates the SRTP encryption key (key B) to the 682 Security Descriptions endpoint (using a=crypto). (There is no 683 way, with DTLS-SRTP, to communicate the Security Descriptions key 684 to the DTLS-SRTP key endpoint.) 686 4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 687 B. This is received by the SBC. 689 5. The received SRTP packet is simply forwarded; the SBC does not 690 need to do anything with this packet as its key (key B) was 691 already communicated in step 3. 693 6. The Security Descriptions endpoint sends an SRTP packet, 694 encrypted with its key A. 696 7. The SBC has to authenticate and decrypt the SRTP packet (using 697 key A), and re-encrypt it and generate an HMAC (using key C). 699 8. The SBC sends the new SRTP packet. 701 If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the 702 computationally expensive operation so the SBC does not need not 703 perform any per-packet operations on the SRTP (or SRTCP) packets in 704 either direction. With EKT the SBC can simply forward the SRTP (and 705 SRTCP) packets in both directions without per-packet HMAC or 706 cryptographic operations. 708 To accomplish this interworking, DTLS-SRTP EKT must be supported on 709 the DTLS-SRTP endpoint, which allows the SBC to transport the 710 Security Description key to the EKT endpoint and send the DTLS-SRTP 711 key to the Security Descriptions endpoint. This works equally well 712 for both incoming and outgoing calls. An abbreviated message flow is 713 shown in Figure 4, below. 715 RFC4568 endpoint SBC 716 DTLS-SRTP endpoint 717 | | | 718 1. |---key=A------------->| | 719 2. | |<-DTLS-SRTP handshake->| 720 3. |<--key=B--------------| | 721 4. | |--new_srtp_key:A------>| 722 5. | |<--SRTP, encrypted w/B-| 723 5. |<-SRTP, encrypted w/B-| | 724 6. |-SRTP, encrypted w/A->| | 725 7. | |-SRTP, encrypted w/A-->| 726 | | | 728 Figure 4: Interworking Security Descriptions and EKT 730 The message flow is as follows (similar steps occur with SRTCP): 732 1. Security Descriptions endpoint discloses its SRTP key to the SBC 733 (a=crypto). 735 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 736 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 737 B) and to the DTLS-SRTP endpoint (key C). 739 3. The SBC communicates the SRTP encryption key (key B) to the 740 Security Descriptions endpoint. 742 4. The SBC uses the EKT to indicate that SRTP packets will be 743 encrypted with 'key A' towards the DTLS-SRTP endpoint. 745 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 746 B. This is received by the SBC. 748 6. The received SRTP packet is simply forwarded; the SBC does not 749 need to do anything with this packet as its key (key B) was 750 communicated in step 3. 752 7. The Security Descriptions endpoint sends an SRTP packet, 753 encrypted with its key A. 755 8. The received SRTP packet is simply forwarded; the SBC does not 756 need to do anything with this packet as its key (key A) was 757 communicated in step 4. 759 4. EKT and SDP Security Descriptions 761 The SDP Security Descriptions (SDES) [RFC4568] specification defines 762 a generic framework for negotiating security parameters for media 763 streams negotiated via the Session Description Protocol by use of a 764 new SDP "crypto" attribute and the Offer/Answer procedures defined in 765 [RFC3264]. In addition to the general framework, SDES also defines 766 how to use that framework specifically to negotiate security 767 parameters for Secure RTP. Below, we first provide a brief recap of 768 the crypto attribute when used for SRTP and we then explain how it is 769 complementary to EKT. In the rest of this Section, we provide 770 extensions to the crypto attribute and associated offer/answer 771 procedures to define its use with EKT. 773 4.1. SDP Security Descriptions Recap 775 The SRTP crypto attribute defined for SDP Security Descriptions 776 contains a tag followed by three types of parameters (refer to 777 [RFC4568] for details): 779 Crypto-suite. Identifies the encryption and authentication 780 transform 782 Key parameters. SRTP keying material and parameters. 784 Session parameters. Additional (optional) SRTP parameters such as 785 Key Derivation Rate, Forward Error Correction Order, use of 786 unencrypted SRTP, etc. 788 The crypto attributes in the example SDP in Figure 5 illustrate these 789 parameters. 791 v=0 792 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 793 s=SRTP Discussion 794 i=A discussion of Secure RTP 795 u=http://www.example.com/seminars/srtp.pdf 796 e=marge@example.com (Marge Simpson) 797 c=IN IP4 192.0.2.12 798 t=2873397496 2873404696 799 m=audio 49170 RTP/SAVP 0 800 a=crypto:1 AES_CM_128_HMAC_SHA1_80 801 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 802 FEC_ORDER=FEC_SRTP 803 a=crypto:2 F8_128_HMAC_SHA1_80 804 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 805 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 806 FEC_ORDER=FEC_SRTP 808 Figure 5: SDP Security Descriptions example. Line breaks are 809 included for formatting purposes only. 811 The first crypto attribute has the tag "1" and uses the crypto-suite 812 "AES_CM_128_HMAC_SHA1_80". The "inline" parameter provides the SRTP 813 master key and salt, the master key lifetime (number of packets), and 814 the (optional) Master Key Identifier (MKI) whose value is "1" and has 815 a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER 816 session parameter indicates the order of Forward Error Correction 817 used (FEC is applied before SRTP processing by the sender of the SRTP 818 media). 820 The second crypto attribute has the tag "2" and uses the crypto-suite 821 "F8_128_HMAC_SHA1_80". It includes two SRTP master keys and 822 associated salts. The first one is used with the MKI value 1, 823 whereas the second one is used with the MKI value 2. Finally, the 824 FEC_ORDER session parameter indicates the order of Forward Error 825 Correction used. 827 4.2. Relationship between EKT and SDP Security Descriptions 829 SDP Security Descriptions [RFC4568] define a generic framework for 830 negotiating security parameters for media streams negotiated via the 831 Session Description Protocol by use of the Offer/Answer procedures 832 defined in [RFC3264]. In addition to the general framework, SDP 833 Security Descriptions (SDES) also defines how to use it specifically 834 to negotiate security parameters for Secure RTP. 836 EKT and SDESC are complementary. SDP Security Descriptions can 837 negotiate several of the SRTP security parameters (e.g. cipher and 838 use of Master Key Identifier/MKI) as well as SRTP master keys. SDP 839 Security Descriptions however does not negotiate SSRCs and their 840 associated Rollover Counter (ROC). Instead, SDES relies on a so- 841 called "late binding", where a newly observed SSRC will have its 842 crypto context initialized to a ROC value of zero. Clearly, this 843 does not work for participants joining an SRTP session that has been 844 established for a while and hence has a non-zero ROC. It is 845 impossible to use SDES to join an SRTP session that is already in 846 progress. In this case, EKT on the endpoint running SDP Security can 847 provide the additional signaling necessary to communicate the ROC 848 (Section 6.4.1 of [RFC4568]). The use of EKT solves this problem by 849 communicating the ROC associated with the SSRC in the media plane. 851 SDP Security Descriptions negotiates different SRTP master keys in 852 the send and receive direction. The offer contains the master key 853 used by the offerer to send media, and the answer contains the master 854 key used by the answerer to send media. Consequently, if media is 855 received by the offerer prior to the answer being received, the 856 offerer does not know the master key being used. Use of SDP security 857 preconditions can solve this problem, however it requires an 858 additional round-trip as well as a more complicated state machine. 859 EKT solves this problem by simply sending the master key used in the 860 media plane thereby avoiding the need for security preconditions. 862 If multiple crypto-suites were offered, the offerer also will not 863 know which of the crypto-suites offered was selected until the answer 864 is received. EKT solves this problem by using a correlator, the 865 Security Parameter Index (SPI), which uniquely identifies each crypto 866 attribute in the offer. 868 One of the primary call signaling protocols using offer/answer is the 869 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 870 message to initiate a media session and typically includes an offer 871 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 872 which potentially can lead to multiple answers being received. SDP 873 Security Descriptions however does not properly support this 874 scenario, mainly because SDP and RTP/RTCP does not contain sufficient 875 information to allow for correlation of an incoming RTP/RTCP packet 876 with a particular answer SDP. Note that extensions providing this 877 correlation do exist, e.g. Interactive Connectivity Establishment 878 (ICE). SDP Security Descriptions addresses this point-to-multipoint 879 problem by moving each answer to a separate RTP transport address 880 thereby turning a point-to-multipoint scenario into multiple point- 881 to-point scenarios. There are however significant disadvantages to 882 doing so. As long as the crypto attribute in the answer does not 883 contain any declarative parameters that differ from those in the 884 offer, EKT solves this problem by use of the SPI correlator and 885 communication of the answerer's SRTP master key in EKT. 887 As can be seen from the above, the combination of EKT and SDES 888 provides a better solution to SRTP negotiation for offer/answer than 889 either of them alone. SDES negotiates the various SRTP crypto 890 parameters (which EKT does not), whereas EKT addresses the 891 shortcomings of SDES. 893 4.3. Overview of Combined EKT and SDP Security Description Operation 895 We define three session extension parameters to SDES to communicate 896 the EKT cipher, EKT key, and Security Parameter Index to the peer. 897 The original SDES parameters are used as defined in [RFC4568], 898 however the procedures associated with the SRTP master key differ 899 slightly, since both SDES and EKT communicate an SRTP master key. In 900 particular, the SRTP master key communicated via SDES is used only if 901 there is currently no crypto context established for the SSRC in 902 question. This will be the case when an entity has received only the 903 offer or answer, but has yet to receive a valid EKT message from the 904 peer. Once a valid EKT message is received for the SSRC, the crypto 905 context is initialized accordingly, and the SRTP master key will then 906 be derived from the EKT message. Subsequent offer/answer exchanges 907 do not change this: The most recent SRTP master key negotiated via 908 EKT will be used, or, if none is available for the SSRC in question, 909 the most recent SRTP master key negotiated via offer/answer will be 910 used. Note that with these rules, once a valid EKT message has been 911 received for a given SSRC, rekeying for that SSRC can only be done 912 via EKT. The associated SRTP crypto parameters however can be 913 changed via SDES. 915 4.4. EKT Extensions to SDP Security Descriptions 917 In order to use EKT and SDES in conjunction, we now define the 918 following new SDES session parameters, each of which MUST NOT appear 919 more than once in a given crypto attribute: 921 EKT_Cipher The EKT cipher used to encrypt the SRTP Master Key 923 EKT_Key The EKT key used to encrypt the SRTP Master Key 925 EKT_SPI The EKT Security Parameter Index 927 Below, we provide additional detail on each of these attributes. 929 4.4.1. EKT_Cipher 931 The (optional) EKT_Cipher parameter parameter defines the EKT cipher 932 used to encrypt the EKT key with in SRTCP packets. The default value 933 is "AES_128" in accordance with Section 2.3.1. For the AES Key Wrap 934 cipher (see Section 2.3.2, the values "AESKW_128", "AESKW_192", and 935 "AESKW_256" are defined for values of L=16, 24, and 32 respectively. 936 In the Offer/Answer model, the EKT_Cipher parameter is a negotiated 937 parameter. 939 4.4.2. EKT_Key 941 The (mandatory) EKT_Key parameter is the key K used to encrypt the 942 SRTP Master Key in SRTCP packets. The value is base64 encoded (see 943 [RFC3548], Section 3). When base64 decoding the key, padding 944 characters (i.e., one or two "=" at the end of the base64 encoded 945 data) are discarded (see [RFC3548] for details). Base64 encoding 946 assumes that the base64 encoding input is an integral number of 947 octets. If a given EKT cipher requires the use of a key with a 948 length that is not an integral number of octets, said cipher MUST 949 define a padding scheme that results in the base64 input being an 950 integral number of octets. For example, if the length defined was 951 250 bits, then 6 padding bits would be needed, which could be defined 952 to be the last 6 bits in a 256 bit input. In the Offer/Answer model, 953 the EKT_Key parameter is a negotiated parameter. 955 4.4.3. EKT_SPI 957 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 958 It is encoded as an ASCII string representing the hexadecimal value 959 of the Security Parameter Index. The SPI identifies the *offer* 960 crypto attribute (including the EKT Key and Cipher) being used for 961 the associated SRTP session. A crypto attribute corresponds to an 962 EKT Parameter Set and hence the SPI effectively identifies a 963 particular EKT parameter set. Note that the scope of the SPI is the 964 SRTP session, which may or may not be limited to the scope of the 965 associated SIP dialog. In particular, if one of the participants in 966 an SRTP session is an SRTP translator, the scope of the SRTP session 967 is not limited to the scope of a single SIP dialog. However, if all 968 of the participants in the session are endpoints or mixers, the scope 969 of the SRTP session will correspond to a single SIP dialog. In the 970 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 972 4.5. Offer/Answer Procedures 974 In this section, we provide the offer/answer procedures associated 975 with use of the three new SDES parameters defined in Section 976 Section 4.4. Since SDES is defined only for unicast streams, we 977 provide only offer/answer procedures for unicast streams here as 978 well. 980 4.5.1. Generating the Initial Offer - Unicast Streams 982 When the initial offer is generated, the offerer MUST follow the 983 steps defined in [RFC4568] Section 7.1.1 as well as the following 984 steps. 986 For each unicast media line using SDES and where use of EKT is 987 desired, the offerer MUST include one EKT_Key parameter and one 988 EKT_SPI parameter in at least one "crypto" attribute (see [RFC4568]). 989 The EKT_SPI parameter serves to identify the EKT parameter set used 990 for a particular SRTCP packet. Consequently, within a single media 991 line, a given EKT_SPI value MUST NOT be used with multiple crypto 992 attributes. Note that the EKT parameter set to use for the session 993 is not yet established at this point; each offered crypto attribute 994 contains a candidate EKT parameter set. Furthermore, if the media 995 line refers to an existing SRTP session, then any SPI values used for 996 EKT parameter sets in that session MUST NOT be remapped to any 997 different EKT parameter sets. When an offer describes an SRTP 998 session that is already in progress, the offer SHOULD use an EKT 999 parameter set (incl. EKT_SPI and EKT_KEY) that is already in use. 1001 If an EKT_Cipher other than the default cipher is to be used, then 1002 the EKT_Cipher parameter MUST be included as well. 1004 If a given crypto attribute includes more than one set of SRTP key 1005 parameters (SRTP master key, salt, lifetime, MKI), they MUST all use 1006 the same salt. (EKT requires a single shared salt between all the 1007 participants in the direct SRTP session). 1009 Important Note: The scope of the offer/answer exchange is the SIP 1010 dialog(s) established as a result of the INVITE, however the scope of 1011 EKT is the direct SRTP session, i.e. all the participants that are 1012 able to receive SRTP and SRTCP packets directly. If an SRTP session 1013 spans multiple SIP dialogs, the EKT parameter sets MUST be 1014 synchronized between all the SIP dialogs where SRTP and SRTCP packets 1015 can be exchanged. In the case where the SIP entity operates as an 1016 RTP mixer (and hence re-originates SRTP and SRTCP packets with its 1017 own SSRC), this is not an issue, unless the mixer receives traffic 1018 from the various participants on the same destination IP address and 1019 port, in which case further coordination of SPI values and crypto 1020 parameters may be needed between the SIP dialogs (note that SIP 1021 forking with multiple early media senders is an example of this). 1022 However if it operates as an RTP translator, synchronized negotiation 1023 of the EKT parameter sets on *all* the involved SIP dialogs will be 1024 needed. This is non-trivial in a variety of use cases, and hence use 1025 of the combined SDES/EKT mechanism with RTP translators should be 1026 considered very carefully. It should be noted, that use of SRTP with 1027 RTP translators in general should be considered very carefully as 1028 well. 1030 The EKT session parameters can either be included as optional or 1031 mandatory parameters, however within a given crypto attribute, they 1032 MUST all be either optional or mandatory. 1034 4.5.2. Generating the Initial Answer - Unicast Streams 1036 When the initial answer is generated, the answerer MUST follow the 1037 steps defined in [RFC4568] Section 7.1.2 as well as the following 1038 steps. 1040 For each unicast media line using SDES, the answerer examines the 1041 associated crypto attribute(s) for the presence of EKT parameters. 1042 If mandatory EKT parameters are included with a "crypto" attribute, 1043 the answerer MUST support those parameters in order to accept that 1044 offered crypto attribute. If optional EKT parameters are included 1045 instead, the answerer MAY accept the offered crypto attribute without 1046 using EKT. However, doing so will prevent the offerer from 1047 processing any packets received before the answer. If neither 1048 optional nor mandatory EKT parameters are included with a crypto 1049 attribute, and that crypto attribute is accepted in the answer, EKT 1050 MUST NOT be used. If a given a crypto attribute includes a mixture 1051 of optional and mandatory EKT parameters, or an incomplete set of 1052 mandatory EKT parameters, that crypto attribute MUST be considered 1053 invalid. 1055 When EKT is used with SDES, the offerer and answerer MUST use the 1056 same SRTP salt. Thus, the SRTP key parameter(s) in the answer crypto 1057 attribute MUST use the same salt as the one accepted from the offer. 1059 When the answerer accepts the offered media line and EKT is being 1060 used, the crypto attribute included in the answer MUST include the 1061 same EKT parameter values as found in the accepted crypto attribute 1062 from the offer (however, if the default EKT cipher is being used, it 1063 may be omitted). Furthermore, the EKT parameters included MUST be 1064 mandatory (i.e. no "-" prefix). 1066 Acceptance of a crypto attribute with EKT parameters leads to 1067 establishment of the EKT parameter set for the corresponding SRTP 1068 session. Consequently, the answerer MUST send packets in accordance 1069 with that particular EKT parameter set only. If the answerer wants 1070 to enable the offerer to process SRTP packets received by the offerer 1071 before it receives the answer, the answerer MUST NOT include any 1072 declarative session parameters that either were not present in the 1073 offered crypto attribute, or were present but with a different value. 1074 Otherwise, the offerer's view of the EKT parameter set would differ 1075 from the answerer's until the answer is received. Similarly, unless 1076 the offerer and answerer has other means for correlating an answer 1077 with a particular SRTP session, the answer SHOULD NOT include any 1078 declarative session parameters that either were not present in the 1079 offered crypto attribute, or were present but with a different value. 1080 If this recommendation is not followed and the offerer receives 1081 multiple answers (e.g. due to SIP forking), the offerer may not be 1082 able to process incoming media stream packets correctly. 1084 4.5.3. Processing of the Initial Answer - Unicast Streams 1086 When the offerer receives the answer, it MUST perform the steps in 1087 [RFC4568] Section 7.1.3 as well as the following steps for each SRTP 1088 media stream it offered with one or more crypto lines containing EKT 1089 parameters in it. 1091 If the answer crypto line contains EKT parameters, and the 1092 corresponding crypto line from the offer contained the same EKT 1093 values, use of EKT has been negotiated successfully and MUST be used 1094 for the media stream. When determining whether the values match, 1095 optional and mandatory parameters MUST be considered equal. 1096 Furthermore, if the default EKT cipher is being used, it MAY be 1097 either present or absent in the offer and/or answer. 1099 If the answer crypto line does not contain EKT parameters, then EKT 1100 MUST NOT be used for the corresponding SRTP session. Note that per 1101 [RFC4568] Section 5.1.3, if the accepted crypto attribute contained 1102 mandatory EKT parameters in the offer, and the crypto attribute in 1103 the answer does not contain EKT parameters, then negotiation has 1104 failed. 1106 If the answer crypto line contains EKT parameters but the 1107 corresponding offered crypto line did not, or if the parameters don't 1108 match or are invalid, then the offerer MUST consider the crypto line 1109 invalid (see [RFC4568] Section 7.1.3 for further operation). 1111 The EKT parameter set is established when the answer is received, 1112 however there are a couple of special cases to consider here. First 1113 of all, if an SRTCP packet is received prior to the answer, then the 1114 EKT parameter set is established provisionally based on the SPI 1115 included. Once the answer (which may include declarative session 1116 parameters) is received, the EKT parameter set is fully established. 1117 The second case involves receipt of multiple answers due to SIP 1118 forking. In this case, there will be multiple EKT parameter sets; 1119 one for each SRTP session. As mentioned earlier, reliable 1120 correlation of SIP dialogs to SRTP sessions requires extensions, and 1121 hence if one or more of the answers include declarative session 1122 parameters, it may be difficult to fully establish the EKT parameter 1123 set for each SRTP session. In the absence of a specific correlation 1124 mechanism, it is RECOMMENDED, that such correlation be done based on 1125 the signaled receive IP-address in the SDP and the observed source 1126 IP-address in incoming SRTP/SRTCP packets, and, if necessary, the 1127 signaled receive UDP port and the observed source UDP port. 1129 4.6. SRTP-Specific Use Outside Offer/Answer 1131 SDES use for SRTP is not defined outside offer/answer and hence 1132 neither is SDES with EKT. 1134 4.7. Modifying the Session 1136 When a media stream using the SRTP security descriptions has been 1137 established, and a new offer/answer exchange is performed, the 1138 offerer and answerer MUST follow the steps in [RFC4568] Section 7.1.4 1139 as well as the following steps. SDES allows for all parameters of 1140 the session to be modified, and the EKT session parameters are no 1141 exception to that, however, there are a few additional rules to be 1142 adhered to when using EKT. 1144 It is permissible to start a session without the use of EKT, and then 1145 subsequently start using EKT, however the converse is not. Thus, 1146 once use of EKT has been negotiated on a particular media stream, EKT 1147 MUST continue to be used on that media stream in all subsequent 1148 offer/answer exchanges. 1150 The reason for this is that both SDES and EKT communicate the SRTP 1151 Master Key with EKT Master Keys taking precedence. Reverting back to 1152 an SDES controlled master key in a synchronized manner is difficult. 1154 Once EKT is being used, the salt for the direct SRTP session MUST NOT 1155 be changed. Thus, a new offer/answer which does not create a new 1156 SRTP session (e.g. because it reuses the same IP address and port) 1157 MUST use the same salt for all crypto attributes as is currently used 1158 for the direct SRTP session. 1160 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1161 value to a different EKT parameter set until 2^32 other mappings have 1162 been used within the SRTP session. In practice, this requirements is 1163 most easily met by using a monotonically increasing SPI value (modulo 1164 2^32 and starting with zero) per direct SRTP session. Note that a 1165 direct SRTP session may span multiple SIP dialogs, and in such cases 1166 coordination of SPI values across those SIP dialogs will be required. 1167 In the simple point-to-point unicast case without translators, the 1168 requirement simply applies within each media line in the SDP. In the 1169 point-to-multipoint case, the requirement applies across all the 1170 associated SIP dialogs. 1172 4.8. Backwards Compatibility Considerations 1174 Backwards compatibility can be achieved in a couple of ways. First 1175 of all, SDES allows for session parameters to be prefixed with "-" to 1176 indicate that they are optional. If the answerer does not support 1177 the EKT session parameters, such optional parameters will simply be 1178 ignored. When the answer is received, absence of the parameters will 1179 indicate that EKT is not being used. Receipt of SRTCP packets prior 1180 to receipt of such an answer will obviously be problematic (as is 1181 normally the case for SDES without EKT). 1183 Alternatively, SDES allows for multiple crypto lines to be included 1184 for a particular media stream. Thus, two crypto lines that differ in 1185 their use of EKT parameters (presence in one, absence in the other) 1186 can be used as a way to negotiate use of EKT. When the answer is 1187 received, the accepted crypto attribute will indicate whether EKT is 1188 being used or not. 1190 4.9. Grammar 1192 The Augmented Backus-Naur Form (ABNF) syntax [RFC4234] for the three 1193 new SDES session parameters is as in Figure 6. 1195 EKT_Cipher = "EKT_Cipher=" EKT_Cipher_Name 1196 EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128" 1197 ; "AESKW_192" and "AESKW_256" 1198 ; defined in this document. 1199 EKT_Key = 1*(base64) ; See Section 3 in RFC3548 1200 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1201 EKT_SPI = 4HEXDIG ; See RFC4234 1203 Figure 6: ABNF for the EKT session parameters. 1205 5. Use of EKT with DTLS-SRTP Key Transport 1207 DTLS-SRTP Key Transport (KTR) [I-D.wing-avt-dtls-srtp-key-transport] 1208 uses DTLS to securely transport SRTP keying material from one DTLS- 1209 SRTP peer to another, so the same SRTP keying material can be used by 1210 multiple DTLS-SRTP peers. This extension can be used to establish 1211 EKT keys. This combination of protocols is valuable because it 1212 combines the advantages of DTLS (strong authentication of the 1213 endpoint, flexibility) with the advantages of EKT (allowing secure 1214 multiparty RTP with loose coordination and efficient communication of 1215 per-source keys). 1217 5.1. DTLS-SRTP Extension 1219 This document adds a new TLS negotiated extension called "ekt". This 1220 adds a new TLS content type, EKT, and a new negotiated extension EKT. 1221 The negotiated extension MUST only be requested in conjunction with 1222 the "use_srtp" extension (Section 3.2 of [I-D.ietf-avt-dtls-srtp]). 1223 The DTLS server indicates its support for EKT by including "ekt" in 1224 its ServerHello message. If a DTLS client includes "ekt" in its 1225 ClientHello, but does not receive "ekt" in the ServerHello, the DTLS 1226 client MUST NOT send DTLS packets with the "ekt" content-type. 1228 Using the syntax described in DTLS [I-D.ietf-tls-rfc4347-bis], the 1229 following structures are used: 1231 enum { 1232 ekt_key(0), 1233 ekt_key_ack(1), 1234 ekt_key_error(254), 1235 (255) 1236 } SRTPKeyTransportType; 1238 struct { 1239 SRTPKeyTransportType keytrans_type; 1240 uint24 length; 1241 uint16 message_seq; 1242 uint24 fragment_offset; 1243 uint24 fragment_length; 1244 select (SRTPKeyTransportType) { 1245 case ekt_key: EKTkey; 1246 }; 1247 } KeyTransport; 1249 enum { 1250 AES_128(0), 1251 AESKW_128(1), 1252 AESKW_192(2), 1253 AESKW_256(3), 1254 } ektcipher; 1256 struct { 1257 ektcipher EKT_Cipher; 1258 uint EKT_Key_Value<1..256>; 1259 uint16 EKT_SPI; 1260 } EKTkey; 1262 Figure 7: Additional TLS Data Structure 1264 A message flow showing a DTLS client and DTLS server using the EKT 1265 extension. The first set of SRTP packets, if present, are encrypted 1266 using the normal DTLS-SRTP key deriviation function. The second set 1267 of SRTP packets, after the ekt_key message, can be encrypted using 1268 the EKT key. Reliability of the ekt_key is achieved _____ (how?). 1270 Client Server 1272 ClientHello + use_srtp + EKT 1273 --------> 1274 ServerHello + use_srtp + EKT 1275 Certificate* 1276 ServerKeyExchange* 1277 CertificateRequest* 1278 <-------- ServerHelloDone 1279 Certificate* 1280 ClientKeyExchange 1281 CertificateVerify* 1282 [ChangeCipherSpec] 1283 Finished --------> 1284 [ChangeCipherSpec] 1285 <-------- Finished 1286 SRTP packets <-------> SRTP packets 1287 ekt_key --------> 1288 SRTP packets <-------> SRTP packets 1290 Figure 8: Handshake Message Flow 1292 6. Use of EKT with MIKEY 1294 The advantages outlined in Section 1 are useful in some scenarios in 1295 which MIKEY is used to establish SRTP sessions. In this section, we 1296 briefly review MIKEY and related work, and discuss these scenarios. 1297 A n SRTP sender or a group controller can use MIKEY to establish a 1298 SRTP cryptographic context. This capability includes the 1299 distribution of the TEK or a TEK generation key (TGK) , security 1300 policy payload, crypto session bundle ID (CSB_ID), and a crypto 1301 session ID (CS_ID). The TEK directly maps to an SRTP master key, 1302 whereas the TGK is used along with the CSB_ID and a CS_ID to generate 1303 a TEK. The CS_ID can be used to generate multiple TEKs from a single 1304 TGK. For group communication, the sender or group controller sends 1305 the same TGK, CSB_ID, and CS_ID to all the members. For interactive 1306 conferencing, each sender distributes the same SRTP crypto context to 1307 the rest of the members. 1309 The MIKEY specification [RFC3830] suggests the use of unicast for 1310 rekeying. This method does not scale well to large groups or 1311 interactive groups. MIKEY also provides a way to provide ROC values 1312 to members when they join the group. It is desirable to not require 1313 the group controller to track the ROC values of each member. For 1314 example, in mobile and wireless environments, members may go in and 1315 out of coverage, and in those cases, key management based ROC 1316 synchronization is not reliable or sufficient. A better alternative 1317 to support ROC synchronization is to send ROC values via SRTP, as EKT 1318 does. A separate SRTP extension is being proposed [RFC4771] to 1319 include the ROC as part of a modified authentication tag. Unlike 1320 EKT, this extension uses SRTP and not SRTCP as its transport. A new 1321 MIKEY extension [RFC4563] specifies the use of MIKEY to update group 1322 keys via multicast or broadcast for 3GPP MBMS networks. 1324 The EKT extension of SRTP/SRTCP provides a combined solution for 1325 rekeying and ROC synchronization. It also offers several advantages. 1326 With EKT, an SRTP session participant can start a new SRTP source 1327 without coordinating with a group controller about the selection of 1328 keys or SSRC values. With EKT, SRTP can handle early media, since 1329 its SPI allows the receiver to identify the cryptographic keys and 1330 parameters used by the source. EKT also allows SRTP to work with SIP 1331 forking. 1333 MIKEY can readily be extended so that it can establish the EKT key, 1334 cipher and SPI values. 1336 6.1. EKT transform attribute mapping in MIKEY 1338 Interactive group communication using MIKEY currently requires each 1339 member to send its own TGK and SSRC information to the other members, 1340 resulting in O(n^2) MIKEY sessions. That is not desirable. With 1341 EKT, the conference organizer or only one of the members needs to 1342 distribute the EKT parameters to all the members. After that, each 1343 member can distribute its SRTP master key and ROC values using EKT. 1344 Cryptographic policy initially distributed via MIKEY will apply to 1345 all sessions. MIKEY specifies a security policy (SP) payload to 1346 negotiate or distribute SRTP security policy. Policy payload 1347 attributes include Session Encryption key length, Authentication 1348 algorithm, Session Authentication key length, Session Salt key 1349 length, SRTP PRF, Authentication tag length and other fields (see 1350 Section 6.10.1 of RFC 3830). 1352 For the EKT_Cipher parameter, we propose to specify a new SRTP Policy 1353 Type in the Security Policy (SP) payload of MIKEY (see Section 6.10 1354 of RFC 3830). The SP payload contains a number of Policy Param TLVs. 1355 We define Type = TBD: (will be requested from IANA) for EKT_Cipher. 1356 As with other payloads specifying cryptographic algorithms, we only 1357 specify Type and Values only. 1359 EKT_Cipher | Value 1360 ------------------- 1361 AES_128 | 0 1362 AESKW_128 | 1 1363 AESKW_192 | 2 1364 AESKW_256 | 3 1366 Figure 9: EKT_Cipher Table 1368 We propose to use the KEMAC payload to transport the two mandatory 1369 EKT parameters: EKT_Key and EKT_SPI MIKEY KEMAC payload, as specified 1370 in RFC 3830 carries the Traffic Encryption Key (TEK) or the TEK 1371 Generation Key (TGK). One or more TEKs or TGKs are carried in 1372 individual Key Data sub-payloads within the KEMAC payload. The KEMAC 1373 payload is encrypted as part of MIKEY. The Key Data sub- payload, 1374 specified in Section 6.13 of RFC 3830, has the following format: 1376 1 2 3 1377 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 ! Next Payload ! Type ! KV ! Key data len ! 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 ! Key data ~ 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 ! Salt len (optional) ! Salt data (optional) ~ 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 ! KV data (optional) ~ 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 Figure 10: Key Data Sub-Payload of MIKEY 1390 The Type field, 4 bits in length, indicates the type of key included 1391 in the payload. We define Type = TBD (will be requested from IANA) 1392 to indicate transport of EKT_Key. 1394 KV (4 bits): indicates the type of key validity period specified. 1395 KV=1 is currently specified as an SPI. We propose to use that value 1396 to indicate the KV_data contains the ETK_SPI. KV_data would be 16 1397 octets in length, but it is also possible to interpret the length 1398 from the 'Key data len' field. 1400 KV data MUST NOT be optional when KV = 1. 1402 7. Design Rationale 1404 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1405 "persistent transport-level identifier for an RTP source" since 1406 "receivers require the CNAME to keep track of each participant." EKT 1407 works in much the same way, using SRTCP to carry information needed 1408 for the proper processing of the SRTP traffic. 1410 With EKT, SRTP gains the ability to synchronize the creation of 1411 cryptographic contexts across all of the participants in a single 1412 session. This feature provides some, but not all, of the 1413 functionality that is present in IKE phase two (but not phase one). 1414 Importantly, EKT does not provide a way to indicate SRTP options. 1416 With EKT, external signaling mechanisms provide the SRTP options and 1417 the EKT Key, but need not provide the key(s) for each individual SRTP 1418 source. EKT provides a separation between the signaling mechanisms 1419 and the details of SRTP. The signaling system need not coordinate 1420 all SRTP streams, nor predict in advance how many streams will be 1421 present, nor communicate SRTP-level information (e.g. rollover 1422 counters) of current sessions. 1424 EKT is especially useful for multi-party sessions, and for the case 1425 where multiple RTP sessions are sent to the same destination 1426 transport address (see the example in the definition of "RTP session" 1427 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1428 multiple endpoints at the same time) can cause multiple RTP sessions 1429 to be sent to the same transport address, making EKT useful for use 1430 with SIP. 1432 EKT can also be used in conjunction with a scalable group-key 1433 management system like GDOI. Such a system provides a secure entity 1434 authentication method and a way to revoke group membership, both of 1435 which are out of scope of EKT. 1437 It is natural to use SRTCP to transport encrypted keying material for 1438 SRTP, as it provides a secure control channel for (S)RTP. However, 1439 there are several different places in SRTCP in which the encrypted 1440 SRTP master key and ROC could be conveyed. We briefly review some of 1441 the alternatives in order to motivate the particular choice used in 1442 this specification. One alternative is to have those values carried 1443 as a new SDES item or RTCP packet. This would require that the 1444 normal SRTCP encryption be turned off for the packets containing that 1445 SDES item, since on the receiver's side, SRTCP processing completes 1446 before the RTCP processing starts. This tension between encryption 1447 and the desire for RTCP privacy is highly undesirable. Additionally, 1448 this alternative makes SRTCP dependent upon the parsing of the RTCP 1449 compound packet, which adds complexity. It is simpler to carry the 1450 encrypted key in a new SRTCP field. One way to do this and to be 1451 backwards compatible with the existing specification is to define a 1452 new crypto function that incorporates the encrypted key. We define a 1453 new authentication transform because EKT relies on the normal SRTCP 1454 authentication to provide implicit authentication of the encrypted 1455 key. 1457 An SRTP packet containing an SSRC that has not been seen will be 1458 discarded. This practice may induce a burst of packet loss at the 1459 outset of an SRTP stream, due to the loss or reorder of the first 1460 SRTCP packet with the EKT containing the key and rollover counter for 1461 that stream. However, this practice matches the conservative RTP 1462 memory-allocation strategy; many existing applications accept this 1463 risk of initial packet loss. Alternatively, implementations may wish 1464 to delay discarding such packets for a short period of time as 1465 described in Section 2.4. 1467 When EKT is carried in SRTCP, it adds eight additional bytes to each 1468 SRTCP packet, plus the length of the Encrypted Master Key field. 1469 Using the SRTP and EKT defaults, the total overhead is 24 bytes. 1470 This overhead does not detract from the total bandwidth used by SRTP, 1471 since it is included in the RTCP bandwidth computation. However, it 1472 will cause the control protocol to issue packets less frequently. 1474 The main motivation for the use of the variable-length format is 1475 bandwidth conservation. If EKT is used of SRTP, there will be a loss 1476 of bandwidth due to the additional 24 bytes in each RTP packet. For 1477 some applications, this bandwidth loss is significant. 1479 8. RTP Transport 1481 EKT MAY be used over SRTP instead of SRTCP if the latter protocol is 1482 not available, though implementations SHOULD otherwise use SRTCP. If 1483 EKT over SRTP is used in an SRTP session in which SRTCP is available, 1484 then EKT MUST be used for both SRTP and SRTCP. 1486 The packet processing, state machine, and Authentication Tag format 1487 for EKT over SRTP is identical to that for EKT over SRTCP. 1489 EKT SHOULD be carried over RTCP. However, if it is carried over SRTP 1490 within a session, then it SHOULD NOT be carried over SRTCP in that 1491 session. 1493 9. Security Considerations 1495 With EKT, each SRTP sender and receiver can generate distinct SRTP 1496 master keys. This property avoids any security concern over the re- 1497 use of keys, by empowering the SRTP layer to create keys on demand. 1498 Note that the inputs of EKT are the same as for SRTP with key- 1499 sharing: a single key is provided to protect an entire SRTP session. 1500 However, EKT provides complete security, even in the absence of 1501 further out-of-band coordination of SSRCs, and even when SSRC values 1502 collide. 1504 EKT uses encrypted key transport with implicit authentication. A 1505 strong cipher is used to ensure the confidentiality of the master 1506 keys as they are transported. The authenticity of the master keys is 1507 ensured by the base authentication check, which uses the plaintext 1508 form of that key. If the base authentication function and the cipher 1509 cannot be defeated by a particular attacker, then that attacker will 1510 be unable to defeat the implicit authentication. 1512 In order to avoid potential security issues, the SRTP authentication 1513 tag length used by the base authentication method MUST be at least 1514 ten octets. 1516 10. IANA Considerations 1518 This section registers with IANA the following SRTP session 1519 parameters for SDP Security Descriptions [RFC4568]: 1521 EKT_KEY 1523 EKT_CIPHER 1525 EKT_SPI 1527 The definition of these parameters is provided in Section 4.4. 1529 We request the following IANA assignments from existing MIKEY IANA 1530 tables: 1532 From the "Key Data payload name spaces:" a value to indicate the 1533 type as the "EKT_Key." 1535 From the "SRTP" policy table name space, a new value to be 1536 assigned for "EKT_Cipher." 1538 Furthermore, we need a new table to be defined: 1540 EKT_Cipher | Value 1541 ------------------- 1542 AES_128 | 0 1543 AESKW_128 | 1 1544 AESKW_192 | 2 1545 AESKW_256 | 3 1547 Figure 11: EKT_Cipher Table 1549 11. Acknowledgements 1551 Thanks to Rob Raymond, Nermeen Ismail, and Kai Fischer for fruitful 1552 discussions and comments. 1554 12. References 1556 12.1. Normative References 1558 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1559 Information Processing Standard. 1561 [I-D.ietf-avt-dtls-srtp] 1562 McGrew, D. and E. Rescorla, "Datagram Transport Layer 1563 Security (DTLS) Extension to Establish Keys for Secure 1564 Real-time Transport Protocol (SRTP)", 1565 draft-ietf-avt-dtls-srtp-07 (work in progress), 1566 February 2009. 1568 [I-D.ietf-tls-rfc4347-bis] 1569 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1570 Security version 1.2", draft-ietf-tls-rfc4347-bis-02 (work 1571 in progress), March 2009. 1573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1574 Requirement Levels", BCP 14, RFC 2119, March 1997. 1576 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1577 A., Peterson, J., Sparks, R., Handley, M., and E. 1578 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1579 June 2002. 1581 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1582 with Session Description Protocol (SDP)", RFC 3264, 1583 June 2002. 1585 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1586 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1588 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1589 Encodings", RFC 3548, July 2003. 1591 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1592 Jacobson, "RTP: A Transport Protocol for Real-Time 1593 Applications", STD 64, RFC 3550, July 2003. 1595 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1596 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1597 RFC 3711, March 2004. 1599 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1600 Specifications: ABNF", RFC 4234, October 2005. 1602 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1603 Information Type for the General Extension Payload in 1604 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1606 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1607 Description Protocol (SDP) Security Descriptions for Media 1608 Streams", RFC 4568, July 2006. 1610 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1611 Transform Carrying Roll-Over Counter for the Secure Real- 1612 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1614 12.2. Informative References 1616 [I-D.wing-avt-dtls-srtp-key-transport] 1617 Wing, D., "DTLS-SRTP Key Transport (KTR)", 1618 draft-wing-avt-dtls-srtp-key-transport-03 (work in 1619 progress), March 2009. 1621 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1622 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1623 August 2004. 1625 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1626 Internet Protocol", RFC 4301, December 2005. 1628 Authors' Addresses 1630 David A. McGrew 1631 Cisco Systems, Inc. 1632 510 McCarthy Blvd. 1633 Milpitas, CA 95035 1634 US 1636 Phone: (408) 525 8651 1637 Email: mcgrew@cisco.com 1638 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1640 Flemming Andreason 1641 Cisco Systems, Inc. 1642 499 Thornall Street 1643 Edison, NJ 08837 1644 US 1646 Email: fandreas@cisco.com 1648 Dan Wing 1649 Cisco Systems, Inc. 1650 510 McCarthy Blvd. 1651 Milpitas, CA 95035 1652 US 1654 Phone: (408) 853 4197 1655 Email: dwing@cisco.com 1657 Lakshminath Dondeti 1658 QUALCOMM 1659 5775 Morehouse Drive 1660 San Diego, CA 92121 1661 US 1663 Email: ldondeti@qualcomm.com