idnits 2.17.1 draft-siemborski-rfc1734bis-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2449, but the abstract doesn't seem to directly say this. It does mention RFC2449 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2449, updated by this document, for RFC5378 checks: 1998-02-13) -- 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 (November 2006) is 6364 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 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-12) exists of draft-ietf-sasl-rfc2831bis-11 -- Obsolete informational reference (is this intentional?): RFC 1734 (Obsoleted by RFC 5034) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Siemborski 3 INTERNET-DRAFT Google, Inc. 4 Intended Category: Proposed Standard Abhijit Menon-Sen 5 Obsoletes: RFC 1734 Oryx Mail Systems GmbH 6 Updates: RFC 2449 November 2006 8 POP3 SASL Authentication Mechanism 9 draft-siemborski-rfc1734bis-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 30 Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire in May 2007. 35 Abstract 37 This document defines a profile of the Simple Authentication and 38 Security Layer (SASL) for the Post Office Protocol (POP3). This 39 extension allows a POP3 client to indicate an authentication 40 mechanism to the server, perform an authentication protocol 41 exchange, and optionally negotiate a security layer for subsequent 42 protocol interactions during this session. 44 This document seeks to consolidate the information related to POP3 45 AUTH into a single document. To this end, this document obsoletes 46 RFC 1734, replacing it as a Proposed Standard and updates 48 POP3 SASL Authentication Mechanism November 2006 50 information contained in Section 6.3 of RFC 2449. 52 1. Conventions Used in This Document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 In examples, "C:" and "S:" indicate lines sent by the client and 59 server respectively. 61 Formal syntax is defined by [RFC4234]. 63 2. Introduction 65 The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered 66 several problems in its specification. The first is that it was 67 very similar to a SASL framework defined by [RFC4422], but pre-dated 68 the initial SASL specification. It was therefore missing some key 69 components, such as a way to list the available authentication 70 mechanisms. 72 Later, [RFC2449] attempted to remedy this situation by adding the 73 CAPA command and allowing an initial client response to the AUTH 74 command, however problems in the clarity of the specification of how 75 the initial client response was to be handled remained. 77 Additionally, there is yet another document, [RFC3206], that 78 provides additional response codes that are useful during 79 authentication. Together, this means creating a full POP3 AUTH 80 implementaiton requires an understanding of material in at least 81 five (and probably six) different documents. 83 This document attempts to combine the information in [RFC1734] and 84 [RFC2449] to simplify this situation. Additionally, it aims to 85 clarify and update the older specifications where appropriate. 87 3. The SASL Capability 89 This section supersedes the definition of the SASL Capability in 90 section 6.3 of [RFC2449]. 92 CAPA tag: 93 SASL 95 POP3 SASL Authentication Mechanism November 2006 97 Arguments: 98 Supported SASL Mechanisms 100 Added commands: 101 AUTH 103 Standard Commands Affected 104 None 106 Announced states / possible differences: 107 both / no 109 Commands valid in states: 110 AUTHORIZATION 112 Specification Reference: 113 This Document, [RFC4422] 115 Discussion 116 The SASL capability permits the use of the AUTH command (as 117 defined in section 4 of this document) to begin a SASL 118 negotiation (as defined in [RFC4422]). The argument to the SASL 119 capability is a space-separated list of SASL mechanisms which 120 are supported. 122 If a server either does not support the CAPA command or does not 123 advertise the SASL capability, clients SHOULD NOT attempt the 124 AUTH command. If a client does attempt the AUTH command in such 125 a situation, it MUST NOT supply the client initial response 126 parameter (for backwards compatibility with [RFC1734]). 128 Note that the list of available mechanisms MAY change after a 129 successful STLS command (see [RFC2595]). However, as required 130 by [RFC2449] implementations MUST continue to include the SASL 131 capability even after a successful AUTH command has been 132 completed (even though no further AUTH commands may be issued). 134 Example 135 S: +OK pop.example.com BlurdyBlurp POP3 server ready 136 C: CAPA 137 S: +OK List of capabilities follows 138 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 139 S: STLS 140 S: IMPLEMENTATION BlurdyBlurp POP3 server 141 S: . 143 POP3 SASL Authentication Mechanism November 2006 145 4. The AUTH Command 147 AUTH mechanism [initial-response] 149 Arguments: 151 mechanism: A string identifying a SASL authentication 152 mechanism. 154 initial-response: An optional initial client response. If 155 present, this response MUST be encoded as Base64 (specified in 156 Section 4 of [RFC4648]) or consist only of the single 157 character "=", which represents an empty initial response. 159 Restrictions: 161 After an AUTH command has been successfully completed, no more 162 AUTH commands may be issued in the same session. After a 163 successful AUTH command completes, a server MUST reject any 164 further AUTH commands with an -ERR reply. 166 The AUTH command may only be given during the AUTHORIZATION 167 state. 169 Discussion: 171 The AUTH command initiates a SASL authentication exchange 172 between the client and the server. The client identifies the 173 SASL mechanism to use with the first parameter of the AUTH 174 command. If the server supports the requested authentication 175 mechanism, it performs the SASL exchange to authenticate the 176 user. Optionally, it also negotiates a security layer for 177 subsequent protocol interactions during this session. If the 178 requested authentication mechanism is not supported, the 179 server rejects the AUTH command with an -ERR reply. 181 The authentication protocol exchange consists of a series of 182 server challenges and client responses that are specific to 183 the chosen SASL mechanism. 185 A server challenge is sent as a line consisting of a "+" 186 character followed by a single space and a string encoded 187 using Base64 as specified in Section 4 of [RFC4648]. This 188 line MUST NOT contain any text other than the BASE64 encoded 189 challenge. 191 A client response consists of a line containing a string 192 encoded as Base64. If the client wishes to cancel the 194 POP3 SASL Authentication Mechanism November 2006 196 authentication exchange, it issues a line with a single "*". 197 If the server receives such a response, it MUST reject the 198 AUTH command by sending an -ERR reply. 200 The optional initial response argument to the AUTH command is 201 used to save a round trip when using authentication mechanisms 202 that support an initial client response. If the initial 203 response argument is omitted and the chosen mechanism requires 204 an initial client response, the server MUST proceed as defined 205 in section 3 of [RFC4422]. In POP3, a server challenge with 206 no data is defined as line with only a "+" followed by a 207 single space. It MUST NOT contain any other data. 209 For the purposes of the initial client response, the line 210 length limitation defined in [RFC2449] still applies. If a 211 client initial send would cause the AUTH command to exceed 212 this length, the client MUST NOT use the initial response 213 parameter (and instead proceed as defined in section 5.1 of 214 [RFC4422]). 216 If the client needs to send a zero-length initial response, 217 the client MUST transmit the response as a single equals sign 218 ("="). This indicates that the response is present, but 219 contains no data. 221 If the client uses an initial-response argument to the AUTH 222 command with a SASL mechanism that does not support an initial 223 client send, the server MUST reject the AUTH command with an 224 -ERR reply. 226 If the server cannot Base64 decode a client response, it MUST 227 reject the AUTH command with an -ERR reply. If the client 228 cannot Base64 decode any of the server's challenges, it MUST 229 cancel the authentication using the "*" response. In 230 particular, servers and clients MUST reject (and not ignore) 231 any character not explicitly allowed by the Base64 alphabet, 232 and MUST reject any sequence of Base64 characters that 233 contains the pad character ('=') anywhere other than the end 234 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 236 Note that these Base64 strings (excepting the initial client 237 response) may be of arbitrarily length. Clients and servers 238 MUST be able to handle the maximum encoded size of challenges 239 and responses generated by their supported authentication 240 mechanisms. This requirement is independent of any line 241 length limitations the client or server may have in other 242 parts of its protocol implementation. 244 POP3 SASL Authentication Mechanism November 2006 246 If the server is unable to authenticate the client, it MUST 247 reject the AUTH command with an -ERR reply. Should the client 248 successfully complete the exchange, the server issues a +OK 249 reply. Additionally, upon success, the POP3 session enters 250 the TRANSACTION state. 252 The authorization identity generated by the SASL exchange is a 253 simple username, and SHOULD use the SASLprep profile (see 254 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to 255 prepare these names for matching. If preparation of the 256 authorization identity fails or results in an empty string 257 (unless it was transmitted as the empty string), the server 258 MUST fail the authentication. 260 If a security layer is negotiated during the SASL exchange, it 261 takes effect for the client on the octet immediately following 262 the CRLF that concludes the last response generated by the 263 client. For the server, it takes effect immediately following 264 the CRLF of its success reply. 266 When a security layer takes effect, the server MUST discard 267 any knowledge previously obtained from the client, which was 268 not obtained from the SASL negotiation itself. Likewise, the 269 client MUST discard any knowledge obtained from the server, 270 such as the list of available POP3 service extensions. 272 When both TLS (see [RFC4346]) and SASL security layers are in 273 effect, the TLS encoding MUST be applied after the SASL 274 encoding when sending data. (According to [RFC2595], STLS can 275 only be issued before AUTH in any case.) 277 Note that POP3 does not allow for additional data to be sent 278 with a message indicating a successful outcome (see section 279 3.6 of [RFC4422]). 281 The service name specified by this protocol's profile of SASL 282 is "pop". 284 If an AUTH command fails, the client may try another 285 authentication mechanism or present different credentials by 286 issuing another AUTH command (or by using one of the other 287 POP3 authentication mechanisms). Likewise, the server MUST 288 behave as if the client had not issued the AUTH command. 290 To ensure interoperability, client and server implementations 291 of this extension MUST implement the [DIGEST-MD5] SASL 292 mechanism. 294 POP3 SASL Authentication Mechanism November 2006 296 5. Formal Syntax 298 The following syntax specification uses the Augmented Backus-Naur 299 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and 300 DIGIT are imported from [RFC4234]. The sasl-mech rule is from 301 [RFC4422]. 303 Except as noted otherwise, all alphabetic characters are case- 304 insensitive. The use of upper or lower case characters to define 305 token strings is for editorial clarity only. Implementations MUST 306 accept these strings in a case-insensitive fashion. 308 auth-command = "AUTH" SP sasl-mech [SP (base64 / "=")] *(CRLF 309 [base64]) CRLF 311 auth-resp = ("*" / base64) CRLF 313 base64 = base64-terminal / 314 ( 1*(4base64-CHAR) [base64-terminal] ) 316 base64-char = ALPHA / DIGIT / "+" / "/" 317 ;; Case-sensitive 319 base64-terminal = (2base64-char "==") / (3base64-char "=") 321 continue-req = "+" SP [base64] CRLF 323 Additionally, the ABNF specified in [RFC2449] is updated as follows: 325 challenge /= continue-req 327 6. Examples 329 Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) 330 under TLS and making use of the initial client response: 332 S: +OK pop.example.com BlurdyBlurp POP3 server ready 333 C: CAPA 334 S: +OK List of capabilities follows 335 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 336 S: STLS 337 S: IMPLEMENTATION BlurdyBlurp POP3 server 338 S: . 339 C: STLS 340 S: +OK Begin TLS negotiation now 341 (TLS negotiation proceeds, further commands protected by TLS 342 layer) 344 POP3 SASL Authentication Mechanism November 2006 346 C: CAPA 347 S: +OK List of capabilities follows 348 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 349 S: IMPLEMENTATION BlurdyBlurp POP3 server 350 S: . 351 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 352 S: +OK Maildrop locked and ready 354 Here is another client that is attempting AUTH PLAIN under a TLS 355 layer, this time without the initial response. Parts of the 356 negotiation before the TLS layer was established have been omitted: 358 (TLS negotiation proceeds, further commands protected by TLS 359 layer) 360 C: CAPA 361 S: +OK List of capabilities follows 362 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 363 S: IMPLEMENTATION BlurdyBlurp POP3 server 364 S: . 365 C: AUTH PLAIN 366 (note that there is a space following the '+' on the 367 following line) 368 S: + 369 C: dGVzdAB0ZXN0AHRlc3Q= 370 S: +OK Maildrop locked and ready 372 Here is an example using a mechanism in which the exchange begins 373 with a server challenge (the long lines are broken for editorial 374 clarity only): 376 S: +OK pop.example.com BlurdyBlurp POP3 server ready 377 C: CAPA 378 S: +OK List of capabilities follows 379 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 380 S: STLS 381 S: IMPLEMENTATION BlurdyBlurp POP3 server 382 S: . 383 C: AUTH DIGEST-MD5 384 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 385 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 386 cnNldD11dGYtOA== 387 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 388 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 389 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 390 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 391 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= 392 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 393 C: 395 POP3 SASL Authentication Mechanism November 2006 397 S: +OK Maildrop locked and ready 399 7. Security Considerations 401 Security issues are discussed throughout this document. 403 8. IANA Considerations 405 The IANA is requested to refer to this RFC instead of [RFC1734] in 406 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 407 extension registry). 409 9. Acknowledgments 411 The authors would like to acknowledge the contributions of John 412 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 413 contributors to RFC 1734 and RFC 2554, on which this document draws 414 heavily. 416 The authors would also like to thank Ken Murchison, Randall Gellens, 417 Alexey Melnikov, Mark Crispin, and Arnt Gulbrandsen for the time 418 they devoted to reviewing early drafts of this document. 420 10. Changes From RFC 1734, RFC 2449. 422 1. The SASL-based semantics defined in RFC 2449 are now normative 423 for the AUTH extension. 425 2. Clarifications and examples of the proper behavior of initial 426 client response handling. 428 3. Minimum requirement of support for DIGEST-MD5. 430 4. Clarify ordering of TLS and SASL security layers. 432 5. Update references to newer versions of various specifications. 434 6. Clarify that the mechanism list can change. 436 7. Add the use of the SASLprep profile for preparing authorization 437 identities. 439 8. General other editorial clarifications. 441 POP3 SASL Authentication Mechanism November 2006 443 9. Consolidation of much applicable information into a single 444 document. 446 10. CR is no longer (incorrectly) defined here. 448 11. Include M-T-I DIGEST-MD5 in the SASL capability response. 450 12. Explicitly mention that "=" means a zero-length initial 451 response. 453 13. Change MUST to SHOULD use SASLprep, because nobody does. 455 14. Clarify that the TLS encoding should be applied after any SASL 456 one. 458 15. Note that POP3 doesn't allow additional data to be sent with 459 +OK. 461 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule 462 instead of AUTH_CHAR. 464 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove 465 KERBEROS_V4. 467 11. Normative References 469 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53, 470 RFC 1939, May 1996. 472 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism", 476 RFC 2449, November 1998. 478 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 479 June 1999. 481 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized 482 Strings ( RFC 3454, December 2002. 484 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names 485 and Passwords", RFC 4013, OpenLDAP Foundation, February 486 2005. 488 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 489 Specifications: ABNF", RFC 4234, Brandenburg 491 POP3 SASL Authentication Mechanism November 2006 493 Internetworking, Demon Internet Ltd, October 2005. 495 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 496 Layer (SASL)", RFC 4422, June 2006. 498 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 499 Encodings", RFC 4648, October 2003. 501 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 502 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode 503 Ltd., November 2006 505 12. Informative References 507 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January 508 1994. 510 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206, 511 February 2002. 513 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 514 Protocol, Version 1.1", RFC 4346, April 2006. 516 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security 517 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation, 518 August 2006. 520 13. Authors' Addresses 522 Robert Siemborski 523 Google, Inc. 524 1600 Ampitheatre Parkway 525 Mountain View, CA 94043 527 Phone: +1 650 623 6925 528 Email: robsiemb@google.com 530 Abhijit Menon-Sen 531 Oryx Mail Systems GmbH 533 Email: ams@oryx.com 535 POP3 SASL Authentication Mechanism November 2006 537 Protocol Actions 539 [RFC Editor: Remove this section before publication] 541 This document obsoletes RFC 1734 and replaces it as a Proposed 542 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 543 moved to Historic (as RFC 1734 was the last document to have a 544 normative reference). 546 It also updates information contained in Section 6.3 of RFC 2449. 548 POP3 SASL Authentication Mechanism November 2006 550 Intellectual Property Statement 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed 554 to pertain to the implementation or use of the technology described 555 in this document or the extent to which any license under such 556 rights might or might not be available; nor does it represent that 557 it has made any independent effort to identify any such rights. 558 Information on the procedures with respect to rights in RFC 559 documents can be found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use 564 of such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository 566 at http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at ietf- 572 ipr@ietf.org. 574 Full Copyright Statement 576 Copyright (C) The Internet Society (2006). This document is subject 577 to the rights, licenses and restrictions contained in BCP 78, and 578 except as set forth therein, the authors retain all their rights. 580 This document and the information contained herein are provided on 581 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 582 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 583 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 584 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Acknowledgment 590 Funding for the RFC Editor function is currently provided by the 591 Internet Society.