idnits 2.17.1 draft-siemborski-rfc1734bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 197 instances of lines with control characters in the document. -- The abstract seems to indicate that this document obsoletes RFC1734, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 445 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Intended Category: Proposed Standard ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ABNF' is mentioned on line 348, but not defined ** Obsolete normative reference: RFC 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 1734 (ref. 'POP3-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Siemborski 3 INTERNET-DRAFT Carnegie Mellon University 4 Intended Category: Proposed Standard October, 2003 6 POP3 SASL Authentication Mechanism 8 10 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Task Force 15 (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Abstract 33 This document defines a profile of the Simple Authentication and 34 Security Layer (SASL) for the Post Office Protocol (POP3). This 35 extension allows a POP3 client to indicate an authentication 36 mechanism to the server, perform an authentication protocol 37 exchange, and optionally negotiate a security layer for subsequent 38 protocol interactions during this session. 40 This document obsoletes RFC 1734 and replaces it as a Proposed 41 Standard. It also updates information contained in Section 6.3 of 42 RFC 2449. 44 1. How to Read This Document 46 The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 47 "RECOMMENDED", and "MAY" in this document are to be interpreted as 49 POP3 SASL Authentication Mechanism October, 2003 51 Table of Contents 53 1. How to Read This Document . . . . . . . . . . . . . . . . . . . . 1 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The SASL Capability . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 61 8. Intellectual Property Rights . . . . . . . . . . . . . . . . . . 9 62 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 11. Changes From RFC 1734 and RFC 2449 . . . . . . . . . . . . . . . 11 65 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 66 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 68 POP3 SASL Authentication Mechanism October, 2003 70 defined in "Key words for use in RFCs to Indicate Requirement 71 Levels" [KEYWORDS] 73 In examples, "C:" and "S:" indicate lines sent by the client and 74 server respectively. 76 2. Introduction 78 The AUTH command [POP3-AUTH] in [POP3] has suffered several 79 deficiencies in its specification. The first is that it was very 80 similar to a [SASL] framework, but pre-dated the initial SASL 81 specification. It was therefore missing some key components, such 82 as a way to list the available authentication mechanisms. Later, 83 [POP3-EXT] attempted to remedy this situation by adding the CAPA 84 command, and allowing an initial client response to the AUTH 85 command, however problems in the specification of how the initial 86 client response was to be handled remained. This document attempts 87 to combine all of the POP3 SASL authentication related details into 88 a single document. 90 3. The SASL Capability 92 This section supercedes the definition of the SASL Capability in 93 section 6.3 of [POP3-EXT]. 95 CAPA tag: 96 SASL 98 Arguments: 99 Supported SASL Mechanisms 101 Standard Commands Affected 102 None 104 Announced states / possible differences: 105 both / no 107 Commands valid in states: 108 AUTHENTICATION 110 Specification Reference: 111 This Document, [SASL] 113 Discussion 114 The SASL capability permits the use of the AUTH command (as 115 defined in section 4 of this document) to begin a [SASL] 116 negotiation. The arguments to the SASL capability is a space- 117 separated list of SASL mechanisms which are supported. 119 POP3 SASL Authentication Mechanism October, 2003 121 If a server either does not support the CAPA command or does not 122 advertise the SASL capability, clients SHOULD NOT attempt the 123 AUTH command. If a client does attempt the AUTH command in such 124 a situation, it MUST NOT supply the client initial response 125 parameter (for backwards compatibility with [POP3-AUTH]). 127 Note that the list of available mechanisms MAY change after a 128 successful STLS command [POP3-TLS]. Additionally, 129 implementations MAY choose to omit the SASL capability after a 130 successful AUTH command has been completed. 132 Example 134 S: +OK pop.example.com BlurdyBlurp POP3 server ready 135 C: CAPA 136 S: +OK List of capabilities follows 137 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 138 S: STLS 139 S: IMPLEMENTATION BlurdyBlurp POP3 server 140 S: . 142 4. The AUTH Command 144 AUTH mechanism [initial-response] 146 Arguments: 147 mechanism: A string identifying a [SASL] authentication 148 mechanism. 150 initial-response: An optional initial client response. If 151 present, this response MUST be [BASE64] encoded. 153 Restrictions: 154 After an AUTH command has been successfully completed, no more 155 AUTH commands may be issued in the same session. After a 156 successful AUTH command completes, a server MUST reject any 157 further AUTH commands with a -ERR reply. 159 The AUTH command may only be given during the AUTHORIZATION 160 state. 162 Discussion: 163 The AUTH command initiates a [SASL] authentication exchange 164 between the client and the server. The client identifies the 165 SASL mechanism to use with the first parameter of the AUTH 166 command. If the server supports the requested authentication 167 mechanism, it performs the SASL exchange to authenticate the 169 POP3 SASL Authentication Mechanism October, 2003 171 user. Optionally, it also negotiates a security layer for 172 subsequent protocol interactions during this session. If the 173 requested authentication mechanism is not supported, the 174 server rejects the AUTH command with a -ERR reply. 176 The authentication protocol exchange consists of a series of 177 server challenges and client responses that are specific to 178 the chosen [SASL] mechanism. 180 A server challenge is sent as a line consisting of a "+" 181 character followed by a single space and a [BASE64] encoded 182 string supplied by the SASL mechanism. This challenge MUST 183 NOT contain any text other than the BASE64 encoded challenge. 185 A client response consists of a line containing a [BASE64] 186 encoded string. If the client wishes to cancel the 187 authentication exchange, it issues a line with a single "*". 188 If the server receives such a response, it MUST reject the 189 AUTH command by sending a -ERR reply. 191 The optional initial response argument to the AUTH command is 192 used to save a round trip when using authentication mechanisms 193 that support an initial client response. If the initial 194 response argument is omitted and the chosen mechanism requires 195 an initial client response, the server MUST proceed as defined 196 in section 5.1 of [SASL]. In POP3, a server challenge with no 197 data is defined as line with only a "+" followed by a single 198 space. It MUST NOT contain any other data. 200 For the purposes of the initial client response, the line 201 length limitation defined in [POP3-EXT] still applies. If a 202 client initial send would cause the AUTH command to exceed 203 this length, the client MUST NOT use the initial response 204 parameter (and instead proceed as defined in section 5.1 of 205 [SASL]). 207 If the client needs to send a zero-length initial response, 208 the client MUST transmit the response as a single equals sign 209 ("="). This indicates that the response is present, but 210 contains no data. 212 If the client uses an initial-response argument to the AUTH 213 command with a SASL mechanism that does not support an initial 214 client send, the server MUST reject the AUTH command with a 215 -ERR reply. 217 If the server cannot [BASE64] decode any client response, it 218 MUST reject the AUTH command with a -ERR reply. If the client 220 POP3 SASL Authentication Mechanism October, 2003 222 cannot BASE64 decode any of the server's challenges, it MUST 223 cancel the authentication using the "*" response. In 224 particular, servers and clients MUST reject (and not ignore) 225 any character not explicitly allowed by the BASE64 alphabet, 226 and MUST reject any sequence of BASE64 characters that 227 contains the pad character ('=') anywhere other than the end 228 of the string (e.g. "=AAA" and "AAA=BBB" are not allowed). 230 Note that these [BASE64] strings (excepting the initial client 231 response) may be of arbitrarily length. Clients and servers 232 MUST be able to handle the maximum encoded size of challenges 233 and responses generated by their supported authentication 234 mechanisms. This requirement is independent of any line 235 length limitations the client or server may have in other 236 parts of its protocol implementation. 238 If the server is unable to authenticate the client, it MUST 239 reject the AUTH command with a -ERR reply. Should the client 240 successfully complete the exchange, the server issues a +OK 241 reply. Additionally, upon success, the POP3 session enters 242 the TRANSACTION state. 244 If a security layer is negotiated during the SASL exchange, it 245 takes effect for the client on the octet immediately following 246 the CRLF that concludes the last response generated by the 247 client. For the server, it takes effect immediately following 248 the CRLF of its success reply. 250 When a security layer takes effect, the server MUST discard 251 any knowledge previously obtained from the client, which was 252 not obtained from the SASL negotiation itself. Likewise, the 253 client MUST discard any knowledge obtained from the server, 254 such as the list of available POP3 service extensions. After 255 a security layer is established, the server SHOULD NOT 256 advertise either the SASL or the STLS extension. 258 When both [TLS] and SASL security layers are in effect, the 259 TLS encoding MUST be applied after the SASL encoding, 260 regardless of the order in which the layers were negotiated. 262 The service name specified by this protocol's profile of SASL 263 is "pop". 265 If an AUTH command fails, the client may try another 266 authentication mechanism or present different credentials by 267 issuing another AUTH command (or by using one of the other 268 [POP3] authentication mechanisms). Likewise, the server MUST 269 behave as if the client had not issued the AUTH command. 271 POP3 SASL Authentication Mechanism October, 2003 273 To ensure interoperability, client and server implementations 274 of this extension MUST implement the STLS extension, and the 275 PLAIN SASL mechanism [POP3-TLS]. Implementations MUST support 276 a configuration where [SASL] mechanisms that are vulnerable to 277 passive eavesdropping attacks are not advertised or used 278 without the presence of an external security layer such as 279 [TLS]. 281 4.1. Examples 283 Here is an example of a client attempting AUTH PLAIN under TLS and 284 making use of the initial client response: 286 S: +OK pop.example.com BlurdyBlurp POP3 server ready 287 C: CAPA 288 S: +OK List of capabilities follows 289 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 290 S: STLS 291 S: IMPLEMENTATION BlurdyBlurp POP3 server 292 S: . 293 C: STLS 294 S: +OK Begin TLS negotiation now 295 ... TLS negotiation proceeds, further commands protected by TLS layer ... 296 C: CAPA 297 S: +OK List of capabilities follows 298 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 299 S: IMPLEMENTATION BlurdyBlurp POP3 server 300 S: . 301 C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q= 302 S: +OK Maildrop locked and ready 304 Here is another client that is attempting AUTH PLAIN under a TLS 305 layer, this time without the initial response. Parts of the 306 negotiation before the TLS layer was established have been omitted: 308 ... TLS negotiation proceeds, further commands protected by TLS layer ... 309 C: CAPA 310 S: +OK List of capabilities follows 311 S: SASL PLAIN KERBEROS_V4 GSSAPI ANONYMOUS 312 S: IMPLEMENTATION BlurdyBlurp POP3 server 313 S: . 314 C: AUTH PLAIN 315 (note that there is a space following the '+' on the following line) 316 S: + 317 C: dGVzdAB0ZXN0AHRlc3Q= 318 S: +OK Maildrop locked and ready 320 Here is an example using a mechanism which does not support an 322 POP3 SASL Authentication Mechanism October, 2003 324 initial client send, and includes server challenges: 326 S: +OK pop.example.com BlurdyBlurp POP3 server ready 327 C: CAPA 328 S: +OK List of capabilities follows 329 S: SASL KERBEROS_V4 GSSAPI ANONYMOUS 330 S: STLS 331 S: IMPLEMENTATION BlurdyBlurp POP3 server 332 S: . 333 C: AUTH KERBEROS_V4 334 S: + ezLUFA== 335 (the following lines are broken for editorial clarity only) 336 C: BAYFQU5EUkVXLkNNVS5FRFUAOCCXeMiVyFe9K6Nwne7+sPLgIoF9YQ5ePfxUsMlJAf 337 C7aoNySU8nrqS9m8JAddsUeuyc5HFXXovaKLrZNo2bTLH0Lyolwy0W9ryJDojbKmHy 338 zSMqFsGD4EL0 339 S: + Z74fTwDw7KQ= 340 C: vSAF7ha6qotK2UHUgKlsEA== 341 S: +OK Maildrop locked and ready 342 ... at this point a security layer has been established and additional 343 commands and responses proceed within it ... 345 5. Formal Syntax 347 The following syntax specification uses the Augmented Backus-Naur 348 Form notation as specified in [ABNF]. 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 UPALPHA = %x41-5A ;; Uppercase: A-Z 357 LOALPHA = %x61-7A ;; Lowercase: a-z 359 ALPHA = UPALPHA / LOALPHA ;; case insensitive 361 DIGIT = %x30-39 ;; Digits 0-9 363 AUTH_CHAR = ALPHA / DIGIT / "-" / "_" 365 auth_type = 1*20AUTH_CHAR 367 auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] 368 *(CRLF [base64]) CRLF 370 POP3 SASL Authentication Mechanism October, 2003 372 base64 = base64_terminal / 373 ( 1*(4base64_CHAR) [base64_terminal] ) 375 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 376 ;; Case-sensitive 378 base64_terminal = (2base64_char "==") / (3base64_char "=") 380 continue_req = "+" SPACE [base64] CRLF 382 CR = %x0C ;; ASCII CR, carriage return 384 CRLF = CR LF 386 LF = %x0A ;; ASCII LF, line feed 388 SPACE = %x20 ;; ASCII SP, space 390 6. Security Considerations 392 Security issues are discussed throughout this memo. 394 Before the [SASL] negotiation has begun, any protocol interactions 395 are performed in the clear and may be modified by an active 396 attacker. For this reason, clients and servers MUST discard any 397 knowledge obtained prior to the start of the SASL negotiation upon 398 the establishment of a security layer. 400 7. IANA Considerations 402 This document requests that the IANA update the entry for the "pop" 403 SASL protocol name to point at this document. 405 This document requests that the IANA update the entry for the SASL 406 POP3 capability to be as defined in Section 3 of this document. 408 8. Intellectual Property Rights 410 The IETF takes no position regarding the validity or scope of any 411 intellectual property or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; neither does it represent that it 415 has made any effort to identify any such rights. Information on the 416 IETF's procedures with respect to rights in standards-track and 417 standards-related documentation can be found in BCP-11. Copies of 418 claims of rights made available for publication and any assurances 420 POP3 SASL Authentication Mechanism October, 2003 422 of licenses to be made available, or the result of an attempt made 423 to obtain a general license or permission for the use of such 424 proprietary rights by implementors or users of this specification 425 can be obtained from the IETF Secretariat. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights which may cover technology that may be required to practice 430 this standard. Please address the information to the IETF Executive 431 Director. 433 9. Copyright 435 Copyright (C) The Internet Society (2003). All Rights Reserved. 437 This document and translations of it may be copied and furnished to 438 others, and derivative works that comment on or otherwise explain it 439 or assist in its implementation may be prepared, copied, published 440 and distributed, in whole or in part, without restriction of any 441 kind, provided that the above copyright notice and this paragraph 442 are included on all such copies and derivative works. However, this 443 document itself may not be modified in any way, such as by removing 444 the copyright notice or references to the Internet Society or other 445 Internet organizations, except as needed for the purpose of 446 developing Internet standards in which case the procedures for 447 copyrights defined in the Internet Standards process must be 448 followed, or as required to translate it into languages other than 449 English. 451 This document and the information contained herein is provided on an 452 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 453 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 454 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 455 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 456 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 458 POP3 SASL Authentication Mechanism October, 2003 460 10. References 462 The following documents contain normative definitions or 463 specifications that are necessary for correct understanding of this 464 protocol: 466 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 467 Encodings", RFC 3548, July 2003. 469 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997 472 [POP3] Myers, J. & Rose, M., "Post Office Protocol - Version 3", 473 STD 53, RFC 1939, May 1996. 475 [POP3-EXT] Gellens, R., Newman, C. & Lundblade, L., "POP3 Extension 476 Mechanism", RFC 2449, November 1998. 478 [POP3-TLS] Newman, C. "Using TLS with IMAP, POP3, and ACAP", RFC 2595, 479 June 1999. 481 [SASL] Myers, J., "Simple Authentication and Security Layer 482 (SASL)", RFC 2222, October 1997. 484 The following references are for informational purposes only: 486 [POP3-AUTH] Myers, J., "POP3 AUTHentication Command", RFC 1734, January 487 1994. 489 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 490 2246, January 1999. 492 11. Changes From RFC 1734 and RFC 2449 494 1. The SASL-based semantics defined in RFC 2449 are now 495 normative for the AUTH extension. 497 2. Clarifications and examples of the proper behavior of 498 initial client response handling. 500 3. Minimum requirement of support for TLS+PLAIN. 502 4. Clarify ordering of TLS and SASL security layers. 504 5. Update references to newer versions of various 505 specifications. 507 POP3 SASL Authentication Mechanism October, 2003 509 6. Clarify that the mechanism list can change. 511 7. General other editorial clarifications. 513 12. Author's Address: 515 Robert Siemborski 516 Carnegie Mellon, Andrew Systems Group 517 Cyert Hall 207 518 5000 Forbes Avenue 519 Pittsburgh, PA 15213 520 +1 412 268 7456 521 rjs3+@andrew.cmu.edu 523 13. Acknowledgments: 525 The author would like to acknowledge the contributions of John Myers 526 and other contributors to RFC 1734, on which this document draws 527 heavily. 529 The author would also like to thank Ken Murchison and Mark Crispin 530 for the time they devoted to reviewing early drafts of this 531 document.