idnits 2.17.1 draft-siemborski-rfc1734bis-10.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 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 594. ** 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 6305 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) Summary: 6 errors (**), 0 flaws (~~), 3 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-10.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 with the AUTH 74 command, but problems remained in the clarity of the specification 75 of how the initial client response was to be handled. 77 Together, this means creating a full POP3 AUTH implementation 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 PLAIN 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 by issuing 205 an empty challenge, as defined in section 3 of [RFC4422]. In 206 POP3, an empty server challenge is defined as line with only a 207 "+" followed by a single space. It MUST NOT contain any other 208 data. 210 For the purposes of the initial client response, the 255-octet 211 limit on the length of a single command, defined in section 4 212 of [RFC2449], still applies. If specifying an initial 213 response would cause the AUTH command to exceed this length, 214 the client MUST NOT use the initial-response parameter (and 215 must proceed instead by sending its initial response after an 216 empty challenge from the server, as in section 3 of 217 [RFC4422]). 219 If the client needs to send a zero-length initial response, it 220 MUST transmit the response as a single equals sign ("="). 221 This indicates that the response is present, but contains no 222 data. 224 If the client uses an initial-response argument to the AUTH 225 command with a SASL mechanism that does not support an initial 226 client send, the server MUST reject the AUTH command with an 227 -ERR reply. 229 If the server cannot Base64 decode a client response, it MUST 230 reject the AUTH command with an -ERR reply. If the client 231 cannot Base64 decode any of the server's challenges, it MUST 232 cancel the authentication using the "*" response. In 233 particular, servers and clients MUST reject (and not ignore) 234 any character not explicitly allowed by the Base64 alphabet, 235 and MUST reject any sequence of Base64 characters that 236 contains the pad character ('=') anywhere other than the end 237 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 239 Note that these Base64 strings (excepting the initial client 240 response) may be of arbitrarily length. Clients and servers 241 MUST be able to handle the maximum encoded size of challenges 242 and responses generated by their supported authentication 244 POP3 SASL Authentication Mechanism January 2007 246 mechanisms. This requirement is independent of any line 247 length limitations the client or server may have in other 248 parts of its protocol implementation. 250 If the server is unable to authenticate the client, it MUST 251 reject the AUTH command with an -ERR reply. Should the client 252 successfully complete the exchange, the server issues a +OK 253 reply. Additionally, upon success, the POP3 session enters 254 the TRANSACTION state. 256 The authorization identity generated by the SASL exchange is a 257 simple username, and SHOULD use the SASLprep profile (see 258 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to 259 prepare these names for matching. If preparation of the 260 authorization identity fails or results in an empty string 261 (unless it was transmitted as the empty string), the server 262 MUST fail the authentication. 264 If a security layer is negotiated during the SASL exchange, it 265 takes effect for the client on the octet immediately following 266 the CRLF that concludes the last response generated by the 267 client. For the server, it takes effect immediately following 268 the CRLF of its success reply. 270 When a security layer takes effect, the server MUST discard 271 any knowledge previously obtained from the client, which was 272 not obtained from the SASL negotiation itself. Likewise, the 273 client MUST discard any knowledge obtained from the server, 274 such as the list of available POP3 service extensions. 276 When both TLS (see [RFC4346]) and SASL security layers are in 277 effect, the TLS encoding MUST be applied after the SASL 278 encoding when sending data. (According to [RFC2595], STLS can 279 only be issued before AUTH in any case.) 281 Note that POP3 does not allow for additional data to be sent 282 with a message indicating a successful outcome (see section 283 3.6 of [RFC4422]). 285 The service name specified by this protocol's profile of SASL 286 is "pop". 288 If an AUTH command fails, the client may try another 289 authentication mechanism or present different credentials by 290 issuing another AUTH command (or by using one of the other 291 POP3 authentication mechanisms). Likewise, the server MUST 292 behave as if the client had not issued the AUTH command. 294 POP3 SASL Authentication Mechanism January 2007 296 To ensure interoperability, client and server implementations 297 of this extension MUST implement the PLAIN SASL mechanism, 298 defined in [RFC4616]. 300 A server implementation MUST implement a configuration in 301 which it does NOT permit any plaintext password mechanisms, 302 unless either the STLS command has been used to negotiate a 303 TLS session (see [RFC2595]), or some other mechanism that 304 protects the session from password snooping has been provided. 305 Server sites SHOULD NOT use any configuration which permits a 306 plaintext password mechanism without such a protection 307 mechanism against password snooping. Client and server 308 implementations SHOULD implement additional SASL mechanisms 309 that do not send plaintext passwords, such as the [DIGEST-MD5] 310 mechanism. 312 5. Formal Syntax 314 The following syntax specification uses the Augmented Backus-Naur 315 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and 316 DIGIT are imported from [RFC4234]. The sasl-mech rule is from 317 [RFC4422]. 319 Except as noted otherwise, all alphabetic characters are case- 320 insensitive. The use of upper or lower case characters to define 321 token strings is for editorial clarity only. Implementations MUST 322 accept these strings in a case-insensitive fashion. 324 auth-command = "AUTH" SP sasl-mech [SP (base64 / "=")] *(CRLF 325 [base64]) CRLF 327 auth-resp = ("*" / base64) CRLF 329 base64 = base64-terminal / 330 ( 1*(4base64-CHAR) [base64-terminal] ) 332 base64-char = ALPHA / DIGIT / "+" / "/" 333 ;; Case-sensitive 335 base64-terminal = (2base64-char "==") / (3base64-char "=") 337 continue-req = "+" SP [base64] CRLF 339 Additionally, the ABNF specified in [RFC2449] is updated as follows: 341 response =/ continue-req 343 POP3 SASL Authentication Mechanism January 2007 345 6. Examples 347 Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) 348 under TLS and making use of the initial client response: 350 S: +OK pop.example.com BlurdyBlurp POP3 server ready 351 C: CAPA 352 S: +OK List of capabilities follows 353 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 354 S: STLS 355 S: IMPLEMENTATION BlurdyBlurp POP3 server 356 S: . 357 C: STLS 358 S: +OK Begin TLS negotiation now 359 (TLS negotiation proceeds, further commands protected by TLS 360 layer) 361 C: CAPA 362 S: +OK List of capabilities follows 363 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 364 S: IMPLEMENTATION BlurdyBlurp POP3 server 365 S: . 366 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 367 S: +OK Maildrop locked and ready 369 Here is another client that is attempting AUTH PLAIN under a TLS 370 layer, this time without the initial response. Parts of the 371 negotiation before the TLS layer was established have been omitted: 373 (TLS negotiation proceeds, further commands protected by TLS 374 layer) 375 C: CAPA 376 S: +OK List of capabilities follows 377 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS 378 S: IMPLEMENTATION BlurdyBlurp POP3 server 379 S: . 380 C: AUTH PLAIN 381 (note that there is a space following the '+' on the 382 following line) 383 S: + 384 C: dGVzdAB0ZXN0AHRlc3Q= 385 S: +OK Maildrop locked and ready 387 Here is an example using a mechanism in which the exchange begins 388 with a server challenge (the long lines are broken for editorial 389 clarity only): 391 S: +OK pop.example.com BlurdyBlurp POP3 server ready 392 C: CAPA 394 POP3 SASL Authentication Mechanism January 2007 396 S: +OK List of capabilities follows 397 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS 398 S: STLS 399 S: IMPLEMENTATION BlurdyBlurp POP3 server 400 S: . 401 C: AUTH DIGEST-MD5 402 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 403 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 404 cnNldD11dGYtOA== 405 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 406 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 407 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In 408 BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1 409 NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA== 410 S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA== 411 C: 412 S: +OK Maildrop locked and ready 414 7. Security Considerations 416 Security issues are discussed throughout this document. 418 8. IANA Considerations 420 The IANA is requested to refer to this RFC instead of [RFC1734] in 421 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 422 extension registry). 424 9. Acknowledgments 426 The authors would like to acknowledge the contributions of John 427 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 428 contributors to RFC 1734 and RFC 2554, on which this document draws 429 heavily. 431 The authors would also like to thank Ken Murchison, Randall Gellens, 432 Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, and 433 Frank Ellermann for their reviews of this document. 435 10. Changes From RFC 1734, RFC 2449. 437 1. The SASL-based semantics defined in RFC 2449 are now normative 438 for the AUTH extension. 440 POP3 SASL Authentication Mechanism January 2007 442 2. Clarifications and examples of the proper behavior of initial 443 client response handling. 445 3. Minimum requirement of support for TLS+PLAIN. 447 4. Clarify ordering of TLS and SASL security layers. 449 5. Update references to newer versions of various specifications. 451 6. Clarify that the mechanism list can change. 453 7. Add the use of the SASLprep profile for preparing authorization 454 identities. 456 8. General other editorial clarifications. 458 9. Consolidation of much applicable information into a single 459 document. 461 10. CR is no longer (incorrectly) defined here. 463 12. Explicitly mention that "=" means a zero-length initial 464 response. 466 13. Change MUST to SHOULD use SASLprep, because nobody does. 468 14. Clarify that the TLS encoding should be applied after any SASL 469 one. 471 15. Note that POP3 doesn't allow additional data to be sent with 472 +OK. 474 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule 475 instead of AUTH_CHAR. 477 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove 478 KERBEROS_V4. 480 18. Reword the reference to [RFC3206] to make it clearer that it is 481 not mandatory. 483 19. Define the initial-response by reference to SASL. 485 20. Add continue-req to the response production from [RFC2449]. 487 POP3 SASL Authentication Mechanism January 2007 489 11. Normative References 491 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53, 492 RFC 1939, May 1996. 494 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism", 498 RFC 2449, November 1998. 500 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 501 June 1999. 503 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized 504 Strings ("stringprep")", RFC 3454, December 2002. 506 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names 507 and Passwords", RFC 4013, OpenLDAP Foundation, February 508 2005. 510 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 511 Specifications: ABNF", RFC 4234, Brandenburg 512 Internetworking, Demon Internet Ltd, October 2005. 514 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 515 Layer (SASL)", RFC 4422, June 2006. 517 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 518 Encodings", RFC 4648, October 2003. 520 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security 521 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation, 522 August 2006. 524 12. Informative References 526 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January 527 1994. 529 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206, 530 February 2002. 532 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 533 Protocol, Version 1.1", RFC 4346, April 2006. 535 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 537 POP3 SASL Authentication Mechanism January 2007 539 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode 540 Ltd., November 2006 542 13. Authors' Addresses 544 Robert Siemborski 545 Google, Inc. 546 1600 Ampitheatre Parkway 547 Mountain View, CA 94043 549 Phone: +1 650 623 6925 550 Email: robsiemb@google.com 552 Abhijit Menon-Sen 553 Oryx Mail Systems GmbH 555 Email: ams@oryx.com 557 POP3 SASL Authentication Mechanism January 2007 559 Protocol Actions 561 [RFC Editor: Remove this section before publication] 563 This document obsoletes RFC 1734 and replaces it as a Proposed 564 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 565 moved to Historic (as RFC 1734 was the last document to have a 566 normative reference). 568 It also updates information contained in Section 6.3 of RFC 2449. 570 POP3 SASL Authentication Mechanism January 2007 572 Intellectual Property Statement 574 The IETF takes no position regarding the validity or scope of any 575 Intellectual Property Rights or other rights that might be claimed 576 to pertain to the implementation or use of the technology described 577 in this document or the extent to which any license under such 578 rights might or might not be available; nor does it represent that 579 it has made any independent effort to identify any such rights. 580 Information on the procedures with respect to rights in RFC 581 documents can be found in BCP 78 and BCP 79. 583 Copies of IPR disclosures made to the IETF Secretariat and any 584 assurances of licenses to be made available, or the result of an 585 attempt made to obtain a general license or permission for the use 586 of such proprietary rights by implementers or users of this 587 specification can be obtained from the IETF on-line IPR repository 588 at http://www.ietf.org/ipr. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights that may cover technology that may be required to implement 593 this standard. Please address the information to the IETF at ietf- 594 ipr@ietf.org. 596 Full Copyright Statement 598 Copyright (C) The Internet Society (2007). This document is subject 599 to the rights, licenses and restrictions contained in BCP 78, and 600 except as set forth therein, the authors retain all their rights. 602 This document and the information contained herein are provided on 603 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 604 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 605 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 606 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Acknowledgment 612 Funding for the RFC Editor function is currently provided by the 613 Internet Society.