idnits 2.17.1 draft-ietf-avt-dtls-srtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1079. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2007) is 6256 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) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 221 ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4347 (ref. '5') (Obsoleted by RFC 6347) == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-05 == Outdated reference: A later version (-03) exists of draft-fischl-sipping-media-dtls-02 == Outdated reference: A later version (-04) exists of draft-fischl-mmusic-sdp-dtls-02 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-01) exists of draft-mcgrew-srtp-big-aes-00 == Outdated reference: A later version (-01) exists of draft-rescorla-tls-extractor-00 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track E. Rescorla 5 Expires: September 11, 2007 Network Resonance 6 March 10, 2007 8 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for 9 Secure Real-time Transport Protocol (SRTP) 10 draft-ietf-avt-dtls-srtp-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 11, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The Secure Real-time Transport Protocol (SRTP) is a profile of the 44 Real-time Transport Protocol that can provide confidentiality, 45 message authentication, and replay protection to the RTP traffic and 46 to the control traffic for RTP, the Real-time Transport Control 47 Protocol (RTCP). This document describes a method of using DTLS key 48 management for SRTP by using a new extension that indicates that SRTP 49 is to be used for data protection, and which establishes SRTP keys. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Usage Model . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5 58 3.2.1. use_srtp Extension Definition . . . . . . . . . . . . 6 59 3.2.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 6 60 3.2.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 8 61 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 9 62 3.4. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.5. Key Usage Limitations . . . . . . . . . . . . . . . . . . 11 64 3.6. Data Protection . . . . . . . . . . . . . . . . . . . . . 11 65 3.6.1. Transmission . . . . . . . . . . . . . . . . . . . . . 11 66 3.6.2. Reception . . . . . . . . . . . . . . . . . . . . . . 12 67 3.7. Rehandshake and Re-key . . . . . . . . . . . . . . . . . . 13 68 4. Multi-party RTP Sessions . . . . . . . . . . . . . . . . . . . 13 69 4.1. SIP Forking . . . . . . . . . . . . . . . . . . . . . . . 14 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 5.1. Security of Negotiation . . . . . . . . . . . . . . . . . 14 72 5.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 14 73 5.3. Sequence Number Interactions . . . . . . . . . . . . . . . 15 74 5.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 8.2. Informational References . . . . . . . . . . . . . . . . . 16 81 Appendix A. Open Issue: Key/Stream Interaction . . . . . . . . . 17 82 Appendix B. Open Issue: Using a single DTLS session per SRTP 83 session . . . . . . . . . . . . . . . . . . . . . . . 19 84 B.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 20 85 B.1.1. SRTP Parameter Profiles for Single-DTLS . . . . . . . 21 86 B.2. Pros and Cons of Single-DTLS . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 88 Intellectual Property and Copyright Statements . . . . . . . . . . 24 90 1. Introduction 92 The Secure Real-time Transport Protocol (SRTP) [6] is a profile of 93 the Real-time Transport Protocol (RTP) [1] that can provide 94 confidentiality, message authentication, and replay protection to RTP 95 traffic and to the control traffic for RTP, the Real-time Transport 96 Control Protocol (RTCP). SRTP does not provide key management 97 functionality but instead depends on external key management to 98 provide secret master keys and the algorithms and parameters for use 99 with those keys. 101 Datagram Transport Layer Security (DTLS) [5] is a channel security 102 protocol that offers integrated key management, parameter 103 negotiation, and secure data transfer. Because DTLS's data transfer 104 protocol is generic, it is less highly optimized for use with RTP 105 than is SRTP, which has been specifically tuned for that purpose. 107 This document describes DTLS-SRTP, an SRTP extension for DTLS which 108 combine the performance and encryption flexibility benefits of SRTP 109 with the flexibility and convenience of DTLS's integrated key and 110 association management. DTLS-SRTP can be viewed in two equivalent 111 ways: as a new key management method for SRTP, and a new RTP- 112 specific data format for DTLS. 114 This extension MUST only be used when the data being transported is 115 RTP and RTCP [4]. 117 The key points of DTLS-SRTP are that: 118 o application data is protected using SRTP, 119 o the DTLS handshake is used to establish keying material, 120 algorithms, and parameters for SRTP, 121 o a DTLS extension used to negotiate SRTP algorithms, and 122 o other DTLS record layer content types are protected using the 123 ordinary DTLS record format. 124 The next section provides details of the new extension. 126 2. Conventions Used In This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [2]. 132 3. Protocol Description 134 In this section we define the DTLS extension and its use. 136 3.1. Usage Model 138 DTLS-SRTP is defined for point-to-point media sessions, in which 139 there are exactly two participants. Each DTLS-SRTP session contains 140 a single DTLS association (called a "connection" in TLS jargon), and 141 an SRTP context. A single DTLS-SRTP session only protects data 142 carried over a single UDP source and destination port pair. 144 If both RTCP and RTP use the same source and destination ports [7], 145 then the both the RTCP packets and the RTP packets are protected by a 146 single DTLS-SRTP session. Otherwise, each RTCP flow is protected by 147 a separate DTLS-SRTP session that is independent from the DTLS-SRTP 148 session that protects the RTP packet flow. 150 Symmetric RTP is the case in which there are two RTP sessions that 151 have their source and destination ports and addresses reversed, in a 152 manner similar to the way that a TCP connection uses its ports. Each 153 participant has an inbound RTP session and an outbound RTP session. 154 When symmetric RTP is used, a single DTLS-SRTP session can protect 155 both of the RTP sessions. 157 Between a single pair of participants, there may be multiple media 158 sessions. There MUST be a separate DTLS-SRTP session for each 159 distinct pair of source and destination ports used by a media session 160 (though the sessions can share a single DTLS session and hence 161 amortize the initial public key handshake!). One or both of the 162 DTLS-SRTP session participants MAY be RTP mixers. 164 A DTLS-SRTP session can be indicated by an external signaling 165 protocol like SIP. When the signaling exchange is integrity- 166 protected (e.g when SIP Identity protection via digital signatures is 167 used), DTLS-SRTP can leverage this integrity guarantee to provide 168 complete security of the media stream. A description of how to 169 indicate DTLS-SRTP sessions in SIP and SDP, and how to authenticate 170 the endpoints using fingerprints can be found in [9] and [8]. 172 In a naive implementation, when there are multiple media sessions, 173 there is a new DTLS session establishment (complete with public key 174 cryptography) for each media channel. For example, a videophone may 175 be sending both an audio stream and a video stream, each of which 176 would use a separate DTLS session establishment exchange, which would 177 proceed in parallel. As an optimization, the DTLS-SRTP 178 implementation SHOULD use the following strategy: a single DTLS 179 connection is established, and all other DTLS sessions wait until 180 that connection is established before proceeding with their session 181 establishment exchanges. This strategy allows the later sessions to 182 use the DTLS session re-start, which allows the amortization of the 183 expensive public key cryptography operations over multiple DTLS 184 session establishment instances. 186 The SRTP keys used to protect packets originated by the client are 187 distinct from the SRTP keys used to protect packets originated by the 188 server. All of the RTP sources originating on the client use the 189 same SRTP keys, and similarly, all of the RTP sources originating on 190 the server over the same channel use the same SRTP keys. The SRTP 191 implementation MUST ensure that all of the SSRC values for all of the 192 RTP sources originating from the same device are distinct, in order 193 to avoid the "two-time pad" problem (as described in Section 9.1 of 194 RFC 3711). 196 3.2. The use_srtp Extension 198 In order to negotiate the use of SRTP data protection, clients MAY 199 include an extension of type "use_srtp" in the extended client hello. 200 The "extension_data" field of this extension contains the list of 201 acceptable SRTP protection profiles, as indicated below. 203 Servers that receive an extended hello containing a "use_srtp" 204 extension MAY agree to use SRTP by including an extension of type 205 "use_srtp", with the chosen protection profile in the extended server 206 hello. This process is shown below. 208 Client Server 210 ClientHello + use_srtp --------> 211 ServerHello + use_srtp 212 Certificate* 213 ServerKeyExchange* 214 CertificateRequest* 215 <-------- ServerHelloDone 216 Certificate* 217 ClientKeyExchange 218 CertificateVerify* 219 [ChangeCipherSpec] 220 Finished --------> 221 [ChangeCipherSpec] 222 <-------- Finished 223 SRTP packets <-------> SRTP packets 225 Once the "use_srtp" extension is negotiated, packets of type 226 "application_data" in the newly negotiated association (i.e., after 227 the change_cipher_spec) MUST be protected using SRTP and packets of 228 type "application_data" MUST NOT be sent. Records of type other than 229 "application_data" MUST use ordinary DTLS framing. When the 230 "use_srtp" extension is in effect, implementations MUST NOT place 231 more than one "record" per datagram. (This is only meaningful from 232 the perspective of DTLS because SRTP is inherently oriented towards 233 one payload per packet, but is stated purely for clarification.) 235 3.2.1. use_srtp Extension Definition 237 The client MUST fill the extension_data field of the "use_srtp" 238 extension with an UseSRTPData value: 240 uint8 SRTPProtectionProfile[2]; 242 struct { 243 SRTPProtectionProfiles SRTPProtectionProfiles; 244 uint8 srtp_mki<255>; 245 } UseSRTPData; 247 SRTPProtectionProfile SRTPProtectionProfiles<2^16-1>; 249 The SRTPProtectionProfiles list indicates the SRTP protection 250 profiles that the client is willing to support, listed in descending 251 order of preference. The srtp_mki value contains the SRTP 252 MasterKeyIdentifier (MKI) value (if any) which the client will use 253 for his SRTP messages. 255 If the server is willing to accept the use_srtp extension, it MUST 256 respond with its own "use_srtp" extension in the ExtendedServerHello. 257 The extension_data field MUST contain a UseSRTPData value with a 258 single SRTPProtectionProfile value which the server has chosen for 259 use with this connection. The server MUST NOT select a value which 260 the client has not offered. If there is no shared profile, the 261 server should not return the use_srtp extension at which point the 262 connection falls back to the negotiated DTLS cipher suite. If that 263 is not acceptable the server should return an appropriate DTLS alert. 265 3.2.2. SRTP Protection Profiles 267 A DTLS-SRTP SRTP Protection Profile defines the parameters and 268 options that are in effect for the SRTP processing. This document 269 defines the following SRTP protection profiles. 271 SRTPProtectionProfile SRTP_AES128_CM_SHA1_80 = {0x00, 0x01}; 272 SRTPProtectionProfile SRTP_AES128_CM_SHA1_32 = {0x00, 0x02}; 273 SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03}; 274 SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04}; 275 SRTPProtectionProfile SRTP_NULL_SHA1_80 = {0x00, 0x05}; 276 SRTPProtectionProfile SRTP_NULL_SHA1_32 = {0x00, 0x06}; 278 The following list indicates the SRTP transform parameters for each 279 protection profile. The parameters cipher_key_length, 280 cipher_salt_length, auth_key_length, and auth_tag_length express the 281 number of bits in the values to which they refer. The 282 maximum_lifetime parameter indicates the maximum number of packets 283 that can be protected with each single set of keys when the parameter 284 profile is in use. All of these parameters apply to both RTP and 285 RTCP, unless the RTCP parameters are separately specified. 287 All of the crypto algorithms in these profiles are from [6], except 288 for the AES256_CM cipher, which is specified in [14]. 290 SRTP_AES128_CM_HMAC_SHA1_80 291 cipher: AES_128_CM 292 cipher_key_length: 128 293 cipher_salt_length: 112 294 maximum_lifetime: 2^31 295 auth_function: HMAC-SHA1 296 auth_key_length: 160 297 auth_tag_length: 80 298 SRTP_AES128_CM_HMAC_SHA1_32 299 cipher: AES_128_CM 300 cipher_key_length: 128 301 cipher_salt_length: 112 302 maximum_lifetime: 2^31 303 auth_function: HMAC-SHA1 304 auth_key_length: 160 305 auth_tag_length: 32 306 RTCP auth_tag_length: 80 307 SRTP_AES256_CM_HMAC_SHA1_80 308 cipher: AES_128_CM 309 cipher_key_length: 128 310 cipher_salt_length: 112 311 maximum_lifetime: 2^31 312 auth_function: HMAC-SHA1 313 auth_key_length: 160 314 auth_tag_length: 80 315 SRTP_AES256_CM_HMAC_SHA1_32 316 cipher: AES_128_CM 317 cipher_key_length: 128 318 cipher_salt_length: 112 319 maximum_lifetime: 2^31 320 auth_function: HMAC-SHA1 321 auth_key_length: 160 322 auth_tag_length: 32 323 RTCP auth_tag_length: 80 325 SRTP_NULL_HMAC_SHA1_80 326 cipher: NULL 327 cipher_key_length: 0 328 cipher_salt_length: 0 329 maximum_lifetime: 2^31 330 auth_function: HMAC-SHA1 331 auth_key_length: 160 332 auth_tag_length: 80 333 SRTP_NULL_HMAC_SHA1_32 334 cipher: NULL 335 cipher_key_length: 0 336 cipher_salt_length: 0 337 maximum_lifetime: 2^31 338 auth_function: HMAC-SHA1 339 auth_key_length: 160 340 auth_tag_length: 32 341 RTCP auth_tag_length: 80 343 With all of these SRTP Parameter profiles, the following SRTP options 344 are in effect: 346 o The TLS Key Derivation Function (KDF) is used to generate keys to 347 feed into the SRTP KDF. 348 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 349 not re-derived based on the SRTP sequence number. 350 o For all other parameters, the default values are used. 352 All SRTP parameters that are not determined by the SRTP Protection 353 Profile MAY be established via the signaling system. In particular, 354 the relative order of Forward Error Correction and SRTP processing, 355 and a suggested SRTP replay window size SHOULD be established in this 356 manner. An example of how these parameters can be defined for SDP by 357 is contained in [10]. 359 Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection 360 Profiles between the DTLS-SRTP session that protects an RTP flow and 361 the DTLS-SRTP session that protects the associated RTCP flow (in 362 those case in which the RTP and RTCP are not multiplexed over a 363 common port). In particular, identical ciphers SHOULD be used. 365 New SRTPProtectionProfile values must be defined by RFC 2434 366 Standards Action. See Section 6 for IANA Considerations. 368 3.2.3. srtp_mki value 370 The srtp_mki value MAY be used to indicate the capability and desire 371 to use the SRTP Master Key Indicator (MKI) field in the SRTP and 372 SRTCP packets. The MKI field indicates to an SRTP receiver which key 373 was used to protect the packet that contains that field. The 374 srtp_mki field contains the value of the SRTP MKI which is associated 375 with the SRTP master keys derived from this handshake. Each SRTP 376 session MUST have exactly one master key that is used to protect 377 packets at any given time. The client MUST choose the MKI value so 378 that it is distinct from the last MKI value that was used, and it 379 SHOULD make these values unique. 381 Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, 382 the server MUST either (assuming it accepts the extension at all): 384 1. include a matching "srtp_mki" value in its "use_srtp" extension 385 to indicate that it will make use of the MKI, or 386 2. return an empty "srtp_mki" value to indicate that it cannot make 387 use of the MKI. 389 If the client detects a nonzero-length MKI in the server's response 390 that is different than the one the client offered MUST abort the 391 handshake and SHOULD send an invalid_parameter alert. If the client 392 and server agree on an MKI, all SRTP packets protected under the new 393 security parameters MUST contain that MKI. 395 3.3. Key Derivation 397 When SRTP mode is in effect, different keys are used for ordinary 398 DTLS record protection and SRTP packet protection. These keys are 399 generated as additional keying material at the end of the DTLS key 400 block. Thus, the key block becomes: 402 client_write_MAC_secret[SecurityParameters.hash_size] 403 server_write_MAC_secret[SecurityParameters.hash_size] 404 client_write_key[SecurityParameters.key_material_len] 405 server_write_key[SecurityParameters.key_material_len] 406 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len] 407 server_write_SRTP_master_key[SRTPSecurityParams.master_key_len] 408 client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len] 409 server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len] 411 NOTE: It would probably be more attractive to use a TLS extractor as 412 defined in [15]. However, this technique has not yet been vetted by 413 the TLS WG and therefore this remains an open issue. 415 The last four values are provided as inputs to the SRTP key 416 derivation mechanism, as shown in Figure 5 and detailed below. By 417 default, the mechanism defined in Section 4.3 of [6] is used, unless 418 another key derivation mechanism is specified as part of an SRTP 419 Protection Profile. 421 The client_write_SRTP_master_key and client_write_SRTP_master_salt 422 are provided to one invocation of the SRTP key derivation function, 423 to generate the SRTP keys used to encrypt and authenticate packets 424 sent by the client. The server MUST only use these keys to decrypt 425 and to check the authenticity of inbound packets. 427 The server_write_SRTP_master_key and server_write_SRTP_master_salt 428 are provided to one invocation of the SRTP key derivation function, 429 to generate the SRTP keys used to encrypt and authenticate packets 430 sent by the server. The client MUST only use these keys to decrypt 431 and to check the authenticity of inbound packets. 433 +------- TLS master secret 434 | 435 v +-> client_write_MAC_secret 436 +-----+ | 437 | TLS |--+-> server_write_MAC_secret 438 | KDF | | 439 +-----+ +-> client_write_key 440 | 441 +-> server_write_key 442 | +------+ SRTP 443 +-> client_write_SRTP_master_key ----->| SRTP |-> client 444 | +--->| KDF | write 445 +-> server_write_SRTP_master_key --|-+ +------+ keys 446 | | | 447 +-> client_write_SRTP_master_salt -+ | +------+ SRTP 448 | +->| SRTP |-> server 449 +-> server_write_SRTP_master_salt ----->| KDF | write 450 +------+ keys 452 Figure 5: The derivation of the SRTP keys. 454 When both RTCP and RTP use the same source and destination ports, 455 then both the SRTP and SRTCP keys are need. Otherwise, there are two 456 DTLS-SRTP sessions, one of which protects the RTP packets and one of 457 which protects the RTCP packets; each DTLS-SRTP session protects the 458 part of an SRTP session that passes over a single source/destination 459 transport address pair, as shown in Figure 6. When a DTLS-SRTP 460 session is protecting RTP, the SRTCP keys derived from the DTLS 461 handshake are not needed and are discarded. When a DTLS-SRTP session 462 is protecting RTCP, the SRTP keys derived from the DTLS handshake are 463 not needed and are discarded. 465 Client Server 466 (Sender) (Receiver) 467 (1) <----- DTLS ------> src/dst = a/b and b/a 468 ------ SRTP ------> src/dst = a/b, uses client write keys 470 (2) <----- DTLS ------> src/dst = c/d and d/c 471 ------ SRTCP -----> src/dst = c/d, uses client write keys 472 <----- SRTCP ------ src/dst = d/c, uses server write keys 474 Figure 6: A DTLS-SRTP session protecting RTP (1) and another one 475 protecting RTCP (2), showing the transport addresses and keys used. 477 3.4. Key Scope 479 Because of the possibility of packet reordering, DTLS-SRTP 480 implementations SHOULD store multiple SRTP keys sets during a re-key 481 in order to avoid the need for receivers to drop packets for which 482 they lack a key. 484 3.5. Key Usage Limitations 486 The maximum_lifetime parameter in the SRTP protection profile 487 indicates the maximum number of packets that can be protected with 488 each single encryption and authentication key. (Note that, since RTP 489 and RTCP are protected with independent keys, those protocols are 490 counted separately for the purposes of determining when a key has 491 reached the end of its lifetime.) Each profile defines its own 492 limit. When this limit is reached, a new DTLS session SHOULD be used 493 to establish replacement keys, and SRTP implementations MUST NOT use 494 the existing keys for the processing of either outbound or inbound 495 traffic. 497 3.6. Data Protection 499 Once the DTLS handshake has completed the peers can send RTP or RTCP 500 over the newly created channel. We describe the transmission process 501 first followed by the reception process. 503 Within each RTP session, SRTP processing MUST NOT take place before 504 the DTLS handshake completes. 506 3.6.1. Transmission 508 DTLS and TLS define a number of record content types. In ordinary 509 TLS/DTLS, all data is protected using the same record encoding and 510 mechanisms. When the mechanism described in this document is in 511 effect, this is modified so that data of type "application_data" 512 (used to transport data traffic) is encrypted using SRTP rather than 513 the standard TLS record encoding. 515 When a user of DTLS wishes to send an RTP packet in SRTP mode it 516 delivers it to the DTLS implementation as a single write of type 517 "application_data". The DTLS implementation then invokes the 518 processing described in RFC 3711 Sections 3 and 4. The resulting 519 SRTP packet is then sent directly on the wire as a single datagram 520 with no DTLS framing. This provides an encapsulation of the data 521 that conforms to and interoperates with SRTP. Note that the RTP 522 sequence number rather than the DTLS sequence number is used for 523 these packets. 525 3.6.2. Reception 527 When DTLS-SRTP is used to protect an RTP session, the RTP receiver 528 needs to demultiplex packets that are arriving on the RTP port. 529 Arriving packets may be of types RTP, DTLS, or STUN[13]. The type of 530 a packet can be determined by looking at its first byte. 532 The process for demultiplexing a packet is as follows. The receiver 533 looks at the first byte of the packet. If the value of this byte is 534 0 or 1, then the packet is STUN. If the value is in between 128 and 535 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 536 RTP are being multiplexed over the same destination port). If the 537 value is between 20 and 63 (inclusive), the packet is DTLS. This 538 processes is summarized in Figure 7. 540 +----------------+ 541 | 127 < B < 192 -+--> forward to RTP 542 | | 543 packet --> | 19 < B < 64 -+--> forward to DTLS 544 | | 545 | B < 2 -+--> forward to STUN 546 +----------------+ 548 Figure 7: The DTLS-SRTP receiver's packet demultiplexing 549 algorithm. Here the field B denotes the leading byte of the packet. 551 3.6.2.1. Opportunistic Probing 553 [[Open Issue In discussions of media-level security, some have 554 suggested that a desirable property is to allow the endpoints to 555 automatically detect the capability to do security at the media layer 556 without interaction from the signalling. This issue is primarily out 557 of scope for this document, however because of the demuxing mentioned 558 above, it is possible for an implementation to "probe" by sending 559 DTLS handshake packets and seeing if they are answered. A DTLS-SRTP 560 implementation can demux the packets, detect that a handshake has 561 been requested and notify the application to potentially initiate a 562 DTLS-SRTP association. It is, however, necessary to have a rule to 563 break the symmetry as to which side is client and which server. In 564 applications where the media channel is established via SDP, the 565 offeror should be the server and the answerer the client.]] 567 3.7. Rehandshake and Re-key 569 Rekeying in DTLS is accomplished by performing a new handshake over 570 the existing DTLS channel. This handshake can be performed in 571 parallel with data transport, so no interruption of the data flow is 572 required. Once the handshake is finished, the newly derived set of 573 keys is used to protect all outbound packets, both DTLS and SRTP. 575 Because of packet reordering, packets protected by the previous set 576 of keys can appear on the wire after the handshake has completed. To 577 compensate for this fact, receivers SHOULD maintain both sets of keys 578 for some time in order to be able to decrypt and verify older 579 packets. The keys should be maintained for the duration of the 580 maximum segment lifetime (MSL). 582 If an MKI is used, then the receiver should use the corresponding set 583 of keys to process an incoming packet. Otherwise, when a packet 584 arrives after the handshake completed, a receiver SHOULD use the 585 newly derived set of keys to process that packet unless there is an 586 MKI (If the packet was protected with the older set of keys, this 587 fact will become apparent to the receiver as an authentication 588 failure will occur.) If the authentication check on the packet fails 589 and no MKI is being used, then the receiver MAY process the packet 590 with the older set of keys. If that authentication check indicates 591 that the packet is valid, the packet should be accepted; otherwise, 592 the packet MUST be discarded and rejected. 594 Receivers MAY use the SRTP packet sequence number to aid in the 595 selection of keys. After a packet has been received and 596 authenticated with the new key set, any packets with sequence numbers 597 that are greater will also have been protected with the new key set. 599 4. Multi-party RTP Sessions 601 Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only 602 to protect RTP sessions in which there are exactly two participants. 603 This does not preclude its use with RTP mixers. For example, a 604 conference bridge may use DTLS-SRTP to secure the communication to 605 and from each of the participants in a conference. 607 4.1. SIP Forking 609 When SIP parallel forking occurs while establishing an RTP session, a 610 situation may arise in which two or more sources are sending RTP 611 packets to a single RTP destination transport address. When this 612 situation arises and DTLS-SRTP is in use, the receiver MUST use the 613 source transport IP address and port of each packet to distinguish 614 between the senders, and treat the flow of packets from each distinct 615 source transport address as a distinct DTLS-SRTP session for the 616 purposes of the DTLS association. 618 When SIP forking occurs, the following method can be used to 619 correlate each answer to the corresponding DTLS-SRTP session. If the 620 answers have different certificates then fingerprints in the answers 621 can be used to correlate the SIP dialogs with the associated DTLS 622 session. Note that two forks with the same certificate cannot be 623 distinguished at the DTLS level, but this problem is a generic 624 problem with SIP forking and should be solved at a higher level. 626 5. Security Considerations 628 The use of multiple data protection framings negotiated in the same 629 handshake creates some complexities, which are discussed here. 631 5.1. Security of Negotiation 633 One concern here is that attackers might be able to implement a bid- 634 down attack forcing the peers to use ordinary DTLS rather than SRTP. 635 However, because the negotiation of this extension is performed in 636 the DTLS handshake, it is protected by the Finished messages. 637 Therefore, any bid-down attack is automatically detected, which 638 reduces this to a denial of service attack - which any attacker who 639 can control the channel can always mount. 641 5.2. Framing Confusion 643 Because two different framing formats are used, there is concern that 644 an attacker could convince the receiver to treat an SRTP-framed RTP 645 packet as a DTLS record (e.g., a handshake message) or vice versa. 646 This attack is prevented by using different keys for MAC verification 647 for each type of data. Therefore, this type of attack reduces to 648 being able to forge a packet with a valid MAC, which violates a basic 649 security invariant of both DTLS and SRTP. 651 As an additional defense against injection into the DTLS handshake 652 channel, the DTLS record type is included in the MAC. Therefore, an 653 SRTP record would be treated as an unknown type and ignored. (See 654 Section 6 of [11]). 656 5.3. Sequence Number Interactions 658 As described in Section 3.6.1, the SRTP and DTLS sequence number 659 spaces are distinct. This means that it is not possible to 660 unambiguously order a given DTLS control record with respect to an 661 SRTP packet. In general, this is relevant in two situations: alerts 662 and rehandshake. 664 5.3.1. Alerts 666 Because DTLS handshake and change_cipher_spec messages share the same 667 sequence number space as alerts, they can be ordered correctly. 668 Because DTLS alerts are inherently unreliable and SHOULD NOT be 669 generated as a response to data packets, reliable sequencing between 670 SRTP packets and DTLS alerts is not an important feature. However, 671 implementations which wish to use DTLS alerts to signal problems with 672 the SRTP encoding SHOULD simply act on alerts as soon as they are 673 received and assume that they refer to the temporally contiguous 674 stream. Such implementations MUST check for alert retransmission and 675 discard retransmitted alerts to avoid overreacting to replay attacks. 677 5.3.2. Renegotiation 679 Because the rehandshake transition algorithm specified in Section 680 Section 3.7 requires trying multiple sets of keys if no MKI is used, 681 it slightly weakens the authentication. For instance, if an n-bit 682 MAC is used and k different sets of keys are present, then the MAC is 683 weakened by log_2(k) bits to n - log_2(k). In practice, since the 684 number of keys used will be very small and the MACs in use are 685 typically strong (the default for SRTP is 80 bits) the decrease in 686 security involved here is minimal. 688 Another concern here is that this algorithm slightly increases the 689 work factor on the receiver because it needs to attempt multiple 690 validations. However, again, the number of potential keys will be 691 very small (and the attacker cannot force it to be larger) and this 692 technique is already used for rollover counter management, so the 693 authors do not consider this to be a serious flaw. 695 6. IANA Considerations 697 This document a new extension for DTLS, in accordance with [12]: 698 enum { use_srtp (??) } ExtensionType; 700 [[ NOTE: This value needs to be assigned by IANA ]] 701 This extension MUST only be used with DTLS, and not with TLS. 703 Section 3.2.2 requires that all SRTPProtectionProfile values be 704 defined by RFC 2434 Standards Action. IANA SHOULD create a DTLS 705 SRTPProtectionProfile registry initially populated with values from 706 Section 3.2.2 of this document. Future values MUST be allocated via 707 Standards Action as described in [3] 709 7. Acknowledgments 711 Special thanks to Jason Fischl, Flemming Andreasen, Dan Wing, and 712 Cullen Jennings for input, discussions, and guidance. 714 8. References 716 8.1. Normative References 718 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 719 "RTP: A Transport Protocol for Real-Time Applications", 720 RFC 1889, January 1996. 722 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 723 Levels", BCP 14, RFC 2119, March 1997. 725 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 726 Considerations Section in RFCs", BCP 26, RFC 2434, 727 October 1998. 729 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 730 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 731 RFC 3550, July 2003. 733 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 734 Security", RFC 4347, April 2006. 736 [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 737 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 738 RFC 3711, March 2004. 740 8.2. Informational References 742 [7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 743 Control Packets on a Single Port", 744 draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), 745 May 2007. 747 [8] Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol 748 for Protection of Media Traffic Established with the Session 749 Initiation Protocol", draft-fischl-sipping-media-dtls-02 (work 750 in progress), March 2007. 752 [9] Fischl, J. and H. Tschofenig, "Session Description Protocol 753 (SDP) Indicators for Datagram Transport Layer Security 754 (DTLS)", draft-fischl-mmusic-sdp-dtls-02 (work in progress), 755 March 2007. 757 [10] Andreasen, F., "Session Description Protocol Security 758 Descriptions for Media Streams", 759 draft-ietf-mmusic-sdescriptions-12 (work in progress), 760 September 2005. 762 [11] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 763 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 765 [12] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", 766 draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005. 768 [13] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)", 769 draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007. 771 [14] McGrew, D., "The use of AES-192 and AES-256 in Secure RTP", 772 draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006. 774 [15] Rescorla, E., "Keying Material Extractors for Transport Layer 775 Security (TLS)", draft-rescorla-tls-extractor-00 (work in 776 progress), January 2007. 778 Appendix A. Open Issue: Key/Stream Interaction 780 Standard practice for security protocols such as TLS, DTLS, and SSH 781 which do inline key management is to create a separate security 782 association for each underlying network channel (TCP connection, UDP 783 host/port quartet, etc.). This has dual advantages of simplicity and 784 independence of the security contexts for each channel. 786 Three concerns have been raised about the overhead of this strategy 787 in the context of RTP security. The first concern is the additional 788 performance overhead of doing a separate public key operation for 789 each channel. The conventional procedure here (used in TLS and DTLS) 790 is to establish a master context which can then be used to derive 791 fresh traffic keys for new associations. In TLS/DTLS this is called 792 "session resumption" and can be transparently negotiated between the 793 peers. Similar techniques could be applied to other inline RTP 794 security protocols. 796 The second concern is network bandwidth overhead for the 797 establishment of subsequent connections and for rehandshake (for 798 rekeying) for existing connections. In particular, there is a 799 concern that the channels will have very narrow capacity requirements 800 allocated entirely to media which will be overflowed by the 801 rehandshake. Measurements of the size of the rehandshake (with 802 resumption) in TLS indicate that it is about 300-400 bytes if a full 803 selection of cipher suites is offered. (the size of a full handshake 804 is approximately 1-2k larger because of the certificate and keying 805 material exchange). 807 The third concern is the additional round-trips associated with 808 establishing the 2nd, 3rd, ... channels. In TLS/DTLS these can all 809 be done in parallel but in order to take advantage of session 810 resumption they should be done after the first channel is 811 established. For two channels this provides a ladder diagram 812 something like this (parenthetical #s are media channel #s) 814 Alice Bob 815 ------------------------------------------- 816 <- ClientHello (1) 817 ServerHello (1) -> 818 Certificate (1) 819 ServerHelloDone (1) 820 <- ClientKeyExchange (1) 821 ChangeCipherSpec (1) 822 Finished (1) 823 ChangeCipherSpec (1)-> 824 Finished (1)-> 825 <--- Channel 1 ready 827 <- ClientHello (2) 828 ServerHello (2) -> 829 ChangeCipherSpec(2)-> 830 Finished(2) -> 831 <- ChangeCipherSpec (2) 832 Finished (2) 833 <--- Channel 2 ready 835 So, there is an additional 1 RTT after Channel 1 is ready before 836 Channel 2 is ready. If the peers are potentially willing to forego 837 resumption they can interlace the handshakes, like so: 839 Alice Bob 840 ------------------------------------------- 841 <- ClientHello (1) 842 ServerHello (1) -> 843 Certificate (1) 844 ServerHelloDone (1) 845 <- ClientKeyExchange (1) 846 ChangeCipherSpec (1) 847 Finished (1) 848 <- ClientHello (2) 849 ChangeCipherSpec (1)-> 850 Finished (1)-> 851 <--- Channel 1 ready 852 ServerHello (2) -> 853 ChangeCipherSpec(2)-> 854 Finished(2) -> 855 <- ChangeCipherSpec (2) 856 Finished (2) 857 <--- Channel 2 ready 859 In this case the channels are ready contemporaneously, but if a 860 message in handshake (1) is lost then handshake (2) requires either a 861 full rehandshake or that Alice be clever and queue the resumption 862 attempt until the first handshake completes. Note that just dropping 863 the packet works as well since Bob will retransmit. 865 We don't know if this is a problem yet or whether it is possible to 866 use some of the capacity allocated to other channels (e.g., RTCP) to 867 perform the rehandshake. Another alternative that has been proposed 868 is to use one security association connection on a single channel and 869 reuse the keying material across multiple channels, but this gives up 870 the simplicity and independence benefits mentioned above and so is 871 architecturally undesirable unless absolutely necessary. 873 Another alternative is to take advantage of the fact that an (S)RTP 874 channel is intended to be paired with an (S)RTCP channel. The DTLS 875 handshake could be performed on just one of those channels and the 876 same keys used for both the RTP and RTCP channels. This alternative 877 is defined in Appendix B for study and discussion. 879 Appendix B. Open Issue: Using a single DTLS session per SRTP session 881 In order to address the performance, bandwidth, and latency concerns 882 described in Appendix A, it may be desirable to use a single DTLS 883 session for each SRTP session. This appendix outlines one approach 884 for achieving that goal in the next subsection, and then describes 885 its benefits in the following one. However, note that the use of 886 symmetric RTP and the multiplexing of RTCP and RTP over a single port 887 pair largely eliminates this issue, since it allows a bidirectional 888 pair of SRTP sessions (complete with SRTP and SRTCP) to be 889 established following a single DTLS handshake. 891 B.1. Definition 893 This section defines the "Single DTLS" model by descibing its 894 differences from the DTLS-SRTP as defined in the body of this 895 document. A point-to-point SRTP session consists of a unidirectional 896 SRTP flow and a bidirectional SRTCP flow. In the Single-DTLS model, 897 a DTLS-SRTP session contains a single SRTP session and a single DTLS 898 connection. Within each SRTP session, there may be multiple SRTP 899 sources; all of these sources use a single SRTP master key. See 900 Figure 11. As before, the DTLS connection uses the same transport 901 addresses as the RTP flow; receivers demultiplex packets by 902 inspection of their first byte. 904 +------------------------------------------------+ 905 | TLS Master Secret | 906 | | | 907 | v | 908 | TLS PRF | 909 | | | 910 | +--------------------+---------------------+ | 911 | | | | | 912 | | v | | 913 | | SRTP Master Key | | 914 | | | | | 915 | | +------------+------------+ | | 916 | | | | | | | 917 | | v v v | | 918 | | +----------+ +----------+ | | 919 | | | SRTP | | SRTP | ... | | 920 | | | Source A | | Source B | | | 921 | | +----------+ +----------+ | | 922 | | | | 923 | | SRTP Session | | 924 | +------------------------------------------+ | 925 | | 926 | DTLS-SRTP Session | 927 +------------------------------------------------+ 929 Figure 11: Key derivation in the Single-DTLS model. 931 Until the SRTP keys have been established by the DTLS handshake, the 932 participants MUST reject all SRTP and SRTCP packets that they receive 933 in the DTLS-SRTP session. 935 The SRTP keys are derived as defined in Section 3.3, and are used as 936 shown in Figure 12. This figure should be contrasted with Figure 6. 938 Client Server 939 (Sender) (Receiver) 940 <----- DTLS ------> src/dst = a/b and b/a 941 ------ SRTP ------> src/dst = a/b, uses client write keys 942 ------ SRTCP -----> src/dst = c/d, uses client write keys 943 <----- SRTCP ------ src/dst = d/c, uses server write keys 945 Figure 12: A DTLS-SRTP session in the Single-DTLS model. 947 B.1.1. SRTP Parameter Profiles for Single-DTLS 949 The following list indicates the SRTP transform parameters for each 950 protection profile in the Single-DTLS model. The main difference is 951 that, in this model, an SRTP Parameter Profile determines the policy 952 for the protection of RTP and RTCP packets. 954 SRTP_AES128_CM_HMAC_SHA1_80 955 SRTP and SRTCP cipher: AES_128_CM 956 SRTP and SRTCP cipher_key_length: 128 957 SRTP and SRTCP cipher_salt_length: 112 958 SRTP maximum_lifetime: 2^48 959 SRTCP maximum_lifetime: 2^31 960 SRTP and SRTCP auth_function: HMAC-SHA1 961 SRTP and SRTCP auth_key_length: 160 962 SRTP and SRTCP auth_tag_length: 80 963 SRTP_AES128_CM_HMAC_SHA1_32 964 SRTP and SRTCP cipher: AES_128_CM 965 SRTP and SRTCP cipher_key_length: 128 966 SRTP and SRTCP cipher_salt_length: 112 967 SRTP maximum_lifetime: 2^48 968 SRTCP maximum_lifetime: 2^31 969 SRTP and SRTCP auth_function: HMAC-SHA1 970 SRTP and SRTCP auth_key_length: 160 971 SRTP auth_tag_length: 32 972 SRTCP auth_tag_length: 80 973 SRTP_AES256_CM_HMAC_SHA1_80 974 SRTP and SRTCP cipher: AES_128_CM 975 SRTP and SRTCP cipher_key_length: 128 976 SRTP and SRTCP cipher_salt_length: 112 977 SRTP maximum_lifetime: 2^48 978 SRTCP maximum_lifetime: 2^31 979 SRTP and SRTCP auth_function: HMAC-SHA1 980 SRTP and SRTCP auth_key_length: 160 981 SRTP and SRTCP auth_tag_length: 80 982 SRTP_AES256_CM_HMAC_SHA1_32 983 SRTP and SRTCP cipher: AES_128_CM 984 SRTP and SRTCP cipher_key_length: 128 985 SRTP and SRTCP cipher_salt_length: 112 986 SRTP maximum_lifetime: 2^48 987 SRTCP maximum_lifetime: 2^31 988 SRTP and SRTCP auth_function: HMAC-SHA1 989 SRTP and SRTCP auth_key_length: 160 990 SRTP auth_tag_length: 32 991 SRTCP auth_tag_length: 80 992 SRTP_NULL_HMAC_SHA1_80 993 SRTP and SRTCP cipher: NULL 994 SRTP and SRTCP cipher_key_length: 0 995 SRTP and SRTCP cipher_salt_length: 0 996 SRTP maximum_lifetime: 2^48 997 SRTCP maximum_lifetime: 2^31 998 SRTP and SRTCP auth_function: HMAC-SHA1 999 SRTP and SRTCP auth_key_length: 160 1000 SRTP and SRTCP auth_tag_length: 80 1001 SRTP_NULL_HMAC_SHA1_32 1002 SRTP and SRTCP cipher: NULL 1003 SRTP and SRTCP cipher_key_length: 0 1004 SRTP and SRTCP cipher_salt_length: 0 1005 SRTP maximum_lifetime: 2^48 1006 SRTCP maximum_lifetime: 2^31 1007 SRTP and SRTCP auth_function: HMAC-SHA1 1008 SRTP and SRTCP auth_key_length: 160 1009 SRTP auth_tag_length: 32 1010 SRTCP auth_tag_length: 80 1012 B.2. Pros and Cons of Single-DTLS 1014 Using a single DTLS session per SRTP session has potential 1015 performance benefits in terms of reducing latency and compution. The 1016 discussion of the performance of multiple parallel DTLS connections 1017 in Appendix A applies here as well. In addition, it provides a good 1018 match for existing SRTP implementations, since it matches their SRTP 1019 policy definitions for cryptographic algorithm configuration and 1020 makes use of all of the derived keys rather than having to discard 1021 half as described in Section 3.3. 1023 Authors' Addresses 1025 David McGrew 1026 Cisco Systems 1027 510 McCarthy Blvd. 1028 Milpitas, CA 95305 1029 USA 1031 Email: mcgrew@cisco.com 1033 Eric Rescorla 1034 Network Resonance 1035 2483 E. Bayshore #212 1036 Palo Alto, CA 94303 1037 USA 1039 Email: ekr@networkresonance.com 1041 Full Copyright Statement 1043 Copyright (C) The IETF Trust (2007). 1045 This document is subject to the rights, licenses and restrictions 1046 contained in BCP 78, and except as set forth therein, the authors 1047 retain all their rights. 1049 This document and the information contained herein are provided on an 1050 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1051 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1052 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1053 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1054 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1055 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1057 Intellectual Property 1059 The IETF takes no position regarding the validity or scope of any 1060 Intellectual Property Rights or other rights that might be claimed to 1061 pertain to the implementation or use of the technology described in 1062 this document or the extent to which any license under such rights 1063 might or might not be available; nor does it represent that it has 1064 made any independent effort to identify any such rights. Information 1065 on the procedures with respect to rights in RFC documents can be 1066 found in BCP 78 and BCP 79. 1068 Copies of IPR disclosures made to the IETF Secretariat and any 1069 assurances of licenses to be made available, or the result of an 1070 attempt made to obtain a general license or permission for the use of 1071 such proprietary rights by implementers or users of this 1072 specification can be obtained from the IETF on-line IPR repository at 1073 http://www.ietf.org/ipr. 1075 The IETF invites any interested party to bring to its attention any 1076 copyrights, patents or patent applications, or other proprietary 1077 rights that may cover technology that may be required to implement 1078 this standard. Please address the information to the IETF at 1079 ietf-ipr@ietf.org. 1081 Acknowledgment 1083 Funding for the RFC Editor function is provided by the IETF 1084 Administrative Support Activity (IASA).