idnits 2.17.1 draft-dewinter-nntp-sasl-auth-00.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-25) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 227 lines 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. ** There are 14 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 154: '...al clarity only. Implementations MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 143 has weird spacing: '... answer are...' -- 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 (17 December 1996) is 9991 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 1734 (ref. 'POP3-AUTH') (Obsoleted by RFC 5034) == Outdated reference: A later version (-12) exists of draft-myers-auth-sasl-04 Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J. De Winter 2 Expires in six months Wildbear Consulting, Inc. 3 17 December 1996 5 NNTP SASL AUTHentication command 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 21 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 1. Introduction 27 This document describes the optional AUTHSASL command, for indicating an 28 authentication mechanism to the server, performing an authentication 29 protocol exchange, and optionally negotiating a protection mechanism 30 for subsequent protocol interactions. The authentication and 31 protection mechanisms used by the NNTP AUTHSASL command are those used by 32 SASL draft. 34 Please note that large portions of this document are copied from 35 [POP3-AUTH] with the permission of the author of that document, John G. 36 Meyers. 38 2. The AUTHSASL command 40 AUTHSASL mechanism 42 Arguments: 43 a string identifying an SASL authentication mechanism, 44 such as defined by [SASL]. If no mechanism is identified 45 after the AUTHSASL command, it is interpretted as a request 46 for a list of all mechanisms supported by the server. 48 Restrictions: 49 may only be given in the AUTHORIZATION state 51 Discussion: 52 The AUTHSASL command indicates an authentication mechanism to 53 the server. If the server supports the requested 54 authentication mechanism, it performs an authentication 55 protocol exchange to authenticate and identify the user. 56 Optionally, it also negotiates a protection mechanism for 57 subsequent protocol interactions. If the requested 58 authentication mechanism is not supported, the server 59 should reject the AUTHSASL command by sending a negative 60 response. 62 The authentication protocol exchange consists of a series 63 of server challenges and client answers that are specific 64 to the authentication mechanism. A server challenge, 65 otherwise known as a ready response, is a line consisting 66 of a string starting with the 350 continue authortization response 67 code followed by a space, and then followed by a BASE64 encoded string. 68 The client answer consists solely of a line containing a 69 BASE64 encoded string. If the client wishes 70 to cancel an authentication exchange, it should issue a 71 line with a single "*". If the server receives such an 72 answer, it must reject the AUTHSASL command by sending a 73 negative response. 75 A protection mechanism provides integrity and privacy 76 protection to the protocol session. If a protection 77 mechanism is negotiated, it is applied to all subsequent 78 data sent over the connection. The protection mechanism 79 takes effect immediately following the CRLF that concludes 80 the authentication exchange for the client, and the CRLF of 81 the positive response for the server. Once the protection 82 mechanism is in effect, the stream of command and response 83 octets is processed into buffers of ciphertext. Each 84 buffer is transferred over the connection as a stream of 85 octets prepended with a four octet field in network byte 86 order that represents the length of the following data. 87 The maximum ciphertext buffer length is defined by the 88 protection mechanism. 90 The server is not required to support any particular 91 authentication mechanism, nor are authentication mechanisms 92 required to support any protection mechanisms. If an AUTHSASL 93 command fails with a negative response, the session remains 94 in the AUTHORIZATION state and client may try another 95 authentication mechanism by issuing another AUTHSASL command, 96 or may attempt to authenticate by using other available 97 authentication commands. In other words, the client may request 98 authentication types in decreasing order of preference, 99 with the AUTH USER command as a last resort. 101 If a request for a list of all the supported authenticated mechanisms 102 is received, the server will return the list of supported mechanisms, 103 each mechanism on a separate line. The end of the list is denoted by 104 the period character ('.') on a line by itself. While improbable, it 105 is possible that an implementation of AUTHSASL will return a null list, 106 that is a list consisting of no mechanisms. 108 Should the client successfully complete the authentication 109 exchange, the NNTP server issues a positive response and 110 the NNTP session enters the EXCHANGE state. 112 Possible Responses: 113 215 List of supported mechanisms follows. 114 250 Authorization accepted 115 350 Continue with authorization sequence 116 452 Authorization rejected 117 501 Command not supported 118 502 Authentication mechanism not defined. 120 Examples: 121 ... 122 C: AUTHSASL 123 S: KERBEROS_V4 124 S: . 125 ... 126 C: AUTHSASL KERBEROS_V4 127 S: 350 AmFYig== 128 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 129 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 130 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 131 S: 350 or//EoAADZI= 132 C: DiAF5A4gA+oOIALuBkAAmw== 133 S: 250 Kerberos V4 authentication successful 134 ... 135 C: AUTHSASL KERBEROS_V4 136 S: 350 AmFYig== 137 C: * 138 S: 452 Authorization rejected 139 ... 140 C: AUTHSASL FOOBAR 141 S: 502 Unrecognized authentication type 143 Note: the line breaks in the first client answer are 144 for editorial clarity and are not in real authentica- 145 tors. 147 3. Formal Syntax 149 The following syntax specification uses the augmented Backus-Naur 150 Form (BNF) notation as specified in RFC 822. 152 Except as noted otherwise, all alphabetic characters are case- 153 insensitive. The use of upper or lower case characters to define 154 token strings is for editorial clarity only. Implementations MUST 155 accept these strings in a case-insensitive fashion. 157 ATOM_CHAR ::= 159 atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / 160 <"> / "\" 162 auth ::= "AUTHSASL" 1*(SPACE / TAB) auth_type *(CRLF base64) 163 CRLF 165 auth_type ::= 0*ATOM_CHAR 167 base64 ::= *(4base64_CHAR) [base64_terminal] 169 base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / 170 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / 171 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 172 "Y" / "Z" / 173 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / 174 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / 175 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / 176 "y" / "z" / 177 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / 178 "8" / "9" / "+" / "/" 179 ;; Case-sensitive 181 base64_terminal ::= (2base64_char "==") / (3base64_char "=") 183 CHAR ::= 186 continue_req ::= "350" SPACE base64 CRLF 188 CR ::= 190 CRLF ::= CR LF 192 CTL ::= 195 LF ::= 197 SPACE ::= 199 TAB ::= 201 4. References 203 [POP3-AUTH] Myers, J., "POP3 Authentication Mechanisms", RFC 1734, 204 Carnegie Mellon, December 1994. 206 [SASL] Myers, J., "Simple Authentication and Security Layer", 207 draft-myers-auth-sasl-04.txt, July 1996 (not yet published as an RFC) 209 5. Security Considerations 211 Security issues are discussed throughout this memo. 213 6. Author's Address 215 Jack De Winter 216 Wildbear Consulting, Inc. 217 17 Brock Street 218 Kitchener, Ontario, Canada 219 N2M 1X2 221 Email: jack@wildbear.on.ca