idnits 2.17.1 draft-dondeti-msec-rtpsec-mikeyv2-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. 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 5, 2007) is 6252 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: 'IDr' is mentioned on line 418, but not defined == Missing Reference: 'CHASH' is mentioned on line 432, but not defined == Missing Reference: 'PKE' is mentioned on line 435, but not defined == Missing Reference: 'SIGNi' is mentioned on line 432, but not defined == Missing Reference: 'V' is mentioned on line 434, but not defined == Missing Reference: 'SIGNr' is mentioned on line 435, but not defined == Unused Reference: 'I-D.ietf-msec-mikey-ecc' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-msec-mikey-rsa-r' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-msec-mikey-applicability' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-msec-mikey-dhhmac' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-rtpsec-keying-eval' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-media-security-requirements' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-msec-mikey-ecc-01 == Outdated reference: A later version (-09) exists of draft-ietf-msec-mikey-applicability-03 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-wing-media-security-requirements-00 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG L. Dondeti 3 Internet-Draft QUALCOMM, Inc. 4 Intended status: Standards Track March 5, 2007 5 Expires: September 6, 2007 7 MIKEYv2: SRTP Key Management using MIKEY, revisited 8 draft-dondeti-msec-rtpsec-mikeyv2-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Multimedia Internet Keying (MIKEY) protocol is a general purpose 42 key management protocol; it is used especially for key management for 43 secure RTP. We specify a couple of variations of that protocol to 44 support mode negotiation, media path key establishment and other 45 assorted requirements. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Motivation to Designing MIKEYv2 . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. SRTP Key Management Design Goals, Constraints and Use Cases . 5 53 3.1. SRTP Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. SRTP Cryptographic Context . . . . . . . . . . . . . . . . 6 55 3.3. SRTCP Crypto Context . . . . . . . . . . . . . . . . . . . 6 56 4. MIKEYv2 Outline . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. MIKEYv2 Protocol Details: Option 1 . . . . . . . . . . . . . . 8 58 5.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 8 59 5.2. Create Crypto Context Exchange . . . . . . . . . . . . . . 9 60 6. MIKEYv2 Protocol Details: Option 2 . . . . . . . . . . . . . . 10 61 6.1. MIKEY Mode Negotiation Exchange . . . . . . . . . . . . . 10 62 6.2. MIKEY-RSA/PSK Exchange . . . . . . . . . . . . . . . . . . 10 63 7. Transporting MIKEYv2 Messages . . . . . . . . . . . . . . . . 11 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 The Multimedia Internet Keying (MIKEY) [RFC3830] protocol is a 76 general purpose key management protocol for real-time applications, 77 especially for SRTP. It's a half or one round trip authentication 78 and key delivery/establishment protocol that uses timestamps for 79 replay protection, and asymmetric or symmetric keys for entity 80 authentication. 82 MIKEY supports point-to-point as well as group key establishment and 83 is the protocol of choice in other standards development 84 organizations: for instance, the 3GPP Multimedia Broadcast and 85 Multicast Service (MBMS) uses MIKEY for session key establishment via 86 unicast and traffic key establishment and update via broadcast. 3GPP 87 uses the IANA assigned UDP port 2269 for MIKEY transport. The Open 88 Mobile Alliance (OMA)'s Broadcast (BCAST) specification uses MIKEY to 89 transport the long and short term key messages. 91 However, several shortcomings of MIKEY have been identified, 92 especially on its applicability to general purpose key management for 93 VoIP application. 95 MIKEY has too many modes and no real support for mode negotiation. 97 It requires time synchronization for replay protected. 99 MIKEY, as specified in RFC 3830 [RFC3830] requires SDP for 100 transport. 102 MIKEY-RSA mode requires that the Initiator of the protocol know 103 the identity and certificate of the recipient. This mode does not 104 handle SIP forking well. 106 MIKEY-PSK mode requires that the Initiator share a PSK with the 107 Responder. This is simply not a practical assumption. This mode 108 also does not handle SIP forking well. 110 MIKEY-RSA-R does not handle early media well. Early media may 111 arrive before the SDP answer arrives. 113 Next, after some debate and discussion at the IETF, there is a 114 consensus on some of the requirements for a common key management 115 protocol for an application such as VoIP so there is a chance for 116 cross-domain interoperability. The idea is to come up with a single 117 protocol for key management for SRTP. 119 However, given the variety of constraints and use cases, it may not 120 be possible to have a single universal key management protocol for 121 SRTP. Many of the devices that will need to implement the protocol 122 are resource-constrained and some of them have one of the candidate 123 protocols or their close cousins already implemented. There may be 124 resistance to implement another protocol. Next some of the 125 requirements may force resource-intensive computations, especially 126 when there is SIP forking; a PSTN gateway may not be able to perform 127 several DH computations per session. 129 1.1. Motivation to Designing MIKEYv2 131 There are at least two candidates for key management for SRTP, namely 132 DTLS-SRTP and zRTP other than MIKEYv2. Considering the goal of 133 specifying a single protocol, it makes sense to not design a new 134 protocol. So the question is why design MIKEYv2? We consider that 135 question in detail below: 137 First, MIKEY [RFC3830] was designed with SRTP as the primary 138 application and has taken into account a number of design 139 considerations. It is as good a candidate for reuse as any. None 140 of the shortcomings listed earlier are inherent to MIKEY. In the 141 end, just as any other candidate key management protocol it can be 142 extended to meet the requirements at hand. 144 Next, MIKEY is the key management protocol for SRTP for other use 145 cases such as broadcast key management. MIKEY is (planned to be) 146 implemented in a smartcard, which is typically the device with 147 which 3GPP and 3GPP2 operators share credentials with. The 148 question may be whether it is difficult to implement TLS or DTLS 149 on the smartcard. Difficult? Yes. Improbable, no! There are 150 known implementations of TLS on a smartcard. It is definitely 151 wasteful to have to implement two different protocols for key 152 management for SRTP on the same device, and especially on a 153 smartcard. 155 Finally, the current designs of some of the candidate protocols 156 seem to indicate that negotiation of SRTP parameters may have to 157 be split between the key management protocol and SDP. It is not 158 clear whether there is an inherent shortcoming in the key 159 management protocol or not. Furthermore, session reestablishment 160 semantics seem less than optimal. There is also no support for 161 group keying; whereas shared key conferencing is not a consensus 162 requirement, broadcast/multicast using SRTP is a known use case 163 today. Thus, it may be better to explore other options for key 164 management for SRTP. 166 With this background, we propose MIKEYv2. We consider two possible 167 designs: the first is to extend MIKEY along the lines of the IKEv2 168 [RFC4306], taking into account the lessons learned in the process of 169 implementing and deploying MIKEY. The second is to simply add mode 170 negotiation to base MIKEY exchanges limiting modifications to MIKEY 171 to an absolute minimum. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 In addition, we use the terminology in the MIKEY [RFC3830] and SRTP 180 [RFC3711] specifications. 182 3. SRTP Key Management Design Goals, Constraints and Use Cases 184 The primary goal of SRTP key management is to establish the 185 cryptographic context for SRTP encapsulation. In the rest of this 186 document, we refer to this as the SRTP crypto context. The 187 information includes, SRTP encryption and integrity protection keys, 188 cryptographic algorithms used, key lengths, initialization vectors 189 (IVs), salts and identifiers, and replay protection counters and 190 state information. The key management protocol is expected to 191 bootstrap the SRTP crypto context, and so we delve into the details 192 of these parameters and explore how communicating parties might be 193 able to arrive at sharing the same crypto context. Note that the RTP 194 traffic may be flowing between two parties or from one to two or more 195 parties. In the following, we list SRTP use cases, design goals and 196 constraints, and describe SRTP and SRTCP cryptographic context. 198 3.1. SRTP Use Cases 200 We identify three simple use cases: 202 Unicast: In the first, there are one or more RTP sessions between 203 two communicating parties and session keys need to be derived for 204 them. 206 One-to-many group communication: In the second, there are one or 207 more one-to-many RTP sessions, all from one sender to two or more 208 receivers. 210 Many-to-many group communication: The final use case is multi-party 211 multimedia conferencing, where two or more speakers are 212 originators of RTP streams (one or more each) and two or more 213 receivers are recipients of those streams. 215 3.2. SRTP Cryptographic Context 217 The SRTP specification [RFC3711] identifies transform dependent and 218 transform independent parameters that comprise the crypto context. 219 The transform-dependent parameters are as follows: 221 encryption algorithm, e.g., AES-CTR, AES-f8, and associated key 222 length 224 integrity protection transform, e.g., TESLA; integrity algorithm, 225 e.g., HMAC-SHA1, associated key length and output length (e.g., 226 MAC/ICV truncation) 228 key derivation parameters (e.g., PRF algorithm) 230 input for IV formation 232 The transform-independent parameters are listed below: 234 32-bit unsigned rollover counter (RoC), which records how many 235 times the 16-bit RTP sequence number has been reset to zero after 236 passing through 65,535 (2^16-1), 238 for each master key, an SRTP stream MAY use the following 239 associated values: 241 a master salt, to be used in the key derivation of session 242 keys. Note that the master salt, MUST be random, but MAY be 243 public 245 an integer in the set {1,2,4,...,2^24}, the 246 "key_derivation_rate"; the key management protocol may leave 247 this unspecified and in that cast the key_derivation_rate is 248 assumed to be zero 250 a master key identifier (MKI) value to identify the SRTP crypto 251 context 253 The key management system may also specify the lifetime of the 254 crypto context with a range of SRTP packet indices, From and 255 To. The SRTP packet index is a 48-bit value formed by 256 concatenating the 32-bit RoC with the 16-bit RTP packet index. 258 3.3. SRTCP Crypto Context 260 SRTCP by default shares the crypto context with SRTP, except there is 261 no need to establish the rollover counter via key management as the 262 RTCP index is explicitly carried in each SRTCP packet, 263 A cryptographic context SHALL be uniquely identified by the triplet 264 context identifier: 266 context id = < SSRC, destination network address, destination 267 transport port number > 269 where the destination network address and the destination transport 270 port are the ones in the SRTP packet. It is assumed that, when 271 presented with this information, the key management returns a context 272 with the information as described in Section 3.2. 274 4. MIKEYv2 Outline 276 MIKEYv2 supports mode negotiation, allows fast session 277 reestablishment using reduced roundtrip exchanges, but does not 278 require time synchronization. 280 MIKEYv2 runs over UDP (reusing the port number assigned for MIKEY) or 281 over RTP/RTCP. 283 It may be plausible to specify starting MIKEYv2 over the signaling 284 path and resume it via the media path (Steffen Fries talked about 285 this at various times). 287 MIKEYv2 reuses MIKEY payloads and introduces as few new payloads as 288 possible to facilitate the revised design and the new features. 289 MIKEYv2 messages use version number 0x02 in the common HDR payload 290 specified in RFC3830. Version number 0x02 is reserved for messages 291 described in this specification. Reuse of that version number is 292 allowed only with a revision of this specification. 294 MIKEYv2 takes two round trips to complete and establishes unicast 295 and/or group SRTP and/or SRTCP crypto contexts. We reuse the key 296 derivation and traffic key containers defined in RFC3830. The 297 payloads and message structure while retained, are essentially part 298 of a new key management protocol and need a fresh security analysis. 300 For fast session reestablishment, it is plausible to use one of the 301 RFC 3830 MIKEY exchange. 303 MIKEYv2 can also take advantage of the SAS technique introduced by 304 zRTP or the certificate fingerprint transport via SDP as described in 305 the context of DTLS-SRTP. 307 We explore two possible approaches to designing MIKEYv2: 309 MIKEYv2 is an authenticated DH key management protocol based on 310 SIGMA. In the first round trip, the communicating parties learn 311 each other's identities, agree on a MIKEY mode (type of entity 312 authentication primarily), MIKEY crypto algorithms, and exchange 313 nonces for replay protection. In the second round trip, they 314 negotiate unicast and/or group SRTP crypto context for SRTP and/or 315 SRTCP. 317 The second option is to simply add mode negotiation to MIKEY 318 exchanges. 320 5. MIKEYv2 Protocol Details: Option 1 322 MIKEYv2 has two sets of exchanges. The initial exchange consists of 323 identity establishment, MIKEY mode and algorithm negotiation and the 324 second exchange consists of SRTP and SRTCP crypto context 325 establishment. 327 5.1. Initial Exchange 329 MIKEYv2_INIT_EXCH message is as follows: 331 Initiator Responder 332 ========= ========= 334 HDR, RANDi, M-SPi, IDi, 335 [IDr], DHi ---> 337 <--- HDR, RANDr, M-SPr, IDr, 338 [CERTREQ,] DHr 340 Figure 1: MIKEYv2 Policy Negotiation Exchange 342 MIKEYv2 is closely modeled after IKEv2 [RFC4306] and relies on the 343 SIGMA protocol for its security. The payloads, at least most of 344 them, are reused from the original MIKEY specification, in the 345 interest of code reuse (and potential backward compatibility. This 346 is for further discussion and study). 348 MIKEYv2_INIT_EXCH is a Diffie-Hellman exchange, which allows the two 349 parties to establish an unauthenticated secure channel. 351 There is no identity protection as it is specified currently, but 352 that can be added easily. SIGMA provides some identity protection to 353 the Initiator's or the Responder's identities. 355 The M-SPi payloads allow MIKEY mode and algorithm negotiation for the 356 secure channel. These payloads are intended to be used to negotiate 357 the algorithm used in generating the AUTH and KEMAC paylods of the 358 MIKEYv2 SRTP Cryptographic Context Establishment Exchange or 359 MIKEYv2_SRTP_CCE. 361 In the second message, the Responder can request that Certificates be 362 used for entity authentication. The proposal is to allow negotiation 363 of this via the M-SPi payload. 365 The RAND paylods provide replay protection and are used to provide 366 entropy for key derivation in the unicast case. 368 5.2. Create Crypto Context Exchange 370 MIKEYv2_SRTP_CCE message is as follows: 372 Unicast case: 373 ============= 375 Initiator Responder 376 ========= ========= 378 HDR, [CERTi,] [CERTREQ,] 379 SRTP-SPi, AUTH, KEMAC ---> 381 <--- HDR, [CERTr,] SRTP-SPr 382 AUTH, KEMAC 384 Group key establishment: 385 ======================== 387 Initiator Group Controller 388 ========= ================ 390 HDR, [CERTi,] [CERTREQ,] 391 GCC-REQ, AUTH, KEMAC ---> 393 <--- HDR, [CERTr,] SRTP-SPg 394 AUTH, KEMAC 396 Figure 2: MIKEYv2 SRTP Crypto Context Establishment 398 The key material derived in the MIKEYv2_INIT_EXCH is used to protect 399 the messages/payloads of MIKEYv2_SRTP_CCE. The purpose of this 400 exchange is to authenticate the first exchange via the AUTH payloads 401 computed in a manner similar to that in RFC 4306 [RFC4306] and to 402 negotiate or distribute the SRTP crypto context via the SRTP-SP 403 payloads. The KEMAC payloads in the unicast case do not necessarily 404 contain keys, but the MAC portion of KEMAC integrity protects the 405 entire message. The KEMAC payload sent by the Group Controller MUST 406 contain keys. 408 6. MIKEYv2 Protocol Details: Option 2 410 6.1. MIKEY Mode Negotiation Exchange 412 MIKEYv2_MODE_NEG_EXCH message is as follows: 414 Initiator Responder 415 ========= ========= 417 HDR, RANDi, M-SPi, IDi, 418 [IDr], DHi ---> 420 <--- HDR, RANDr, M-SPr, IDr, 421 [CERTREQ,] DHr 423 Figure 3: MIKEYv2 Mode Negotiation Exchange 425 6.2. MIKEY-RSA/PSK Exchange 427 MIKEYv2_CCE2 message is as follows: 429 Initiator Responder 430 ========= ========= 431 HDR, T, RAND, {SP}, KEMAC, 432 [CHASH], [PKE, SIGNi] ---> 434 <--- HDR, T, IDr, [V], 435 [PKE, SIGNr] 437 Figure 4: MIKEYv2 SRTP Crypto Context Establishment Exchange 439 The idea here is to authenticate the initial exchange as part of the 440 SIGNx payload and provide a proof of possession of the key derived 441 using the DH exchange via the KEMAC and the V payload. These 442 processing semantics are slightly different from that of RFC 3830. 443 Note that these exchanges are shown to given an idea on how MIKEY may 444 be reused; the details are TBD. The T payload contains a sequence 445 number instead of a timestamp (note that the 3GPP MBMS specification 446 also uses a sequence number instead of a timestamp in the exchange). 448 The CCE exchange may be used for 1 RT rekeying. The timestamp field 449 contains a monotonically increasing sequence number (and serves a 450 similar purpose as the message-id field of IKEv2 [RFC4306]). 452 7. Transporting MIKEYv2 Messages 454 MIKEYv2 messages may be transported via UDP using IANA assigned port 455 2269. Alternatively, MIKEYv2 messages may share the RTP/RTCP port 456 with media/control packets. In the end, we may allow one option of 457 this based on consensus. 459 8. Security Considerations 461 Security considerations of RFC 3830 apply. For Option 1, security 462 considerations of RFC 4306 also apply. 464 9. IANA Considerations 466 Several IANA registrations may be required, include MIKEY version 467 number and new payload types. Detailed instructions to IANA will be 468 included in a future version. 470 10. Acknowledgments 472 This work benefited from discussions with various folks at the IETF, 473 among them are Flemming Andreasan, Francois Audet, Rolf Blom, Ran 474 Canetti, Steffen Fries, Dragan Ignjatic, Cullen Jennings, David 475 McGrew, Karl Norrman, Jon Peterson, Rohan Mahy, and Dan Wing. Note 476 that these folks may not necessarily be endorsing the MIKEYv2 477 protocol; in fact, it is plausible many of them do not even like the 478 protocol. 480 11. References 481 11.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 487 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 488 August 2004. 490 11.2. Informative References 492 [I-D.ietf-msec-mikey-ecc] 493 Milne, A., "ECC Algorithms for MIKEY", 494 draft-ietf-msec-mikey-ecc-01 (work in progress), 495 October 2006. 497 [I-D.ietf-msec-mikey-rsa-r] 498 Ignjatic, D., "An additional mode of key distribution in 499 MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-07 (work 500 in progress), August 2006. 502 [I-D.ietf-msec-mikey-applicability] 503 Fries, S. and D. Ignjatic, "On the applicability of 504 various MIKEY modes and extensions", 505 draft-ietf-msec-mikey-applicability-03 (work in progress), 506 December 2006. 508 [I-D.ietf-msec-mikey-dhhmac] 509 Euchner, M., "HMAC-authenticated Diffie-Hellman for 510 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 511 progress), April 2005. 513 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 514 RFC 4306, December 2005. 516 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 517 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 518 RFC 3711, March 2004. 520 [I-D.wing-rtpsec-keying-eval] 521 Audet, F. and D. Wing, "Evaluation of SRTP Keying with 522 SIP", draft-wing-rtpsec-keying-eval-02 (work in progress), 523 February 2007. 525 [I-D.wing-media-security-requirements] 526 Wing, D., "Media Security Requirements", 527 draft-wing-media-security-requirements-00 (work in 528 progress), October 2006. 530 Author's Address 532 Lakshminath Dondeti 533 QUALCOMM, Inc. 534 5775 Morehouse Dr 535 San Diego, CA 536 USA 538 Phone: +1 858-845-1267 539 Email: ldondeti@qualcomm.com 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2007). 545 This document is subject to the rights, licenses and restrictions 546 contained in BCP 78, and except as set forth therein, the authors 547 retain all their rights. 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Intellectual Property 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Acknowledgment 583 Funding for the RFC Editor function is provided by the IETF 584 Administrative Support Activity (IASA).