idnits 2.17.1 draft-ietf-perc-srtp-ekt-diet-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2020) is 1379 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: 'ACK' is mentioned on line 722, but not defined == Missing Reference: 'EKTKey' is mentioned on line 720, but not defined == Missing Reference: 'TBD-at-Registration' is mentioned on line 1019, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Mattsson 5 Expires: December 20, 2020 Ericsson AB 6 D. McGrew 7 Cisco Systems 8 D. Wing 9 Citrix Systems, Inc. 10 F. Andreason 11 Cisco Systems 12 June 18, 2020 14 Encrypted Key Transport for DTLS and Secure RTP 15 draft-ietf-perc-srtp-ekt-diet-12 17 Abstract 19 Encrypted Key Transport (EKT) is an extension to DTLS (Datagram 20 Transport Layer Security) and Secure Real-time Transport Protocol 21 (SRTP) that provides for the secure transport of SRTP master keys, 22 rollover counters, and other information within SRTP. This facility 23 enables SRTP for decentralized conferences by distributing a common 24 key to all of the conference endpoints. 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 https://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 December 20, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Conventions Used In This Document . . . . . . . . . . . . . . 4 63 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 64 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 65 4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8 66 4.3. Packet Processing and State Machine . . . . . . . . . . . 8 67 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 68 4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10 69 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12 71 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13 72 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 73 4.6. Timing and Reliability Consideration . . . . . . . . . . 13 74 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 75 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15 76 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15 77 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17 78 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17 79 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 80 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21 84 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 22 86 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 22 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 9.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 Real-time Transport Protocol (RTP) is designed to allow decentralized 96 groups with minimal control to establish sessions, such as for 97 multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) 98 cannot be used in many minimal-control scenarios, because it requires 99 that synchronization source (SSRC) values and other data be 100 coordinated among all of the participants in a session. For example, 101 if a participant joins a session that is already in progress, that 102 participant needs to be told the SRTP keys along with the SSRC, 103 rollover counter (ROC) and other details of the other SRTP sources. 105 The inability of SRTP to work in the absence of central control was 106 well understood during the design of the protocol; the omission was 107 considered less important than optimizations such as bandwidth 108 conservation. Additionally, in many situations SRTP is used in 109 conjunction with a signaling system that can provide the central 110 control needed by SRTP. However, there are several cases in which 111 conventional signaling systems cannot easily provide all of the 112 coordination required. 114 This document defines Encrypted Key Transport (EKT) for SRTP and 115 reduces the amount of external signaling control that is needed in a 116 SRTP session with multiple receivers. EKT securely distributes the 117 SRTP master key and other information for each SRTP source. With 118 this method, SRTP entities are free to choose SSRC values as they see 119 fit, and to start up new SRTP sources with new SRTP master keys 120 within a session without coordinating with other entities via 121 external signaling or other external means. 123 EKT extends DTLS and SRTP to enable a common key encryption key 124 (called an EKTKey) to be distributed to all endpoints, so that each 125 endpoint can securely send its SRTP master key and current SRTP 126 rollover counter to the other participants in the session. This data 127 furnishes the information needed by the receiver to instantiate an 128 SRTP/SRTCP receiver context. 130 EKT can be used in conferences where the central media distributor or 131 conference bridge cannot decrypt the media, such as the type defined 132 for [I-D.ietf-perc-private-media-framework]. It can also be used for 133 large scale conferences where the conference bridge or media 134 distributor can decrypt all the media but wishes to encrypt the media 135 it is sending just once and then send the same encrypted media to a 136 large number of participants. This reduces the amount of CPU time 137 needed for encryption and can be used for some optimization to media 138 sending that use source specific multicast. 140 EKT does not control the manner in which the SSRC is generated. It 141 is only concerned with distributing the security parameters that an 142 endpoint needs to associate with a given SSRC in order to decrypt 143 SRTP packets from that sender. 145 EKT is not intended to replace external key establishment mechanisms. 146 Instead, it is used in conjunction with those methods, and it 147 relieves those methods of the burden to deliver the context for each 148 SRTP source to every SRTP participant. This document defines how EKT 149 works with the DTLS-SRTP approach to key establishment, by using keys 150 derived from the DTLS-SRTP handshake to encipher the EKTKey in 151 addition to the SRTP media. 153 2. Overview 155 This specification defines a way for the server in a DTLS-SRTP 156 negotiation, see Section 5, to provide an EKTKey to the client during 157 the DTLS handshake. The EKTKey thus obtained can be used to encrypt 158 the SRTP master key that is used to encrypt the media sent by the 159 endpoint. This specification also defines a way to send the 160 encrypted SRTP master key (with the EKTKey) along with the SRTP 161 packet, see Section 4. Endpoints that receive this and know the 162 EKTKey can use the EKTKey to decrypt the SRTP master key which can 163 then be used to decrypt the SRTP packet. 165 One way to use this is described in the architecture defined by 166 [I-D.ietf-perc-private-media-framework]. Each participant in the 167 conference forms a DTLS-SRTP connection to a common key distributor 168 that distributes the same EKTKey to all the endpoints. Then each 169 endpoint picks its own SRTP master key for the media they send. When 170 sending media, the endpoint also includes the SRTP master key 171 encrypted with the EKTKey in the SRTP packet. This allows all the 172 endpoints to decrypt the media. 174 3. Conventions Used In This Document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 4. Encrypted Key Transport 184 EKT defines a new method of providing SRTP master keys to an 185 endpoint. In order to convey the ciphertext corresponding to the 186 SRTP master key, and other additional information, an additional 187 field, called EKTField, is added to the SRTP packets. The EKTField 188 appears at the end of the SRTP packet. It appears after the optional 189 authentication tag if one is present, otherwise the EKTField appears 190 after the ciphertext portion of the packet. 192 EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key 193 Identifier) or with SRTP's [RFC3711], as those SRTP 194 features duplicate some of the functions of EKT. Senders MUST NOT 195 include MKI when using EKT. Receivers SHOULD simply ignore any MKI 196 field received if EKT is in use. 198 This document defines the use of EKT with SRTP. Its use with SRTCP 199 would be similar, but is reserved for a future specification. SRTP 200 is preferred for transmitting key material because it shares fate 201 with the transmitted media, because SRTP rekeying can occur without 202 concern for RTCP transmission limits, and because it avoids the need 203 for SRTCP compound packets with RTP translators and mixers. 205 4.1. EKTField Formats 207 The EKTField uses the format defined in Figure 1 for the FullEKTField 208 and ShortEKTField. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 : : 214 : EKT Ciphertext : 215 : : 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Security Parameter Index | Epoch | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Length |0 0 0 0 0 0 1 0| 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: FullEKTField format 224 0 1 2 3 4 5 6 7 225 +-+-+-+-+-+-+-+-+ 226 |0 0 0 0 0 0 0 0| 227 +-+-+-+-+-+-+-+-+ 229 Figure 2: ShortEKTField format 231 The following shows the syntax of the EKTField expressed in ABNF 232 [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP 233 packet. The EKTPlaintext is the concatenation of 234 SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The 235 EKTCiphertext is computed by encrypting the EKTPlaintext using the 236 EKTKey. Future extensions to the EKTField MUST conform to the syntax 237 of ExtensionEKTField. 239 BYTE = %x00-FF 241 EKTMsgTypeFull = %x02 242 EKTMsgTypeShort = %x00 243 EKTMsgTypeExtension = %x03-FF 245 EKTMsgLength = 2BYTE; 247 SRTPMasterKeyLength = BYTE 248 SRTPMasterKey = 1*256BYTE 249 SSRC = 4BYTE; SSRC from RTP 250 ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC 252 EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 254 EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 255 Epoch = 2BYTE 256 SPI = 2BYTE 258 FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull 260 ShortEKTField = EKTMsgTypeShort 262 ExtensionData = 1*1024BYTE 263 ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 265 EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 267 Figure 3: EKTField Syntax 269 These fields and data elements are defined as follows: 271 EKTPlaintext: The data that is input to the EKT encryption operation. 272 This data never appears on the wire, and is used only in computations 273 internal to EKT. This is the concatenation of the SRTP Master Key 274 and its length, the SSRC, and the ROC. 276 EKTCiphertext: The data that is output from the EKT encryption 277 operation, described in Section 4.4. This field is included in SRTP 278 packets when EKT is in use. The length of EKTCiphertext can be 279 larger than the length of the EKTPlaintext that was encrypted. 281 SRTPMasterKey: On the sender side, the SRTP Master Key associated 282 with the indicated SSRC. 284 SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This 285 depends on the cipher suite negotiated for SRTP using SDP Offer/ 286 Answer [RFC3264] for the SRTP. 288 SSRC: On the sender side, this is the SSRC for this SRTP source. The 289 length of this field is 32 bits. The SSRC value in the EKT tag MUST 290 be the same as the one in the header of the SRTP packet to which the 291 tag is appended. 293 Rollover Counter (ROC): On the sender side, this is set to the 294 current value of the SRTP rollover counter in the SRTP/SRTCP context 295 associated with the SSRC in the SRTP or SRTCP packet. The length of 296 this field is 32 bits. 298 Security Parameter Index (SPI): This field indicates the appropriate 299 EKTKey and other parameters for the receiver to use when processing 300 the packet, within a given conference. The length of this field is 301 16 bits, representing a two-byte integer in network byte order. The 302 parameters identified by this field are: 304 o The EKT cipher used to process the packet. 306 o The EKTKey used to process the packet. 308 o The SRTP Master Salt associated with any master key encrypted with 309 this EKT Key. The master salt is communicated separately, via 310 signaling, typically along with the EKTKey. (Recall that the SRTP 311 master salt is used in the formation of IVs / nonces.) 313 Epoch: This field indicates how many SRTP keys have been sent for 314 this SSRC under the current EKTKey, prior to the current key, as a 315 two-byte integer in network byte order. It starts at zero at the 316 beginning of a session and resets to zero whenever the EKTKey is 317 changed (i.e., when a new SPI appears). The epoch for an SSRC 318 increments by one every time the sender transmits a new key. The 319 recipient of a FullEKTField MUST reject any future FullEKTField for 320 this SPI and SSRC that has an equal or lower epoch value to an epoch 321 already seen. 323 Together, these data elements are called an EKT parameter set. Each 324 distinct EKT parameter set that is used MUST be associated with a 325 distinct SPI value to avoid ambiguity. 327 EKTMsgLength: All EKT messages types other than the ShortEKTField 328 have a length as second from the last element. This is the length in 329 octets (in network byte order) of either the FullEKTField/ 330 ExtensionEKTField including this length field and the following EKT 331 Message Type. 333 Message Type: The last byte is used to indicate the type of the 334 EKTField. This MUST be 2 for the FullEKTField format and 0 in 335 ShortEKTField format. If a received EKT tag has an unknown message 336 type, then the receiver MUST discard the whole EKT tag. 338 4.2. SPIs and EKT Parameter Sets 340 The SPI field identifies the parameters for how the EKT tag should be 341 processed: 343 o The EKTKey and EKT cipher used to process the packet. 345 o The SRTP Master Salt associated with any master key encrypted with 346 this EKT Key. The master salt is communicated separately, via 347 signaling, typically along with the EKTKey. 349 Together, these data elements are called an "EKT parameter set". 350 Each distinct EKT parameter set that is used MUST be associated with 351 a distinct SPI value to avoid ambiguity. The association of a given 352 parameter set with a given SPI value is configured by some other 353 protocol, e.g., the DTLS-SRTP extension defined in Section 5. 355 4.3. Packet Processing and State Machine 357 At any given time, each SRTP/SRTCP source has associated with it a 358 single EKT parameter set. This parameter set is used to process all 359 outbound packets, and is called the outbound parameter set for that 360 SSRC. There may be other EKT parameter sets that are used by other 361 SRTP/SRTCP sources in the same session, including other SRTP/SRTCP 362 sources on the same endpoint (e.g., one endpoint with voice and video 363 might have two EKT parameter sets, or there might be multiple video 364 sources on an endpoint each with their own EKT parameter set). All 365 of the received EKT parameter sets SHOULD be stored by all of the 366 participants in an SRTP session, for use in processing inbound SRTP 367 and SRTCP traffic. If a participant deletes an EKT parameter set 368 (e.g., because of space limitations, then it will be unable to 369 process Full EKT Tags containing updated media keys, and thus unable 370 to receive media from a particpant that has changed its media key. 372 Either the FullEKTField or ShortEKTField is appended at the tail end 373 of all SRTP packets. The decision on which to send when is specified 374 in Section 4.6. 376 4.3.1. Outbound Processing 378 See Section 4.6 which describes when to send an SRTP packet with a 379 FullEKTField. If a FullEKTField is not being sent, then a 380 ShortEKTField is sent so the receiver can correctly determine how to 381 process the packet. 383 When an SRTP packet is sent with a FullEKTField, the EKTField for 384 that packet is created as follows, or uses an equivalent set of 385 steps. The creation of the EKTField MUST precede the normal SRTP 386 packet processing. 388 1. The Security Parameter Index (SPI) field is set to the value of 389 the Security Parameter Index that is associated with the outbound 390 parameter set. 392 2. The EKTPlaintext field is computed from the SRTP Master Key, 393 SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP 394 Master Key, and SSRC used in EKT processing MUST be the same as 395 the one used in the SRTP processing. 397 3. The EKTCiphertext field is set to the ciphertext created by 398 encrypting the EKTPlaintext with the EKTCipher using the EKTKey 399 as the encryption key. The encryption process is detailed in 400 Section 4.4. 402 4. Then the FullEKTField is formed using the EKTCiphertext and the 403 SPI associated with the EKTKey used above. Also appended are the 404 Length and Message Type using the FullEKTField format. 406 * Note: the value of the EKTCiphertext field is identical in 407 successive packets protected by the same EKTKey and SRTP 408 master key. This value MAY be cached by an SRTP sender to 409 minimize computational effort. 411 The computed value of the FullEKTField is appended to the end of the 412 SRTP packet, after the encrypted payload. 414 When a packet is sent with the ShortEKTField, the ShortEKFField is 415 simply appended to the packet. 417 Outbound packets SHOULD continue to use the old SRTP Master Key for 418 250 ms after sending any new key in a FullEKTField value. This gives 419 all the receivers in the system time to get the new key before they 420 start receiving media encrypted with the new key. (The specific 421 value of 250ms is chosen to represent a reasonable upper bound on the 422 amount of latency and jitter that is tolerable in a real-time 423 context.) 425 4.3.2. Inbound Processing 427 When receiving a packet on a RTP stream, the following steps are 428 applied for each SRTP received packet. 430 1. The final byte is checked to determine which EKT format is in 431 use. When an SRTP or SRTCP packet contains a ShortEKTField, the 432 ShortEKTField is removed from the packet then normal SRTP or 433 SRTCP processing occurs. If the packet contains a FullEKTField, 434 then processing continues as described below. The reason for 435 using the last byte of the packet to indicate the type is that 436 the length of the SRTP or SRTCP part is not known until the 437 decryption has occurred. At this point in the processing, there 438 is no easy way to know where the EKTField would start. However, 439 the whole UDP packet has been received, so instead of the 440 starting at the front of the packet, the parsing works backwards 441 at the end of the packet and thus the type is placed at the very 442 end of the packet. 444 2. The Security Parameter Index (SPI) field is used to find the 445 right EKT parameter set to be used for processing the packet. If 446 there is no matching SPI, then the verification function MUST 447 return an indication of authentication failure, and the steps 448 described below are not performed. The EKT parameter set 449 contains the EKTKey, EKTCipher, and the SRTP Master Salt. 451 3. The EKTCiphertext is authenticated and decrypted, as described in 452 Section 4.4, using the EKTKey and EKTCipher found in the previous 453 step. If the EKT decryption operation returns an authentication 454 failure, then EKT processing MUST be aborted. The receiver 455 SHOULD discard the whole UDP packet. 457 4. The resulting EKTPlaintext is parsed as described in Section 4.1, 458 to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP 459 Master Salt that is associated with the EKTKey is also retrieved. 460 If the value of the srtp_master_salt sent as part of the EKTkey 461 is longer than needed by SRTP, then it is truncated by taking the 462 first N bytes from the srtp_master_salt field. 464 5. If the SSRC in the EKTPlaintext does not match the SSRC of the 465 SRTP packet received, then all the information from this 466 EKTPlaintext MUST be discarded and the following steps in this 467 list are skipped. 469 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous 470 steps are saved in a map indexed by the SSRC found in the 471 EKTPlaintext and can be used for any future crypto operations on 472 the inbound packets with that SSRC. 474 * Unless the transform specifies other acceptable key lengths, 475 the length of the SRTP Master Key MUST be the same as the 476 master key length for the SRTP transform in use. If this is 477 not the case, then the receiver MUST abort EKT processing and 478 SHOULD discared the whole UDP packet. 480 * If the length of the SRTP Master Key is less than the master 481 key length for the SRTP transform in use, and the transform 482 specifies that this length is acceptable, then the SRTP Master 483 Key value is used to replace the first bytes in the existing 484 master key. The other bytes remain the same as in the old 485 key. For example, the Double GCM transform 486 [I-D.ietf-perc-double] allows replacement of the first, "end 487 to end" half of the master key. 489 7. At this point, EKT processing has successfully completed, and the 490 normal SRTP or SRTCP processing takes place. 492 The value of the EKTCiphertext field is identical in successive 493 packets protected by the same EKT parameter set and the same SRTP 494 master key, and ROC. SRTP senders and receivers MAY cache an 495 EKTCiphertext value to optimize processing in cases where the master 496 key hasn't changed. Instead of encrypting and decrypting, senders 497 can simply copy the pre-computed value and receivers can compare a 498 received EKTCiphertext to the known value. 500 Section 4.3.1 recommends that SRTP senders continue using an old key 501 for some time after sending a new key in an EKT tag. Receivers that 502 wish to avoid packet loss due to decryption failures MAY perform 503 trial decryption with both the old key and the new key, keeping the 504 result of whichever decryption succeeds. Note that this approach is 505 only compatible with SRTP transforms that include integrity 506 protection. 508 When receiving a new EKTKey, implementations need to use the ekt_ttl 509 field (see Section 5.2.2) to create a time after which this key 510 cannot be used and they also need to create a counter that keeps 511 track of how many times the key has been used to encrypt data to 512 ensure it does not exceed the T value for that cipher (see 513 Section 4.4). If either of these limits are exceeded, the key can no 514 longer be used for encryption. At this point implementation need to 515 either use the call signaling to renegotiate a new session or need to 516 terminate the existing session. Terminating the session is a 517 reasonable implementation choice because these limits should not be 518 exceeded except under an attack or error condition. 520 4.4. Ciphers 522 EKT uses an authenticated cipher to encrypt and authenticate the 523 EKTPlaintext. This specification defines the interface to the 524 cipher, in order to abstract the interface away from the details of 525 that function. This specification also defines the default cipher 526 that is used in EKT. The default cipher described in Section 4.4.1 527 MUST be implemented, but another cipher that conforms to this 528 interface MAY be used. The cipher used for a given EKTCiphertext 529 value is negotiated using the supported_ekt_ciphers and indicated 530 with the SPI value in the FullEKTField. 532 An EKTCipher consists of an encryption function and a decryption 533 function. The encryption function E(K, P) takes the following 534 inputs: 536 o a secret key K with a length of L bytes, and 538 o a plaintext value P with a length of M bytes. 540 The encryption function returns a ciphertext value C whose length is 541 N bytes, where N may be larger than M. The decryption function D(K, 542 C) takes the following inputs: 544 o a secret key K with a length of L bytes, and 546 o a ciphertext value C with a length of N bytes. 548 The decryption function returns a plaintext value P that is M bytes 549 long, or returns an indication that the decryption operation failed 550 because the ciphertext was invalid (i.e. it was not generated by the 551 encryption of plaintext with the key K). 553 These functions have the property that D(K, E(K, P)) = P for all 554 values of K and P. Each cipher also has a limit T on the number of 555 times that it can be used with any fixed key value. The EKTKey MUST 556 NOT be used for encryption more that T times. Note that if the same 557 FullEKTField is retransmitted 3 times, that only counts as 1 558 encryption. 560 Security requirements for EKT ciphers are discussed in Section 6. 562 4.4.1. AES Key Wrap 564 The default EKT Cipher is the Advanced Encryption Standard (AES) Key 565 Wrap with Padding [RFC5649] algorithm. It requires a plaintext 566 length M that is at least one octet, and it returns a ciphertext with 567 a length of N = M + (M mod 8) + 8 octets. 569 It can be used with key sizes of L = 16, and L = 32 octets, and its 570 use with those key sizes is indicated as AESKW128, or AESKW256, 571 respectively. The key size determines the length of the AES key used 572 by the Key Wrap algorithm. With this cipher, T=2^48. 574 +----------+----+------+ 575 | Cipher | L | T | 576 +----------+----+------+ 577 | AESKW128 | 16 | 2^48 | 578 | AESKW256 | 32 | 2^48 | 579 +----------+----+------+ 581 Table 1: EKT Ciphers 583 As AES-128 is the mandatory to implement transform in SRTP, AESKW128 584 MUST be implemented for EKT and AESKW256 MAY be implemented. 586 4.4.2. Defining New EKT Ciphers 588 Other specifications may extend this document by defining other 589 EKTCiphers as described in Section 7. This section defines how those 590 ciphers interact with this specification. 592 An EKTCipher determines how the EKTCiphertext field is written, and 593 how it is processed when it is read. This field is opaque to the 594 other aspects of EKT processing. EKT ciphers are free to use this 595 field in any way, but they SHOULD NOT use other EKT or SRTP fields as 596 an input. The values of the parameters L, and T MUST be defined by 597 each EKTCipher. The cipher MUST provide integrity protection. 599 4.5. Synchronizing Operation 601 If a source has its EKTKey changed by the key management, it MUST 602 also change its SRTP master key, which will cause it to send out a 603 new FullEKTField. This ensures that if key management thought the 604 EKTKey needs changing (due to a participant leaving or joining) and 605 communicated that to a source, the source will also change its SRTP 606 master key, so that traffic can be decrypted only by those who know 607 the current EKTKey. 609 4.6. Timing and Reliability Consideration 611 A system using EKT learns the SRTP master keys distributed with the 612 FullEKTField sent with the SRTP, rather than with call signaling. A 613 receiver can immediately decrypt an SRTP packet, provided the SRTP 614 packet contains a FullEKTField. 616 This section describes how to reliably and expediently deliver new 617 SRTP master keys to receivers. 619 There are three cases to consider. The first case is a new sender 620 joining a session, which needs to communicate its SRTP master key to 621 all the receivers. The second case is a sender changing its SRTP 622 master key which needs to be communicated to all the receivers. The 623 third case is a new receiver joining a session already in progress 624 which needs to know the sender's SRTP master key. 626 The three cases are: 628 New sender: 629 A new sender SHOULD send a packet containing the FullEKTField as 630 soon as possible, always before or coincident with sending its 631 initial SRTP packet. To accommodate packet loss, it is 632 RECOMMENDED that three consecutive packets contain the 633 FullEKTField be transmitted. If the sender does not send a 634 FullEKTField in its initial packets and receivers have not 635 otherwise been provisioned with a decryption key, then decryption 636 will fail and SRTP packets will be dropped until the receiver 637 receives a FullEKTField from the sender. 639 Rekey: 640 By sending EKT tag over SRTP, the rekeying event shares fate with 641 the SRTP packets protected with that new SRTP master key. To 642 accommodate packet loss, it is RECOMMENDED that three consecutive 643 packets contain the FullEKTField be transmitted. 645 New receiver: 646 When a new receiver joins a session it does not need to 647 communicate its sending SRTP master key (because it is a 648 receiver). When a new receiver joins a session, the sender is 649 generally unaware of the receiver joining the session. Thus, 650 senders SHOULD periodically transmit the FullEKTField. That 651 interval depends on how frequently new receivers join the session, 652 the acceptable delay before those receivers can start processing 653 SRTP packets, and the acceptable overhead of sending the 654 FullEKTField. If sending audio and video, the RECOMMENDED 655 frequency is the same as the rate of intra coded video frames. If 656 only sending audio, the RECOMMENDED frequency is every 100ms. 658 5. Use of EKT with DTLS-SRTP 660 This document defines an extension to DTLS-SRTP called SRTP EKTKey 661 Transport which enables secure transport of EKT keying material from 662 the DTLS-SRTP peer in the server role to the client. This allows 663 those peers to process EKT keying material in SRTP (or SRTCP) and 664 retrieve the embedded SRTP keying material. This combination of 665 protocols is valuable because it combines the advantages of DTLS, 666 which has strong authentication of the endpoint and flexibility, 667 along with allowing secure multiparty RTP with loose coordination and 668 efficient communication of per-source keys. 670 In cases where the DTLS termination point is more trusted than the 671 media relay, the protection that DTLS affords to EKT key material can 672 allow EKT keys to be tunneled through an untrusted relay such as a 673 centralized conference bridge. For more details, see 674 [I-D.ietf-perc-private-media-framework]. 676 5.1. DTLS-SRTP Recap 678 DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers 679 to exchange keying material, algorithms, and parameters for SRTP. 680 The SRTP flow operates over the same transport as the DTLS-SRTP 681 exchange (i.e., the same 5-tuple). DTLS-SRTP combines the 682 performance and encryption flexibility benefits of SRTP with the 683 flexibility and convenience of DTLS-integrated key and association 684 management. DTLS-SRTP can be viewed in two equivalent ways: as a new 685 key management method for SRTP, and a new RTP-specific data format 686 for DTLS. 688 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 690 This document defines a new TLS negotiated extension 691 supported_ekt_ciphers and a new TLS handshake message type ekt_key. 692 The extension negotiates the cipher to be used in encrypting and 693 decrypting EKTCiphertext values, and the handshake message carries 694 the corresponding key. 696 Figure 4 shows a message flow of DTLS 1.3 client and server using EKT 697 configured using the DTLS extensions described in this section. (The 698 initial cookie exchange and other normal DTLS messages are omitted.) 699 To be clear, EKT can be used with versions of DTLS prior to 1.3. The 700 only difference is that in a pre-1.3 TLS stacks will not have built- 701 in support for generating and processing ACK messages. 703 Client Server 705 ClientHello 706 + use_srtp 707 + supported_ekt_ciphers 708 --------> 710 ServerHello 711 {EncryptedExtensions} 712 + use_srtp 713 + supported_ekt_ciphers 714 {... Finished} 715 <-------- 717 {... Finished} --------> 719 [ACK] 720 <-------- [EKTKey] 722 [ACK] --------> 724 |SRTP packets| <-------> |SRTP packets| 725 + + 727 {} Messages protected using DTLS handshake keys 729 [] Messages protected using DTLS application traffic keys 731 <> Messages protected using the EKTKey and EKT cipher 733 || Messages protected using the SRTP Master Key sent in 734 a Full EKT Tag 736 Figure 4 738 In the context of a multi-party SRTP session in which each endpoint 739 performs a DTLS handshake as a client with a central DTLS server, the 740 extensions defined in this document allow the DTLS server to set a 741 common EKTKey for all participants. Each endpoint can then use EKT 742 tags encrypted with that common key to inform other endpoint of the 743 keys it uses to protect SRTP packets. This avoids the need for many 744 individual DTLS handshakes among the endpoints, at the cost of 745 preventing endpoints from directly authenticating one another. 747 Client A Server Client B 749 <----DTLS Handshake----> 750 <--------EKTKey--------- 751 <----DTLS Handshake----> 752 ---------EKTKey--------> 754 -------------SRTP Packet + EKT Tag-------------> 755 <------------SRTP Packet + EKT Tag-------------- 757 5.2.1. Negotiating an EKTCipher 759 To indicate its support for EKT, a DTLS-SRTP client includes in its 760 ClientHello an extension of type supported_ekt_ciphers listing the 761 ciphers used for EKT by the client supports in preference order, with 762 the most preferred version first. If the server agrees to use EKT, 763 then it includes a supported_ekt_ciphers extension in its ServerHello 764 containing a cipher selected from among those advertised by the 765 client. 767 The extension_data field of this extension contains an "EKTCipher" 768 value, encoded using the syntax defined in [RFC8446]: 770 enum { 771 reserved(0), 772 aeskw_128(1), 773 aeskw_256(2), 774 } EKTCipherType; 776 struct { 777 select (Handshake.msg_type) { 778 case client_hello: 779 EKTCipherType supported_ciphers<1..255>; 781 case server_hello: 782 EKTCipherType selected_cipher; 783 }; 784 } EKTCipher; 786 5.2.2. Establishing an EKT Key 788 Once a client and server have concluded a handshake that negotiated 789 an EKTCipher, the server MUST provide to the client a key to be used 790 when encrypting and decrypting EKTCiphertext values. EKTKeys are 791 sent in encrypted handshake records, using handshake type 792 ekt_key(TBD). The body of the handshake message contains an EKTKey 793 structure: 795 [[ NOTE: RFC Editor, please replace "TBD" above with the code point 796 assigned by IANA ]] 798 struct { 799 opaque ekt_key_value<1..256>; 800 opaque srtp_master_salt<1..256>; 801 uint16 ekt_spi; 802 uint24 ekt_ttl; 803 } EKTKey; 805 The contents of the fields in this message are as follows: 807 ekt_key_value 808 The EKTKey that the recipient should use when generating 809 EKTCiphertext values 811 srtp_master_salt 812 The SRTP Master Salt to be used with any Master Key encrypted with 813 this EKT Key 815 ekt_spi 816 The SPI value to be used to reference this EKTKey and SRTP Master 817 Salt in EKT tags (along with the EKT cipher negotiated in the 818 handshake) 820 ekt_ttl 821 The maximum amount of time, in seconds, that this EKTKey can be 822 used. The ekt_key_value in this message MUST NOT be used for 823 encrypting or decrypting information after the TTL expires. 825 If the server did not provide a supported_ekt_ciphers extension in 826 its ServerHello, then EKTKey messages MUST NOT be sent by the client 827 or the server. 829 When an EKTKey is received and processed successfully, the recipient 830 MUST respond with an ACK message as described in Section 7 of 831 [I-D.ietf-tls-dtls13]. The EKTKey message and ACK MUST be 832 retransmitted following the rules of the negotiated version of DTLS. 834 EKT MAY be used with versions of DTLS prior to 1.3. In such cases, 835 the ACK message is still used to provide reliability. Thus, DTLS 836 implementations supporting EKT with DTLS pre-1.3 will need to have 837 explicit affordances for sending the ACK message in response to an 838 EKTKey message, and for verifying that an ACK message was received. 839 The retransmission rules for both sides are otherwise defined by the 840 negotiated version of DTLS. 842 If an EKTKey message is received that cannot be processed, then the 843 recipient MUST respond with an appropriate DTLS alert. 845 5.3. Offer/Answer Considerations 847 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 848 the DTLS handshake level and does not change the [RFC3264] Offer / 849 Answer messaging. 851 5.4. Sending the DTLS EKTKey Reliably 853 The DTLS EKTKey message is sent using the retransmissions specified 854 in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished 855 with an ACK message or an alert is received. 857 6. Security Considerations 859 EKT inherits the security properties of the the key management 860 protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP 861 extension defined in this document. 863 With EKT, each SRTP sender and receiver MUST generate distinct SRTP 864 master keys. This property avoids any security concern over the re- 865 use of keys, by empowering the SRTP layer to create keys on demand. 866 Note that the inputs of EKT are the same as for SRTP with key- 867 sharing: a single key is provided to protect an entire SRTP session. 868 However, EKT remains secure even when SSRC values collide. 870 SRTP master keys MUST be randomly generated, and [RFC4086] offers 871 some guidance about random number generation. SRTP master keys MUST 872 NOT be re-used for any other purpose, and SRTP master keys MUST NOT 873 be derived from other SRTP master keys. 875 The EKT Cipher includes its own authentication/integrity check. For 876 an attacker to successfully forge a FullEKTField, it would need to 877 defeat the authentication mechanisms of the EKT Cipher authentication 878 mechanism. 880 The presence of the SSRC in the EKTPlaintext ensures that an attacker 881 cannot substitute an EKTCiphertext from one SRTP stream into another 882 SRTP stream. This mitigates the impact of the cut-and-paste attacks 883 that arise due to the lack of a cryptographic binding between the EKT 884 tag and the rest of the SRTP packet. SRTP tags can only be cut-and- 885 pasted within the stream of packets sent by a given RTP endpoint; an 886 attacker cannot "cross the streams" and use an EKT tag from one SSRC 887 to reset the key for another SSRC. The epoch field in the 888 FullEKTField also prevents an attacker from rolling back to a 889 previous key. 891 An attacker could send packets containing a FullEKTField, in an 892 attempt to consume additional CPU resources of the receiving system 893 by causing the receiving system to decrypt the EKT ciphertext and 894 detect an authentication failure. In some cases, caching the 895 previous values of the Ciphertext as described in Section 4.3.2 helps 896 mitigate this issue. 898 In a similar vein, EKT has no replay protection, so an attacker could 899 implant improper keys in receivers by capturing EKTCiphertext values 900 encrypted with a given EKTKey and replaying them in a different 901 context, e.g., from a different sender. When the underlying SRTP 902 transform provides integrity protection, this attack will just result 903 in packet loss. If it does not, then it will result in random data 904 being fed to RTP payload processing. An attacker that is in a 905 position to mount these attacks, however, could achieve the same 906 effects more easily without attacking EKT. 908 The key encryption keys distributed with EKTKey messages are group 909 shared symmetric keys, which means they do not provide protection 910 within the group. Group members can impersonate each other; for 911 example, any group member can generate an EKT tag for any SSRC. The 912 entity that distributes EKTKeys can decrypt any keys distributed 913 using EKT, and thus any media protected with those keys. 915 Each EKT cipher specifies a value T that is the maximum number of 916 times a given key can be used. An endpoint MUST NOT encrypt more 917 than T different FullEKTField values using the same EKTKey. In 918 addition, the EKTKey MUST NOT be used beyond the lifetime provided by 919 the TTL described in Section 5.2. 921 The confidentiality, integrity, and authentication of the EKT cipher 922 MUST be at least as strong as the SRTP cipher and at least as strong 923 as the DTLS-SRTP ciphers. 925 Part of the EKTPlaintext is known, or easily guessable to an 926 attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. 927 In practice, this requirement does not impose any restrictions on our 928 choices, since the ciphers in use provide high security even when 929 much plaintext is known. 931 An EKT cipher MUST resist attacks in which both ciphertexts and 932 plaintexts can be adaptively chosen and adversaries that can query 933 both the encryption and decryption functions adaptively. 935 In some systems, when a member of a conference leaves the 936 conferences, the conferences is rekeyed so that member no longer has 937 the key. When changing to a new EKTKey, it is possible that the 938 attacker could block the EKTKey message getting to a particular 939 endpoint and that endpoint would keep sending media encrypted using 940 the old key. To mitigate that risk, the lifetime of the EKTKey MUST 941 be limited using the ekt_ttl. 943 7. IANA Considerations 945 7.1. EKT Message Types 947 IANA is requested to create a new table for "EKT Messages Types" in 948 the "Real-Time Transport Protocol (RTP) Parameters" registry. The 949 initial values in this registry are: 951 +--------------+-------+---------------+ 952 | Message Type | Value | Specification | 953 +--------------+-------+---------------+ 954 | Short | 0 | RFCAAAA | 955 | Full | 2 | RFCAAAA | 956 | Unallocated | 3-254 | RFCAAAA | 957 | Reserved | 255 | RFCAAAA | 958 +--------------+-------+---------------+ 960 Table 2: EKT Messages Types 962 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 963 this specification. 965 New entries to this table can be added via "Specification Required" 966 as defined in [RFC8126]. IANA SHOULD prefer allocation of even 967 values over odd ones until the even code points are consumed to avoid 968 conflicts with pre standard versions of EKT that have been deployed. 969 Allocated values MUST be in the range of 0 to 254. 971 All new EKT messages MUST be defined to have a length as second from 972 the last element, as specified. 974 7.2. EKT Ciphers 976 IANA is requested to create a new table for "EKT Ciphers" in the 977 "Real-Time Transport Protocol (RTP) Parameters" registry. The 978 initial values in this registry are: 980 +-------------+-------+---------------+ 981 | Name | Value | Specification | 982 +-------------+-------+---------------+ 983 | AESKW128 | 0 | RFCAAAA | 984 | AESKW256 | 1 | RFCAAAA | 985 | Unallocated | 2-254 | | 986 | Reserved | 255 | RFCAAAA | 987 +-------------+-------+---------------+ 989 Table 3: EKT Cipher Types 991 Note to RFC Editor: Please replace RFCAAAA with the RFC number for 992 this specification. 994 New entries to this table can be added via "Specification Required" 995 as defined in [RFC8126]. The expert SHOULD ensure the specification 996 defines the values for L and T as required in Section 4.4 of RFCAAAA. 997 Allocated values MUST be in the range of 0 to 254. 999 7.3. TLS Extensions 1001 IANA is requested to add supported_ekt_ciphers as a new extension 1002 name to the "TLS ExtensionType Values" table of the "Transport Layer 1003 Security (TLS) Extensions" registry: 1005 Value: [TBD-at-Registration] 1006 Extension Name: supported_ekt_ciphers 1007 TLS 1.3: CH, SH 1008 Recommended: Y 1009 Reference: RFCAAAA 1011 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 1013 7.4. TLS Handshake Type 1015 IANA is requested to add ekt_key as a new entry in the "TLS 1016 HandshakeType Registry" table of the "Transport Layer Security (TLS) 1017 Parameters" registry: 1019 Value: [TBD-at-Registration] 1020 Description: ekt_key 1021 DTLS-OK: Y 1022 Reference: RFCAAAA 1023 Comment: 1025 [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 1027 8. Acknowledgements 1029 Thank you to Russ Housley provided detailed review and significant 1030 help with crafting text for this document. Thanks to David Benham, 1031 Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul 1032 Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean 1033 Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, 1034 comments, and contributions to this document. 1036 9. References 1038 9.1. Normative References 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", BCP 14, RFC 2119, 1042 DOI 10.17487/RFC2119, March 1997, 1043 . 1045 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1046 with Session Description Protocol (SDP)", RFC 3264, 1047 DOI 10.17487/RFC3264, June 2002, 1048 . 1050 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1051 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1052 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1053 . 1055 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1056 Specifications: ABNF", STD 68, RFC 5234, 1057 DOI 10.17487/RFC5234, January 2008, 1058 . 1060 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1061 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1062 DOI 10.17487/RFC5649, September 2009, 1063 . 1065 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1066 Security (DTLS) Extension to Establish Keys for the Secure 1067 Real-time Transport Protocol (SRTP)", RFC 5764, 1068 DOI 10.17487/RFC5764, May 2010, 1069 . 1071 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1072 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1073 January 2012, . 1075 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1076 Writing an IANA Considerations Section in RFCs", BCP 26, 1077 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1078 . 1080 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1081 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1082 May 2017, . 1084 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1085 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1086 . 1088 9.2. Informative References 1090 [I-D.ietf-perc-double] 1091 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 1092 Double Encryption Procedures", draft-ietf-perc-double-12 1093 (work in progress), August 2019. 1095 [I-D.ietf-perc-private-media-framework] 1096 Jones, P., Benham, D., and C. Groves, "A Solution 1097 Framework for Private Media in Privacy Enhanced RTP 1098 Conferencing (PERC)", draft-ietf-perc-private-media- 1099 framework-12 (work in progress), June 2019. 1101 [I-D.ietf-tls-dtls13] 1102 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1103 Datagram Transport Layer Security (DTLS) Protocol Version 1104 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1105 2020. 1107 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1108 "Randomness Requirements for Security", BCP 106, RFC 4086, 1109 DOI 10.17487/RFC4086, June 2005, 1110 . 1112 Authors' Addresses 1114 Cullen Jennings 1115 Cisco Systems 1117 Email: fluffy@iii.ca 1118 John Mattsson 1119 Ericsson AB 1121 Email: john.mattsson@ericsson.com 1123 David A. McGrew 1124 Cisco Systems 1126 Email: mcgrew@cisco.com 1128 Dan Wing 1129 Citrix Systems, Inc. 1131 Email: dwing-ietf@fuggles.com 1133 Flemming Andreason 1134 Cisco Systems 1136 Email: fandreas@cisco.com