idnits 2.17.1 draft-hoffman-ike-ipsec-hash-use-06.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 3, 2007) is 6258 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) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKEv1') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4307 (ref. 'IKEv2Algs') (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4305 (ref. 'IPsecAlgs') (Obsoleted by RFC 4835) == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-11 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Expires: September 4, 2007 March 3, 2007 6 Use of Hash Algorithms in IKE and IPsec 7 draft-hoffman-ike-ipsec-hash-use-06.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 4, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document describes how the IKEv1, IKEv2, and IPsec protocols use 41 hash functions, and explains the level of vulnerability of these 42 protocols to the reduced collision resistance of the MD5 and SHA-1 43 hash algorithms. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Hashes in IKEv1 and IKEv2 . . . . . . . . . . . . . . . . . . 3 49 3. Hashes in IPsec . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . . 4 51 5. Choosing Cryptographic Functions . . . . . . . . . . . . . . . 4 52 5.1. Different Cryptographic Functions . . . . . . . . . . . . 5 53 5.2. Specifying Cryptographic Functions in the Protocol . . . . 5 54 5.3. Specifying Cryptographic Functions in Authentication . . . 6 55 6. Suggested Changes . . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Suggested Changes for the Protocols . . . . . . . . . . . 7 57 6.2. Suggested Changes for Implementors . . . . . . . . . . . . 8 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 60 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 61 Appendix B. Changes between versions . . . . . . . . . . . . . . 10 62 B.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 10 63 B.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 10 64 B.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 11 65 B.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 11 66 B.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 11 67 B.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 13 71 1. Introduction 73 Recently, attacks on the collision-resistance properties of MD5 and 74 SHA-1 hash functions have been discovered; [HashAttacks] summarizes 75 the discoveries. The security community is now reexamining how 76 various Internet protocols use hash functions. The goal of this 77 reexamination is to be sure that the current usage is safe in the 78 face of these new attacks, and whether protocols can easily use new 79 hash functions when they become recommended. 81 Different protocols use hash functions quite differently. Because of 82 this, the IETF has asked for reviews of all protocols that use hash 83 functions. This document reviews the many ways that three protocols 84 (IKEv1 [IKEv1], IKEv2 [IKEv2], and IPsec [ESP] and [AH]) use hash 85 functions. 87 In this document, "IKEv1" refers to only "Phase 1" of IKEv1 and the 88 agreement process. "IKEv2" refers to the IKE_SA_INIT and IKE_AUTH 89 exchanges. "IPsec" refers to IP encapsulated in either AH or ESP. 91 The intended status of this document is an Informational RFC that has 92 been reviewed by the IETF. 94 2. Hashes in IKEv1 and IKEv2 96 Both IKEv1 and IKEv2 can use hash functions as pseudo-random 97 functions (PRFs). The inputs to the PRFs always contain nonce values 98 from both the initiator and the responder that the other party cannot 99 predict in advance. In IKEv1, the length of this nonce is at least 100 64 bits, and in IKEv2 it is at least 128 bits. Because of this, the 101 use of hash functions in IKEv1 and IKEv2 are not susceptible to any 102 known collision-reduction attack. 104 IKEv1 also uses hash functions on the inputs to the PRF. The inputs 105 are a combination of values from both the initiator and responder, 106 and thus the hash function here is not susceptible to any known 107 collision-reduction attack. 109 In IKEv2, hashes are used as integrity protection for all messages 110 after the IKE_SA_INIT Exchange. These hashes are used in HMACs. As 111 described in [HMAC-reduction], MD5 used in HMACs is susceptible to 112 forgery, and it is suspected that full SHA-1 used in HMAC is 113 susceptible to forgery. There is no known reason for the person who 114 creates legitimate integrity protection to want to spoof it. 116 Both IKEv1 and IKEv2 have authentication modes that use digital 117 signatures. Digital signatures use hashes to make unique digests of 118 the message being signed. With the current known attacks, the only 119 party that can create the two messages that collide is the IKE entity 120 that generates the message. As shown in [Target-collisions], an 121 attacker can create two different PKIX certificates with different 122 identities that have the same signatures. 124 IKEv1 has two modes, "public key encryption" and "revised public key 125 encryption", that use hashes to identify the public key used. The 126 hash function here is used simply to reduce the size of the 127 identifier. In IKEv2 with public-key certificates, a hash function 128 is used for similar purposes, both for identifying the sender's 129 public key and in identifying the trust anchors. Using a collision- 130 reduction attack, an individual could create two public keys that 131 have the same hash value. This is not considered to be a useful 132 attack because the key generator holds both private keys. 134 IKEv1 can be used together with NAT traversal support, as described 135 in [NAT-T]; IKEv2 includes this NAT traversal support. In both of 136 these cases, hash functions are used to obscure the IP addresses used 137 by the initiator and/or the responder. The hash function here is not 138 susceptible to any known collision-reduction attack. 140 3. Hashes in IPsec 142 AH uses hash functions for authenticating packets; the same is true 143 for ESP when ESP is using its own authentication. For both uses of 144 IPsec, hash functions are always used in hashed MACs (HMACs). As 145 described in [HMAC-reduction], MD5 used in HMACs is susceptible to 146 forgery, and it is suspected that full SHA-1 used in HMAC is 147 susceptible to forgery. There is no known reason for the person who 148 creates legitimate packet authentication to want to spoof it. 150 4. PKIX Certificates in IKEv1 and IKEv2 152 Some implementations of IKEv1 and IKEv2 use PKIX certificates for 153 authentication. Any weaknesses in PKIX certificates due to 154 particular ways hash functions are used, or due to weaknesses in 155 particular hash functions used in certificates, will be inherited in 156 IKEv1 and IKEv2 implementations that use PKIX-based authentication. 158 5. Choosing Cryptographic Functions 160 Recently, there has been more discussion in the IETF about the 161 ability of one party in a protocol to tell the other party which 162 cryptographic functions the first party prefers the second party to 163 use. The discussion was spurred in part by [Deploying]. Although 164 that paper focuses on hash functions, it is relevant to other 165 cryptographic functions as well. 167 There are (at least) three distinct subtopics related to choosing 168 cryptographic functions in protocols: 170 o The ability to pick between different cryptographic functions 171 instead of having just one specified in the protocol 172 o If there are multiple functions, the ability to agree on which 173 function will be used in the main protocol 174 o The ability to suggest to the other party which kinds of 175 cryptographic functions should be used in the other party's public 176 key certificates 178 5.1. Different Cryptographic Functions 180 Protocols that use cryptographic functions can either specify a 181 single function, or can allow different functions. Protocols in the 182 first category are susceptible to attack if the specified function is 183 later found to be too weak for the stated purpose; protocols in the 184 second category can usually avoid such attacks, but at a cost of 185 increased protocol complexity. In the IETF, protocols that allow a 186 choice of cryptographic functions are strongly preferred. 188 IKEv1, IKEv2, and IPsec already allow different hash functions in 189 every significant place where hash functions are used (that is, in 190 every place that has any susceptibility to a collision-reduction 191 attack). 193 5.2. Specifying Cryptographic Functions in the Protocol 195 Protocols that allow a choice of cryptographic functions need to have 196 a way for all parties to agree on which function is going to be used. 197 Some protocols, such as secure electronic mail, allow the initiator 198 to simply pick a set of cryptographic functions; if the responder 199 does not understand the functions used, the transmission fails. 200 Other protocols allow for the two parties to agree on which 201 cryptographic functions will be used. This is sometimes called 202 "negotiation", but the term "negotiation" is inappropriate for 203 protocols in which one party (the "proposer") lists all the functions 204 it is willing to use, and the other party (the "chooser") simply 205 picks the ones that will be used. 207 When a new cryptographic function is introduced, one party may want 208 to tell the other party that they can use the new function. If it is 209 the proposer who wants to use the new function, the situation is 210 easy: the proposer simply adds the new function in its list, possibly 211 removing other parallel functions that the proposer no longer wants 212 to use. 214 On the other hand, if it is the chooser who wants to use the new 215 function and the proposer didn't list it, the chooser may want to 216 signal the proposer that they are capable of using the new function 217 or the chooser may want to say that it is only willing to use the new 218 function. If a protocol wants to handle either of these cases, it 219 has to have a way for the chooser to specify this information to the 220 proposer in its acceptance and/or rejection message. 222 It is not clear from a design standpoint how important it might be to 223 let the chooser specify the additional functions it knows. As long 224 as the proposer offers all the functions it wants to use, there is no 225 reason for the chooser to say "I know one you don't know". The only 226 place where the chooser being able to signal the proposer with 227 different functions is in protocols where listing all the functions 228 might be prohibitive, such as where they would add additional round 229 trips or significant packet length. 231 IKEv1 and IKEv2 allow the proposer to list all functions. Neither 232 allows the chooser to specify which functions that were not proposed 233 it could have used, either in a successful or unsuccessful SA 234 establishment. 236 5.3. Specifying Cryptographic Functions in Authentication 238 Passing public key certificates and signatures used in authentication 239 creates additional issues for protocols. When specifying 240 cryptographic functions for a protocol, it is an agreement between 241 the proposer and the chooser. When choosing cryptographic functions 242 for public key certificates, however, the proposer and the chooser 243 are beholden to functions used by the trusted third parties, the 244 certification authorities (CAs). It doesn't really matter what 245 either party wants the other party to use, since the other party is 246 not the one issuing the certificates. 248 In this discussion, the term "certificate" does not necessarily mean 249 a PKIX certificate. Instead, it means any message that binds an 250 identity to a public key, where the message is signed by a trusted 251 third party. This can be non-PKIX certificates or other types of 252 cryptographic identity-binding structures that may be used in the 253 future 255 The question of specifying cryptographic functions is only relevant 256 if one party has multiple certificates or signatures with different 257 cryptographic functions. In this section, the terms "proposer" and 258 "chooser" have a different meaning than in the previous section. 260 Here, both parties act as proposers of the identity they want to use 261 and the certificates with which they are backing up that identity, 262 and both parties are choosers of the other party's identity and 263 certificate. 265 Some protocols allow the proposer to send multiple certificates or 266 signatures, while other protocols only allow the proposer to send a 267 single certificate or signature. Some protocols allow the proposer 268 to send multiple certificates but advise against it, given that 269 certificates can be fairly large (particularly when the CA loads the 270 certificate with lots of information). 272 IKEv1 and IKEv2 allow both parties to list all the certificates that 273 they want to use. [PKI4IPsec] proposes to restrict this by saying 274 that all the certificates for a proposer have to have the same 275 identity. 277 6. Suggested Changes 279 In investigating how protocols use hash functions, the IETF is 280 looking at (at least) two areas of possible changes to individual 281 protocols: how the IETF might need to change the protocols, and how 282 implementors of current protocols might change what they do. This 283 section describes both of this with respect to IKEv1, IKEv2, and 284 IPsec. 286 6.1. Suggested Changes for the Protocols 288 Protocols might need to be changed if they rely on the collision- 289 resistance of particular hash functions. They might also need to be 290 changed if they do not allow for agreement of hash functions because 291 it is expected that the "preferred" hash function for different users 292 will change over time. 294 IKEv1 and IKEv2 already allow for the agreement of hash functions for 295 both IKE and IPsec, and thus do not need any protocol change. 297 IKEv1 and IKEv2, when used with public key authentication, already 298 allow each party to send multiple PKIX certificates, and thus do not 299 need any protocol change. 301 There are known weaknesses in PKIX with respect to collision- 302 resistance of some hash functions. Because of this, it is hoped that 303 there will be changes to PKIX fostered by the PKIX Working Group. 304 Some of the changes to PKIX may be usable in IKEv1 and IKEv2 without 305 having to change IKEv1 and IKEv2. Other changes to PKIX may require 306 changes to IKEv1 and IKEv2 in order to incorporate them, but that 307 will not be known until the changes to PKIX are finalized. 309 6.2. Suggested Changes for Implementors 311 As described in earlier sections, IKE and IPsec themselves are not 312 susceptible to any known collision-reduction attacks on hash 313 functions. Thus, implementors do not need to make changes such as 314 prohibiting the use of MD5 or SHA-1. The mandatory and suggested 315 algorithms for IKEv2 and IPsec are given in [IKEv2Algs] and 316 [IPsecAlgs]. 318 Note that some IKE and IPsec users will misunderstand the relevance 319 of the known attacks and want to use "stronger" hash functions. 320 Thus, implementors should strongly consider adding support for 321 alternatives, particularly the AES-XCBC-PRF-128 [AES-PRF] and AES- 322 XCBC-MAC-96 [AES-MAC] algorithms, as well as forthcoming algorithms 323 based on the SHA-2 family [SHA2-HMAC]. 325 Implementations of IKEv1 and IKEv2 that use PKIX certificates for 326 authentication may be susceptible to attacks based on weaknesses in 327 PKIX. It is widely expected that PKIX certificates in the future 328 will use hash functions other than MD5 and SHA-1. Implementers of 329 IKE that allow certificate authentication should strongly consider 330 allowing the use of certificates that are signed with the SHA-256, 331 SHA-384, and SHA-512 hash algorithms. Similarly, those implementers 332 should also strongly consider allowing the sending of multiple 333 certificates for identification. 335 7. Security Considerations 337 This entire document is about security implications of reduced 338 collision-resistance of common hash algorithms for the IKE and IPsec 339 protocols. 341 The Security Considerations section of [HashAttacks] gives much more 342 detail about the security of hash functions. 344 8. Informative References 346 [AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 347 and Its Use With IPsec", RFC 3566, September 2003. 349 [AES-PRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 350 Internet Key Exchange Protocol (IKE)", RFC 4434, 351 February 2006. 353 [AH] Kent, S., "IP Authentication Header", RFC 4302, 354 December 2005. 356 [Deploying] 357 Bellovin, S. and E. Rescorla, "Deploying a New Hash 358 Algorithm", NDSS '06, February 2006. 360 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 361 RFC 4303, December 2005. 363 [HashAttacks] 364 Hoffman, P. and B. Schneier, "Attacks on Cryptographic 365 Hashes in Internet Protocols", RFC 4270, November 2005. 367 [HMAC-reduction] 368 Contini, S. and YL. Yin, "Forgery and Partial Key-Recovery 369 Attacks on HMAC and NMAC Using Hash Collisions", 370 Cryptology ePrint Report 2006/319, September 2006. 372 [IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange 373 (IKE)", RFC 2409, November 1998. 375 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 376 Protocol", RFC 4306, December 2005. 378 [IKEv2Algs] 379 Schiller, J., "Cryptographic Algorithms for use in the 380 Internet Key Exchange Version 2", RFC 4307, December 2005. 382 [IPsecAlgs] 383 Eastlake, D., "Cryptographic Algorithm Implementation 384 Requirements For ESP And AH", RFC 4305, December 2005. 386 [NAT-T] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 387 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 388 January 2005. 390 [PKI4IPsec] 391 Korver, B., "The Internet IP Security PKI Profile of 392 IKEv1/ISAKMP, IKEv2, and PKIX", 393 draft-ietf-pki4ipsec-ikecert-profile-11 (work in 394 progress), September 2006. 396 [SHA2-HMAC] 397 Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 398 384, and HMAC-SHA-512 With IPsec", 399 draft-kelly-ipsec-ciph-sha2-01 (work in progress), 400 January 2007. 402 [Target-collisions] 403 Stevens, M., Lenstra, A., and B. de Weger, "Target 404 Collisions for MD5 and Colliding X.509 Certificates for 405 Different Identities", Cryptology ePrint Report 2006/360, 406 October 2006. 408 Appendix A. Acknowledgments 410 Tero Kivinen helped with ideas in the first draft of this document. 411 Many participants on the SAAG and IPsec mailing lists contributed 412 ideas in later drafts. In particular, suggestions were made by 413 Alfred Hoenes, Michael Richardson, Hugo Krawczyk, Steve Bellovin, 414 David McGrew, Russ Housley, Arjen Lenstra, and Pasi Eronen. 416 Appendix B. Changes between versions 418 (This section is to be removed by the RFC Editor.) 420 B.1. Changes between -00 and -01 422 Added that IKEv2 uses hash functions for its own integrity 423 protection, based on a suggestion by Michael Richardson. 425 Added description of use of digital signatures in IKEv1 and IKEv2, 426 based on a suggestion from Hugo Krawczyk. 428 Removed the description of specific PKIX attacks and remedies, and 429 replaced it with pointers to the future PKIX work. Added a section 430 in the suggested changes to the protocols pointing out that some 431 changes that come from the PKIX world will require no changes to IKE, 432 but others might. 434 Added the long section on "Choosing Cryptographic Functions" based on 435 a suggestion from Steve Bellovin. 437 Added references for AES-XCBC-PRF-128 and AES-XCBC-MAC-96, based on a 438 suggestion from David McGrew. 440 Strengthened the PKIX discussion that is now in an appendix, but will 441 later be removed when the PKIX document is started. 443 B.2. Changes between -01 and -02 445 A bunch of editorial fixes from Alfred Hoenes. 447 Updated the references to the new RFCs. 449 B.3. Changes between -02 and -03 451 None; just a freshening. 453 B.4. Changes between -03 and -04 455 None; just a freshening. 457 B.5. Changes between -04 and -05 459 In 6.1, changed "Because of this, it is expected that there will be 460 changes to PKIX fostered by the PKIX Working Group" to "Because of 461 this, it is hoped that ...". 463 Removed Appendix B, which was to be removed before publishing. 465 Beefed up the Acknowledgments in preparation for this change log 466 being removed. 468 B.6. Changes between -05 and -06 470 Small editorial issues from Russ Housley. 472 In 2, added: "With the current known attacks, the only party that can 473 create the two messages that collide is the IKE entity that generates 474 the message." 476 In the first paragraph of 2, clarified that the reason that this is 477 not susceptible to collision-reduction attacks is that the unknown 478 values are large. 480 Significantly changed the third paragraph of 2. Also added the new 481 reference. 483 Significantly changed the fourth paragraph of 2. Also added the new 484 reference. 486 In 5, changed "multiple" to "different" in a few places to make it 487 clear that IKE allows the use of different hash functions, not 488 multiple functions at one time. 490 In 5.1, changed "every place" to "every significant place ... (that 491 is, in every place that has any susceptibility to a collision- 492 reduction attack)". 494 In 6.2, added mention of the SHA-2 PRFs, and signature functions 495 based on SHA-2, to the list of suggested functions to be allowed. 497 Author's Address 499 Paul Hoffman 500 VPN Consortium 501 127 Segre Place 502 Santa Cruz, CA 95060 503 US 505 Email: paul.hoffman@vpnc.org 507 Full Copyright Statement 509 Copyright (C) The IETF Trust (2007). 511 This document is subject to the rights, licenses and restrictions 512 contained in BCP 78, and except as set forth therein, the authors 513 retain all their rights. 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Intellectual Property 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Acknowledgment 549 Funding for the RFC Editor function is provided by the IETF 550 Administrative Support Activity (IASA).