idnits 2.17.1 draft-ietf-msec-mikey-ecc-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3830]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 22, 2007) is 6243 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: 'P' is mentioned on line 181, but not defined == Missing Reference: 'IDr' is mentioned on line 338, but not defined == Missing Reference: 'CHASH' is mentioned on line 335, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-IEC-15946-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Milne 3 Internet-Draft 4 Intended status: Standards Track M. Blaser 5 Expires: September 23, 2007 D. Brown 6 E. Chin 7 Certicom Corp. 8 L. Dondeti 9 QUALCOMM, Inc. 10 March 22, 2007 12 ECC Algorithms for MIKEY 13 draft-ietf-msec-mikey-ecc-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 23, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document proposes extensions to the authentication, encryption 47 and digital signature methods described for use in MIKEY, employing 48 elliptic-curve cryptography (ECC). These extensions are defined to 49 align MIKEY with other ECC implementations and standards. 51 It should be noted that this document is not self-contained; it uses 52 the notations and definitions of [RFC3830]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. MIKEY-DHSIGN with ECDSA or ECGDSA . . . . . . . . . . . . . . 5 58 3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 59 4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 62 6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Intellectual Property and Copyright Statements . . . . . . . . . . 18 71 1. Introduction 73 This document describes additional algorithms for use in MIKEY. The 74 document assumes that the reader is familiar with the MIKEY protocol. 76 The MIKEY protocol [RFC3830] defines three methods for transporting 77 or establishing keys: with the use of a pre-shared key, public-key 78 encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY- 79 DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve 80 Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital 81 Signature Algorithm (ECGDSA) as the signature algorithm and further 82 extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH) 83 groups. In addition, this document introduces two new methods based 84 on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and 85 Elliptic Curve Menezes-Qu-Vanstone (ECMQV) in exchanges similar to 86 those of MIKEY-RSA, and name these methods MIKEY-ECIES and MIKEY- 87 ECMQV respectively. 89 Implementations have shown that elliptic curve algorithms can 90 significantly improve performance and security-per-bit over other 91 recommended algorithms. The purpose of this document is to expand 92 the options available to implementers of MIKEY to take advantage of 93 these benefits. 95 In addition, elliptic curve algorithms are capable of providing 96 security consistent with AES keys of 128, 192, and 256 bits without 97 extensive growth in asymmetric key sizes. The following table, taken 98 from [HOF] and [LEN], gives approximate comparable key sizes for 99 symmetric systems, ECC systems, and DH/DSA/RSA systems. The 100 estimates are based on the running times of the best algorithms known 101 today. 103 Symmetric | ECC2N | ECP | DH/DSA/RSA 104 80 | 163 | 192 | 1024 105 128 | 283 | 256 | 3072 106 192 | 409 | 384 | 7680 107 256 | 571 | 521 | 15360 109 Table 1: Comparable key sizes 111 Thus, for example, when securing a 192-bit symmetric key, it is 112 prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ 113 RSA. With smaller key sizes the symmetric keys would be 114 underprotected. 116 Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA or 117 ECGDSA signature algorithm. Section 3 describes the extension of 118 MIKEY-DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES 119 method. Section 5 describes the MIKEY-ECMQV method. Section 6 120 describes additional payloads required to support these new methods. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. MIKEY-DHSIGN with ECDSA or ECGDSA 128 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The 129 Initiator's message includes SIGNi, a signature covering the 130 Initiator's message. As well, the Responder's message includes 131 SIGNr, a signature covering the Responder's message. According to 132 Section 4.2.6 of [RFC3830], the signature algorithm applied is 133 defined by, and dependent on the certificate used. It is MANDATORY 134 to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA 135 PSS. Instead of these signature algorithms, ECDSA or ECGDSA may be 136 used to allow shorter and more efficient signatures. 138 ECDSA signatures are detailed in [ANSI-X9.62] and ECGDSA signatures 139 are detailed in [ISO-IEC-15946-2]. Curve selection and other 140 parameters will be defined by, and dependent on the certificate used. 141 When generating signatures, the hash function that MUST be used 142 depends on the key size, as follows: 144 ECC2N | ECP | Hash To Use 145 163 | 192 | SHA-1 146 233 | 224 | SHA-224 147 283 | 256 | SHA-256 148 409 | 384 | SHA-384 149 571 | 521 | SHA-512 151 Table 2: Hash to use with ECDSA and ECGDSA 153 The signature payload (SIGN) specified in Section 6.5 of [RFC3830] 154 can be used without modification. Two additional S types for ECDSA 155 and ECGDSA is defined as follows: 157 S type | Value | Comments 158 ------------------------------------- 159 ECDSA | 2 | ECDSA signature [ANSI_X9.62] 160 ECGDSA | 3 | ECGDSA signature [ISO/IEC_15946-2] 162 [RFC3279] describes algorithms and identifiers for Internet X.509 163 certificates and CRLs. It includes ECC algorithms and identifiers. 165 To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve 166 Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with 167 the extension described in Section 3. 169 3. MIKEY-DHSIGN with ECDH 171 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to 172 Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and 173 support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these 174 Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) 175 groups may significantly improve performance and security. 177 The ECDH groups to be used by MIKEY are the groups recommended by 178 NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH 179 groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2 180 [SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N 181 prime or over GF[P] with P prime. Eleven of the groups proposed here 182 have been assigned identifiers by IANA [IANA] and the remaining five 183 might later be assigned identifiers by IANA. The group with IANA 184 number 6 is described in [ANSI-X9.62] and [SEC2], with object 185 identifier sect163r1, but it is not one of the fifteen curves that 186 NIST recommends [FIPS-186-2]. The remaining NIST recommended groups 187 are suggested and anticipated to be assigned IANA numbers as 188 specified in Table 3. 190 id Group Type Group Description NIST Name SEC 2 OID 191 -- ---------- ----------------- --------- --------- 193 22 2 ECP ECPRGF192Random P-192 secp192r1 194 23 3 EC2N EC2NGF163Random B-163 sect163r2 195 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 196 6 3 EC2N EC2NGF163Random2 none sect163r1 198 24 2 ECP ECPRGF224Random P-224 secp224r1 199 25 3 EC2N EC2NGF233Random B-233 sect233r1 200 26 3 EC2N EC2NGF233Koblitz K-233 sect233k1 202 19 2 ECP ECPRGF256Random P-256 secp256r1 203 8 3 EC2N EC2NGF283Random B-283 sect283r1 204 9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 206 20 2 ECP ECPRGF384Random P-384 secp384r1 207 10 3 EC2N EC2NGF409Random B-409 sect409r1 208 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 210 21 2 ECP ECPRGF521Random P-521 secp521r1 211 12 3 EC2N EC2NGF571Random B-571 sect571r1 212 13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 214 Table 3: Recommended Groups and Names 216 The ECDH groups in Table 3 are arranged into 5 classes, corresponding 217 to approximately equivalent security strengths. To encourage 218 interoperability, implementations that support one of these classes, 219 SHOULD support the one group in that class that is defined over a 220 prime field (which will be one of P-192, P-224, P-256, P-384, or 221 P-521). Implementations SHOULD support one of P-256 or P-384. 222 Implementations MAY support any set of groups. 224 The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be 225 used without modification. Additional DH-Group identifiers are 226 required as follows: 228 DH-Group | Value 229 --------------------------------------|------- 230 ECPRGF192Random / P-192 / secp192r1 | 3 231 EC2NGF163Random / B-163 / sect163r2 | 4 232 EC2NGF163Koblitz / K-163 / sect163k1 | 5 233 EC2NGF163Random2 / none / sect163r1 | 6 234 | 235 ECPRGF224Random / P-224 / secp224r1 | 7 236 EC2NGF233Random / B-233 / sect233r1 | 8 237 EC2NGF233Koblitz / K-233 / sect233k1 | 9 238 | 239 ECPRGF256Random / P-256 / secp256r1 | 10 240 EC2NGF283Random / B-283 / sect283r1 | 11 241 EC2NGF283Koblitz / K-283 / sect283k1 | 12 242 | 243 ECPRGF384Random / P-384 / secp384r1 | 13 244 EC2NGF409Random / B-409 / sect409r1 | 14 245 EC2NGF409Koblitz / K-409 / sect409k1 | 15 246 | 247 ECPRGF521Random / P-521 / secp521r1 | 16 248 EC2NGF571Random / B-571 / sect571r1 | 17 249 EC2NGF571Koblitz / K-571 / sect571k1 | 18 251 When using the ECDH groups, the DH-value in the DH data payload (DH) 252 is the octet string representation specified in ANSI X9.62 253 [ANSI-X9.62] and [SEC1]. 255 If the initiator chooses secret i and the responder chooses secret r, 256 then the raw shared secret is the x-coordinate(only) of (ir)*G. 258 To use ECDH and ECDSA signature algorithm or to use ECDH and ECGDSA 259 signature algorithm, this extension to MIKEY-DHSIGN may be combined 260 with the extension described in Section 2. 262 4. MIKEY-ECIES 264 The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- 265 key encryption scheme based on ECC. Section 3.2 of [RFC3830] already 266 specifies a public-key encryption method (MIKEY-RSA). Here we 267 describe the new MIKEY-ECIES method. 269 Initiator Responder 271 I_MESSAGE = 272 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 273 ECCPT, KEMAC, [CHASH], SIGNi ---> 275 R_MESSAGE = 276 [<---] HDR, T, [IDr], V 278 As with the MIKEY-RSA case, the main objective of the Initiator's 279 message is to transport one or more TGKs and a set of security 280 parameters to the Responder in a secure manner. 282 With MIKEY-RSA, the TGKs are encrypted with an "envelope key". 283 However, ECIES uses a symmetric encapsulation algorithm, so 284 encrypting an envelope key (to be used with another symmetric method 285 to decrypt the actual payload) would be redundant. As a result, the 286 PKE payload is not used. 288 The ECCPT contains the elliptic curve point that represents the 289 ephemeral public key required for ECIES. 291 As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads 292 and a MAC: 294 KEMAC = E(encr_key, IDi || {TGK}) || MAC 296 The encr_key and auth_key are derived from the ECIES-derived key by 297 using the algorithm described in Section 4.1.4 of [RFC3830], in 298 identical fashion as the envelope key used in the MIKEY-RSA. 300 Both SIGNi and SIGNr will use either ECDSA or ECGDSA as a signature 301 algorithm, as described in Section 2. 303 As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so 304 that it can be used as a pre-shared key. 306 ECIES is described in detail in [SEC1]. For ECIES, the key 307 derivation function that MUST be used is ANSI-X9.63-KDF as described 308 in [SEC1]. As well, the MAC scheme that MUST be used is HMAC-SHA-1- 309 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be 310 used (as opposed to 'cofactor'). The symmetric encryption scheme 311 that MUST be used depends on the key size, as follows: 313 ECC2N | ECP | Symmetric Cipher To Use 314 163 | 192 | 3DES-CBC 315 233 | 224 | AES-128-CBC 316 283 | 256 | AES-128-CBC 317 409 | 384 | AES-256-CBC 318 571 | 521 | AES-256-CBC 320 Table 4: Symmetric cipher to use with ECIES 322 5. MIKEY-ECMQV 324 ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass 325 protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both 326 modes of ECMQV provide mutual authentication between the 327 communicating parties and key establishment for the secure transport 328 of data. Here we describe the new MIKEY-ECMQV method based on the 329 1-pass protocol. 331 Initiator Responder 333 I_MESSAGE = 334 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 335 ECCPT, KEMAC, [CHASH], SIGNi ---> 337 R_MESSAGE = 338 [<---] HDR, T, [IDr], V 340 The ECCPT contains the elliptic curve point that represents the 341 ephemeral public key contributed by the Initiator. 343 As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads 344 and a MAC: 346 KEMAC = E(encr_key, IDi || {TGK}) || MAC 348 The encr_key and auth_key are derived from the ECMQV-derived key by 349 using the algorithm described in Section 4.1.4 of [RFC3830], in 350 identical fashion as the envelope key used in the MIKEY-RSA. 352 1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63]. 354 6. Additional Payload Encoding 356 6.1. ECC Point payload (ECCPT) 358 The ECCPT payload carries a point on the elliptic curve used in 359 MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22. 361 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 ! Next payload ! Point length ! Pt data ... ~ 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 ~ Point data ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 * Next payload (8 bits): identifies the payload that is added after 370 this payload. See Section 6.1 for values. 372 * Point length (16 bits): length of the Point data field (in *bits*). 374 * Point data (variable length): point data, padded to end on a 32-bit 375 boundary, encoded in octet string representation specified in 376 ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be 377 supported. Hybrid and compressed formats MAY be supported. 379 7. Security Considerations 381 Since this document proposes new methods for use within MIKEY, many 382 of the security considerations contained within [RFC3830] apply here 383 as well. Some of the methods proposed in this document offer higher 384 cryptographic strength than those proposed in [RFC3830]. In 385 particular, there are elliptic curves corresponding to each of the 386 symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This 387 allows the MIKEY key exchange to offer security comparable with 388 higher-strength AES algorithms and SHA implementations. The methods 389 proposed in this document are among those standardized by NIST in 390 FIPS 186-2 [FIPS-186-2], by the SECG in SEC2 [SEC2], and by ANSI in 391 ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63]. 393 8. IANA Considerations 395 This document adds entries to existing MIKEY namespaces in Section 2 396 (S types in signature payloads), Section 3 (DH Group identifier in DH 397 payloads), and Section 6.1 (ECCPT payload identifier). 399 9. References 401 9.1. Normative References 403 [ANSI-X9.62] 404 American National Standards Institute, "ANSI X9.62: Public 405 Key Cryptography For The Financial Services Industry: The 406 Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. 408 [ANSI-X9.63] 409 American National Standards Institute, "ANSI X9.63: Public 410 Key Cryptography For The Financial Services Industry: Key 411 Agreement and Key Transport using Elliptic Curve 412 Cryptography", 2001. 414 [FIPS-186-2] 415 National Institute of Standards and Technology, "FIPS 416 186-2 Digital Signature Standard", 2000. 418 [IANA] Internet Assigned Numbers Authority, "Attribute Assigned 419 Numbers.", . 422 [ISO-IEC-15946-2] 423 International Organization for Standardization and 424 International Electrotechnical Commission, "ISO/IEC 425 15946-2: Information technology -- Security techniques -- 426 Cryptographic techniques based on elliptic curves -- Part 427 2: Digital signatures", 2002. 429 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 430 Identifiers for the Internet X.509 Public Key 431 Infrastructure Certificate and Certificate Revocation List 432 (CRL) Profile", RFC 3279, April 2002. 434 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 435 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 436 August 2004. 438 [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic 439 Curve Cryptography", September 2000. 441 [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended 442 Elliptic Curve Domain Parameters", September 2000. 444 9.2. Informative References 446 [HOF] Hoffman, P. and H. Orman, "Determining strengths for 447 public keys used for exchanging symmetric keys", 448 August 2000. 450 [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key 451 sizes", . 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 Authors' Addresses 458 Andrew Milne 460 Mitch Blaser 461 Certicom Corp. 462 5520 Explorer Drive 463 Mississauga, Ontario L4W 5L1 464 CANADA 466 Phone: +1-905-507-4220 467 Fax: +1-905-507-4230 468 Email: mblaser@certicom.com 469 URI: http://www.certicom.com 471 Daniel R. L. Brown 472 Certicom Corp. 473 5520 Explorer Drive 474 Mississauga, Ontario L4W 5L1 475 CANADA 477 Phone: +1-905-507-4220 478 Fax: +1-905-507-4230 479 Email: dbrown@certicom.com 480 URI: http://www.certicom.com 482 Eugene Chin 483 Certicom Corp. 484 5520 Explorer Drive 485 Mississauga, Ontario L4W 5L1 486 CANADA 488 Phone: +1-905-507-4220 489 Fax: +1-905-507-4230 490 Email: echin@certicom.com 491 URI: http://www.certicom.com 492 Lakshminath Dondeti 493 QUALCOMM, Inc. 494 5775 Morehouse Drive 495 San Diego, CA 496 USA 498 Phone: +1-858-845-1267 499 Email: ldondeti@qualcomm.com 501 Full Copyright Statement 503 Copyright (C) The IETF Trust (2007). 505 This document is subject to the rights, licenses and restrictions 506 contained in BCP 78, and except as set forth therein, the authors 507 retain all their rights. 509 This document and the information contained herein are provided on an 510 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 511 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 512 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 513 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 514 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 515 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 517 Intellectual Property 519 The IETF takes no position regarding the validity or scope of any 520 Intellectual Property Rights or other rights that might be claimed to 521 pertain to the implementation or use of the technology described in 522 this document or the extent to which any license under such rights 523 might or might not be available; nor does it represent that it has 524 made any independent effort to identify any such rights. Information 525 on the procedures with respect to rights in RFC documents can be 526 found in BCP 78 and BCP 79. 528 Copies of IPR disclosures made to the IETF Secretariat and any 529 assurances of licenses to be made available, or the result of an 530 attempt made to obtain a general license or permission for the use of 531 such proprietary rights by implementers or users of this 532 specification can be obtained from the IETF on-line IPR repository at 533 http://www.ietf.org/ipr. 535 The IETF invites any interested party to bring to its attention any 536 copyrights, patents or patent applications, or other proprietary 537 rights that may cover technology that may be required to implement 538 this standard. Please address the information to the IETF at 539 ietf-ipr@ietf.org. 541 Acknowledgment 543 Funding for the RFC Editor function is provided by the IETF 544 Administrative Support Activity (IASA).