idnits 2.17.1 draft-siemborski-rfc1734bis-04.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 472. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 223 instances of lines with control characters in the document. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 February, 2005', 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.) -- The document date () is 739384 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) == Missing Reference: 'ABNF' is mentioned on line 309, but not defined == Unused Reference: 'PLAIN' is defined on line 517, but no explicit reference was found in the text ** 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: 20 errors (**), 0 flaws (~~), 8 warnings (==), 15 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 February, 2005 5 Obsoletes: RFC 1734 Updates: RFC 2449 7 POP3 SASL Authentication Mechanism 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 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. Internet Drafts are draft documents valid for a maximum of 22 six months. Internet Drafts may be updated, replaced, or obsoleted 23 by other documents at any time. It is not appropriate to use 24 Internet Drafts as reference material or to cite them other than as 25 ``work in progress''. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the 34 RFC editor as a Standards Track RFC for the Internet Community. 35 Discussion and suggestions for improvement are requested. 36 Distribution of this draft is unlimited. 38 When published as an RFC this document will obsolete RFC 1734 and 39 update RFC 2449. 41 POP3 SASL Authentication Mechanism February, 2005 43 Abstract 45 This document defines a profile of the Simple Authentication and 46 Security Layer (SASL) for the Post Office Protocol (POP3). This 47 extension allows a POP3 client to indicate an authentication 48 mechanism to the server, perform an authentication protocol 49 exchange, and optionally negotiate a security layer for subsequent 50 protocol interactions during this session. 52 This document seeks to consolidate the information related to POP3 53 AUTH into a single document. To this end, this document obsoletes 54 RFC 1734, replacing it as a Proposed Standard and updates 55 information contained in Section 6.3 of RFC 2449. 57 POP3 SASL Authentication Mechanism February, 2005 59 Table of Contents 61 1. How to Read This Document . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The SASL Capability . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. Intellectual Property Rights . . . . . . . . . . . . . . . . . . 11 69 7. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Changes From RFC 1734, RFC 2449. . . . . . . . . . . . . . . . . 14 72 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 75 POP3 SASL Authentication Mechanism February, 2005 77 1. How to Read This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 80 NOT", "RECOMMENDED", and "MAY" in this document are to be 81 interpreted as defined in "Key words for use in RFCs to Indicate 82 Requirement Levels" [KEYWORDS] 84 In examples, "C:" and "S:" indicate lines sent by the client and 85 server respectively. 87 2. Introduction 89 The [POP3] AUTH command [POP3-AUTH] has suffered several problems in 90 its specification. The first is that it was very similar to a 91 [SASL] framework, but pre-dated the initial SASL specification. It 92 was therefore missing some key components, such as a way to list the 93 available authentication mechanisms. 95 Later, [POP3-EXT] attempted to remedy this situation by adding the 96 CAPA command and allowing an initial client response to the AUTH 97 command, however problems in the clarity of the specification of how 98 the initial client response was to be handled remained. 100 Additionally, there is yet another document, [POP3-CODES], that 101 provides additional response codes that are useful during 102 authentication. Together, this means creating a full POP3 AUTH 103 implementaiton requires an understanding of material in at least 104 five (and probably six) different documents. 106 This document attempts to combine the information in [POP3-AUTH] and 107 [POP3-EXT] to simplify this situation. Additionally, it aims to 108 clarify and update the older specifications where appropriate. 110 3. The SASL Capability 112 This section supercedes the definition of the SASL Capability in 113 section 6.3 of [POP3-EXT]. 115 CAPA tag: 116 SASL 118 Arguments: 119 Supported SASL Mechanisms 121 Added commands: 122 AUTH 124 Standard Commands Affected 126 POP3 SASL Authentication Mechanism February, 2005 128 None 130 Announced states / possible differences: 131 both / no 133 Commands valid in states: 134 AUTHORIZATION 136 Specification Reference: 137 This Document, [SASL] 139 Discussion 140 The SASL capability permits the use of the AUTH command (as 141 defined in section 4 of this document) to begin a [SASL] 142 negotiation. The argument to the SASL capability is a space- 143 separated list of SASL mechanisms which are supported. 145 If a server either does not support the CAPA command or does not 146 advertise the SASL capability, clients SHOULD NOT attempt the 147 AUTH command. If a client does attempt the AUTH command in such 148 a situation, it MUST NOT supply the client initial response 149 parameter (for backwards compatibility with [POP3-AUTH]). 151 Note that the list of available mechanisms MAY change after a 152 successful STLS command [POP3-TLS]. However, as required by 153 [POP3-EXT] implementations MUST continue to include the SASL 154 capability even after a successful AUTH command has been 155 completed (even though no further AUTH commands may be issued). 157 Example 159 S: +OK pop.example.com BlurdyBlurp POP3 server ready 160 C: CAPA 161 S: +OK List of capabilities follows 162 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 163 S: STLS 164 S: IMPLEMENTATION BlurdyBlurp POP3 server 165 S: . 167 4. The AUTH Command 169 AUTH mechanism [initial-response] 171 Arguments: 172 mechanism: A string identifying a [SASL] authentication 173 mechanism. 175 POP3 SASL Authentication Mechanism February, 2005 177 initial-response: An optional initial client response. If 178 present, this response MUST be encoded as specified in Section 179 3 of [BASE64]. 181 Restrictions: 182 After an AUTH command has been successfully completed, no more 183 AUTH commands may be issued in the same session. After a 184 successful AUTH command completes, a server MUST reject any 185 further AUTH commands with an -ERR reply. 187 The AUTH command may only be given during the AUTHORIZATION 188 state. 190 Discussion: 191 The AUTH command initiates a [SASL] authentication exchange 192 between the client and the server. The client identifies the 193 SASL mechanism to use with the first parameter of the AUTH 194 command. If the server supports the requested authentication 195 mechanism, it performs the SASL exchange to authenticate the 196 user. Optionally, it also negotiates a security layer for 197 subsequent protocol interactions during this session. If the 198 requested authentication mechanism is not supported, the 199 server rejects the AUTH command with an -ERR reply. 201 The authentication protocol exchange consists of a series of 202 server challenges and client responses that are specific to 203 the chosen [SASL] mechanism. 205 A server challenge is sent as a line consisting of a "+" 206 character followed by a single space and a string encoded as 207 specified in Section 3 of [BASE64]. This line MUST NOT 208 contain any text other than the BASE64 encoded challenge. 210 A client response consists of a line containing a string 211 encoded as defined in Section 3 of [BASE64]. If the client 212 wishes to cancel the authentication exchange, it issues a line 213 with a single "*". If the server receives such a response, it 214 MUST reject the AUTH command by sending an -ERR reply. 216 The optional initial response argument to the AUTH command is 217 used to save a round trip when using authentication mechanisms 218 that support an initial client response. If the initial 219 response argument is omitted and the chosen mechanism requires 220 an initial client response, the server MUST proceed as defined 221 in section 5.1 of [SASL]. In POP3, a server challenge with no 222 data is defined as line with only a "+" followed by a single 223 space. It MUST NOT contain any other data. 225 POP3 SASL Authentication Mechanism February, 2005 227 For the purposes of the initial client response, the line 228 length limitation defined in [POP3-EXT] still applies. If a 229 client initial send would cause the AUTH command to exceed 230 this length, the client MUST NOT use the initial response 231 parameter (and instead proceed as defined in section 5.1 of 232 [SASL]). 234 If the client needs to send a zero-length initial response, 235 the client MUST transmit the response as a single equals sign 236 ("="). This indicates that the response is present, but 237 contains no data. 239 If the client uses an initial-response argument to the AUTH 240 command with a SASL mechanism that does not support an initial 241 client send, the server MUST reject the AUTH command with an 242 -ERR reply. 244 If the server cannot [BASE64] decode a client response, it 245 MUST reject the AUTH command with an -ERR reply. If the 246 client cannot BASE64 decode a server challenge, it MUST cancel 247 the authentication using the "*" response. In particular, 248 servers and clients MUST reject (and not ignore) any character 249 not explicitly allowed by the BASE64 alphabet, and MUST reject 250 any sequence of BASE64 characters that contains the pad 251 character ('=') anywhere other than the end of the string 252 (e.g. "=AAA" and "AAA=BBB" are not allowed). 254 Note that these [BASE64] strings (excepting the initial client 255 response) may be of arbitrarily length. Clients and servers 256 MUST be able to handle the maximum encoded size of challenges 257 and responses generated by their supported authentication 258 mechanisms. This requirement is independent of any line 259 length limitations the client or server may have in other 260 parts of its protocol implementation. 262 If the server is unable to authenticate the client, it MUST 263 reject the AUTH command with an -ERR reply. Should the client 264 successfully complete the exchange, the server issues a +OK 265 reply. Additionally, upon success, the POP3 session enters 266 the TRANSACTION state. 268 The authorization identity generated by the [SASL] exchange is 269 a simple username, and MUST use the [SASLprep] profile of the 270 [StringPrep] algorithm to prepare these names for matching. 271 If preparation of the authorization identity fails or results 272 in an empty string (unless it was transmitted as the empty 273 string), the server MUST fail the authentication. 275 POP3 SASL Authentication Mechanism February, 2005 277 If a security layer is negotiated during the SASL exchange, it 278 takes effect for the client on the octet immediately following 279 the CRLF that concludes the last response generated by the 280 client. For the server, it takes effect immediately following 281 the CRLF of its success reply. 283 When a security layer takes effect, the server MUST discard 284 any knowledge previously obtained from the client, which was 285 not obtained from the SASL negotiation itself. Likewise, the 286 client MUST discard any knowledge obtained from the server, 287 such as the list of available POP3 service extensions. 289 When both [TLS] and SASL security layers are in effect, the 290 TLS encoding MUST be applied after the SASL encoding, 291 regardless of the order in which the layers were negotiated. 293 The service name specified by this protocol's profile of SASL 294 is "pop". 296 If an AUTH command fails, the client may try another 297 authentication mechanism or present different credentials by 298 issuing another AUTH command (or by using one of the other 299 [POP3] authentication mechanisms). Likewise, the server MUST 300 behave as if the client had not issued the AUTH command. 302 To ensure interoperability, client and server implementations 303 of this extension MUST implement the [DIGEST-MD5] SASL 304 mechanism. 306 4.1. Formal Syntax 308 The following syntax specification uses the Augmented Backus-Naur 309 Form notation as specified in [ABNF]. 311 Except as noted otherwise, all alphabetic characters are case- 312 insensitive. The use of upper or lower case characters to define 313 token strings is for editorial clarity only. Implementations MUST 314 accept these strings in a case-insensitive fashion. 316 UPALPHA = %x41-5A ;; Uppercase: A-Z 318 LOALPHA = %x61-7A ;; Lowercase: a-z 320 ALPHA = UPALPHA / LOALPHA ;; case insensitive 322 DIGIT = %x30-39 ;; Digits 0-9 324 POP3 SASL Authentication Mechanism February, 2005 326 AUTH_CHAR = ALPHA / DIGIT / "-" / "_" 328 auth_type = 1*20AUTH_CHAR 330 auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] 331 *(CRLF [base64]) CRLF 333 auth_resp = ("*" / base64) CRLF 335 base64 = base64_terminal / 336 ( 1*(4base64_CHAR) [base64_terminal] ) 338 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 339 ;; Case-sensitive 341 base64_terminal = (2base64_char "==") / (3base64_char "=") 343 continue_req = "+" SPACE [base64] CRLF 345 CR = %x0C ;; ASCII CR, carriage return 347 CRLF = CR LF 349 LF = %x0A ;; ASCII LF, line feed 351 SPACE = %x20 ;; ASCII SP, space 353 Additionally, the ABNF specified in [POP3-EXT] is updated as 354 follows: 356 response = greeting / single-line / capa-resp / multi-line / 357 continue_req 359 4.2. Examples 361 Here is an example of a client attempting AUTH PLAIN under TLS and 362 making use of the initial client response: 364 POP3 SASL Authentication Mechanism February, 2005 366 S: +OK pop.example.com BlurdyBlurp POP3 server ready 367 C: CAPA 368 S: +OK List of capabilities follows 369 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 370 S: STLS 371 S: IMPLEMENTATION BlurdyBlurp POP3 server 372 S: . 373 C: STLS 374 S: +OK Begin TLS negotiation now 375 ... TLS negotiation proceeds, further commands protected by TLS layer ... 376 C: CAPA 377 S: +OK List of capabilities follows 378 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 379 S: IMPLEMENTATION BlurdyBlurp POP3 server 380 S: . 381 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 382 S: +OK Maildrop locked and ready 384 Here is another client that is attempting AUTH PLAIN under a TLS 385 layer, this time without the initial response. Parts of the 386 negotiation before the TLS layer was established have been omitted: 388 ... TLS negotiation proceeds, further commands protected by TLS layer ... 389 C: CAPA 390 S: +OK List of capabilities follows 391 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 392 S: IMPLEMENTATION BlurdyBlurp POP3 server 393 S: . 394 C: AUTH PLAIN 395 (note that there is a space following the '+' on the following line) 396 S: + 397 C: dGVzdAB0ZXN0AHRlc3Q= 398 S: +OK Maildrop locked and ready 400 Here is an example using a mechanism which does not support an 401 initial client send, and includes server challenges: 403 POP3 SASL Authentication Mechanism February, 2005 405 S: +OK pop.example.com BlurdyBlurp POP3 server ready 406 C: CAPA 407 S: +OK List of capabilities follows 408 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 409 S: STLS 410 S: IMPLEMENTATION BlurdyBlurp POP3 server 411 S: . 412 C: AUTH KERBEROS_V4 413 S: + ezLUFA== 414 (the following lines are broken for editorial clarity only) 415 C: BAYFQU5EUkVXLkNNVS5FRFUAOCCXeMiVyFe9K6Nwne7+sPLgIoF9YQ5ePfxUsMlJAf 416 C7aoNySU8nrqS9m8JAddsUeuyc5HFXXovaKLrZNo2bTLH0Lyolwy0W9ryJDojbKmHy 417 zSMqFsGD4EL0 418 S: + Z74fTwDw7KQ= 419 C: vSAF7ha6qotK2UHUgKlsEA== 420 S: +OK Maildrop locked and ready 421 ... at this point a security layer has been established and additional 422 commands and responses proceed within it ... 424 5. Protocol Actions 426 [RFC Editor: Remove this section before publication] 428 This document obsoletes RFC 1734 and replaces it as a Proposed 429 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be 430 moved to Historic (as RFC 1734 was the last document to have a 431 normative reference). 433 It also updates information contained in Section 6.3 of RFC 2449. 435 6. Intellectual Property Rights 437 The IETF takes no position regarding the validity or scope of any 438 intellectual property or other rights that might be claimed to 439 pertain to the implementation or use of the technology described in 440 this document or the extent to which any license under such rights 441 might or might not be available; neither does it represent that it 442 has made any effort to identify any such rights. Information on the 443 IETF's procedures with respect to rights in standards-track and 444 standards-related documentation can be found in BCP-11. Copies of 445 claims of rights made available for publication and any assurances 446 of licenses to be made available, or the result of an attempt made 447 to obtain a general license or permission for the use of such 448 proprietary rights by implementors or users of this specification 449 can be obtained from the IETF Secretariat. 451 The IETF invites any interested party to bring to its attention any 453 POP3 SASL Authentication Mechanism February, 2005 455 copyrights, patents or patent applications, or other proprietary 456 rights which may cover technology that may be required to practice 457 this standard. Please address the information to the IETF Executive 458 Director. 460 7. Copyright 462 Copyright (C) The Internet Society (2005). This document is subject 463 to the rights, licenses and restrictions contained in BCP 78, and 464 except as set forth therein, the authors retain all their rights." 466 "This document and the information contained herein are provided on 467 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 468 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 469 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 470 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 471 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 POP3 SASL Authentication Mechanism February, 2005 476 8. References 478 The following documents contain normative definitions or 479 specifications that are necessary for correct understanding of this 480 protocol: 482 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 483 Encodings", RFC 3548, July 2003. 485 [DIGEST-MD5] 486 Leach, P., Melnikov, A., and Newman C., "Using Digest 487 Authentication as a SASL Mechanism", draft-ietf-sasl- 488 rfc2831bis-*.txt, a work in progress. 490 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997 493 [POP3] Myers, J. and Rose, M., "Post Office Protocol - Version 3", 494 STD 53, RFC 1939, May 1996. 496 [POP3-EXT] Gellens, R., Newman, C., and Lundblade, L., "POP3 Extension 497 Mechanism", RFC 2449, November 1998. 499 [POP3-TLS] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 500 June 1999. 502 [SASL] Melnikov, A., "Simple Authentication and Security Layer 503 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, a work in 504 progress. 506 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names 507 and passwords", draft-ietf-sasl-saslprep-*.txt, a work in 508 progress 510 [StringPrep] 511 Hoffman, P. and Blanchet, M., "Preparation of 512 Internationalized Strings ("stringprep")", draft-hoffman- 513 rfc3454bis-*.txt, a work in progress 515 The following references are for informational purposes only: 517 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", draft-ietf-sasl- 518 plain-*.txt, a work in progress. 520 [POP3-AUTH] Myers, J., "POP3 AUTHentication Command", RFC 1734, January 521 1994. 523 [POP3-CODES] 525 POP3 SASL Authentication Mechanism February, 2005 527 Gellens, R., "The SYS and AUTH POP Response Codes", RFC 528 3206, February 2002. 530 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 531 2246, January 1999. 533 9. Changes From RFC 1734, RFC 2449. 535 1. The SASL-based semantics defined in RFC 2449 are now 536 normative for the AUTH extension. 538 2. Clarifications and examples of the proper behavior of 539 initial client response handling. 541 3. Minimum requirement of support for DIGEST-MD5. 543 4. Clarify ordering of TLS and SASL security layers. 545 5. Update references to newer versions of various 546 specifications. 548 6. Clarify that the mechanism list can change. 550 7. Add the use of the SASLprep profile for preparing 551 authorization identities. 553 8. General other editorial clarifications. 555 9. Consolidation of much applicable information into a 556 single document. 558 10. Author's Address: 560 Robert Siemborski 561 Google, Inc. 562 1600 Ampitheatre Parkway 563 Mountain View, CA 94043 564 +1 650 623 6925 565 robsiemb@google.com 567 11. Acknowledgments: 569 The author would like to acknowledge the contributions of John 570 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other 571 contributors to RFC 1734 and RFC 2554, on which this document draws 572 heavily. 574 The author would also like to thank Ken Murchison, Randall Gellens, 576 POP3 SASL Authentication Mechanism February, 2005 578 Alexey Melnikov, and Mark Crispin for the time they devoted to 579 reviewing early drafts of this document.