idnits 2.17.1 draft-siemborski-rfc1734bis-08.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 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. ** 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 (January 2007) is 6308 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 January 2007 8 POP3 SASL Authentication Mechanism 9 draft-siemborski-rfc1734bis-08.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 January 2007 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 Together, this means creating a full POP3 AUTH implementaiton 78 requires an understanding of material in at least five different 79 documents (and [RFC3206] provides additional response codes that are 80 useful during authentication). 82 This document attempts to combine the information in [RFC1734] and 83 [RFC2449] to simplify this situation. Additionally, it aims to 84 clarify and update the older specifications where appropriate. 86 3. The SASL Capability 88 This section supersedes the definition of the SASL Capability in 89 section 6.3 of [RFC2449]. 91 CAPA tag: 92 SASL 94 POP3 SASL Authentication Mechanism January 2007 96 Arguments: 97 Supported SASL Mechanisms 99 Added commands: 100 AUTH 102 Standard Commands Affected 103 None 105 Announced states / possible differences: 106 both / no 108 Commands valid in states: 109 AUTHORIZATION 111 Specification Reference: 112 This Document, [RFC4422] 114 Discussion 115 The SASL capability permits the use of the AUTH command (as 116 defined in section 4 of this document) to begin a SASL 117 negotiation (as defined in [RFC4422]). The argument to the SASL 118 capability is a space-separated list of SASL mechanisms which 119 are supported. 121 If a server either does not support the CAPA command or does not 122 advertise the SASL capability, clients SHOULD NOT attempt the 123 AUTH command. If a client does attempt the AUTH command in such 124 a situation, it MUST NOT supply the client initial response 125 parameter (for backwards compatibility with [RFC1734]). 127 Note that the list of available mechanisms MAY change after a 128 successful STLS command (see [RFC2595]). However, as required 129 by [RFC2449] implementations MUST continue to include the SASL 130 capability even after a successful AUTH command has been 131 completed (even though no further AUTH commands may be issued). 133 Example 134 S: +OK pop.example.com BlurdyBlurp POP3 server ready 135 C: CAPA 136 S: +OK List of capabilities follows 137 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 138 S: STLS 139 S: IMPLEMENTATION BlurdyBlurp POP3 server 140 S: . 142 POP3 SASL Authentication Mechanism January 2007 144 4. The AUTH Command 146 AUTH mechanism [initial-response] 148 Arguments: 150 mechanism: A string identifying a SASL authentication 151 mechanism. 153 initial-response: An optional initial client response, as 154 defined in section 3 of [RFC4422]. If present, this response 155 MUST be encoded as Base64 (specified in Section 4 of 156 [RFC4648]) or consist only of the single character "=", which 157 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 193 POP3 SASL Authentication Mechanism January 2007 195 encoded as Base64. If the client wishes to cancel the 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 must proceed instead by sending its initial 214 response after an empty challenge from the server, as in 215 section 3 of [RFC4422]). 217 If the client needs to send a zero-length initial response, 218 the client MUST transmit the response as a single equals sign 219 ("="). This indicates that the response is present, but 220 contains no data. 222 If the client uses an initial-response argument to the AUTH 223 command with a SASL mechanism that does not support an initial 224 client send, the server MUST reject the AUTH command with an 225 -ERR reply. 227 If the server cannot Base64 decode a client response, it MUST 228 reject the AUTH command with an -ERR reply. If the client 229 cannot Base64 decode any of the server's challenges, it MUST 230 cancel the authentication using the "*" response. In 231 particular, servers and clients MUST reject (and not ignore) 232 any character not explicitly allowed by the Base64 alphabet, 233 and MUST reject any sequence of Base64 characters that 234 contains the pad character ('=') anywhere other than the end 235 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 237 Note that these Base64 strings (excepting the initial client 238 response) may be of arbitrarily length. Clients and servers 239 MUST be able to handle the maximum encoded size of challenges 240 and responses generated by their supported authentication 241 mechanisms. This requirement is independent of any line 242 length limitations the client or server may have in other 244 POP3 SASL Authentication Mechanism January 2007 246 parts of its protocol implementation. 248 If the server is unable to authenticate the client, it MUST 249 reject the AUTH command with an -ERR reply. Should the client 250 successfully complete the exchange, the server issues a +OK 251 reply. Additionally, upon success, the POP3 session enters 252 the TRANSACTION state. 254 The authorization identity generated by the SASL exchange is a 255 simple username, and SHOULD use the SASLprep profile (see 256 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to 257 prepare these names for matching. If preparation of the 258 authorization identity fails or results in an empty string 259 (unless it was transmitted as the empty string), the server 260 MUST fail the authentication. 262 If a security layer is negotiated during the SASL exchange, it 263 takes effect for the client on the octet immediately following 264 the CRLF that concludes the last response generated by the 265 client. For the server, it takes effect immediately following 266 the CRLF of its success reply. 268 When a security layer takes effect, the server MUST discard 269 any knowledge previously obtained from the client, which was 270 not obtained from the SASL negotiation itself. Likewise, the 271 client MUST discard any knowledge obtained from the server, 272 such as the list of available POP3 service extensions. 274 When both TLS (see [RFC4346]) and SASL security layers are in 275 effect, the TLS encoding MUST be applied after the SASL 276 encoding when sending data. (According to [RFC2595], STLS can 277 only be issued before AUTH in any case.) 279 Note that POP3 does not allow for additional data to be sent 280 with a message indicating a successful outcome (see section 281 3.6 of [RFC4422]). 283 The service name specified by this protocol's profile of SASL 284 is "pop". 286 If an AUTH command fails, the client may try another 287 authentication mechanism or present different credentials by 288 issuing another AUTH command (or by using one of the other 289 POP3 authentication mechanisms). Likewise, the server MUST 290 behave as if the client had not issued the AUTH command. 292 To ensure interoperability, client and server implementations 293 of this extension MUST implement the [DIGEST-MD5] SASL 295 POP3 SASL Authentication Mechanism January 2007 297 mechanism. 299 5. Formal Syntax 301 The following syntax specification uses the Augmented Backus-Naur 302 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and 303 DIGIT are imported from [RFC4234]. The sasl-mech rule is from 304 [RFC4422]. 306 Except as noted otherwise, all alphabetic characters are case- 307 insensitive. The use of upper or lower case characters to define 308 token strings is for editorial clarity only. Implementations MUST 309 accept these strings in a case-insensitive fashion. 311 auth-command = "AUTH" SP sasl-mech [SP (base64 / "=")] *(CRLF 312 [base64]) CRLF 314 auth-resp = ("*" / base64) CRLF 316 base64 = base64-terminal / 317 ( 1*(4base64-CHAR) [base64-terminal] ) 319 base64-char = ALPHA / DIGIT / "+" / "/" 320 ;; Case-sensitive 322 base64-terminal = (2base64-char "==") / (3base64-char "=") 324 continue-req = "+" SP [base64] CRLF 326 Additionally, the ABNF specified in [RFC2449] is updated as follows: 328 challenge /= continue-req 330 6. Examples 332 Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) 333 under TLS and making use of the initial client response: 335 S: +OK pop.example.com BlurdyBlurp POP3 server ready 336 C: CAPA 337 S: +OK List of capabilities follows 338 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 339 S: STLS 340 S: IMPLEMENTATION BlurdyBlurp POP3 server 341 S: . 342 C: STLS 344 POP3 SASL Authentication Mechanism January 2007 346 S: +OK Begin TLS negotiation now 347 (TLS negotiation proceeds, further commands protected by TLS 348 layer) 349 C: CAPA 350 S: +OK List of capabilities follows 351 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 352 S: IMPLEMENTATION BlurdyBlurp POP3 server 353 S: . 354 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 355 S: +OK Maildrop locked and ready 357 Here is another client that is attempting AUTH PLAIN under a TLS 358 layer, this time without the initial response. Parts of the 359 negotiation before the TLS layer was established have been omitted: 361 (TLS negotiation proceeds, further commands protected by TLS 362 layer) 363 C: CAPA 364 S: +OK List of capabilities follows 365 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 366 S: IMPLEMENTATION BlurdyBlurp POP3 server 367 S: . 368 C: AUTH PLAIN 369 (note that there is a space following the '+' on the 370 following line) 371 S: + 372 C: dGVzdAB0ZXN0AHRlc3Q= 373 S: +OK Maildrop locked and ready 375 Here is an example using a mechanism in which the exchange begins 376 with a server challenge (the long lines are broken for editorial 377 clarity only): 379 S: +OK pop.example.com BlurdyBlurp POP3 server ready 380 C: CAPA 381 S: +OK List of capabilities follows 382 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 383 S: STLS 384 S: IMPLEMENTATION BlurdyBlurp POP3 server 385 S: . 386 C: AUTH DIGEST-MD5 387 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 388 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 389 cnNldD11dGYtOA== 390 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 391 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 392 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 393 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 395 POP3 SASL Authentication Mechanism January 2007 397 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= 398 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 399 C: 400 S: +OK Maildrop locked and ready 402 7. Security Considerations 404 Security issues are discussed throughout this document. 406 8. IANA Considerations 408 The IANA is requested to refer to this RFC instead of [RFC1734] in 409 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 410 extension registry). 412 9. Acknowledgments 414 The authors would like to acknowledge the contributions of John 415 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 416 contributors to RFC 1734 and RFC 2554, on which this document draws 417 heavily. 419 The authors would also like to thank Ken Murchison, Randall Gellens, 420 Alexey Melnikov, Mark Crispin, and Arnt Gulbrandsen for the time 421 they devoted to reviewing early drafts of this document. 423 10. Changes From RFC 1734, RFC 2449. 425 1. The SASL-based semantics defined in RFC 2449 are now normative 426 for the AUTH extension. 428 2. Clarifications and examples of the proper behavior of initial 429 client response handling. 431 3. Minimum requirement of support for DIGEST-MD5. 433 4. Clarify ordering of TLS and SASL security layers. 435 5. Update references to newer versions of various specifications. 437 6. Clarify that the mechanism list can change. 439 7. Add the use of the SASLprep profile for preparing authorization 440 identities. 442 POP3 SASL Authentication Mechanism January 2007 444 8. General other editorial clarifications. 446 9. Consolidation of much applicable information into a single 447 document. 449 10. CR is no longer (incorrectly) defined here. 451 11. Include M-T-I DIGEST-MD5 in the SASL capability response. 453 12. Explicitly mention that "=" means a zero-length initial 454 response. 456 13. Change MUST to SHOULD use SASLprep, because nobody does. 458 14. Clarify that the TLS encoding should be applied after any SASL 459 one. 461 15. Note that POP3 doesn't allow additional data to be sent with 462 +OK. 464 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule 465 instead of AUTH_CHAR. 467 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove 468 KERBEROS_V4. 470 18. Reword the reference to [RFC3206] to make it clearer that it is 471 not mandatory. 473 19. Define the initial-response by reference to SASL. 475 20. Fix the dangling reference to 2222/5.1. 477 11. Normative References 479 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53, 480 RFC 1939, May 1996. 482 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism", 486 RFC 2449, November 1998. 488 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 489 June 1999. 491 POP3 SASL Authentication Mechanism January 2007 493 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized 494 Strings ("stringprep")", RFC 3454, December 2002. 496 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names 497 and Passwords", RFC 4013, OpenLDAP Foundation, February 498 2005. 500 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 501 Specifications: ABNF", RFC 4234, Brandenburg 502 Internetworking, Demon Internet Ltd, October 2005. 504 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 505 Layer (SASL)", RFC 4422, June 2006. 507 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 508 Encodings", RFC 4648, October 2003. 510 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 511 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode 512 Ltd., November 2006 514 12. Informative References 516 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January 517 1994. 519 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206, 520 February 2002. 522 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 523 Protocol, Version 1.1", RFC 4346, April 2006. 525 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security 526 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation, 527 August 2006. 529 POP3 SASL Authentication Mechanism January 2007 531 13. Authors' Addresses 533 Robert Siemborski 534 Google, Inc. 535 1600 Ampitheatre Parkway 536 Mountain View, CA 94043 538 Phone: +1 650 623 6925 539 Email: robsiemb@google.com 541 Abhijit Menon-Sen 542 Oryx Mail Systems GmbH 544 Email: ams@oryx.com 546 POP3 SASL Authentication Mechanism January 2007 548 Protocol Actions 550 [RFC Editor: Remove this section before publication] 552 This document obsoletes RFC 1734 and replaces it as a Proposed 553 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 554 moved to Historic (as RFC 1734 was the last document to have a 555 normative reference). 557 It also updates information contained in Section 6.3 of RFC 2449. 559 POP3 SASL Authentication Mechanism January 2007 561 Intellectual Property Statement 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed 565 to pertain to the implementation or use of the technology described 566 in this document or the extent to which any license under such 567 rights might or might not be available; nor does it represent that 568 it has made any independent effort to identify any such rights. 569 Information on the procedures with respect to rights in RFC 570 documents can be found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use 575 of such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository 577 at http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at ietf- 583 ipr@ietf.org. 585 Full Copyright Statement 587 Copyright (C) The Internet Society (2007). This document is subject 588 to the rights, licenses and restrictions contained in BCP 78, and 589 except as set forth therein, the authors retain all their rights. 591 This document and the information contained herein are provided on 592 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 593 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 594 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 595 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.