7 Network Working Group Robert Siemborski
8 INTERNET-DRAFT Google, Inc.
9 Intended status: Proposed Standard Abhijit Menon-Sen
10 Obsoletes: RFC 1734 Oryx Mail Systems GmbH
11 Updates: RFC 2449 January 2007
12 Expires: August 26, 2007
15 POP3 SASL Authentication Mechanism
16 draft-siemborski-rfc1734bis-11.txt
21 By submitting this Internet-Draft, each author represents that any
22 applicable patent or other IPR claims of which he or she is aware
23 have been or will be disclosed, and any of which he or she becomes
24 aware will be disclosed, in accordance with Section 6 of BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
31 Internet-Drafts are draft documents valid for a maximum of six
32 months and may be updated, replaced, or obsoleted by other documents
33 at any time. It is inappropriate to use Internet-Drafts as
34 reference material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
38 Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire in August 2007.
46 This document defines a profile of the Simple Authentication and
47 Security Layer (SASL) for the Post Office Protocol (POP3). This
48 extension allows a POP3 client to indicate an authentication
49 mechanism to the server, perform an authentication protocol
50 exchange, and optionally negotiate a security layer for subsequent
51 protocol interactions during this session.
53 This document seeks to consolidate the information related to POP3
54 AUTH into a single document. To this end, this document obsoletes
58 Siemborski and Menon-Sen Expires August 2007 [Page 1]
60 POP3 SASL Authentication Mechanism January 2007
63 RFC 1734, replacing it as a Proposed Standard, and updates
64 information contained in Section 6.3 of RFC 2449.
67 1. Conventions Used in This Document
69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
71 document are to be interpreted as described in [RFC2119].
73 In examples, "C:" and "S:" indicate lines sent by the client and
76 Formal syntax is defined by [RFC4234].
81 The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
82 several problems in its specification. The first is that it was
83 very similar to a SASL framework defined by [RFC4422], but pre-dated
84 the initial SASL specification. It was therefore missing some key
85 components, such as a way to list the available authentication
88 Later, [RFC2449] attempted to remedy this situation by adding the
89 CAPA command and allowing an initial client response with the AUTH
90 command, but problems remained in the clarity of the specification
91 of how the initial client response was to be handled.
93 Together, this means creating a full POP3 AUTH implementation
94 requires an understanding of material in at least five different
95 documents (and [RFC3206] provides additional response codes that are
96 useful during authentication).
98 This document attempts to combine the information in [RFC1734] and
99 [RFC2449] to simplify this situation. Additionally, it aims to
100 clarify and update the older specifications where appropriate.
103 3. The SASL Capability
105 This section supersedes the definition of the SASL Capability in
106 section 6.3 of [RFC2449].
114 Siemborski and Menon-Sen Expires August 2007 [Page 2]
116 POP3 SASL Authentication Mechanism January 2007
120 Supported SASL Mechanisms
125 Standard Commands Affected
128 Announced states / possible differences:
131 Commands valid in states:
134 Specification Reference:
135 This Document, [RFC4422]
138 The SASL capability permits the use of the AUTH command (as
139 defined in section 4 of this document) to begin a SASL
140 negotiation (as defined in [RFC4422]). The argument to the SASL
141 capability is a space-separated list of SASL mechanisms which
144 If a server either does not support the CAPA command or does not
145 advertise the SASL capability, clients SHOULD NOT attempt the
146 AUTH command. If a client does attempt the AUTH command in such
147 a situation, it MUST NOT supply the client initial response
148 parameter (for backwards compatibility with [RFC1734]).
150 Note that the list of available mechanisms MAY change after a
151 successful STLS command (see [RFC2595]). However, as required
152 by [RFC2449], implementations MUST continue to include the SASL
153 capability even after a successful AUTH command has been
154 completed (even though no further AUTH commands may be issued).
157 S: +OK pop.example.com BlurdyBlurp POP3 server ready
159 S: +OK List of capabilities follows
160 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
162 S: IMPLEMENTATION BlurdyBlurp POP3 server
170 Siemborski and Menon-Sen Expires August 2007 [Page 3]
172 POP3 SASL Authentication Mechanism January 2007
177 AUTH mechanism [initial-response]
181 mechanism: A string identifying a SASL authentication
184 initial-response: An optional initial client response, as
185 defined in section 3 of [RFC4422]. If present, this response
186 MUST be encoded as Base64 (specified in Section 4 of
187 [RFC4648]), or consist only of the single character "=", which
188 represents an empty initial response.
192 After an AUTH command has been successfully completed, no more
193 AUTH commands may be issued in the same session. After a
194 successful AUTH command completes, a server MUST reject any
195 further AUTH commands with an -ERR reply.
197 The AUTH command may only be given during the AUTHORIZATION
202 The AUTH command initiates a SASL authentication exchange
203 between the client and the server. The client identifies the
204 SASL mechanism to use with the first parameter of the AUTH
205 command. If the server supports the requested authentication
206 mechanism, it performs the SASL exchange to authenticate the
207 user. Optionally, it also negotiates a security layer for
208 subsequent protocol interactions during this session. If the
209 requested authentication mechanism is not supported, the
210 server rejects the AUTH command with an -ERR reply.
212 The authentication protocol exchange consists of a series of
213 server challenges and client responses that are specific to
214 the chosen SASL mechanism.
216 A server challenge is sent as a line consisting of a "+"
217 character followed by a single space and a string encoded
218 using Base64 as specified in Section 4 of [RFC4648]. This
219 line MUST NOT contain any text other than the BASE64 encoded
222 A client response consists of a line containing a string
226 Siemborski and Menon-Sen Expires August 2007 [Page 4]
228 POP3 SASL Authentication Mechanism January 2007
231 encoded as Base64. If the client wishes to cancel the
232 authentication exchange, it issues a line with a single "*".
233 If the server receives such a response, it MUST reject the
234 AUTH command by sending an -ERR reply.
236 The optional initial-response argument to the AUTH command is
237 used to save a round trip when using authentication mechanisms
238 that support an initial client response. If the initial
239 response argument is omitted and the chosen mechanism requires
240 an initial client response, the server MUST proceed by issuing
241 an empty challenge, as defined in section 3 of [RFC4422]. In
242 POP3, an empty server challenge is defined as line with only a
243 "+" followed by a single space. It MUST NOT contain any other
246 For the purposes of the initial client response, the 255-octet
247 limit on the length of a single command, defined in section 4
248 of [RFC2449], still applies. If specifying an initial
249 response would cause the AUTH command to exceed this length,
250 the client MUST NOT use the initial-response parameter (and
251 must proceed instead by sending its initial response after an
252 empty challenge from the server, as in section 3 of
255 If the client needs to send a zero-length initial response, it
256 MUST transmit the response as a single equals sign ("=").
257 This indicates that the response is present, but contains no
260 If the client uses an initial-response argument to the AUTH
261 command with a SASL mechanism that does not support an initial
262 client send, the server MUST reject the AUTH command with an
265 If the server cannot Base64 decode a client response, it MUST
266 reject the AUTH command with an -ERR reply. If the client
267 cannot Base64 decode any of the server's challenges, it MUST
268 cancel the authentication using the "*" response. In
269 particular, servers and clients MUST reject (and not ignore)
270 any character not explicitly allowed by the Base64 alphabet,
271 and MUST reject any sequence of Base64 characters that
272 contains the pad character ('=') anywhere other than the end
273 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed).
275 Note that these Base64 strings (excepting the initial client
276 response) may be of arbitrarily length. Clients and servers
277 MUST be able to handle the maximum encoded size of challenges
278 and responses generated by their supported authentication
282 Siemborski and Menon-Sen Expires August 2007 [Page 5]
284 POP3 SASL Authentication Mechanism January 2007
287 mechanisms. This requirement is independent of any line
288 length limitations the client or server may have in other
289 parts of its protocol implementation.
291 If the server is unable to authenticate the client, it MUST
292 reject the AUTH command with an -ERR reply. Should the client
293 successfully complete the exchange, the server issues a +OK
294 reply. Additionally, upon success, the POP3 session enters
295 the TRANSACTION state.
297 The authorization identity generated by the SASL exchange is a
298 simple username, and SHOULD use the SASLprep profile (see
299 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
300 prepare these names for matching. If preparation of the
301 authorization identity fails or results in an empty string
302 (unless it was transmitted as the empty string), the server
303 MUST fail the authentication.
305 If a security layer is negotiated during the SASL exchange, it
306 takes effect for the client on the octet immediately following
307 the CRLF that concludes the last response generated by the
308 client. For the server, it takes effect immediately following
309 the CRLF of its success reply.
311 When a security layer takes effect, the server MUST discard
312 any knowledge previously obtained from the client, which was
313 not obtained from the SASL negotiation itself. Likewise, the
314 client MUST discard any knowledge obtained from the server,
315 such as the list of available POP3 service extensions.
317 When both TLS (see [RFC4346]) and SASL security layers are in
318 effect, the TLS encoding MUST be applied after the SASL
319 encoding when sending data. (According to [RFC2595], STLS can
320 only be issued before AUTH in any case.)
322 Note that POP3 does not allow for additional data to be sent
323 with a message indicating a successful outcome (see section
326 The service name specified by this protocol's profile of SASL
329 If an AUTH command fails, the client may try another
330 authentication mechanism or present different credentials by
331 issuing another AUTH command (or by using one of the other
332 POP3 authentication mechanisms). Likewise, the server MUST
333 behave as if the client had not issued the AUTH command.
338 Siemborski and Menon-Sen Expires August 2007 [Page 6]
340 POP3 SASL Authentication Mechanism January 2007
343 To ensure interoperability, client and server implementations
344 of this extension MUST implement the PLAIN SASL mechanism,
345 defined in [RFC4616].
347 A server implementation MUST implement a configuration in
348 which it does NOT permit any plaintext password mechanisms,
349 unless either the STLS command has been used to negotiate a
350 TLS session (see [RFC2595]), or some other mechanism that
351 protects the session from password snooping has been provided.
352 Server sites SHOULD NOT use any configuration which permits a
353 plaintext password mechanism without such a protection
354 mechanism against password snooping. Client and server
355 implementations SHOULD implement additional SASL mechanisms
356 that do not send plaintext passwords, such as the [DIGEST-MD5]
362 The following syntax specification uses the Augmented Backus-Naur
363 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and
364 DIGIT are imported from [RFC4234]. The sasl-mech rule is from
367 Except as noted otherwise, all alphabetic characters are case-
368 insensitive. The use of upper or lower case characters to define
369 token strings is for editorial clarity only. Implementations MUST
370 accept these strings in a case-insensitive fashion.
372 auth-command = "AUTH" SP sasl-mech [SP initial-response]
373 *(CRLF [base64]) [CRLF cancel-response] CRLF
375 initial-response= base64 / "="
377 cancel-response = "*"
379 base64 = base64-terminal /
380 ( 1*(4base64-CHAR) [base64-terminal] )
382 base64-char = ALPHA / DIGIT / "+" / "/"
385 base64-terminal = (2base64-char "==") / (3base64-char "=")
387 continue-req = "+" SP [base64] CRLF
389 Additionally, the ABNF specified in [RFC2449] is updated as follows:
394 Siemborski and Menon-Sen Expires August 2007 [Page 7]
396 POP3 SASL Authentication Mechanism January 2007
399 response =/ continue-req
404 Here is an example of a client attempting AUTH PLAIN (see [RFC4616])
405 under TLS and making use of the initial client response:
407 S: +OK pop.example.com BlurdyBlurp POP3 server ready
409 S: +OK List of capabilities follows
410 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
412 S: IMPLEMENTATION BlurdyBlurp POP3 server
415 S: +OK Begin TLS negotiation now
416 (TLS negotiation proceeds, further commands protected by TLS
419 S: +OK List of capabilities follows
420 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
421 S: IMPLEMENTATION BlurdyBlurp POP3 server
423 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
424 S: +OK Maildrop locked and ready
426 Here is another client that is attempting AUTH PLAIN under a TLS
427 layer, this time without the initial response. Parts of the
428 negotiation before the TLS layer was established have been omitted:
430 (TLS negotiation proceeds, further commands protected by TLS
433 S: +OK List of capabilities follows
434 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
435 S: IMPLEMENTATION BlurdyBlurp POP3 server
438 (note that there is a space following the '+' on the
441 C: dGVzdAB0ZXN0AHRlc3Q=
442 S: +OK Maildrop locked and ready
444 Here is an example using a mechanism in which the exchange begins
445 with a server challenge (the long lines are broken for editorial
450 Siemborski and Menon-Sen Expires August 2007 [Page 8]
452 POP3 SASL Authentication Mechanism January 2007
455 S: +OK pop.example.com BlurdyBlurp POP3 server ready
457 S: +OK List of capabilities follows
458 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
460 S: IMPLEMENTATION BlurdyBlurp POP3 server
463 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
464 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
466 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
467 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
468 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
469 BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
470 NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
471 S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
473 S: +OK Maildrop locked and ready
476 7. Security Considerations
478 Security issues are discussed throughout this document.
481 8. IANA Considerations
483 The IANA is requested to refer to this RFC instead of [RFC1734] in
484 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3
485 extension registry), and also in
486 http://www.iana.org/assignments/gssapi-service-names (the
487 GSSAPI/SASL service name registry).
492 The authors would like to acknowledge the contributions of John
493 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other
494 contributors to RFC 1734 and RFC 2554, on which this document draws
497 The authors would also like to thank Ken Murchison, Randall Gellens,
498 Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault,
499 Frank Ellermann, and Philip Guenther for their reviews of this
506 Siemborski and Menon-Sen Expires August 2007 [Page 9]
508 POP3 SASL Authentication Mechanism January 2007
511 10. Changes From RFC 1734, RFC 2449.
513 1. The SASL-based semantics defined in RFC 2449 are now normative
514 for the AUTH extension.
516 2. Clarifications and examples of the proper behavior of initial
517 client response handling.
519 3. Minimum requirement of support for TLS+PLAIN.
521 4. Clarify ordering of TLS and SASL security layers.
523 5. Update references to newer versions of various specifications.
525 6. Clarify that the mechanism list can change.
527 7. Add the use of the SASLprep profile for preparing authorization
530 8. General other editorial clarifications.
532 9. Consolidation of much applicable information into a single
535 10. CR is no longer (incorrectly) defined here.
537 12. Explicitly mention that "=" means a zero-length initial
540 13. Change MUST to SHOULD use SASLprep, because nobody does.
542 14. Clarify that the TLS encoding should be applied after any SASL
545 15. Note that POP3 doesn't allow additional data to be sent with
548 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule
549 instead of AUTH_CHAR.
551 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove
554 18. Reword the reference to [RFC3206] to make it clearer that it is
557 19. Define the initial-response by reference to SASL.
562 Siemborski and Menon-Sen Expires August 2007 [Page 10]
564 POP3 SASL Authentication Mechanism January 2007
567 20. Add continue-req to the response production from [RFC2449].
569 21. Add initial-response and cancel-response productions to the
573 11. Normative References
575 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53,
578 [RFC2119] Bradner, "Key words for use in RFCs to Indicate
579 Requirement Levels", BCP 14, RFC 2119, March 1997.
581 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism",
582 RFC 2449, November 1998.
584 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595,
587 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized
588 Strings ("stringprep")", RFC 3454, December 2002.
590 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names
591 and Passwords", RFC 4013, OpenLDAP Foundation, February
594 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax
595 Specifications: ABNF", RFC 4234, Brandenburg
596 Internetworking, Demon Internet Ltd, October 2005.
598 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security
599 Layer (SASL)", RFC 4422, June 2006.
601 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data
602 Encodings", RFC 4648, October 2003.
604 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security
605 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation,
609 12. Informative References
611 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January
614 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206,
618 Siemborski and Menon-Sen Expires August 2007 [Page 11]
620 POP3 SASL Authentication Mechanism January 2007
625 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS)
626 Protocol, Version 1.1", RFC 4346, April 2006.
628 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL
629 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode
633 13. Authors' Addresses
637 1600 Ampitheatre Parkway
638 Mountain View, CA 94043
640 Phone: +1 650 623 6925
641 Email: robsiemb@google.com
645 Oryx Mail Systems GmbH
674 Siemborski and Menon-Sen Expires August 2007 [Page 12]
676 POP3 SASL Authentication Mechanism January 2007
681 [RFC Editor: Remove this section before publication]
683 This document obsoletes RFC 1734 and replaces it as a Proposed
684 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be
685 moved to Historic (as RFC 1734 was the last document to have a
686 normative reference).
688 It also updates information contained in Section 6.3 of RFC 2449.
730 Siemborski and Menon-Sen Expires August 2007 [Page 13]
732 POP3 SASL Authentication Mechanism January 2007
735 Intellectual Property Statement
737 The IETF takes no position regarding the validity or scope of any
738 Intellectual Property Rights or other rights that might be claimed
739 to pertain to the implementation or use of the technology described
740 in this document or the extent to which any license under such
741 rights might or might not be available; nor does it represent that
742 it has made any independent effort to identify any such rights.
743 Information on the procedures with respect to rights in RFC
744 documents can be found in BCP 78 and BCP 79.
746 Copies of IPR disclosures made to the IETF Secretariat and any
747 assurances of licenses to be made available, or the result of an
748 attempt made to obtain a general license or permission for the use
749 of such proprietary rights by implementers or users of this
750 specification can be obtained from the IETF on-line IPR repository
751 at http://www.ietf.org/ipr.
753 The IETF invites any interested party to bring to its attention any
754 copyrights, patents or patent applications, or other proprietary
755 rights that may cover technology that may be required to implement
756 this standard. Please address the information to the IETF at ietf-
760 Full Copyright Statement
762 Copyright (C) The IETF Trust (2007). This document is subject to
763 the rights, licenses and restrictions contained in BCP 78, and
764 except as set forth therein, the authors retain all their rights.
766 This document and the information contained herein are provided on
767 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
768 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
769 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
770 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
771 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
772 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
773 FOR A PARTICULAR PURPOSE.
778 Funding for the RFC Editor function is currently provided by the
786 Siemborski and Menon-Sen Expires August 2007 [Page 14]