idnits 2.17.1 draft-mcgrew-srtp-ekt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1314. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 655 has weird spacing: '... breaks are...' == Line 1251 has weird spacing: '...iptions for ...' == 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 (February 21, 2006) is 6639 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 581, but not defined == Unused Reference: 'RFC2234' is defined on line 1224, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYID' -- Possible downref: Non-RFC (?) normative reference: ref. 'RCC' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDES' -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 12 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 Expires: August 25, 2006 Cisco Systems, Inc. 5 L. Dondeti 6 QUALCOMM 7 February 21, 2006 9 Encrypted Key Transport for Secure RTP 10 draft-mcgrew-srtp-ekt-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 25, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 SRTP Encrypted Key Transport (EKT) is an extension to SRTP that 44 provides for the secure transport of SRTP master keys, Rollover 45 Counters, and other information, within SRTCP. This facility enables 46 SRTP to work for decentralized conferences with minimal control, and 47 to handle situations caused by SIP forking and early media. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Conventions Used In This Document . . . . . . . . . . . . 4 53 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 5 54 2.1 Authentication Tag Format . . . . . . . . . . . . . . . . 5 55 2.2 Packet Processing and State Machine . . . . . . . . . . . 7 56 2.2.1 Outbound (Tag Generation) . . . . . . . . . . . . . . 7 57 2.2.2 Inbound (Tag Verification) . . . . . . . . . . . . . . 8 58 2.3 Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 2.3.1 The Default Cipher . . . . . . . . . . . . . . . . . . 12 60 2.3.2 The AES Key Wrap Cipher . . . . . . . . . . . . . . . 12 61 2.3.3 Other EKT Ciphers . . . . . . . . . . . . . . . . . . 13 62 2.4 Synchronizing Operation . . . . . . . . . . . . . . . . . 13 63 2.5 Timing and Reliability Consideration . . . . . . . . . . . 14 64 3. EKT and SDP Security Descriptions . . . . . . . . . . . . . . 15 65 3.1 SDP Security Descriptions Recap . . . . . . . . . . . . . 15 66 3.2 Relationship between EKT and SDP Security Descriptions . . 16 67 3.3 Overview of Combined EKT and SDP Security Description 68 Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 69 3.4 EKT Extensions to SDP Security Descriptions . . . . . . . 18 70 3.4.1 EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 18 71 3.4.2 EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 19 72 3.4.3 EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 19 73 3.5 Offer/Answer Procedures . . . . . . . . . . . . . . . . . 19 74 3.5.1 Generating the Initial Offer - Unicast Streams . . . . 19 75 3.5.2 Generating the Initial Answer - Unicast Streams . . . 21 76 3.5.3 Processing of the Initial Answer - Unicast Streams . . 22 77 3.6 SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 22 78 3.7 Modifying the Session . . . . . . . . . . . . . . . . . . 23 79 3.8 Backwards Compatibility Considerations . . . . . . . . . . 23 80 3.9 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 4. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 25 82 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 26 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.1 Normative References . . . . . . . . . . . . . . . . . . . 31 88 9.2 Informative References . . . . . . . . . . . . . . . . . . 32 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 90 Intellectual Property and Copyright Statements . . . . . . . . 33 92 1. Introduction 94 RTP is designed to allow decentralized groups with minimal control to 95 establish sessions, e.g. for multimedia conferences. Unfortunately, 96 Secure RTP (SRTP, [RFC3711]) cannot be used in many minimal-control 97 scenarios, because it requires that SSRC values and other data be 98 coordinated among all of the participants in a session. For example, 99 if a participant joins a session that is already in progress, the 100 SRTP rollover counter (ROC) of each SRTP source in the session needs 101 to be provided to that participant. 103 The inability of SRTP to work in the absence of central control was 104 well understood during the design of that protocol; that omission was 105 considered less important than optimizations such as bandwidth 106 conservation. Additionally, in many situations SRTP is used in 107 conjunction with a signaling system that can provide most of the 108 central control needed by SRTP. However, there are several cases in 109 which conventional signaling systems cannot easily provide all of the 110 coordination required. It is also desirable to eliminate the layer 111 violations that occur when signaling systems coordinate certain SRTP 112 parameters, such as SSRC values and ROCs. 114 This document defines Encrypted Key Transport (EKT) for SRTP, an 115 extension to SRTP that fits within the SRTP framework and reduces the 116 amount of signaling control that is needed in an SRTP session. EKT 117 securely distributes the SRTP master key and other information for 118 each SRTP source, using SRTCP to transport that information. With 119 this method, SRTP entities are free to choose SSRC values as they see 120 fit, and to start up new SRTP sources with new SRTP master keys (see 121 Section 2.2) within a session without coordinating with other 122 entities via signaling or other external means. This fact allows to 123 reinstate the RTP collision detection and repair mechanism, which is 124 nullified by the current SRTP specification because of the need to 125 control SSRC values closely. An SRTP endpoint using EKT can generate 126 new keys whenever an existing SRTP master key has been overused, or 127 start up a new SRTP source to replace an old SRTP source that has 128 reached the packet-count limit. EKT also solves the problem in which 129 the burst loss of the N initial SRTP packets can confuse an SRTP 130 receiver, when the initial RTP sequence number is greater than or 131 equal to 2^16 - N. These features simplify many architectures that 132 implement SRTP. 134 EKT provides a way for an SRTP session participant, either sender or 135 receiver, to securely transport its SRTP master key and current SRTP 136 rollover counter to the other participants in the session. This 137 data, possibly in conjunction with additional data provided by an 138 external signaling protocol, furnishes the information needed by the 139 receiver to instantiate an SRTP/SRTCP receiver context. 141 EKT does not control the manner in which the SSRC and master key are 142 generated; it is concerned only with their secure transport. Those 143 values may be generated on demand by the SRTP endpoint, or may be 144 dictated by an external mechanism such as a signaling agent or a 145 secure group controller. 147 EKT is not intended to replace external key establishment mechanisms 148 such as SDP Security Descriptions [SDES] or MIKEY [RFC3830]. 149 Instead, it is used in conjunction with those methods, and it 150 relieves them of the burden of tightly coordinating every SRTP source 151 among every SRTP participant. 153 This document is organized as follows. A complete normative 154 definition of EKT is provided in Section 2. It consists of packet 155 processing algorithms (Section 2.2) and cryptographic definitions 156 (Section 2.3) . In Section 3, the use of EKT with SDP Security 157 Descriptions is defined. In Section 4 we outline the use of EKT with 158 MIKEY. Section 5 provides a design rationale. Security 159 Considerations are provided in Section 6, and IANA considerations are 160 provided in Section 7. 162 1.1 Conventions Used In This Document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 2. Encrypted Key Transport 170 In EKT, an SRTP master key is encrypted with a Key Encrypting Key 171 (KEK), and the resulting ciphertext is transported in every SRTCP 172 packet. A single KEK suffices for a single SRTP session, regardless 173 of the number of participants in the session. However, there can be 174 multiple KEKs used within a particular session. 176 In order to convey the ciphertext of the SRTP master key, and other 177 additional information, the SRTCP Authentication Tag field is 178 subdivided as shown in Figure 1. EKT defines a new SRTCP 179 authentication function, which uses this format. It incorporates a 180 conventional SRTCP authentication function, which is called the base 181 authentication function in this specification. Any SRTCP 182 authentication function, such as the default one of HMAC-SHA1 with a 183 160-bit key and an 80-bit authentication tag, can be used as a base 184 authentication function. EKT also defines a new method of providing 185 SRTP master keys to an endpoint. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 : Base Authentication Tag : 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 : Encrypted Master Key : 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Rollover Counter | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Initial Sequence Number | Security Parameter Index | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: The EKT Authentication Tag format. 201 2.1 Authentication Tag Format 203 The Authentication Tag field contains the following sub-fields: 205 Base Authentication Tag This field contains the authentication tag 206 computed by the base authentication function. The value of this 207 field is used to check the authenticity of the packet. 209 Encrypted Master Key The length of this field is variable, and is 210 equal to the ciphertext size N defined in Section 2.3. Note that 211 the length of the field is inferable from the SPI field, since the 212 particular EKT cipher used by the sender of a packet is inferable 213 from that field. The Encrypted Master Key field is included 214 outside of the authenticated portion of the SRTCP packet, 215 immediately following the Authentication Tag. It contains the 216 ciphertext value resulting from the encryption of the SRTP master 217 key corresponding to the SSRC contained in the packet. The 218 encryption and decryption of this value is done using a cipher as 219 defined in Section 2.3. 221 Rollover Counter The length of this field is fixed at 32 bits. This 222 field is set to the current value of the SRTP rollover counter in 223 the SRTP context associated with the SSRC in the SRTCP packet. 224 This field immediately follows the Encrypted Master Key field. 226 Initial Sequence Number (ISN) The length of this field is fixed at 16 227 bits. If this field is nonzero, then it indicates the RTP 228 sequence number of the initial RTP packet that is protected using 229 the SRTP master key conveyed (in encrypted form) by the Encrypted 230 Master Key field of this packet. If this field is zero, it 231 indicates that the initial RTP packet protected using the SRTP 232 master key conveyed in this packet preceded, or was concurrent 233 with, the last roll-over of the RTP sequence number. The ISN 234 field follows the Rollover Counter field. 236 Security Parameter Index (SPI) The length of this field is fixed at 237 16 bits. This field indicates the appropriate Key Encrypting Key 238 and other parameters for the receiver to use when processing the 239 packet. It is an "index" into a table of possibilities (which are 240 established via signaling or some other out-of-band means), much 241 like the IPsec Security Parameter Index [RFC2401]. The parameters 242 that are identified by this field are: 244 The Key Encrypting Key used to process the packet. 246 The EKT cipher used to process the packet. 248 The Secure RTP parameters associated with the SRTP Master Key 249 carried by the packet and the SSRC value in the packet. 250 Section 8.2. of [RFC3711] summarizes the parameters defined by 251 that specification. 253 Together, these elements are called an EKT parameter set. Within 254 each SRTP session, each distinct EKT parameter set that may be 255 used MUST be associated with a distinct SPI value, to avoid 256 ambiguity. The SPI field follows the Initial Sequence Number. 257 Since it is the last field in the packet, and has a fixed length, 258 it is always possible to unambiguously parse this field. 260 2.2 Packet Processing and State Machine 262 At any given time, each SRTP/SRTCP source has associated with it a 263 single EKT parameter set. This parameter set is used to process all 264 outbound packets, and is called the outbound parameter set. There 265 may be other EKT parameter sets that are used by other SRTP/SRTCP 266 sources in the same session. All of these EKT parameter sets SHOULD 267 be stored by all of the participants in an SRTP session, for use in 268 processing inbound SRTCP traffic. 270 We next review the SRTCP authentication method and show how the EKT 271 authentication method is built on top of the base method. An SRTCP 272 authentication method consists of a tag-generation function and a 273 verification function. The tag-generation function takes as input a 274 secret key, the data to be authenticated, and the SRTCP packet index. 275 It provides an authentication tag as its sole output, and is used in 276 the processing of outbound packets. The verification function takes 277 as input a secret key, the data to be authenticated, the SRTCP packet 278 index, and the authentication tag. It returns an indication of 279 whether or not the data, index, and tag are valid or not. It is used 280 in the processing of inbound packets. EKT defines a tag-generation 281 function in terms of the base tag-generation function, and defines a 282 verification function in terms of the base verification function. 283 The tag-generation function is used to process outbound packets, and 284 the verification function is used to process inbound packets. 286 2.2.1 Outbound (Tag Generation) 288 When an SRTCP packet needs to be sent, the EKT tag generation 289 function works as follows. Given an RTCP packet, the Rollover 290 Counter field in the SRTCP packet is set to the current value of the 291 SRTP rollover counter (represented as an unsigned integer in network 292 byte order). 294 The Initial Sequence Number field is set to zero, if the initial RTP 295 packet protected using the current SRTP master key for this source 296 preceded, or was concurrent with, the last roll-over of the RTP 297 sequence number. Otherwise, that field is set to the value of the 298 RTP sequence number of the initial RTP packet that was or will be 299 protected by that key. When the SRTP master key corresponding to a 300 source is changed, the new key SHOULD be communicated in advance via 301 EKT. (Note that the ISN field allows the receiver to know when it 302 should start using the new key to process SRTP packets.) This 303 enables the rekeying event to be communicated before any RTP packets 304 are protected with the new key. The rekeying event MUST not change 305 the value of ROC (otherwise, the current value of the ROC would not 306 be known to late joiners of existing sessions). 308 The Security Parameter Index field is set to the value of the 309 Security Parameter Index that is associated with the outbound 310 parameter set. 312 The Encrypted Master Key field is set to the ciphertext created by 313 encrypting the SRTP master key with the EKT cipher, using the KEK as 314 the encryption key. The encryption process is detailed in 315 Section 2.3. Implementations MAY cache the value of this field to 316 avoid recomputing it for each packet that is sent. 318 2.2.1.1 Base Authentication Tag 320 The Base Authentication Tag field is computed using the base tag- 321 generation function as follows. It can only be computed after all of 322 the other fields have been set. The authenticated input consists of 323 the following elements, in order: 325 the SRTCP authenticated portion, 327 a string of zero bits whose length exactly matches that of the 328 Base Authentication Tag field, 330 the Encrypted Master Key field, 332 the Rollover Counter field, 334 the Initial Sequence Number field, and 336 the Security Parameter Index field. 338 Implementation note: the string of zero bits is included in the 339 authenticated input in order to allow implementations to compute 340 the base authentication tag using a single pass of the base 341 authentication function. Implementations MAY write zeros into the 342 Base Authentication Tag field prior to computing that function, on 343 the sending side. 345 2.2.2 Inbound (Tag Verification) 347 The EKT verification function proceeds as follows (see Figure 2), or 348 uses an equivalent set of steps. Recall that the verification 349 function is a component of SRTCP processing. When a packet does not 350 pass the verification step, the function indicates this fact to the 351 SRTCP packet processing function when it returns control to that 352 function. 354 1. The Security Parameter Index field is checked to determine which 355 EKT parameter set should be used when processing the packet. If 356 multiple parameter sets been defined for the SRTP session, then 357 the one that is associated with the Security Parameter Index 358 value that matches the Security Parameter Index field in the 359 packet is used. This parameter set is called the matching 360 parameter set below. If there is no matching SPI, then the 361 verification function MUST return an indication of authentication 362 failure, and the steps described below are not performed. 364 2. The Encrypted Master Key field is decrypted using the EKT 365 cipher's decryption function. That field is used as the 366 ciphertext input, and the Key Encrypting Key in the matching 367 parameter set is used as the decryption key. The decryption 368 process is detailed in Section 2.3. The plaintext resulting from 369 this decryption is provisionally accepted as the SRTP master key 370 corresponding to the SSRC in the packet. If an MKI is present in 371 the packet, then the provisional key corresponds to the 372 particular SSRC and MKI combination. A provisional key MUST be 373 used only to process one single packet. A provisional SRTCP 374 authentication key is generated from the provisional master key, 375 and the SRTP master salt from the matching parameter set, using 376 the SRTP key derivation algorithm (see Section 4.3 of [RFC3711]). 378 3. An authentication check is performed on the packet, using the 379 provisional SRTCP authentication key. This key is provided to 380 the base SRTCP authentication function (see Figure 2), which is 381 evaluated as described in Section 2.2.1.1. If the Base 382 Authentication Tag field matches the tag computed by the base 383 authentication function, then the packet passes the check. 385 Implementation note: an SRTP receiver MAY copy the Base 386 Authentication Tag field into temporary storage, then write 387 zeros into that field, prior to computing the base 388 authentication tag value. This step allows the base 389 authentication function to be computed in a single pass. 391 4. If the base authentication check using the provisional key fails, 392 then the provisional key MUST be discarded and it MUST NOT affect 393 any subsequent processing. The verification function MUST return 394 an indication of authentication failure, and the steps described 395 below are not performed. 397 5. Otherwise, if the base authentication check is passed, the 398 provisional key is also accepted as the SRTP master key 399 corresponding to the SRTP source that sent the packet. If an MKI 400 is present in the packet, then the master key corresponds to the 401 particular SSRC and MKI combination. If there is no SRTP crypto 402 context corresponding to the SSRC in the packet, then a new 403 crypto context is created. The rollover counter in the context 404 is set to the value of the Rollover Counter field. 406 6. If the Initial Sequence Number field is nonzero, then the initial 407 sequence number for the SRTP master key is set to the packet 408 index created by appending that field to the current rollover 409 counter and treating the result as a 48-bit unsigned integer. 410 The initial sequence number for the master key is equivalent to 411 the "From" value of the < From, To > pair of indices (Section 412 8.1.1 of [RFC3711]) that can be associated with a master key. 414 7. The newly accepted SRTP master key, the SRTP parameters from the 415 matching parameter set, the SSRC from the packet, and the MKI 416 from the packet, if one is present, are stored in the crypto 417 context associated with the SRTP source. The SRTP Key Derivation 418 algorithm is run in order to compute the SRTP encryption and 419 authentication keys, and those keys are stored for use in SRTP 420 processing of inbound packets. 422 8. The verification function then returns an indication that the 423 packet passed the verification. 425 Implementation note: the value of the Encrypted Master Key 426 field is identical in successive packets protected by the same 427 KEK and SRTP master key. This value MAY be cached by an SRTP 428 receiver to minimize computational effort, by allowing it to 429 recognize when the SRTP master key is unchanged, and thus 430 avoid repeating Steps 2, 6, and 7. 432 +------- Encrypted Master Key 433 | 434 v 435 +------------+ 436 | Decryption | 437 | Function |<-------------------------- Key Encrypting Key 438 +------------+ 439 | +----------------+ EKT 440 +--------+-- provisional ---->| SRTCP |<-- master 441 | master key | Key Derivation | salt 442 | +----------------+ 443 | | 444 | provisional SRTCP authentication key 445 | | 446 | v 447 | +----------------+ 448 | authenticated portion --> | Base SRTCP | 449 | authentication tag -----> | Verification | 450 | +----------------+ 451 | | 452 | +----------------+ +---+ 453 | | return FAIL |<- FAIL -| ? | 454 | +----------------+ +---+ 455 | | 456 | +----------------+ | 457 +------->| set master key,|<- PASS ---+ 458 | ROC, and MKI | 459 +----------------+ 460 | 461 v 462 +----------------+ 463 | return PASS | 464 +----------------+ 466 Figure 2: EKT inbound processing. 468 2.3 Ciphers 470 EKT uses a cipher to encrypt the SRTP master keys. We first specify 471 the interface to the cipher, in order to abstract the interface away 472 from the details of that function. We then define the cipher that is 473 used in EKT by default. This cipher MUST be implemented, but another 474 cipher that conforms to this interface MAY be used, in which case its 475 use MUST be coordinated by external means (e.g. call signaling). 477 An EKT cipher consists of an encryption function and a decryption 478 function. The encryption function E(K, P) takes the following 479 inputs: 481 a secret key K with a length of L bytes, and 483 a plaintext value P with a length of M bytes. 485 The encryption function returns a ciphertext value C whose length is 486 N bytes, where N is at least M. The decryption function D(K, C) takes 487 the following inputs: 489 a secret key K with a length of L bytes, and 491 a ciphertext value C with a length of N bytes. 493 The decryption function returns a plaintext value P that is M bytes 494 long. These functions have the property that D(K, E(K, P)) = P for 495 all values of K and P. Each cipher also has a limit T on the number 496 of times that it can be used with any fixed key value. For each key, 497 the encryption function MUST NOT be invoked on more than T distinct 498 values of P, and the decryption function MUST NOT be invoked on more 499 than T distinct values of C. 501 An EKT cipher MUST resist attacks in which both ciphertexts and 502 plaintexts can be adaptively chosen. For each randomly chosen key, 503 the encryption and decryption functions cannot be distinguished from 504 a random permutation and its inverse with non-negligible advantage. 505 This must be true even for adversaries that can query both the 506 encryption and decryption functions adaptively. The advantage is 507 defined as the difference between the probability that the adversary 508 will identify the cipher as such and the probability that the 509 adversary will identify the random permutation as the cipher, when 510 each case is equally likely. 512 2.3.1 The Default Cipher 514 The default cipher is the Advanced Encryption Standard (AES) 515 [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its 516 parameters are fixed at L=16, M=16, and T=2^48. Note that M matches 517 the size of the SRTP master keys used by the default SRTP key 518 derivation function; if an SRTP cipher with a different SRTP master 519 key length is to be used with EKT, then another EKT cipher must be 520 used. ECB is the simplest mode of operation of a block cipher, in 521 which the block cipher is used in its raw form. 523 2.3.2 The AES Key Wrap Cipher 525 The AES Key Wrap [RFC3394] defines a cipher that can be used with 526 plaintexts larger than 16 bytes in length. It requires a plaintext 527 length M that is a multiple of eight bytes, and it returns a 528 ciphertext with a length of N = M + 8 bytes. It can be used with key 529 sizes of L = 16, 24, and 32. The key size determines the length of 530 the AES key used by the Key Wrap algorithm. With this cipher, 531 T=2^48. 533 2.3.3 Other EKT Ciphers 535 Other specification MAY extend this one by defining other EKT 536 ciphers. This section defines how those ciphers interact with this 537 specification. 539 An EKT cipher determines how the Encrypted Master Key field is 540 written, and how it is processed when it is read. This field is 541 opaque to the other aspects of EKT processing. EKT ciphers are free 542 to use this field in any way, but they SHOULD NOT use other EKT or 543 SRTP fields as an input. The values of the parameters L, M, N, and T 544 MUST be defined by each EKT cipher, and those values MUST be 545 inferable from the EKT parameter set. 547 2.4 Synchronizing Operation 549 EKT is transported over SRTCP, but some of the information that it 550 conveys is used for SRTP processing; some elements of the EKT 551 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 552 packets can be lost and both SRTP and SRTCP packets may be delivered 553 out-of-order. This can lead to various race conditions, which we 554 review below. 556 When joining an SRTP session, SRTP packets may be received before any 557 SRTCP (EKT) packets, which implies the crypto context has not been 558 established, unless other external signaling mechanism has done so. 559 Rather than automatically discarding such SRTP packets, the receiver 560 MAY want to provisionally place them in a jitter buffer and delay 561 discarding them until playout time. 563 When an SRTP source using EKT performs a rekeying operation, there is 564 a race between the actual rekeying signaled via SRTCP and the SRTP 565 packets secured by the new keying material. If the SRTP packets are 566 received first, they will fail authentication; alternatively, if 567 authentication is not being used, they will decrypt to unintelligible 568 random-looking plaintext. (Note, however, that [RFC3711] says that 569 SRTP "SHOULD NOT be used without message authentication".) In order 570 to address this problem, the rekeying event can be sent before 571 packets using the new SRTP master key are sent (by use of the ISN 572 field). Another solution involves using an MKI at the expense of 573 added overhead in each SRTP packet. Alternatively, receivers MAY 574 want to delay discarding packets from known SSRCs that fail 575 authentication in anticipation of receiving a rekeying event via EKT 576 (SRTCP) shortly. 578 The ROC signaled via EKT over SRTCP may be off by one when it is 579 received by the other party(ies) in the session. In order to deal 580 with this, receivers should simply follow the SRTP packet index 581 estimation procedures defined in [SRTP] Section 3.3.1. 583 2.5 Timing and Reliability Consideration 585 SRTCP communicates the master key and ROC for the SRTP session. 586 Thus, as explained above, if SRTP packets are received prior to the 587 corresponding SRTCP (EKT) packet, a race condition occurs. From an 588 EKT point of view, it is therefore desirable for an SRTP sender to 589 send an SRTCP packet as soon as possible, and in no case any later 590 than when the initial SRTP packet is sent. SRTCP however MUST obey 591 the timing rules associated with the profile under which it runs 592 (e.g. RTP/SAVP or RTP/SAVPF). Subject to that constraint, SRTP 593 senders SHOULD send an SRTCP packet as soon as possible after joining 594 a session. Note that there is no need for SRTP receivers to do so. 595 Also note, that per RFC 3550, Section 6.2, it is permissible to send 596 a compound RTCP packet immediately after joining a unicast session 597 (but not a multicast session). 599 SRTCP is not reliable and hence SRTCP packets may be lost. This is 600 obviously a problem for endpoints joining an SRTP session and 601 receiving SRTP traffic (as opposed to SRTCP), or for endpoints 602 receiving SRTP traffic following a rekeying event. To reduce the 603 impact of lost packets, SRTP senders SHOULD send SRTCP packets as 604 often as allowed by the profile under which they operate. 606 3. EKT and SDP Security Descriptions 608 The SDP Security Descriptions (SDES) [SDES] specification defines a 609 generic framework for negotiating security parameters for media 610 streams negotiated via the Session Description Protocol by use of a 611 new SDP "crypto" attribute and the Offer/Answer procedures defined in 612 [RFC3264]. In addition to the general framework, SDES also defines 613 how to use that framework specifically to negotiate security 614 parameters for Secure RTP. Below, we first provide a brief recap of 615 the crypto attribute when used for SRTP and we then explain how it is 616 complementary to EKT. In the rest of this Section, we provide 617 extensions to the crypto attribute and associated offer/answer 618 procedures to define its use with EKT. 620 3.1 SDP Security Descriptions Recap 622 The SRTP crypto attribute defined for SDP Security Descriptions 623 contains a tag followed by three types of parameters (refer to [SDES] 624 for details): 626 Crypto-suite. Identifies the encryption and authentication 627 transform 629 Key parameters. SRTP keying material and parameters. 631 Session parameters. Additional (optional) SRTP parameters such as 632 Key Derivation Rate, Forward Error Correction Order, use of 633 unencrypted SRTP, etc. 635 The crypto attributes in the example SDP in Figure 3 illustrate these 636 parameters. 638 v=0 639 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 640 s=SRTP Discussion 641 i=A discussion of Secure RTP 642 u=http://www.example.com/seminars/srtp.pdf 643 e=marge@example.com (Marge Simpson) 644 c=IN IP4 168.2.17.12 645 t=2873397496 2873404696 646 m=audio 49170 RTP/SAVP 0 647 a=crypto:1 AES_CM_128_HMAC_SHA1_80 648 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 649 FEC_ORDER=FEC_SRTP 650 a=crypto:2 F8_128_HMAC_SHA1_80 651 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 652 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 653 FEC_ORDER=FEC_SRTP 655 Figure 3: SDP Security Descriptions example. Line breaks are 656 included for formatting purposes only. 658 The first crypto attribute has the tag "1" and uses the crypto-suite 659 "AES_CM_128_HMAC_SHA1_80". The "inline" parameter provides the SRTP 660 master key and salt, the master key lifetime (number of packets), and 661 the (optional) Master Key Identifier (MKI) whose value is "1" and has 662 a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER 663 session parameter indicates the order of Forward Error Correction 664 used (FEC is applied before SRTP processing by the sender of the SRTP 665 media). 667 The second crypto attribute has the tag "2" and uses the crypto-suite 668 "F8_128_HMAC_SHA1_80". It includes two SRTP master keys and 669 associated salts. The first one is used with the MKI value 1, 670 whereas the second one is used with the MKI value 2. Finally, the 671 FEC_ORDER session parameter indicates the order of Forward Error 672 Correction used. 674 3.2 Relationship between EKT and SDP Security Descriptions 676 SDP Security Descriptions [SDES] define a generic framework for 677 negotiating security parameters for media streams negotiated via the 678 Session Description Protocol by use of the Offer/Answer procedures 679 defined in [RFC3264]. In addition to the general framework, SDP 680 Security Descriptions (SDES) also defines how to use it specifically 681 to negotiate security parameters for Secure RTP. 683 EKT and SDES are complementary. SDP Security Descriptions can 684 negotiate several of the SRTP security parameters (e.g. cipher and 685 use of Master Key Identifier/MKI) as well as SRTP master keys. SDP 686 Security Descriptions however does not negotiate SSRCs and their 687 associated Rollover Counter (ROC). Instead, SDES relies on a so- 688 called "late binding", where a newly observed SSRC will have its 689 crypto context initialized to a ROC value of zero. Clearly, this 690 does not work for participants joining an SRTP session that has been 691 established for a while and hence has a non-zero ROC. The use of EKT 692 solves this problem by communicating the ROC associated with the SSRC 693 in the media plane. 695 SDP Security Descriptions negotiates different SRTP master keys in 696 the send and receive direction. The offer contains the master key 697 used by the offerer to send media, and the answer contains the master 698 key used by the answerer to send media. Consequently, if media is 699 received by the offerer prior to the answer being received, the 700 offerer does not know the master key being used. Use of SDP security 701 preconditions can solve this problem, however it requires an 702 additional round-trip as well as a more complicated state machine. 703 EKT solves this problem by simply sending the master key used in the 704 media plane thereby avoiding the need for security preconditions. 706 If multiple crypto-suites were offered, the offerer also will not 707 know which of the crypto-suites offered was selected until the answer 708 is received. EKT solves this problem by using a correlator, the 709 Security Parameter Index (SPI), which uniquely identifies each crypto 710 attribute in the offer. 712 One of the primary call signaling protocols using offer/answer is the 713 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 714 message to initiate a media session and typically includes an offer 715 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 716 which potentially can lead to multiple answers being received. SDP 717 Security Descriptions however does not properly support this 718 scenario, mainly because SDP and RTP/RTCP does not contain sufficient 719 information to allow for correlation of an incoming RTP/RTCP packet 720 with a particular answer SDP. Note that extensions providing this 721 correlation do exist, e.g. Interactive Connectivity Establishment 722 (ICE). SDP Security Descriptions addresses this point-to-multipoint 723 problem by moving each answer to a separate RTP transport address 724 thereby turning a point-to-multipoint scenario into multiple point- 725 to-point scenarios. There are however significant disadvantages to 726 doing so. As long as the crypto attribute in the answer does not 727 contain any declarative parameters that differ from those in the 728 offer, EKT solves this problem by use of the SPI correlator and 729 communication of the answerer's SRTP master key in EKT. 731 As can be seen from the above, the combination of EKT and SDES 732 provides a better solution to SRTP negotiation for offer/answer than 733 either of them alone. SDES negotiates the various SRTP crypto 734 parameters (which EKT does not), whereas EKT addresses the 735 shortcomings of SDES. 737 3.3 Overview of Combined EKT and SDP Security Description Operation 739 We define three session extension parameters to SDES to communicate 740 the EKT cipher, EKT key, and Security Parameter Index to the peer. 741 The original SDES parameters are used as defined in [SDES], however 742 the procedures associated with the SRTP master key differ slightly, 743 since both SDES and EKT communicate an SRTP master key. In 744 particular, the SRTP master key communicated via SDES is used only if 745 there is currently no crypto context established for the SSRC in 746 question. This will be the case when an entity has received only the 747 offer or answer, but has yet to receive a valid EKT message from the 748 peer. Once a valid EKT message is received for the SSRC, the crypto 749 context is initialized accordingly, and the SRTP master key will then 750 be derived from the EKT message. Subsequent offer/answer exchanges 751 do not change this: The most recent SRTP master key negotiated via 752 EKT will be used, or, if none is available for the SSRC in question, 753 the most recent SRTP master key negotiated via offer/answer will be 754 used. Note that with these rules, once a valid EKT message has been 755 received for a given SSRC, rekeying for that SSRC can only be done 756 via EKT. The associated SRTP crypto parameters however can be 757 changed via SDES. 759 3.4 EKT Extensions to SDP Security Descriptions 761 In order to use EKT and SDES in conjunction, we now define the 762 following new SDES session parameters, each of which MUST NOT appear 763 more than once in a given crypto attribute: 765 EKT_Cipher The EKT cipher used to encrypt the SRTP Master Key 767 EKT_Key The EKT key used to encrypt the SRTP Master Key 769 EKT_SPI The EKT Security Parameter Index 771 Below, we provide additional detail on each of these attributes. 773 3.4.1 EKT_Cipher 775 The (optional) EKT_Cipher parameter parameter defines the EKT cipher 776 used to encrypt the EKT key with in SRTCP packets. The default value 777 is "AES_128" in accordance with Section 2.3.1. For the AES Key Wrap 778 cipher (see Section 2.3.2, the values "AESKW_128", "AESKW_192", and 779 "AESKW_256" are defined for values of L=16, 24, and 32 respectively. 780 In the Offer/Answer model, the EKT_Cipher parameter is a negotiated 781 parameter. 783 3.4.2 EKT_Key 785 The (mandatory) EKT_Key parameter is the key K used to encrypt the 786 SRTP Master Key in SRTCP packets. The value is base64 encoded (see 787 [RFC3548], Section 3). When base64 decoding the key, padding 788 characters (i.e., one or two "=" at the end of the base64 encoded 789 data) are discarded (see [RFC3548] for details). Base64 encoding 790 assumes that the base64 encoding input is an integral number of 791 octets. If a given EKT cipher requires the use of a key with a 792 length that is not an integral number of octets, said cipher MUST 793 define a padding scheme that results in the base64 input being an 794 integral number of octets. For example, if the length defined was 795 250 bits, then 6 padding bits would be needed, which could be defined 796 to be the last 6 bits in a 256 bit input. In the Offer/Answer model, 797 the EKT_Key parameter is a negotiated parameter. 799 3.4.3 EKT_SPI 801 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 802 It is encoded as an ASCII string representing the hexadecimal value 803 of the Security Parameter Index. The SPI identifies the *offer* 804 crypto attribute (including the EKT Key and Cipher) being used for 805 the associated SRTP session. A crypto attribute corresponds to an 806 EKT Parameter Set and hence the SPI effectively identifies a 807 particular EKT parameter set. Note that the scope of the SPI is the 808 SRTP session, which may or may not be limited to the scope of the 809 associated SIP dialog. In particular, if one of the participants in 810 an SRTP session is an SRTP translator, the scope of the SRTP session 811 is not limited to the scope of a single SIP dialog. However, if all 812 of the participants in the session are endpoints or mixers, the scope 813 of the SRTP session will correspond to a single SIP dialog. In the 814 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 816 3.5 Offer/Answer Procedures 818 In this section, we provide the offer/answer procedures associated 819 with use of the three new SDES parameters defined in Section 820 Section 3.4. Since SDES is defined only for unicast streams, we 821 provide only offer/answer procedures for unicast streams here as 822 well. 824 3.5.1 Generating the Initial Offer - Unicast Streams 826 When the initial offer is generated, the offerer MUST follow the 827 steps defined in [SDES] Section 7.1.1 as well as the following steps. 829 For each unicast media line using SDES and where use of EKT is 830 desired, the offerer MUST include one EKT_Key parameter and one 831 EKT_SPI parameter in at least one "crypto" attribute (see [SDES]). 832 The EKT_SPI parameter serves to identify the EKT parameter set used 833 for a particular SRTCP packet. Consequently, within a single media 834 line, a given EKT_SPI value MUST NOT be used with multiple crypto 835 attributes. Note that the EKT parameter set to use for the session 836 is not yet established at this point; each offered crypto attribute 837 contains a candidate EKT parameter set. Furthermore, if the media 838 line refers to an existing SRTP session, then any SPI values used for 839 EKT parameter sets in that session MUST NOT be remapped to any 840 different EKT parameter sets. When an offer describes an SRTP 841 session that is already in progress, the offer SHOULD use an EKT 842 parameter set (incl. EKT_SPI and EKT_KEY) that is already in use. 844 If an EKT_Cipher other than the default cipher is to be used, then 845 the EKT_Cipher parameter MUST be included as well. 847 If a given crypto attribute includes more than one set of SRTP key 848 parameters (SRTP master key, salt, lifetime, MKI), they MUST all use 849 the same salt. (EKT requires a single shared salt between all the 850 participants in the direct SRTP session). 852 Important Note: The scope of the offer/answer exchange is the SIP 853 dialog(s) established as a result of the INVITE, however the scope of 854 EKT is the direct SRTP session, i.e. all the participants that are 855 able to receive SRTP and SRTCP packets directly. If an SRTP session 856 spans multiple SIP dialogs, the EKT parameter sets MUST be 857 synchronized between all the SIP dialogs where SRTP and SRTCP packets 858 can be exchanged. In the case where the SIP entity operates as an 859 RTP mixer (and hence re-originates SRTP and SRTCP packets with its 860 own SSRC), this is not an issue, unless the mixer receives traffic 861 from the various participants on the same destination IP address and 862 port, in which case further coordination of SPI values and crypto 863 parameters may be needed between the SIP dialogs (note that SIP 864 forking with multiple early media senders is an example of this). 865 However if it operates as an RTP translator, synchronized negotiation 866 of the EKT parameter sets on *all* the involved SIP dialogs will be 867 needed. This is non-trivial in a variety of use cases, and hence use 868 of the combined SDES/EKT mechanism with RTP translators should be 869 considered very carefully. It should be noted, that use of SRTP with 870 RTP translators in general should be considered very carefully as 871 well. 873 The EKT session parameters can either be included as optional or 874 mandatory parameters, however within a given crypto attribute, they 875 MUST all be either optional or mandatory. 877 3.5.2 Generating the Initial Answer - Unicast Streams 879 When the initial answer is generated, the answerer MUST follow the 880 steps defined in [SDES] Section 7.1.2 as well as the following steps. 882 For each unicast media line using SDES, the answerer examines the 883 associated crypto attribute(s) for the presence of EKT parameters. 884 If mandatory EKT parameters are included with a "crypto" attribute, 885 the answerer MUST support those parameters in order to accept that 886 offered crypto attribute. If optional EKT parameters are included 887 instead, the answerer MAY accept the offered crypto attribute without 888 using EKT. However, doing so will prevent the offerer from 889 processing any packets received before the answer. If neither 890 optional nor mandatory EKT parameters are included with a crypto 891 attribute, and that crypto attribute is accepted in the answer, EKT 892 MUST NOT be used. If a given a crypto attribute includes a mixture 893 of optional and mandatory EKT parameters, or an incomplete set of 894 mandatory EKT parameters, that crypto attribute MUST be considered 895 invalid. 897 When EKT is used with SDES, the offerer and answerer MUST use the 898 same SRTP salt. Thus, the SRTP key parameter(s) in the answer crypto 899 attribute MUST use the same salt as the one accepted from the offer. 901 When the answerer accepts the offered media line and EKT is being 902 used, the crypto attribute included in the answer MUST include the 903 same EKT parameter values as found in the accepted crypto attribute 904 from the offer (however, if the default EKT cipher is being used, it 905 may be omitted). Furthermore, the EKT parameters included MUST be 906 mandatory (i.e. no "-" prefix). 908 Acceptance of a crypto attribute with EKT parameters leads to 909 establishment of the EKT parameter set for the corresponding SRTP 910 session. Consequently, the answerer MUST send packets in accordance 911 with that particular EKT parameter set only. If the answerer wants 912 to enable the offerer to process SRTP packets received by the offerer 913 before it receives the answer, the answerer MUST NOT include any 914 declarative session parameters that either were not present in the 915 offered crypto attribute, or were present but with a different value. 916 Otherwise, the offerer's view of the EKT parameter set would differ 917 from the answerer's until the answer is received. Similarly, unless 918 the offerer and answerer has other means for correlating an answer 919 with a particular SRTP session, the answer SHOULD NOT include any 920 declarative session parameters that either were not present in the 921 offered crypto attribute, or were present but with a different value. 922 If this recommendation is not followed and the offerer receives 923 multiple answers (e.g. due to SIP forking), the offerer may not be 924 able to process incoming media stream packets correctly. 926 3.5.3 Processing of the Initial Answer - Unicast Streams 928 When the offerer receives the answer, it MUST perform the steps in 929 [SDES] Section 7.1.3 as well as the following steps for each SRTP 930 media stream it offered with one or more crypto lines containing EKT 931 parameters in it. 933 If the answer crypto line contains EKT parameters, and the 934 corresponding crypto line from the offer contained the same EKT 935 values, use of EKT has been negotiated successfully and MUST be used 936 for the media stream. When determining whether the values match, 937 optional and mandatory parameters MUST be considered equal. 938 Furthermore, if the default EKT cipher is being used, it MAY be 939 either present or absent in the offer and/or answer. 941 If the answer crypto line does not contain EKT parameters, then EKT 942 MUST NOT be used for the corresponding SRTP session. Note that per 943 [SDES] Section 5.1.3, if the accepted crypto attribute contained 944 mandatory EKT parameters in the offer, and the crypto attribute in 945 the answer does not contain EKT parameters, then negotiation has 946 failed. 948 If the answer crypto line contains EKT parameters but the 949 corresponding offered crypto line did not, or if the parameters don't 950 match or are invalid, then the offerer MUST consider the crypto line 951 invalid (see [SDES] Section 7.1.3 for further operation). 953 The EKT parameter set is established when the answer is received, 954 however there are a couple of special cases to consider here. First 955 of all, if an SRTCP packet is received prior to the answer, then the 956 EKT parameter set is established provisionally based on the SPI 957 included. Once the answer (which may include declarative session 958 parameters) is received, the EKT parameter set is fully established. 959 The second case involves receipt of multiple answers due to SIP 960 forking. In this case, there will be multiple EKT parameter sets; 961 one for each SRTP session. As mentioned earlier, reliable 962 correlation of SIP dialogs to SRTP sessions requires extensions, and 963 hence if one or more of the answers include declarative session 964 parameters, it may be difficult to fully establish the EKT parameter 965 set for each SRTP session. In the absence of a specific correlation 966 mechanism, it is RECOMMENDED, that such correlation be done based on 967 the signaled receive IP-address in the SDP and the observed source 968 IP-address in incoming SRTP/SRTCP packets, and, if necessary, the 969 signaled receive UDP port and the observed source UDP port. 971 3.6 SRTP-Specific Use Outside Offer/Answer 973 SDES use for SRTP is not defined outside offer/answer and hence 974 neither is SDES with EKT. 976 3.7 Modifying the Session 978 When a media stream using the SRTP security descriptions has been 979 established, and a new offer/answer exchange is performed, the 980 offerer and answerer MUST follow the steps in [SDES] Section 7.1.4 as 981 well as the following steps. SDES allows for all parameters of the 982 session to be modified, and the EKT session parameters are no 983 exception to that, however, there are a few additional rules to be 984 adhered to when using EKT. 986 It is permissible to start a session without the use of EKT, and then 987 subsequently start using EKT, however the converse is not. Thus, 988 once use of EKT has been negotiated on a particular media stream, EKT 989 MUST continue to be used on that media stream in all subsequent 990 offer/answer exchanges. 992 The reason for this is that both SDES and EKT communicate the SRTP 993 Master Key with EKT Master Keys taking precedence. Reverting back to 994 an SDES controlled master key in a synchronized manner is difficult. 996 Once EKT is being used, the salt for the direct SRTP session MUST NOT 997 be changed. Thus, a new offer/answer which does not create a new 998 SRTP session (e.g. because it reuses the same IP address and port) 999 MUST use the same salt for all crypto attributes as is currently used 1000 for the direct SRTP session. 1002 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1003 value to a different EKT parameter set until 2^32 other mappings have 1004 been used within the SRTP session. In practice, this requirements is 1005 most easily met by using a monotonically increasing SPI value (modulo 1006 2^32 and starting with zero) per direct SRTP session. Note that a 1007 direct SRTP session may span multiple SIP dialogs, and in such cases 1008 coordination of SPI values across those SIP dialogs will be required. 1009 In the simple point-to-point unicast case without translators, the 1010 requirement simply applies within each media line in the SDP. In the 1011 point-to-multipoint case, the requirement applies across all the 1012 associated SIP dialogs. 1014 3.8 Backwards Compatibility Considerations 1016 Backwards compatibility can be achieved in a couple of ways. First 1017 of all, SDES allows for session parameters to be prefixed with "-" to 1018 indicate that they are optional. If the answerer does not support 1019 the EKT session parameters, such optional parameters will simply be 1020 ignored. When the answer is received, absence of the parameters will 1021 indicate that EKT is not being used. Receipt of SRTCP packets prior 1022 to receipt of such an answer will obviously be problematic (as is 1023 normally the case for SDES without EKT). 1025 Alternatively, SDES allows for multiple crypto lines to be included 1026 for a particular media stream. Thus, two crypto lines that differ in 1027 their use of EKT parameters (presence in one, absence in the other) 1028 can be used as a way to negotiate use of EKT. When the answer is 1029 received, the accepted crypto attribute will indicate whether EKT is 1030 being used or not. 1032 3.9 Grammar 1034 The ABNF for the three new SDES session parameters is as in Figure 4. 1036 EKT_Cipher = "EKT_Cipher=" EKT_Cipher_Name 1037 EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128" 1038 ; "AESKW_192" and "AESKW_256" 1039 ; defined in this document. 1041 EKT_Key = 1*(base64) ; See Section 3 in RFC3548 1042 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1044 EKT_SPI = 1*8(HEXDIG) ; See RFC2234 1046 Figure 4: ABNF for the EKT session parameters. 1048 4. Use of EKT with MIKEY 1050 The advantages outlined in Section 1 are useful in some scenarios in 1051 which MIKEY is used to establish SRTP sessions. In this section, we 1052 briefly review MIKEY and related work, and discuss these scenarios. 1053 A n SRTP sender or a group controller can use MIKEY to establish a 1054 SRTP cryptographic context. This capability includes the 1055 distribution of the TEK or a TEK generation key (TGK) , security 1056 policy payload, crypto session bundle ID (CSB_ID), and a crypto 1057 session ID (CS_ID). The TEK directly maps to an SRTP master key, 1058 whereas the TGK is used along with the CSB_ID and a CS_ID to generate 1059 a TEK. The CS_ID can be used to generate multiple TEKs from a single 1060 TGK. For group communication, the sender or group controller sends 1061 the same TGK, CSB_ID, and CS_ID to all the members. For interactive 1062 conferencing, each sender distributes the same SRTP crypto context to 1063 the rest of the members. 1065 The MIKEY specification [RFC3830] suggests the use of unicast for 1066 rekeying. This method does not scale well to large groups or 1067 interactive groups. MIKEY also provides a way to provide ROC values 1068 to members when they join the group. It is desirable to not require 1069 the group controller to track the ROC values of each member. For 1070 example, in mobile and wireless environments, members may go in and 1071 out of coverage, and in those cases, key management based ROC 1072 synchronization is not reliable or sufficient. A better alternative 1073 to support ROC synchronization is to send ROC values via SRTP, as EKT 1074 does. A separate SRTP extension is being proposed [RCC] to include 1075 the ROC as part of a modified authentication tag. Unlike EKT, this 1076 extension uses SRTP and not SRTCP as its transport. A new MIKEY 1077 extension [KEYID] specifies the use of MIKEY to update group keys via 1078 multicast or broadcast for 3GPP MBMS networks. 1080 The EKT extension of SRTP/SRTCP provides a combined solution for 1081 rekeying and ROC synchronization. It also offers several advantages. 1082 With EKT, an SRTP session participant can start a new SRTP source 1083 without coordinating with a group controller about the selection of 1084 keys or SSRC values. With EKT, SRTP can handle early media, since 1085 its SPI allows the receiver to identify the cryptographic keys and 1086 parameters used by the source. EKT also allows SRTP to work with SIP 1087 forking. 1089 MIKEY can readily be extended so that it can establish the EKT key, 1090 cipher and SPI values. A future version of this document will 1091 specify how this can be done. 1093 5. Design Rationale 1095 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1096 "persistent transport-level identifier for an RTP source" since 1097 "receivers require the CNAME to keep track of each participant." EKT 1098 works in much the same way, using SRTCP to carry information needed 1099 for the proper processing of the SRTP traffic. 1101 With EKT, SRTP gains the ability to synchronize the creation of 1102 cryptographic contexts across all of the participants in a single 1103 session. This feature provides some, but not all, of the 1104 functionality that is present in IKE phase two (but not phase one). 1105 Importantly, EKT does not provide a way to indicate SRTP options. 1107 With EKT, external signaling mechanisms provide the SRTP options and 1108 the EKT Key, but need not provide the key(s) for each individual SRTP 1109 source. EKT provides a separation between the signaling mechanisms 1110 and the details of SRTP. The signaling system need not coordinate 1111 all SRTP streams, nor predict in advance how many streams will be 1112 present, nor communicate SRTP-level information (e.g. rollover 1113 counters) of current sessions. 1115 EKT is especially useful for multi-party sessions, and for the case 1116 where multiple RTP sessions are sent to the same destination 1117 transport address (see the example in the definition of "RTP session" 1118 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1119 multiple endpoints at the same time) can cause multiple RTP sessions 1120 to be sent to the same transport address, making EKT useful for use 1121 with SIP. 1123 EKT can also be used in conjunction with a scalable group-key 1124 management system like GDOI. Such a system provides a secure entity 1125 authentication method and a way to revoke group membership, both of 1126 which are out of scope of EKT. 1128 It is natural to use SRTCP to transport encrypted keying material for 1129 SRTP, as it provides a secure control channel for (S)RTP. However, 1130 there are several different places in SRTCP in which the encrypted 1131 SRTP master key and ROC could be conveyed. We briefly review some of 1132 the alternatives in order to motivate the particular choice used in 1133 this specification. One alternative is to have those values carried 1134 as a new SDES item or RTCP packet. This would require that the 1135 normal SRTCP encryption be turned off for the packets containing that 1136 SDES item, since on the receiver's side, SRTCP processing completes 1137 before the RTCP processing starts. This tension between encryption 1138 and the desire for RTCP privacy is highly undesirable. Additionally, 1139 this alternative makes SRTCP dependent upon the parsing of the RTCP 1140 compound packet, which adds complexity. It is simpler to carry the 1141 encrypted key in a new SRTCP field. One way to do this and to be 1142 backwards compatible with the existing specification is to define a 1143 new crypto function that incorporates the encrypted key. We define a 1144 new authentication transform because EKT relies on the normal SRTCP 1145 authentication to provide implicit authentication of the encrypted 1146 key. 1148 An SRTP packet containing an SSRC that has not been seen will be 1149 discarded. This practice may induce a burst of packet loss at the 1150 outset of an SRTP stream, due to the loss or reorder of the first 1151 SRTCP packet with the EKT containing the key and rollover counter for 1152 that stream. However, this practice matches the conservative RTP 1153 memory-allocation strategy; many existing applications accept this 1154 risk of initial packet loss. Alternatively, implementations may wish 1155 to delay discarding such packets for a short period of time as 1156 described in Section 2.4. 1158 EKT adds eight additional bytes to each SRTCP packet, plus the length 1159 of the Encrypted Master Key field. Using the SRTP and EKT defaults, 1160 the total overhead is 24 bytes. This overhead does not detract from 1161 the total bandwidth used by SRTP, since it is included in the RTCP 1162 bandwidth computation. However, it will cause the control protocol 1163 to issue packets less frequently. 1165 6. Security Considerations 1167 With EKT, each SRTP sender and receiver can generate distinct SRTP 1168 master keys. This property avoids any security concern over the re- 1169 use of keys, by empowering the SRTP layer to create keys on demand. 1170 Note that the inputs of EKT are the same as for SRTP with key- 1171 sharing: a single key is provided to protect an entire SRTP session. 1172 However, EKT provides complete security, even in the absence of 1173 further out-of-band coordination of SSRCs, and even when SSRC values 1174 collide. 1176 EKT uses encrypted key transport with implicit authentication. A 1177 strong cipher is used to ensure the confidentiality of the master 1178 keys as they are transported. The authenticity of the master keys is 1179 ensured by the base authentication check, which uses the plaintext 1180 form of that key. If the base authentication function and the cipher 1181 cannot be defeated by a particular attacker, then that attacker will 1182 be unable to defeat the implicit authentication. 1184 In order to avoid potential security issues, the SRTP authentication 1185 tag length used by the base authentication method MUST be at least 1186 ten octets. 1188 7. IANA Considerations 1190 This section registers with IANA the following SRTP session 1191 parameters for SDP Security Descriptions [SDES]: 1193 EKT_KEY 1195 EKT_CIPHER 1197 EKT_SPI 1199 The definition of these parameters is provided in Section 3.4. 1201 8. Acknowledgements 1203 Thanks to Dan Wing and Rob Raymond for fruitful discussions. 1205 9. References 1207 9.1 Normative References 1209 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1210 Information Processing Standard. 1212 [KEYID] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1213 Information Type for the General Extension Payload in 1214 MIKEY", Work In 1215 Progress. . 1217 [RCC] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1218 Transform Carrying Roll-over Counter", Work In 1219 Progress. . 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1225 Specifications: ABNF", RFC 2234, November 1997. 1227 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1228 A., Peterson, J., Sparks, R., Handley, M., and E. 1229 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1230 June 2002. 1232 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1233 with Session Description Protocol (SDP)", RFC 3264, 1234 June 2002. 1236 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1237 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1239 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1240 Encodings", RFC 3548, July 2003. 1242 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1243 Jacobson, "RTP: A Transport Protocol for Real-Time 1244 Applications", STD 64, RFC 3550, July 2003. 1246 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1247 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1248 RFC 3711, March 2004. 1250 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 1251 Description Protocol Security Descriptions for Media 1252 Streams", Work In 1253 Progress. . 1255 9.2 Informative References 1257 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1258 Internet Protocol", RFC 2401, November 1998. 1260 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1261 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1262 August 2004. 1264 Authors' Addresses 1266 David A. McGrew 1267 Cisco Systems, Inc. 1268 510 McCarthy Blvd. 1269 Milpitas, CA 95035 1270 US 1272 Phone: (408) 525 8651 1273 Email: mcgrew@cisco.com 1274 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1276 Flemming Andreason 1277 Cisco Systems, Inc. 1278 499 Thornall Street 1279 Edison, NJ 08837 1280 US 1282 Email: fandreas@cisco.com 1284 Lakshminath Dondeti 1285 QUALCOMM 1286 5775 Morehouse Drive 1287 San Diego, CA 92121 1288 US 1290 Email: ldondeti@qualcomm.com 1292 Intellectual Property Statement 1294 The IETF takes no position regarding the validity or scope of any 1295 Intellectual Property Rights or other rights that might be claimed to 1296 pertain to the implementation or use of the technology described in 1297 this document or the extent to which any license under such rights 1298 might or might not be available; nor does it represent that it has 1299 made any independent effort to identify any such rights. Information 1300 on the procedures with respect to rights in RFC documents can be 1301 found in BCP 78 and BCP 79. 1303 Copies of IPR disclosures made to the IETF Secretariat and any 1304 assurances of licenses to be made available, or the result of an 1305 attempt made to obtain a general license or permission for the use of 1306 such proprietary rights by implementers or users of this 1307 specification can be obtained from the IETF on-line IPR repository at 1308 http://www.ietf.org/ipr. 1310 The IETF invites any interested party to bring to its attention any 1311 copyrights, patents or patent applications, or other proprietary 1312 rights that may cover technology that may be required to implement 1313 this standard. Please address the information to the IETF at 1314 ietf-ipr@ietf.org. 1316 Disclaimer of Validity 1318 This document and the information contained herein are provided on an 1319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1326 Copyright Statement 1328 Copyright (C) The Internet Society (2006). This document is subject 1329 to the rights, licenses and restrictions contained in BCP 78, and 1330 except as set forth therein, the authors retain all their rights. 1332 Acknowledgment 1334 Funding for the RFC Editor function is currently provided by the 1335 Internet Society.