3 Network Working Group Robert Siemborski
4 INTERNET-DRAFT Carnegie Mellon University
5 Intended Category: Proposed Standard December, 2003
8 POP3 SASL Authentication Mechanism
10 <draft-siemborski-rfc1734bis-02.txt>
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 Internet-Drafts are working documents of the Internet Task Force
18 (IETF), its areas, and its working groups. Note that other groups
19 may also distribute working documents as Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six
22 months and may be updated, replaced, or obsoleted by other documents
23 at any time. It is inappropriate to use Internet Drafts as
24 reference material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 Distribution of this memo is unlimited.
36 This document defines a profile of the Simple Authentication and
37 Security Layer (SASL) for the Post Office Protocol (POP3). This
38 extension allows a POP3 client to indicate an authentication
39 mechanism to the server, perform an authentication protocol
40 exchange, and optionally negotiate a security layer for subsequent
41 protocol interactions during this session.
43 In order to consolidate all of the authentication related
44 information for POP3 into a single document, this document obsoletes
45 RFC 1734 and RFC 3206, replacing them as a Proposed Standard. It
46 also updates information contained in Section 6.3 and Section 8 of
54 Siemborski Expires May, 2004 [Page 1]
60 POP3 SASL Authentication Mechanism December, 2003
66 1. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3
67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 3. The SASL Capability . . . . . . . . . . . . . . . . . . . . . . . 3
69 4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4
70 4.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
71 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
72 5. Extended POP3 Response Codes . . . . . . . . . . . . . . . . . . 10
73 5.1. The LOGIN-DELAY Response Code . . . . . . . . . . . . . . . . . 10
74 5.2. The IN-USE Response Code . . . . . . . . . . . . . . . . . . . 10
75 5.3. The AUTH Response Code . . . . . . . . . . . . . . . . . . . . 11
76 5.3.1. The AUTH-RESP-CODE Capability . . . . . . . . . . . . . . . . 11
77 5.4. The SYS Response Code . . . . . . . . . . . . . . . . . . . . . 12
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 12
79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 13
80 8. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . . . 13
81 9. Intellectual Property Rights . . . . . . . . . . . . . . . . . . 13
82 10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
84 12. Changes From RFC 1734, RFC 2449, and RFC 3206 . . . . . . . . . 16
85 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
86 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16
114 Siemborski Expires May, 2004 [Page 2]
120 POP3 SASL Authentication Mechanism December, 2003
123 1. How to Read This Document
125 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
126 NOT", "RECOMMENDED", and "MAY" in this document are to be
127 interpreted as defined in "Key words for use in RFCs to Indicate
128 Requirement Levels" [KEYWORDS]
130 In examples, "C:" and "S:" indicate lines sent by the client and
135 The [POP3] AUTH command [POP3-AUTH] in has suffered several problems
136 in its specification. The first is that it was very similar to a
137 [SASL] framework, but pre-dated the initial SASL specification. It
138 was therefore missing some key components, such as a way to list the
139 available authentication mechanisms.
141 Later, [POP3-EXT] attempted to remedy this situation by adding the
142 CAPA command and allowing an initial client response to the AUTH
143 command, however problems in the clarity of the specification of how
144 the initial client response was to be handled remained.
146 Additionally, there is yet another document, [POP3-CODES], that
147 provides additional response codes that are useful during
148 authentication. Together, this means creating a full POP3 AUTH
149 implementaiton requires an understanding of material in atleast six
152 This document attempts to combine all of the POP3 SASL
153 authentication related details into a single document, in addition
154 to clarifying and updating the older specifications where
157 3. The SASL Capability
159 This section supercedes the definition of the SASL Capability in
160 section 6.3 of [POP3-EXT].
166 Supported SASL Mechanisms
168 Standard Commands Affected
174 Siemborski Expires May, 2004 [Page 3]
180 POP3 SASL Authentication Mechanism December, 2003
183 Announced states / possible differences:
186 Commands valid in states:
189 Specification Reference:
190 This Document, [SASL]
193 The SASL capability permits the use of the AUTH command (as
194 defined in section 4 of this document) to begin a [SASL]
195 negotiation. The arguments to the SASL capability is a space-
196 separated list of SASL mechanisms which are supported.
198 If a server either does not support the CAPA command or does not
199 advertise the SASL capability, clients SHOULD NOT attempt the
200 AUTH command. If a client does attempt the AUTH command in such
201 a situation, it MUST NOT supply the client initial response
202 parameter (for backwards compatibility with [POP3-AUTH]).
204 Note that the list of available mechanisms MAY change after a
205 successful STLS command [POP3-TLS]. Additionally,
206 implementations MAY choose to omit the SASL capability after a
207 successful AUTH command has been completed.
211 S: +OK pop.example.com BlurdyBlurp POP3 server ready
213 S: +OK List of capabilities follows
214 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS
216 S: IMPLEMENTATION BlurdyBlurp POP3 server
222 AUTH mechanism [initial-response]
225 mechanism: A string identifying a [SASL] authentication
228 initial-response: An optional initial client response. If
229 present, this response MUST be encoded as specified in Section
234 Siemborski Expires May, 2004 [Page 4]
240 POP3 SASL Authentication Mechanism December, 2003
244 After an AUTH command has been successfully completed, no more
245 AUTH commands may be issued in the same session. After a
246 successful AUTH command completes, a server MUST reject any
247 further AUTH commands with a -ERR reply.
249 The AUTH command may only be given during the AUTHORIZATION
253 The AUTH command initiates a [SASL] authentication exchange
254 between the client and the server. The client identifies the
255 SASL mechanism to use with the first parameter of the AUTH
256 command. If the server supports the requested authentication
257 mechanism, it performs the SASL exchange to authenticate the
258 user. Optionally, it also negotiates a security layer for
259 subsequent protocol interactions during this session. If the
260 requested authentication mechanism is not supported, the
261 server rejects the AUTH command with a -ERR reply.
263 The authentication protocol exchange consists of a series of
264 server challenges and client responses that are specific to
265 the chosen [SASL] mechanism.
267 A server challenge is sent as a line consisting of a "+"
268 character followed by a single space and a string encoded as
269 specified in Section 3 of [BASE64]. This challenge MUST NOT
270 contain any text other than the BASE64 encoded challenge.
272 A client response consists of a line containing a string
273 encoded as defined in Section 3 of [BASE64]. If the client
274 wishes to cancel the authentication exchange, it issues a line
275 with a single "*". If the server receives such a response, it
276 MUST reject the AUTH command by sending a -ERR reply.
278 The optional initial response argument to the AUTH command is
279 used to save a round trip when using authentication mechanisms
280 that support an initial client response. If the initial
281 response argument is omitted and the chosen mechanism requires
282 an initial client response, the server MUST proceed as defined
283 in section 5.1 of [SASL]. In POP3, a server challenge with no
284 data is defined as line with only a "+" followed by a single
285 space. It MUST NOT contain any other data.
287 For the purposes of the initial client response, the line
288 length limitation defined in [POP3-EXT] still applies. If a
289 client initial send would cause the AUTH command to exceed
290 this length, the client MUST NOT use the initial response
294 Siemborski Expires May, 2004 [Page 5]
300 POP3 SASL Authentication Mechanism December, 2003
303 parameter (and instead proceed as defined in section 5.1 of
306 If the client needs to send a zero-length initial response,
307 the client MUST transmit the response as a single equals sign
308 ("="). This indicates that the response is present, but
311 If the client uses an initial-response argument to the AUTH
312 command with a SASL mechanism that does not support an initial
313 client send, the server MUST reject the AUTH command with a
316 If the server cannot [BASE64] decode any client response, it
317 MUST reject the AUTH command with a -ERR reply. If the client
318 cannot BASE64 decode any of the server's challenges, it MUST
319 cancel the authentication using the "*" response. In
320 particular, servers and clients MUST reject (and not ignore)
321 any character not explicitly allowed by the BASE64 alphabet,
322 and MUST reject any sequence of BASE64 characters that
323 contains the pad character ('=') anywhere other than the end
324 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed).
326 Note that these [BASE64] strings (excepting the initial client
327 response) may be of arbitrarily length. Clients and servers
328 MUST be able to handle the maximum encoded size of challenges
329 and responses generated by their supported authentication
330 mechanisms. This requirement is independent of any line
331 length limitations the client or server may have in other
332 parts of its protocol implementation.
334 If the server is unable to authenticate the client, it MUST
335 reject the AUTH command with a -ERR reply. Should the client
336 successfully complete the exchange, the server issues a +OK
337 reply. Additionally, upon success, the POP3 session enters
338 the TRANSACTION state.
340 The authorization identity generated by this [SASL] exchange
341 is a simple username, and MUST use the [SASLprep] profile of
342 the [StringPrep] algorithm to prepare these names for
343 matching. If preparation of the authorization identity fails
344 or results in an empty string (unless it was transmitted as
345 the empty string), the server MUST fail the authentication.
347 If a security layer is negotiated during the SASL exchange, it
348 takes effect for the client on the octet immediately following
349 the CRLF that concludes the last response generated by the
350 client. For the server, it takes effect immediately following
354 Siemborski Expires May, 2004 [Page 6]
360 POP3 SASL Authentication Mechanism December, 2003
363 the CRLF of its success reply.
365 When a security layer takes effect, the server MUST discard
366 any knowledge previously obtained from the client, which was
367 not obtained from the SASL negotiation itself. Likewise, the
368 client MUST discard any knowledge obtained from the server,
369 such as the list of available POP3 service extensions. After
370 a security layer is established, the server SHOULD NOT
371 advertise either the SASL or the STLS extension.
373 When both [TLS] and SASL security layers are in effect, the
374 TLS encoding MUST be applied after the SASL encoding,
375 regardless of the order in which the layers were negotiated.
377 The service name specified by this protocol's profile of SASL
380 If an AUTH command fails, the client may try another
381 authentication mechanism or present different credentials by
382 issuing another AUTH command (or by using one of the other
383 [POP3] authentication mechanisms). Likewise, the server MUST
384 behave as if the client had not issued the AUTH command.
386 To ensure interoperability, client and server implementations
387 of this extension MUST implement the [DIGEST-MD5] SASL
391 <<Open Issue: Is this the best choice of mandatory-to-implement
392 mechanism for POP3? IMAP arrived at a choice that equates
393 to STLS+PLAIN, and therefore is likely to be implemented in
394 clients already. Is there really a compelling reason to
395 choose something else?
397 DIGEST-MD5 has been suggested as a choice that does
398 not require servers to implement TLS, which is desireable from a
399 code complexity/deployability standpoint. However, DIGEST-MD5 also
400 requires the storage of (essentially) plaintext equivilent passwords
401 which also may not be acceptable in some enviornments.>>
406 The following syntax specification uses the Augmented Backus-Naur
407 Form notation as specified in [ABNF].
409 Except as noted otherwise, all alphabetic characters are case-
410 insensitive. The use of upper or lower case characters to define
414 Siemborski Expires May, 2004 [Page 7]
420 POP3 SASL Authentication Mechanism December, 2003
423 token strings is for editorial clarity only. Implementations MUST
424 accept these strings in a case-insensitive fashion.
427 UPALPHA = %x41-5A ;; Uppercase: A-Z
429 LOALPHA = %x61-7A ;; Lowercase: a-z
431 ALPHA = UPALPHA / LOALPHA ;; case insensitive
433 DIGIT = %x30-39 ;; Digits 0-9
435 AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
437 auth_type = 1*20AUTH_CHAR
439 auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
440 *(CRLF [base64]) CRLF
442 base64 = base64_terminal /
443 ( 1*(4base64_CHAR) [base64_terminal] )
445 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
448 base64_terminal = (2base64_char "==") / (3base64_char "=")
450 continue_req = "+" SPACE [base64] CRLF
452 CR = %x0C ;; ASCII CR, carriage return
456 LF = %x0A ;; ASCII LF, line feed
458 SPACE = %x20 ;; ASCII SP, space
463 Here is an example of a client attempting AUTH PLAIN under TLS and
464 making use of the initial client response:
474 Siemborski Expires May, 2004 [Page 8]
480 POP3 SASL Authentication Mechanism December, 2003
483 S: +OK pop.example.com BlurdyBlurp POP3 server ready
485 S: +OK List of capabilities follows
486 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS
488 S: IMPLEMENTATION BlurdyBlurp POP3 server
491 S: +OK Begin TLS negotiation now
492 ... TLS negotiation proceeds, further commands protected by TLS layer ...
494 S: +OK List of capabilities follows
495 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS
496 S: IMPLEMENTATION BlurdyBlurp POP3 server
498 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
499 S: +OK Maildrop locked and ready
501 Here is another client that is attempting AUTH PLAIN under a TLS
502 layer, this time without the initial response. Parts of the
503 negotiation before the TLS layer was established have been omitted:
505 ... TLS negotiation proceeds, further commands protected by TLS layer ...
507 S: +OK List of capabilities follows
508 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS
509 S: IMPLEMENTATION BlurdyBlurp POP3 server
512 (note that there is a space following the '+' on the following line)
514 C: dGVzdAB0ZXN0AHRlc3Q=
515 S: +OK Maildrop locked and ready
517 Here is an example using a mechanism which does not support an
518 initial client send, and includes server challenges:
534 Siemborski Expires May, 2004 [Page 9]
540 POP3 SASL Authentication Mechanism December, 2003
543 S: +OK pop.example.com BlurdyBlurp POP3 server ready
545 S: +OK List of capabilities follows
546 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS
548 S: IMPLEMENTATION BlurdyBlurp POP3 server
552 (the following lines are broken for editorial clarity only)
553 C: BAYFQU5EUkVXLkNNVS5FRFUAOCCXeMiVyFe9K6Nwne7+sPLgIoF9YQ5ePfxUsMlJAf
554 C7aoNySU8nrqS9m8JAddsUeuyc5HFXXovaKLrZNo2bTLH0Lyolwy0W9ryJDojbKmHy
557 C: vSAF7ha6qotK2UHUgKlsEA==
558 S: +OK Maildrop locked and ready
559 ... at this point a security layer has been established and additional
560 commands and responses proceed within it ...
563 5. Extended POP3 Response Codes
565 This section defines four POP3 response codes which can be used to
566 determine the reason for a failed login (provided that the server
567 advertises the RESP-CODES capability [POP3-EXT]). These definitions
568 supercede those in [POP3-EXT] and [POP3-CODES].
570 It is RECOMMENDED that server applications use these codes when
571 possible to allow clients a straightforward, interoperable way to
572 determine the cause of an authentication failure (as opposed to
575 5.1. The LOGIN-DELAY Response Code
577 This occurs on an -ERR response to an AUTH, USER (see note), PASS or
578 APOP command and indicates that the user has logged in recently and
579 will not be allowed to login again until the login delay period has
582 Please see the Security Considerations section of this document for
583 an important note about returning this code in response to the USER
586 5.2. The IN-USE Response Code
588 This occurs on an -ERR response to an AUTH, APOP, or PASS command.
589 It indicates the authentication was successful, but the user's
590 maildrop is currently in use (probably by another POP3 client).
594 Siemborski Expires May, 2004 [Page 10]
600 POP3 SASL Authentication Mechanism December, 2003
603 5.3. The AUTH Response Code
605 The AUTH response code informs the client that there is a problem
606 with the user's credentials. This might be an incorrect password,
607 an unknown user name, an expired account, an attempt to authenticate
608 in violation of policy (such as from an invalid location or during
609 an unauthorized time), or some other problem.
611 The AUTH response code is valid with an -ERR response to any
612 authentication command including AUTH, USER (see the note in the
613 Security Considerations section of this document), PASS, or APOP.
615 Servers which include the AUTH response code with any authentication
616 failure SHOULD support the CAPA command [POP3-EXT] and SHOULD
617 include the AUTH-RESP-CODE capability (defined in the next section)
618 in the CAPA response. AUTH-RESP-CODE assures the client that only
619 errors with the AUTH code are caused by credential problems.
621 5.3.1. The AUTH-RESP-CODE Capability
632 Standard commands affected:
635 Announced states / possible differences:
638 Commands valid in states:
641 Specification reference:
645 The AUTH-RESP-CODE capability indicates that the server includes
646 the AUTH response code with any authentication error caused by a
647 problem with the user's credentials.
654 Siemborski Expires May, 2004 [Page 11]
660 POP3 SASL Authentication Mechanism December, 2003
663 5.4. The SYS Response Code
665 The SYS response code announces that a failure is due to a system
666 error, as opposed to the user's credentials or an external
667 condition. It is hierarchical, with two possible second-level
668 codes: TEMP and PERM. (Case is not significant at any level of the
671 SYS/TEMP indicates a problem which is likely to be temporary in
672 nature, and therefore there is no need to alarm the user, unless the
673 failure persists. Examples might include a central resource which
674 is currently locked or otherwise temporarily unavailable,
675 insufficient free disk or memory, etc.
677 SYS/PERM is used for problems which are unlikely to be resolved
678 without intervention. It is appropriate to alert the user and
679 suggest that the organization's support or assistance personnel be
680 contacted. Examples include corrupted mailboxes, system
681 configuration errors, etc.
683 The SYS response code is valid with an -ERR response to any command.
685 6. Security Considerations
687 Security issues are discussed throughout this memo.
689 Before the [SASL] negotiation has begun, any protocol interactions
690 are performed in the clear and may be modified by an active
691 attacker. For this reason, clients and servers MUST discard any
692 knowledge obtained prior to the start of the SASL negotiation upon
693 the establishment of a security layer.
695 Servers MAY implement a policy whereby the connection is dropped
696 after a number of failed authentication attempts. If they do so,
697 they SHOULD NOT drop the connection until atleast 3 attempts to
698 authenticate have failed.
700 Implementations MUST support a configuration where [SASL] mechanisms
701 that are vulnerable to passive eavesdropping attacks (such as
702 [PLAIN]) are not advertised or used without the presence of an
703 external security layer such as [TLS].
705 Returning the LOGIN-DELAY or AUTH response codes to the USER command
706 avoids the work of authenticating the user but is likely to reveal
707 information to the client about the existence of the account in
708 question. Unless the server is operating in an environment where
709 user names are not secret (for example, many popular email clients
710 advertise the POP server and user name in an outgoing mail header),
714 Siemborski Expires May, 2004 [Page 12]
720 POP3 SASL Authentication Mechanism December, 2003
723 or where server access is restricted, or the server can verify that
724 the connection is to the same user, the the server SHOULD NOT issue
725 this response code to the USER command. The server still saves the
726 cost of opening the maildrop, which in some environments is the most
729 7. IANA Considerations
731 This document requests that the IANA update the entry for the "pop"
732 SASL protocol name to point at this document.
734 This document requests that the IANA update the entry for the SASL
735 POP3 capability to be as defined in Section 3 of this document.
737 This document requests that the IANA update the entry for the LOGIN-
738 DELAY, IN-USE, AUTH, SYS/TEMP, and SYS/PERM POP3 response codes to
741 This document requests that the IANA update the entry for the AUTH-
742 RESP-CODE capability to be as defined in Section 5.3.1 of this
747 [RFC Editor: Remove this section before publication]
749 This document obsoletes RFC 1734 and replaces it as a Proposed
750 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be
751 moved to Historic (as RFC 1734 was the last document to have a
752 normative reference).
754 This document obsoletes RFC 3206 and replaces it as a Proposed
757 It also updates information contained in Section 6.3 and Section 8
760 9. Intellectual Property Rights
762 The IETF takes no position regarding the validity or scope of any
763 intellectual property or other rights that might be claimed to
764 pertain to the implementation or use of the technology described in
765 this document or the extent to which any license under such rights
766 might or might not be available; neither does it represent that it
767 has made any effort to identify any such rights. Information on the
768 IETF's procedures with respect to rights in standards-track and
769 standards-related documentation can be found in BCP-11. Copies of
770 claims of rights made available for publication and any assurances
774 Siemborski Expires May, 2004 [Page 13]
780 POP3 SASL Authentication Mechanism December, 2003
783 of licenses to be made available, or the result of an attempt made
784 to obtain a general license or permission for the use of such
785 proprietary rights by implementors or users of this specification
786 can be obtained from the IETF Secretariat.
788 The IETF invites any interested party to bring to its attention any
789 copyrights, patents or patent applications, or other proprietary
790 rights which may cover technology that may be required to practice
791 this standard. Please address the information to the IETF Executive
796 Copyright (C) The Internet Society (2003). All Rights Reserved.
798 This document and translations of it may be copied and furnished to
799 others, and derivative works that comment on or otherwise explain it
800 or assist in its implementation may be prepared, copied, published
801 and distributed, in whole or in part, without restriction of any
802 kind, provided that the above copyright notice and this paragraph
803 are included on all such copies and derivative works. However, this
804 document itself may not be modified in any way, such as by removing
805 the copyright notice or references to the Internet Society or other
806 Internet organizations, except as needed for the purpose of
807 developing Internet standards in which case the procedures for
808 copyrights defined in the Internet Standards process must be
809 followed, or as required to translate it into languages other than
812 This document and the information contained herein is provided on an
813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
834 Siemborski Expires May, 2004 [Page 14]
840 POP3 SASL Authentication Mechanism December, 2003
845 The following documents contain normative definitions or
846 specifications that are necessary for correct understanding of this
849 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
850 Encodings", RFC 3548, July 2003.
853 Leach, P., Melnikov, A., and Newman C., "Using Digest
854 Authentication as a SASL Mechanism", draft-ietf-sasl-
855 rfc2831bis-*.txt, a work in progress.
857 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
858 Requirement Levels", BCP 14, RFC 2119, March 1997
860 [POP3] Myers, J. and Rose, M., "Post Office Protocol - Version 3",
861 STD 53, RFC 1939, May 1996.
863 [POP3-EXT] Gellens, R., Newman, C., and Lundblade, L., "POP3 Extension
864 Mechanism", RFC 2449, November 1998.
866 [POP3-TLS] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC 2595,
869 [SASL] Melnikov, A., "Simple Authentication and Security Layer
870 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, a work in
873 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names
874 and passwords", draft-ietf-sasl-saslprep-*.txt, a work in
878 Hoffman, P. and Blanchet, M., "Preparation of
879 Internationalized Strings ("stringprep")", draft-hoffman-
880 rfc3454bis-*.txt, a work in progress
882 The following references are for informational purposes only:
884 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", draft-ietf-sasl-
885 plain-*.txt, a work in progress.
887 [POP3-AUTH] Myers, J., "POP3 AUTHentication Command", RFC 1734, January
894 Siemborski Expires May, 2004 [Page 15]
900 POP3 SASL Authentication Mechanism December, 2003
903 Gellens, R., "The SYS and AUTH POP Response Codes", RFC
906 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
909 12. Changes From RFC 1734, RFC 2449, and RFC 3206
911 1. The SASL-based semantics defined in RFC 2449 are now
912 normative for the AUTH extension.
914 2. Clarifications and examples of the proper behavior of
915 initial client response handling.
917 3. Minimum requirement of support for DIGEST-MD5.
919 4. Clarify ordering of TLS and SASL security layers.
921 5. Update references to newer versions of various
924 6. Clarify that the mechanism list can change.
926 7. Add the use of the SASLprep profile for preparing
927 authorization identities.
929 8. General other editorial clarifications.
931 9. Consolidation of all applicable information into a
934 13. Author's Address:
937 Carnegie Mellon, Andrew Systems Group
946 The author would like to acknowledge the contributions of John
947 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other
948 contributors to RFC 1734, RFC 2554, and RFC 3206, on which this
949 document draws heavily.
954 Siemborski Expires May, 2004 [Page 16]
960 POP3 SASL Authentication Mechanism December, 2003
963 The author would also like to thank Ken Murchison, Alexey Melnikov,
964 and Mark Crispin for the time they devoted to reviewing early drafts
1014 Siemborski Expires May, 2004 [Page 17]