idnits 2.17.1 draft-fenton-dkim-threats-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 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 21, 2005) is 6762 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) == Outdated reference: A later version (-01) exists of draft-allman-dkim-base-00 == Outdated reference: A later version (-02) exists of draft-allman-dkim-ssp-00 == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-04 == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-02 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-workgroup J. Fenton 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 24, 2006 October 21, 2005 6 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) 7 draft-fenton-dkim-threats-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 April 24, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document provides an analysis of some threats against Internet 41 mail that are intended to be addressed by signature-based mail 42 authentication, in particular DomainKeys Identified Mail. It 43 discusses the nature and location of the bad actors, what their 44 capabilities are, and what they intend to accomplish via their 45 attacks. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The Bad Actors . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Capabilities of the Bad Actors . . . . . . . . . . . . . . . . 4 52 3.1. General capabilities . . . . . . . . . . . . . . . . . . . 4 53 3.2. Advanced capabilities . . . . . . . . . . . . . . . . . . 4 54 4. Location of the Bad Actors . . . . . . . . . . . . . . . . . . 5 55 4.1. Externally-located Bad Actors . . . . . . . . . . . . . . 5 56 4.2. Within Claimed Originator's Administrative Unit . . . . . 6 57 4.3. Within Recipient's Administrative Unit . . . . . . . . . . 6 58 5. Representative Bad Acts . . . . . . . . . . . . . . . . . . . 7 59 5.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 7 60 5.2. Use of Specific Identities . . . . . . . . . . . . . . . . 7 61 5.2.1. Exploitation of Social Relationships . . . . . . . . . 8 62 5.2.2. Identity-Related Fraud . . . . . . . . . . . . . . . . 8 63 5.2.3. Reputation Attacks . . . . . . . . . . . . . . . . . . 8 64 6. Attacks on Message Signing . . . . . . . . . . . . . . . . . . 9 65 6.1. Unsigned Messages . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Use of Throw-Away Addresses . . . . . . . . . . . . . . . 9 67 6.3. Message Replay . . . . . . . . . . . . . . . . . . . . . . 10 68 6.4. Control of Key Management . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 11 73 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 74 Appendix C. Edit History . . . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . . . 14 78 1. Introduction 80 DomainKeys Identified Mail (DKIM) [I-D.allman-dkim-base] defines a 81 simple, low cost, and effective mechanism by which email messages can 82 be cryptographically signed, permitting a signing domain to claim 83 responsibility for the use of a given email address. Message 84 recipients can verify the signature by querying the signer's domain 85 directly to retrieve the appropriate public key, and thereby confirm 86 that the message was attested to by a party in possession of the 87 private key for the signing domain. 89 Once the attesting party or parties have been established, the 90 recipient may evaluate the message in the context of additional 91 information such as locally-maintained whitelists, shared reputation 92 services, and/or third-party accreditation. The description of these 93 mechanisms is outside the scope of this effort. By applying a 94 signature, a good player will be able to associate a positive 95 reputation with the message, in hopes that it will receive 96 preferential treatment by the recipient. 98 This effort is not intended to address threats associated with 99 message confidentiality nor does it intend to provide a long-term 100 archival signature. 102 2. The Bad Actors 104 The problem space being addressed by DKIM is characterized by a wide 105 range of attackers in terms of motivation, sophistication, and 106 capabilities. 108 At the low end of the spectrum are bad actors who may simply send 109 email, perhaps using one of many commercially available tools, which 110 the recipient does not want to receive. These tools may or may not 111 falsify the origin address of messages, and may, in the future, be 112 capable of generating message signatures as well. 114 At the next tier are what would be considered "professional" senders 115 of unwanted email. These attackers would deploy specific 116 infrastructure, including Mail Transfer Agents (MTAs), registered 117 domains and possibly networks of compromised computers ("zombies") to 118 send messages, and in some cases to harvest addresses to which to 119 send. These senders often operate as commercial enterprises and send 120 messages on behalf of third parties. 122 The most sophisticated and financially-motivated senders of messages 123 are those who stand to receive substantial financial benefit, such as 124 from an email-based fraud scheme. These attackers can be expected to 125 employ all of the above mechanisms and in addition attacks on 126 Internet infrastructure itself, such as DNS cache-poisoning attacks 127 and IP routing attacks via compromised network routing elements. 129 3. Capabilities of the Bad Actors 131 3.1. General capabilities 133 In general, the bad actors described above should be expected to have 134 access to the following: 136 1. An extensive corpus of messages from domains they might wish to 137 impersonate 139 2. Knowledge of the business aims and model for domains they might 140 wish to impersonate 142 3. Access to public key and associated authorization records 143 published by the domain 145 and the ability to do at least some of the following: 147 1. Submit messages to MTAs at multiple locations in the Internet 149 2. Construct arbitrary message headers, including those claiming to 150 be mailing lists, resenders, and other mail agents 152 3. Sign messages on behalf of potentially-untraceable domains under 153 their control 155 4. Generate substantial numbers of either unsigned or apparently- 156 signed messages which might be used to attempt a denial of 157 service attack 159 5. Resend messages which may have been previously signed by the 160 domain 162 6. Transmit messages using any envelope information desired 164 3.2. Advanced capabilities 166 As noted above, certain classes of bad actors may have substantial 167 financial motivation for their activities, and therefore should be 168 expected to have more capabilities at their disposal. These include: 170 1. Manipulation of IP routing. This could be used to submit 171 messages from specific IP addresses or difficult-to-trace 172 addresses, or to cause diversion of messages to a specific 173 domain. 175 2. Limited influence over portions of DNS using mechanisms such as 176 cache poisoning. This might be used to influence message 177 routing, or to cause falsification of DNS-based key or policy 178 advertisements. 180 3. Access to significant computing resources, perhaps through the 181 conscription of worm-infected "zombie" computers. This could 182 allow the bad actor to perform various types of brute-force 183 attacks. 185 4. Ability to "wiretap" some existing traffic, perhaps from a 186 wireless network. 188 Either of the first two of these mechanisms could be used to allow 189 the bad actor to function as a man-in-the-middle between sender and 190 recipient, if that attack is useful. 192 4. Location of the Bad Actors 194 In the following discussion, the term "administrative unit", taken 195 from [I-D.crocker-email-arch], is used to refer to a portion of the 196 email path that is under common administration. The originator and 197 recipient typically develop trust relationships with the 198 administrative units that send and receive their email, respectively, 199 to perform the signing and verification of their messages. 201 Bad actors or their proxies can be located anywhere in the Internet. 202 Bad actors within the administrative unit of the claimed originator 203 and/or recipient domain have capabilities beyond those elsewhere, as 204 described in the below sections. Bad actors can also collude by 205 acting in multiple locations simultaneously (a "distributed bad 206 actor"). 208 4.1. Externally-located Bad Actors 210 DKIM focuses primarily on bad actors located outside of the 211 administrative units of the claimed originator and the recipient. 212 These administrative units frequently correspond to the protected 213 portions of the network adjacent to the originator and recipient. It 214 is in this area that the trust relationships required for 215 authenticated message submission do not exist and do not scale 216 adequately to be practical. Conversely, within these administrative 217 units, there are other mechanisms such as authenticated message 218 submission that are wasier to deploy and more likely to be used than 219 DKIM. 221 External bad actors are usually attempting to exploit the "any to 222 any" nature of email which motivates most recipient MTAs to accept 223 messages from anywhere for delivery to their local domain. They may 224 generate messages without signatures, with incorrect signatures, or 225 with correct signatures from domains with little traceability. They 226 may also pose as mailing lists, greeting cards, or other agents which 227 legitimately send or re-send messages on behalf of others. 229 4.2. Within Claimed Originator's Administrative Unit 231 Bad actors in the form of rogue or unauthorized users or malware- 232 infected computers can exist within the administrative unit 233 corresponding to a message's origin address. Since the submission of 234 messages in this area generally occurs prior to the application of a 235 message signature, DKIM is not directly effective against these bad 236 actors. Defense against these bad actors is dependent upon other 237 means, such as proper use of firewalls, and mail submission agents 238 that are configured to authenticate the sender. 240 In the special case where the administrative unit is non-contiguous 241 (e.g., a company that communicates between branches over the external 242 Internet), DKIM signatures can be used to distinguish between 243 legitimate externally-originated messages and attempts to spoof 244 addresses in the local domain. 246 4.3. Within Recipient's Administrative Unit 248 Bad actors may also exist within the administrative unit of the 249 message recipient. These bad actors may attempt to exploit the trust 250 relationships which exist within the unit. Since messages will 251 typically only have undergone DKIM verification at the administrative 252 unit boundary, DKIM is not effective against messages submitted in 253 this area. 255 For example, the bad actor may attempt to apply a header such as 256 Authentication-Results [I-D.kucherawy-sender-auth-header] which would 257 normally be added (and spoofing of which would be detected) at the 258 boundary of the administrative unit. This could be used to falsely 259 indicate that the message was authenticated successfully. 261 As in the originator case, these bad actors are best dealt with by 262 controlling the submission of messages within the administrative 263 unit. Depending on the characteristics of the administrative unit, 264 cryptographic methods may or may not be needed to accomplish this. 266 5. Representative Bad Acts 268 One of the most fundamental bad acts being attempted is the delivery 269 of messages which are not authorized by the alleged originating 270 domain. As described above, these messages might merely be unwanted 271 by the recipient, or might be part of a confidence scheme or a 272 delivery vector for malware. 274 5.1. Use of Arbitrary Identities 276 This class of bad acts includes the sending of messages which aim to 277 obscure the identity of the actual sender. In some cases the actual 278 sender might be the bad actor, or in other cases might be a third- 279 party under the control of the bad actor (e.g., a compromised 280 computer). 282 DKIM is effective in mitigating against the use of addresses not 283 controlled by bad actors, but is not effective against the use of 284 addresses they control. In other words, the presence of a valid DKIM 285 signature does not guarantee that the signer is not a bad actor. It 286 also does not guarantee the accountability of the signer, since that 287 is limited by the extent to which domain registration requires 288 accountability for its registrants. However, accreditation and 289 reputation systems can be used to enhance the accountability of DKIM- 290 verified addresses and/or the likelihood that signed messages are 291 desirable. 293 5.2. Use of Specific Identities 295 A second major class of bad acts involves the assertion of specific 296 identities in email. 298 Note that some bad acts involving specific identities can sometimes 299 be accomplished, although perhaps less effectively, with similar 300 looking identities that mislead some recipients. For example, if the 301 bad actor is able to control the domain "examp1e.com" (note the "one" 302 between the p and e), they might be able to convince some recipients 303 that a message from admin@examp1e.com is really admin@example.com. 304 Similar types of attacks using internationalized domain names have 305 been hypothesized where it could be very difficult to see character 306 differences in popular typefaces. Similarly, if example2.com was 307 controlled by a bad actor, the bad actor could sign messages from 308 bigbank.example2.com which might also mislead some recipients. To 309 the extent that these domains are controlled by bad actors, DKIM is 310 not effective against these attacks, although it could support the 311 ability of reputation and/or accreditation systems to aid the user in 312 identifying them. 314 5.2.1. Exploitation of Social Relationships 316 One reason for asserting a specific origin address is to encourage a 317 recipient to read and act on particular email messages by appearing 318 to be an acquaintance or previous correspondent that the recipient 319 might trust. This tactic has been used by email-propagated malware 320 which mail themselves to addresses in the infected host's address 321 book. In this case, however, the sender's address may not be 322 falsified, so DKIM would not be effective in defending against this 323 act. 325 It is also possible for address books to be harvested and used by an 326 attacker to send messages from elsewhere. DKIM would be effective in 327 mitigating these acts by limiting the scope of origin addresses for 328 which a valid signature can be obtained when sending the messages 329 from other locations. 331 5.2.2. Identity-Related Fraud 333 Bad acts related to email-based fraud often, but not always, involve 334 the transmission of messages using specific origin addresses of other 335 entities as part of the fraud scheme. The use of a specific address 336 of origin sometimes contributes to the success of the fraud by 337 convincing the recipient that the message was actually sent by the 338 alleged sender. 340 To the extent that the success of the fraud depends on or is enhanced 341 by the use of a specific origin address, the bad actor may have 342 significant financial motivation and resources to circumvent any 343 measures taken to protect specific addresses from unauthorized use. 345 5.2.3. Reputation Attacks 347 Another motivation for using a specific origin address in a message 348 is to harm the reputation of another, commonly referred to as a "joe- 349 job". For example, a commercial entity might wish to harm the 350 reputation of a competitor, perhaps by sending unsolicited bulk email 351 on behalf of that competitor. It is for this reason that reputation 352 systems must be based on an identity that is, in practice, fairly 353 reliable. 355 Reputation attacks of this sort are sometimes based on the 356 retransmission (often referred to as a "replay") of a legitimately 357 sent message. DKIM provides little protection against such acts, 358 although the key used to sign the original instance of the message 359 can be revoked, which limits the time window available for such 360 attacks. Other reputation attacks, involving the fabrication and 361 transmission of a fictitious message, are addressed by DKIM since the 362 bad actor would not, without inside assistance, be able to obtain a 363 valid signature for the fabricated message. 365 6. Attacks on Message Signing 367 Bad actors can be expected to exploit all of the limitations of 368 message authentication systems. They are also likely to be motivated 369 to degrade the usefulness of message authentication systems in order 370 to hinder their deployment. Some representatives of these categories 371 of bad acts are described below. Additional postulated attacks are 372 described in the Security Considerations section of [I-D.allman-dkim- 373 base]. 375 6.1. Unsigned Messages 377 Messages without signatures may be sent in an effort to exploit the 378 incremental deployment of message signatures. In many cases, a 379 recipient may not be able to make a determination about unsigned 380 messages from a domain, and therefore will need to accept the message 381 (although perhaps at a lower delivery priority). This situation is 382 mitigated by the use of the DKIM Sender Signing Policy (SSP) 383 [I-D.allman-dkim-ssp] that indicates whether or not a given domain 384 signs all of its messages. Nevertheless, the possibility of 385 signature breakage due to legitimate modification of the message may 386 limit the ability of SSP to dictate harsh treatment of messages 387 without valid signatures. 389 Messages with invalid signatures may also be introduced by bad 390 actors. The intent may be to make the message appear as though it 391 was legitimately sent, but "broken" in transit, i.e. that the message 392 was modified, rendering the signature invalid. At least until the 393 causes of signature breakage are well understood, messages with 394 invalid signatures need to be evaluated as if the invalid signature 395 isn't present at all. 397 6.2. Use of Throw-Away Addresses 399 Bad actors may also introduce messages with valid signatures on 400 behalf of domains they control, perhaps "throw-away" domains 401 registered under false pretenses which are difficult to trace. In 402 other words, the existence of a message signature does not imply that 403 the message is "good". The use of such domains will undoubtedly give 404 rise to domain-based accreditation and reputation systems. Until 405 these are available, local reputation, mostly in the form of 406 whitelists, can be maintained by domains to improve the 407 deliverability of email from domains with which they have business or 408 other relationships. 410 Accreditation and reputation, or even local whitelists, require a 411 reliable identity on which to base their assertion, and in the case 412 of reputation on which to base any feedback reports. Message signing 413 provides an identity which is intended to be sufficiently reliable 414 for this purpose, and it (or some other reliable mechanism) is 415 necessary for accreditation and reputation systems to operate. 417 Modification of messages by mailing lists and other legitimate agents 418 requires that a mechanism be created for signing of messages by other 419 than the originating domain. This provides a bad actor with an 420 additional avenue through which it might attempt to circumvent 421 message authentication. A bad actor might attempt to pose as a 422 mailing list which modifies a message and adds its own signature 423 taking responsibility for the message. If this signature is from an 424 untraceable domain, little assertion of the legitimacy of the message 425 is provided by this signature. For this reason, accreditation, 426 reputation, and local reputation in the form of white lists is at 427 least as important for these signatures from third parties as they 428 are for origination address signatures. 430 6.3. Message Replay 432 Message replay is a term used to describe the retransmission of 433 already-signed messages. Here the bad actor obtains an account with 434 a domain such as a consumer ISP, and sends an undesirable message to 435 an external address controlled by the bad actor or an accomplice. 436 That message, having now obtained a signature, is forwarded to other 437 recipients without the authorization of the signing domain. It is 438 closely related to one of the reputation attacks described above. 440 This bad act is basically indistinguishable from a number of 441 acceptable acts, such as the transparent forwarding of messages by a 442 recipient to multiple addresses. For this reason, DKIM is not 443 particularly effective at detecting and eliminating this bad act. 444 Prompt key revocation may mitigate this problem; however, since 445 verification typically occurs as messages are received by recipient 446 domains, time is of the essence. 448 Other means to mitigate this bad act include the use of content 449 filtering on messages being signed, and business models which enforce 450 more accountability for subscribers whose messages are to be signed 451 by DKIM. 453 6.4. Control of Key Management 455 In cases where the Bad Actor is in control of the DNS zone for a 456 domain's keyspace subdomain (_domainkey), or is able to influence the 457 records in that zone, message signing may present a new opportunity 458 to interfere with the receipt of legitimate messages or to sign 459 messages not illegitimately. This could occur if the DNS provider 460 for the domain is not reliable or if the security measures used by 461 the DNS provider are breached by the bad actor. DKIM is fully 462 dependent on the key information which it is provided by DNS, so 463 independent means such as audits of the key records would be required 464 to mitigate this threat. 466 7. IANA Considerations 468 This document defines no items requiring IANA assignment. 470 8. Security Considerations 472 This document describes the security threat environment in which 473 DomainKeys Identified Mail (DKIM) is expected to provide some 474 benefit. 476 9. Informative References 478 [I-D.allman-dkim-base] 479 Allman, E., "DomainKeys Identified Mail (DKIM)", 480 draft-allman-dkim-base-00 (work in progress), July 2005. 482 [I-D.allman-dkim-ssp] 483 Allman, E., "DKIM Sender Signing Policy", 484 draft-allman-dkim-ssp-00 (work in progress), July 2005. 486 [I-D.crocker-email-arch] 487 Crocker, D., "Internet Mail Architecture", 488 draft-crocker-email-arch-04 (work in progress), 489 March 2005. 491 [I-D.kucherawy-sender-auth-header] 492 Kucherawy, M., "Message Header for Indicating Sender 493 Authentication Status", 494 draft-kucherawy-sender-auth-header-02 (work in progress), 495 May 2005. 497 Appendix A. Glossary 499 Origin address - The address on an email message, typically the RFC 500 2822 From: address, which is associated with the alleged author of 501 the message and is displayed by the recipient's MUA as the source of 502 the message. 504 Appendix B. Acknowledgements 506 The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony 507 Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, and 508 Jon Callas for valuable suggestions and constructive criticism of 509 earlier versions of this draft. 511 Appendix C. Edit History 513 Changes since -00 draft: 515 o Changed beginning of introduction to make it consistent with -base 516 draft. 518 o Clarified reasons for focus on externally-located bad actors. 520 o Elaborated on reasons for effectiveness of address book attacks. 522 o Described attack time windows with respect to replay attacks. 524 o Added discussion of attacks using look-alike domains. 526 o Added section on key management attacks. 528 Author's Address 530 Jim Fenton 531 Cisco Systems, Inc. 532 MS SJ-24/2 533 170 W. Tasman Drive 534 San Jose, CA 95134-1706 535 USA 537 Phone: +1 408 526 5914 538 Email: fenton@cisco.com 539 URI: 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2005). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.