idnits 2.17.1 draft-siemborski-rfc1734bis-11.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. 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 obsoletes RFC1734, but the abstract doesn't seem to directly say this. It does mention RFC1734 though, so this could be OK. -- 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 IETF Trust 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 6311 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) -- Obsolete informational reference (is this intentional?): RFC 1734 (Obsoleted by RFC 5034) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-12) exists of draft-ietf-sasl-rfc2831bis-11 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 status: Proposed Standard Abhijit Menon-Sen 5 Obsoletes: RFC 1734 Oryx Mail Systems GmbH 6 Updates: RFC 2449 January 2007 7 Expires: August 26, 2007 9 POP3 SASL Authentication Mechanism 10 draft-siemborski-rfc1734bis-11.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in August 2007. 36 Abstract 38 This document defines a profile of the Simple Authentication and 39 Security Layer (SASL) for the Post Office Protocol (POP3). This 40 extension allows a POP3 client to indicate an authentication 41 mechanism to the server, perform an authentication protocol 42 exchange, and optionally negotiate a security layer for subsequent 43 protocol interactions during this session. 45 This document seeks to consolidate the information related to POP3 46 AUTH into a single document. To this end, this document obsoletes 48 POP3 SASL Authentication Mechanism January 2007 50 RFC 1734, replacing it as a Proposed Standard, and updates 51 information contained in Section 6.3 of RFC 2449. 53 1. Conventions Used in This Document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 In examples, "C:" and "S:" indicate lines sent by the client and 60 server respectively. 62 Formal syntax is defined by [RFC4234]. 64 2. Introduction 66 The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered 67 several problems in its specification. The first is that it was 68 very similar to a SASL framework defined by [RFC4422], but pre-dated 69 the initial SASL specification. It was therefore missing some key 70 components, such as a way to list the available authentication 71 mechanisms. 73 Later, [RFC2449] attempted to remedy this situation by adding the 74 CAPA command and allowing an initial client response with the AUTH 75 command, but problems remained in the clarity of the specification 76 of how the initial client response was to be handled. 78 Together, this means creating a full POP3 AUTH implementation 79 requires an understanding of material in at least five different 80 documents (and [RFC3206] provides additional response codes that are 81 useful during authentication). 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 January 2007 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 PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 139 S: STLS 140 S: IMPLEMENTATION BlurdyBlurp POP3 server 141 S: . 143 POP3 SASL Authentication Mechanism January 2007 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, as 155 defined in section 3 of [RFC4422]. If present, this response 156 MUST be encoded as Base64 (specified in Section 4 of 157 [RFC4648]), or consist only of the single character "=", which 158 represents an empty initial response. 160 Restrictions: 162 After an AUTH command has been successfully completed, no more 163 AUTH commands may be issued in the same session. After a 164 successful AUTH command completes, a server MUST reject any 165 further AUTH commands with an -ERR reply. 167 The AUTH command may only be given during the AUTHORIZATION 168 state. 170 Discussion: 172 The AUTH command initiates a SASL authentication exchange 173 between the client and the server. The client identifies the 174 SASL mechanism to use with the first parameter of the AUTH 175 command. If the server supports the requested authentication 176 mechanism, it performs the SASL exchange to authenticate the 177 user. Optionally, it also negotiates a security layer for 178 subsequent protocol interactions during this session. If the 179 requested authentication mechanism is not supported, the 180 server rejects the AUTH command with an -ERR reply. 182 The authentication protocol exchange consists of a series of 183 server challenges and client responses that are specific to 184 the chosen SASL mechanism. 186 A server challenge is sent as a line consisting of a "+" 187 character followed by a single space and a string encoded 188 using Base64 as specified in Section 4 of [RFC4648]. This 189 line MUST NOT contain any text other than the BASE64 encoded 190 challenge. 192 A client response consists of a line containing a string 194 POP3 SASL Authentication Mechanism January 2007 196 encoded as Base64. If the client wishes to cancel the 197 authentication exchange, it issues a line with a single "*". 198 If the server receives such a response, it MUST reject the 199 AUTH command by sending an -ERR reply. 201 The optional initial-response argument to the AUTH command is 202 used to save a round trip when using authentication mechanisms 203 that support an initial client response. If the initial 204 response argument is omitted and the chosen mechanism requires 205 an initial client response, the server MUST proceed by issuing 206 an empty challenge, as defined in section 3 of [RFC4422]. In 207 POP3, an empty server challenge is defined as line with only a 208 "+" followed by a single space. It MUST NOT contain any other 209 data. 211 For the purposes of the initial client response, the 255-octet 212 limit on the length of a single command, defined in section 4 213 of [RFC2449], still applies. If specifying an initial 214 response would cause the AUTH command to exceed this length, 215 the client MUST NOT use the initial-response parameter (and 216 must proceed instead by sending its initial response after an 217 empty challenge from the server, as in section 3 of 218 [RFC4422]). 220 If the client needs to send a zero-length initial response, it 221 MUST transmit the response as a single equals sign ("="). 222 This indicates that the response is present, but contains no 223 data. 225 If the client uses an initial-response argument to the AUTH 226 command with a SASL mechanism that does not support an initial 227 client send, the server MUST reject the AUTH command with an 228 -ERR reply. 230 If the server cannot Base64 decode a client response, it MUST 231 reject the AUTH command with an -ERR reply. If the client 232 cannot Base64 decode any of the server's challenges, it MUST 233 cancel the authentication using the "*" response. In 234 particular, servers and clients MUST reject (and not ignore) 235 any character not explicitly allowed by the Base64 alphabet, 236 and MUST reject any sequence of Base64 characters that 237 contains the pad character ('=') anywhere other than the end 238 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 240 Note that these Base64 strings (excepting the initial client 241 response) may be of arbitrarily length. Clients and servers 242 MUST be able to handle the maximum encoded size of challenges 243 and responses generated by their supported authentication 245 POP3 SASL Authentication Mechanism January 2007 247 mechanisms. This requirement is independent of any line 248 length limitations the client or server may have in other 249 parts of its protocol implementation. 251 If the server is unable to authenticate the client, it MUST 252 reject the AUTH command with an -ERR reply. Should the client 253 successfully complete the exchange, the server issues a +OK 254 reply. Additionally, upon success, the POP3 session enters 255 the TRANSACTION state. 257 The authorization identity generated by the SASL exchange is a 258 simple username, and SHOULD use the SASLprep profile (see 259 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to 260 prepare these names for matching. If preparation of the 261 authorization identity fails or results in an empty string 262 (unless it was transmitted as the empty string), the server 263 MUST fail the authentication. 265 If a security layer is negotiated during the SASL exchange, it 266 takes effect for the client on the octet immediately following 267 the CRLF that concludes the last response generated by the 268 client. For the server, it takes effect immediately following 269 the CRLF of its success reply. 271 When a security layer takes effect, the server MUST discard 272 any knowledge previously obtained from the client, which was 273 not obtained from the SASL negotiation itself. Likewise, the 274 client MUST discard any knowledge obtained from the server, 275 such as the list of available POP3 service extensions. 277 When both TLS (see [RFC4346]) and SASL security layers are in 278 effect, the TLS encoding MUST be applied after the SASL 279 encoding when sending data. (According to [RFC2595], STLS can 280 only be issued before AUTH in any case.) 282 Note that POP3 does not allow for additional data to be sent 283 with a message indicating a successful outcome (see section 284 3.6 of [RFC4422]). 286 The service name specified by this protocol's profile of SASL 287 is "pop". 289 If an AUTH command fails, the client may try another 290 authentication mechanism or present different credentials by 291 issuing another AUTH command (or by using one of the other 292 POP3 authentication mechanisms). Likewise, the server MUST 293 behave as if the client had not issued the AUTH command. 295 POP3 SASL Authentication Mechanism January 2007 297 To ensure interoperability, client and server implementations 298 of this extension MUST implement the PLAIN SASL mechanism, 299 defined in [RFC4616]. 301 A server implementation MUST implement a configuration in 302 which it does NOT permit any plaintext password mechanisms, 303 unless either the STLS command has been used to negotiate a 304 TLS session (see [RFC2595]), or some other mechanism that 305 protects the session from password snooping has been provided. 306 Server sites SHOULD NOT use any configuration which permits a 307 plaintext password mechanism without such a protection 308 mechanism against password snooping. Client and server 309 implementations SHOULD implement additional SASL mechanisms 310 that do not send plaintext passwords, such as the [DIGEST-MD5] 311 mechanism. 313 5. Formal Syntax 315 The following syntax specification uses the Augmented Backus-Naur 316 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and 317 DIGIT are imported from [RFC4234]. The sasl-mech rule is from 318 [RFC4422]. 320 Except as noted otherwise, all alphabetic characters are case- 321 insensitive. The use of upper or lower case characters to define 322 token strings is for editorial clarity only. Implementations MUST 323 accept these strings in a case-insensitive fashion. 325 auth-command = "AUTH" SP sasl-mech [SP initial-response] 326 *(CRLF [base64]) [CRLF cancel-response] CRLF 328 initial-response= base64 / "=" 330 cancel-response = "*" 332 base64 = base64-terminal / 333 ( 1*(4base64-CHAR) [base64-terminal] ) 335 base64-char = ALPHA / DIGIT / "+" / "/" 336 ;; Case-sensitive 338 base64-terminal = (2base64-char "==") / (3base64-char "=") 340 continue-req = "+" SP [base64] CRLF 342 Additionally, the ABNF specified in [RFC2449] is updated as follows: 344 POP3 SASL Authentication Mechanism January 2007 346 response =/ continue-req 348 6. Examples 350 Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) 351 under TLS and making use of the initial client response: 353 S: +OK pop.example.com BlurdyBlurp POP3 server ready 354 C: CAPA 355 S: +OK List of capabilities follows 356 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 357 S: STLS 358 S: IMPLEMENTATION BlurdyBlurp POP3 server 359 S: . 360 C: STLS 361 S: +OK Begin TLS negotiation now 362 (TLS negotiation proceeds, further commands protected by TLS 363 layer) 364 C: CAPA 365 S: +OK List of capabilities follows 366 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 367 S: IMPLEMENTATION BlurdyBlurp POP3 server 368 S: . 369 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 370 S: +OK Maildrop locked and ready 372 Here is another client that is attempting AUTH PLAIN under a TLS 373 layer, this time without the initial response. Parts of the 374 negotiation before the TLS layer was established have been omitted: 376 (TLS negotiation proceeds, further commands protected by TLS 377 layer) 378 C: CAPA 379 S: +OK List of capabilities follows 380 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 381 S: IMPLEMENTATION BlurdyBlurp POP3 server 382 S: . 383 C: AUTH PLAIN 384 (note that there is a space following the '+' on the 385 following line) 386 S: + 387 C: dGVzdAB0ZXN0AHRlc3Q= 388 S: +OK Maildrop locked and ready 390 Here is an example using a mechanism in which the exchange begins 391 with a server challenge (the long lines are broken for editorial 392 clarity only): 394 POP3 SASL Authentication Mechanism January 2007 396 S: +OK pop.example.com BlurdyBlurp POP3 server ready 397 C: CAPA 398 S: +OK List of capabilities follows 399 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 400 S: STLS 401 S: IMPLEMENTATION BlurdyBlurp POP3 server 402 S: . 403 C: AUTH DIGEST-MD5 404 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 405 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 406 cnNldD11dGYtOA== 407 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 408 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 409 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In 410 BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1 411 NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA== 412 S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA== 413 C: 414 S: +OK Maildrop locked and ready 416 7. Security Considerations 418 Security issues are discussed throughout this document. 420 8. IANA Considerations 422 The IANA is requested to refer to this RFC instead of [RFC1734] in 423 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 424 extension registry), and also in 425 http://www.iana.org/assignments/gssapi-service-names (the 426 GSSAPI/SASL service name registry). 428 9. Acknowledgments 430 The authors would like to acknowledge the contributions of John 431 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 432 contributors to RFC 1734 and RFC 2554, on which this document draws 433 heavily. 435 The authors would also like to thank Ken Murchison, Randall Gellens, 436 Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, 437 Frank Ellermann, and Philip Guenther for their reviews of this 438 document. 440 POP3 SASL Authentication Mechanism January 2007 442 10. Changes From RFC 1734, RFC 2449. 444 1. The SASL-based semantics defined in RFC 2449 are now normative 445 for the AUTH extension. 447 2. Clarifications and examples of the proper behavior of initial 448 client response handling. 450 3. Minimum requirement of support for TLS+PLAIN. 452 4. Clarify ordering of TLS and SASL security layers. 454 5. Update references to newer versions of various specifications. 456 6. Clarify that the mechanism list can change. 458 7. Add the use of the SASLprep profile for preparing authorization 459 identities. 461 8. General other editorial clarifications. 463 9. Consolidation of much applicable information into a single 464 document. 466 10. CR is no longer (incorrectly) defined here. 468 12. Explicitly mention that "=" means a zero-length initial 469 response. 471 13. Change MUST to SHOULD use SASLprep, because nobody does. 473 14. Clarify that the TLS encoding should be applied after any SASL 474 one. 476 15. Note that POP3 doesn't allow additional data to be sent with 477 +OK. 479 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule 480 instead of AUTH_CHAR. 482 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove 483 KERBEROS_V4. 485 18. Reword the reference to [RFC3206] to make it clearer that it is 486 not mandatory. 488 19. Define the initial-response by reference to SASL. 490 POP3 SASL Authentication Mechanism January 2007 492 20. Add continue-req to the response production from [RFC2449]. 494 21. Add initial-response and cancel-response productions to the 495 ABNF. 497 11. Normative References 499 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53, 500 RFC 1939, May 1996. 502 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism", 506 RFC 2449, November 1998. 508 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 509 June 1999. 511 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized 512 Strings ("stringprep")", RFC 3454, December 2002. 514 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names 515 and Passwords", RFC 4013, OpenLDAP Foundation, February 516 2005. 518 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 519 Specifications: ABNF", RFC 4234, Brandenburg 520 Internetworking, Demon Internet Ltd, October 2005. 522 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 523 Layer (SASL)", RFC 4422, June 2006. 525 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 526 Encodings", RFC 4648, October 2003. 528 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security 529 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation, 530 August 2006. 532 12. Informative References 534 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January 535 1994. 537 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206, 539 POP3 SASL Authentication Mechanism January 2007 541 February 2002. 543 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 544 Protocol, Version 1.1", RFC 4346, April 2006. 546 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 547 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode 548 Ltd., November 2006 550 13. Authors' Addresses 552 Robert Siemborski 553 Google, Inc. 554 1600 Ampitheatre Parkway 555 Mountain View, CA 94043 557 Phone: +1 650 623 6925 558 Email: robsiemb@google.com 560 Abhijit Menon-Sen 561 Oryx Mail Systems GmbH 563 Email: ams@oryx.com 565 POP3 SASL Authentication Mechanism January 2007 567 Protocol Actions 569 [RFC Editor: Remove this section before publication] 571 This document obsoletes RFC 1734 and replaces it as a Proposed 572 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 573 moved to Historic (as RFC 1734 was the last document to have a 574 normative reference). 576 It also updates information contained in Section 6.3 of RFC 2449. 578 POP3 SASL Authentication Mechanism January 2007 580 Intellectual Property Statement 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed 584 to pertain to the implementation or use of the technology described 585 in this document or the extent to which any license under such 586 rights might or might not be available; nor does it represent that 587 it has made any independent effort to identify any such rights. 588 Information on the procedures with respect to rights in RFC 589 documents can be found in BCP 78 and BCP 79. 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use 594 of such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository 596 at http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at ietf- 602 ipr@ietf.org. 604 Full Copyright Statement 606 Copyright (C) The IETF Trust (2007). This document is subject to 607 the rights, licenses and restrictions contained in BCP 78, and 608 except as set forth therein, the authors retain all their rights. 610 This document and the information contained herein are provided on 611 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 612 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 613 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 614 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 615 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 616 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 617 FOR A PARTICULAR PURPOSE. 619 Acknowledgment 621 Funding for the RFC Editor function is currently provided by the 622 Internet Society.