idnits 2.17.1 draft-siemborski-rfc1734bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 238 instances of lines with control characters in the document. -- The abstract seems to indicate that this document obsoletes RFC1734, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 590 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Intended Category: Proposed Standard ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ABNF' is mentioned on line 280, but not defined ** Obsolete normative reference: RFC 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) -- No information found for draft-ietf-sasl-rfc2831bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIGEST-MD5' -- No information found for draft-ietf-sasl-rfc2222bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-sasl-saslprep- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLprep' -- No information found for draft-hoffman-rfc3454bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'StringPrep' -- No information found for draft-ietf-sasl-plain- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PLAIN' ** Obsolete normative reference: RFC 1734 (ref. 'POP3-AUTH') (Obsoleted by RFC 5034) -- Possible downref: Non-RFC (?) normative reference: ref. 'POP3-CODES' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Siemborski 3 INTERNET-DRAFT Carnegie Mellon University 4 Intended Category: Proposed Standard April, 2004 6 POP3 SASL Authentication Mechanism 8 10 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Task Force 15 (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Abstract 33 This document defines a profile of the Simple Authentication and 34 Security Layer (SASL) for the Post Office Protocol (POP3). This 35 extension allows a POP3 client to indicate an authentication 36 mechanism to the server, perform an authentication protocol 37 exchange, and optionally negotiate a security layer for subsequent 38 protocol interactions during this session. 40 In order to consolidate all of the authentication related 41 information for POP3 into a single document, this document obsoletes 42 RFC 1734 and RFC 3206, replacing them as a Proposed Standard. It 43 also updates information contained in Section 6.3 and Section 8 of 44 RFC 2449. 46 POP3 SASL Authentication Mechanism April, 2004 48 1. How to Read This Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 51 NOT", "RECOMMENDED", and "MAY" in this document are to be 52 interpreted as defined in "Key words for use in RFCs to Indicate 53 Requirement Levels" [KEYWORDS] 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. 58 2. Introduction 60 The [POP3] AUTH command [POP3-AUTH] in has suffered several problems 61 in its specification. The first is that it was very similar to a 62 [SASL] framework, but pre-dated the initial SASL specification. It 63 was therefore missing some key components, such as a way to list the 64 available authentication mechanisms. 66 Later, [POP3-EXT] attempted to remedy this situation by adding the 67 CAPA command and allowing an initial client response to the AUTH 68 command, however problems in the clarity of the specification of how 69 the initial client response was to be handled remained. 71 Additionally, there is yet another document, [POP3-CODES], that 72 provides additional response codes that are useful during 73 authentication. Together, this means creating a full POP3 AUTH 74 implementaiton requires an understanding of material in atleast six 75 different documents. 77 This document attempts to combine all of the POP3 SASL 78 authentication related details into a single document, in addition 79 to clarifying and updating the older specifications where 80 appropriate. 82 3. The SASL Capability 84 This section supercedes the definition of the SASL Capability in 85 section 6.3 of [POP3-EXT]. 87 CAPA tag: 88 SASL 90 Arguments: 91 Supported SASL Mechanisms 93 Standard Commands Affected 94 None 96 POP3 SASL Authentication Mechanism April, 2004 98 Announced states / possible differences: 99 both / no 101 Commands valid in states: 102 AUTHORIZATION 104 Specification Reference: 105 This Document, [SASL] 107 Discussion 108 The SASL capability permits the use of the AUTH command (as 109 defined in section 4 of this document) to begin a [SASL] 110 negotiation. The arguments to the SASL capability is a space- 111 separated list of SASL mechanisms which are supported. 113 If a server either does not support the CAPA command or does not 114 advertise the SASL capability, clients SHOULD NOT attempt the 115 AUTH command. If a client does attempt the AUTH command in such 116 a situation, it MUST NOT supply the client initial response 117 parameter (for backwards compatibility with [POP3-AUTH]). 119 Note that the list of available mechanisms MAY change after a 120 successful STLS command [POP3-TLS]. Additionally, 121 implementations MAY choose to omit the SASL capability after a 122 successful AUTH command has been completed. 124 Example 126 S: +OK pop.example.com BlurdyBlurp POP3 server ready 127 C: CAPA 128 S: +OK List of capabilities follows 129 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 130 S: STLS 131 S: IMPLEMENTATION BlurdyBlurp POP3 server 132 S: . 134 4. The AUTH Command 136 AUTH mechanism [initial-response] 138 Arguments: 139 mechanism: A string identifying a [SASL] authentication 140 mechanism. 142 initial-response: An optional initial client response. If 143 present, this response MUST be encoded as specified in Section 144 3 of [BASE64]. 146 POP3 SASL Authentication Mechanism April, 2004 148 Restrictions: 149 After an AUTH command has been successfully completed, no more 150 AUTH commands may be issued in the same session. After a 151 successful AUTH command completes, a server MUST reject any 152 further AUTH commands with a -ERR reply. 154 The AUTH command may only be given during the AUTHORIZATION 155 state. 157 Discussion: 158 The AUTH command initiates a [SASL] authentication exchange 159 between the client and the server. The client identifies the 160 SASL mechanism to use with the first parameter of the AUTH 161 command. If the server supports the requested authentication 162 mechanism, it performs the SASL exchange to authenticate the 163 user. Optionally, it also negotiates a security layer for 164 subsequent protocol interactions during this session. If the 165 requested authentication mechanism is not supported, the 166 server rejects the AUTH command with a -ERR reply. 168 The authentication protocol exchange consists of a series of 169 server challenges and client responses that are specific to 170 the chosen [SASL] mechanism. 172 A server challenge is sent as a line consisting of a "+" 173 character followed by a single space and a string encoded as 174 specified in Section 3 of [BASE64]. This challenge MUST NOT 175 contain any text other than the BASE64 encoded challenge. 177 A client response consists of a line containing a string 178 encoded as defined in Section 3 of [BASE64]. If the client 179 wishes to cancel the authentication exchange, it issues a line 180 with a single "*". If the server receives such a response, it 181 MUST reject the AUTH command by sending a -ERR reply. 183 The optional initial response argument to the AUTH command is 184 used to save a round trip when using authentication mechanisms 185 that support an initial client response. If the initial 186 response argument is omitted and the chosen mechanism requires 187 an initial client response, the server MUST proceed as defined 188 in section 5.1 of [SASL]. In POP3, a server challenge with no 189 data is defined as line with only a "+" followed by a single 190 space. It MUST NOT contain any other data. 192 For the purposes of the initial client response, the line 193 length limitation defined in [POP3-EXT] still applies. If a 194 client initial send would cause the AUTH command to exceed 195 this length, the client MUST NOT use the initial response 197 POP3 SASL Authentication Mechanism April, 2004 199 parameter (and instead proceed as defined in section 5.1 of 200 [SASL]). 202 If the client needs to send a zero-length initial response, 203 the client MUST transmit the response as a single equals sign 204 ("="). This indicates that the response is present, but 205 contains no data. 207 If the client uses an initial-response argument to the AUTH 208 command with a SASL mechanism that does not support an initial 209 client send, the server MUST reject the AUTH command with a 210 -ERR reply. 212 If the server cannot [BASE64] decode any client response, it 213 MUST reject the AUTH command with a -ERR reply. If the client 214 cannot BASE64 decode any of the server's challenges, it MUST 215 cancel the authentication using the "*" response. In 216 particular, servers and clients MUST reject (and not ignore) 217 any character not explicitly allowed by the BASE64 alphabet, 218 and MUST reject any sequence of BASE64 characters that 219 contains the pad character ('=') anywhere other than the end 220 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 222 Note that these [BASE64] strings (excepting the initial client 223 response) may be of arbitrarily length. Clients and servers 224 MUST be able to handle the maximum encoded size of challenges 225 and responses generated by their supported authentication 226 mechanisms. This requirement is independent of any line 227 length limitations the client or server may have in other 228 parts of its protocol implementation. 230 If the server is unable to authenticate the client, it MUST 231 reject the AUTH command with a -ERR reply. Should the client 232 successfully complete the exchange, the server issues a +OK 233 reply. Additionally, upon success, the POP3 session enters 234 the TRANSACTION state. 236 The authorization identity generated by this [SASL] exchange 237 is a simple username, and MUST use the [SASLprep] profile of 238 the [StringPrep] algorithm to prepare these names for 239 matching. If preparation of the authorization identity fails 240 or results in an empty string (unless it was transmitted as 241 the empty string), the server MUST fail the authentication. 243 If a security layer is negotiated during the SASL exchange, it 244 takes effect for the client on the octet immediately following 245 the CRLF that concludes the last response generated by the 246 client. For the server, it takes effect immediately following 248 POP3 SASL Authentication Mechanism April, 2004 250 the CRLF of its success reply. 252 When a security layer takes effect, the server MUST discard 253 any knowledge previously obtained from the client, which was 254 not obtained from the SASL negotiation itself. Likewise, the 255 client MUST discard any knowledge obtained from the server, 256 such as the list of available POP3 service extensions. After 257 a security layer is established, the server SHOULD NOT 258 advertise either the SASL or the STLS extension. 260 When both [TLS] and SASL security layers are in effect, the 261 TLS encoding MUST be applied after the SASL encoding, 262 regardless of the order in which the layers were negotiated. 264 The service name specified by this protocol's profile of SASL 265 is "pop". 267 If an AUTH command fails, the client may try another 268 authentication mechanism or present different credentials by 269 issuing another AUTH command (or by using one of the other 270 [POP3] authentication mechanisms). Likewise, the server MUST 271 behave as if the client had not issued the AUTH command. 273 To ensure interoperability, client and server implementations 274 of this extension MUST implement the [DIGEST-MD5] SASL 275 mechanism. 277 4.1. Formal Syntax 279 The following syntax specification uses the Augmented Backus-Naur 280 Form notation as specified in [ABNF]. 282 Except as noted otherwise, all alphabetic characters are case- 283 insensitive. The use of upper or lower case characters to define 284 token strings is for editorial clarity only. Implementations MUST 285 accept these strings in a case-insensitive fashion. 287 UPALPHA = %x41-5A ;; Uppercase: A-Z 289 LOALPHA = %x61-7A ;; Lowercase: a-z 291 ALPHA = UPALPHA / LOALPHA ;; case insensitive 293 DIGIT = %x30-39 ;; Digits 0-9 295 AUTH_CHAR = ALPHA / DIGIT / "-" / "_" 297 POP3 SASL Authentication Mechanism April, 2004 299 auth_type = 1*20AUTH_CHAR 301 auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] 302 *(CRLF [base64]) CRLF 304 base64 = base64_terminal / 305 ( 1*(4base64_CHAR) [base64_terminal] ) 307 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 308 ;; Case-sensitive 310 base64_terminal = (2base64_char "==") / (3base64_char "=") 312 continue_req = "+" SPACE [base64] CRLF 314 CR = %x0C ;; ASCII CR, carriage return 316 CRLF = CR LF 318 LF = %x0A ;; ASCII LF, line feed 320 SPACE = %x20 ;; ASCII SP, space 322 4.2. Examples 324 Here is an example of a client attempting AUTH PLAIN under TLS and 325 making use of the initial client response: 327 S: +OK pop.example.com BlurdyBlurp POP3 server ready 328 C: CAPA 329 S: +OK List of capabilities follows 330 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 331 S: STLS 332 S: IMPLEMENTATION BlurdyBlurp POP3 server 333 S: . 334 C: STLS 335 S: +OK Begin TLS negotiation now 336 ... TLS negotiation proceeds, further commands protected by TLS layer ... 337 C: CAPA 338 S: +OK List of capabilities follows 339 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 340 S: IMPLEMENTATION BlurdyBlurp POP3 server 341 S: . 342 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 343 S: +OK Maildrop locked and ready 345 Here is another client that is attempting AUTH PLAIN under a TLS 347 POP3 SASL Authentication Mechanism April, 2004 349 layer, this time without the initial response. Parts of the 350 negotiation before the TLS layer was established have been omitted: 352 ... TLS negotiation proceeds, further commands protected by TLS layer ... 353 C: CAPA 354 S: +OK List of capabilities follows 355 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 356 S: IMPLEMENTATION BlurdyBlurp POP3 server 357 S: . 358 C: AUTH PLAIN 359 (note that there is a space following the '+' on the following line) 360 S: + 361 C: dGVzdAB0ZXN0AHRlc3Q= 362 S: +OK Maildrop locked and ready 364 Here is an example using a mechanism which does not support an 365 initial client send, and includes server challenges: 367 S: +OK pop.example.com BlurdyBlurp POP3 server ready 368 C: CAPA 369 S: +OK List of capabilities follows 370 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 371 S: STLS 372 S: IMPLEMENTATION BlurdyBlurp POP3 server 373 S: . 374 C: AUTH KERBEROS_V4 375 S: + ezLUFA== 376 (the following lines are broken for editorial clarity only) 377 C: BAYFQU5EUkVXLkNNVS5FRFUAOCCXeMiVyFe9K6Nwne7+sPLgIoF9YQ5ePfxUsMlJAf 378 C7aoNySU8nrqS9m8JAddsUeuyc5HFXXovaKLrZNo2bTLH0Lyolwy0W9ryJDojbKmHy 379 zSMqFsGD4EL0 380 S: + Z74fTwDw7KQ= 381 C: vSAF7ha6qotK2UHUgKlsEA== 382 S: +OK Maildrop locked and ready 383 ... at this point a security layer has been established and additional 384 commands and responses proceed within it ... 386 5. Extended POP3 Response Codes 388 This section defines four POP3 response codes which can be used to 389 determine the reason for a failed login (provided that the server 390 advertises the RESP-CODES capability [POP3-EXT]). These definitions 391 supercede those in [POP3-EXT] and [POP3-CODES]. 393 It is RECOMMENDED that server applications use these codes when 394 possible to allow clients a straightforward, interoperable way to 395 determine the cause of an authentication failure (as opposed to 397 POP3 SASL Authentication Mechanism April, 2004 399 parsing error text). 401 5.1. The LOGIN-DELAY Response Code 403 This occurs on an -ERR response to an AUTH, USER (see note), PASS or 404 APOP command and indicates that the user has logged in recently and 405 will not be allowed to login again until the login delay period has 406 expired. 408 Please see the Security Considerations section of this document for 409 an important note about returning this code in response to the USER 410 command. 412 5.2. The IN-USE Response Code 414 This occurs on an -ERR response to an AUTH, APOP, or PASS command. 415 It indicates the authentication was successful, but the user's 416 maildrop is currently in use (probably by another POP3 client). 418 5.3. The AUTH Response Code 420 The AUTH response code informs the client that there is a problem 421 with the user's credentials. This might be an incorrect password, 422 an unknown user name, an expired account, an attempt to authenticate 423 in violation of policy (such as from an invalid location or during 424 an unauthorized time), or some other problem. 426 The AUTH response code is valid with an -ERR response to any 427 authentication command including AUTH, USER (see the note in the 428 Security Considerations section of this document), PASS, or APOP. 430 Servers which include the AUTH response code with any authentication 431 failure SHOULD support the CAPA command [POP3-EXT] and SHOULD 432 include the AUTH-RESP-CODE capability (defined in the next section) 433 in the CAPA response. AUTH-RESP-CODE assures the client that only 434 errors with the AUTH code are caused by credential problems. 436 5.3.1. The AUTH-RESP-CODE Capability 438 CAPA tag: 439 AUTH-RESP-CODE 441 Arguments: 442 none 444 Added commands: 445 none 447 POP3 SASL Authentication Mechanism April, 2004 449 Standard commands affected: 450 none 452 Announced states / possible differences: 453 both / no 455 Commands valid in states: 456 n/a 458 Specification reference: 459 this document 461 Discussion: 462 The AUTH-RESP-CODE capability indicates that the server includes 463 the AUTH response code with any authentication error caused by a 464 problem with the user's credentials. 466 5.4. The SYS Response Code 468 The SYS response code announces that a failure is due to a system 469 error, as opposed to the user's credentials or an external 470 condition. It is hierarchical, with two possible second-level 471 codes: TEMP and PERM. (Case is not significant at any level of the 472 hierarchy.) 474 SYS/TEMP indicates a problem which is likely to be temporary in 475 nature, and therefore there is no need to alarm the user, unless the 476 failure persists. Examples might include a central resource which 477 is currently locked or otherwise temporarily unavailable, 478 insufficient free disk or memory, etc. 480 SYS/PERM is used for problems which are unlikely to be resolved 481 without intervention. It is appropriate to alert the user and 482 suggest that the organization's support or assistance personnel be 483 contacted. Examples include corrupted mailboxes, system 484 configuration errors, etc. 486 The SYS response code is valid with an -ERR response to any command. 488 6. Security Considerations 490 Security issues are discussed throughout this memo. 492 Before the [SASL] negotiation has begun, any protocol interactions 493 are performed in the clear and may be modified by an active 494 attacker. For this reason, clients and servers MUST discard any 495 knowledge obtained prior to the start of the SASL negotiation upon 496 the establishment of a security layer. 498 POP3 SASL Authentication Mechanism April, 2004 500 Servers MAY implement a policy whereby the connection is dropped 501 after a number of failed authentication attempts. If they do so, 502 they SHOULD NOT drop the connection until atleast 3 attempts to 503 authenticate have failed. 505 Implementations MUST support a configuration where [SASL] mechanisms 506 that are vulnerable to passive eavesdropping attacks (such as 507 [PLAIN]) are not advertised or used without the presence of an 508 external security layer such as [TLS]. 510 Returning the LOGIN-DELAY or AUTH response codes to the USER command 511 avoids the work of authenticating the user but is likely to reveal 512 information to the client about the existence of the account in 513 question. Unless the server is operating in an environment where 514 user names are not secret (for example, many popular email clients 515 advertise the POP server and user name in an outgoing mail header), 516 or where server access is restricted, or the server can verify that 517 the connection is to the same user, the the server SHOULD NOT issue 518 this response code to the USER command. The server still saves the 519 cost of opening the maildrop, which in some environments is the most 520 expensive step. 522 7. IANA Considerations 524 This document requests that the IANA update the entry for the "pop" 525 SASL protocol name to point at this document. 527 This document requests that the IANA update the entry for the SASL 528 POP3 capability to be as defined in Section 3 of this document. 530 This document requests that the IANA update the entry for the LOGIN- 531 DELAY, IN-USE, AUTH, SYS/TEMP, and SYS/PERM POP3 response codes to 532 this document. 534 This document requests that the IANA update the entry for the AUTH- 535 RESP-CODE capability to be as defined in Section 5.3.1 of this 536 document. 538 8. Protocol Actions 540 [RFC Editor: Remove this section before publication] 542 This document obsoletes RFC 1734 and replaces it as a Proposed 543 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 544 moved to Historic (as RFC 1734 was the last document to have a 545 normative reference). 547 This document obsoletes RFC 3206 and replaces it as a Proposed 549 POP3 SASL Authentication Mechanism April, 2004 551 Standard. 553 It also updates information contained in Section 6.3 and Section 8 554 of RFC 2449. 556 9. Intellectual Property Rights 558 The IETF takes no position regarding the validity or scope of any 559 intellectual property or other rights that might be claimed to 560 pertain to the implementation or use of the technology described in 561 this document or the extent to which any license under such rights 562 might or might not be available; neither does it represent that it 563 has made any effort to identify any such rights. Information on the 564 IETF's procedures with respect to rights in standards-track and 565 standards-related documentation can be found in BCP-11. Copies of 566 claims of rights made available for publication and any assurances 567 of licenses to be made available, or the result of an attempt made 568 to obtain a general license or permission for the use of such 569 proprietary rights by implementors or users of this specification 570 can be obtained from the IETF Secretariat. 572 The IETF invites any interested party to bring to its attention any 573 copyrights, patents or patent applications, or other proprietary 574 rights which may cover technology that may be required to practice 575 this standard. Please address the information to the IETF Executive 576 Director. 578 10. Copyright 580 Copyright (C) The Internet Society (2003). All Rights Reserved. 582 This document and translations of it may be copied and furnished to 583 others, and derivative works that comment on or otherwise explain it 584 or assist in its implementation may be prepared, copied, published 585 and distributed, in whole or in part, without restriction of any 586 kind, provided that the above copyright notice and this paragraph 587 are included on all such copies and derivative works. However, this 588 document itself may not be modified in any way, such as by removing 589 the copyright notice or references to the Internet Society or other 590 Internet organizations, except as needed for the purpose of 591 developing Internet standards in which case the procedures for 592 copyrights defined in the Internet Standards process must be 593 followed, or as required to translate it into languages other than 594 English. 596 This document and the information contained herein is provided on an 597 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 598 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 600 POP3 SASL Authentication Mechanism April, 2004 602 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 603 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 604 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 606 POP3 SASL Authentication Mechanism April, 2004 608 11. References 610 The following documents contain normative definitions or 611 specifications that are necessary for correct understanding of this 612 protocol: 614 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 615 Encodings", RFC 3548, July 2003. 617 [DIGEST-MD5] 618 Leach, P., Melnikov, A., and Newman C., "Using Digest 619 Authentication as a SASL Mechanism", draft-ietf-sasl- 620 rfc2831bis-*.txt, a work in progress. 622 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997 625 [POP3] Myers, J. and Rose, M., "Post Office Protocol - Version 3", 626 STD 53, RFC 1939, May 1996. 628 [POP3-EXT] Gellens, R., Newman, C., and Lundblade, L., "POP3 Extension 629 Mechanism", RFC 2449, November 1998. 631 [POP3-TLS] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 632 June 1999. 634 [SASL] Melnikov, A., "Simple Authentication and Security Layer 635 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, a work in 636 progress. 638 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names 639 and passwords", draft-ietf-sasl-saslprep-*.txt, a work in 640 progress 642 [StringPrep] 643 Hoffman, P. and Blanchet, M., "Preparation of 644 Internationalized Strings ("stringprep")", draft-hoffman- 645 rfc3454bis-*.txt, a work in progress 647 The following references are for informational purposes only: 649 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", draft-ietf-sasl- 650 plain-*.txt, a work in progress. 652 [POP3-AUTH] Myers, J., "POP3 AUTHentication Command", RFC 1734, January 653 1994. 655 [POP3-CODES] 657 POP3 SASL Authentication Mechanism April, 2004 659 Gellens, R., "The SYS and AUTH POP Response Codes", RFC 660 3206, February 2002. 662 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 663 2246, January 1999. 665 12. Changes From RFC 1734, RFC 2449, and RFC 3206 667 1. The SASL-based semantics defined in RFC 2449 are now 668 normative for the AUTH extension. 670 2. Clarifications and examples of the proper behavior of 671 initial client response handling. 673 3. Minimum requirement of support for DIGEST-MD5. 675 4. Clarify ordering of TLS and SASL security layers. 677 5. Update references to newer versions of various 678 specifications. 680 6. Clarify that the mechanism list can change. 682 7. Add the use of the SASLprep profile for preparing 683 authorization identities. 685 8. General other editorial clarifications. 687 9. Consolidation of all applicable information into a 688 single document. 690 13. Author's Address: 692 Robert Siemborski 693 Carnegie Mellon, Andrew Systems Group 694 Cyert Hall 207 695 5000 Forbes Avenue 696 Pittsburgh, PA 15213 697 +1 412 268 7456 698 rjs3+@andrew.cmu.edu 700 14. Acknowledgments: 702 The author would like to acknowledge the contributions of John 703 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 704 contributors to RFC 1734, RFC 2554, and RFC 3206, on which this 705 document draws heavily. 707 POP3 SASL Authentication Mechanism April, 2004 709 The author would also like to thank Ken Murchison, Alexey Melnikov, 710 and Mark Crispin for the time they devoted to reviewing early drafts 711 of this document. 713 POP3 SASL Authentication Mechanism April, 2004 715 Table of Contents 717 1. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 718 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 719 3. The SASL Capability . . . . . . . . . . . . . . . . . . . . . . . 3 720 4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4 721 4.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 722 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 723 5. Extended POP3 Response Codes . . . . . . . . . . . . . . . . . . 9 724 5.1. The LOGIN-DELAY Response Code . . . . . . . . . . . . . . . . . 10 725 5.2. The IN-USE Response Code . . . . . . . . . . . . . . . . . . . 10 726 5.3. The AUTH Response Code . . . . . . . . . . . . . . . . . . . . 10 727 5.3.1. The AUTH-RESP-CODE Capability . . . . . . . . . . . . . . . . 10 728 5.4. The SYS Response Code . . . . . . . . . . . . . . . . . . . . . 11 729 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11 730 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 731 8. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . . . 12 732 9. Intellectual Property Rights . . . . . . . . . . . . . . . . . . 13 733 10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 734 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 735 12. Changes From RFC 1734, RFC 2449, and RFC 3206 . . . . . . . . . 16 736 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 737 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16