idnits 2.17.1 draft-ietf-dnsext-dnssec-intro-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 abstract seems to contain references ([1]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 24, 2002) is 7855 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 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dns-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-dns-threats (ref. '5') ** Obsolete normative reference: RFC 2671 (ref. '6') (Obsoleted by RFC 6891) == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-00 == Outdated reference: A later version (-04) exists of draft-ietf-dnsext-restrict-key-for-dnssec-02 ** Obsolete normative reference: RFC 2845 (ref. '11') (Obsoleted by RFC 8945) == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 2538 (ref. '15') (Obsoleted by RFC 4398) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dnssec-roadmap-05 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft 4 Expires: April 24, 2003 M. Larson 5 VeriSign 6 D. Massey 7 USC/ISI 8 S. Rose 9 NIST 10 October 24, 2002 12 DNS Security Introduction and Requirements 13 draft-ietf-dnsext-dnssec-intro-03 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 24, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 The Domain Name System Security Extensions (DNSSEC) provide data 45 origin authentication and data integrity. This document introduces 46 these extensions and describes their capabilities and limitations. 47 The services that the security extensions provide and do not provide 48 are discussed. Lastly, the group of documents that describe the DNS 49 security extensions and their interrelationships is discussed. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [1]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 4 59 3. Services Provided by DNS Security . . . . . . . . . . . . . 5 60 3.1 Data Origin Authentication and Data Integrity . . . . . . . 5 61 3.1.1 Authenticating Name and Type Non-Existence . . . . . . . . . 6 62 3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3 Transaction Security . . . . . . . . . . . . . . . . . . . . 7 64 4. Services Not Provided by DNS Security . . . . . . . . . . . 8 65 5. Resolver Considerations . . . . . . . . . . . . . . . . . . 9 66 6. Zone Considerations . . . . . . . . . . . . . . . . . . . . 10 67 7. Server Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. DNS Security Document Family . . . . . . . . . . . . . . . . 12 69 8.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . 12 70 8.2 Categories of DNS Security Documents . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 72 10. Security Considerations . . . . . . . . . . . . . . . . . . 15 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 74 Normative References . . . . . . . . . . . . . . . . . . . . 17 75 Informative References . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 77 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 This document introduces the Domain Name System Security Extensions 82 (DNSSEC). This document and a collection of related documents update 83 RFC 2535 [2] and its related documents to further clarify and refine 84 the security extensions defined in RFC 2535. These security 85 extensions consist of a set of new resource record types and 86 modifications to the existing DNS protocol [3]. The new records and 87 protocol modifications are not fully described in this document, but 88 in a family of documents outlined in Section 8. The capabilities and 89 limitations of the security extensions are described in greater 90 detail in Section 3 and Section 4, respectively. Lastly, the effect 91 that these security extensions will have on resolvers, zones and 92 servers is discussed in Section 5, Section 6 and Section 7, 93 respectively. 95 The DNS security extensions provide data origin authentication and 96 data integrity protection as well as a means of public key 97 distribution. The security extensions do not provide protection 98 against other types of attack, nor do they provide confidentiality. 100 2. Definitions of Important DNSSEC Terms 102 authentication key: A public key, for a zone or a host, that a 103 resolver trusts and that can therefore be used to verify data. A 104 key can become trusted in two ways: First, it can be statically 105 configured and declared in the resolver's initial configuration. 106 Second, if a new key is referenced by a DS record that is signed 107 by an already known authentication key, and the signature 108 verifies, the new key becomes trusted by the resolver. 110 authentication path: In DNSSEC, a key signs a DS record, which points 111 to another key, which in turn signs another DS record, which 112 points to yet another key, etc. This alternating succession of 113 KEY and DS records forms a chain of signed data, with each link in 114 the chain vouching for the next. A resolver starting at a piece 115 of data in the chain signed by a known authentication key can 116 verify all subsequent signatures. Thus all subsequent data in the 117 chain is verified and authenticated. 119 security-aware resolver: A resolver (defined in section 2.4 of [4]) 120 that understands the DNS security extensions. In particular, a 121 security-aware resolver uses known authentication keys to verify 122 signatures over RRsets and (optionally) DNS messages. 124 security-aware server: A name server (also defined in section 2.4 of 125 [4]) that understands the DNS security extensions. In particular, 126 it supports the KEY, SIG, DS and NXT record types, a larger DNS 127 message size via EDNS0, and other protocol changes such as support 128 for the OK bit. Also called a "secure server". 130 unsecure server: The proper term for the opposite of a security-aware 131 server. 133 unsigned zone: The proper term for the opposite of a secure zone. 135 signed zone: A zone whose RRsets are signed and which contains 136 properly constructed KEY, SIG, NXT and (optionally) DS records. 138 3. Services Provided by DNS Security 140 The Domain Name System (DNS) protocol security extensions provide 141 three distinct services: Data origin authentication and data 142 integrity, key distribution, and transaction security, as described 143 below. 145 These services protect against the threats to the Domain Name System 146 described in [5]. 148 3.1 Data Origin Authentication and Data Integrity 150 Authentication is provided by cryptographically generated digital 151 signatures associated with DNS RRsets. These digital signatures are 152 stored in a new resource record, the SIG record. Typically, there 153 will be a single private key that signs a zone's data, but multiple 154 keys are possible; e.g., for different digital signature algorithms. 155 If a security-aware resolver reliably learns a zone's public key, it 156 can authenticate that zone's signed data. An important DNSSEC 157 concept is that the key that signs a zone's data is associated with 158 the zone itself and not with the zone's authoritative servers 159 (although hosts can also have key pairs in DNSSEC; see the reference 160 to SIG(0) in Section 3.3 below). Security-aware servers attempt to 161 send the signature(s) needed to authenticate an RRset in the DNS 162 reply message along with the RRset itself, provided there is space 163 available in the message. 165 A resolver could learn a zone's public key by having the key 166 statically configured or by normal DNS resolution. To allow the 167 latter, public keys are stored in a new resource record, the KEY 168 record (see Section 3.2 below). (Note that the private keys used to 169 sign zone data must be kept secure and best practices call for them 170 to be stored offline.) To reliably discover a public key by DNS 171 resolution, the key itself needs to be signed by either a statically 172 configured authentication key or another key that has been previously 173 authenticated. Zone information is authenticated by forming a chain 174 from a newly learned public key back to a previously known 175 authentication public key (which is either statically configured or 176 previously learned and verified). Therefore, the resolver must be 177 configured with at least one public key that authenticates one zone 178 as a starting point. To establish this authentication chain, 179 security-aware servers attempt to send the signature(s) needed to 180 authenticate a zone's public key in the DNS reply message along with 181 the public key itself, provided there is space available in the 182 message. 184 The authentication chain specified in the original DNS security 185 extensions proceeded from signed KEY record to signed KEY record, as 186 necessary, and finally to the queried RRset. A new record, the 187 delegation signer (DS), has been added for additional flexibility. 188 The DS RRset resides at a delegation point in a parent zone and 189 specifies the keys used by the specified child zone to self-sign the 190 KEY RRset at its apex. The child, in turn, uses one of these keys to 191 sign its zone data. The authentication chain is therefore DS->KEY- 192 >[DS->KEY->...]->RRset. 194 Adding data origin authentication and data integrity requires minor 195 changes to the on-the-wire DNS protocol. Several new resource record 196 types are required, including the aforementioned SIG, KEY and DS. 197 EDNS0 support [6] for larger message sizes [7] is required, as is 198 support for the OK bit [8]. 200 3.1.1 Authenticating Name and Type Non-Existence 202 The security mechanism referenced above in Section 3.1 only provides 203 a way to sign existing RRsets in a zone. The problem of providing 204 negative responses with the same level of authentication and 205 integrity requires the use of another new resource record, the non- 206 existence (NXT) record. The NXT record allows a negative reply 207 (either for name or type non-existence) to be authenticated the same 208 way as other DNS replies. NXT records require a canonical 209 representation and order for domain names in zones. NXT records 210 exist to cover the gaps, or "empty space", between domain names in a 211 zone, as well as non-existent record types for existing names. Each 212 NXT record is signed and authenticated in the same way as any other 213 RRset. 215 3.2 Key Distribution 217 The KEY resource record is defined to associate public keys with DNS 218 names. This record permits the DNS to be used as a public key 219 distribution mechanism in support of DNSSEC. Security-aware 220 resolvers can query for a zone's public key when establishing a 221 authentication chain. 223 The syntax of the KEY resource record (and the other additional 224 resource records required for DNSSEC) is described in [9]. It 225 includes identifiers for the algorithm the key is used for and 226 information on the entity the key is associated with. 228 The original DNSSEC specification allowed other protocols and 229 applications to use the KEY record as a general-purpose mechanism to 230 store public keys. For reasons documented in [10], the KEY record is 231 now restricted for use with DNSSEC only. Work is in progress on 232 storing public keys [14] and certificates [15] used by other 233 protocols and applications in the DNS. A secure DNS tree could then 234 be used as a lightweight key distribution mechanism that could 235 support other protocols. However, this should not lead to the 236 conclusion that the DNS is then safe to use as a trusted protocol or 237 a Public Key Infrastructure. DNSSEC lacks many features found in a 238 PKI such as a Certificate Revocation List (CRL). 240 3.3 Transaction Security 242 The data origin authentication and data integrity service described 243 above authenticates retrieved RRsets and the non-existence of RRsets, 244 but provides no protection for complete DNS messages, e.g., when they 245 occur in zone transfers and dynamic updates. 247 A DNS message can be authenticated by including a special signature 248 RR at the end of the message, either a transaction signature (TSIG) 249 [11] or SIG record with a type covered field of zero (a "SIG(0)", see 250 [12]). Such a signature can be used to verify the integrity of the 251 DNS message. (The signature record in the additional section of a 252 query may produce an error or simply be ignored by older DNS 253 implementations that don't support transaction security.) Unlike the 254 mechanism described in Section 3.1, transaction security is specific 255 to the individual hosts exchanging DNS messages. The cryptographic 256 keys used with transaction security are associated with individual 257 hosts and not DNS zones. 259 In addition to transaction signatures, there is also support for key 260 agreement protocols to support transaction security using symmetric 261 encryption keys. This service uses the transaction key (TKEY) [13] 262 resource record. The use of the TKEY record in a key agreement 263 transaction depends on the algorithm used, and each key agreement 264 protocol is described in a separate document specific to each 265 algorithm. 267 4. Services Not Provided by DNS Security 269 The DNS design philosophy calls for all DNS data to be public and 270 uniform answers to all inquirers. Accordingly, confidentiality for 271 queries or responses is not provided, nor are any sort of access 272 control lists or other means to differentiate inquirers. 274 Denial of service is not protected against. 276 Signed zone data and/or the use of transaction signatures will not 277 protect against errors in DNS zone information or servers incorrectly 278 interpreting and/or setting DNS message header fields. 280 5. Resolver Considerations 282 A security-aware resolver needs to be able to perform necessary 283 cryptographic functions to verify digital signatures using at least 284 the mandatory-to-implement algorithms. Also, security-aware 285 resolvers must be capable of forming a authentication chain from a 286 newly learned zone back to a trusted authentication key. This might 287 require additional queries to intermediate DNS zones for necessary 288 KEY, DS and SIG records. It is assumed that a security-aware 289 resolver will be configured with at least one authentication key to 290 aid this process. 292 The stub resolver found in many hosts may be augmented to provide a 293 different set of security features instead of the full security 294 awareness found in a complete resolver. The use of transaction 295 security could help secure the final message passing between a 296 recursive DNS server and a stub resolver. This a matter of local 297 security policy. 299 A security-aware resolver needs to communicate with only security- 300 aware servers. If an unsecure server or an unsigned/unsecure zone is 301 part of the DNS resolution path, the resolver cannot ensure security. 302 If a security-aware resolver must rely on an unsecure server (or 303 unsigned zone), the resolver cannot verify DNS responses and should 304 rely on local policy when following responses. 306 6. Zone Considerations 308 A secure zone will have several differences from an unsigned zone. A 309 secure zone will contain additional security-related records (SIG, 310 KEY, DS and NXT records). SIG and NXT records may be generated by a 311 signing process prior to serving the zone. If SIG and NXT records 312 are not present in the zone, an authoritative server needs to 313 generate them before serving the zone. Zone data is only valid and 314 considered secure for a definable time period. The SIG records that 315 accompany zone data have defined inception and expiration times. 316 These times establish a validity period for the signatures and the 317 zone data the signatures cover. 319 7. Server Considerations 321 A security-aware server must be capable of performing the following 322 operations in addition to the normal operations of a DNS server 323 described in [3]: 325 A security-aware server should make all attempts to include 326 necessary security-related records (SIG, KEY, DS and NXT) in 327 responses as DNS message space permits. 329 A security-aware caching server must also take a signature's 330 validation period into consideration when determining the time to 331 live (TTL) of cached data: signed data should not be cached beyond 332 the signature validity period. 334 A security-aware server should have a means of employing 335 transaction security, such as transaction signatures (TSIG) or 336 SIG(0). Transaction security is primarily used when performing 337 other DNS operations such as zone transfers and dynamic updates 338 (if they are permitted according to the server's local policy). 340 All other means of restricting query, zone transfer, dynamic 341 update and administrative access to a security-aware server fall 342 under the category of operational security and are not addressed 343 by the DNS security extensions. 345 8. DNS Security Document Family 347 The DNSSEC set of documents can be partitioned into five main groups 348 as depicted in Figure 1. All these documents are in turn under the 349 larger umbrella of the DNS base protocol documents described in [16]. 351 8.1 DNS Security Document Roadmap 353 --------------------------------------------------------------------- 355 +--------------------------------+ 356 | | 357 | Base DNS Protocol Docs | 358 | [RFC1035, RFC2181, etc.] | 359 | | 360 +--------------------------------+ 361 | 362 | 363 +-----------+ +-------------+ 364 | DNSSEC | | New | 365 | Protocol |--------->| Security | 366 | Documents | | Uses | 367 +-----------+ +-------------+ 368 | 369 | 370 +------------------------------+ 371 | | 372 | | 373 +------------+ +---------------+ 374 | Dig. Sig. | | | 375 | Algorithm | | Transaction | 376 | Impl. | | Impl. | 377 | | | | 378 +------------+ +---------------+ 380 Figure 1: DNSSEC Document Roadmap 382 --------------------------------------------------------------------- 384 8.2 Categories of DNS Security Documents 386 The "DNSSEC protocol document set" refers to the three documents that 387 form the core of the DNS security extensions: 389 1. DNS Security Introduction and Requirements (this document) 390 2. Resource Records for DNS Security Extensions [9] 392 3. Protocol Modifications for the DNS Security Extensions (not yet 393 published) [12] 395 The "Dig. Sig. Algorithm Impl." document set refers to the group of 396 documents that describe how a specific digital signature algorithm is 397 implemented to fit the DNSSEC resource record format. Each of these 398 documents deals with a specific digital signature algorithm. 400 The "Transaction Impl." document set refers to the group of documents 401 that deal with DNS message transaction security, including secret key 402 establishment and verification. 404 The final document set, "New Security Uses", refers to documents that 405 seek to use proposed DNS Security extensions for other security 406 related purposes. Documents that fall in this category include the 407 use of DNS in the storage and distribution of certificates [15] and 408 individual user public keys (PGP, e-mail, etc.) [14]. 410 9. IANA Considerations 412 This document introduces no new IANA considerations. 414 10. Security Considerations 416 This document introduces the DNS security extensions and describes 417 the document set that contains the new security records and DNS 418 protocol modifications. The capabilities and limitations of these 419 extensions are discussed. The extensions provide data origin 420 authentication and data integrity using digital signatures over 421 resource records and (optionally) DNS messages. 423 In order for a secure resolver to validate a DNS response, all the 424 intermediate zones and servers must be capable of DNS security 425 processing. A security-aware resolver cannot verify responses sent 426 by an non-security-aware server. 428 The DNS security extensions do not protect against denial of service 429 (DoS) attacks or provide confidentiality. 431 11. Acknowledgements 433 This document was created from the input and ideas of several members 434 of the DNS Extensions Working Group. The authors would like to 435 acknowledge (in alphabetical order) the following people for their 436 contributions and comments on this document: 438 Derek Atkins 439 Rob Austein 440 Donald Eastlake 441 Miek Gieben 442 Olafur Gudmundsson 443 Olaf Kolkman 444 Ed Lewis 445 Ted Lindgreen 446 Bill Manning 447 Brian Wellington 449 Normative References 451 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 452 Levels", BCP 14, RFC 2119, March 1997. 454 [2] Eastlake, D., "Domain Name System Security Extensions", RFC 455 2535, March 1999. 457 [3] Mockapetris, P., "Domain names - implementation and 458 specification", STD 13, RFC 1035, November 1987. 460 [4] Mockapetris, P., "Domain names - concepts and facilities", STD 461 13, RFC 1034, November 1987. 463 [5] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name 464 System", draft-ietf-dnsext-dns-threats-01 (work in progress), 465 February 2002. 467 [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 468 August 1999. 470 [7] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 471 message size requirements", RFC 3226, December 2001. 473 [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 474 December 2001. 476 [9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource 477 Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- 478 records-00 (work in progress), March 2002. 480 [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 481 Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in 482 progress), March 2002. 484 [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 485 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 486 2845, May 2000. 488 [12] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol 489 Modifications for the DNS Security Extensions (Not yet 490 published)", draft-ietf-dnsext-dnssec-protocol-00 (work in 491 progress), to be published in 2002. 493 [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 494 2930, September 2000. 496 Informative References 498 [14] Schlyter, J., "Storing application public keys in the DNS", 499 draft-schlyter-appkey-02 (work in progress), February 2002. 501 [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 502 Domain Name System (DNS)", RFC 2538, March 1999. 504 [16] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- 505 dnssec-roadmap-05 (work in progress), November 2001. 507 Authors' Addresses 509 Roy Arends 510 Bankastraat 41-E 511 1094 EB Amsterdam 512 NL 514 EMail: roy@logmess.com 516 Matt Larson 517 VeriSign, Inc. 518 21345 Ridgetop Circle 519 Dulles, VA 20166-6503 520 USA 522 EMail: mlarson@verisign.com 524 Dan Massey 525 USC Information Sciences Institute 526 3811 N. Fairfax Drive 527 Arlington, VA 22203 528 USA 530 EMail: masseyd@isi.edu 532 Scott Rose 533 National Institute for Standards and Technology 534 100 Bureau Drive 535 Gaithersburg, MD 20899-8920 536 USA 538 EMail: scott.rose@nist.gov 540 Full Copyright Statement 542 Copyright (C) The Internet Society (2002). All Rights Reserved. 544 This document and translations of it may be copied and furnished to 545 others, and derivative works that comment on or otherwise explain it 546 or assist in its implementation may be prepared, copied, published 547 and distributed, in whole or in part, without restriction of any 548 kind, provided that the above copyright notice and this paragraph are 549 included on all such copies and derivative works. However, this 550 document itself may not be modified in any way, such as by removing 551 the copyright notice or references to the Internet Society or other 552 Internet organizations, except as needed for the purpose of 553 developing Internet standards in which case the procedures for 554 copyrights defined in the Internet Standards process must be 555 followed, or as required to translate it into languages other than 556 English. 558 The limited permissions granted above are perpetual and will not be 559 revoked by the Internet Society or its successors or assigns. 561 This document and the information contained herein is provided on an 562 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 563 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 564 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 565 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 566 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Acknowledgement 570 Funding for the RFC Editor function is currently provided by the 571 Internet Society.