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