7 Network Working Group Robert Siemborski
8 INTERNET-DRAFT Google, Inc.
9 Intended Category: Proposed Standard Abhijit Menon-Sen
10 Obsoletes: RFC 1734 Oryx Mail Systems GmbH
11 Updates: RFC 2449 November 2006
14 POP3 SASL Authentication Mechanism
15 draft-siemborski-rfc1734bis-07.txt
20 By submitting this Internet-Draft, each author represents that any
21 applicable patent or other IPR claims of which he or she is aware
22 have been or will be disclosed, and any of which he or she becomes
23 aware will be disclosed, in accordance with Section 6 of BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
30 Internet-Drafts are draft documents valid for a maximum of six
31 months and may be updated, replaced, or obsoleted by other documents
32 at any time. It is inappropriate to use Internet-Drafts as
33 reference material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
37 Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire in May 2007.
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
58 Siemborski and Menon-Sen Expires May 2007 [Page 1]
60 POP3 SASL Authentication Mechanism November 2006
63 information contained in Section 6.3 of RFC 2449.
66 1. Conventions Used in This Document
68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
70 document are to be interpreted as described in [RFC2119].
72 In examples, "C:" and "S:" indicate lines sent by the client and
75 Formal syntax is defined by [RFC4234].
80 The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
81 several problems in its specification. The first is that it was
82 very similar to a SASL framework defined by [RFC4422], but pre-dated
83 the initial SASL specification. It was therefore missing some key
84 components, such as a way to list the available authentication
87 Later, [RFC2449] attempted to remedy this situation by adding the
88 CAPA command and allowing an initial client response to the AUTH
89 command, however problems in the clarity of the specification of how
90 the initial client response was to be handled remained.
92 Additionally, there is yet another document, [RFC3206], that
93 provides additional response codes that are useful during
94 authentication. Together, this means creating a full POP3 AUTH
95 implementaiton requires an understanding of material in at least
96 five (and probably six) different documents.
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 May 2007 [Page 2]
116 POP3 SASL Authentication Mechanism November 2006
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 DIGEST-MD5 GSSAPI ANONYMOUS
162 S: IMPLEMENTATION BlurdyBlurp POP3 server
170 Siemborski and Menon-Sen Expires May 2007 [Page 3]
172 POP3 SASL Authentication Mechanism November 2006
177 AUTH mechanism [initial-response]
181 mechanism: A string identifying a SASL authentication
184 initial-response: An optional initial client response. If
185 present, this response MUST be encoded as Base64 (specified in
186 Section 4 of [RFC4648]) or consist only of the single
187 character "=", which represents an empty initial response.
191 After an AUTH command has been successfully completed, no more
192 AUTH commands may be issued in the same session. After a
193 successful AUTH command completes, a server MUST reject any
194 further AUTH commands with an -ERR reply.
196 The AUTH command may only be given during the AUTHORIZATION
201 The AUTH command initiates a SASL authentication exchange
202 between the client and the server. The client identifies the
203 SASL mechanism to use with the first parameter of the AUTH
204 command. If the server supports the requested authentication
205 mechanism, it performs the SASL exchange to authenticate the
206 user. Optionally, it also negotiates a security layer for
207 subsequent protocol interactions during this session. If the
208 requested authentication mechanism is not supported, the
209 server rejects the AUTH command with an -ERR reply.
211 The authentication protocol exchange consists of a series of
212 server challenges and client responses that are specific to
213 the chosen SASL mechanism.
215 A server challenge is sent as a line consisting of a "+"
216 character followed by a single space and a string encoded
217 using Base64 as specified in Section 4 of [RFC4648]. This
218 line MUST NOT contain any text other than the BASE64 encoded
221 A client response consists of a line containing a string
222 encoded as Base64. If the client wishes to cancel the
226 Siemborski and Menon-Sen Expires May 2007 [Page 4]
228 POP3 SASL Authentication Mechanism November 2006
231 authentication exchange, it issues a line with a single "*".
232 If the server receives such a response, it MUST reject the
233 AUTH command by sending an -ERR reply.
235 The optional initial response argument to the AUTH command is
236 used to save a round trip when using authentication mechanisms
237 that support an initial client response. If the initial
238 response argument is omitted and the chosen mechanism requires
239 an initial client response, the server MUST proceed as defined
240 in section 3 of [RFC4422]. In POP3, a server challenge with
241 no data is defined as line with only a "+" followed by a
242 single space. It MUST NOT contain any other data.
244 For the purposes of the initial client response, the line
245 length limitation defined in [RFC2449] still applies. If a
246 client initial send would cause the AUTH command to exceed
247 this length, the client MUST NOT use the initial response
248 parameter (and instead proceed as defined in section 5.1 of
251 If the client needs to send a zero-length initial response,
252 the client MUST transmit the response as a single equals sign
253 ("="). This indicates that the response is present, but
256 If the client uses an initial-response argument to the AUTH
257 command with a SASL mechanism that does not support an initial
258 client send, the server MUST reject the AUTH command with an
261 If the server cannot Base64 decode a client response, it MUST
262 reject the AUTH command with an -ERR reply. If the client
263 cannot Base64 decode any of the server's challenges, it MUST
264 cancel the authentication using the "*" response. In
265 particular, servers and clients MUST reject (and not ignore)
266 any character not explicitly allowed by the Base64 alphabet,
267 and MUST reject any sequence of Base64 characters that
268 contains the pad character ('=') anywhere other than the end
269 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed).
271 Note that these Base64 strings (excepting the initial client
272 response) may be of arbitrarily length. Clients and servers
273 MUST be able to handle the maximum encoded size of challenges
274 and responses generated by their supported authentication
275 mechanisms. This requirement is independent of any line
276 length limitations the client or server may have in other
277 parts of its protocol implementation.
282 Siemborski and Menon-Sen Expires May 2007 [Page 5]
284 POP3 SASL Authentication Mechanism November 2006
287 If the server is unable to authenticate the client, it MUST
288 reject the AUTH command with an -ERR reply. Should the client
289 successfully complete the exchange, the server issues a +OK
290 reply. Additionally, upon success, the POP3 session enters
291 the TRANSACTION state.
293 The authorization identity generated by the SASL exchange is a
294 simple username, and SHOULD use the SASLprep profile (see
295 [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
296 prepare these names for matching. If preparation of the
297 authorization identity fails or results in an empty string
298 (unless it was transmitted as the empty string), the server
299 MUST fail the authentication.
301 If a security layer is negotiated during the SASL exchange, it
302 takes effect for the client on the octet immediately following
303 the CRLF that concludes the last response generated by the
304 client. For the server, it takes effect immediately following
305 the CRLF of its success reply.
307 When a security layer takes effect, the server MUST discard
308 any knowledge previously obtained from the client, which was
309 not obtained from the SASL negotiation itself. Likewise, the
310 client MUST discard any knowledge obtained from the server,
311 such as the list of available POP3 service extensions.
313 When both TLS (see [RFC4346]) and SASL security layers are in
314 effect, the TLS encoding MUST be applied after the SASL
315 encoding when sending data. (According to [RFC2595], STLS can
316 only be issued before AUTH in any case.)
318 Note that POP3 does not allow for additional data to be sent
319 with a message indicating a successful outcome (see section
322 The service name specified by this protocol's profile of SASL
325 If an AUTH command fails, the client may try another
326 authentication mechanism or present different credentials by
327 issuing another AUTH command (or by using one of the other
328 POP3 authentication mechanisms). Likewise, the server MUST
329 behave as if the client had not issued the AUTH command.
331 To ensure interoperability, client and server implementations
332 of this extension MUST implement the [DIGEST-MD5] SASL
338 Siemborski and Menon-Sen Expires May 2007 [Page 6]
340 POP3 SASL Authentication Mechanism November 2006
345 The following syntax specification uses the Augmented Backus-Naur
346 Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and
347 DIGIT are imported from [RFC4234]. The sasl-mech rule is from
350 Except as noted otherwise, all alphabetic characters are case-
351 insensitive. The use of upper or lower case characters to define
352 token strings is for editorial clarity only. Implementations MUST
353 accept these strings in a case-insensitive fashion.
355 auth-command = "AUTH" SP sasl-mech [SP (base64 / "=")] *(CRLF
358 auth-resp = ("*" / base64) CRLF
360 base64 = base64-terminal /
361 ( 1*(4base64-CHAR) [base64-terminal] )
363 base64-char = ALPHA / DIGIT / "+" / "/"
366 base64-terminal = (2base64-char "==") / (3base64-char "=")
368 continue-req = "+" SP [base64] CRLF
370 Additionally, the ABNF specified in [RFC2449] is updated as follows:
372 challenge /= continue-req
377 Here is an example of a client attempting AUTH PLAIN (see [RFC4616])
378 under TLS and making use of the initial client response:
380 S: +OK pop.example.com BlurdyBlurp POP3 server ready
382 S: +OK List of capabilities follows
383 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
385 S: IMPLEMENTATION BlurdyBlurp POP3 server
388 S: +OK Begin TLS negotiation now
389 (TLS negotiation proceeds, further commands protected by TLS
394 Siemborski and Menon-Sen Expires May 2007 [Page 7]
396 POP3 SASL Authentication Mechanism November 2006
400 S: +OK List of capabilities follows
401 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
402 S: IMPLEMENTATION BlurdyBlurp POP3 server
404 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
405 S: +OK Maildrop locked and ready
407 Here is another client that is attempting AUTH PLAIN under a TLS
408 layer, this time without the initial response. Parts of the
409 negotiation before the TLS layer was established have been omitted:
411 (TLS negotiation proceeds, further commands protected by TLS
414 S: +OK List of capabilities follows
415 S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
416 S: IMPLEMENTATION BlurdyBlurp POP3 server
419 (note that there is a space following the '+' on the
422 C: dGVzdAB0ZXN0AHRlc3Q=
423 S: +OK Maildrop locked and ready
425 Here is an example using a mechanism in which the exchange begins
426 with a server challenge (the long lines are broken for editorial
429 S: +OK pop.example.com BlurdyBlurp POP3 server ready
431 S: +OK List of capabilities follows
432 S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
434 S: IMPLEMENTATION BlurdyBlurp POP3 server
437 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
438 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
440 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
441 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
442 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
443 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
444 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
445 S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
450 Siemborski and Menon-Sen Expires May 2007 [Page 8]
452 POP3 SASL Authentication Mechanism November 2006
455 S: +OK Maildrop locked and ready
458 7. Security Considerations
460 Security issues are discussed throughout this document.
463 8. IANA Considerations
465 The IANA is requested to refer to this RFC instead of [RFC1734] in
466 http://www.iana.org/assignments/pop3-extension-mechanism (the POP3
472 The authors would like to acknowledge the contributions of John
473 Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other
474 contributors to RFC 1734 and RFC 2554, on which this document draws
477 The authors would also like to thank Ken Murchison, Randall Gellens,
478 Alexey Melnikov, Mark Crispin, and Arnt Gulbrandsen for the time
479 they devoted to reviewing early drafts of this document.
482 10. Changes From RFC 1734, RFC 2449.
484 1. The SASL-based semantics defined in RFC 2449 are now normative
485 for the AUTH extension.
487 2. Clarifications and examples of the proper behavior of initial
488 client response handling.
490 3. Minimum requirement of support for DIGEST-MD5.
492 4. Clarify ordering of TLS and SASL security layers.
494 5. Update references to newer versions of various specifications.
496 6. Clarify that the mechanism list can change.
498 7. Add the use of the SASLprep profile for preparing authorization
501 8. General other editorial clarifications.
506 Siemborski and Menon-Sen Expires May 2007 [Page 9]
508 POP3 SASL Authentication Mechanism November 2006
511 9. Consolidation of much applicable information into a single
514 10. CR is no longer (incorrectly) defined here.
516 11. Include M-T-I DIGEST-MD5 in the SASL capability response.
518 12. Explicitly mention that "=" means a zero-length initial
521 13. Change MUST to SHOULD use SASLprep, because nobody does.
523 14. Clarify that the TLS encoding should be applied after any SASL
526 15. Note that POP3 doesn't allow additional data to be sent with
529 16. Change "_" to "-" in the ABNF, and use the sasl-mech rule
530 instead of AUTH_CHAR.
532 17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove
536 11. Normative References
538 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53,
541 [RFC2119] Bradner, "Key words for use in RFCs to Indicate
542 Requirement Levels", BCP 14, RFC 2119, March 1997.
544 [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism",
545 RFC 2449, November 1998.
547 [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595,
550 [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized
551 Strings ( RFC 3454, December 2002.
553 [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names
554 and Passwords", RFC 4013, OpenLDAP Foundation, February
557 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax
558 Specifications: ABNF", RFC 4234, Brandenburg
562 Siemborski and Menon-Sen Expires May 2007 [Page 10]
564 POP3 SASL Authentication Mechanism November 2006
567 Internetworking, Demon Internet Ltd, October 2005.
569 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security
570 Layer (SASL)", RFC 4422, June 2006.
572 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data
573 Encodings", RFC 4648, October 2003.
575 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL
576 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode
580 12. Informative References
582 [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January
585 [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206,
588 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS)
589 Protocol, Version 1.1", RFC 4346, April 2006.
591 [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security
592 Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation,
596 13. Authors' Addresses
600 1600 Ampitheatre Parkway
601 Mountain View, CA 94043
603 Phone: +1 650 623 6925
604 Email: robsiemb@google.com
608 Oryx Mail Systems GmbH
618 Siemborski and Menon-Sen Expires May 2007 [Page 11]
620 POP3 SASL Authentication Mechanism November 2006
625 [RFC Editor: Remove this section before publication]
627 This document obsoletes RFC 1734 and replaces it as a Proposed
628 Standard. By moving RFC 1734 to Historic, RFC 1731 can also be
629 moved to Historic (as RFC 1734 was the last document to have a
630 normative reference).
632 It also updates information contained in Section 6.3 of RFC 2449.
674 Siemborski and Menon-Sen Expires May 2007 [Page 12]
676 POP3 SASL Authentication Mechanism November 2006
679 Intellectual Property Statement
681 The IETF takes no position regarding the validity or scope of any
682 Intellectual Property Rights or other rights that might be claimed
683 to pertain to the implementation or use of the technology described
684 in this document or the extent to which any license under such
685 rights might or might not be available; nor does it represent that
686 it has made any independent effort to identify any such rights.
687 Information on the procedures with respect to rights in RFC
688 documents can be found in BCP 78 and BCP 79.
690 Copies of IPR disclosures made to the IETF Secretariat and any
691 assurances of licenses to be made available, or the result of an
692 attempt made to obtain a general license or permission for the use
693 of such proprietary rights by implementers or users of this
694 specification can be obtained from the IETF on-line IPR repository
695 at http://www.ietf.org/ipr.
697 The IETF invites any interested party to bring to its attention any
698 copyrights, patents or patent applications, or other proprietary
699 rights that may cover technology that may be required to implement
700 this standard. Please address the information to the IETF at ietf-
704 Full Copyright Statement
706 Copyright (C) The Internet Society (2006). This document is subject
707 to the rights, licenses and restrictions contained in BCP 78, and
708 except as set forth therein, the authors retain all their rights.
710 This document and the information contained herein are provided on
711 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
712 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
713 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
714 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
715 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
721 Funding for the RFC Editor function is currently provided by the
730 Siemborski and Menon-Sen Expires May 2007 [Page 13]