idnits 2.17.1 draft-levine-smtp-batv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 591. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 12, 2008) is 5827 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) -- No information found for draft-email-arch - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track D. Crocker 5 Expires: November 13, 2008 Brandenburg InternetWorking 6 S. Silberman 7 Openwave 8 T. Finch 9 University of Cambridge 10 May 12, 2008 12 Bounce Address Tag Validation (BATV) 13 draft-levine-smtp-batv-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 13, 2008. 40 Abstract 42 The envelope of Internet mail contains an RFC2821.MailFrom command, 43 which may supply an address to be used as the recipient of 44 transmission and delivery notices about the original message. 45 Existing Internet mail permits unauthorized use of addresses in the 46 MailFrom command, causing notices to be sent to unwitting and 47 unwilling recipients. Bounce Address Tag Validation (BATV) defines 48 an extensible mechanism for validating the MailFrom address. It also 49 defines an initial use of that mechanism which requires no 50 administrative overhead and no global implementation. 52 This document is a revision of draft-levine-mass-batv-02. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Meta-Syntax . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Tagging Schemes . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Beyond BATV . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Local-Part Meta-Syntax . . . . . . . . . . . . . . . . . . . . 7 63 4. Simple Private Signature (prvs) . . . . . . . . . . . . . . . 8 64 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. References - Normative . . . . . . . . . . . . . . . . . . 12 70 7.2. References - Informative . . . . . . . . . . . . . . . . . 12 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 72 Appendix B. IANA Considerations . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 The envelope for Internet Mail may contain an address that is 79 designated to receive transmission-related notifications. It is 80 specified in the RFC2821.MailFrom command. The field is set by the 81 RFC2822.Sender, acting as an agent of the message author specified in 82 RFC2822.From. However no portion of the MailFrom address is required 83 to have any similarity to any portion of the From or Sender 84 addresses, and valid usage scenarios do call for the MailFrom address 85 to have no visible relationship to the From or Sender values. 87 Further, existing Internet mail permits unauthorized use of addresses 88 in the MailFrom command, which results in having notices sent to 89 unwitting and unwilling recipients. Therefore, the challenge is to 90 distinguish legitimate uses from these unauthorized uses and to do 91 this with a mechanism that incurs modest administration, operations 92 and performance costs. 94 Bounce Address Tag Validation (BATV) defines a framework for 95 mechanisms that validate the value in this command. Multiple 96 validation methods are envisioned. So BATV defines a common 97 syntactic framework that enhances the local-part field of the 98 MailFrom address. An initial, specific validation scheme is also 99 defined; it requires no administrative overhead and no global 100 implementation. 102 The of an Internet mail address is a globally opaque 103 string. Hence, the specified modification to the local-part can be 104 deployed in a manner that is entirely transparent to the public 105 Internet mail service, except for mail system components within the 106 scope of the MailFrom domain, and then only for components that 107 process the MailFrom address local-part. The result permits the 108 MailFrom target domain to distinguish notification message addresses 109 that are valid from those that are not. Enhancements would permit 110 processing agents that are along the original message's transfer path 111 to determine whether the MailFrom adress is likely to be valid. This 112 assessment could aid in deciding whether to send a bounce message, 113 thereby reducing the Internet mail infrastructure cost for 114 transmitting notification messages in response to addresses used 115 without permission. It might even be used to detect invalid 116 messages, thereby reducing Internet mail infrastructure cost for 117 original messages. 119 Terminology: Terminology conforms to [I-D.email-arch] 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 121 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 122 in this document are to be interpreted as described in [RFC2119] 124 2. Model 126 BATV defines a method for tagging information to be included in the 127 of the RFC2821.MailFrom address. This permits encoding 128 information that authenticates the MailFrom. Because the information 129 is placed in MailFrom, rather than in an RFC2822 header, it sometimes 130 is not as publicly visible as an RFC2822 header. Tagging the 131 MailFrom address rather than any of the RFC2822 addresses avoids 132 problems arising from rewriting message headers that may be visible 133 to recipients, and enables the validation process to operate within 134 an SMTP session before the contents of a message are transferred. 136 2.1. Meta-Syntax 138 BATV tagging is based on a meta-syntax that defines a field-oriented 139 structure for an address local-part. It permits use of a variety of 140 address authentication methods, while supporting remote extraction of 141 the core portion of the local-part, without having to understand the 142 semantics of any particular scheme. 144 NOTE: BATV is for the purpose of detecting invalid RFC2821.MailFrom 145 addresses. Any BATV-related modifications that are made to the 146 original MailFrom MUST preserve the result of returning valid 147 bounces to the address originally specified in that MailFrom. 149 The meta-syntax for MailFrom local-part is defined in Section 3. 151 2.2. Tagging Schemes 153 BATV permits alternative schemes. To ensure interoperability among 154 independent participants, other specifications adopting the meta- 155 syntax conventions MUST define and register with IANA a unique, case 156 insensitive element, to identify the specific mechanism 157 that is being used for MailFrom validation. 159 Private Tagging: If MailFrom validity assessment is performed only 160 within the scope of the domain referenced in the MailFrom address, 161 then its semantic scope is private (closed), encompassing only 162 that domain and the one that generated the validity information. 163 To the rest of the Internet, the tag information is opaque, like a 164 cookie. In these situations, the closed system is free to use any 165 tagging scheme it deems helpful, although a standard format aids 166 other systems that wish to avoid re-tagging addresses that are 167 already tagged, or to strip off the tag for compatibility with 168 legacy systems that key on the MailFrom address of incoming mail. 169 A simple scheme for this is defined in Section 4. 171 Public Tagging: Using a public-key approach for signing the 172 MailFrom's local-part permits intermediaries that process the 173 envelope to validate that address. For example, an intermediary 174 (that otherwise might create a bounce message) would be able to 175 decide that the MailFrom address use is not valid, so they might 176 decide to terminate bounce processing. Such a scheme might use 177 the BATV meta-syntax in the following way: 179 pub3==@example.com 181 If the creator of a bounce could make this assessment, all of 182 earlier intermedite MTAs also could. Hence, every MTA would be 183 able to assess whether a message has an unauthorized 184 RFC2821.MailFrom. 186 Unfortunately, none of the multiple existing public key services 187 has yet gained wide adoption. Therefore, this specification is 188 not able to provide a single method for public MailFrom validity 189 checking. 191 2.3. Beyond BATV 193 BATV defines a framework that retains the original local-part of the 194 MailFrom address within the BATV-encoded form. This permits external 195 inspection of the original local-part, such as for analyzing its use 196 with respect to particular RFC2822.From addresses. Enhancements that 197 go beyond the open information of BATV might replace the original 198 local-part with some form of translation. Examples of such schemes 199 could include: 201 Alias: The original RFC2821.MailFrom local-part could be replaced 202 with an alternative local-part. The meta-syntax provides a way to 203 flag the difference between the new local-part and the original. 205 Opaque Pointer: This could be used to consult a database with 206 records of mail sent and bounces received. 208 Challenge Response: The receiver could make a DNS-query for 209 instructions about processing the RFC2821.MailFrom bounce address. 211 2.4. Operation 213 The basic methods for creating and interpreting BATV-encoded MailFrom 214 addresses are very simple. 216 2.4.1. Tag Creation 218 The RFC2821.MailFrom address is specified by the RFC2822.Sender. 219 This makes the MailFrom address an end-user string, created by the 220 oMUA or MSA. However it is entirely reasonable to have an outbound 221 MTA, under administrative control of the Sender's domain, perform the 222 necessary signing. What is significant is that this requires a 223 change to only two modules, one in the outbound sequence and one in 224 the corresponding inbound sequence. The change is transparent to all 225 other systems components that transmit the message. 227 NOTE: If a MailFrom local-part already conforms to the meta-syntax, 228 the string SHOULD be left unchanged, so as not to break 229 forwarding. 231 NOTE: An MTA MUST ONLY tag addresses in domains whose inbound MTAs 232 can validate the tags. In particular, when an MTA is relaying a 233 message, on behalf of another Administrative Management Domain 234 (ADMD), it must not tag the MailFrom address, even if the original 235 ADMD did not add a tag. In all cases, the MTA must only tag 236 addresses for which it has access to the signing key that 237 corresponds to the validation key used by the inbound MTA for the 238 address' domain. 240 2.4.2. Tag Interpretation: 242 Addresses that contain BATV tags can be interpreted for two different 243 purposes: bounce address validation and bounce delivery. 245 Address validation: An MTA MAY validate a BATV-encoded MailFrom 246 address. This requires that the MTA be able to process the 247 specific BATV validation scheme that is specified by the field. If the address is determined to be invalid, the MTA 249 SHOULD process the address as having a permanent failure, for 250 example by returning a 550 response to the SMTP command containing 251 the address. 253 The MTA MAY also require that the use of the address is 254 appropriate, for example that the message is a bounce as indicated 255 by a null RFC2821.MailFrom; other heuristically determined 256 contexts MAY also be appropriate. For example, messages with 257 MailFroms beginning with "mailer-daemon@" are in practice almost 258 always bounces. Use of a BATV address in inappropriate contexts 259 SHOULD cause a permanent failure as above. 261 Bounce delivery: When an MTA within the specified address delivery 262 domain's administration receives a delivery notification directed 263 to a BATV-encoded address, the MTA SHOULD validate that address 264 when that message has a null MailFrom. A receiving server MAY 265 also perform heuristic selection of other incoming mail, such as 266 ones that have a MailFrom starting with "mailer-daemon@". If it 267 determines that the use is not valid, it SHOULD reject the message 268 during the mail transfer connection, such as with SMTP. 270 If the BATV address passes these checks, the message SHOULD then 271 be delivered to the original RFC2821.MailFrom address. This 272 original MailFrom address would be recovered as a side-effect of 273 validating the BATV address. 275 3. Local-Part Meta-Syntax 277 A meta-syntax for the of an address creates a public 278 convention for partitioning an address' local-part field (left-hand 279 side) into sub-fields of attributes associated with the 280 that was the original local-part. 282 A standardized meta-syntax for local-part permits attributes to be 283 present in the address, without requiring that public processing of 284 the address have any understanding of the attributes' semantics. The 285 semantics of are strictly local to the domain 286 administering the field. This separation between local 287 and global semantics has been a powerful benefit to Internet mail. 288 It affords considerable operational flexibility. The meta-syntax 289 permits public information in an address to be richer, while 290 maintaining the local/global separation. 292 The generic element syntax for the structured fields defined for a 293 BATV is: 295 local-part = tag-type "=" tag-val "=" loc-core 297 tag-type = 1*( DIGIT / ALPHA / "-" ) 298 ; specific, registered validation scheme 300 loc-core = {original local-part value} 302 tag-val = 1*( DIGIT / ALPHA / "-" ) 303 ; the validation data 305 This syntax is chosen so that software that needs, for legacy 306 compatibility reasons, to recover the original bounce address can do 307 so by checking for the presence of the tag-type, and if it is 308 present, discarding the local-part up through the second equal sign. 310 4. Simple Private Signature (prvs) 312 The Simple Private Signature (PRVS) scheme signs the original 313 MailFrom by using a simple shared-key to add a hash of the address 314 and some time-based randomizing information. 316 4.1. Syntax 318 This scheme is identified as: 320 tag-type = "prvs" 321 ; simple private signature 323 tag-val = K DDD SSSSSS 325 K = 1DIGIT 326 ; key number, to allow key rotation 328 DDD = 3DIGIT 329 ; day number, low three digits of 330 ; the number of days since 1970 331 ; when the address will expire 333 SSSSSS = 6HEXDIG 334 ; hex of the first three bytes of the 335 ; SHA-1 HMAC of and a key 337 hash-source = K DDD 339 orig-mailfrom = 341 4.2. Operation 343 4.2.1. Signature Creation 345 PRVS creates a package around an existing , comprising 346 the PRVS label and the signature hash on the left. The hash is 347 extremely simple and not very robust, because the requirements for 348 BATV do not entail strong protection. The mechanism provides very 349 weak protection against replay, in order to keep the effort to create 350 or validate the signature small. 352 4.2.2. Signature Checking 354 The checking of private signatures is only performed within the 355 domain specified in the MailFrom command. The first component that 356 processes the MailFrom's local-part must be able to interpret the 357 meta-syntax. It MAY also perform validation. 359 The scheme described here permits algorithmic validation. It does 360 not require maintaining a database of information about recently sent 361 messages. 363 The DDD part of the allows a domain to limit the lifetime 364 of PRVS addresses to give very basic protection against replay 365 attacks. If the expiry time has passed the address SHOULD be 366 considered invalid even if the HMAC is OK. The address lifetime 367 SHOULD be 7 days, to allow for long delivery delays before a bounce 368 occurs. Since it is valid and often useful for a single message to 369 provoke multiple bounces, it is specifically not a goal of BATV to 370 prevent them. Note that the DDD is the low three digits of the day 371 number, so comparisons MUST use unsigned subtraction mod 1000 or the 372 equivalent to handle wraparound correctly. 374 5. Interoperability 376 BATV seeks to retrofit a standardized syntactic structure onto the 377 of an RFC2821.MailFrom email address. Although it is 378 based on an existing, standard structure, it will be used in new 379 environments. Because this field has previously been opaque to these 380 environments, it is likely to create some usage problems with some 381 existing services. Problems are most likely in some services that 382 operate in the scope of the delivery stage of processing, rather than 383 in intermediaries between independent user services. In particular 384 serious problems are likely to be with third-party services that 385 constrain local-part beyond the Internet standards. Hence they 386 restrict interoperability, even without concern for BATV. 388 As an example, such systems incorrectly identify the sender of the 389 message by using the MailFrom address, rather than the RFC2822.Sender 390 address. Examples are listed below. Further, they require that this 391 address be the same for all future postings from the RFC2822.From 392 address. Problems arise because messages authored by a particular 393 RFC2822.From address are like to vary the associated MailFrom address 394 over time, particularly when BATV encoding is used. 396 Such systems SHOULD fix the underlying problem, at a minimum by using 397 the RFC2822.Sender address to identify the sender. However, note 398 that Internet mail does not require that the value of the Sender 399 address be related to a From address, and there are many legitimate 400 reasons for it to vary. 402 Some systems MAY continue to require correlation between MailFrom and 403 From. For example the system might operate on the envelope before 404 the message data has been transmitted, so software might strip off 405 the meta-syntax to recover the which can then be used as 406 the MailFrom address's original . For such validation 407 processing this altered address MUST NOT be used for further mail- 408 delivery processing. Rather the MailFrom string MUST be preserved as 409 it was received. 411 The benefit of a standardized meta-syntax for adding validation 412 attributes is that it permits such mechanisms to detect the 413 "attribute" portions of the local-part and extract only the core 414 portion, without having to understand any of the details of the 415 attributes. 417 The known and likely set of problem third-parties are: 419 Greylisters: A correct BATV implementation will only result in 420 routine delays in this case. However the result of BATV tagging 421 MUST be a constant local-part, for a given message, and not (say) 422 created at delivery time such that each retry gets a different 423 validation string, which would prevent it from ever getting 424 through to a greylisting site. 426 Mailing Lists: BATV will cause problems with some mailing lists 427 that identify posters by their bounce address. The list will not 428 recognize the identical MailFrom addresses, because it will 429 interpret the differing BATV attributes as part of the address. 430 These services will either reject postings or pass them all to the 431 moderator. 433 Challenge-Response Systems: The problem with these is similar to 434 the those with mailing lists, but the challenged user will have to 435 take special action for every message recipient that auto-sorts 436 mail by bounce address. 438 Sorting and Duplicate Detection: Any system that sorts by bounce 439 address (MailFrom) will interpret the addresses as different, even 440 though they are not. This may include whitelisting services. 442 BATV requires that the sending and receiving mail software within a 443 domain share the secret key used to create the signature. Usually 444 this is easy to arrange, by creating the signature in a domain's 445 outgoing mail relay and checking it in the inbound MX, if both are 446 run by the same management. But it is not necessary for a domain's 447 inbound and outbound relays to be under the same management; for 448 example it is fairly common for incoming mail for a small business 449 domain to be received by an MTA run by a hosting company, while the 450 outbound mail is sent through the ISP that provides the connection to 451 the company's office. In this case, it may be necessary to sign the 452 outgoing mail in the individual senders' MUAs, to check the signature 453 in the individual recipients' MUAs, or both. 455 6. Security Considerations 457 This entire document pertains to the security of email's asynchronous 458 error handling (bounce notification) mechanism, by describing a way 459 to differentiate between valid and invalid bounce addresses. This 460 document does not directly provide a mechanism for authenticating 461 RFC2821.MailFrom addresses at intermediate MTAs. The ability to 462 perform validation across the entire transfer sequence is possible if 463 a standardized public key scheme is defined. 465 The PRVS scheme described here provides minimal protection of the 466 RFC2821.Mailfrom against forgery, with detection possible at the 467 target (delivery) domain. The scheme does not attempt to protect 468 against a replay attack in which a valid, signed MailFrom is used but 469 the message contents are replaced. The same will be true for any 470 other BATV scheme that does not include some link with the message 471 data; however such protection is only reliable for the recipient of 472 the original message, because the integrity of the link will often be 473 broken when the original message data is mangled into the bounce. 475 There are two common forms of email address forgery: guessing (e.g. 476 attaching common s to a domain) and harvesting (e.g. from 477 the web or usenet). Cryptographic BATV schemes make guessing attacks 478 unfeasibly difficult; however these are relatively minor compared to 479 replay attacks, which deserve closer attention. 481 MailFrom addresses are not usually exposed in the places from which 482 addresses are usually harvested. Many mailing list systems archive 483 messages sent to a list on the web; however they usually replace the 484 original MailFrom address with one that refers to the mailing list 485 manager. So this case is generally not a problem, although there are 486 exceptions. There are other instances of systems that archive email 487 publicly without altering the MailFrom address, such as bug tracking 488 systems; these are a problem. 490 A proportion of forgeries are caused by mass mailing viruses. Unlike 491 spammers, these have access to private email stores and are therefore 492 more likely to be able to find and replay BATV addresses. For that 493 matter, they can generate MailFrom addresses that are entirely valid. 495 The PRVS scheme includes a modest protection against replay attacks, 496 by virtue of its using an expiry time, which prevents very old 497 addresses from being used by attackers. It does not prevent replay 498 attacks of young addresses. 500 7. References 502 7.1. References - Normative 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 7.2. References - Informative 509 [I-D.email-arch] 510 Crocker, D., "Internet Mail Architecture", May 2004. 512 Appendix A. Acknowledgements 514 This specification was greatly improved by the extensive 515 participation of John Leslie and Douglas Otis, in early design 516 discussions. 518 Appendix B. IANA Considerations 520 It may be desirable to establish a registry of BATV tagging schemes 521 and tag types. 523 Authors' Addresses 525 John Levine 526 Taughannock Networks 527 PO Box 727 528 Trumansburg, NY 14886 530 Email: standards@taugh.com 531 Dave Crocker 532 Brandenburg InternetWorking 533 675 Spruce Drive 534 Sunnyvale, CA 94086 535 USA 537 Phone: +1.408.246.8253 538 Email: dcrocker@bbiw.com 540 Sam Silberman 541 Openwave 543 Email: sam_silberman@openwave.com 545 Tony Finch 546 University of Cambridge 547 Cambridge CB2 1TN 548 UK 550 Email: dot@dotat.at 551 URI: http://dotat.at 553 Full Copyright Statement 555 Copyright (C) The IETF Trust (2008). 557 This document is subject to the rights, licenses and restrictions 558 contained in BCP 78, and except as set forth therein, the authors 559 retain all their rights. 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 564 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 565 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 566 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Intellectual Property 571 The IETF takes no position regarding the validity or scope of any 572 Intellectual Property Rights or other rights that might be claimed to 573 pertain to the implementation or use of the technology described in 574 this document or the extent to which any license under such rights 575 might or might not be available; nor does it represent that it has 576 made any independent effort to identify any such rights. Information 577 on the procedures with respect to rights in RFC documents can be 578 found in BCP 78 and BCP 79. 580 Copies of IPR disclosures made to the IETF Secretariat and any 581 assurances of licenses to be made available, or the result of an 582 attempt made to obtain a general license or permission for the use of 583 such proprietary rights by implementers or users of this 584 specification can be obtained from the IETF on-line IPR repository at 585 http://www.ietf.org/ipr. 587 The IETF invites any interested party to bring to its attention any 588 copyrights, patents or patent applications, or other proprietary 589 rights that may cover technology that may be required to implement 590 this standard. Please address the information to the IETF at 591 ietf-ipr@ietf.org.