From 4ef3257e82d06997a40c06a1fb9418dc3d721692 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Tue, 28 Nov 2006 20:15:56 +0000 Subject: [PATCH] Add. --- .../draft-siemborski-rfc1734bis-05.txt | 731 +++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/specification/draft-siemborski-rfc1734bis-05.txt diff --git a/doc/specification/draft-siemborski-rfc1734bis-05.txt b/doc/specification/draft-siemborski-rfc1734bis-05.txt new file mode 100644 index 0000000..649705a --- /dev/null +++ b/doc/specification/draft-siemborski-rfc1734bis-05.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group Robert Siemborski +INTERNET-DRAFT Google, Inc. +Intended Category: Proposed Standard Abhijit Menon-Sen +Obsoletes: RFC 1734 Oryx Mail Systems GmbH +Updates: RFC 2449 November 2006 + + + POP3 SASL Authentication Mechanism + draft-siemborski-rfc1734bis-05.txt + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- + Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire in May 2007. + + +Abstract + + This document defines a profile of the Simple Authentication and + Security Layer (SASL) for the Post Office Protocol (POP3). This + extension allows a POP3 client to indicate an authentication + mechanism to the server, perform an authentication protocol + exchange, and optionally negotiate a security layer for subsequent + protocol interactions during this session. + + This document seeks to consolidate the information related to POP3 + AUTH into a single document. To this end, this document obsoletes + RFC 1734, replacing it as a Proposed Standard and updates + + + +Siemborski and Menon-Sen Expires May 2007 [Page 1] + +POP3 SASL Authentication Mechanism November 2006 + + + information contained in Section 6.3 of RFC 2449. + + +1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + Formal syntax is defined by [RFC4234]. + + +2. Introduction + + The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered + several problems in its specification. The first is that it was + very similar to a SASL framework defined by [RFC4422], but pre-dated + the initial SASL specification. It was therefore missing some key + components, such as a way to list the available authentication + mechanisms. + + Later, [RFC2449] attempted to remedy this situation by adding the + CAPA command and allowing an initial client response to the AUTH + command, however problems in the clarity of the specification of how + the initial client response was to be handled remained. + + Additionally, there is yet another document, [RFC3206], that + provides additional response codes that are useful during + authentication. Together, this means creating a full POP3 AUTH + implementaiton requires an understanding of material in at least + five (and probably six) different documents. + + This document attempts to combine the information in [RFC1734] and + [RFC2449] to simplify this situation. Additionally, it aims to + clarify and update the older specifications where appropriate. + + +3. The SASL Capability + + This section supersedes the definition of the SASL Capability in + section 6.3 of [RFC2449]. + + CAPA tag: + SASL + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 2] + +POP3 SASL Authentication Mechanism November 2006 + + + Arguments: + Supported SASL Mechanisms + + Added commands: + AUTH + + Standard Commands Affected + None + + Announced states / possible differences: + both / no + + Commands valid in states: + AUTHORIZATION + + Specification Reference: + This Document, [RFC4422] + + Discussion + The SASL capability permits the use of the AUTH command (as + defined in section 4 of this document) to begin a SASL + negotiation (as defined in [RFC4422]). The argument to the SASL + capability is a space-separated list of SASL mechanisms which + are supported. + + If a server either does not support the CAPA command or does not + advertise the SASL capability, clients SHOULD NOT attempt the + AUTH command. If a client does attempt the AUTH command in such + a situation, it MUST NOT supply the client initial response + parameter (for backwards compatibility with [RFC1734]). + + Note that the list of available mechanisms MAY change after a + successful STLS command (see [RFC2595]). However, as required + by [RFC2449] implementations MUST continue to include the SASL + capability even after a successful AUTH command has been + completed (even though no further AUTH commands may be issued). + + Example + S: +OK pop.example.com BlurdyBlurp POP3 server ready + C: CAPA + S: +OK List of capabilities follows + S: SASL KERBEROS_V4 GSSAPI ANONYMOUS + S: STLS + S: IMPLEMENTATION BlurdyBlurp POP3 server + S: . + + + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 3] + +POP3 SASL Authentication Mechanism November 2006 + + +4. The AUTH Command + + AUTH mechanism [initial-response] + + Arguments: + + mechanism: A string identifying a SASL authentication + mechanism. + + initial-response: An optional initial client response. If + present, this response MUST be encoded as Base64 (specified in + Section 4 of [RFC4648]). + + Restrictions: + + After an AUTH command has been successfully completed, no more + AUTH commands may be issued in the same session. After a + successful AUTH command completes, a server MUST reject any + further AUTH commands with an -ERR reply. + + The AUTH command may only be given during the AUTHORIZATION + state. + + Discussion: + + The AUTH command initiates a SASL authentication exchange + between the client and the server. The client identifies the + SASL mechanism to use with the first parameter of the AUTH + command. If the server supports the requested authentication + mechanism, it performs the SASL exchange to authenticate the + user. Optionally, it also negotiates a security layer for + subsequent protocol interactions during this session. If the + requested authentication mechanism is not supported, the + server rejects the AUTH command with an -ERR reply. + + The authentication protocol exchange consists of a series of + server challenges and client responses that are specific to + the chosen SASL mechanism. + + A server challenge is sent as a line consisting of a "+" + character followed by a single space and a string encoded + using Base64 as specified in Section 4 of [RFC4648]. This + line MUST NOT contain any text other than the BASE64 encoded + challenge. + + A client response consists of a line containing a string + encoded as Base64. If the client wishes to cancel the + authentication exchange, it issues a line with a single "*". + + + +Siemborski and Menon-Sen Expires May 2007 [Page 4] + +POP3 SASL Authentication Mechanism November 2006 + + + If the server receives such a response, it MUST reject the + AUTH command by sending an -ERR reply. + + The optional initial response argument to the AUTH command is + used to save a round trip when using authentication mechanisms + that support an initial client response. If the initial + response argument is omitted and the chosen mechanism requires + an initial client response, the server MUST proceed as defined + in section 3 of [RFC4422]. In POP3, a server challenge with + no data is defined as line with only a "+" followed by a + single space. It MUST NOT contain any other data. + + For the purposes of the initial client response, the line + length limitation defined in [RFC2449] still applies. If a + client initial send would cause the AUTH command to exceed + this length, the client MUST NOT use the initial response + parameter (and instead proceed as defined in section 5.1 of + [RFC4422]). + + If the client needs to send a zero-length initial response, + the client MUST transmit the response as a single equals sign + ("="). This indicates that the response is present, but + contains no data. + + If the client uses an initial-response argument to the AUTH + command with a SASL mechanism that does not support an initial + client send, the server MUST reject the AUTH command with an + -ERR reply. + + If the server cannot Base64 decode a client response, it MUST + reject the AUTH command with an -ERR reply. If the client + cannot Base64 decode any of the server's challenges, it MUST + cancel the authentication using the "*" response. In + particular, servers and clients MUST reject (and not ignore) + any character not explicitly allowed by the Base64 alphabet, + and MUST reject any sequence of Base64 characters that + contains the pad character ('=') anywhere other than the end + of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). + + Note that these Base64 strings (excepting the initial client + response) may be of arbitrarily length. Clients and servers + MUST be able to handle the maximum encoded size of challenges + and responses generated by their supported authentication + mechanisms. This requirement is independent of any line + length limitations the client or server may have in other + parts of its protocol implementation. + + If the server is unable to authenticate the client, it MUST + + + +Siemborski and Menon-Sen Expires May 2007 [Page 5] + +POP3 SASL Authentication Mechanism November 2006 + + + reject the AUTH command with an -ERR reply. Should the client + successfully complete the exchange, the server issues a +OK + reply. Additionally, upon success, the POP3 session enters + the TRANSACTION state. + + The authorization identity generated by the SASL exchange is a + simple username, and MUST use the SASLprep profile (see + [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to + prepare these names for matching. If preparation of the + authorization identity fails or results in an empty string + (unless it was transmitted as the empty string), the server + MUST fail the authentication. + + If a security layer is negotiated during the SASL exchange, it + takes effect for the client on the octet immediately following + the CRLF that concludes the last response generated by the + client. For the server, it takes effect immediately following + the CRLF of its success reply. + + When a security layer takes effect, the server MUST discard + any knowledge previously obtained from the client, which was + not obtained from the SASL negotiation itself. Likewise, the + client MUST discard any knowledge obtained from the server, + such as the list of available POP3 service extensions. + + When both TLS (see [RFC4346]) and SASL security layers are in + effect, the TLS encoding MUST be applied after the SASL + encoding, regardless of the order in which the layers were + negotiated. + + The service name specified by this protocol's profile of SASL + is "pop". + + If an AUTH command fails, the client may try another + authentication mechanism or present different credentials by + issuing another AUTH command (or by using one of the other + POP3 authentication mechanisms). Likewise, the server MUST + behave as if the client had not issued the AUTH command. + + To ensure interoperability, client and server implementations + of this extension MUST implement the [DIGEST-MD5] SASL + mechanism. + + +5. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and + + + +Siemborski and Menon-Sen Expires May 2007 [Page 6] + +POP3 SASL Authentication Mechanism November 2006 + + + DIGIT are imported from [RFC4234]. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + AUTH_CHAR = ALPHA / DIGIT / "-" / "_" + + auth_type = 1*20AUTH_CHAR + + auth_command = "AUTH" SP auth_type [SP (base64 / "=")] *(CRLF + [base64]) CRLF + + auth_resp = ("*" / base64) CRLF + + base64 = base64_terminal / + ( 1*(4base64_CHAR) [base64_terminal] ) + + base64_char = ALPHA / DIGIT / "+" / "/" + ;; Case-sensitive + + base64_terminal = (2base64_char "==") / (3base64_char "=") + + continue_req = "+" SP [base64] CRLF + + Additionally, the ABNF specified in [RFC2449] is updated as follows: + + challenge /= continue_req + + +6. Examples + + Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) + under TLS and making use of the initial client response: + + S: +OK pop.example.com BlurdyBlurp POP3 server ready + C: CAPA + S: +OK List of capabilities follows + S: SASL KERBEROS_V4 GSSAPI ANONYMOUS + S: STLS + S: IMPLEMENTATION BlurdyBlurp POP3 server + S: . + C: STLS + S: +OK Begin TLS negotiation now + (TLS negotiation proceeds, further commands protected by TLS + layer) + C: CAPA + + + +Siemborski and Menon-Sen Expires May 2007 [Page 7] + +POP3 SASL Authentication Mechanism November 2006 + + + S: +OK List of capabilities follows + S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS + S: IMPLEMENTATION BlurdyBlurp POP3 server + S: . + C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= + S: +OK Maildrop locked and ready + + Here is another client that is attempting AUTH PLAIN under a TLS + layer, this time without the initial response. Parts of the + negotiation before the TLS layer was established have been omitted: + + (TLS negotiation proceeds, further commands protected by TLS + layer) + C: CAPA + S: +OK List of capabilities follows + S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS + S: IMPLEMENTATION BlurdyBlurp POP3 server + S: . + C: AUTH PLAIN + (note that there is a space following the '+' on the + following line) + S: + + C: dGVzdAB0ZXN0AHRlc3Q= + S: +OK Maildrop locked and ready + + Here is an example using a mechanism which does not support an + initial client send, and includes server challenges: + + S: +OK pop.example.com BlurdyBlurp POP3 server ready + C: CAPA + S: +OK List of capabilities follows + S: SASL KERBEROS_V4 GSSAPI ANONYMOUS + S: STLS + S: IMPLEMENTATION BlurdyBlurp POP3 server + S: . + C: AUTH KERBEROS_V4 + S: + ezLUFA== + (the following lines are broken for editorial clarity only) + C: BAYFQU5EUkVXLkNNVS5FRFUAOCCXeMiVyFe9K6Nwne7+sPLgIoF9YQ5ePfxU + sMlJAfC7aoNySU8nrqS9m8JAddsUeuyc5HFXXovaKLrZNo2bTLH0Lyolwy0W + 9ryJDojbKmHyzSMqFsGD4EL0 + S: + Z74fTwDw7KQ= + C: vSAF7ha6qotK2UHUgKlsEA== + S: +OK Maildrop locked and ready + (at this point a security layer has been established and + additional commands and responses proceed within it) + + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 8] + +POP3 SASL Authentication Mechanism November 2006 + + +7. Security Considerations + + Security issues are discussed throughout this document. + + +8. IANA Considerations + + The IANA is requested to refer to this RFC instead of [RFC1734] in + http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 + extension registry). + + +9. Acknowledgments + + The author would like to acknowledge the contributions of John + Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other + contributors to RFC 1734 and RFC 2554, on which this document draws + heavily. + + The author would also like to thank Ken Murchison, Randall Gellens, + Alexey Melnikov, and Mark Crispin for the time they devoted to + reviewing early drafts of this document. + + +10. Changes From RFC 1734, RFC 2449. + + 1. The SASL-based semantics defined in RFC 2449 are now normative + for the AUTH extension. + + 2. Clarifications and examples of the proper behavior of initial + client response handling. + + 3. Minimum requirement of support for DIGEST-MD5. + + 4. Clarify ordering of TLS and SASL security layers. + + 5. Update references to newer versions of various specifications. + + 6. Clarify that the mechanism list can change. + + 7. Add the use of the SASLprep profile for preparing authorization + identities. + + 8. General other editorial clarifications. + + 9. Consolidation of much applicable information into a single + document. + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 9] + +POP3 SASL Authentication Mechanism November 2006 + + + 10. CR is now defined as 0x0D, not 0x0C. + + +11. Normative References + + [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", STD 53, + RFC 1939, May 1996. + + [RFC2119] Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2449] Gellens, Newman, Lundblade, "POP3 Extension Mechanism", + RFC 2449, November 1998. + + [RFC2595] Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595, + June 1999. + + [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized + Strings ( RFC 3454, December 2002. + + [RFC4013] Zeilenga, "SASLprep: Stringprep Profile for User Names + and Passwords", RFC 4013, OpenLDAP Foundation, February + 2005. + + [RFC4234] Crocker, Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, Brandenburg + Internetworking, Demon Internet Ltd, October 2005. + + [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security + Layer (SASL)", RFC 4422, June 2006. + + [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2003. + + [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL + Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode + Ltd., November 2006 + + +12. Informative References + + [RFC1734] Myers, "POP3 AUTHentication Command", RFC 1734, January + 1994. + + [RFC3206] Gellens, "The SYS and AUTH POP Response Codes", RFC 3206, + February 2002. + + [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) + + + +Siemborski and Menon-Sen Expires May 2007 [Page 10] + +POP3 SASL Authentication Mechanism November 2006 + + + Protocol, Version 1.1", RFC 4346, April 2006. + + [RFC4616] Zeilenga, "The PLAIN Simple Authentication and Security + Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation, + August 2006. + + +13. Authors' Addresses + + Robert Siemborski + Google, Inc. + 1600 Ampitheatre Parkway + Mountain View, CA 94043 + + Phone: +1 650 623 6925 + Email: robsiemb@google.com + + + Abhijit Menon-Sen + Oryx Mail Systems GmbH + + Email: ams@oryx.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 11] + +POP3 SASL Authentication Mechanism November 2006 + + +Protocol Actions + + [RFC Editor: Remove this section before publication] + + This document obsoletes RFC 1734 and replaces it as a Proposed + Standard. By moving RFC 1734 to Historic, RFC 1731 can also be + moved to Historic (as RFC 1734 was the last document to have a + normative reference). + + It also updates information contained in Section 6.3 of RFC 2449. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 12] + +POP3 SASL Authentication Mechanism November 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; nor does it represent that + it has made any independent effort to identify any such rights. + Information on the procedures with respect to rights in RFC + documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Siemborski and Menon-Sen Expires May 2007 [Page 13] + \ No newline at end of file -- 2.11.4.GIT