idnits 2.17.1 draft-ietf-avt-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 -- The document date (October 31, 2011) is 4560 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 1307, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group D. McGrew 3 Internet-Draft F. Andreasen 4 Intended status: Standards Track D. Wing 5 Expires: May 3, 2012 Cisco 6 K. Fischer 7 Siemens Enterprise Communications 8 October 31, 2011 10 Encrypted Key Transport for Secure RTP 11 draft-ietf-avt-srtp-ekt-03 13 Abstract 15 SRTP Encrypted Key Transport (EKT) is an extension to SRTP that 16 provides for the secure transport of SRTP master keys, Rollover 17 Counters, and other information, within SRTP or SRTCP. This facility 18 enables SRTP to work for decentralized conferences with minimal 19 control, and to handle situations caused by early media. 21 This note defines EKT, and also describes how to use it with SDP 22 Security Descriptions, DTLS-SRTP, and MIKEY. These other key 23 management protocols provide an EKT key to everyone in a session, and 24 EKT coordinates the 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 May 3, 2012. 43 Copyright Notice 45 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Conventions Used In This Document . . . . . . . . . . . . 5 62 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 63 2.1. Authentication Tag Formats . . . . . . . . . . . . . . . . 6 64 2.2. Packet Processing and State Machine . . . . . . . . . . . 8 65 2.2.1. Outbound (Tag Generation) . . . . . . . . . . . . . . 9 66 2.2.2. Inbound (Tag Verification) . . . . . . . . . . . . . . 11 67 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 15 69 2.3.2. AES ECB . . . . . . . . . . . . . . . . . . . . . . . 15 70 2.3.3. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 16 71 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 16 72 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 17 73 2.6. Timing and Reliability Consideration . . . . . . . . . . . 17 74 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 19 75 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 19 76 3.2. Relationship between EKT and SDP Security Descriptions . . 20 77 3.3. Overview of Combined EKT and SDP Security Description 78 Operation . . . . . . . . . . . . . . . . . . . . . . . . 22 79 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 22 80 3.4.1. EKT_Cipher . . . . . . . . . . . . . . . . . . . . . . 22 81 3.4.2. EKT_Key . . . . . . . . . . . . . . . . . . . . . . . 23 82 3.4.3. EKT_SPI . . . . . . . . . . . . . . . . . . . . . . . 23 83 3.5. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 23 84 3.5.1. Generating the Initial Offer - Unicast Streams . . . . 24 85 3.5.2. Generating the Initial Answer - Unicast Streams . . . 25 86 3.5.3. Processing of the Initial Answer - Unicast Streams . . 26 87 3.6. SRTP-Specific Use Outside Offer/Answer . . . . . . . . . . 27 88 3.7. Modifying the Session . . . . . . . . . . . . . . . . . . 27 89 3.8. Backwards Compatibility Considerations . . . . . . . . . . 28 90 3.9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 4. Use of EKT with DTLS-SRTP Key Transport . . . . . . . . . . . 30 92 4.1. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 30 93 4.1.1. Scaling to Large Groups . . . . . . . . . . . . . . . 32 94 4.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 33 95 4.2.1. Generating the Initial Offer . . . . . . . . . . . . . 33 96 4.2.2. Generating the Initial Answer . . . . . . . . . . . . 34 97 4.2.3. Processing the Initial Answer . . . . . . . . . . . . 34 98 4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 35 99 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 36 100 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 37 101 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 39 102 5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 39 103 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 40 104 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 40 105 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 40 106 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 42 107 6.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 43 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48 113 10.2. Informative References . . . . . . . . . . . . . . . . . . 49 114 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with 115 Security Descriptions . . . . . . . . . . . . . . . . 50 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 118 1. Introduction 120 RTP is designed to allow decentralized groups with minimal control to 121 establish sessions, such as for multimedia conferences. 122 Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many 123 minimal-control scenarios, because it requires that SSRC values and 124 other data be coordinated among all of the participants in a session. 125 For example, if a participant joins a session that is already in 126 progress, the SRTP rollover counter (ROC) of each SRTP source in the 127 session needs to be provided to that participant. 129 The inability of SRTP to work in the absence of central control was 130 well understood during the design of that protocol; that omission was 131 considered less important than optimizations such as bandwidth 132 conservation. Additionally, in many situations SRTP is used in 133 conjunction with a signaling system that can provide most of the 134 central control needed by SRTP. However, there are several cases in 135 which conventional signaling systems cannot easily provide all of the 136 coordination required. It is also desirable to eliminate the layer 137 violations that occur when signaling systems coordinate certain SRTP 138 parameters, such as SSRC values and ROCs. 140 This document defines Encrypted Key Transport (EKT) for SRTP, an 141 extension to SRTP that fits within the SRTP framework and reduces the 142 amount of signaling control that is needed in an SRTP session. EKT 143 securely distributes the SRTP master key and other information for 144 each SRTP source, using SRTCP or SRTP to transport that information. 145 With this method, SRTP entities are free to choose SSRC values as 146 they see fit, and to start up new SRTP sources with new SRTP master 147 keys (see Section 2.2) within a session without coordinating with 148 other entities via signaling or other external means. This fact 149 allows to reinstate the RTP collision detection and repair mechanism, 150 which is nullified by the current SRTP specification because of the 151 need to control SSRC values closely. An SRTP endpoint using EKT can 152 generate new keys whenever an existing SRTP master key has been 153 overused, or start up a new SRTP source to replace an old SRTP source 154 that has reached the packet-count limit. EKT also solves the problem 155 in which the burst loss of the N initial SRTP packets can confuse an 156 SRTP receiver, when the initial RTP sequence number is greater than 157 or equal to 2^16 - N. These features simplify many architectures that 158 implement SRTP. 160 EKT provides a way for an SRTP session participant, either sender or 161 receiver, to securely transport its SRTP master key and current SRTP 162 rollover counter to the other participants in the session. This 163 data, possibly in conjunction with additional data provided by an 164 external signaling protocol, furnishes the information needed by the 165 receiver to instantiate an SRTP/SRTCP receiver context. 167 EKT does not control the manner in which the SSRC and master key are 168 generated; it is concerned only with their secure transport. Those 169 values may be generated on demand by the SRTP endpoint, or may be 170 dictated by an external mechanism such as a signaling agent or a 171 secure group controller. 173 EKT is not intended to replace external key establishment mechanisms 174 such as SDP Security Descriptions [RFC4568], DTLS-SRTP [RFC5764], or 175 MIKEY [RFC3830][RFC4563]. Instead, it is used in conjunction with 176 those methods, and it relieves them of the burden of tightly 177 coordinating every SRTP source among every SRTP participant. 179 This document is organized as follows. A complete normative 180 definition of EKT is provided in Section 2. It consists of packet 181 processing algorithms (Section 2.2) and cryptographic definitions 182 (Section 2.3) . In Section 3, the use of EKT with SDP Security 183 Descriptions is defined, and in Section 4 its use with DTLS-SRTP is 184 defined. In Section 5 we outline the use of EKT with MIKEY. 185 Section 6 provides a design rationale. Security Considerations are 186 provided in Section 7, and IANA considerations are provided in 187 Section 8. 189 1.1. Conventions Used In This Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 2. Encrypted Key Transport 197 In EKT, an SRTP master key is encrypted with a Key Encrypting Key 198 (KEK), and the resulting ciphertext is transported (using the EKT 199 Base Authentication Tag) in selected SRTCP or in selected SRTP 200 packets. A single KEK suffices for a single SRTP session, regardless 201 of the number of participants in the session. However, there can be 202 multiple KEKs used within a particular session. We use terms "KEK" 203 or "EKT key" to mean the same thing; the latter term is used when 204 describing the relation of EKT to external key management. 206 In order to convey the ciphertext of the SRTP master key, and other 207 additional information, the Authentication Tag field is subdivided as 208 defined in Section 2.1. EKT defines new SRTP and SRTCP 209 authentication functions, which use this format. It incorporates a 210 conventional authentication function, which is called the base 211 authentication function in this specification. Any authentication 212 function, such as the default one of HMAC-SHA1 with a 160-bit key and 213 an 80-bit authentication tag, can be used as a base authentication 214 function. EKT also defines a new method of providing SRTP master 215 keys to an endpoint. 217 2.1. Authentication Tag Formats 219 The EKT Authentication Tag uses one of the two formats defined below. 220 These two formats can always be unambiguously distinguished on 221 receipt by examining the final bit of the EKT Authentication Tag, 222 which is also the final bit of the SRTP packet. The first format is 223 the Full EKT Authentication Tag (Figure 1), and the second is the 224 Abbreviated EKT Authentication Tag (Figure 2). 226 The following figure shows the packet layout for the Full EKT 227 Authentication Tag: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 : Base Authentication Tag : 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 : Encrypted Master Key : 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Rollover Counter | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Initial Sequence Number | Security Parameter Index |1| 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1: Full EKT Authentication Tag format 243 The Full EKT Authentication Tag field contains the following sub- 244 fields: 246 Base Authentication Tag: This field contains the authentication tag 247 computed by the base authentication function. The value of this 248 field is used to check the authenticity of the packet. 250 Encrypted Master Key: The length of this field is variable, and is 251 equal to the ciphertext size N defined in Section 2.3. Note that 252 the length of the field is inferable from the SPI field, since the 253 particular EKT cipher used by the sender of a packet is inferable 254 from that field. The Encrypted Master Key field is included 255 outside of the authenticated portion of the SRTCP packet, 256 immediately following the Authentication Tag. It contains the 257 ciphertext value resulting from the encryption of the SRTP master 258 key corresponding to the SSRC contained in the packet. The 259 encryption and decryption of this value is done using a cipher as 260 defined in Section 2.3. 262 Rollover Counter: The length of this field is fixed at 32 bits. 263 This field is set to the current value of the SRTP rollover 264 counter in the SRTP context associated with the SSRC in the SRTCP 265 packet. This field immediately follows the Encrypted Master Key 266 field. 268 Initial Sequence Number (ISN): The length of this field is fixed at 269 16 bits. If this field is nonzero, then it indicates the RTP 270 sequence number of the initial RTP packet that is protected using 271 the SRTP master key conveyed (in encrypted form) by the Encrypted 272 Master Key field of this packet. If this field is zero, it 273 indicates that the initial RTP packet protected using the SRTP 274 master key conveyed in this packet preceded, or was concurrent 275 with, the last roll-over of the RTP sequence number. 277 Security Parameter Index (SPI): The length of this field is fixed at 278 15 bits. This field indicates the appropriate Key Encrypting Key 279 and other parameters for the receiver to use when processing the 280 packet. It is an "index" into a table of possibilities (which are 281 established via signaling or some other out-of-band means), much 282 like the IPsec Security Parameter Index [RFC4301]. The parameters 283 that are identified by this field are: 285 * The Key Encrypting Key used to process the packet. 287 * The EKT cipher used to process the packet. 289 * The Secure RTP parameters associated with the SRTP Master Key 290 carried by the packet and the SSRC value in the packet. 292 Section 8.2. of [RFC3711] summarizes the parameters defined by 293 that specification. 295 * The Master Salt associated with the Master Key. (This value is 296 part of the parameters mentioned above, but we call it out for 297 emphasis.) The Master Salt is communicated separately, via 298 signaling, typically along with the EKT Key Encrypting Key. 300 Together, these elements are called an EKT parameter set. Within 301 each SRTP session, each distinct EKT parameter set that may be 302 used MUST be associated with a distinct SPI value, to avoid 303 ambiguity. The SPI field follows the Initial Sequence Number. 304 Since it appears at the end of the packet, and has a fixed length, 305 it is always possible to unambiguously parse this field. 307 Final bit: This MUST be 1. This flag distinguishes the packet 308 layout between Figure 2 or Figure 1. 310 The following figure shows the packet layout of the Abbreviated EKT 311 Authentication Tag: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 : Base Authentication Tag : 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Reserved |0| 319 +-+-+-+-+-+-+-+-+ 321 Figure 2: Abbreviated EKT Authentication Tag format 323 The Abbreviated EKT Authentication Tag field contains the following 324 sub-fields: 326 Base Authentication Tag: same as described above. 328 Reserved: 7 bits. MUST be 0 on transmission and MUST be ignored on 329 reception. 331 Final Bit: This MUST be 0. This flag distinguishes the packet 332 layout betweenFigure 1 or Figure 2.s 334 2.2. Packet Processing and State Machine 336 At any given time, each SRTP/SRTCP source has associated with it a 337 single EKT parameter set. This parameter set is used to process all 338 outbound packets, and is called the outbound parameter set. There 339 may be other EKT parameter sets that are used by other SRTP/SRTCP 340 sources in the same session. All of these EKT parameter sets SHOULD 341 be stored by all of the participants in an SRTP session, for use in 342 processing inbound SRTCP traffic. 344 We next review SRTP authentication and show how the EKT 345 authentication method is built on top of a base authentication 346 method. An SRTP or SRTCP authentication method consists of a tag- 347 generation function and a verification function. The tag-generation 348 function takes as input a secret key, the data to be authenticated, 349 and the packet index. It provides an authentication tag as its sole 350 output, and is used in the processing of outbound packets. The 351 verification function takes as input a secret key, the data to be 352 authenticated, the packet index, and the authentication tag. It 353 returns an indication of whether or not the data, index, and tag are 354 valid or not. It is used in the processing of inbound packets. EKT 355 defines a tag-generation function in terms of the base tag-generation 356 function, and defines a verification function in terms of the base 357 verification function. The tag-generation function is used to 358 process outbound packets, and the verification function is used to 359 process inbound packets. 361 2.2.1. Outbound (Tag Generation) 363 When an SRTP or SRTCP packet needs to be sent, the EKT tag generation 364 function works as follows. The Rollover Counter field in the packet 365 is set to the current value of the SRTP rollover counter (represented 366 as an unsigned integer in network byte order). 368 The Initial Sequence Number field is set to zero, if the initial RTP 369 packet protected using the current SRTP master key for this source 370 preceded, or was concurrent with, the last roll-over of the RTP 371 sequence number. Otherwise, that field is set to the value of the 372 RTP sequence number of the initial RTP packet that was or will be 373 protected by that key. When the SRTP master key corresponding to a 374 source is changed, the new key SHOULD be communicated in advance via 375 EKT. (Note that the ISN field allows the receiver to know when it 376 should start using the new key to process SRTP packets.) This 377 enables the rekeying event to be communicated before any RTP packets 378 are protected with the new key. The rekeying event MUST NOT change 379 the value of ROC (otherwise, the current value of the ROC would not 380 be known to late joiners of existing sessions). 382 The Security Parameter Index field is set to the value of the 383 Security Parameter Index that is associated with the outbound 384 parameter set. 386 The Encrypted Master Key field is set to the ciphertext created by 387 encrypting the SRTP master key with the EKT cipher, using the KEK as 388 the encryption key. The encryption process is detailed in 389 Section 2.3. Implementations MAY cache the value of this field to 390 avoid recomputing it for each packet that is sent. 392 2.2.1.1. Computing the Base Authentication Tag 394 If using the Base Authentication Tag format, the field is computed 395 using the base tag-generation function as follows. It can only be 396 computed after all of the other fields have been set. The 397 authenticated input consists of the following elements, in order: 399 1. the SRTP or SRTCP authenticated portion, 401 2. a string of zero bits whose length exactly matches that of the 402 Base Authentication Tag field, 404 3. the Encrypted Master Key field, 406 4. the Rollover Counter field, 408 5. the Initial Sequence Number field, and 410 6. the Security Parameter Index field. 412 Implementation note: the string of zero bits is included in the 413 authenticated input in order to allow implementations to compute 414 the base authentication tag using a single pass of the base 415 authentication function. Implementations MAY write zeros into the 416 Base Authentication Tag field prior to computing that function, on 417 the sending side. 419 2.2.1.2. Computing the Abbreviated Authentication Tag 421 If using the Abbreviated Authentication Tag format, the field is 422 computed using the base tag-generation function as follows. It can 423 only be computed after all of the other fields have been set. The 424 authenticated input consists of the following elements, in order: 426 1. the SRTP or SRTCP authenticated portion, 428 2. a string of zero bits whose length exactly matches that of the 429 Base Authentication Tag field. Then for SRTP only, place the ROC 430 (in network order) into the first 4 bytes of the "base 431 authentication tag" field. 433 3. set reserved bits and final bit to zeros. 435 2.2.2. Inbound (Tag Verification) 437 The EKT verification function proceeds as follows (see Figure 3), or 438 uses an equivalent set of steps. Recall that the verification 439 function is a component of SRTP and SRTCP processing. When a packet 440 does not pass the verification step, the function indicates this fact 441 to the SRTCP packet processing function when it returns control to 442 that function. 444 1. The Security Parameter Index field is checked to determine which 445 EKT parameter set should be used when processing the packet. If 446 multiple parameter sets been defined for the SRTP session, then 447 the one that is associated with the Security Parameter Index 448 value that matches the Security Parameter Index field in the 449 packet is used. This parameter set is called the matching 450 parameter set below. If there is no matching SPI, then the 451 verification function MUST return an indication of authentication 452 failure, and the steps described below are not performed. 454 2. If there is already an SRTP crypto context associated with the 455 SSRC in the packet, and replay protection is in use, then the 456 receiver performs the replay check described in Section 3.3.2 of 457 [RFC3711]. If the EKT fields are conveyed in an RTCP packet, 458 then the packet index used in that check is formed from the 459 Rollover Counter and the Initial Sequence Number fields in that 460 packet. If the EKT fields are conveyed in an SRTP packet, then 461 the packet index used in that check is formed from the EKT 462 Rollover Counter field and the RTP Sequence Number in that 463 packet. 465 3. The Encrypted Master Key field is decrypted using the EKT 466 cipher's decryption function. That field is used as the 467 ciphertext input, and the Key Encrypting Key in the matching 468 parameter set is used as the decryption key. The decryption 469 process is detailed in Section 2.3. The plaintext resulting from 470 this decryption is provisionally accepted as the SRTP master key 471 corresponding to the SSRC in the packet. If an SRTP master key 472 identifier (MKI) is present in the packet, then the provisional 473 key corresponds to the particular SSRC and MKI combination. A 474 provisional key MUST be used only to process one single packet. 475 A provisional SRTP or SRTCP authentication key is generated from 476 the provisional master key, and the SRTP master salt from the 477 matching parameter set, using the SRTP key derivation algorithm 478 (see Section 4.3 of [RFC3711]). 480 4. An authentication check is performed on the packet, using the 481 provisional SRTP or SRTCP authentication key. This key is 482 provided to the base authentication function (see Figure 3), 483 which is evaluated as described in Section 2.2.1.1. If the Base 484 Authentication Tag field matches the tag computed by the base 485 authentication function, then the packet passes the check. 487 Implementation note: a receiver MAY copy the Base 488 Authentication Tag field into temporary storage, then write 489 zeros into that field, prior to computing the base 490 authentication tag value. This step allows the base 491 authentication function to be computed in a single pass over 492 the data in the packet. 494 5. If the base authentication check using the provisional key fails, 495 then the provisional key MUST be discarded and it MUST NOT affect 496 any subsequent processing. The verification function MUST return 497 an indication of authentication failure, and the steps described 498 below are not performed. 500 6. Otherwise, if the base authentication check is passed, the 501 provisional key is also accepted as the SRTP master key 502 corresponding to the SRTP source that sent the packet. If an MKI 503 is present in the packet, then the master key corresponds to the 504 particular SSRC and MKI combination. If there is no SRTP crypto 505 context corresponding to the SSRC in the packet, then a new 506 crypto context is created. The rollover counter in the context 507 is set to the value of the Rollover Counter field. If the crypto 508 context is not new, then the rollover counter in the context MUST 509 NOT be set to a value lower than its current value. (If the 510 replay protection step described above is performed, it ensures 511 that this requirement is satisfied.) 513 7. If the Initial Sequence Number field is nonzero, then the initial 514 sequence number for the SRTP master key is set to the packet 515 index created by appending that field to the current rollover 516 counter and treating the result as a 48-bit unsigned integer. 517 The initial sequence number for the master key is equivalent to 518 the "From" value of the pair of indices (Section 8.1.1 519 of [RFC3711]) that can be associated with a master key. 521 8. The newly accepted SRTP master key, the SRTP parameters from the 522 matching parameter set, the SSRC from the packet, and the MKI 523 from the packet, if one is present, are stored in the crypto 524 context associated with the SRTP source. The SRTP Key Derivation 525 algorithm is run in order to compute the SRTP encryption and 526 authentication keys, and those keys are stored for use in SRTP 527 processing of inbound packets. The Key Derivation algorithm 528 takes as input the newly accepted SRTP master key, along with the 529 Master Salt from the matching parameter set. 531 Implementation note: the receiver may want to retain old 532 master keys for some brief period of time, so that out of 533 order packets can be processed. 535 9. The verification function then returns an indication that the 536 packet passed the verification. 538 Implementation note: the value of the Encrypted Master Key 539 field is identical in successive packets protected by the same 540 KEK and SRTP master key. This value MAY be cached by an SRTP 541 receiver to minimize computational effort, by allowing it to 542 recognize when the SRTP master key is unchanged, and thus 543 avoid repeating Steps 2, 6, and 7. 545 +------- Encrypted Master Key 546 | 547 v 548 +------------+ 549 | Decryption | 550 | Function |<-------------------------- Key Encrypting Key 551 +------------+ 552 | +----------------+ EKT 553 +--------+-- provisional ---->| SRTCP |<-- master 554 | master key | Key Derivation | salt 555 | +----------------+ 556 | | 557 | provisional SRTCP authentication key 558 | | 559 | v 560 | +----------------+ 561 | authenticated portion --> | Base SRTCP | 562 | authentication tag -----> | Verification | 563 | +----------------+ 564 | | 565 | +----------------+ +---+ 566 | | return FAIL |<- FAIL -| ? | 567 | +----------------+ +---+ 568 | | 569 | +----------------+ | 570 +------->| set master key,|<- PASS ---+ 571 | ROC, and MKI | 572 +----------------+ 573 | 574 v 575 +----------------+ 576 | return PASS | 577 +----------------+ 579 Figure 3: EKT inbound processing. 581 2.3. Ciphers 583 EKT uses a cipher to encrypt the SRTP master keys. We first specify 584 the interface to the cipher, in order to abstract the interface away 585 from the details of that function. We then define the cipher that is 586 used in EKT by default. This cipher MUST be implemented, but another 587 cipher that conforms to this interface MAY be used, in which case its 588 use MUST be coordinated by external means (e.g., call signaling). 590 An EKT cipher consists of an encryption function and a decryption 591 function. The encryption function E(K, P) takes the following 592 inputs: 594 o a secret key K with a length of L bytes, and 596 o a plaintext value P with a length of M bytes. 598 The encryption function returns a ciphertext value C whose length is 599 N bytes, where N is at least M. The decryption function D(K, C) takes 600 the following inputs: 602 o a secret key K with a length of L bytes, and 604 o a ciphertext value C with a length of N bytes. 606 The decryption function returns a plaintext value P that is M bytes 607 long. These functions have the property that D(K, E(K, P)) = P for 608 all values of K and P. Each cipher also has a limit T on the number 609 of times that it can be used with any fixed key value. For each key, 610 the encryption function MUST NOT be invoked on more than T distinct 611 values of P, and the decryption function MUST NOT be invoked on more 612 than T distinct values of C. 614 An EKT cipher MUST resist attacks in which both ciphertexts and 615 plaintexts can be adaptively chosen. For each randomly chosen key, 616 the encryption and decryption functions cannot be distinguished from 617 a random permutation and its inverse with non-negligible advantage. 618 This must be true even for adversaries that can query both the 619 encryption and decryption functions adaptively. The advantage is 620 defined as the difference between the probability that the adversary 621 will identify the cipher as such and the probability that the 622 adversary will identify the random permutation as the cipher, when 623 each case is equally likely. 625 2.3.1. The Default Cipher 627 The default EKT Cipher is the AES Key Wrap [RFC3394] algorithm, which 628 can be used with plaintexts larger than 16 bytes in length, and is 629 thus suitable for keys of any size. It requires a plaintext length M 630 that is a multiple of eight bytes, and it returns a ciphertext with a 631 length of N = M + 8 bytes. It can be used with key sizes of L = 16, 632 24, and 32, and its use with those key sizes is indicated as 633 AESKW_128, AESKW_192, and AESKW_256, respectively. The key size 634 determines the length of the AES key used by the Key Wrap algorithm. 635 With this cipher, T=2^48. 637 2.3.2. AES ECB 639 The simplest EKT cipher is the Advanced Encryption Standard (AES) 640 [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its 641 use is indicated as AES_ECB, and its parameters are fixed at L=16, 642 M=16, and T=2^48. Note that M matches the size of the SRTP master 643 keys used by the default SRTP key derivation function; if an SRTP 644 cipher with a different SRTP master key length is to be used with 645 EKT, then another EKT cipher must be used. ECB is the simplest mode 646 of operation of a block cipher, in which the block cipher is used in 647 its raw form. 649 2.3.3. Other EKT Ciphers 651 Other specification MAY extend this one by defining other EKT ciphers 652 per Section 8. This section defines how those ciphers interact with 653 this specification. 655 An EKT cipher determines how the Encrypted Master Key field is 656 written, and how it is processed when it is read. This field is 657 opaque to the other aspects of EKT processing. EKT ciphers are free 658 to use this field in any way, but they SHOULD NOT use other EKT or 659 SRTP fields as an input. The values of the parameters L, M, N, and T 660 MUST be defined by each EKT cipher, and those values MUST be 661 inferable from the EKT parameter set. 663 2.4. Synchronizing Operation 665 A participant in a session MAY opt to use a particular EKT key to 666 protect outbound packets after it accepts that EKT key for protecting 667 inbound traffic. In this case, the fact that one participant has 668 changed to using a new EKT key for outbound traffic can trigger other 669 participants to switch to using the same key. 671 An SRTP/SRTCP source SHOULD change its SRTP master key after its EKT 672 key has been changed. This will ensure that the set of participants 673 able to decrypt the traffic will be limited to those who know the 674 current EKT key. 676 EKT can be transported over SRTCP, but some of the information that 677 it conveys is used for SRTP processing; some elements of the EKT 678 parameter set apply to both SRTP and SRTCP. Furthermore, SRTCP 679 packets can be lost and both SRTP and SRTCP packets may be delivered 680 out of order. This can lead to various race conditions, which we 681 review below. 683 When joining an SRTP session, SRTP packets may be received before any 684 EKT over SRTCP packets, which implies the crypto context has not been 685 established, unless other external signaling mechanism has done so. 686 Rather than automatically discarding such SRTP packets, the receiver 687 MAY want to provisionally place them in a jitter buffer and delay 688 discarding them until playout time. 690 When an SRTP source using EKT over SRTCP performs a rekeying 691 operation, there is a race between the actual rekeying signaled via 692 SRTCP and the SRTP packets secured by the new keying material. If 693 the SRTP packets are received first, they will fail authentication; 694 alternatively, if authentication is not being used, they will decrypt 695 to unintelligible random-looking plaintext. (Note, however, that 696 [RFC3711] says that SRTP "SHOULD NOT be used without message 697 authentication".) In order to address this problem, the rekeying 698 event can be sent before packets using the new SRTP master key are 699 sent (by use of the ISN field). Another solution involves using an 700 MKI at the expense of added overhead in each SRTP packet. 701 Alternatively, receivers MAY want to delay discarding packets from 702 known SSRCs that fail authentication in anticipation of receiving a 703 rekeying event via EKT (SRTCP) shortly. 705 The ROC signaled via EKT over SRTCP may be off by one when it is 706 received by the other party(ies) in the session. In order to deal 707 with this, receivers should simply follow the SRTP packet index 708 estimation procedures defined in Section 3.3.1 [RFC3711]. 710 2.5. Transport 712 EKT MUST be used over SRTCP, whenever RTCP is in use. EKT MAY be 713 used over SRTP. When EKT over SRTP is used in an SRTP session in 714 which SRTCP is available, then EKT MUST be used for both SRTP and 715 SRTCP. 717 The packet processing, state machine, and Authentication Tag format 718 for EKT over SRTP are nearly identical to that for EKT over SRTCP. 719 Differences are highlighted in Section 2.2.1 and Section 2.2.2. 721 2.6. Timing and Reliability Consideration 723 SRTCP communicates the master key and ROC for the SRTP session. 724 Thus, as explained above, if SRTP packets are received prior to the 725 corresponding SRTCP (EKT) packet, a race condition occurs. From an 726 EKT point of view, it is therefore desirable for an SRTP sender to 727 send an EKT packet containing the Base Authentication Tag as soon as 728 possible, and in no case any later than when the initial SRTP packet 729 is sent. It is RECOMMENDED that the Base Authentication Tag be 730 transmitted 3 times (to accomodate packet loss) and to provide a 731 reliable indication to the receiver that the sender is now using the 732 EKT key. If the Base Authentication Tag sent in SRTCP, the SRTCP 733 timing rules associated with the profile under which it runs (e.g., 734 RTP/SAVP or RTP/SAVPF) MUST be obeyed. Subject to that constraint, 735 SRTP senders using EKT over SRTCP SHOULD send an SRTCP packet as soon 736 as possible after joining a session. Note that there is no need for 737 SRTP receivers to do so. Also note, that per RFC 3550, Section 6.2, 738 it is permissible to send a compound RTCP packet immediately after 739 joining a unicast session (but not a multicast session). 741 SRTCP is not reliable and hence SRTCP packets may be lost. This is 742 obviously a problem for endpoints joining an SRTP session and 743 receiving SRTP traffic (as opposed to SRTCP), or for endpoints 744 receiving SRTP traffic following a rekeying event. To reduce the 745 impact of lost packets, SRTP senders using EKT over SRTCP SHOULD send 746 SRTCP packets as often as allowed by the profile under which they 747 operate. 749 3. Use of EKT with SDP Security Descriptions 751 The SDP Security Descriptions (SDESC) [RFC4568] specification defines 752 a generic framework for negotiating security parameters for media 753 streams negotiated via the Session Description Protocol by use of a 754 new SDP "crypto" attribute and the Offer/Answer procedures defined in 755 [RFC3264]. In addition to the general framework, SDES also defines 756 how to use that framework specifically to negotiate security 757 parameters for Secure RTP. Below, we first provide a brief recap of 758 the crypto attribute when used for SRTP and we then explain how it is 759 complementary to EKT. In the rest of this Section, we provide 760 extensions to the crypto attribute and associated offer/answer 761 procedures to define its use with EKT. 763 3.1. SDP Security Descriptions Recap 765 The SRTP crypto attribute defined for SDESC contains a tag followed 766 by three types of parameters (refer to [RFC4568] for details): 768 o Crypto-suite. Identifies the encryption and authentication 769 transform 771 o Key parameters. SRTP keying material and parameters. 773 o Session parameters. Additional (optional) SRTP parameters such as 774 Key Derivation Rate, Forward Error Correction Order, use of 775 unencrypted SRTP, and other parameters defined by SDESC. 777 The crypto attributes in the example SDP in Figure 4 illustrate these 778 parameters. 780 v=0 781 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 782 s=SRTP Discussion 783 i=A discussion of Secure RTP 784 u=http://www.example.com/seminars/srtp.pdf 785 e=marge@example.com (Marge Simpson) 786 c=IN IP4 192.0.2.12 787 t=2873397496 2873404696 788 m=audio 49170 RTP/SAVP 0 789 a=crypto:1 AES_CM_128_HMAC_SHA1_80 790 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 791 FEC_ORDER=FEC_SRTP 792 a=crypto:2 F8_128_HMAC_SHA1_80 793 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 794 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 795 FEC_ORDER=FEC_SRTP 797 Figure 4: SDP Security Descriptions example 799 For legibility the SDP shows line breaks that are not present on the 800 wire. 802 The first crypto attribute has the tag "1" and uses the crypto-suite 803 AES_CM_128_HMAC_SHA1_80. The "inline" parameter provides the SRTP 804 master key and salt, the master key lifetime (number of packets), and 805 the (optional) Master Key Identifier (MKI) whose value is "1" and has 806 a byte length of "4" in the SRTP packets. Finally, the FEC_ORDER 807 session parameter indicates the order of Forward Error Correction 808 used (FEC is applied before SRTP processing by the sender of the SRTP 809 media). 811 The second crypto attribute has the tag "2" and uses the crypto-suite 812 F8_128_HMAC_SHA1_80. It includes two SRTP master keys and associated 813 salts. The first one is used with the MKI value 1, whereas the 814 second one is used with the MKI value 2. Finally, the FEC_ORDER 815 session parameter indicates the order of Forward Error Correction 816 used. 818 3.2. Relationship between EKT and SDP Security Descriptions 820 SDP Security Descriptions [RFC4568] define a generic framework for 821 negotiating security parameters for media streams negotiated via the 822 Session Description Protocol by use of the Offer/Answer procedures 823 defined in [RFC3264]. In addition to the general framework, SDESC 824 also defines how to use it specifically to negotiate security 825 parameters for Secure RTP. 827 EKT and SDESC are complementary. SDESC can negotiate several of the 828 SRTP security parameters (e.g., cipher and use of Master Key 829 Identifier/MKI) as well as SRTP master keys. SDESC, however, does 830 not negotiate SSRCs and their associated Rollover Counter (ROC). 831 Instead, SDESC relies on a so-called "late binding", where a newly 832 observed SSRC will have its crypto context initialized to a ROC value 833 of zero. Clearly, this does not work for participants joining an 834 SRTP session that has been established for a while and hence has a 835 non-zero ROC. It is impossible to use SDESC to join an SRTP session 836 that is already in progress. In this case, EKT on the endpoint 837 running SDP Security can provide the additional signaling necessary 838 to communicate the ROC (Section 6.4.1 of [RFC4568]). The use of EKT 839 solves this problem by communicating the ROC associated with the SSRC 840 in the media plane. 842 SDP Security Descriptions negotiates different SRTP master keys in 843 the send and receive direction. The offer contains the master key 844 used by the offerer to send media, and the answer contains the master 845 key used by the answerer to send media. Consequently, if media is 846 received by the offerer prior to the answer being received, the 847 offerer does not know the master key being used. Use of SDP security 848 preconditions can solve this problem, however it requires an 849 additional round-trip as well as a more complicated state machine. 850 EKT solves this problem by simply sending the master key used in the 851 media plane thereby avoiding the need for security preconditions. 853 If multiple crypto-suites were offered, the offerer also will not 854 know which of the crypto-suites offered was selected until the answer 855 is received. EKT solves this problem by using a correlator, the 856 Security Parameter Index (SPI), which uniquely identifies each crypto 857 attribute in the offer. 859 One of the primary call signaling protocols using offer/answer is the 860 Session Initiation Protocol (SIP) [RFC3261]. SIP uses the INVITE 861 message to initiate a media session and typically includes an offer 862 SDP in the INVITE. An INVITE may be "forked" to multiple recipients 863 which potentially can lead to multiple answers being received. 864 SDESC, however, does not properly support this scenario, mainly 865 because SDP and RTP/RTCP does not contain sufficient information to 866 allow for correlation of an incoming RTP/RTCP packet with a 867 particular answer SDP. Note that extensions providing this 868 correlation do exist (e.g., Interactive Connectivity Establishment 869 (ICE)). SDESC addresses this point-to-multipoint problem by moving 870 each answer to a separate RTP transport address thereby turning a 871 point-to-multipoint scenario into multiple point-to-point scenarios. 872 There are however significant disadvantages to doing so. As long as 873 the crypto attribute in the answer does not contain any declarative 874 parameters that differ from those in the offer, EKT solves this 875 problem by use of the SPI correlator and communication of the 876 answerer's SRTP master key in EKT. 878 As can be seen from the above, the combination of EKT and SDESC 879 provides a better solution to SRTP negotiation for offer/answer than 880 either of them alone. SDESC negotiates the various SRTP crypto 881 parameters (which EKT does not), whereas EKT addresses the 882 shortcomings of SDESC. 884 3.3. Overview of Combined EKT and SDP Security Description Operation 886 We define three session extension parameters to SDESC to communicate 887 the EKT cipher, EKT key, and Security Parameter Index to the peer. 888 The original SDESC parameters are used as defined in [RFC4568], 889 however the procedures associated with the SRTP master key differ 890 slightly, since both SDESC and EKT communicate an SRTP master key. 891 In particular, the SRTP master key communicated via SDESC is used 892 only if there is currently no crypto context established for the SSRC 893 in question. This will be the case when an entity has received only 894 the offer or answer, but has yet to receive a valid EKT message from 895 the peer. Once a valid EKT message is received for the SSRC, the 896 crypto context is initialized accordingly, and the SRTP master key 897 will then be derived from the EKT message. Subsequent offer/answer 898 exchanges do not change this: The most recent SRTP master key 899 negotiated via EKT will be used, or, if none is available for the 900 SSRC in question, the most recent SRTP master key negotiated via 901 offer/answer will be used. Note that with these rules, once a valid 902 EKT message has been received for a given SSRC, rekeying for that 903 SSRC can only be done via EKT. The associated SRTP crypto parameters 904 however can be changed via SDESC. 906 3.4. EKT Extensions to SDP Security Descriptions 908 In order to use EKT and SDESC in conjunction with each other, the 909 following new SDES session parameters are defined. These MUST NOT 910 appear more than once in a given crypto attribute: 912 EKT_Cipher: The EKT cipher used to encrypt the SRTP Master Key 914 EKT_Key: The EKT key used to encrypt the SRTP Master Key 916 EKT_SPI: The EKT Security Parameter Index 918 Below are details on each of these attributes. 920 3.4.1. EKT_Cipher 922 The (optional) EKT_Cipher parameter defines the EKT cipher used to 923 encrypt the EKT key with in SRTCP packets. The default value is 924 "AESKW_128" in accordance with Section 2.3.1. For the AES Key Wrap 925 cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are 926 defined for values of L=16, 24, and 32 respectively. For the AES ECB 927 cipher, "AES_ECB" is defined. In the Offer/Answer model, the 928 EKT_Cipher parameter is a negotiated parameter. 930 3.4.2. EKT_Key 932 The (mandatory) EKT_Key parameter is the key K used to encrypt the 933 SRTP Master Key in SRTCP packets. The value is base64 encoded as 934 described in Section 4 [RFC4648]. When base64 decoding the key, 935 padding characters (i.e., one or two "=" at the end of the base64 936 encoded data) are discarded (see [RFC4648] for details). Base64 937 encoding assumes that the base64 encoding input is an integral number 938 of octets. If a given EKT cipher requires the use of a key with a 939 length that is not an integral number of octets, said cipher MUST 940 define a padding scheme that results in the base64 input being an 941 integral number of octets. For example, if the length defined was 942 250 bits, then 6 padding bits would be needed, which could be defined 943 to be the last 6 bits in a 256 bit input. In the Offer/Answer model, 944 the EKT_Key parameter is a negotiated parameter. 946 3.4.3. EKT_SPI 948 The (mandatory) EKT_SPI parameter is the Security Parameter Index. 949 It is encoded as an ASCII string representing the hexadecimal value 950 of the Security Parameter Index. The SPI identifies the *offer* 951 crypto attribute (including the EKT Key and Cipher) being used for 952 the associated SRTP session. A crypto attribute corresponds to an 953 EKT Parameter Set and hence the SPI effectively identifies a 954 particular EKT parameter set. Note that the scope of the SPI is the 955 SRTP session, which may or may not be limited to the scope of the 956 associated SIP dialog. In particular, if one of the participants in 957 an SRTP session is an SRTP translator, the scope of the SRTP session 958 is not limited to the scope of a single SIP dialog. However, if all 959 of the participants in the session are endpoints or mixers, the scope 960 of the SRTP session will correspond to a single SIP dialog. In the 961 Offer/Answer model, the EKT_SPI parameter is a negotiated parameter. 963 3.5. Offer/Answer Procedures 965 In this section, we provide the offer/answer procedures associated 966 with use of the three new SDESC parameters defined in Section 967 Section 3.4. Since SDESC is defined only for unicast streams, we 968 provide only offer/answer procedures for unicast streams here as 969 well. 971 3.5.1. Generating the Initial Offer - Unicast Streams 973 When the initial offer is generated, the offerer MUST follow the 974 steps defined in [RFC4568] Section 7.1.1 as well as the following 975 steps. 977 For each unicast media line using SDESC and where use of EKT is 978 desired, the offerer MUST include one EKT_Key parameter and one 979 EKT_SPI parameter in at least one "crypto" attribute (see [RFC4568]). 980 The EKT_SPI parameter serves to identify the EKT parameter set used 981 for a particular SRTCP packet. Consequently, within a single media 982 line, a given EKT_SPI value MUST NOT be used with multiple crypto 983 attributes. Note that the EKT parameter set to use for the session 984 is not yet established at this point; each offered crypto attribute 985 contains a candidate EKT parameter set. Furthermore, if the media 986 line refers to an existing SRTP session, then any SPI values used for 987 EKT parameter sets in that session MUST NOT be remapped to any 988 different EKT parameter sets. When an offer describes an SRTP 989 session that is already in progress, the offer SHOULD use an EKT 990 parameter set (incl. EKT_SPI and EKT_KEY) that is already in use. 992 If an EKT_Cipher other than the default cipher is to be used, then 993 the EKT_Cipher parameter MUST be included as well. 995 If a given crypto attribute includes more than one set of SRTP key 996 parameters (SRTP master key, salt, lifetime, MKI), they MUST all use 997 the same salt. (EKT requires a single shared salt between all the 998 participants in the direct SRTP session). 1000 Important Note: The scope of the offer/answer exchange is the SIP 1001 dialog(s) established as a result of the INVITE, however the scope 1002 of EKT is the direct SRTP session, i.e., all the participants that 1003 are able to receive SRTP and SRTCP packets directly. If an SRTP 1004 session spans multiple SIP dialogs, the EKT parameter sets MUST be 1005 synchronized between all the SIP dialogs where SRTP and SRTCP 1006 packets can be exchanged. In the case where the SIP entity 1007 operates as an RTP mixer (and hence re-originates SRTP and SRTCP 1008 packets with its own SSRC), this is not an issue, unless the mixer 1009 receives traffic from the various participants on the same 1010 destination IP address and port, in which case further 1011 coordination of SPI values and crypto parameters may be needed 1012 between the SIP dialogs (note that SIP forking with multiple early 1013 media senders is an example of this). However if it operates as 1014 an RTP translator, synchronized negotiation of the EKT parameter 1015 sets on *all* the involved SIP dialogs will be needed. This is 1016 non-trivial in a variety of use cases, and hence use of the 1017 combined SDES/EKT mechanism with RTP translators should be 1018 considered very carefully. It should be noted, that use of SRTP 1019 with RTP translators in general should be considered very 1020 carefully as well. 1022 The EKT session parameters can either be included as optional or 1023 mandatory parameters, however within a given crypto attribute, they 1024 MUST all be either optional or mandatory. 1026 3.5.2. Generating the Initial Answer - Unicast Streams 1028 When the initial answer is generated, the answerer MUST follow the 1029 steps defined in [RFC4568] Section 7.1.2 as well as the following 1030 steps. 1032 For each unicast media line using SDESC, the answerer examines the 1033 associated crypto attribute(s) for the presence of EKT parameters. 1034 If mandatory EKT parameters are included with a "crypto" attribute, 1035 the answerer MUST support those parameters in order to accept that 1036 offered crypto attribute. If optional EKT parameters are included 1037 instead, the answerer MAY accept the offered crypto attribute without 1038 using EKT. However, doing so will prevent the offerer from 1039 processing any packets received before the answer. If neither 1040 optional nor mandatory EKT parameters are included with a crypto 1041 attribute, and that crypto attribute is accepted in the answer, EKT 1042 MUST NOT be used. If a given a crypto attribute includes a mixture 1043 of optional and mandatory EKT parameters, or an incomplete set of 1044 mandatory EKT parameters, that crypto attribute MUST be considered 1045 invalid. 1047 When EKT is used with SDESC, the offerer and answerer MUST use the 1048 same SRTP master salt. Thus, the SRTP key parameter(s) in the answer 1049 crypto attribute MUST use the same master salt as the one accepted 1050 from the offer. 1052 When the answerer accepts the offered media line and EKT is being 1053 used, the crypto attribute included in the answer MUST include the 1054 same EKT parameter values as found in the accepted crypto attribute 1055 from the offer (however, if the default EKT cipher is being used, it 1056 may be omitted). Furthermore, the EKT parameters included MUST be 1057 mandatory (i.e., no "-" prefix). 1059 Acceptance of a crypto attribute with EKT parameters leads to 1060 establishment of the EKT parameter set for the corresponding SRTP 1061 session. Consequently, the answerer MUST send packets in accordance 1062 with that particular EKT parameter set only. If the answerer wants 1063 to enable the offerer to process SRTP packets received by the offerer 1064 before it receives the answer, the answerer MUST NOT include any 1065 declarative session parameters that either were not present in the 1066 offered crypto attribute, or were present but with a different value. 1068 Otherwise, the offerer's view of the EKT parameter set would differ 1069 from the answerer's until the answer is received. Similarly, unless 1070 the offerer and answerer has other means for correlating an answer 1071 with a particular SRTP session, the answer SHOULD NOT include any 1072 declarative session parameters that either were not present in the 1073 offered crypto attribute, or were present but with a different value. 1074 If this recommendation is not followed and the offerer receives 1075 multiple answers (e.g., due to SIP forking), the offerer may not be 1076 able to process incoming media stream packets correctly. 1078 3.5.3. Processing of the Initial Answer - Unicast Streams 1080 When the offerer receives the answer, it MUST perform the steps in 1081 [RFC4568] Section 7.1.3 as well as the following steps for each SRTP 1082 media stream it offered with one or more crypto lines containing EKT 1083 parameters in it. 1085 If the answer crypto line contains EKT parameters, and the 1086 corresponding crypto line from the offer contained the same EKT 1087 values, use of EKT has been negotiated successfully and MUST be used 1088 for the media stream. When determining whether the values match, 1089 optional and mandatory parameters MUST be considered equal. 1090 Furthermore, if the default EKT cipher is being used, it MAY be 1091 either present or absent in the offer and/or answer. 1093 If the answer crypto line does not contain EKT parameters, then EKT 1094 MUST NOT be used for the corresponding SRTP session. Note that if 1095 the accepted crypto attribute contained mandatory EKT parameters in 1096 the offer, and the crypto attribute in the answer does not contain 1097 EKT parameters, then negotiation has failed (Section 5.1.3 of 1098 [RFC4568]). 1100 If the answer crypto line contains EKT parameters but the 1101 corresponding offered crypto line did not, or if the parameters don't 1102 match or are invalid, then the offerer MUST consider the crypto line 1103 invalid (see Section 7.1.3 of [RFC4568] for further operation). 1105 The EKT parameter set is established when the answer is received, 1106 however there are a couple of special cases to consider here. First 1107 of all, if an SRTCP packet is received prior to the answer, then the 1108 EKT parameter set is established provisionally based on the SPI 1109 included. Once the answer (which may include declarative session 1110 parameters) is received, the EKT parameter set is fully established. 1111 The second case involves receipt of multiple answers due to SIP 1112 forking. In this case, there will be multiple EKT parameter sets; 1113 one for each SRTP session. As mentioned earlier, reliable 1114 correlation of SIP dialogs to SRTP sessions requires extensions, and 1115 hence if one or more of the answers include declarative session 1116 parameters, it may be difficult to fully establish the EKT parameter 1117 set for each SRTP session. In the absence of a specific correlation 1118 mechanism, it is RECOMMENDED, that such correlation be done based on 1119 the signaled receive IP-address in the SDP and the observed source 1120 IP-address in incoming SRTP/SRTCP packets, and, if necessary, the 1121 signaled receive UDP port and the observed source UDP port. 1123 3.6. SRTP-Specific Use Outside Offer/Answer 1125 Security Descriptions use for SRTP is not defined outside offer/ 1126 answer and hence neither does Security Descriptions with EKT. 1128 3.7. Modifying the Session 1130 When a media stream using the SRTP security descriptions has been 1131 established, and a new offer/answer exchange is performed, the 1132 offerer and answerer MUST follow the steps in Section 7.1.4 of 1133 [RFC4568] as well as the following steps. SDESC allows for all 1134 parameters of the session to be modified, and the EKT session 1135 parameters are no exception to that, however, there are a few 1136 additional rules to be adhered to when using EKT. 1138 It is permissible to start a session without the use of EKT, and then 1139 subsequently start using EKT, however the converse is not. Thus, 1140 once use of EKT has been negotiated on a particular media stream, EKT 1141 MUST continue to be used on that media stream in all subsequent 1142 offer/answer exchanges. 1144 The reason for this is that both SDESC and EKT communicate the SRTP 1145 Master Key with EKT Master Keys taking precedence. Reverting back to 1146 an SDESC-controlled master key in a synchronized manner is difficult. 1148 Once EKT is being used, the salt for the direct SRTP session MUST NOT 1149 be changed. Thus, a new offer/answer which does not create a new 1150 SRTP session (e.g., because it reuses the same IP address and port) 1151 MUST use the same salt for all crypto attributes as is currently used 1152 for the direct SRTP session. 1154 Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI 1155 value to a different EKT parameter set until 2^32 other mappings have 1156 been used within the SRTP session. In practice, this requirements is 1157 most easily met by using a monotonically increasing SPI value (modulo 1158 2^32 and starting with zero) per direct SRTP session. Note that a 1159 direct SRTP session may span multiple SIP dialogs, and in such cases 1160 coordination of SPI values across those SIP dialogs will be required. 1161 In the simple point-to-point unicast case without translators, the 1162 requirement simply applies within each media line in the SDP. In the 1163 point-to-multipoint case, the requirement applies across all the 1164 associated SIP dialogs. 1166 3.8. Backwards Compatibility Considerations 1168 Backwards compatibility can be achieved in a couple of ways. First 1169 of all, SDESC allows for session parameters to be prefixed with "-" 1170 to indicate that they are optional. If the answerer does not support 1171 the EKT session parameters, such optional parameters will simply be 1172 ignored. When the answer is received, absence of the parameters will 1173 indicate that EKT is not being used. Receipt of SRTCP packets prior 1174 to receipt of such an answer will obviously be problematic (as is 1175 normally the case for SDESC without EKT). 1177 Alternatively, SDESC allows for multiple crypto lines to be included 1178 for a particular media stream. Thus, two crypto lines that differ in 1179 their use of EKT parameters (presence in one, absence in the other) 1180 can be used as a way to negotiate use of EKT. When the answer is 1181 received, the accepted crypto attribute will indicate whether EKT is 1182 being used or not. 1184 3.9. Grammar 1186 The ABNF [RFC5234] syntax for the three new SDP Security Descriptions 1187 session parameters is shown in Figure 5. 1189 EKT = EKT_Cipher "|" EKT_Key "|" EKT_SPI 1190 EKT_Cipher = "EKT=" EKT_Cipher_Name 1191 EKT_Cipher_Name = 1*(ALPHA / DIGIT / "_") ; "AES_128", "AESKW_128" 1192 ; "AESKW_192" and 1193 ; "AESKW_256" defined in 1194 ; this document. 1195 EKT_Key = 1*(base64) ; See Section 4 of [RFC4648] 1196 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1197 EKT_SPI = 4HEXDIG ; See [RFC5234] 1199 Figure 5: ABNF for the EKT session parameters 1201 Using the example from Figure 5 with the EKT extensions to SDP 1202 Security Descriptions results in the following example SDP: 1204 v=0 1205 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1206 s=SRTP Discussion 1207 i=A discussion of Secure RTP 1208 u=http://www.example.com/seminars/srtp.pdf 1209 e=marge@example.com (Marge Simpson) 1210 c=IN IP4 192.0.2.12 1211 t=2873397496 2873404696 1212 m=audio 49170 RTP/SAVP 0 1213 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1214 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1215 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1216 a=crypto:2 F8_128_HMAC_SHA1_80 1217 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1218 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1219 FEC_ORDER=FEC_SRTP EKT=AES_128|FE9C|AAE0 1221 For legibility the SDP shows line breaks that are not present on the 1222 wire. 1224 4. Use of EKT with DTLS-SRTP Key Transport 1226 This document defines an extension to DTLS-SRTP called Key Transport. 1227 Using EKT with the DTLS-SRTP Key Transport extensions allows securely 1228 transporting SRTP keying material from one DTLS-SRTP peer to another, 1229 so the same SRTP keying material can be used by those peers and so 1230 those peers can process EKT keys. This combination of protocols is 1231 valuable because it combines the advantages of DTLS (strong 1232 authentication of the endpoint and flexibility) with the advantages 1233 of EKT (allowing secure multiparty RTP with loose coordination and 1234 efficient communication of per-source keys). 1236 4.1. EKT Extensions to DTLS-SRTP 1238 This document adds a new TLS negotiated extension called "ekt". This 1239 adds a new TLS content type, EKT, and a new negotiated extension EKT. 1240 The negotiated extension MUST only be requested in conjunction with 1241 the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server 1242 indicates its support for EKT by including "dtls-srtp-ekt" in its SDP 1243 and "ekt" in its TLS ServerHello message. If a DTLS client includes 1244 "ekt" in its ClientHello, but does not receive "ekt" in the 1245 ServerHello, the DTLS client MUST NOT send DTLS packets with the 1246 "ekt" content-type. 1248 Using the syntax described in DTLS [I-D.ietf-tls-rfc4347-bis], the 1249 following structures are used: 1251 enum { 1252 ekt_key(0), 1253 ekt_key_ack(1), 1254 ekt_key_error(254), 1255 (255) 1256 } SRTPKeyTransportType; 1258 struct { 1259 SRTPKeyTransportType keytrans_type; 1260 uint24 length; 1261 uint16 message_seq; 1262 uint24 fragment_offset; 1263 uint24 fragment_length; 1264 select (SRTPKeyTransportType) { 1265 case ekt_key: 1266 EKTkey; 1267 }; 1268 } KeyTransport; 1270 enum { 1271 AES_128(0), 1272 AESKW_128(1), 1273 AESKW_192(2), 1274 AESKW_256(3), 1275 } ektcipher; 1277 struct { 1278 ektcipher EKT_Cipher; 1279 uint EKT_Key_Value<1..256>; 1280 uint EKT_Master_Salt<1..256>; 1281 uint16 EKT_SPI; 1282 } EKTkey; 1284 Figure 6: Additional TLS Data Structures 1286 The diagram below shows a message flow of DTLS client and DTLS server 1287 using the DTLS-SRTP Key Transport extension. SRTP packets exchanged 1288 prior to the ekt_message are encrypted using the SRTP master key 1289 derived from the normal DTLS-SRTP key derivation function. After the 1290 ekt_key message, they can be encrypted using the EKT key. 1292 Editor's note: do we need reliability for the ekt_key messages? 1293 Client Server 1295 ClientHello + use_srtp + EKT 1296 --------> 1297 ServerHello + use_srtp + EKT 1298 Certificate* 1299 ServerKeyExchange* 1300 CertificateRequest* 1301 <-------- ServerHelloDone 1302 Certificate* 1303 ClientKeyExchange 1304 CertificateVerify* 1305 [ChangeCipherSpec] 1306 Finished --------> 1307 [ChangeCipherSpec] 1308 <-------- Finished 1309 SRTP packets <-------> SRTP packets 1310 SRTP packets <-------> SRTP packets 1311 ekt_key --------> 1312 SRTP packets <-------> SRTP packets 1313 SRTP packets <-------> SRTP packets 1315 Figure 7: Handshake Message Flow 1317 4.1.1. Scaling to Large Groups 1319 In certain scenarios it is useful to perform DTLS-SRTP with a device 1320 that is not the RTP peer. A common scenario is multicast, where it 1321 is necessary to distribute the DTLS-SRTP (and EKT distribution) to 1322 several devices. To allow for this, a new SDP attribute, dtls-srtp- 1323 host, is defined which follows the general syntax specified in 1324 Section 5.13 of [RFC4566]. When signaled, it indicates this host 1325 controls the EKT keying for all group members. For the dtls-srtp- 1326 host attribute: 1328 o the name is the ASCII string "dtls-srtp-host" (lowercase) 1330 o the value is the IP address and port number used for DTLS-SRTP 1332 o This is a media-level attribute and MUST NOT appear at the session 1333 level 1335 The formal description of the attribute is defined by the following 1336 ABNF [RFC5234] syntax: 1338 attribute = "a=dtls-srtp-host:" 1339 dtls-srtp-host-info *(SP dtls-srtp-host-info) 1340 host-info = nettype space addrtype space 1341 connection-address space port CRLF 1343 Multiple IP/port pairs are provided for IPv6/IPv4 interworking, and 1344 to allow failover. The receiving host SHOULD attempt to use them in 1345 the order provided. 1347 An example of SDP containing the dtls-srtp-host attribute: 1349 v=0 1350 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1351 s=SRTP Discussion 1352 i=A discussion of Secure RTP 1353 u=http://www.example.com/seminars/srtp.pdf 1354 e=marge@example.com (Marge Simpson) 1355 c=IN IP4 192.0.2.12 1356 t=2873397496 2873404696 1357 m=audio 49170 UDP/TLS/RTP/SAVP 0 1358 a=fingerprint:SHA-1 1359 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1360 a=dtls-srtp-ekt 1361 a=dtls-srtp-host:IN IP4 192.0.2.13 56789 1363 For legibility the SDP shows line breaks that are not present on the 1364 wire. 1366 4.2. Offer/Answer Considerations 1368 This section describes Offer/Answer considerations for the use of EKT 1369 together with DTLS-SRTP for unicast and multicast streams. The 1370 offerer and answerer MUST follow the procedures specified in 1371 [RFC5764] as well as the following ones. 1373 As most DTLS-SRTP processing is performed on the media channel, 1374 rather than in SDP, there is little processing performed in SDP other 1375 than informational and to redirect DTLS-SRTP to an alternate host. 1376 Advertising support for the extension is necessary in SDP because in 1377 some cases it is required to establish an SRTP call. For example, a 1378 mixer may be able to only support SRTP listeners if those listeners 1379 implement DTLS Key Transport (because it lacks the CPU cycles 1380 necessary to encrypt SRTP uniquely for each listener). 1382 4.2.1. Generating the Initial Offer 1384 The initial offer contains a new SDP attribute, "dtls-srtp-ekt", 1385 which contains no value. This indicates the offerer is capable of 1386 supporting DTLS-SRTP with EKT extensions, and indicates the desire to 1387 use the "ekt" extension during the DTLS-SRTP handshake. If the 1388 offerer wants another host to perform DTLS-SRTP-EKT processing, it 1389 also includes the dtls-srtp-host attribute in its offer 1390 (Section 4.1). 1392 An example of SDP containing the dtls-srtp-ekt attribute:: 1394 v=0 1395 o=sam 2890844526 2890842807 IN IP4 192.0.2.5 1396 s=SRTP Discussion 1397 i=A discussion of Secure RTP 1398 u=http://www.example.com/seminars/srtp.pdf 1399 e=marge@example.com (Marge Simpson) 1400 c=IN IP4 192.0.2.12 1401 t=2873397496 2873404696 1402 m=audio 49170 UDP/TLS/RTP/SAVP 0 1403 a=fingerprint:SHA-1 1404 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1405 a=dtls-srtp-ekt 1407 For legibility the SDP shows line breaks that are not present on the 1408 wire. 1410 4.2.2. Generating the Initial Answer 1412 Upon receiving the initial offer, the presence of the dtls-srtp-ekt 1413 attribute indicates a desire to receive the EKT extension in the 1414 DTLS-SRTP handshake. The presence of the dtls-srtp-host attribute 1415 indicates an alternate host to send the DTLS-SRTP handshake (instead 1416 of the host on the c/m lines). DTLS messages should be constructed 1417 according to those two attributes. 1419 The SDP answer SHOULD contain the dtls-srtp-ekt attribute to indicate 1420 the answerer understands dtls-srtp. It should only contain the dtls- 1421 srtp-host attribute if the answerer also wishes to offload its DTLS- 1422 SRTP processing to another host. 1424 4.2.3. Processing the Initial Answer 1426 The presence of the dtls-srtp-ekt attribute indicates a desire by the 1427 answerer to perform DTLS-SRTP with EKT extensions, and the dtls-srtp- 1428 host attribute indicates an alternate host for DTLS-SRTP processing. 1430 After successful negotiation of the key_transport extension, the DTLS 1431 client and server MAY exchange SRTP packets, encrypted using the KDF 1432 described in [RFC5764]. This is normal and expected, even if Key 1433 Transport was negotiated by both sides, as neither side may (yet) 1434 have a need to alter the SRTP key. However, it is also possible that 1435 one (or both) peers will immediately send new_srtp_key message before 1436 sending any SRTP, and also possible that SRTP, encrypted with an 1437 unknown key, may be received before the new_srtp_key message is 1438 received. 1440 4.2.4. Modifying the Session 1442 As DTLS-SRTP-EKT processing is done on the DTLS-SRTP channel (media 1443 channel) rather than signaling, no special processing for modifying 1444 the session is necessary. 1446 5. Use of EKT with MIKEY 1448 The advantages outlined in Section 1 are useful in some scenarios in 1449 which MIKEY is used to establish SRTP sessions. In this section, we 1450 briefly review MIKEY and related work, and discuss these scenarios. 1452 An SRTP sender or a group controller can use MIKEY to establish a 1453 SRTP cryptographic context. This capability includes the 1454 distribution of a TEK generation key (TGK) or the TEK itself, 1455 security policy payload, crypto session bundle ID (CSB_ID) and a 1456 crypto session ID (CS_ID). The TEK directly maps to an SRTP master 1457 key, whereas the TGK is used along with the CSB_ID and a CS_ID to 1458 generate a TEK. The CS_ID is used to generate multiple TEKs (SRTP 1459 master keys) from a single TGK. For a media stream in SDP, MIKEY 1460 allocates two consecutive numbers for the crypto session IDs, so that 1461 each direction uses a different SRTP master key (see [RFC4567]). 1463 The MIKEY specification [RFC3830] defines three modes to exchange 1464 keys, associated parameters and to protect the MIKEY message: pre- 1465 shared key, public-key encryption and Diffie-Hellman key exchange. 1466 In the first two modes the MIKEY initiator only chooses and 1467 distributes the TGK or TEK, whereas in the third mode both MIKEY 1468 entities (the initiator and responder) contribute to the keys. All 1469 three MIKEY modes have in common that for establishing a SRTP session 1470 the exchanged key is valid for the send and receive direction. 1471 Especially for group communications it is desirable to update the 1472 SRTP master key individually per direction. EKT provides this 1473 property by distributing the SRTP master key within the SRTP/SRTCP 1474 packet. 1476 MIKEY already supports synchronization of ROC values between the 1477 MIKEY initiator and responder. The SSRC / ROC value pair is part of 1478 the MIKEY Common Header payload. This allows providing the current 1479 ROC value to late joiners of a session. However, in some scenarios a 1480 key management based ROC synchronization is not sufficient. For 1481 example, in mobile and wireless environments, members may go in and 1482 out of coverage and may miss a sequence number overrun. In point-to- 1483 multipoint translator scenarios it is desirable to not require the 1484 group controller to track the ROC values of each member, but to 1485 provide the ROC value by the originator of the SRTP packet. A better 1486 alternative to synchronize the ROC values is to send them directly 1487 via SRTP/SRTCP, as EKT does. A separate SRTP extension is being 1488 proposed [RFC4771] to include the ROC as part of a modified 1489 authentication tag. Unlike EKT, this extension uses only SRTP and 1490 not SRTCP as its transport and does not allow updating the SRTP 1491 master key. 1493 Besides the ROC, MIKEY synchronizes also the SSRC values of the SRTP 1494 streams. Each sender of a stream sends the associated SSRC within 1495 the MIKEY message to the other party. If a SRTP session participant 1496 starts a new SRTP source or a new participant is added to a group, 1497 subsequent SDP offer/answer and MIKEY exchanges are necessary to 1498 update the SSRC values. EKT improves these scenarios by updating the 1499 keys and SSRC values without coordination on the signaling channel. 1500 With EKT, SRTP can handle early media, since the EKT SPI allows the 1501 receiver to identify the cryptographic keys and parameters used by 1502 the source. 1504 The MIKEY specification [RFC3830] suggests the use of unicast for 1505 rekeying. This method does not scale well to large groups or 1506 interactive groups. The EKT extension of SRTP/SRTCP provides a 1507 solution for rekeying the SRTP master key and for ROC/SSRC 1508 synchronization. EKT is not a substitution for MIKEY, but rather a 1509 complementary addition to address the above described limitations of 1510 MIKEY. 1512 In the next section we provide an extension to MIKEY for support of 1513 EKT. EKT can be used only with the pre-shared key or public-key 1514 encryption MIKEY mode of [RFC3830]. The Diffie-Hellman exchange mode 1515 is not suitable in conjunction with EKT, because it is not possible 1516 to establish one common EKT key over multiple EKT entities. 1517 Additional MIKEY modes specified in separate documents are not 1518 considered for EKT. 1520 5.1. EKT extensions to MIKEY 1522 In order to use EKT with MIKEY, the EKT cipher, EKT key and EKT SPI 1523 must be negotiated in the MIKEY message exchange. 1525 For EKT we specify a new SRTP Policy Type in the Security Policy (SP) 1526 payload of MIKEY (see Section 6.10 of [RFC3830]). The SP payload 1527 contains a set of policies. Each policy consists of a number Policy 1528 Param TLVs. 1530 Prot type | Value 1531 ------------------- 1532 EKT | TBD (will be requested from IANA) 1534 For legibility the SDP shows line breaks that are not present on the 1535 wire. 1537 Figure 8: EKT Security Policy 1539 The EKT Security Policy has one parameter representing the EKT 1540 cipher. 1542 Type | Meaning | Possible values 1543 ---------------------------------------------------- 1544 0 | EKT cipher | see below 1546 Figure 9: EKT Security Policy Parameters 1548 EKT cipher | Value 1549 ------------------- 1550 AES_128 | 0 1551 AESKW_128 | 1 1552 AESKW_192 | 2 1553 AESKW_256 | 3 1555 Figure 10: EKT Cipher Parameters 1557 AES_128 is the default value for the EKT cipher. 1559 The two mandatory EKT parameters (EKT_Key and EKT_SPI) are 1560 transported in the MIKEY KEMAC payload within one separate Key Data 1561 sub-payload. As specified in Section 6.2 of [RFC3830], the KEMAC 1562 payload carries the TEK Generation Key (TGK) or the Traffic 1563 Encryption Key (TEK). One or more TGKs or TEKs are carried in 1564 individual Key Data sub-payloads within the KEMAC payload. The KEMAC 1565 payload is encrypted as part of MIKEY. The Key Data sub- payload, 1566 specified in Section 6.13 of [RFC3830], has the following format: 1568 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Next Payload | Type | KV | Key data length | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 : Key data : 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 : Salt length (optional) ! Salt data (optional) : 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 : KV data (optional) : 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 11: Key Data Sub-Payload of MIKEY 1582 These fields are described below: 1584 Type: 4 bits in length, indicates the type of key included in the 1585 payload. We define Type = TBD (will be requested from IANA) to 1586 indicate transport of the EKT key. 1588 KV: (4 bits): indicates the type of key validity period specified. 1589 KV=1 is currently specified as an SPI. We use that value to 1590 indicate the KV_data contains the ETK_SPI for the key type 1591 EKT_Key. KV_data would be 16 bits in length, but it is also 1592 possible to interpret the length from the 'Key data len' field. 1593 KV data MUST NOT be optional for the key type EKT_Key when KV = 1. 1595 Salt length, Salt Data: These optional fields SHOULD be omitted for 1596 the key type EKT_Key, if the SRTP master salt is already present 1597 in the TGK or TEK Key Data sub-payload. The EKT_Key sub-payload 1598 MUST contain a SRTP master salt, if the SRTP master salt is not 1599 already present in the TGK or TEK Key Data sub-payload. 1601 KV Data: length determined by Key Data Length field. 1603 5.2. Offer/Answer considerations 1605 This section describes Offer/Answer considerations for the use of EKT 1606 together with MIKEY for unicast streams. The offerer and answerer 1607 MUST follow the procedures specified in [RFC3830] and [RFC4567] as 1608 well as the following ones. 1610 5.2.1. Generating the Initial Offer 1612 If it is intended to use MIKEY together with EKT, the offerer MUST 1613 include at least one MIKEY key-mgmt attribute with one EKT_Key Key 1614 Data sub-payload and the EKT_Cipher Security Policy payload. MIKEY 1615 can be used on session or media level. On session level, MIKEY 1616 provides the keys for multiple SRTP sessions in the SDP offer. The 1617 EKT SPI references a EKT parameter set including the Secure RTP 1618 parameters as specified in Section 8.2 in [RFC3711]. If MIKEY is 1619 used on session level, it is only possible to use one EKT SPI value. 1620 Therefore, the session-level MIKEY message MUST contain one SRTP 1621 Security Policy payload only, which is valid for all related SRTP 1622 media lines. If MIKEY is used on media level, different SRTP 1623 Security Policy parameters (and consequently different EKT SPI 1624 values) can be used for each media line. If MIKEY is used on session 1625 and media level, the medial level content overrides the session level 1626 content. 1628 EKT requires a single shared SRTP master salt between all 1629 participants in the direct SRTP session. If a MIKEY key-mgmt 1630 attribute contains more than one TGK or TEK Key Data sub-payload, all 1631 the sub-payloads MUST contain the same master salt value. 1632 Consequently, the EKT_Key Key Data sub-payload MAY also contain the 1633 same salt or MAY omit the salt value. If the SRTP master salt is not 1634 present in the TGK and TEK Key Data sub-payloads, the EKT_Key sub- 1635 payload MUST contain a master salt. 1637 5.2.2. Generating the Initial Answer 1639 For each media line in the offer using MIKEY, provided on session or/ 1640 and on media level, the answerer examines the related MIKEY key-mgmt 1641 attributes for the presence of EKT parameters. In order to accept 1642 the offered key-mgmt attribute, the MIKEY message MUST contain one 1643 EKT_Key Key Data sub-payload and the EKT_Cipher Security Policy 1644 payload. The answerer examines also the existence of a SRTP master 1645 salt in the TGK/TEK and/or the EKT_Key sub-payloads. If multiple 1646 salts are available, all values MUST be equal. If the salt values 1647 differ or no salt is present, the key-mgmt attribute MUST be 1648 considered as invalid. 1650 The MIKEY responder message in the SDP answer does not contain a 1651 MIKEY KEMAC or Security Policy payload and consequently does not 1652 contain any EKT parameters. If the key-mgmt attribute for a media 1653 line was accepted by the answerer, the EKT parameter set of the 1654 offerer is valid for both directions of the SRTP session. 1656 5.2.3. Processing the Initial Answer 1658 On reception of the answer, the offerer examines if EKT has been 1659 accepted for the offered media lines. If a MIKEY key-mgmt attribute 1660 is received containing a valid MIKEY responder message, EKT has been 1661 successfully negotiated. On receipt of a MIKEY error message, EKT 1662 negotiation has failed. For example, this may happen if an EKT 1663 extended MIKEY initiator message is sent to a MIKEY entity not 1664 supporting EKT. A MIKEY error code 'Invalid SP' or 'Invalid DT' is 1665 returned to indicate that the EKT_Cipher Security Policy payload or 1666 the EKT_Key sub-payload is not supported. In this case, the offerer 1667 may send a second SDP offer with a MIKEY key-mgmt attribute without 1668 the additional EKT extensions. 1670 This behavior can be improved by defining an additional key-mgmt 1671 prtcl-id value 'mikeyekt' and offering two key-mgmt SDP attributes. 1672 One attribute offers MIKEY together with EKT and the other one offers 1673 MIKEY without EKT. This is for further discussion. 1675 5.2.4. Modifying the Session 1677 Once a SRTP stream has been established, a new offer/answer exchange 1678 can modify the session including the EKT parameters. If the EKT key 1679 or EKT cipher is modified (i.e., a new EKT parameter set is created) 1680 the offerer MUST also provide a new EKT SPI value. The offerer MUST 1681 NOT remap an existing EKT SPI value to a new EKT parameter set. 1682 Similar, a modification of the SRTP Security Policy leads to a new 1683 EKT parameter set and requires a fresh EKT SPI, even the EKT key or 1684 cipher did not change. 1686 Once EKT is being used, the SRTP master salt for the SRTP session 1687 MUST NOT be changed. The salt in the Key Data sub-payloads within 1688 the subsequent offers MUST be the same as the one already used. 1690 After EKT has been successfully negotiated for a session and a SRTP 1691 master key has been transported by EKT, it is difficult to switch 1692 back to a pure MIKEY based key exchange in a synchronized way. 1693 Therefore, once EKT is being used for a session, EKT MUST be used 1694 also in all subsequent offer/answer exchanges for that session. 1696 6. Design Rationale 1698 From [RFC3550], a primary function of RTCP is to carry the CNAME, a 1699 "persistent transport-level identifier for an RTP source" since 1700 "receivers require the CNAME to keep track of each participant." EKT 1701 works in much the same way, using SRTCP to carry information needed 1702 for the proper processing of the SRTP traffic. 1704 With EKT, SRTP gains the ability to synchronize the creation of 1705 cryptographic contexts across all of the participants in a single 1706 session. This feature provides some, but not all, of the 1707 functionality that is present in IKE phase two (but not phase one). 1708 Importantly, EKT does not provide a way to indicate SRTP options. 1710 With EKT, external signaling mechanisms provide the SRTP options and 1711 the EKT Key, but need not provide the key(s) for each individual SRTP 1712 source. EKT provides a separation between the signaling mechanisms 1713 and the details of SRTP. The signaling system need not coordinate 1714 all SRTP streams, nor predict in advance how many streams will be 1715 present, nor communicate SRTP-level information (e.g., rollover 1716 counters) of current sessions. 1718 EKT is especially useful for multi-party sessions, and for the case 1719 where multiple RTP sessions are sent to the same destination 1720 transport address (see the example in the definition of "RTP session" 1721 in [RFC3550]). A SIP offer that is forked in parallel (sent to 1722 multiple endpoints at the same time) can cause multiple RTP sessions 1723 to be sent to the same transport address, making EKT useful for use 1724 with SIP. 1726 EKT can also be used in conjunction with a scalable group-key 1727 management system like GDOI [RFC3547]. Such a system provides a 1728 secure entity authentication method and a way to revoke group 1729 membership, both of which are out of scope of EKT. 1731 It is natural to use SRTCP to transport encrypted keying material for 1732 SRTP, as it provides a secure control channel for (S)RTP. However, 1733 there are several different places in SRTCP in which the encrypted 1734 SRTP master key and ROC could be conveyed. We briefly review some of 1735 the alternatives in order to motivate the particular choice used in 1736 this specification. One alternative is to have those values carried 1737 as a new SDESC item or RTCP packet. This would require that the 1738 normal SRTCP encryption be turned off for the packets containing that 1739 SDESC item, since on the receiver's side, SRTCP processing completes 1740 before the RTCP processing starts. This tension between encryption 1741 and the desire for RTCP privacy is highly undesirable. Additionally, 1742 this alternative makes SRTCP dependent upon the parsing of the RTCP 1743 compound packet, which adds complexity. It is simpler to carry the 1744 encrypted key in a new SRTCP field. One way to do this and to be 1745 backwards compatible with the existing specification is to define a 1746 new crypto function that incorporates the encrypted key. We define a 1747 new authentication transform because EKT relies on the normal SRTCP 1748 authentication to provide implicit authentication of the encrypted 1749 key. 1751 An SRTP packet containing an SSRC that has not been seen will be 1752 discarded. This practice may induce a burst of packet loss at the 1753 outset of an SRTP stream, due to the loss or reorder of the first 1754 SRTCP packet with the EKT containing the key and rollover counter for 1755 that stream. However, this practice matches the conservative RTP 1756 memory-allocation strategy; many existing applications accept this 1757 risk of initial packet loss. Alternatively, implementations may wish 1758 to delay discarding such packets for a short period of time as 1759 described in Section 2.4. 1761 When EKT is carried in SRTCP, it adds eight additional bytes to each 1762 SRTCP packet, plus the length of the Encrypted Master Key field. 1763 Using the SRTP and EKT defaults, the total overhead is 24 bytes. 1764 This overhead does not detract from the total bandwidth used by SRTP, 1765 since it is included in the RTCP bandwidth computation. However, it 1766 will cause the control protocol to issue packets less frequently. 1768 The main motivation for the use of the variable-length format is 1769 bandwidth conservation. If EKT is used of SRTP, there will be a loss 1770 of bandwidth due to the additional 24 bytes in each RTP packet. For 1771 some applications, this bandwidth loss is significant. 1773 6.1. Alternatives 1775 In its current design, EKT requires that the Master Salt be 1776 established out of band. That requirement is undesirable. In an 1777 offer/answer environment, it forces the answerer to re-use the same 1778 Master Salt value used by the offerer. The Master Salt value could 1779 be carried in EKT packets though that would consume yet more 1780 bandwidth. 1782 In some scenarios, two SRTP sessions may be combined into a single 1783 session. When using EKT in such sessions, it is desirable to have an 1784 SPI value that is larger than 15 bits, so that collisions between SPI 1785 values in use in the two different sessions are unlikely (since each 1786 collision would confuse the members of one of the sessions.) 1788 An alternative that addresses both of these needs is as follows: the 1789 SPI value can be lengthed from 15 bits to 63 bits, and the Master 1790 Salt can be identical to, or constructed from, the SPI value. SRTP 1791 conventionally uses a 14-byte Master Salt, but shorter values are 1792 acceptable. This alternative would add six bytes to each EKT packet; 1793 that overhead may be a reasonable tradeoff for addressing the 1794 problems outlined above. 1796 7. Security Considerations 1798 With EKT, each SRTP sender and receiver can generate distinct SRTP 1799 master keys. This property avoids any security concern over the re- 1800 use of keys, by empowering the SRTP layer to create keys on demand. 1801 Note that the inputs of EKT are the same as for SRTP with key- 1802 sharing: a single key is provided to protect an entire SRTP session. 1803 However, EKT provides complete security, even in the absence of 1804 further out-of-band coordination of SSRCs, and even when SSRC values 1805 collide. 1807 EKT uses encrypted key transport with implicit authentication. A 1808 strong cipher is used to ensure the confidentiality of the master 1809 keys as they are transported. The authenticity of the master keys is 1810 ensured by the base authentication check, which uses the plaintext 1811 form of that key. If the base authentication function and the cipher 1812 cannot be defeated by a particular attacker, then that attacker will 1813 be unable to defeat the implicit authentication. 1815 In order to avoid potential security issues, the SRTP authentication 1816 tag length used by the base authentication method MUST be at least 1817 ten octets. 1819 8. IANA Considerations 1821 This section registers with IANA the following SRTP session 1822 parameters for SDP Security Descriptions [RFC4568]: 1824 o EKT_KEY 1826 o EKT_CIPHER 1828 o EKT_SPI 1830 The definition of these parameters is provided in Section 3.4. 1832 We request the following IANA assignments from existing MIKEY IANA 1833 tables: 1835 o From the Key Data payload name spaces, a value to indicate the 1836 type as the 'EKT_Key'. 1838 o From the Security Policy table name space, a new value to be 1839 assigned for 'EKT' (see Figure 8). 1841 Furthermore, we need the following two new IANA registries created, 1842 populated with the initial values in this document. New values for 1843 both of these registries can be defined via Specification Required 1844 [RFC5226]. 1846 o EKT parameter type (initially populated with the list from 1847 Figure 9) 1849 o EKT cipher (initially populated with the list from Figure 10) 1851 9. Acknowledgements 1853 Thanks to Lakshminath Dondeti for assistance with earlier versions of 1854 this document. Thanks to Nermeen Ismail, Eddy Lem, and Rob Raymond 1855 for fruitful discussions and comments. Thanks to Romain Biehlmann 1856 for his encouragement to add support DTLS-SRTP-EKT key servers for 1857 multicast. Thanks to Felix Wyss for his review and comments 1858 regarding ciphers. 1860 10. References 1862 10.1. Normative References 1864 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 1865 Information Processing Standard. 1867 [I-D.ietf-tls-rfc4347-bis] 1868 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1869 Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work 1870 in progress), July 2011. 1872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1873 Requirement Levels", BCP 14, RFC 2119, March 1997. 1875 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1876 A., Peterson, J., Sparks, R., Handley, M., and E. 1877 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1878 June 2002. 1880 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1881 with Session Description Protocol (SDP)", RFC 3264, 1882 June 2002. 1884 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1885 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1887 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1888 Jacobson, "RTP: A Transport Protocol for Real-Time 1889 Applications", STD 64, RFC 3550, July 2003. 1891 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1892 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1893 RFC 3711, March 2004. 1895 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1896 Information Type for the General Extension Payload in 1897 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1899 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1900 Description Protocol", RFC 4566, July 2006. 1902 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1903 Carrara, "Key Management Extensions for Session 1904 Description Protocol (SDP) and Real Time Streaming 1905 Protocol (RTSP)", RFC 4567, July 2006. 1907 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1908 Description Protocol (SDP) Security Descriptions for Media 1909 Streams", RFC 4568, July 2006. 1911 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1912 Encodings", RFC 4648, October 2006. 1914 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1915 Transform Carrying Roll-Over Counter for the Secure Real- 1916 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1918 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1919 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1920 May 2008. 1922 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1923 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1925 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1926 Security (DTLS) Extension to Establish Keys for the Secure 1927 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1929 10.2. Informative References 1931 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1932 Group Domain of Interpretation", RFC 3547, July 2003. 1934 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1935 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1936 August 2004. 1938 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1939 Internet Protocol", RFC 4301, December 2005. 1941 Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security 1942 Descriptions 1944 Today, SDP Security Descriptions [RFC4568] is used for distributing 1945 SRTP keys in several different IP PBX systems and is expected to be 1946 used by 3GPP's Long Term Evolution (LTE). The IP PBX systems are 1947 typically used within a single enterprise, and LTE is used within the 1948 confines of a mobile operator's network. A Session Border Controller 1949 is a reasonable solution to interwork between Security Descriptions 1950 in one network and DTLS-SRTP in another network. For example, a 1951 mobile operator (or an Enterprise) could operate Security 1952 Descriptions within their network and DTLS-SRTP towards the Internet. 1954 However, due to the way Security Descriptions and DTLS-SRTP manage 1955 their SRTP keys, such an SBC has to authenticate, decrypt, re- 1956 encrypt, and re-authenticate the SRTP (and SRTCP) packets in one 1957 direction, as shown in Figure 12, below. This is computationally 1958 expensive. 1960 RFC4568 endpoint SBC DTLS-SRTP endpoint 1961 | | | 1962 1. |---key=A------------->| | 1963 2. | |<-DTLS-SRTP handshake->| 1964 3. |<--key=B--------------| | 1965 4. | |<--SRTP, encrypted w/B-| 1966 5. |<-SRTP, encrypted w/B-| | 1967 6. |-SRTP, encrypted w/A->| | 1968 7. | (decrypt, re-encrypt) | 1969 8. | |-SRTP, encrypted w/C-->| 1970 | | | 1972 Figure 12: Interworking Security Descriptions and DTLS-SRTP 1974 The message flow is as follows (similar steps occur with SRTCP): 1976 1. The Security Descriptions [RFC4568] endpoint discloses its SRTP 1977 key to the SBC, using a=crypto in its SDP. 1979 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 1980 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 1981 B) and to the DTLS-SRTP endpoint (key C). 1983 3. The SBC communicates the SRTP encryption key (key B) to the 1984 Security Descriptions endpoint (using a=crypto). (There is no 1985 way, with DTLS-SRTP, to communicate the Security Descriptions key 1986 to the DTLS-SRTP key endpoint.) 1988 4. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 1989 B. This is received by the SBC. 1991 5. The received SRTP packet is simply forwarded; the SBC does not 1992 need to do anything with this packet as its key (key B) was 1993 already communicated in step 3. 1995 6. The Security Descriptions endpoint sends an SRTP packet, 1996 encrypted with its key A. 1998 7. The SBC has to authenticate and decrypt the SRTP packet (using 1999 key A), and re-encrypt it and generate an HMAC (using key C). 2001 8. The SBC sends the new SRTP packet. 2003 If EKT is deployed on the DTLS-SRTP endpoints, EKT helps to avoid the 2004 computationally expensive operation so the SBC does not need not 2005 perform any per-packet operations on the SRTP (or SRTCP) packets in 2006 either direction. With EKT the SBC can simply forward the SRTP (and 2007 SRTCP) packets in both directions without per-packet HMAC or 2008 cryptographic operations. 2010 To accomplish this interworking, DTLS-SRTP EKT must be supported on 2011 the DTLS-SRTP endpoint, which allows the SBC to transport the 2012 Security Description key to the EKT endpoint and send the DTLS-SRTP 2013 key to the Security Descriptions endpoint. This works equally well 2014 for both incoming and outgoing calls. An abbreviated message flow is 2015 shown in Figure 13, below. 2017 RFC4568 endpoint SBC DTLS-SRTP endpoint 2018 | | | 2019 1. |---key=A------------->| | 2020 2. | |<-DTLS-SRTP handshake->| 2021 3. |<--key=B--------------| | 2022 4. | |--new_srtp_key:A------>| 2023 5. | |<--SRTP, encrypted w/B-| 2024 5. |<-SRTP, encrypted w/B-| | 2025 6. |-SRTP, encrypted w/A->| | 2026 7. | |-SRTP, encrypted w/A-->| 2027 | | | 2029 Figure 13: Interworking Security Descriptions and EKT 2031 The message flow is as follows (similar steps occur with SRTCP): 2033 1. Security Descriptions endpoint discloses its SRTP key to the SBC 2034 (a=crypto). 2036 2. SBC completes DTLS-SRTP handshake. From this handshake, the SBC 2037 derives the SRTP key for traffic from the DTLS-SRTP endpoint (key 2038 B) and to the DTLS-SRTP endpoint (key C). 2040 3. The SBC communicates the SRTP encryption key (key B) to the 2041 Security Descriptions endpoint. 2043 4. The SBC uses the EKT to indicate that SRTP packets will be 2044 encrypted with 'key A' towards the DTLS-SRTP endpoint. 2046 5. The DTLS-SRTP endpoint sends an SRTP key, encrypted with its key 2047 B. This is received by the SBC. 2049 6. The received SRTP packet is simply forwarded; the SBC does not 2050 need to do anything with this packet as its key (key B) was 2051 communicated in step 3. 2053 7. The Security Descriptions endpoint sends an SRTP packet, 2054 encrypted with its key A. 2056 8. The received SRTP packet is simply forwarded; the SBC does not 2057 need to do anything with this packet as its key (key A) was 2058 communicated in step 4. 2060 Authors' Addresses 2062 David A. McGrew 2063 Cisco Systems, Inc. 2064 510 McCarthy Blvd. 2065 Milpitas, CA 95035 2066 US 2068 Phone: (408) 525 8651 2069 Email: mcgrew@cisco.com 2070 URI: http://www.mindspring.com/~dmcgrew/dam.htm 2072 Flemming Andreason 2073 Cisco Systems, Inc. 2074 499 Thornall Street 2075 Edison, NJ 08837 2076 US 2078 Email: fandreas@cisco.com 2080 Dan Wing 2081 Cisco Systems, Inc. 2082 510 McCarthy Blvd. 2083 Milpitas, CA 95035 2084 US 2086 Phone: (408) 853 4197 2087 Email: dwing@cisco.com 2089 Kai Fischer 2090 Siemens Enterprise Communications GmbH & Co. KG 2091 Hofmannstr. 51 2092 Munich, Bavaria 81739 2093 Germany 2095 Email: kai.fischer@siemens-enterprise.com