idnits 2.17.1 draft-ietf-avtcore-srtp-ekt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 == Line 549 has weird spacing: '...ngth of lengt...' == Line 551 has weird spacing: '...ansform tran...' -- The document date (February 14, 2014) is 3716 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1254, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE Working Group D. McGrew 3 Internet-Draft D. Wing 4 Intended status: Standards Track F. Andreasen 5 Expires: August 18, 2014 Cisco 6 February 14, 2014 8 Encrypted Key Transport for Secure RTP 9 draft-ietf-avtcore-srtp-ekt-02 11 Abstract 13 Encrypted Key Transport (EKT) is an extension to Secure Real-time 14 Transport Protocol (SRTP) that provides for the secure transport of 15 SRTP master keys, Rollover Counters, and other information. This 16 facility enables SRTP to work for decentralized conferences with 17 minimal control. 19 This note defines EKT, and also describes how to use it with SDP 20 Security Descriptions, DTLS-SRTP, and MIKEY. With EKT, these other 21 key management protocols provide an EKT key to everyone in a session, 22 and EKT coordinates the SRTP keys within the session. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Conventions Used In This Document . . . . . . . . . . . . 5 61 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 5 62 2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Packet Processing and State Machine . . . . . . . . . . . 8 64 2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 65 2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 66 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . 12 68 2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 12 69 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 70 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.6. Timing and Reliability Consideration . . . . . . . . . . 14 72 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 15 73 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 15 74 3.2. Relationship between EKT and SDP Security Descriptions . 16 75 3.3. Overview of Combined EKT and SDP Security Description 76 Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 77 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 18 78 3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . 18 79 3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 19 80 3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 19 81 3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 19 82 3.5.1. Generating the Initial Offer - Unicast Streams . . . 19 83 3.5.2. Generating the Initial Answer - Unicast Streams . . . 20 84 3.5.3. Processing of the Initial Answer - Unicast Streams . 21 85 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . 22 86 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 23 87 3.8. Backwards Compatibility Considerations . . . . . . . . . 23 88 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 25 90 4.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 25 91 4.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 25 92 4.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 27 93 4.3.1. Generating the Initial Offer . . . . . . . . . . . . 27 94 4.3.2. Generating the Initial Answer . . . . . . . . . . . . 28 95 4.3.3. Processing the Initial Answer . . . . . . . . . . . . 28 96 4.3.4. Sending DTLS EKT Key Reliably . . . . . . . . . . . . 29 97 4.3.5. Modifying the Session . . . . . . . . . . . . . . . . 29 98 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 29 99 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 31 100 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 32 101 5.2.1. Generating the Initial Offer . . . . . . . . . . . . 32 102 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 33 103 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 33 104 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 34 105 6. Using EKT for interoperability between key management systems 34 106 7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 35 107 7.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 36 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 110 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 113 11.2. Informative References . . . . . . . . . . . . . . . . . 40 114 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with 115 Security Descriptions . . . . . . . . . . . . . . . 41 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 118 1. Introduction 120 RTP is designed to allow decentralized groups with minimal control to 121 establish sessions, such as for multimedia conferences. 122 Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many 123 minimal-control scenarios, because it requires that SSRC values and 124 other data be coordinated among all of the participants in a session. 125 For example, if a participant joins a session that is already in 126 progress, that participant needs to be told the SRTP keys (and SSRC, 127 ROC and other details) of the other SRTP sources. 129 The inability of SRTP to work in the absence of central control was 130 well understood during the design of the protocol; the omission was 131 considered less important than optimizations such as bandwidth 132 conservation. Additionally, in many situations SRTP is used in 133 conjunction with a signaling system that can provide most of the 134 central control needed by SRTP. However, there are several cases in 135 which conventional signaling systems cannot easily provide all of the 136 coordination required. It is also desirable to eliminate the layer 137 violations that occur when signaling systems coordinate certain SRTP 138 parameters, such as SSRC values and ROCs. 140 This document defines Encrypted Key Transport (EKT) for SRTP, an 141 extension to SRTP that fits within the SRTP framework and reduces the 142 amount of external signaling control that is needed in an SRTP 143 session. EKT securely distributes the SRTP master key and other 144 information for each SRTP source (SSRC), using SRTCP or SRTP to 145 transport that information. With this method, SRTP entities are free 146 to choose SSRC values as they see fit, and to start up new SRTP 147 sources (SSRC) with new SRTP master keys (see Section 2.2) within a 148 session without coordinating with other entities via external 149 signaling or other external means. This fact allows to reinstate the 150 RTP collision detection and repair mechanism, which is nullified by 151 the current SRTP specification because of the need to control SSRC 152 values closely. An SRTP endpoint using EKT can generate new keys 153 whenever an existing SRTP master key has been overused, or start up a 154 new SRTP source (SSRC) to replace an old SRTP source that has reached 155 the packet-count limit. However, EKT does not allow SRTP's ROC to 156 rollover; that requires re-keying outside of EKT (e.g., using MIKEY 157 or DTLS-SRTP). EKT also solves the problem in which the burst loss 158 of the N initial SRTP packets can confuse an SRTP receiver, when the 159 initial RTP sequence number is greater than or equal to 2^16 - N. 160 These features can simplify many architectures that implement SRTP. 162 EKT provides a way for an SRTP session participant, either a sender 163 or receiver, to securely transport its SRTP master key and current 164 SRTP rollover counter to the other participants in the session. This 165 data, possibly in conjunction with additional data provided by an 166 external signaling protocol, furnishes the information needed by the 167 receiver to instantiate an SRTP/SRTCP receiver context. 169 EKT does not control the manner in which the SSRC is generated; it is 170 only concerned with their secure transport. Those values may be 171 generated on demand by the SRTP endpoint, or may be dictated by an 172 external mechanism such as a signaling agent or a secure group 173 controller. 175 EKT is not intended to replace external key establishment mechanisms 176 such as SDP Security Descriptions [RFC4568], DTLS-SRTP [RFC5764], or 177 MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with 178 those methods, and it relieves them of the burden of tightly 179 coordinating every SRTP source (SSRC) among every SRTP participant. 181 1.1. History 183 [[RFC Editor Note: please remove this section prior to publication as 184 an RFC.]] 186 A substantial change occurred between the EKT documents draft-ietf- 187 avt-srtp-ekt-03 and draft-ietf-avtcore-srtp-ekt-00. The change makes 188 it possible for the EKT data to be removed from a packet without 189 affecting the ability of the receiver to correctly process the data 190 that is present in that packet. This capability facilitates 191 interoperability between SRTP implementations with different SRTP key 192 management methods. The changes also greatly simplify the EKT 193 processing rules, and makes the EKT data that must be carried in SRTP 194 and/or SRTCP packets somewhat larger. 196 In draft-ietf-avtcore-srtp-ekt-02 (this document), SRTP master keys 197 have to be always generated randomly and never shared, MKI is no 198 longer allowed with EKT (as MKI duplicates some of EKT's functions), 199 and text clarifies that EKT must be negotiated during call setup. 200 Some text was consolidated and re-written, notably Section 2.6 201 ("Timing and Reliability"). 203 1.2. Conventions Used In This Document 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 2. Encrypted Key Transport 211 In EKT, an SRTP master key is encrypted with a key encrypting key and 212 the resulting ciphertext is transported in selected SRTCP packets or 213 in selected SRTP packets. The key encrypting key is called an EKT 214 key. A single such key suffices for a single SRTP session, 215 regardless of the number of participants in that session. However, 216 there can be multiple EKT keys used within a particular session. 218 EKT defines a new method of providing SRTP master keys to an 219 endpoint. In order to convey the ciphertext of the SRTP master key, 220 and other additional information, an additional EKT field is added to 221 SRTP or SRTCP packets. When added to SRTCP, the EKT field appears at 222 the end of the packet, after the authentication tag, if that tag is 223 present, or after the SRTCP index otherwise. When added to SRTP, The 224 EKT field appears at the end of the SRTP packet, after the 225 authentication tag (if that tag is present), or after the ciphertext 226 of the encrypted portion of the packet otherwise. 228 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 229 Identifier) or with SRTP's [RFC3711], as those SRTP 230 features duplicate some of the functions of EKT. 232 2.1. EKT Field Formats 234 The EKT Field uses one of the two formats defined below. These two 235 formats can always be unambiguously distinguished on receipt by 236 examining the final bit of the EKT Field, which is also the final bit 237 of the SRTP or SRTCP packet. The first format is the Full EKT Field 238 (or Full_EKT_Field), and the second is the Short EKT Field (or 239 Short_EKT_Field). The formats are defined as 240 EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || ISN 242 EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext) 244 Full_EKT_Field = EKT_Ciphertext || SPI || '1' 246 Short_EKT_Field = Reserved || '0' 248 Figure 1: EKT data formats 250 Here || denotes concatenation, and '1' and '0' denote single one and 251 zero bits, respectively. These fields and data elements are defined 252 as follows: 254 EKT_Plaintext: The data that is input to the EKT encryption 255 operation. This data never appears on the wire, and is used only 256 in computations internal to EKT. 258 EKT_Ciphertext: The data that is output from the EKT encryption 259 operation, described in Section 2.3. This field is included in 260 SRTP and SRTCP packets when EKT is in use. The length of this 261 field is variable, and is equal to the ciphertext size N defined 262 in Section 2.3. Note that the length of the field is inferable 263 from the SPI field, since the particular EKT cipher used by the 264 sender of a packet can be inferred from that field. 266 SRTP_Master_Key: On the sender side, the SRTP Master Key associated 267 with the indicated SSRC. The length of this field depends on the 268 cipher suite negotiated during call setup for SRTP or SRTCP. 270 SSRC: On the sender side, this field is the SSRC for this SRTP 271 source. The length of this field is fixed at 32 bits. 273 Rollover Counter (ROC): On the sender side, this field is set to the 274 current value of the SRTP rollover counter in the SRTP context 275 associated with the SSRC in the SRTP or SRTCP packet. The length 276 of this field is fixed at 32 bits. 278 Initial Sequence Number (ISN): If this field is nonzero, it 279 indicates the RTP sequence number of the initial RTP packet that 280 is protected using the SRTP master key conveyed (in encrypted 281 form) by the EKT Ciphertext field of this packet. When this field 282 is present in an RTCP packet it indicates the RTP sequence number 283 of the first RTP packet encrypted by this master key. If the ISN 284 field is zero, it indicates that the initial RTP/RTCP packet 285 protected using the SRTP master key conveyed in this packet 286 preceded, or was concurrent with, the last roll-over of the RTP 287 sequence number, and thus should be used as the current master key 288 for processing this packet. The length of this field is fixed at 289 16 bits. 291 Security Parameter Index (SPI): This field is included in SRTP and 292 SRTCP packets when EKT is in use. It indicates the appropriate 293 EKT key and other parameters for the receiver to use when 294 processing the packet. It is an "index" into a table of 295 possibilities (which are established via signaling or some other 296 out-of-band means), much like the IPsec Security Parameter Index 297 [RFC4301]. The length of this field is fixed at 15 bits. The 298 parameters identified by this field are: 300 * The EKT key used to process the packet. 302 * The EKT cipher used to process the packet. 304 * The Secure RTP parameters associated with the SRTP Master Key 305 carried by the packet and the SSRC value in the packet. 306 Section 8.2. of [RFC3711] summarizes the parameters defined by 307 that specification. 309 * The Master Salt associated with the Master Key. (This value is 310 part of the parameters mentioned above, but we call it out for 311 emphasis.) The Master Salt is communicated separately, via 312 signaling, typically along with the EKT key. 314 Together, these data elements are called an EKT parameter set. 315 Within each SRTP session, each distinct EKT parameter set that may 316 be used MUST be associated with a distinct SPI value, to avoid 317 ambiguity. 319 Reserved: The length of this field is 7 bits. MUST be all zeros on 320 transmission, and MUST be ignored on reception. 322 The Full_EKT_Field and Short_EKT_Field formats are shown in Figure 2 323 and Figure 3, respectively. These figures show the on-the-wire data. 324 The Ciphertext field holds encrypted data, and thus has no apparent 325 inner structure. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 : : 331 : EKT Ciphertext : 332 : : 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Security Parameter Index |1| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 2: Full EKT Field format 338 0 1 2 3 4 5 6 7 8 339 +-+-+-+-+-+-+-+-+-+ 340 | Reserved |0| 341 +-+-+-+-+-+-+-+-+-+ 343 Figure 3: Short EKT Field format 345 2.2. Packet Processing and State Machine 347 At any given time, each SRTP/SRTCP source (SSRC) has associated with 348 it a single EKT parameter set. This parameter set is used to process 349 all outbound packets, and is called the outbound parameter set. 350 There may be other EKT parameter sets that are used by other SRTP/ 351 SRTCP sources in the same session, including other SRTP/SRTCP sources 352 on the same endpoint (e.g., one endpoint with voice and video might 353 have two EKT parameter sets, or there might be multiple video sources 354 on an endpoint each with their own EKT parameter set). All of these 355 EKT parameter sets SHOULD be stored by all of the participants in an 356 SRTP session, for use in processing inbound SRTP and SRTCP traffic. 358 All SRTP master keys MUST NOT be re-used, MUST be randomly generated 359 according to [RFC4086], MUST NOT be equal to or derived from other 360 SRTP master keys. 362 2.2.1. Outbound Processing 364 See Section 2.6 which describes when to send an EKT packet and 365 describes if a Full EKT Field or Short EKT Field is sent. 367 When an SRTP or SRTCP packet is to be sent, the EKT field for that 368 packet is created as follows, or uses an equivalent set of steps. 369 The creation of the EKT field MUST precede the normal SRTP or SRTCP 370 packet processing. The ROC used in EKT processing MUST be the same 371 as the one used in the SRTP processing. 373 If the Short format is used, an all-zero octet is appended to the 374 packet. Otherwise, processing continues as follows. 376 The Rollover Counter field in the packet is set to the current value 377 of the SRTP rollover counter (represented as an unsigned integer in 378 network byte order). 380 The Initial Sequence Number field is set to zero, if the initial RTP 381 packet protected using the current SRTP master key for this source 382 preceded, or was concurrent with, the last roll-over of the RTP 383 sequence number. Otherwise, that field is set to the value of the 384 RTP sequence number of the initial RTP packet that was or will be 385 protected by that key. See "rekey" in Section 2.6. The rekeying 386 event MUST NOT change the value of ROC (otherwise, the current value 387 of the ROC would not be known to late joiners of existing sessions). 388 This means rekeying near the end of sequence number space (e.g., 100 389 packets before sequence number 65535) is not possible because ROC 390 needs to roll over. 392 The Security Parameter Index field is set to the value of the 393 Security Parameter Index that is associated with the outbound 394 parameter set. 396 The EKT_Plaintext field is computed from the SRTP Master Key, SSRC, 397 ROC, and ISN fields, as shown in Figure 1. 399 The EKT_Ciphertext field is set to the ciphertext created by 400 encrypting the EKT_Plaintext with the EKT cipher, using the EKT Key 401 as the encryption key. The encryption process is detailed in 402 Section 2.3. Implementations MAY cache the value of this field to 403 avoid recomputing it for each packet that is sent. 405 Implementation note: Because of the format of the Full EKT Field, a 406 packet containing the Full EKT Field MUST be sent when the ROC 407 changes (i.e., every 2^32 packets). 409 2.2.2. Inbound Processing 411 When an SRTP or SRTCP packet containing a Full EKT Field or Short EKT 412 Field is received, it is processed as follows or using an equivalent 413 set of steps. Inbound EKT processing MUST take place prior to the 414 usual SRTP or SRTCP processing. Implementation note: the receiver 415 may want to have a sliding window to retain old master keys for some 416 brief period of time, so that out of order packets can be processed. 417 The following steps show processing as packets are received in order. 419 1. The final bit is checked to determine which EKT format is in use. 420 If the packet contains a Short EKT Field then the Short EKT Field 421 is removed and normal SRTP or SRTCP processing is applied. If 422 the packet contains a Full EKT Field, then processing continues 423 as described below. 425 2. The Security Parameter Index (SPI) field is checked to determine 426 which EKT parameter set should be used when processing the 427 packet. If multiple parameter sets have been defined for the 428 SRTP session, then the one that is associated with the value of 429 the SPI field in the packet is used. This parameter set is 430 called the matching parameter set below. If there is no matching 431 SPI, then the verification function MUST return an indication of 432 authentication failure, and the steps described below are not 433 performed. 435 3. The EKT_Ciphertext is decrypted using the EKT_Key and EKT_Cipher 436 in the matching parameter set, as described in Section 2.3. If 437 the EKT decryption operation returns an authentication failure, 438 then the packet processing halts with an indication of failure. 439 Otherwise, the resulting EKT_Plaintext is parsed as described in 440 Figure 1, to recover the SRTP Master Key, SSRC, ROC, and ISN 441 fields. 443 4. The SSRC field output from the decryption operation is compared 444 to the SSRC field from the SRTP header. If the values of the two 445 fields do not match, then packet processing halts with an 446 indication of failure. Otherwise, it continues as follows. 448 5. If an SRTP context associated with the SSRC in the previous step 449 already exists and the ROC from the EKT_Plaintext is less than 450 the ROC in the SRTP context, then EKT processing halts and the 451 packet is processed as an out-of-order packet (if within the 452 implementation's sliding window) or dropped (as it is a replay). 453 Otherwise, the ROC in the SRTP context is set to the value of the 454 ROC from the EKT_Plaintext, and the SRTP Master Key from the 455 EKT_Plaintext is accepted as the SRTP master key corresponding to 456 the SSRC indicated in the EKT_Plaintext, beginning at the 457 sequence number indicated by the ISN (see next step). 459 6. If the ISN from the EKT_Plaintext is less than the RTP sequence 460 number of an authenticated received SRTP packet, then EKT 461 processing halts (as this is a replay). If the Initial Sequence 462 Number field is nonzero, then the initial sequence number for the 463 SRTP master key is set to the packet index created by appending 464 that field to the current rollover counter and treating the 465 result as a 48-bit unsigned integer. The initial sequence number 466 for the master key is equivalent to the "From" value of the 467 pair of indices (Section 8.1.1 of [RFC3711]) that can 468 be associated with a master key. 470 7. The newly accepted SRTP master key, the SRTP parameters from the 471 matching parameter set, and the SSRC from the packet are stored 472 in the crypto context associated with the SRTP source (SSRC). 473 The SRTP Key Derivation algorithm is run in order to compute the 474 SRTP encryption and authentication keys, and those keys are 475 stored for use in SRTP processing of inbound packets. The Key 476 Derivation algorithm takes as input the newly accepted SRTP 477 master key, along with the Master Salt from the matching 478 parameter set. 480 8. At this point, EKT processing has successfully completed, and the 481 normal SRTP or SRTCP processing takes place. 483 Implementation note: the value of the EKT Ciphertext field is 484 identical in successive packets protected by the same EKT 485 parameter set and the same SRTP master key, ROC, and ISN. 486 This ciphertext value MAY be cached by an SRTP receiver to 487 minimize computational effort by noting when the SRTP master 488 key is unchanged and avoiding repeating Steps 2 through 6. 490 2.3. Ciphers 492 EKT uses an authenticated cipher to encrypt the EKT Plaintext, which 493 is comprised of the SRTP master keys, SSRC, ROC, and ISN. We first 494 specify the interface to the cipher, in order to abstract the 495 interface away from the details of that function. We then define the 496 cipher that is used in EKT by default. The default cipher described 497 in Section 2.3.1 MUST be implemented, but another cipher that 498 conforms to this interface MAY be used, in which case its use MUST be 499 coordinated by external means (e.g., key management). 501 The master salt length for the offered cipher suites MUST be the 502 same. In practice the easiest way to achieve this is by offering the 503 same crypto suite. 505 An EKT cipher consists of an encryption function and a decryption 506 function. The encryption function E(K, P) takes the following 507 inputs: 509 o a secret key K with a length of L bytes, and 511 o a plaintext value P with a length of M bytes. 513 The encryption function returns a ciphertext value C whose length is 514 N bytes, where N is at least M. The decryption function D(K, C) 515 takes the following inputs: 517 o a secret key K with a length of L bytes, and 519 o a ciphertext value C with a length of N bytes. 521 The decryption function returns a plaintext value P that is M bytes 522 long, or returns an indication that the decryption operation failed 523 because the ciphertext was invalid (i.e. it was not generated by the 524 encryption of plaintext with the key K). 526 These functions have the property that D(K, E(K, P)) = P for all 527 values of K and P. Each cipher also has a limit T on the number of 528 times that it can be used with any fixed key value. For each key, 529 the encryption function MUST NOT be invoked on more than T distinct 530 values of P, and the decryption function MUST NOT be invoked on more 531 than T distinct values of C. 533 The length of the EKT Plaintext is ten bytes, plus the length of the 534 SRTP Master Key. 536 Security requirements for EKT ciphers are discussed in Section 8. 538 2.3.1. The Default Cipher 540 The default EKT Cipher is the Advanced Encryption Standard (AES) 541 [FIPS197] Key Wrap with Padding [RFC5649] algorithm. It requires a 542 plaintext length M that is at least one octet, and it returns a 543 ciphertext with a length of N = M + 8 octets. It can be used with 544 key sizes of L = 16, 24, and 32, and its use with those key sizes is 545 indicated as AESKW_128, AESKW_192, and AESKW_256, respectively. The 546 key size determines the length of the AES key used by the Key Wrap 547 algorithm. With this cipher, T=2^48. 549 length of length of 550 SRTP EKT EKT EKT length of 551 transform transform plaintext ciphertext Full EKT Field 552 --------- ------------ --------- ---------- -------------- 553 AES-128 AESKW_128 (m) 26 40 42 554 AES-192 AESKW_192 34 48 50 555 AES-256 AESKW_256 42 56 58 556 F8-128 AESKW_128 26 40 42 557 SEED-128 AESKW_128 26 40 42 559 Figure 4: AESKW Table 561 The mandatory to implement transform is AESKW_128, indicated by (m). 563 As AES-128 is the mandatory to implement transform in SRTP [RFC3711], 564 AESKW_128 MUST be implemented for EKT. 566 For all the SRTP transforms listed in the table, the corresponding 567 EKT transform MUST be used, unless a stronger EKT transform is 568 negotiated by key management. 570 2.3.2. Other EKT Ciphers 572 Other specifications may extend this one by defining other EKT 573 ciphers per Section 9. This section defines how those ciphers 574 interact with this specification. 576 An EKT cipher determines how the EKT Ciphertext field is written, and 577 how it is processed when it is read. This field is opaque to the 578 other aspects of EKT processing. EKT ciphers are free to use this 579 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 580 an input. The values of the parameters L, M, N, and T MUST be 581 defined by each EKT cipher, and those values MUST be inferable from 582 the EKT parameter set. 584 2.4. Synchronizing Operation 586 A participant in a session MAY opt to use a particular EKT parameter 587 set to protect outbound packets after it accepts that EKT parameter 588 set for protecting inbound traffic. In this case, the fact that one 589 participant has changed to using a new EKT key for outbound traffic 590 can trigger other participants to switch to using the same key. 592 If a source has its EKT key changed by key management, it MUST also 593 change its SRTP master key, which will cause it to send out a new 594 Full EKT Field. This ensures that if key management thought the EKT 595 key needs changing (due to a participant leaving or joining) and 596 communicated that in key management to a source, the source will also 597 change its SRTP master key, so that traffic can be decrypted only by 598 those who know the current EKT key. 600 The use of EKT MUST be negotiated during key management or call setup 601 (e.g., using DTLS-SRTP, Security Descriptions, MIKEY, or similar). 603 2.5. Transport 605 EKT SHOULD be used over SRTP, and MAY be used over SRTCP. SRTP is 606 preferred because it shares fate with transmitted media and because 607 SRTP rekeying can occur without concern for RTCP transmission limits. 609 The packet processing, state machine, and Authentication Tag format 610 for EKT over SRTP are nearly identical to that for EKT over SRTCP. 611 Differences are highlighted in Section 2.2.1 and Section 2.2.2. 613 The Full EKT Field is appended to the SRTP or SRTCP payload and is 614 42, 50, or 58 octets long for AES-128, AES-192, or AES-192, 615 respectively. This length impacts the maximum payload size of the 616 SRTP (or SRTCP) packet itself. To remain below the network path MTU, 617 senders SHOULD constrain the SRTP (or SRTCP) payload size by this 618 length of the Full EKT Field. 620 EKT can be transported over SRTCP, but some of the information that 621 it conveys is used for SRTP processing; some elements of the EKT 622 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 623 packets can be lost and both SRTP and SRTCP packets may be delivered 624 out of order. This can lead to various race conditions if EKT is 625 transported over SRTCP but not SRTP, which we review below. 627 The ROC signaled via EKT over SRTCP may be off by one when it is 628 received by the other party(ies) in the session. In order to deal 629 with this, receivers should simply follow the SRTP packet index 630 estimation procedures defined in Section 3.3.1 [RFC3711]. 632 2.6. Timing and Reliability Consideration 634 A system using EKT has the SRTP keys distributed with EKT, rather 635 than with call signaling. This means a receiver can immediately 636 decrypt an SRTP (or SRTCP packet) using that new key, provided the 637 SRTP packet (or SRTCP packet) also contains the EKT key. However, a 638 receiver cannot immediately authenticate or decrypt an SRTCP packets 639 without the EKT key. Fortunately, the inability to authenticate or 640 decrypt SRTCP has little immediate impact on the end user. 642 This section describes how to reliably and expediently deliver EKT 643 keys to receivers. 645 There are three cases to consider. The first case is a new sender 646 joining a session which needs to communicate its key to all the 647 receivers. The second case is a sender changing its key which needs 648 to be communicated to all the receivers. The third case is a new 649 receiver joining a session already in progress which needs to know 650 the sender's key. 652 New sender: A new sender SHOULD send a packet containing the Full EKT 653 Field as soon as possible, always before or coincident with sending 654 its initial SRTP packet. To accommodate packet loss, it is 655 RECOMMENDED that three consectutive packets contain the Full EKT 656 Field be transmitted. Inclusion of that Full EKT Field can be 657 stopped early if the sender determines all receivers have received 658 the new EKT key by receipt of an SRTCP receiver report or explicit 659 ACK for a sequence number with the new key. 661 Rekey: By sending EKT over SRTP, the rekeying event shares fate with 662 the SRTP packets protected with that new key. To avoid sending large 663 SRTP packets (such as video key frames) with the Full EKT Field, it 664 can be advantageous to send smaller SRTP packets with the Full EKT 665 Field with the Initial Sequence Number prior to the actual rekey 666 event, but this does eliminate the benefits of fate-sharing EKT with 667 the SRTP packets with the new key, which increases the chance a new 668 receiver won't have seen the new key. 670 New receiver: When a new receiver joins a session it does not need to 671 communicate its sending key (because it is a receiver). When a new 672 receiver joins a session the sender is generally unaware of the 673 receiver joining the session. Thus, senders SHOULD periodically 674 transmit the Full EKT Field. That interval depends on how frequently 675 new receivers join the session, the acceptable delay before those 676 receivers can start processing SRTP packets, and the acceptable 677 overhead of sending the Full EKT Field. The RECOMMENDED frequency is 678 the same as the key frame frequency if sending video or every 5 679 seconds. When joining a session it is likely that SRTP or SRTCP 680 packets might be received before a packet containing the Full EKT 681 Field is received. Thus, to avoid doubling the authentication 682 effort, an implementation joining an EKT session SHOULD buffer 683 received SRTP and SRTCP packets until it receives the Full EKT Field 684 packet and use the information in that packet to authenticate and 685 decrypt the received SRTP/SRTCP packets. 687 3. Use of EKT with SDP Security Descriptions 689 The SDP Security Descriptions (SDESC) [RFC4568] specification defines 690 a generic framework for negotiating security parameters for media 691 streams negotiated via the Session Description Protocol with the 692 "crypto" attribute and the Offer/Answer procedures defined in 693 [RFC3264]. In addition to the general framework, SDES also defines 694 how to use that framework specifically to negotiate security 695 parameters for Secure RTP. Below, we first provide a brief recap of 696 the crypto attribute when used for SRTP and we then explain how it is 697 complementary to EKT. In the rest of this Section, we provide 698 extensions to the crypto attribute and associated offer/answer 699 procedures to define its use with EKT. 701 3.1. SDP Security Descriptions Recap 703 The SRTP crypto attribute defined for SDESC contains a tag followed 704 by three types of parameters (refer to [RFC4568] for details): 706 o Crypto-suite. Identifies the encryption and authentication 707 transform. 709 o Key parameters. SRTP keying material and parameters. 711 o Session parameters. Additional (optional) SRTP parameters such as 712 Key Derivation Rate, Forward Error Correction Order, use of 713 unencrypted SRTP, and other parameters defined by SDESC. 715 The crypto attributes in the example SDP in Figure 5 illustrate these 716 parameters. 718 v=0 719 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 720 s=SRTP Discussion 721 i=A discussion of Secure RTP 722 u=http://www.example.com/seminars/srtp.pdf 723 e=marge@example.com (Marge Simpson) 724 c=IN IP4 192.0.2.12 725 t=2873397496 2873404696 726 m=audio 49170 RTP/SAVP 0 727 a=crypto:1 AES_CM_128_HMAC_SHA1_80 728 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20 729 FEC_ORDER=FEC_SRTP 730 a=crypto:2 F8_128_HMAC_SHA1_80 731 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjiiKt|2^20 732 FEC_ORDER=FEC_SRTP 734 Figure 5: SDP Security Descriptions example 736 For legibility the SDP shows line breaks that are not present on the 737 wire. 739 The first crypto attribute has the tag "1" and uses the crypto-suite 740 AES_CM_128_HMAC_SHA1_80. The "inline" parameter provides the SRTP 741 master key and salt and the master key lifetime (number of packets). 742 Finally, the FEC_ORDER session parameter indicates the order of 743 Forward Error Correction used (FEC is applied before SRTP processing 744 by the sender of the SRTP media). 746 The second crypto attribute has the tag "2", the crypto-suite 747 F8_128_HMAC_SHA1_80, two SRTP master keys and associated salts. 748 Finally, the FEC_ORDER session parameter indicates the order of 749 Forward Error Correction used. 751 3.2. Relationship between EKT and SDP Security Descriptions 753 SDP Security Descriptions [RFC4568] define a generic framework for 754 negotiating security parameters for media streams negotiated via the 755 Session Description Protocol by use of the Offer/Answer procedures 756 defined in [RFC3264]. In addition to the general framework, SDESC 757 also defines how to use it specifically to negotiate security 758 parameters for Secure RTP. 760 EKT and SDP Security Descriptions are complementary. SDP Security 761 Descriptions can negotiate several of the SRTP security parameters 762 (e.g., cipher and use of Master Key Identifier) as well as SRTP 763 master keys. SDESC, however, does not negotiate SSRCs and their 764 associated Rollover Counter (ROC). Instead, SDESC relies on a so- 765 called "late binding", where a newly observed SSRC will have its 766 crypto context initialized to a ROC value of zero. Clearly, this 767 does not work for participants joining an SRTP session that has been 768 established for a while and hence has a non-zero ROC. It is 769 impossible to use SDESC to join an SRTP session that is already in 770 progress. In this case, EKT on the endpoint running SDESC can 771 provide the additional signaling necessary to communicate the ROC 772 (Section 6.4.1 of [RFC4568]). The use of EKT solves this problem by 773 communicating the ROC associated with the SSRC in the media plane. 775 SDP Security Descriptions negotiates different SRTP master keys in 776 the send and receive direction. The offer contains the master key 777 used by the offerer to send media, and the answer contains the master 778 key used by the answerer to send media. Consequently, if media is 779 received by the offerer prior to the answer being received, the 780 offerer does not know the master key being used. Use of SDP security 781 preconditions can solve this problem, however it requires an 782 additional round-trip as well as a more complicated state machine. 783 EKT solves this problem by simply sending the master key used in the 784 media plane thereby avoiding the need for security preconditions. 786 If multiple crypto-suites were offered, the offerer also will not 787 know which of the crypto-suites offered was selected until the answer 788 is received. EKT solves this problem by using a correlator, the 789 Security Parameter Index (SPI), which uniquely identifies each crypto 790 attribute in the offer. 792 One of the primary call signaling protocols using offer/answer is the 793 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 794 message to initiate a media session and typically includes an offer 795 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 796 which potentially can lead to multiple answers being received. 797 SDESC, however, does not properly support this scenario, mainly 798 because SDP and RTP/RTCP does not contain sufficient information to 799 allow for correlation of an incoming RTP/RTCP packet with a 800 particular answer SDP. Note that extensions providing this 801 correlation do exist (e.g., Interactive Connectivity Establishment 802 (ICE)). SDESC addresses this point-to-multipoint problem by moving 803 each answer to a separate RTP transport address thereby turning a 804 point-to-multipoint scenario into multiple point-to-point scenarios. 805 There are however significant disadvantages to doing so. As long as 806 the crypto attribute in the answer does not contain any declarative 807 parameters that differ from those in the offer, EKT solves this 808 problem by use of the SPI correlator and communication of the 809 answerer's SRTP master key in EKT. 811 As can be seen from the above, the combination of EKT and SDESC 812 provides a better solution to SRTP negotiation for offer/answer than 813 either of them alone. SDESC negotiates the various SRTP crypto 814 parameters (which EKT does not), whereas EKT addresses the 815 shortcomings of SDESC. 817 3.3. Overview of Combined EKT and SDP Security Description Operation 819 We define three session extension parameters to SDESC to communicate 820 the EKT cipher, EKT key, and Security Parameter Index to the peer. 821 The original SDESC parameters are used as defined in [RFC4568], 822 however the procedures associated with the SRTP master key differ 823 slightly, since both SDESC and EKT communicate an SRTP master key. 824 In particular, the SRTP master key communicated via SDESC is used 825 only if there is currently no crypto context established for the SSRC 826 in question. This will be the case when an entity has received only 827 the offer or answer, but has yet to receive a valid EKT packet from 828 the peer. Once a valid EKT packet is received for the SSRC, the 829 crypto context is initialized accordingly, and the SRTP master key 830 will then be derived from the EKT packet. Subsequent offer/answer 831 exchanges do not change this: The most recent SRTP master key 832 negotiated via EKT will be used, or, if none is available for the 833 SSRC in question, the most recent SRTP master key negotiated via 834 offer/answer will be used. This is done to avoid race conditions 835 between the offer/answer exchange and EKT, even though this breaks 836 some offer/answer rules. Note that with the rules described in this 837 paragraph, once a valid EKT packet has been received for a given 838 SSRC, rekeying for that SSRC can only be done via EKT. The 839 associated SRTP crypto parameters however can be changed via SDESC. 841 3.4. EKT Extensions to SDP Security Descriptions 843 In order to use EKT and SDESC in conjunction with each other, the 844 following new SDESC session parameters are defined. These MUST NOT 845 appear more than once in a given crypto attribute: 847 EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key 849 EKT_Key: The EKT key used to encrypt the SRTP Master Key 851 EKT_SPI: The EKT Security Parameter Index 853 Below are details on each of these attributes. 855 3.4.1. EKT_Cipher 857 The (optional) EKT_Cipher parameter defines the EKT cipher used to 858 encrypt the EKT key within SRTP and SRTCP packets. The default value 859 is "AESKW_128" in accordance with Section 2.3.1. For the AES Key 860 Wrap cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are 861 defined for values of L=16, 24, and 32 respectively. In the Offer/ 862 Answer model, the EKT_Cipher parameter is a negotiated parameter. 864 3.4.2. EKT_Key 866 The (mandatory) EKT_Key parameter is the key K used to encrypt the 867 SRTP Master Key within SRTP and SRTCP packets. The value is base64 868 encoded with "=" padding if padding is necessary (see Section 3.2 and 869 4 of [RFC4648]). In the Offer/Answer model, the EKT_Key parameter is 870 a negotiated parameter. 872 3.4.3. EKT_SPI 874 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 875 It is encoded as an ASCII string representing the hexadecimal value 876 of the Security Parameter Index. The SPI identifies the *offer* 877 crypto attribute (including the EKT Key and Cipher) being used for 878 the associated SRTP session. A crypto attribute corresponds to an 879 EKT Parameter Set and hence the SPI effectively identifies a 880 particular EKT parameter set. Note that the scope of the SPI is the 881 SRTP session, which may or may not be limited to the scope of the 882 associated SIP dialog. In particular, if one of the participants in 883 an SRTP session is an SRTP translator, the scope of the SRTP session 884 is not limited to the scope of a single SIP dialog. However, if all 885 of the participants in the session are endpoints or mixers, the scope 886 of the SRTP session will correspond to a single SIP dialog. In the 887 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 889 3.5. Offer/Answer Procedures 891 In this section, we provide the offer/answer procedures associated 892 with use of the three new SDESC parameters defined in Section 3.4. 893 Since SDESC is defined only for unicast streams, we provide only 894 offer/answer procedures for unicast streams here as well. 896 3.5.1. Generating the Initial Offer - Unicast Streams 898 When the initial offer is generated, the offerer MUST follow the 899 steps defined in [RFC4568] Section 7.1.1 as well as the following 900 steps. 902 [[Editor's Note: following paragraph would benefit from rewording.]] 904 For each unicast media line using Security Descriptions and where use 905 of EKT is desired, the offerer MUST include one EKT_Key parameter and 906 one EKT_SPI parameter in at least one "crypto" attribute (see 907 [RFC4568]). The EKT_SPI parameter serves to identify the EKT 908 parameter set used for a particular SRTCP packet. Consequently, 909 within a single media line, a given EKT_SPI value MUST NOT be used 910 with multiple crypto attributes. Note that the EKT parameter set to 911 use for the session is not yet established at this point; each 912 offered crypto attribute contains a candidate EKT parameter set. 913 Furthermore, if the media line refers to an existing SRTP session, 914 then any SPI values used for EKT parameter sets in that session MUST 915 NOT be remapped to any different EKT parameter sets. When an offer 916 describes an SRTP session that is already in progress, the offer 917 SHOULD use an EKT parameter set (including EKT_SPI and EKT_KEY) that 918 is already in use. 920 If a given crypto attribute includes more than one set of SRTP key 921 parameters (SRTP master key, salt, lifetime), they MUST all use the 922 same salt. (EKT requires a single shared salt between all the 923 participants in the direct SRTP session). 925 As EKT is not defined for use with MKI, the offer and the answer MUST 926 NOT contain MKI. 928 Important Note: The scope of the offer/answer exchange is the SIP 929 dialog(s) established as a result of the INVITE, however the scope 930 of EKT is the direct SRTP session, i.e., all the participants that 931 are able to receive SRTP and SRTCP packets directly. If an SRTP 932 session spans multiple SIP dialogs, the EKT parameter sets MUST be 933 synchronized between all the SIP dialogs where SRTP and SRTCP 934 packets can be exchanged. In the case where the SIP entity 935 operates as an RTP mixer (and hence re-originates SRTP and SRTCP 936 packets with its own SSRC), this is not an issue, unless the mixer 937 receives traffic from the various participants on the same 938 destination IP address and port, in which case further 939 coordination of SPI values and crypto parameters may be needed 940 between the SIP dialogs (note that SIP forking with multiple early 941 media senders is an example of this). However, if it operates as 942 a transport translator (relay) then synchronized negotiation of 943 the EKT parameter sets on *all* the involved SIP dialogs will be 944 needed. This is non-trivial in a variety of use cases, and hence 945 use of the combined SDES/EKT mechanism with RTP translators should 946 be considered very carefully. It should be noted, that use of 947 SRTP with RTP translators in general should be considered very 948 carefully as well. 950 The EKT session parameters can either be included as optional or 951 mandatory parameters, however within a given crypto attribute, they 952 MUST all be either optional or mandatory. 954 3.5.2. Generating the Initial Answer - Unicast Streams 956 When the initial answer is generated, the answerer MUST follow the 957 steps defined in [RFC4568] Section 7.1.2 as well as the following 958 steps. 960 For each unicast media line using SDESC, the answerer examines the 961 associated crypto attribute(s) for the presence of EKT parameters. 962 If mandatory EKT parameters are included with a "crypto" attribute, 963 the answerer MUST support those parameters in order to accept that 964 offered crypto attribute. If optional EKT parameters are included 965 instead, the answerer MAY accept the offered crypto attribute without 966 using EKT. However, doing so will prevent the offerer from 967 processing any packets received before the answer. If neither 968 optional nor mandatory EKT parameters are included with a crypto 969 attribute, and that crypto attribute is accepted in the answer, EKT 970 MUST NOT be used. If a given a crypto attribute includes a mixture 971 of optional and mandatory EKT parameters, or an incomplete set of 972 mandatory EKT parameters, that crypto attribute MUST be considered 973 invalid. 975 When EKT is used with SDESC, the offerer and answerer MUST use the 976 same SRTP master salt. Thus, the SRTP key parameter(s) in the answer 977 crypto attribute MUST use the same master salt as the one accepted 978 from the offer. 980 When the answerer accepts the offered media line and EKT is being 981 used, the crypto attribute included in the answer MUST include the 982 same EKT parameter values as found in the accepted crypto attribute 983 from the offer (however, if the default EKT cipher is being used, it 984 may be omitted). Furthermore, the EKT parameters included MUST be 985 mandatory (i.e., no "-" prefix). 987 Acceptance of a crypto attribute with EKT parameters leads to 988 establishment of the EKT parameter set for the corresponding SRTP 989 session. Consequently, the answerer MUST send packets in accordance 990 with that particular EKT parameter set only. If the answerer wants 991 to enable the offerer to process SRTP packets received by the offerer 992 before it receives the answer, the answerer MUST NOT include any 993 declarative session parameters that either were not present in the 994 offered crypto attribute, or were present but with a different value. 995 Otherwise, the offerer's view of the EKT parameter set would differ 996 from the answerer's until the answer is received. Similarly, unless 997 the offerer and answerer has other means for correlating an answer 998 with a particular SRTP session, the answer SHOULD NOT include any 999 declarative session parameters that either were not present in the 1000 offered crypto attribute, or were present but with a different value. 1001 If this recommendation is not followed and the offerer receives 1002 multiple answers (e.g., due to SIP forking), the offerer may not be 1003 able to process incoming media stream packets correctly. 1005 3.5.3. Processing of the Initial Answer - Unicast Streams 1006 When the offerer receives the answer, it MUST perform the steps in 1007 [RFC4568] Section 7.1.3 as well as the following steps for each SRTP 1008 media stream it offered with one or more crypto lines containing EKT 1009 parameters in it. 1011 [[Editor's Note: following paragraph would benefit from rewording.]] 1013 If the answer crypto line contains EKT parameters, and the 1014 corresponding crypto line from the offer contained the same EKT 1015 values, use of EKT has been negotiated successfully and MUST be used 1016 for the media stream. When determining whether the values match, 1017 optional and mandatory parameters MUST be considered equal. 1018 Furthermore, if the default EKT cipher is being used, it MAY be 1019 either present or absent in the offer and/or answer. 1021 If the answer crypto line does not contain EKT parameters, then EKT 1022 MUST NOT be used for the corresponding SRTP session. Note that if 1023 the accepted crypto attribute contained mandatory EKT parameters in 1024 the offer, and the crypto attribute in the answer does not contain 1025 EKT parameters, then negotiation has failed (Section 5.1.3 of 1026 [RFC4568]). 1028 If the answer crypto line contains EKT parameters but the 1029 corresponding offered crypto line did not, or if the parameters don't 1030 match or are invalid, then the offerer MUST consider the crypto line 1031 invalid (see Section 7.1.3 of [RFC4568] for further operation). 1033 The EKT parameter set is established when the answer is received, 1034 however there are a couple of special cases to consider here. First 1035 of all, if an SRTP packet containing a Full EKT Field is received 1036 prior to the answer, then the EKT parameter set is established 1037 provisionally based on the SPI included. Once the answer (which may 1038 include declarative session parameters) is received, the EKT 1039 parameter set is fully established. The second case involves receipt 1040 of multiple answers due to SIP forking. In this case, there will be 1041 multiple EKT parameter sets; one for each SRTP session. As mentioned 1042 earlier, reliable correlation of SIP dialogs to SRTP sessions 1043 requires extensions, and hence if one or more of the answers include 1044 declarative session parameters, it may be difficult to fully 1045 establish the EKT parameter set for each SRTP session. In the 1046 absence of a specific correlation mechanism, it is RECOMMENDED, that 1047 such correlation be done based on the signaled receive IP-address in 1048 the SDP and the observed source IP-address in incoming SRTP/SRTCP 1049 packets, and, if necessary, the signaled receive UDP port and the 1050 observed source UDP port. 1052 3.6. SRTP-Specific Use Outside Offer/Answer 1053 Security Descriptions use for SRTP is not defined outside offer/ 1054 answer and hence neither does Security Descriptions with EKT. 1056 3.7. Modifying the Session 1058 When a media stream using the SRTP security descriptions has been 1059 established, and a new offer/answer exchange is performed, the 1060 offerer and answerer MUST follow the steps in Section 7.1.4 of 1061 [RFC4568] as well as the following steps. SDESC allows for all 1062 parameters of the session to be modified, and the EKT session 1063 parameters are no exception to that, however, there are a few 1064 additional rules to be adhered to when using EKT. 1066 It is permissible to start a session without the use of EKT, and then 1067 subsequently start using EKT, however the converse is not. Thus, 1068 once use of EKT has been negotiated on a particular media stream, EKT 1069 MUST continue to be used on that media stream in all subsequent offer 1070 /answer exchanges. 1072 The reason for this is that both SDESC and EKT communicate the SRTP 1073 Master Key with EKT Master Keys taking precedence. Reverting back to 1074 an SDESC-controlled master key in a synchronized manner is difficult. 1076 Once EKT is being used, the salt for the direct SRTP session MUST NOT 1077 be changed. Thus, a new offer/answer which does not create a new 1078 SRTP session (e.g., because it reuses the same IP address and port) 1079 MUST use the same salt for all crypto attributes as is currently used 1080 for the direct SRTP session. 1082 [[Editor's Note: following paragraph would benefit from re-arranging 1083 into earlier-described steps.]] 1085 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1086 value to a different EKT parameter set until 2^15 other mappings have 1087 been used within the SRTP session. In practice, this requirements is 1088 most easily met by using a monotonically increasing SPI value (modulo 1089 2^15 and starting with zero) per direct SRTP session. Note that a 1090 direct SRTP session may span multiple SIP dialogs, and in such cases 1091 coordination of SPI values across those SIP dialogs will be required. 1092 In the simple point-to-point unicast case without translators, the 1093 requirement simply applies within each media line in the SDP. In the 1094 point-to-multipoint case, the requirement applies across all the 1095 associated SIP dialogs. 1097 3.8. Backwards Compatibility Considerations 1099 Backwards compatibility can be achieved in a couple of ways. First 1100 of all, Security Descriptions allows for session parameters to be 1101 prefixed with "-" to indicate that they are optional. If the 1102 answerer does not support the EKT session parameters, such optional 1103 parameters will simply be ignored. When the answer is received, 1104 absence of the parameters will indicate that EKT is not being used. 1105 Receipt of SRTP or SRTCP packets prior to receipt of such an answer 1106 will obviously be problematic (as is normally the case for Security 1107 Descriptions without EKT). 1109 Alternatively, Security Descriptions allows for multiple crypto lines 1110 to be included for a particular media stream. Thus, two crypto lines 1111 that differ in their use of EKT parameters (presence in one, absence 1112 in the other) can be used as a way to negotiate use of EKT. When the 1113 answer is received, the accepted crypto attribute will indicate 1114 whether EKT is being used or not. 1116 3.9. Grammar 1118 The ABNF [RFC5234] syntax for the one new SDP Security Descriptions 1119 session parameter, EKT, comprising three parts is shown in Figure 6. 1121 ekt = "EKT=" cipher "|" key "|" spi 1122 cipher = cipher-ext / "AESKW_128" / "AESKW_192" / "AESKW_256" 1123 cipher-ext = 1*64(ALPHA / DIGIT / "_") 1124 key = 1*(base64) ; See Section 4 of [RFC4648] 1125 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1126 spi = 4HEXDIG ; See [RFC5234] 1128 Figure 6: ABNF for the EKT session parameters 1130 Using the example from Figure 6 with the EKT extensions to SDP 1131 Security Descriptions results in the following example SDP: 1133 v=0 1134 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1135 s=SRTP Discussion 1136 i=A discussion of Secure RTP 1137 u=http://www.example.com/seminars/srtp.pdf 1138 e=marge@example.com (Marge Simpson) 1139 c=IN IP4 192.0.2.12 1140 t=2873397496 2873404696 1141 m=audio 49170 RTP/SAVP 0 1142 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1143 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1144 FEC_ORDER=FEC_SRTP EKT=AESKW_128|WWVzQUxvdmVseUVLVGtleQ|AAE0 1145 a=crypto:2 F8_128_HMAC_SHA1_80 1146 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1147 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1148 FEC_ORDER=FEC_SRTP EKT=AESKW_128|VHdvTG92ZWx5RUtUa2V5cw|AAE0 1150 For legibility the SDP shows line breaks that are not present on the 1151 wire. 1153 4. Use of EKT with DTLS-SRTP Key Transport 1155 This document defines an extension to DTLS-SRTP called Key Transport. 1156 The EKT with the DTLS-SRTP Key Transport enables secure transport of 1157 EKT keying material from one DTLS-SRTP peer to another. This enables 1158 those peers to process EKT keying material in SRTP (or SRTCP) and 1159 retrieve the embedded SRTP keying material. This combination of 1160 protocols is valuable because it combines the advantages of DTLS 1161 (strong authentication of the endpoint and flexibility) with the 1162 advantages of EKT (allowing secure multiparty RTP with loose 1163 coordination and efficient communication of per-source keys). 1165 4.1. DTLS-SRTP Recap 1167 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 1168 to exchange keying material, algorithms, and parapeters for SRTP. 1169 The SRTP flow operates over the same transport as the DTLS-SRTP 1170 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 1171 performance and encryption flexibility benefits of SRTP with the 1172 flexibility and convenience of DTLS-integrated key and association 1173 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 1174 key management method for SRTP, and a new RTP-specific data format 1175 for DTLS. 1177 4.2. EKT Extensions to DTLS-SRTP 1179 This document adds a new TLS negotiated extension called "ekt". This 1180 adds a new TLS content type, EKT, and a new negotiated extension EKT. 1181 The negotiated extension MUST only be requested in conjunction with 1182 the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server 1183 MUST include "dtls-srtp-ekt" in its SDP (as a session or media level 1184 attribute) and "ekt" in its TLS ServerHello message. If a DTLS 1185 client includes "ekt" in its ClientHello, but does not receive "ekt" 1186 in the ServerHello, the DTLS client MUST NOT send DTLS packets with 1187 the "ekt" content-type. 1189 The formal description of the dtls-srtp-ekt attribute is defined by 1190 the following ABNF [RFC5234] syntax: 1192 attribute = "a=dtls-srtp-ekt" 1194 Using the syntax described in DTLS [RFC6347], the following 1195 structures are used: 1197 enum { 1198 ekt_key(0), 1199 ekt_key_ack(1), 1200 ekt_key_error(254), 1201 (255) 1202 } SRTPKeyTransportType; 1204 struct { 1205 SRTPKeyTransportType keytrans_type; 1206 uint24 length; 1207 uint16 message_seq; 1208 uint24 fragment_offset; 1209 uint24 fragment_length; 1210 select (SRTPKeyTransportType) { 1211 case ekt_key: 1212 EKTkey; 1213 }; 1214 } KeyTransport; 1216 enum { 1217 RESERVED(0), 1218 AESKW_128(1), 1219 AESKW_192(2), 1220 AESKW_256(3), 1221 } ektcipher; 1223 struct { 1224 ektcipher EKT_Cipher; 1225 uint EKT_Key_Value<1..256>; 1226 uint EKT_Master_Salt<1..256>; 1227 uint16 EKT_SPI; 1228 } EKTkey; 1230 Figure 7: Additional TLS Data Structures 1232 The diagram below shows a message flow of DTLS client and DTLS server 1233 using the DTLS-SRTP Key Transport extension. SRTP packets exchanged 1234 prior to the ekt_message are encrypted using the SRTP master key 1235 derived from the normal DTLS-SRTP key derivation function. After the 1236 ekt_key message, they can be encrypted using the SRTP key carried by 1237 EKT. 1239 Client Server 1241 ClientHello + use_srtp + EKT 1242 --------> 1243 ServerHello + use_srtp + EKT 1244 Certificate* 1246 ServerKeyExchange* 1247 CertificateRequest* 1248 <-------- ServerHelloDone 1249 Certificate* 1250 ClientKeyExchange 1251 CertificateVerify* 1252 [ChangeCipherSpec] 1253 Finished --------> 1254 [ChangeCipherSpec] 1255 <-------- Finished 1256 SRTP packets <-------> SRTP packets 1257 SRTP packets <-------> SRTP packets 1258 ekt_key --------> 1259 SRTP packets <-------> SRTP packets 1260 SRTP packets <-------> SRTP packets 1262 Figure 8: Handshake Message Flow 1264 4.3. Offer/Answer Considerations 1266 This section describes Offer/Answer considerations for the use of EKT 1267 together with DTLS-SRTP for unicast and multicast streams. The 1268 offerer and answerer MUST follow the procedures specified in 1269 [RFC5764] as well as the following ones. 1271 As most DTLS-SRTP processing is performed on the media channel, 1272 rather than in SDP, there is little processing performed in SDP other 1273 than informational and to redirect DTLS-SRTP to an alternate host. 1274 Advertising support for the extension is necessary in SDP because in 1275 some cases it is required to establish an SRTP call. For example, a 1276 mixer may be able to only support SRTP listeners if those listeners 1277 implement DTLS Key Transport (because it lacks the CPU cycles 1278 necessary to encrypt SRTP uniquely for each listener). 1280 4.3.1. Generating the Initial Offer 1282 The initial offer contains a new SDP attribute, "dtls-srtp-ekt", 1283 which contains no value. This attribute MUST only appear at the 1284 media level. This attribute indicates the offerer is capable of 1285 supporting DTLS-SRTP with EKT extensions, and indicates the desire to 1286 use the "ekt" extension during the DTLS-SRTP handshake. 1288 An example of SDP containing the dtls-srtp-ekt attribute:: 1290 v=0 1291 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1292 s=SRTP Discussion 1293 i=A discussion of Secure RTP 1294 u=http://www.example.com/seminars/srtp.pdf 1295 e=marge@example.com (Marge Simpson) 1296 c=IN IP4 192.0.2.12 1297 t=2873397496 2873404696 1298 m=audio 49170 UDP/TLS/RTP/SAVP 0 1299 a=fingerprint:SHA-1 1300 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1301 a=dtls-srtp-ekt 1303 For legibility the SDP shows line breaks that are not present on the 1304 wire. 1306 4.3.2. Generating the Initial Answer 1308 Upon receiving the initial offer, the presence of the dtls-srtp-ekt 1309 attribute indicates a desire to receive the EKT extension in the 1310 DTLS-SRTP handshake. DTLS messages should be constructed according 1311 to those two attributes. 1313 If the answerer does not wish to perform EKT, it MUST NOT include a 1314 =dtls-srtp-ekt in the SDP answer, and it MUST NOT negotiate EKT 1315 during its DTLS-SRTP exchange. 1317 Otherwise, the dtls-srtp-ekt attribute SHOULD be included in the 1318 answer, and EKT SHOULD be negotiated in the DTLS-SRTP handshake. 1320 4.3.3. Processing the Initial Answer 1322 The presence of the dtls-srtp-ekt attribute indicates a desire by the 1323 answerer to perform DTLS-SRTP with EKT extensions. There are two 1324 indications the remote peer does not want to do EKT: the dtls-srtp- 1325 ekt attribute is not present in the answer, or the DTLS-SRTP exchange 1326 fails to negotiate the EKT extension. If the dtls-srtp-ekt attribute 1327 is not present in the answer, the DTLS-SRTP exchange MUST NOT attempt 1328 to negotiate the EKT extension. If the dtls-srtp-ekt attribute is 1329 present in the answer but the DTLS-SRTP exchange fails to negotiate 1330 the EKT extension, EKT MUST NOT be used with that media stream. 1332 After successful DTLS negotiation of the EKT extension, the DTLS 1333 client and server MAY exchange SRTP packets, encrypted using the KDF 1334 described in [RFC5764]. This is normal and expected, even if Key 1335 Transport was negotiated by both sides, as neither side may (yet) 1336 have a need to alter the SRTP key. However, it is also possible that 1337 one (or both) peers will immediately send an EKT packet before 1338 sending any SRTP, and also possible that SRTP, encrypted with an 1339 unknown key, may be received before the EKT packet is received. 1341 4.3.4. Sending DTLS EKT Key Reliably 1343 In the absence of a round trip time estimate, the DTLS ekt_key 1344 message is sent using an exponential backoff initialized to 250ms, so 1345 that if the first message is sent at time 0, the next transmissions 1346 are at 250ms, 500ms, 1000ms, and so on. If a recent round trip time 1347 estimate is available, exponential backoff is used with the first 1348 transmission at 1.5 times the round trip time estimate. In either 1349 case, re-transmission stops when ekt_key_ack or ekt_key_error message 1350 is received for the matching message_seq. 1352 4.3.5. Modifying the Session 1354 As DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel (media 1355 channel) rather than signaling, no special processing for modifying 1356 the session is necessary. 1358 If the initial offer and initial answer both contained EKT attributes 1359 (indicating the answerer desired to perform EKT), a subsequent offer/ 1360 answer exchange MUST also contain those same EKT attributes. If not, 1361 operation is undefined and the sesion MAY be terminated. If the 1362 initial offer and answer failed to negotiate EKT (that is, the answer 1363 did not contain EKT attributes), EKT negotiation failed and a 1364 subsequent offer SHOULD NOT include EKT attributes. 1366 5. Use of EKT with MIKEY 1368 The advantages outlined in Section 1 are useful in some scenarios in 1369 which MIKEY is used to establish SRTP sessions. In this section, we 1370 briefly review MIKEY and related work, and discuss these scenarios. 1372 An SRTP sender or a group controller can use MIKEY to establish a 1373 SRTP cryptographic context. This capability includes the 1374 distribution of a TEK generation key (TGK) or the TEK itself, 1375 security policy payload, crypto session bundle ID (CSB_ID) and a 1376 crypto session ID (CS_ID). The TEK directly maps to an SRTP master 1377 key, whereas the TGK is used along with the CSB_ID and a CS_ID to 1378 generate a TEK. The CS_ID is used to generate multiple TEKs (SRTP 1379 master keys) from a single TGK. For a media stream in SDP, MIKEY 1380 allocates two consecutive numbers for the crypto session IDs, so that 1381 each direction uses a different SRTP master key (see [RFC4567]). 1383 The MIKEY specification [RFC3830] defines three modes to exchange 1384 keys, associated parameters and to protect the MIKEY message: pre- 1385 shared key, public-key encryption and Diffie-Hellman key exchange. 1386 In the first two modes the MIKEY initiator only chooses and 1387 distributes the TGK or TEK, whereas in the third mode both MIKEY 1388 entities (the initiator and responder) contribute to the keys. All 1389 three MIKEY modes have in common that for establishing a SRTP session 1390 the exchanged key is valid for the send and receive direction. 1391 Especially for group communications it is desirable to update the 1392 SRTP master key individually per direction. EKT provides this 1393 property by distributing the SRTP master key within the SRTP/SRTCP 1394 packet. 1396 MIKEY already supports synchronization of ROC values between the 1397 MIKEY initiator and responder. The SSRC / ROC value pair is part of 1398 the MIKEY Common Header payload. This allows providing the current 1399 ROC value to late joiners of a session. However, in some scenarios a 1400 key management based ROC synchronization is not sufficient. For 1401 example, in mobile and wireless environments, members may go in and 1402 out of coverage and may miss a sequence number overrun. In point-to- 1403 multipoint translator scenarios it is desirable to not require the 1404 group controller to track the ROC values of each member, but to 1405 provide the ROC value by the originator of the SRTP packet. A better 1406 alternative to synchronize the ROC values is to send them directly 1407 via SRTP/SRTCP as EKT does. A separate SRTP extension [RFC4771] 1408 includes the ROC in a modified authentication tag but that extension 1409 does not support updating the SRTP master key. 1411 Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP 1412 streams. Each sender of a stream sends the associated SSRC within 1413 the MIKEY message to the other party. If an SRTP session participant 1414 starts a new SRTP source (SSRC) or a new participant is added to a 1415 group, subsequent SDP offer/answer and MIKEY exchanges are necessary 1416 to update the SSRC values. EKT improves these scenarios by updating 1417 the keys and SSRC values without coordination on the signaling 1418 channel. With EKT, SRTP can handle early media, since the EKT SPI 1419 allows the receiver to identify the cryptographic keys and parameters 1420 used by the source. 1422 The MIKEY specification [RFC3830] suggests the use of unicast for 1423 rekeying. This method does not scale well to large groups or 1424 interactive groups. The EKT extension of SRTP/SRTCP provides a 1425 solution for rekeying the SRTP master key and for ROC/SSRC 1426 synchronization. EKT is not a substitution for MIKEY, but rather a 1427 complementary addition to address the above described limitations of 1428 MIKEY. 1430 In the next section we provide an extension to MIKEY for support of 1431 EKT. EKT can be used only with the pre-shared key or public-key 1432 encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode 1433 is not suitable in conjunction with EKT, because it is not possible 1434 to establish one common EKT key over multiple EKT entities. 1435 Additional MIKEY modes specified in separate documents are not 1436 considered for EKT. 1438 5.1. EKT extensions to MIKEY 1440 In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI 1441 must be negotiated in the MIKEY message exchange. 1443 For EKT we specify a new SRTP Policy Type in the Security Policy (SP) 1444 payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload 1445 contains a set of policies. Each policy consists of a number of 1446 Policy Param TLVs. 1448 Prot type | Value 1449 ------------------- 1450 EKT | TBD (will be assigned by IANA) NOTE TO RFC EDITOR 1452 Figure 9: EKT Security Policy 1454 The EKT Security Policy has one parameter representing the EKT 1455 cipher. 1457 Type | Meaning | Possible values 1458 ---------------------------------------------------- 1459 0 | EKT cipher | see below 1461 Figure 10: EKT Security Policy Parameters 1463 EKT cipher | Value 1464 ------------------- 1465 (reserved) | 0 1466 AESKW_128 | 1 1467 AESKW_192 | 2 1468 AESKW_256 | 3 1470 Figure 11: EKT Cipher Parameters 1472 The two mandatory EKT parameters (EKT_Key and EKT_SPI) are 1473 transported in the MIKEY KEMAC payload within one separate Key Data 1474 sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC 1475 payload carries the TEK Generation Key (TGK) or the Traffic 1476 Encryption Key (TEK). One or more TGKs or TEKs are carried in 1477 individual Key Data sub-payloads within the KEMAC payload. The KEMAC 1478 payload is encrypted as part of MIKEY. The Key Data sub- payload, 1479 specified in Section 6.13 of [RFC3830], has the following format: 1481 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Next Payload | Type | KV | Key data length | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 : Key data : 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 : Salt length (optional) ! Salt data (optional) : 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 : KV data (optional) : 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 Figure 12: Key Data Sub-Payload of MIKEY 1495 These fields are described below: 1497 Type: 4 bits in length, indicates the type of key included in the 1498 payload. We define Type = TBD (will be requested from IANA [NOTE 1499 TO RFC EDITOR]) to indicate transport of the EKT key. 1501 KV: (4 bits): indicates the type of key validity period specified. 1502 KV=1 is currently specified as an SPI. We use that value to 1503 indicate the KV data contains the EKT_SPI for the key type 1504 EKT_Key. KV data would be 16 bits in length, but it is also 1505 possible to interpret the length from the 'Key data len' field. 1506 KV data MUST be present for the key type EKT_Key when KV=1. 1508 Salt length, Salt Data: These optional fields SHOULD be omitted for 1509 the key type EKT_Key, if the SRTP master salt is already present 1510 in the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload 1511 MUST contain a SRTP master salt, if the SRTP master salt is not 1512 already present in the TGK or TEK Key Data sub-payload. 1514 KV Data: length determined by Key Data Length field. 1516 5.2. Offer/Answer considerations 1518 This section describes Offer/Answer considerations for the use of EKT 1519 together with MIKEY for unicast streams. The offerer and answerer 1520 MUST follow the procedures specified in [RFC3830] and [RFC4567] as 1521 well as the following ones. 1523 5.2.1. Generating the Initial Offer 1525 If it is intended to use MIKEY together with EKT, the offerer MUST 1526 include at least one MIKEY key-mgmt attribute with one EKT_Key Key 1527 Data sub-payload and the EKT_Cipher Security Policy payload. MIKEY 1528 can be used on session or media level. On session level, MIKEY 1529 provides the keys for multiple SRTP sessions in the SDP offer. The 1530 EKT SPI references a EKT parameter set including the Secure RTP 1531 parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is 1532 used on session level, it is only possible to use one EKT SPI value. 1533 Therefore, the session-level MIKEY message MUST contain one SRTP 1534 Security Policy payload only, which is valid for all related SRTP 1535 media lines. If MIKEY is used on media level, different SRTP 1536 Security Policy parameters (and consequently different EKT SPI 1537 values) can be used for each media line. If MIKEY is used on session 1538 and media level, the media level content overrides the session level 1539 content. 1541 EKT requires a single shared SRTP master salt between all 1542 participants in the direct SRTP session. If a MIKEY key-mgmt 1543 attribute contains more than one TGK or TEK Key Data sub-payload, all 1544 the sub-payloads MUST contain the same master salt value. 1545 Consequently, the EKT_Key Key Data sub-payload MAY also contain the 1546 same salt or MAY omit the salt value. If the SRTP master salt is not 1547 present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub- 1548 payload MUST contain a master salt. 1550 5.2.2. Generating the Initial Answer 1552 For each media line in the offer using MIKEY, provided on session and 1553 /or on media level, the answerer examines the related MIKEY key-mgmt 1554 attributes for the presence of EKT parameters. In order to accept 1555 the offered key-mgmt attribute, the MIKEY message MUST contain one 1556 EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy 1557 payload. The answerer examines also the existence of a SRTP master 1558 salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple 1559 salts are available, all values MUST be equal. If the salt values 1560 differ or no salt is present, the key-mgmt attribute MUST be 1561 considered as invalid. 1563 The MIKEY responder message in the SDP answer does not contain a 1564 MIKEY KEMAC or Security Policy payload and consequently does not 1565 contain any EKT parameters. If a key-mgmt attribute for a media line 1566 was accepted by the answerer, the EKT parameter set of the offerer is 1567 valid for both directions of the SRTP session. 1569 5.2.3. Processing the Initial Answer 1571 On reception of the answer, the offerer examines if EKT has been 1572 accepted for the offered media lines. If a MIKEY key-mgmt attribute 1573 is received containing a valid MIKEY responder message, EKT has been 1574 successfully negotiated. On receipt of a MIKEY error message, EKT 1575 negotiation has failed. For example, this may happen if an EKT 1576 extended MIKEY initiator message is sent to a MIKEY entity not 1577 supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is 1578 returned to indicate that the EKT_Cipher Security Policy payload or 1579 the EKT_Key sub-payload is not supported. In this case, the offerer 1580 may send a second SDP offer with a MIKEY key-mgmt attribute without 1581 the additional EKT extensions. 1583 This behavior can be improved by defining an additional key-mgmt 1584 prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. 1585 One attribute offers MIKEY with SRTP and EKT and the other attribute 1586 offers MIKEY with SRTP without EKT. 1588 5.2.4. Modifying the Session 1590 Once an SRTP stream has been established, a new offer/answer exchange 1591 can modify the session including the EKT parameters. If the EKT key 1592 or EKT cipher is modified (i.e., a new EKT parameter set is created) 1593 the offerer MUST also provide a new EKT SPI value. The offerer MUST 1594 NOT remap an existing EKT SPI value to a new EKT parameter set. 1595 Similar, a modification of the SRTP Security Policy leads to a new 1596 EKT parameter set and requires a fresh EKT SPI, even if the EKT key 1597 or cipher did not change. 1599 Once EKT is being used, the SRTP master salt for the SRTP session 1600 MUST NOT be changed. The salt in the Key Data sub-payloads within 1601 the subsequent offers MUST be the same as the one already used. 1603 After EKT has been successfully negotiated for a session and an SRTP 1604 master key has been transported by EKT, it is difficult to switch 1605 back to a pure MIKEY based key exchange in a synchronized way. 1606 Therefore, once EKT is being used for a session, EKT MUST be used 1607 also in all subsequent offer/answer exchanges for that session. 1609 6. Using EKT for interoperability between key management systems 1611 A media gateway (MGW) can provide interoperability between an SRTP- 1612 EKT endpoint and a non-EKT SRTP endpoint. When doing this function, 1613 the MGW can perform non-cryptographic transformations on SRTP packets 1614 outlined above. However, there are some uses of cryptography that 1615 will be required for that gateway. If a new SRTP master key is 1616 communicated to the MGW (via EKT from the EKT leg, or via Security 1617 Descriptions without EKT from the Security Descriptions leg), the MGW 1618 needs to convert that information for the other leg, and that process 1619 will incur some cryptographic operations. Specifically, if the new 1620 key arrived via EKT, the key must be decrypted and then sent in 1621 Security Descriptions (e.g., as a SIP re-INVITE); likewise, if a new 1622 key arrives via Security Descriptions that must be encrypted via EKT 1623 and sent in SRTP/SRTCP. 1625 Additional non-normative information can be found in Appendix A. 1627 7. Design Rationale 1629 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1630 "persistent transport-level identifier for an RTP source" since 1631 "receivers require the CNAME to keep track of each participant." EKT 1632 works in much the same way but uses SRTP to carry information needed 1633 for the proper processing of the SRTP traffic. 1635 With EKT, SRTP gains the ability to synchronize the creation of 1636 cryptographic contexts across all of the participants in a single 1637 session. This feature provides some, but not all, of the 1638 functionality that is present in IKE phase two (but not phase one). 1639 Importantly, EKT does not provide a way to indicate SRTP options. 1641 With EKT, external signaling mechanisms provide the SRTP options and 1642 the EKT Key, but need not provide the key(s) for each individual SRTP 1643 source. EKT provides a separation between the signaling mechanisms 1644 and the details of SRTP. The signaling system need not coordinate 1645 all SRTP streams, nor predict in advance how many sources will be 1646 present, nor communicate SRTP-level information (e.g., rollover 1647 counters) of current sessions. 1649 EKT is especially useful for multi-party sessions, and for the case 1650 where multiple RTP sessions are sent to the same destination 1651 transport address (see the example in the definition of "RTP session" 1652 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1653 multiple endpoints at the same time) can cause multiple RTP sessions 1654 to be sent to the same transport address, making EKT useful for use 1655 with SIP. 1657 EKT can also be used in conjunction with a scalable group-key 1658 management system like GDOI [RFC6407]. In such a combination GDOI 1659 would provide a secure entity authentication method for group 1660 members, and a scalable way to revoke group membership; by itself, 1661 EKT does not attempt to provide either capability. 1663 EKT carries the encrypted key in a new SRTP field (at the end of the 1664 SRTP packet). This maintains compatibility with the existing SRTP 1665 specification by defining a new crypto function that incorporates the 1666 encrypted key, and a new authentication transform to provide implicit 1667 authentication of the encrypted key. 1669 The main motivation for the use of the variable-length EKT format is 1670 bandwidth conservation. When EKT is sent over SRTP, there will be a 1671 loss of (usable) bandwidth due to the additional EKT bytes in each 1672 RTP packet. For some applications, this bandwidth loss is 1673 significant. 1675 7.1. Alternatives 1677 In its current design, EKT requires that the Master Salt be 1678 established out of band. That requirement is undesirable. In an 1679 offer/answer environment, it forces the answerer to re-use the same 1680 Master Salt value used by the offerer. The Master Salt value could 1681 be carried in EKT packets though that would consume yet more 1682 bandwidth. 1684 In some scenarios, two SRTP sessions may be combined into a single 1685 session. When using EKT in such sessions, it is desirable to have an 1686 SPI value that is larger than 15 bits, so that collisions between SPI 1687 values in use in the two different sessions are unlikely (since each 1688 collision would confuse the members of one of the sessions). 1690 An alternative that addresses both of these needs is as follows: the 1691 SPI value can be lengthed from 15 bits to 63 bits, and the Master 1692 Salt can be identical to, or constructed from, the SPI value. SRTP 1693 conventionally uses a 14-byte Master Salt, but shorter values are 1694 acceptable. This alternative would add six bytes to each EKT packet; 1695 that overhead may be a reasonable tradeoff for addressing the 1696 problems outlined above. This is considered too high a bandwidth 1697 penalty. 1699 8. Security Considerations 1701 EKT inherits the security properties of the SRTP keying it uses: 1702 Security Descriptions, DTLS-SRTP, or MIKEY. 1704 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 1705 master keys. This property avoids any security concern over the re- 1706 use of keys, by empowering the SRTP layer to create keys on demand. 1707 Note that the inputs of EKT are the same as for SRTP with key- 1708 sharing: a single key is provided to protect an entire SRTP session. 1709 However, EKT remains secure even in the absence of out-of-band 1710 coordination of SSRCs, and even when SSRC values collide. 1712 The EKT Cipher includes its own authentication/integrity check. For 1713 an attacker to successfully forge a full EKT packet, it would need to 1714 defeat the authentication mechanisms of both the EKT Cipher and the 1715 SRTP authentication mechanism. 1717 The presence of the SSRC in the EKT_Plaintext ensures that an 1718 attacker cannot substitute an EKT_Ciphertext from one SRTP stream 1719 into another SRTP stream. 1721 An attacker who strips a Full_EKT_Field from an SRTP packet may 1722 prevent the intended receiver of that packet from being able to 1723 decrypt it. This is a minor denial of service vulnerability. 1724 Similarly, an attacker who adds a Full_EKT_Field can disrupt service. 1726 An attacker could send packets containing either Short EKT Field or 1727 Full EKT Field, in an attempt to consume additional CPU resources of 1728 the receiving system. In the case of the Short EKT Field, this field 1729 is stripped and normal SRTP or SRTCP processing is performed. In the 1730 case of the Full EKT Field, the attacker would have to have guessed 1731 or otherwise determined the SPI being used by the receiving system. 1732 If an invalid SPI is provided by the attacker, processing stops. If 1733 a valid SPI is provided by the attacker, the receiving system will 1734 decrypt the EKT ciphertext and return an authentication failure (Step 1735 3 of Section 2.2.2). 1737 EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) 1738 needs to roll over. EKT does not extend SRTP's rollover counter 1739 (ROC), and like SRTP itself EKT cannot properly handle a ROC 1740 rollover. Thus even if using EKT, new (master or session) keys need 1741 to be established after 2^48 packets are transmitted in a single SRTP 1742 stream as described in Section 3.3.1 of [RFC3711]. Due to the 1743 relatively low packet rates of typical RTP sessions, this is not 1744 expected to be a burden. 1746 The confidentiality, integrity, and authentication of the EKT cipher 1747 MUST be at least as strong as the SRTP cipher. 1749 Part of the EKT_Plaintext is known, or easily guessable to an 1750 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 1751 In practice, this requirement does not impose any restrictions on our 1752 choices, since the ciphers in use provide high security even when 1753 much plaintext is known. 1755 An EKT cipher MUST resist attacks in which both ciphertexts and 1756 plaintexts can be adaptively chosen. An EKT cipher MUST resist 1757 attacks in which both ciphertexts and plaintexts can be adaptively 1758 chosen and adversaries that can query both the encryption and 1759 decryption functions adaptively. 1761 9. IANA Considerations 1762 IANA is requested to register EKT from Section 3.9 into the Session 1763 Description Protocol (SDP) Security Descriptions [iana-sdp-sdesc] 1764 registry for "SRTP Session Parameters". 1766 IANA is requested to register the following new attributes into the 1767 SDP Attributes registry [iana-sdp-attr]. 1769 Attribute name: dtls-srtp-ekt 1771 Long form name: DTLS-SRTP with EKT 1773 Type of attribute: Media-level 1775 Subject to charset: No 1777 Purpose: Indicates support for DTLS-SRTP with EKT 1779 Appropriate values: No values 1781 Contact name: Dan Wing, dwing@cisco.com 1783 We request the following IANA assignments from the existing 1784 [iana-mikey] name spaces in the IETF consensus range (0-240) 1785 [RFC3830]: 1787 o From the Key Data payload name spaces, a value to indicate the 1788 type as the 'EKT_Key'. 1790 o From the Security Policy table name space, a new value to be 1791 assigned for 'EKT' (see Figure 9). 1793 Furthermore, we need the following two new IANA registries created, 1794 populated with the initial values in this document. New values for 1795 both of these registries can be defined via Specification Required 1796 [RFC5226]. 1798 o EKT parameter type, initially populated with the list from Figure 1799 10 1801 o EKT cipher, initially populated with the list from Figure 11 1803 10. Acknowledgements 1805 Thanks to Lakshminath Dondeti for assistance with earlier versions of 1806 this document. Thanks to Kai Fischer for writing the MIKEY section. 1808 Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond for fruitful 1809 discussions and comments. Thanks to Felix Wyss for his review and 1810 comments regarding ciphers. Thanks to Michael Peck for his review. 1811 Thanks to John Mattsson for his detailed security review highlighting 1812 the duplicative interaction between SRTP MKI with EKT ISN and 1813 encourged the EKT specification to prohibit sharing SRTP master keys. 1814 Thanks to Magnus Westerlund for his review. 1816 11. References 1818 11.1. Normative References 1820 [FIPS197] National Institute of Standards and Technology (NIST), 1821 "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1822 Information Processing Standard, November 2001. 1824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1825 Requirement Levels", BCP 14, RFC 2119, March 1997. 1827 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1828 with Session Description Protocol (SDP)", RFC 3264, June 1829 2002. 1831 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1832 Jacobson, "RTP: A Transport Protocol for Real-Time 1833 Applications", STD 64, RFC 3550, July 2003. 1835 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1836 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1837 RFC 3711, March 2004. 1839 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1840 Requirements for Security", BCP 106, RFC 4086, June 2005. 1842 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1843 Information Type for the General Extension Payload in 1844 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1846 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1847 Carrara, "Key Management Extensions for Session 1848 Description Protocol (SDP) and Real Time Streaming 1849 Protocol (RTSP)", RFC 4567, July 2006. 1851 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1852 Description Protocol (SDP) Security Descriptions for Media 1853 Streams", RFC 4568, July 2006. 1855 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1856 Encodings", RFC 4648, October 2006. 1858 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1859 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1860 May 2008. 1862 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1863 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1865 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1866 Security (DTLS) Extension to Establish Keys for the Secure 1867 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1869 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1870 Security Version 1.2", RFC 6347, January 2012. 1872 11.2. Informative References 1874 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1875 A., Peterson, J., Sparks, R., Handley, M., and E. 1876 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1877 June 2002. 1879 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1880 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1881 August 2004. 1883 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1884 Internet Protocol", RFC 4301, December 2005. 1886 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1887 Transform Carrying Roll-Over Counter for the Secure Real- 1888 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1890 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1891 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1892 September 2009. 1894 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1895 of Interpretation", RFC 6407, October 2011. 1897 [iana-mikey] 1898 IANA, ., "Multimedia Internet KEYing (Mikey) Payload Name 1899 Spaces", 2011, . 1902 [iana-sdp-attr] 1903 IANA, ., "SDP Parameters", 2011, . 1906 [iana-sdp-sdesc] 1907 IANA, ., "Session Description Protocol (SDP) Security 1908 Descriptions: SRTP Session Parameters", 2011, . 1912 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security 1913 Descriptions 1915 Today, SDP Security Descriptions [RFC4568] is used for distributing 1916 SRTP keys in several different IP PBX systems. The IP PBX systems 1917 are typically used within a single enterprise. A Session Border 1918 Controller is a reasonable solution to interwork between Security 1919 Descriptions in one network and DTLS-SRTP in another network. For 1920 example, a mobile operator (or an Enterprise) could operate Security 1921 Descriptions within their network and DTLS-SRTP towards the Internet. 1923 However, due to the way Security Descriptions and DTLS-SRTP manage 1924 their SRTP keys, such an SBC has to authenticate, decrypt, re- 1925 encrypt, and re-authenticate the SRTP (and SRTCP) packets in one 1926 direction, as shown in Figure 13, below. This is computationally 1927 expensive. 1929 RFC4568 endpoint SBC DTLS-SRTP endpoint 1930 | | | 1931 1. |---key=A------------->| | 1932 2. | |<-DTLS-SRTP handshake->| 1933 3. |<--key=B--------------| | 1934 4. | |<--SRTP, encrypted w/B-| 1935 5. |<-SRTP, encrypted w/B-| | 1936 6. |-SRTP, encrypted w/A->| | 1937 7. | (decrypt, re-encrypt) | 1938 8. | |-SRTP, encrypted w/C-->| 1939 | | | 1941 Figure 13: Interworking Security Descriptions and DTLS-SRTP 1943 The message flow is as follows (similar steps occur with SRTCP): 1945 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 1946 key to the SBC, using a=crypto in its SDP. 1948 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1949 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1950 B) and to the DTLS-SRTP endpoint (key C). 1952 3. The SBC communicates the SRTP encryption key (key B) to the 1953 Security Descriptions endpoint (using a=crypto). (There is no 1954 way, with DTLS-SRTP, to communicate the Security Descriptions key 1955 to the DTLS-SRTP key endpoint.) 1957 4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1958 B. This is received by the SBC. 1960 5. The received SRTP packet is simply forwarded; the SBC does not 1961 need to do anything with this packet as its key (key B) was 1962 already communicated in step 3. 1964 6. The Security Descriptions endpoint sends an SRTP packet, 1965 encrypted with its key A. 1967 7. The SBC has to authenticate and decrypt the SRTP packet (using 1968 key A), and re-encrypt it and generate an HMAC (using key C). 1970 8. The SBC sends the new SRTP packet. 1972 If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the 1973 computationally expensive operation so the SBC does not need to 1974 perform any per-packet operations on the SRTP (or SRTCP) packets in 1975 either direction. With EKT the SBC can simply forward the SRTP (and 1976 SRTCP) packets in both directions without per-packet HMAC or 1977 cryptographic operations. 1979 To accomplish this interworking, DTLS-SRTP EKT must be supported on 1980 the DTLS-SRTP endpoint, which allows the SBC to transport the 1981 Security Description key to the EKT endpoint and send the DTLS-SRTP 1982 key to the Security Descriptions endpoint. This works equally well 1983 for both incoming and outgoing calls. An abbreviated message flow is 1984 shown in Figure 14, below. 1986 RFC4568 endpoint SBC DTLS-SRTP endpoint 1987 | | | 1988 1. |---key=A------------->| | 1989 2. | |<-DTLS-SRTP handshake->| 1990 3. |<--key=B--------------| | 1991 4. | |--ekt:A--------------->| 1992 5. | |<--SRTP, encrypted w/B-| 1993 5. |<-SRTP, encrypted w/B-| | 1994 6. |-SRTP, encrypted w/A->| | 1995 7. | |-SRTP, encrypted w/A-->| 1996 | | | 1998 Figure 14: Interworking Security Descriptions and EKT 2000 The message flow is as follows (similar steps occur with SRTCP): 2002 1. Security Descriptions endpoint discloses its SRTP key to the SBC 2003 (a=crypto). 2005 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 2006 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 2007 B) and to the DTLS-SRTP endpoint (key C). 2009 3. The SBC communicates the SRTP encryption key (key B) to the 2010 Security Descriptions endpoint. 2012 4. The SBC sends an EKT packet indicating that SRTP will be 2013 encrypted with 'key A' towards the DTLS-SRTP endpoint. 2015 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 2016 B. This is received by the SBC. 2018 6. The received SRTP packet is simply forwarded; the SBC does not 2019 need to do anything with this packet as its key (key B) was 2020 communicated in step 3. 2022 7. The Security Descriptions endpoint sends an SRTP packet, 2023 encrypted with its key A. 2025 8. The received SRTP packet is simply forwarded; the SBC does not 2026 need to do anything with this packet as its key (key A) was 2027 communicated in step 4. 2029 Authors' Addresses 2031 David A. McGrew 2032 Cisco Systems, Inc. 2033 510 McCarthy Blvd. 2034 Milpitas, CA 95035 2035 US 2037 Phone: (408) 525 8651 2038 Email: mcgrew@cisco.com 2039 URI: http://www.mindspring.com/~dmcgrew/dam.htm 2041 Dan Wing 2042 Cisco Systems, Inc. 2043 510 McCarthy Blvd. 2044 Milpitas, CA 95035 2045 US 2047 Phone: (408) 853 4197 2048 Email: dwing@cisco.com 2049 Flemming Andreason 2050 Cisco Systems, Inc. 2051 499 Thornall Street 2052 Edison, NJ 08837 2053 US 2055 Email: fandreas@cisco.com