idnits 2.17.1 draft-ietf-dnsext-trustupdate-timers-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. ** 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 '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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 333 has weird spacing: '...herwise a 'Ke...' == Line 370 has weird spacing: '... Key bits....' == Line 396 has weird spacing: '...will be the...' -- 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 (August 15, 2005) is 6819 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 normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. StJohns 3 Internet-Draft Nominum, Inc. 4 Expires: February 16, 2006 August 15, 2005 6 Automated Updates of DNSSEC Trust Anchors 7 draft-ietf-dnsext-trustupdate-timers-01 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 February 16, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes a means for automated, authenticated and 41 authorized updating of DNSSEC "trust anchors". The method provides 42 protection against single key compromise of a key in the trust point 43 key set. Based on the trust established by the presence of a current 44 anchor, other anchors may be added at the same place in the 45 hierarchy, and, ultimately, supplant the existing anchor. 47 This mechanism, if adopted, will require changes to resolver 48 management behavior (but not resolver resolution behavior), and the 49 addition of a single flag bit to the DNSKEY record. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 55 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 56 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 60 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 61 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 62 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 63 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 64 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 65 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 66 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 71 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 72 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 73 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 74 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 77 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 78 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 79 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 80 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 82 Intellectual Property and Copyright Statements . . . . . . . . 12 84 1. Introduction 86 As part of the reality of fielding DNSSEC (Domain Name System 87 Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the 88 community has come to the realization that there will not be one 89 signed name space, but rather islands of signed name space each 90 originating from specific points (i.e. 'trust points') in the DNS 91 tree. Each of those islands will be identified by the trust point 92 name, and validated by at least one associated public key. For the 93 purpose of this document we'll call the association of that name and 94 a particular key a 'trust anchor'. A particular trust point can have 95 more than one key designated as a trust anchor. 97 For a DNSSEC-aware resolver to validate information in a DNSSEC 98 protected branch of the hierarchy, it must have knowledge of a trust 99 anchor applicable to that branch. It may also have more than one 100 trust anchor for any given trust point. Under current rules, a chain 101 of trust for DNSSEC-protected data that chains its way back to ANY 102 known trust anchor is considered 'secure'. 104 Because of the probable balkanization of the DNSSEC tree due to 105 signing voids at key locations, a resolver may need to know literally 106 thousands of trust anchors to perform its duties. (e.g. Consider an 107 unsigned ".COM".) Requiring the owner of the resolver to manually 108 manage this many relationships is problematic. It's even more 109 problematic when considering the eventual requirement for key 110 replacement/update for a given trust anchor. The mechanism described 111 herein won't help with the initial configuration of the trust anchors 112 in the resolvers, but should make trust point key replacement/ 113 rollover more viable. 115 As mentioned above, this document describes a mechanism whereby a 116 resolver can update the trust anchors for a given trust point, mainly 117 without human intervention at the resolver. There are some corner 118 cases discussed (e.g. multiple key compromise) that may require 119 manual intervention, but they should be few and far between. This 120 document DOES NOT discuss the general problem of the initial 121 configuration of trust anchors for the resolver. 123 1.1 Compliance Nomenclature 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in BCP 14, [RFC2119]. 129 1.2 Changes since -00 131 Added the concept of timer triggered resolver queries to refresh the 132 resolvers view of the trust anchor key RRSet. 134 Re-submitted expired draft as -01. Updated DNSSEC RFC References. 136 2. Theory of Operation 138 The general concept of this mechanism is that existing trust anchors 139 can be used to authenticate new trust anchors at the same point in 140 the DNS hierarchy. When a new SEP key is added to a trust point 141 DNSKEY RRSet, and when that RRSet is validated by an existing trust 142 anchor, then the new key can be added to the set of trust anchors. 144 There are some issues with this approach which need to be mitigated. 145 For example, a compromise of one of the existing keys could allow an 146 attacker to add their own 'valid' data. This implies a need for a 147 method to revoke an existing key regardless of whether or not that 148 key is compromised. As another example assuming a single key 149 compromise, an attacker could add a new key and revoke all the other 150 old keys. 152 2.1 Revocation 154 Assume two trust anchor keys A and B. Assume that B has been 155 compromised. Without a specific revocation bit, B could invalidate A 156 simply by sending out a signed trust point key set which didn't 157 contain A. To fix this, we add a mechanism which requires knowledge 158 of the private key of a DNSKEY to revoke that DNSKEY. 160 A key is considered revoked when the resolver sees the key in a self- 161 signed RRSet and the key has the REVOKE bit set to '1'. Once the 162 resolver sees the REVOKE bit, it MUST NOT use this key as a trust 163 anchor or for any other purposes except validating the RRSIG over the 164 DNSKEY RRSet specifically for the purpose of validating the 165 revocation. Unlike the 'Add' operation below, revocation is 166 immediate and permanent upon receipt of a valid revocation at the 167 resolver. 169 N.B. A DNSKEY with the REVOKE bit set has a different fingerprint 170 than one without the bit set. This affects the matching of a DNSKEY 171 to DS records in the parent, or the fingerprint stored at a resolver 172 used to configure a trust point. [msj3] 174 In the given example, the attacker could revoke B because it has 175 knowledge of B's private key, but could not revoke A. 177 2.2 Add Hold-Down 179 Assume two trust point keys A and B. Assume that B has been 180 compromised. An attacker could generate and add a new trust anchor 181 key - C (by adding C to the DNSKEY RRSet and signing it with B), and 182 then invalidate the compromised key. This would result in the both 183 the attacker and owner being able to sign data in the zone and have 184 it accepted as valid by resolvers. 186 To mitigate, but not completely solve, this problem, we add a hold- 187 down time to the addition of the trust anchor. When the resolver 188 sees a new SEP key in a validated trust point DNSKEY RRSet, the 189 resolver starts an acceptance timer, and remembers all the keys that 190 validated the RRSet. If the resolver ever sees the DNSKEY RRSet 191 without the new key but validly signed, it stops the acceptance 192 process and resets the acceptance timer. If all of the keys which 193 were originally used to validate this key are revoked prior to the 194 timer expiring, the resolver stops the acceptance process and resets 195 the timer. 197 Once the timer expires, the new key will be added as a trust anchor 198 the next time the validated RRSet with the new key is seen at the 199 resolver. The resolver MUST NOT treat the new key as a trust anchor 200 until the hold down time expires AND it has retrieved and validated a 201 DNSKEY RRSet after the hold down time which contains the new key. 203 N.B.: Once the resolver has accepted a key as a trust anchor, the key 204 MUST be considered a valid trust anchor by that resolver until 205 explictly revoked as described above. 207 In the given example, the zone owner can recover from a compromise by 208 revoking B and adding a new key D and signing the DNSKEY RRSet with 209 both A and B. 211 The reason this does not completely solve the problem has to do with 212 the distributed nature of DNS. The resolver only knows what it sees. 213 A determined attacker who holds one compromised key could keep a 214 single resolver from realizing that key had been compromised by 215 intercepting 'real' data from the originating zone and substituting 216 their own (e.g. using the example, signed only by B). This is no 217 worse than the current situation assuming a compromised key. 219 2.3 Remove Hold-down 221 A new key which has been seen by the resolver, but hasn't reached 222 it's add hold-down time, MAY be removed from the DNSKEY RRSet by the 223 zone owner. If the resolver sees a validated DNSKEY RRSet without 224 this key, it waits for the remove hold-down time and then, if the key 225 hasn't reappeared, SHOULD discard any information about the key. 227 2.4 Active Refresh 229 A resolver which has been configured for automatic update of keys 230 from a particular trust point MUST query that trust point (e.g. do a 231 lookup for the DNSKEY RRSet and related RRSIG records) no less often 232 than the lesser of 15 days or half the original TTL for the DNSKEY 233 RRSet or half the RRSIG expiration interval. The expiration interval 234 is the amount of time from when the RRSIG was last retrieved until 235 the expiration time in the RRSIG. 237 If the query fails, the resolver MUST repeat the query until 238 satisfied no more often than once an hour and no less often than the 239 lesser of 1 day or 10% of the original TTL or 10% of the original 240 expiration interval. 242 2.5 Resolver Parameters 244 2.5.1 Add Hold-Down Time 246 The add hold-down time is 30 days or the expiration time of the TTL 247 of the first trust point DNSKEY RRSet which contained the key, 248 whichever is greater. This ensures that at least two validated 249 DNSKEY RRSets which contain the new key MUST be seen by the resolver 250 prior to the key's acceptance. 252 2.5.2 Remove Hold-Down Time 254 The remove hold-down time is 30 days. 256 2.5.3 Minimum Trust Anchors per Trust Point 258 A compliant resolver MUST be able to manage at least five SEP keys 259 per trust point. 261 3. Changes to DNSKEY RDATA Wire Format 263 Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' 264 flag. If this bit is set to '1', AND the resolver sees an 265 RRSIG(DNSKEY) signed by the associated key, then the resolver MUST 266 consider this key permanently invalid for all purposes except for 267 validing the revocation. 269 4. State Table 271 The most important thing to understand is the resolver's view of any 272 key at a trust point. The following state table describes that view 273 at various points in the key's lifetime. The table is a normative 274 part of this specification. The initial state of the key is 'Start'. 276 The resolver's view of the state of the key changes as various events 277 occur. 279 [msj1] This is the state of a trust point key as seen from the 280 resolver. The column on the left indicates the current state. The 281 header at the top shows the next state. The intersection of the two 282 shows the event that will cause the state to transition from the 283 current state to the next. 285 NEXT STATE 286 -------------------------------------------------- 287 FROM |Start |AddPend |Valid |Missing|Revoked|Removed| 288 ---------------------------------------------------------- 289 Start | |NewKey | | | | | 290 ---------------------------------------------------------- 291 AddPend |KeyRem | |AddTime| | | 292 ---------------------------------------------------------- 293 Valid | | | |KeyRem |Revbit | | 294 ---------------------------------------------------------- 295 Missing | | |KeyPres| |Revbit | | 296 ---------------------------------------------------------- 297 Revoked | | | | | |RemTime| 298 ---------------------------------------------------------- 299 Removed | | | | | | | 300 ---------------------------------------------------------- 302 4.1 Events 303 NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. 304 That key will become a new trust anchor for the named trust point 305 after its been present in the RRSet for at least 'add time'. 306 KeyPres The key has returned to the valid DNSKEY RRSet. 307 KeyRem The resolver sees a valid DNSKEY RRSet that does not contain 308 this key. 309 AddTime The key has been in every valid DNSKEY RRSet seen for at 310 least the 'add time'. 311 RemTime A revoked key has been missing from the trust point DNSKEY 312 RRSet for sufficient time to be removed from the trust set. 313 RevBit The key has appeared in the trust anchor DNSKEY RRSet with its 314 "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet 315 signed by this key. 317 4.2 States 318 Start The key doesn't yet exist as a trust anchor at the resolver. 319 It may or may not exist at the zone server, but hasn't yet been 320 seen at the resolver. 322 AddPend The key has been seen at the resolver, has its 'SEP' bit set, 323 and has been included in a validated DNSKEY RRSet. There is a 324 hold-down time for the key before it can be used as a trust 325 anchor. 326 Valid The key has been seen at the resolver and has been included in 327 all validated DNSKEY RRSets from the time it was first seen up 328 through the hold-down time. It is now valid for verifying RRSets 329 that arrive after the hold down time. Clarification: The DNSKEY 330 RRSet does not need to be continuously present at the resolver 331 (e.g. its TTL might expire). If the RRSet is seen, and is 332 validated (i.e. verifies against an existing trust anchor), this 333 key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. 334 Missing This is an abnormal state. The key remains as a valid trust 335 point key, but was not seen at the resolver in the last validated 336 DNSKEY RRSet. This is an abnormal state because the zone operator 337 should be using the REVOKE bit prior to removal. [Discussion 338 item: Should a missing key be considered revoked after some 339 period of time?] 340 Revoked This is the state a key moves to once the resolver sees an 341 RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains 342 this key with its REVOKE bit set to '1'. Once in this state, this 343 key MUST permanently be considered invalid as a trust anchor. 344 Removed After a fairly long hold-down time, information about this 345 key may be purged from the resolver. A key in the removed state 346 MUST NOT be considered a valid trust anchor. 348 5. Scenarios 350 The suggested model for operation is to have one active key and one 351 stand-by key at each trust point. The active key will be used to 352 sign the DNSKEY RRSet. The stand-by key will not normally sign this 353 RRSet, but the resolver will accept it as a trust anchor if/when it 354 sees the signature on the trust point DNSKEY RRSet. 356 Since the stand-by key is not in active signing use, the associated 357 private key may (and SHOULD) be provided with additional protections 358 not normally available to a key that must be used frequently. E.g. 359 locked in a safe, split among many parties, etc. Notionally, the 360 stand-by key should be less subject to compromise than an active key, 361 but that will be dependent on operational concerns not addressed 362 here. 364 5.1 Adding A Trust Anchor 366 Assume an existing trust anchor key 'A'. 367 1. Generate a new key pair. 369 2. Create a DNSKEY record from the key pair and set the SEP and Zone 370 Key bits. 371 3. Add the DNSKEY to the RRSet. 372 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 373 'A'. 374 5. Wait a while. 376 5.2 Deleting a Trust Anchor 378 Assume existing trust anchors 'A' and 'B' and that you want to revoke 379 and delete 'A'. 380 1. Set the revolcation bit on key 'A'. 381 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 382 'A' is now revoked. The operator SHOULD include the revoked 'A' in 383 the RRSet for at least the remove hold-down time, but then may remove 384 it from the DNSKEY RRSet. 386 5.3 Key Roll-Over 388 Assume existing keys A and B. 'A' is actively in use (i.e. has been 389 signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been 390 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being 391 used to sign the RRSet.) 392 1. Generate a new key pair 'C'. 393 2. Add 'C' to the DNSKEY RRSet. 394 3. Set the revocation bit on key 'A'. 395 4. Sign the RRSet with 'A' and 'B'. 396 'A' is now revoked, 'B' is now the active key, and 'C' will be the 397 stand-by key once the hold-down expires. The operator SHOULD include 398 the revoked 'A' in the RRSet for at least the remove hold-down time, 399 but may then remove it from the DNSKEY RRSet. 401 5.4 Active Key Compromised 403 This is the same as the mechanism for Key Roll-Over (Section 5.3) 404 above assuming 'A' is the active key. 406 5.5 Stand-by Key Compromised 408 Using the same assumptions and naming conventions as Key Roll-Over 409 (Section 5.3) above: 410 1. Generate a new key pair 'C'. 411 2. Add 'C' to the DNSKEY RRSet. 412 3. Set the revocation bit on key 'B'. 413 4. Sign the RRSet with 'A' and 'B'. 414 'B' is now revoked, 'A' remains the active key, and 'C' will be the 415 stand-by key once the hold-down expires. 'B' SHOULD continue to be 416 included in the RRSet for the remove hold-down time. 418 6. Security Considerations 420 6.1 Key Ownership vs Acceptance Policy 422 The reader should note that, while the zone owner is responsible 423 creating and distributing keys, it's wholly the decision of the 424 resolver owner as to whether to accept such keys for the 425 authentication of the zone information. This implies the decision 426 update trust anchor keys based on trust for a current trust anchor 427 key is also the resolver owner's decision. 429 The resolver owner (and resolver implementers) MAY choose to permit 430 or prevent key status updates based on this mechanism for specific 431 trust points. If they choose to prevent the automated updates, they 432 will need to establish a mechanism for manual or other out-of-band 433 updates outside the scope of this document. 435 6.2 Multiple Key Compromise 437 This scheme permits recovery as long as at least one valid trust 438 anchor key remains uncompromised. E.g. if there are three keys, you 439 can recover if two of them are compromised. The zone owner should 440 determine their own level of comfort with respect to the number of 441 active valid trust anchors in a zone and should be prepared to 442 implement recovery procedures once they detect a compromise. A 443 manual or other out-of-band update of all resolvers will be required 444 if all trust anchor keys at a trust point are compromised. 446 6.3 Dynamic Updates 448 Allowing a resolver to update its trust anchor set based in-band key 449 information is potentially less secure than a manual process. 450 However, given the nature of the DNS, the number of resolvers that 451 would require update if a trust anchor key were compromised, and the 452 lack of a standard management framework for DNS, this approach is no 453 worse than the existing situation. 455 7. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 461 RFC 2535, March 1999. 463 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 464 Rose, "DNS Security Introduction and Requirements", 465 RFC 4033, March 2005. 467 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 468 Rose, "Resource Records for the DNS Security Extensions", 469 RFC 4034, March 2005. 471 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 472 Rose, "Protocol Modifications for the DNS Security 473 Extensions", RFC 4035, March 2005. 475 Editorial Comments 477 [msj1] msj: N.B. This table is preliminary and will be revised to 478 match implementation experience. For example, should there 479 be a state for "Add hold-down expired, but haven't seen the 480 new RRSet"? 482 [msj2] msj: To be assigned. 484 [msj3] msj: For discussion: What's the implementation guidance for 485 resolvers currently with respect to the non-assigned flag 486 bits? If they consider the flag bit when doing key matching 487 at the trust anchor, they won't be able to match. 489 Author's Address 491 Michael StJohns 492 Nominum, Inc. 493 2385 Bay Road 494 Redwood City, CA 94063 495 USA 497 Phone: +1-301-528-4729 498 Email: Mike.StJohns@nominum.com 499 URI: www.nominum.com 501 Intellectual Property Statement 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 The IETF has been notified of intellectual property rights claimed in 526 regard to some or all of the specification contained in this 527 document. For more information consult the online list of claimed 528 rights. 530 Disclaimer of Validity 532 This document and the information contained herein are provided on an 533 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 534 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 535 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 536 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 537 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 538 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 540 Copyright Statement 542 Copyright (C) The Internet Society (2005). This document is subject 543 to the rights, licenses and restrictions contained in BCP 78, and 544 except as set forth therein, the authors retain all their rights. 546 Acknowledgment 548 Funding for the RFC Editor function is currently provided by the 549 Internet Society.