idnits 2.17.1 draft-ietf-msec-mikey-ecc-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 20, 2006) is 6369 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 167, but not defined == Missing Reference: 'IDr' is mentioned on line 319, but not defined == Missing Reference: 'CHASH' is mentioned on line 316, 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. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 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: April 23, 2007 D. Brown 6 E. Chin 7 Certicom Corp. 8 L. Dondeti 9 QUALCOMM, Inc. 10 October 20, 2006 12 ECC Algorithms for MIKEY 13 draft-ietf-msec-mikey-ecc-01 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 April 23, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 14 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 ECDSA as the 80 signature algorithm and further extends MIKEY-DHSIGN to use Elliptic 81 Curve Diffie-Hellman (ECDH) groups. In addition, this document 82 introduces two new methods based on the elliptic curve algorithms 83 ECIES and ECMQV in exchanges similar to those of MIKEY-RSA, and name 84 these methods MIKEY-ECIES and MIKEY-ECMQV respectively. 86 Implementations have shown that elliptic curve algorithms can 87 significantly improve performance and security-per-bit over other 88 recommended algorithms. The purpose of this document is to expand 89 the options available to implementers of MIKEY to take advantage of 90 these benefits. 92 In addition, elliptic curve algorithms are capable of providing 93 security consistent with AES keys of 128, 192, and 256 bits without 94 extensive growth in asymmetric key sizes. The following table, taken 95 from [HOF] and [LEN], gives approximate comparable key sizes for 96 symmetric systems, ECC systems, and DH/DSA/RSA systems. The 97 estimates are based on the running times of the best algorithms known 98 today. 100 Symmetric | ECC2N | ECP | DH/DSA/RSA 101 80 | 163 | 192 | 1024 102 128 | 283 | 256 | 3072 103 192 | 409 | 384 | 7680 104 256 | 571 | 521 | 15360 106 Table 1: Comparable key sizes 108 Thus, for example, when securing a 192-bit symmetric key, it is 109 prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ 110 RSA. With smaller key sizes the symmetric keys would be 111 underprotected. 113 Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA 114 signature algorithm. Section 3 describes the extension of MIKEY- 115 DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES 116 method. Section 5 describes the MIKEY-ECMQV method. Section 6 117 describes additional payloads required to support these new methods. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. MIKEY-DHSIGN with ECDSA 125 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The 126 Initiator's message includes SIGNi, a signature covering the 127 Initiator's message. As well, the Responder's message includes 128 SIGNr, a signature covering the Responder's message. According to 129 Section 4.2.6 of [RFC3830], the signature algorithm applied is 130 defined by, and dependent on the certificate used. It is MANDATORY 131 to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA 132 PSS. Instead of these signature algorithms, ECDSA can be used to 133 allow shorter and more efficient signatures. 135 ECDSA signatures are detailed in [ANSI-X9.62]. Curve selection and 136 other parameters will be defined by, and dependent on the certificate 137 used. When generating signatures, the hash function that MUST be 138 used is SHA-1. 140 The signature payload (SIGN) specified in Section 6.5 of [RFC3830] 141 can be used without modification. An additional S type for ECDSA is 142 defined as follows: 144 S type | Value | Comments 145 ------------------------------------- 146 ECDSA | 2 | ECDSA signature [ANSI_X9.62] 148 [RFC3279] describes algorithms and identifiers for Internet X.509 149 certificates and CRLs. It includes ECC algorithms and identifiers. 151 To use the ECDSA signature algorithm with Elliptic Curve Diffie- 152 Hellman, this extension to MIKEY-DHSIGN may be combined with the 153 extension described in Section 3. 155 3. MIKEY-DHSIGN with ECDH 157 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to 158 Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and 159 support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these 160 Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) 161 groups can significantly improve performance and security. 163 The ECDH groups to be used by MIKEY are the groups recommended by 164 NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH 165 groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2 166 [SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N 167 prime or over GF[P] with P prime. Eleven of the groups proposed here 168 have been assigned identifiers by IANA [IANA] and the remaining five 169 might later be assigned identifiers by IANA. The group with IANA 170 number 6 is described in [ANSI-X9.62] and [SEC2], with object 171 identifier sect163r1, but it is not one of the fifteen curves that 172 NIST recommends [FIPS-186-2]. The remaining NIST recommended groups 173 are suggested and anticipated to be assigned IANA numbers as 174 specified in Table 2. 176 id Group Type Group Description NIST Name SEC 2 OID 177 -- ---------- ----------------- --------- --------- 179 22 2 ECP ECPRGF192Random P-192 secp192r1 180 23 3 EC2N EC2NGF163Random B-163 sect163r2 181 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 182 6 3 EC2N EC2NGF163Random2 none sect163r1 184 24 2 ECP ECPRGF224Random P-224 secp224r1 185 25 3 EC2N EC2NGF233Random B-233 sect233r1 186 26 3 EC2N EC2NGF233Koblitz K-233 sect233k1 188 19 2 ECP ECPRGF256Random P-256 secp256r1 189 8 3 EC2N EC2NGF283Random B-283 sect283r1 190 9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 192 20 2 ECP ECPRGF384Random P-384 secp384r1 193 10 3 EC2N EC2NGF409Random B-409 sect409r1 194 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 196 21 2 ECP ECPRGF521Random P-521 secp521r1 197 12 3 EC2N EC2NGF571Random B-571 sect571r1 198 13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 200 Table 2: Recommended Groups and Names 202 The ECDH groups in Table 2 are arranged into 5 classes, corresponding 203 to approximately equivalent security strengths. To encourage 204 interoperability, implementations that support one of these classes, 205 SHOULD support the one group in that class that is defined over a 206 prime field (which will be one of P-192, P-224, P-256, P-384, or 207 P-521). Implementations SHOULD support one of P-256 or P-384. 208 Implementations MAY support any set of groups. 210 The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be 211 used without modification. Additional DH-Group identifiers are 212 required as follows: 214 DH-Group | Value 215 --------------------------------------|------- 216 ECPRGF192Random / P-192 / secp192r1 | 3 217 EC2NGF163Random / B-163 / sect163r2 | 4 218 EC2NGF163Koblitz / K-163 / sect163k1 | 5 219 EC2NGF163Random2 / none / sect163r1 | 6 220 | 221 ECPRGF224Random / P-224 / secp224r1 | 7 222 EC2NGF233Random / B-233 / sect233r1 | 8 223 EC2NGF233Koblitz / K-233 / sect233k1 | 9 224 | 225 ECPRGF256Random / P-256 / secp256r1 | 10 226 EC2NGF283Random / B-283 / sect283r1 | 11 227 EC2NGF283Koblitz / K-283 / sect283k1 | 12 228 | 229 ECPRGF384Random / P-384 / secp384r1 | 13 230 EC2NGF409Random / B-409 / sect409r1 | 14 231 EC2NGF409Koblitz / K-409 / sect409k1 | 15 232 | 233 ECPRGF521Random / P-521 / secp521r1 | 16 234 EC2NGF571Random / B-571 / sect571r1 | 17 235 EC2NGF571Koblitz / K-571 / sect571k1 | 18 237 When using the ECDH groups, the DH-value in the DH data payload (DH) 238 is the octet string representation specified in ANSI X9.62 239 [ANSI-X9.62] and [SEC1]. 241 To use ECDH and ECDSA signature algorithm, this extension to MIKEY- 242 DHSIGN may be combined with the extension described in Section 2. 244 4. MIKEY-ECIES 246 The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- 247 key encryption scheme based on ECC. Section 3.2 of [RFC3830] already 248 specifies a public-key encryption method (MIKEY-RSA). Here we 249 describe the new MIKEY-ECIES method. 251 Initiator Responder 253 I_MESSAGE = 254 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 255 ECCPT, KEMAC, [CHASH], SIGNi ---> 257 R_MESSAGE = 258 [<---] HDR, T, [IDr], V 260 As with the MIKEY-RSA case, the main objective of the Initiator's 261 message is to transport one or more TGKs and a set of security 262 parameters to the Responder in a secure manner. 264 With MIKEY-RSA, the TGKs are encrypted with an "envelope key". 265 However, ECIES uses a symmetric encapsulation algorithm, so 266 encrypting an envelope key (to be used with another symmetric method 267 to decrypt the actual payload) would be redundant. As a result, the 268 PKE payload is not used. 270 The ECCPT contains the elliptic curve point that represents the 271 ephemeral public key required for ECIES. 273 As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads 274 and a MAC: 276 KEMAC = E(encr_key, IDi || {TGK}) || MAC 278 The encr_key and auth_key are derived from the ECIES-derived key by 279 using the algorithm described in Section 4.1.4 of [RFC3830], in 280 identical fashion as the envelope key used in the MIKEY-RSA. 282 Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as 283 described in Section 2. 285 As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so 286 that it can be used as a pre-shared key. 288 ECIES is described in detail in [SEC1]. For ECIES, the key 289 derivation function that MUST be used is ANSI-X9.63-KDF as described 290 in [SEC1]. As well, the MAC scheme that MUST be used is HMAC-SHA-1- 291 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be 292 used (as opposed to 'cofactor'). The symmetric encryption scheme 293 that MUST be used depends on the key size, as follows: 295 ECC2N | ECP | Symmetric Cipher To Use 296 163 | 192 | 3DES-CBC 297 283 | 256 | AES-128-CBC 298 409 | 384 | AES-256-CBC 299 571 | 521 | AES-256-CBC 301 Table 3: Symmetric cipher to use with ECIES 303 5. MIKEY-ECMQV 305 ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass 306 protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both 307 modes of ECMQV provide mutual authentication between the 308 communicating parties and key establishment for the secure transport 309 of data. Here we describe the new MIKEY-ECMQV method based on the 310 1-pass protocol. 312 Initiator Responder 314 I_MESSAGE = 315 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 316 ECCPT, KEMAC, [CHASH], SIGNi ---> 318 R_MESSAGE = 319 [<---] HDR, T, [IDr], V 321 The ECCPT contains the elliptic curve point that represents the 322 ephemeral public key contributed by the Initiator. 324 As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads 325 and a MAC: 327 KEMAC = E(encr_key, IDi || {TGK}) || MAC 329 The encr_key and auth_key are derived from the ECMQV-derived key by 330 using the algorithm described in Section 4.1.4 of [RFC3830], in 331 identical fashion as the envelope key used in the MIKEY-RSA. 333 1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63]. 335 6. Additional Payload Encoding 337 6.1. ECC Point payload (ECCPT) 339 The ECCPT payload carries a point on the elliptic curve used in 340 MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22. 342 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ! Next payload ! Point length ! Pt data ... ~ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 ~ Point data ~ 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 * Next payload (8 bits): identifies the payload that is added after 351 this payload. See Section 6.1 for values. 353 * Point length (16 bits): length of the Point data field (in *bits*). 355 * Point data (variable length): point data, padded to end on a 32-bit 356 boundary, encoded in octet string representation specified in 357 ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be 358 supported. Hybrid and compressed formats MAY be supported. 360 7. Security Considerations 362 Since this document proposes new methods for use within MIKEY, many 363 of the security considerations contained within [RFC3830] apply here 364 as well. Some of the methods proposed in this document offer higher 365 cryptographic strength than those proposed in [RFC3830]. In 366 particular, there are elliptic curves corresponding to each of the 367 symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This 368 allows the MIKEY key exchange to offer security comparable with 369 higher-strength AES algorithms and SHA implementations. The methods 370 proposed in this document are among those standardized by NIST in 371 FIPS 186-2 [FIPS-186-2], by the SECG in SEC2 [SEC2], and by ANSI in 372 ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63]. 374 8. IANA Considerations 376 This document adds entries to existing MIKEY namespaces in Section 2 377 (S types in signature payloads), Section 3 (DH Group identifier in DH 378 payloads), and Section 6.1 (ECCPT payload identifier). 380 9. References 382 9.1. Normative References 384 [ANSI-X9.62] 385 American National Standards Institute, "ANSI X9.62: Public 386 Key Cryptography For The Financial Services Industry: The 387 Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. 389 [ANSI-X9.63] 390 American National Standards Institute, "ANSI X9.63: Public 391 Key Cryptography For The Financial Services Industry: Key 392 Agreement and Key Transport using Elliptic Curve 393 Cryptography", 2001. 395 [FIPS-186-2] 396 National Institute of Standards and Technology, "FIPS 397 186-2 Digital Signature Standard", 2000. 399 [IANA] Internet Assigned Numbers Authority, "Attribute Assigned 400 Numbers.", . 403 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 404 Identifiers for the Internet X.509 Public Key 405 Infrastructure Certificate and Certificate Revocation List 406 (CRL) Profile", RFC 3279, April 2002. 408 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 409 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 410 August 2004. 412 [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic 413 Curve Cryptography", September 2000. 415 [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended 416 Elliptic Curve Domain Parameters", September 2000. 418 9.2. Informative References 420 [HOF] Hoffman, P. and H. Orman, "Determining strengths for 421 public keys used for exchanging symmetric keys", 422 August 2000. 424 [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key 425 sizes", . 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 Authors' Addresses 432 Andrew Milne 434 Mitch Blaser 435 Certicom Corp. 436 5520 Explorer Drive 437 Mississauga, Ontario L4W 5L1 438 CANADA 440 Phone: +1-905-507-4220 441 Fax: +1-905-507-4230 442 Email: mblaser@certicom.com 443 URI: http://www.certicom.com 445 Daniel R. L. Brown 446 Certicom Corp. 447 5520 Explorer Drive 448 Mississauga, Ontario L4W 5L1 449 CANADA 451 Phone: +1-905-507-4220 452 Fax: +1-905-507-4230 453 Email: dbrown@certicom.com 454 URI: http://www.certicom.com 456 Eugene Chin 457 Certicom Corp. 458 5520 Explorer Drive 459 Mississauga, Ontario L4W 5L1 460 CANADA 462 Phone: +1-905-507-4220 463 Fax: +1-905-507-4230 464 Email: mblaser@certicom.com 465 URI: http://www.certicom.com 466 Lakshminath Dondeti 467 QUALCOMM, Inc. 468 5775 Morehouse Drive 469 San Diego, CA 470 USA 472 Phone: +1-858-845-1267 473 Email: ldondeti@qualcomm.com 475 Full Copyright Statement 477 Copyright (C) The Internet Society (2006). 479 This document is subject to the rights, licenses and restrictions 480 contained in BCP 78, and except as set forth therein, the authors 481 retain all their rights. 483 This document and the information contained herein are provided on an 484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 486 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 487 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 488 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Intellectual Property 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Acknowledgment 517 Funding for the RFC Editor function is provided by the IETF 518 Administrative Support Activity (IASA).