idnits 2.17.1 draft-myers-sasl-pop3-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 160 has weird spacing: '... answer are...' == Line 161 has weird spacing: '... for edit...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft: POP3 Authentication Netscape Communications 4 Document: draft-myers-sasl-pop3-05.txt August 1998 6 POP3 AUTHentication command 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before July 1997. Distribution of this draft is unlimited. 31 1. Introduction 33 This document defines the optional AUTH command to POP3 [POP3], for 34 indicating an authentication mechanism to the server, performing an 35 authentication protocol exchange, and optionally negotiating a 36 security layer for subsequent protocol interactions. This extension 37 is a profile of the Simple Authentication and Session Layer [SASL]. 39 2. Conventions Used in this Document 41 In examples, "C:" and "S:" indicate lines sent by the client and 42 server respectively. 44 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 45 in this document are to be interpreted as defined in "Key words for 46 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 48 3. The AUTH command 50 AUTH [mechanism] [initial-response] 52 Arguments: 53 an optional string identifying a SASL authentication 54 mechanism. 55 an optional base64-encoded response 57 Restrictions: 58 may only be given in the AUTHORIZATION state 60 Discussion: 61 If no argument was given and the POP3 server issues a 62 positive response, then he response given is multi-line. 63 After the initial +OK, for each SASL mechanism supported, 64 the POP3 server responds with a line containing the name of 65 the SASL mechanism. 67 If at least one argument was given, the AUTH command 68 indicates an authentication mechanism to the server. If 69 the server supports the requested authentication mechanism, 70 it performs an authentication protocol exchange to 71 authenticate and identify the user. Optionally, it also 72 negotiates a security layer for subsequent protocol 73 interactions. If the requested authentication mechanism is 74 not supported, the server SHOULD reject the AUTH command by 75 sending a negative response. 77 The authentication protocol exchange consists of a series 78 of server challenges and client answers that are specific 79 to the authentication mechanism. A server challenge, 80 otherwise known as a ready response, is a line consisting 81 of a "+" character followed by a single space and a BASE64 82 encoded string. The client answer consists of a line 83 containing a BASE64 encoded string. If the client wishes 84 to cancel an authentication exchange, it SHOULD issue a 85 line with a single "*". If the server receives such an 86 answer, it MUST reject the AUTH command by sending a 87 negative response. 89 The optional initial-response argument to the AUTH command 90 is used to save a round trip when using authentication 91 mechanisms that are defined to send no data in the initial 92 challenge. When the initial-response argument is used with 93 such a mechanism, the initial empty challenge is not sent 94 to the client and the server uses the data in the initial- 95 response argument as if it were sent in response to the 96 empty challenge. If the initial-response argument to the 97 AUTH command is used with a mechanism that sends data in 98 the initial challenge, the server MUST reject the AUTH 99 command by sending a negative response. 101 The service name specified by this protocol's profile of 102 SASL is "pop". 104 If a security layer is negotiated through the SASL 105 authentication exchange, it takes effect immediately 106 following the CRLF that concludes the authentication 107 exchange for the client, and the CRLF of the positive 108 response for the server. 110 The server is not required to support any particular 111 authentication mechanism, nor are authentication mechanisms 112 required to support any security layers. If an AUTH 113 command fails with a negative response, the session remains 114 in the AUTHORIZATION state and client may try another 115 authentication mechanism by issuing another AUTH command, 116 or may attempt to authenticate by using the USER/PASS or 117 APOP commands. In other words, the client may request 118 authentication types in decreasing order of preference, 119 with the USER/PASS or APOP command as a last resort. 121 Should the client successfully complete the authentication 122 exchange, the POP3 server issues a positive response and 123 the POP3 session enters the TRANSACTION state. 125 The BASE64 string may in general be arbitrarily long. 126 Clients and servers MUST be able to support challenges and 127 responses that are as long as are generated by the 128 authentication mechanisms they support, independent of any 129 line length limitations the client or server may have in 130 other parts of its protocol implementation. 132 Possible Responses: 133 +OK list of supported mechanisms follows 134 +OK maildrop locked and ready 135 -ERR authentication exchange failed 137 Examples: 138 S: +OK POP3 server ready 139 C: AUTH 140 S: +OK Listing of supported mechanisms follows 141 S: KERBEROS_V4 142 S: S/KEY 143 S: . 144 C: AUTH KERBEROS_V4 145 S: + AmFYig== 146 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 147 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 148 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 149 S: + or//EoAADZI= 150 C: DiAF5A4gA+oOIALuBkAAmw== 151 S: +OK Kerberos V4 authentication successful 152 ... 153 C: AUTH FOOBAR 154 S: -ERR Unrecognized authentication type 155 C: AUTH SKEY c21pdGg= 156 S: + OTUgUWE1ODMwOA== 157 C: BsAY3g4gBNo= 158 S: +OK S/Key authentication successful 160 Note: the line breaks in the first client answer are 161 for editorial clarity and are not in real 162 authenticators. 164 4. Formal Syntax 166 The following syntax specification uses the augmented Backus-Naur 167 Form (BNF) notation as specified in RFC 822. 169 Except as noted otherwise, all alphabetic characters are case- 170 insensitive. The use of upper or lower case characters to define 171 token strings is for editorial clarity only. Implementations MUST 172 accept these strings in a case-insensitive fashion. 174 ATOM_CHAR = 176 atom_specials = "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / 177 <"> / "\" 179 auth = "AUTH" [ 1*(SPACE / TAB) auth_type 180 [ 1*(SPACE / TAB) base64 ] *(CRLF base64) ] CRLF 182 auth_type = 1*ATOM_CHAR 184 base64 = *(4base64_CHAR) [base64_terminal] 186 base64_char = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / 187 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / 188 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 189 "Y" / "Z" / 190 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / 191 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / 192 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / 193 "y" / "z" / 194 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / 195 "8" / "9" / "+" / "/" 196 ;; Case-sensitive 198 base64_terminal = (2base64_char "==") / (3base64_char "=") 200 CHAR = 203 continue_req = "+" SPACE base64 CRLF 205 CR = 207 CRLF = CR LF 209 CTL = 212 LF = 214 SPACE = 216 TAB = 218 5. References 220 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 221 Requirement Levels", RFC 2119, March 1997 223 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3.", RFC 224 1939, May 1996 226 [SASL] Myers, J., "Simple Authentication and Security Layer", 227 RFC 2222, October 1997 229 6. Security Considerations 231 Security issues are discussed throughout this memo. 233 Additional security considerations are mentioned in the SASL 234 specification [SASL]. 236 7. Author's Address: 238 John Gardiner Myers 239 Netscape Communications 240 501 East Middlefield Road 241 Mail Stop MV-029 242 Mountain View, CA 94043 244 Email: jgmyers@netscape.com