idnits 2.17.1 draft-ietf-nntpext-authinfo-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 976. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([NNTP], [NNTP-COMMON], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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). -- 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 (September 2004) is 7163 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) == Missing Reference: 'C' is mentioned on line 620, but not defined == Missing Reference: 'S' is mentioned on line 621, but not defined -- Looks like a reference, but probably isn't: '1' on line 382 == Unused Reference: 'ABNF' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'CRAM-MD5' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'SMTP' is defined on line 898, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'AUTH') ** Obsolete normative reference: RFC 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) -- No information found for draft-ietf-nntpext-base- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NNTP' -- No information found for draft-ietf-nntpext-tls-nntp- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NNTP-TLS' -- No information found for draft-ietf-sasl-rfc2222bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-sasl-saslprep- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLprep' -- No information found for draft-hoffman-rfc3454bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'StringPrep' -- No information found for draft-ietf-sasl-crammd5- - is the name correct? -- No information found for draft-ietf-sasl-gssapi- - is the name correct? -- No information found for draft-ietf-sasl-plain- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Vinocur 3 Internet Draft Cornell University 4 Document: draft-ietf-nntpext-authinfo-04.txt C. Newman 5 Sun Microsystems 6 K. Murchison 7 Oceana Matrix Ltd. 8 September 2004 10 NNTP Extension for Authentication 12 Status of this memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document defines a profile of the Simple Authentication and 39 Security Layer [SASL] for the Network News Transport Protocol 40 [NNTP] protocol and updates/deprecates information contained in 41 Section 3.1 of [NNTP-COMMON]. This extension allows an NNTP client 42 to indicate an authentication mechanism to the server, perform an 43 authentication protocol exchange, and optionally negotiate a 44 security layer for subsequent protocol interactions during the 45 remainder of an NNTP session. 47 Table of Contents 49 1. Introduction ............................................. 2 50 1.1. Conventions Used in this Document ................... 3 51 2. The AUTHINFO Extension ................................... 3 52 2.1. Advertising the AUTHINFO Extension .................. 3 53 2.2. Authenticating with the AUTHINFO Extension .......... 4 54 2.3. AUTHINFO USER/PASS Command .......................... 6 55 2.3.1. Usage .......................................... 6 56 2.3.2. Description .................................... 6 57 2.3.3. Examples ....................................... 7 58 2.4. AUTHINFO SASL Command ............................... 8 59 2.4.1. Usage .......................................... 8 60 2.4.2. Description .................................... 9 61 2.4.3. Examples ....................................... 12 62 3. Augmented BNF Syntax for the AUTHINFO Extension .......... 14 63 3.1. Commands ............................................ 14 64 3.2. Command Continuation ................................ 14 65 3.3. Responses ........................................... 15 66 3.4. LIST EXTENSIONS responses ........................... 15 67 3.5. General non-terminals ............................... 15 68 4. Summary of Response Codes ................................ 15 69 5. Authentication Tracking/Logging .......................... 16 70 6. Security Considerations .................................. 16 71 7. IANA Considerations ...................................... 17 72 7.1. IANA Considerations for SASL/GSSAPI services ........ 17 73 7.2. IANA Considerations for NNTP extensions ............. 17 74 8. References ............................................... 18 75 8.1. Normative References ................................ 18 76 8.2. Informative References .............................. 19 77 9. Authors' Addresses ....................................... 19 78 10. Acknowledgments ......................................... 20 79 11. Intellectual Property Rights ............................ 20 80 12. Copyright ............................................... 21 82 1. Introduction 84 Although NNTP [NNTP] has traditionally provided public access to 85 newsgroups, authentication is often useful, for example to control 86 resource consumption, to allow abusers of the POST command to be 87 identified, and to restrict access to "local" newsgroups. 89 The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in 90 [NNTP-COMMON], provide a very weak authentication mechanism in 91 widespread use by the installed base. Due to their insecurity and 92 ubiquity they are formalized in this specification, but only for 93 use in combination with appropriate security layers. 95 The ad-hoc AUTHINFO GENERIC command, also documented in [NNTP- 96 COMMON] but much less ubiquitous, provided an NNTP-specific 97 equivalent of the generic SASL [SASL] facility. This document 98 deprecates AUTHINFO GENERIC in favor of an AUTHINFO SASL 99 replacement so that NNTP can benefit from authentication mechanisms 100 developed for other SASL-enabled application protocols including 101 SMTP, POP, IMAP, LDAP, and BEEP. 103 This specification is to be read in conjunction with the NNTP base 104 specification [NNTP]. Except where specifically stated otherwise, 105 in the case of a conflict between these two documents [NNTP] takes 106 precedence over this one. 108 It is also recommended that this specification be read in 109 conjunction with the SASL base specification [SASL]. 111 1.1. Conventions Used in this Document 113 The notational conventions used in this document are the same as 114 those in [NNTP] and any term not defined in this document has the 115 same meaning as in that one. 117 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 118 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 119 as described in "Key words for use in RFCs to Indicate Requirement 120 Levels" [KEYWORDS]. 122 Terms related to authentication are defined in "On Internet 123 Authentication" [AUTH]. 125 In the examples, commands from the client are indicated with [C], 126 and responses from the server are indicated with [S]. 128 2. The AUTHINFO Extension 130 The AUTHINFO extension is used to authenticate a user. Note that 131 authorization is a matter of site policy, not network protocol, and 132 is therefore not discussed in this document. The server determines 133 authorization in whatever manner is defined by its implementation 134 as configured by the site administrator. 136 This extension provides three new commands: AUTHINFO USER, AUTHINFO 137 PASS, and AUTHINFO SASL. The label for this extension is AUTHINFO. 139 2.1. Advertising the AUTHINFO Extension 141 A server MUST implement at least one of the AUTHINFO USER or 142 AUTHINFO SASL commands in order to advertise the AUTHINFO extension 143 label in the response to the LIST EXTENSIONS command. The AUTHINFO 144 extension label contains an argument list detailing which 145 authentication commands are available. 147 The "USER" argument indicates that AUTHINFO USER/PASS is supported 148 as defined by Section 2.3 of this document. The "USER" argument 149 MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD 150 NOT be provided, unless a strong encryption layer (e.g. TLS [NNTP- 151 TLS]) is in use or backward compatibility dictates otherwise. 153 The "SASL:" argument indicates that AUTHINFO SASL is supported as 154 defined by Section 2.4 of this document. The "SASL:" argument is 155 followed immediately (no intervening whitespace) by a comma- 156 separated list of available SASL mechanism names, and the colon 157 (":") is always included even if no mechanisms are available. 159 The server may list the AUTHINFO capability with no arguments, 160 which indicates that it complies with this draft and does not 161 permit any authentication commands in its current state. In this 162 case, the client MUST NOT attempt to utilize any AUTHINFO commands, 163 even if it contains logic to do so (e.g. for backward compatibility 164 with servers that are not compliant with this specification). 166 Future extensions may add additional arguments to this capability. 167 Unrecognized arguments SHOULD be ignored or brought to the 168 attention of the user. 170 Example: 171 [C] LIST EXTENSIONS 172 [S] 202 Extensions supported: 173 [S] STARTTLS 174 [S] AUTHINFO SASL:CRAM-MD5,DIGEST-MD5,GSSAPI 175 [S] . 176 [C] STARTTLS 177 [S] 382 Continue with TLS negotiation 178 [TLS negotiation proceeds, further commands protected by TLS layer] 179 [C] LIST EXTENSIONS 180 [S] 202 Extensions supported: 181 [S] AUTHINFO USER SASL:CRAM-MD5,DIGEST-MD5,GSSAPI,PLAIN,EXTERNAL 182 [S] . 184 2.2. Authenticating with the AUTHINFO Extension 186 When an NNTP server responds to a client command with a 480 187 response, this indicates the client MUST authenticate and/or 188 authorize in order to use that command or access the indicated 189 resource. Use of the AUTHINFO command as described below is one 190 such way that a client can authenticate/authorize to the server. A 191 client intending to use AUTHINFO may issue the LIST EXTENSIONS 192 command to obtain the available authentication commands and 193 mechanisms before attempting authentication. 195 A client MAY attempt the first step of authentication at any time 196 during a session to acquire additional privileges without having 197 received a 480 response. The client MUST NOT under any 198 circumstances continue with any steps of authentication beyond the 199 first, unless the response code from the server indicates that the 200 authentication exchange is welcomed. In particular, anything other 201 than a 38x response code indicates that the client MUST NOT 202 continue the authentication exchange. 204 Servers are not required to accept unsolicited authentication 205 information from the client, therefore clients MUST accommodate 206 servers that reject such authentication information. Additionally, 207 servers may accept authentication information and yet still deny 208 access to some or all resources; the permanent 502 response 209 indicates a resource is unavailable even though authentication has 210 been performed (this is in contrast to the temporary 480 error 211 indicating that a resource is unavailable now but may become 212 available after authentication). 214 After a successful authentication, the client may retry the 215 original command (if any) to which the server replied with the 480 216 response, or continue with some other command (for example, the 217 client may wish to re-fetch the list of newsgroups). 219 A server MUST NOT under any circumstances reply to an AUTHINFO 220 command with a 480 response. 222 After an AUTHINFO command has been successfully completed, no more 223 AUTHINFO commands may be issued in the same session and a server 224 MUST reject any further AUTHINFO commands with a 502 response. 226 In agreement with [SASL], after a security layer is established the 227 server MUST continue to advertise the AUTHINFO capability and 228 "SASL:" argument with the same mechanism list as before 229 authentication. 231 Note that a successful AUTHINFO command may cause the output of the 232 LIST EXTENSIONS command to change. Any successful authentication 233 MAY result in the server listing different arguments (perhaps 234 listing zero arguments) for AUTHINFO, but MUST NOT result in the 235 AUTHINFO capability being removed entirely from LIST EXTENSIONS (as 236 this might falsely indicate to clients that they were dealing with 237 a non-compliant server). Additionally, after a successful AUTHINFO 238 SASL, the SASL: capability MUST continue to be advertised as 239 described in section 2.4.2. 241 2.3. AUTHINFO USER/PASS Command 243 This section supersedes the definition of the AUTHINFO USER and 244 AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP- 245 COMMON]. 247 These commands MUST NOT be pipelined. 249 2.3.1. Usage 251 Syntax 252 AUTHINFO USER username 253 AUTHINFO PASS password 255 Responses 256 281 Authentication accepted 257 381 Password required [1] 258 481 Authentication failed/rejected 259 482 Authentication commands issued out of sequence 261 [1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx 262 codes which indicate that the client may continue the current 263 command, the legacy 381 code means that the AUTHINFO PASS command 264 must be used to complete the authentication exchange. 266 Parameters 267 username = UTF-8 string identifying the user/client 268 password = UTF-8 string representing the user's password 270 2.3.2. Description 272 The AUTHINFO USER and AUTHINFO PASS commands are used to present 273 clear text credentials to the server. These credentials consist of 274 a username or a username plus a password (the distinction is that a 275 password is expected to be kept secret while a username is not; 276 this does not directly affect the protocol but may have an impact 277 on user interfaces). The username is supplied through the AUTHINFO 278 USER command and the password through the AUTHINFO PASS command. 280 If the server requires only a username, it MUST NOT give a 381 281 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO 282 PASS. 284 If the server requires both username and password, the former MUST 285 be sent before the latter. The server will need to cache the 286 username until the password is received; it MAY require the 287 password to be sent in the immediately next command (in other 288 words, only caching the username until the next command is sent). 289 The server: 291 - MUST return a 381 response to AUTHINFO USER; 292 - MUST return a 482 response to AUTHINFO PASS if there is no cached 293 username; 294 - MUST use the argument of the most recent AUTHINFO USER for 295 authentication; 296 - MUST NOT return a 381 response to AUTHINFO PASS. 298 The server MAY determine whether or not a password is needed based 299 on the username. Thus the same server can respond with both 381 and 300 other response codes to AUTHINFO USER. 302 The AUTHINFO PASS command permits the client to use a clear-text 303 password to authenticate. A conformant implementation MUST NOT 304 implement this mechanism without also implementing support for TLS 305 [NNTP-TLS]. Use of this mechanism without an active strong 306 encryption layer is deprecated as it exposes the user's password to 307 all parties on the network between the client and the server. Any 308 implementation of this mechanism SHOULD be configurable to disable 309 it unless a strong encryption layer such as that provided by [NNTP- 310 TLS] is active, and this configuration SHOULD be the default. The 311 server will use the 483 response code to indicate that the 312 datastream is insufficiently secure for the command being 313 attempted. 315 Usernames and passwords MUST use the UTF-8 [UTF-8] character set 316 and a client MUST convert any user input to UTF-8 if necessary. 318 Note that a server MAY, but is not required to, allow white space 319 characters in usernames and passwords. A server implementation MAY 320 blindly split command arguments at white space and therefore not 321 preserve the exact sequence of white space characters in the 322 username or password. Therefore a client SHOULD scan the username 323 and password for whitespace, and if detected, warn the user of the 324 likelihood of problems. The SASL PLAIN [PLAIN] mechanism is 325 recommended as an alternative as it does not suffer from these 326 issues. 328 2.3.3. Examples 330 Example of successful AUTHINFO USER: 332 [C] AUTHINFO USER wilma 333 [S] 281 Authentication accepted 335 Example of successful AUTHINFO USER/PASS: 337 [C] AUTHINFO USER fred 338 [S] 381 Enter passphrase 339 [C] AUTHINFO PASS flintstone 340 [S] 281 Authentication accepted 342 Example of AUTHINFO USER/PASS requiring a security layer: 344 [C] AUTHINFO USER fred@stonecanyon.example 345 [S] 483 Encryption or stronger authentication required 347 Example of failed AUTHINFO USER/PASS: 349 [C] AUTHINFO USER barney 350 [S] 381 Enter passphrase 351 [C] AUTHINFO PASS flintstone 352 [S] 481 Authentication failed 354 Example of AUTHINFO PASS before AUTHINFO USER: 356 [C] AUTHINFO PASS flintstone 357 [S] 482 Authentication commands issued out of sequence 359 2.4. AUTHINFO SASL Command 361 This section defines a formal profile of the Simple Authentication 362 and Security Layer [SASL]. The use of the AUTHINFO GENERIC command 363 as documented in Section 3.1.3 of [NNTP-COMMON] as a way to perform 364 SASL authentication is deprecated in favor of the AUTHINFO SASL 365 command. A server SHOULD NOT advertise AUTHINFO GENERIC in the 366 list of capabilities returned by LIST EXTENSIONS. 368 This command MUST NOT be pipelined. 370 2.4.1. Usage 372 Syntax 373 AUTHINFO SASL mechanism [initial-response] 375 Responses 376 281 Authentication accepted 377 283 challenge Authentication accepted (with success data) [1] 378 383 challenge Continue with SASL exchange [1] 379 481 Authentication failed/rejected 380 482 SASL protocol error 382 [1] These responses MAY exceed 512 octets. The maximum length of 383 these responses is increased to that which can accommodate the 384 largest encoded challenge possible for any of the SASL mechanisms 385 supported by the implementation. 387 Parameters 388 mechanism = String identifying a [SASL] authentication 389 mechanism. 390 initial-response = Optional initial client response. If present, 391 the response MUST be encoded as specified in 392 Section 3 of [BASE64]. 393 challenge = Server challenge. The challenge MUST be 394 encoded as specified in Section 3 of [BASE64]. 396 2.4.2. Description 398 The AUTHINFO SASL command initiates a [SASL] authentication 399 exchange between the client and the server. The client identifies 400 the SASL mechanism to use with the first parameter of the AUTHINFO 401 SASL command. If the server supports the requested authentication 402 mechanism, it performs the SASL exchange to authenticate the user. 403 Optionally, it also negotiates a security layer for subsequent 404 protocol interactions during this session. If the requested 405 authentication mechanism is invalid (e.g. is not supported), the 406 server rejects the AUTHINFO SASL command with a 501 reply. If the 407 requested authentication mechanism requires an encryption layer, 408 the server rejects the AUTHINFO SASL command with a 483 reply. 410 The SASL authentication exchange consists of a series of server 411 challenges and client responses that are specific to the chosen 412 [SASL] mechanism. 414 A server challenge is sent as a 383 reply with a single argument 415 containing the [BASE64] encoded string supplied by the SASL 416 mechanism. A server challenge that has zero length MUST be sent as 417 a single equals sign ("=") and not omitted (in order to comply with 418 the [NNTP] requirement that responses always have the same number 419 of arguments). 421 A client response consists of a line containing a [BASE64] encoded 422 string. A client response that has zero length MUST be sent as a 423 single equals sign ("=") and not omitted (for consistency with the 424 server challenge format). If the client wishes to cancel the 425 authentication exchange, it issues a line with a single "*". If 426 the server receives such a response, it MUST reject the AUTHINFO 427 SASL command by sending a 481 reply. 429 Note that these [BASE64] strings can be much longer than normal 430 NNTP responses. Clients and servers MUST be able to handle the 431 maximum encoded size of challenges and responses generated by their 432 supported authentication mechanisms. This requirement is 433 independent of any line length limitations the client or server may 434 have in other parts of its protocol implementation. 436 The optional initial response argument to the AUTHINFO SASL command 437 is used to save a round trip when using authentication mechanisms 438 that support an initial client response. If the initial response 439 argument is omitted and the chosen mechanism requires an initial 440 client response, the server MUST proceed as defined in section 5.1 441 of [SASL]. In NNTP, a server challenge that contains no data is 442 equivalent to a zero length challenge and is encoded as a single 443 equals sign ("="). 445 Note that the AUTHINFO SASL command is still subject to the line 446 length limitations defined in [NNTP]. If use of the initial 447 response argument would cause the AUTHINFO SASL command to exceed 448 this length, the client MUST NOT use the initial response parameter 449 (and instead proceed as defined in section 5.1 of [SASL]). 451 If the client is transmitting an initial response of zero length, 452 it MUST instead transmit the response as a single equals sign 453 ("="). This indicates that the response is present, but contains 454 no data. 456 If the client uses an initial-response argument to the AUTHINFO 457 SASL command with a SASL mechanism that does not support an initial 458 client send, the server MUST reject the AUTHINFO SASL command with 459 a 482 reply. 461 If the server cannot [BASE64] decode any client response, it MUST 462 reject the AUTHINFO SASL command with a 504 reply. If the client 463 cannot BASE64 decode any of the server's challenges, it MUST cancel 464 the authentication using the "*" response. In particular, servers 465 and clients MUST reject (and not ignore) any character not 466 explicitly allowed by the BASE64 alphabet, and MUST reject any 467 sequence of BASE64 characters that contains the pad character ('=') 468 anywhere other than the end of the string (e.g. "=AAA" and 469 "AAA=BBB" are not allowed). 471 The authorization identity generated by this [SASL] exchange is a 472 simple username, and both client and server MUST use the [SASLprep] 473 profile of the [StringPrep] algorithm to prepare these names for 474 transmission or comparison. If preparation of the authorization 475 identity fails or results in an empty string (unless it was 476 transmitted as the empty string), the server MUST fail the 477 authentication with a 481 reply. 479 Should the client successfully complete the exchange, the server 480 issues either a 283 or 281 reply. If the server is unable to 481 authenticate the client, it MUST reject the AUTHINFO SASL command 482 with a 481 reply. If an AUTHINFO command fails, the client MAY 483 proceed without authentication. Alternatively, the client MAY try 484 another authentication mechanism or present different credentials 485 by issuing another AUTHINFO command. 487 If the SASL mechanism returns additional data on success (e.g. 488 server authentication), the NNTP server issues a 283 reply with a 489 single argument containing the [BASE64] encoded string supplied by 490 the SASL mechanism. If no additional data is returned on success, 491 the server issues a 281 reply. 493 If a security layer is negotiated during the SASL exchange, it 494 takes effect for the client on the octet immediately following the 495 CRLF that concludes the last response generated by the client. For 496 the server, it takes effect immediately following the CRLF of its 497 success reply. 499 When a security layer takes effect, the server MUST discard any 500 knowledge obtained from the client that was not obtained from the 501 SASL negotiation itself. Likewise, the client MUST discard any 502 knowledge obtained from the server, such as the list of NNTP 503 extensions, that was not obtained from the SASL negotiation itself. 504 (Note that a client MAY compare the advertised SASL mechanisms 505 before and after authentication in order to detect an active down- 506 negotiation attack.) 508 When both TLS [NNTP-TLS] and SASL security layers are in effect, 509 the TLS encoding MUST be applied after the SASL encoding. 511 To ensure interoperability, client and server implementations of 512 this extension MUST implement the [DIGEST-MD5] SASL mechanism. 514 If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the 515 SASL [PLAIN] mechanism SHOULD also be implemented, as the 516 functionality of DIGEST-MD5 is insufficient for some environments 517 (e.g. the server may need to pass the raw password off to an 518 external authentication service). The SASL PLAIN mechanism is 519 preferred over AUTHINFO USER, even if there is not a strong 520 encryption layer active, because it eliminates limitations that 521 AUTHINFO USER/PASS has with regards to white space characters being 522 used in usernames and passwords. 524 The service name specified by this protocol's profile of SASL is 525 "nntp". 527 2.4.3. Examples 529 Example of the [PLAIN] SASL mechanism under a TLS layer, using an 530 initial client response: 532 [C] LIST EXTENSIONS 533 [S] 202 Extensions supported: 534 [S] STARTTLS 535 [S] AUTHINFO SASL:CRAM-MD5,DIGEST-MD5,GSSAPI 536 [S] . 537 [C] STARTTLS 538 [S] 382 Continue with TLS negotiation 539 [TLS negotiation proceeds, further commands protected by TLS layer] 540 [C] LIST EXTENSIONS 541 [S] 202 Extensions supported: 542 [S] AUTHINFO USER SASL:CRAM-MD5,DIGEST-MD5,GSSAPI,PLAIN,EXTERNAL 543 [S] . 544 [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA== 545 [S] 281 Authentication accepted 547 Example of the EXTERNAL SASL mechanism under a TLS layer, using the 548 derived authorization ID, and thus a zero-length initial client 549 response (commands prior to AUTHINFO SASL are the same as the 550 previous example and have been omitted): 552 [C] AUTHINFO SASL EXTERNAL = 553 [S] 281 Authentication accepted 555 Example of the [DIGEST-MD5] SASL mechanism, which includes a server 556 challenge and server success data (whitespace has been inserted for 557 clarity; base64-encoded data is sent as a single line with no 558 embedded whitespace): 560 [C] AUTHINFO SASL DIGEST-MD5 561 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 562 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo 563 LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj 564 NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 565 aG09bWQ1LXNlc3M= 566 [C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j 567 ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp 568 UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J 569 aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy 570 PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs 571 cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= 572 [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ== 574 Example of a failed authentication due to bad [GSSAPI] credentials. 575 Note that while the mechanism can utilize the initial response, the 576 client does not send it because of the limitation on command 577 lengths, resulting in a zero-length server challenge (here 578 whitespace has been inserted for clarity; base64-encoded data is 579 sent as a single line with no embedded whitespace): 581 [C] AUTHINFO SASL GSSAPI 582 [S] 383 = 583 [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj 584 ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw 585 IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB 586 EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 587 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP 588 ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 589 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ 590 djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6 591 Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj 592 RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL 593 kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0 594 0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF 595 iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw= 596 [S] 481 Authentication error 598 Example of a client aborting in the midst of an exchange: 600 [C] AUTHINFO SASL GSSAPI 601 [S] 383 = 602 [C] * 603 [S] 481 Authentication aborted as requested 605 Example of attempting to use a mechanism that is not supported by 606 the server: 608 [C] AUTHINFO SASL EXAMPLE 609 [S] 501 Mechanism not recognized 611 Example of attempting to use a mechanism that requires a security 612 layer: 614 [C] AUTHINFO SASL PLAIN 615 [S] 483 Encryption or stronger authentication required 617 Example of using an initial response with a mechanism that doesn't 618 support it (server must start the exchange): 620 [C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== 621 [S] 482 SASL protocol error 623 3. Augmented BNF Syntax for the AUTHINFO Extension 625 This section describes the syntax of the AUTHINFO extension. It 626 extends the syntax in [NNTP], and non-terminals not defined in this 627 document are defined there. 629 3.1. Commands 631 This syntax extends the non-terminal "command", which represents an 632 NNTP command. 634 command =/ authinfo-user-command / 635 authinfo-pass-command / 636 authinfo-sasl-command 638 authinfo-user-command = "AUTHINFO" WS "USER" WS username 639 authinfo-pass-command = "AUTHINFO" WS "PASS" WS password 640 authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism 641 [WS initial-response] 643 username = 1*user-pass-char 644 password = 1*user-pass-char 645 user-pass-char = P-CHAR 646 initial-response = base64-opt 648 Note: A server implementation MAY parse AUTHINFO USER and AUTHINFO 649 PASS specially as to allow white space to be used within the 650 username or password. Such implementations accept the additional 651 syntax (making these two items inconsistent with "x-argument" in 652 section 9.1 of [NNTP]): 654 user-pass-char =/ SP / TAB 656 In doing so, the grammar can become ambiguous if the username or 657 password begins or ends with white space. To solve this ambiguity, 658 such implementations typically treat everything between the first 659 white space character following "USER"/"PASS" and CRLF as the 660 username/password. 662 3.2. Command Continuation 664 This syntax extends the non-terminal "command-continuation", which 665 represents the further material sent by the client in the case of 666 multi-stage commands. 668 command-continuation =/ authinfo-sasl-continuation 669 authinfo-sasl-continuation = ("*" / base64-opt) CRLF 670 ; client must send a continuation following each 671 ; "383" response from the server 673 3.3. Responses 675 This syntax extends the non-terminal "simple-response-content" for 676 the various commands in this specification. 678 simple-response-content =/ response-sasl-content 679 response-sasl-content = "283" SP base64 / "383" SP base64-opt 681 3.4. LIST EXTENSIONS responses 683 This syntax defines the specific LIST EXTENSIONS responses for the 684 AUTHINFO extension. 686 extension-descriptor =/ authinfo-extension 687 authinfo-extension = %x41.55.54.48.49.4E.46.4F ; "AUTHINFO" 688 *(SPA authinfo-extension-arg) 689 authinfo-extension-arg = "USER" / 690 "SASL:" [mechanism *("," mechanism)] 692 3.5. General non-terminals 694 mechanism = 1*20mech-char 695 mech-char = UPPER / DIGIT / "-" / "_" 697 base64-opt = "=" / base64 699 4. Summary of Response Codes 701 This section contains a list of every new response code defined in 702 this document, whether it is multi-line, which commands can 703 generate it, what arguments it has, and what its meaning is. 705 Response code 281 706 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 707 Meaning: authentication accepted 709 Response code 283 710 Generated by: AUTHINFO SASL 711 1 argument: challenge 712 Meaning: authentication accepted (with success data) 714 Response code 381 715 Generated by: AUTHINFO USER 716 Meaning: password required via AUTHINFO PASS command. Note 717 that this code is used for backwards compatibility and does 718 not conform to the traditional use of 3xx codes. 720 Response code 383 721 Generated by: AUTHINFO SASL 722 1 argument: challenge 723 Meaning: continue with SASL exchange 725 Response code 481 726 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 727 Meaning: authentication failed/rejected 729 Response code 482 730 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 731 Meaning: authentication commands issued out of sequence or 732 SASL protocol error 734 5. Authentication Tracking/Logging 736 This section contains implementation suggestions and notes of best 737 current practice, and does not specify further network protocol 738 requirements. 740 Once authenticated, the authorization identity presented in the 741 AUTHINFO exchange (username when using USER/PASS) SHOULD be 742 included in an audit trail associating the identity with any 743 articles supplied during a POST operation, and this configuration 744 SHOULD be the default. This may be accomplished, for example, by 745 inserting headers in the posted articles or by a server logging 746 mechanism. The server MAY provide a facility for disabling the 747 procedure described above, as some users or administrators may 748 consider it a violation of privacy. 750 6. Security Considerations 752 Security issues are discussed throughout this memo. 754 Before the [SASL] negotiation has begun, any protocol interactions 755 may have been performed in the clear and may have been modified by 756 an active attacker. For this reason, clients and servers MUST 757 discard any knowledge obtained prior to the start of the SASL 758 negotiation upon the establishment of a security layer. 760 Servers MAY implement a policy whereby the connection is dropped 761 after a number of failed authentication attempts. If they do so, 762 they SHOULD NOT drop the connection until at least 3 attempts at 763 authentication have failed. 765 Implementations MUST support a configuration where authentication 766 mechanisms that are vulnerable to passive eavesdropping attacks 767 (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or 768 used without the presence of an external security layer such as TLS 769 [NNTP-TLS]. 771 When multiple authentication mechanisms are permitted by both 772 client and server, an active attacker can cause a down-negotiation 773 to the weakest mechanism. For this reason, both clients and 774 servers SHOULD be configurable to forbid use of weak mechanisms. 776 7. IANA Considerations 778 7.1. IANA Considerations for SASL/GSSAPI services 780 Please register the SASL/GSSAPI service name "nntp". This service 781 name refers to authenticated use of Usenet news service when 782 provided via the [NNTP] protocol. 784 o Published Specification: This document. 786 o Author, Change Controller, and Contact for Further Information: 787 Author of this document. 789 7.2. IANA Considerations for NNTP extensions 791 Below is a formal definition of the AUTHINFO extension as required 792 by Section 8 of [NNTP] for the IANA registry. 794 o This extension provides an extensible mechanism for NNTP 795 authentication via a variety of methods. 797 o The extension-label is "AUTHINFO". 799 o The extension-label has two possible optional arguments "USER" 800 and "SASL:" (as defined in Section 2) indicating which variants 801 of the AUTHINFO command are supported. 803 o The extension defines three new commands, AUTHINFO USER, 804 AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and 805 responses are defined in Section 2. 807 o The extension does not associate any new responses with pre- 808 existing NNTP commands. 810 o The extension may affect the overall behavior of both server and 811 client, in that the AUTHINFO SASL command requires that 812 subsequent communication to be transmitted via an intermediary 813 security layer. 815 o The extension does not affect the maximum length of commands or 816 of initial response lines of pre-existing responses. 818 o The extension defines two new responses, 283 and 383, whose 819 lengths may exceed 512 octets. The maximum length of these 820 responses is increased to that which can accommodate the largest 821 encoded challenge possible for any of the SASL mechanisms 822 supported by the implementation. 824 o The extension does not alter pipelining, but AUTHINFO commands 825 cannot be pipelined. 827 o Use of this extension may alter the output from LIST EXTENSIONS. 828 Once any AUTHINFO command has been used successfully, the server 829 may alter the list of arguments for the AUTHINFO capability 830 (although the capability itself must still be listed, even with 831 zero arguments). However, if a SASL security layer has been 832 negotiated, the server SHOULD continue to advertise the "SASL:" 833 argument with the same list of mechanisms, because the client 834 may wish to compare the pre- and post-authentication list of 835 SASL mechanisms in order to detect active down-negotiation 836 attacks. 838 o The extension does not cause any pre-existing command to produce 839 a 401, 480, or 483 response. 841 o The AUTHINFO commands can be used before or after the MODE 842 READER command, with the same semantics. 844 o Published Specification: This document. 846 o Author, Change Controller, and Contact for Further Information: 847 Author of this document. 849 8. References 851 8.1. Normative References 853 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 854 Specifications: ABNF", RFC 2234, November 1997. 856 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", RFC 1704 857 Bell Communications Research, October 1994. 859 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 860 Encodings", RFC 3548, July 2003. 862 [DIGEST-MD5] Leach, P., Newman, C., "Using Digest Authentication as a 863 SASL Mechanism", RFC 2831, May 2000. 865 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", RFC 2119, Harvard University, March 1997. 868 [NNTP] Feather, C., "Network News Transport Protocol", 869 draft-ietf-nntpext-base-*.txt, Work in Progress. 871 [NNTP-TLS] Vinocur, J., "Using TLS with NNTP", 872 draft-ietf-nntpext-tls-nntp-*.txt, Work in Progress. 874 [SASL] Melnikov, A., "Simple Authentication and Security Layer 875 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, Work in Progress. 877 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names 878 and passwords", draft-ietf-sasl-saslprep-*.txt, Work in Progress. 880 [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of 881 Internationalized Strings ("stringprep")", 882 draft-hoffman-rfc3454bis-*.txt, Work in Progress. 884 8.2. Informative References 886 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", draft- 887 ietf-sasl-crammd5-*.txt, Work in Progress. 889 [GSSAPI] Melnikov, A., "SASL GSSAPI Mechanisms", draft-ietf-sasl- 890 gssapi-*.txt, Work in Progress. 892 [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, 893 Academ Consulting Services, October 2000. 895 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", draft-ietf-sasl- 896 plain-*.txt, Work in Progress. 898 [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, 899 AT&T Laboratories, April 2001. 901 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 902 RFC 3629, Alis Technologies, November 2003. 904 9. Authors' Addresses 906 Jeffrey M. Vinocur 907 Department of Computer Science 908 Upson Hall 909 Cornell University 910 Ithaca, NY 14853 USA 912 Email: vinocur@cs.cornell.edu 914 Chris Newman 915 Sun Microsystems 916 1050 Lakes Drive, Suite 250 917 West Covina, CA 91790 USA 919 Email: cnewman@iplanet.com 921 Kenneth Murchison 922 Oceana Matrix Ltd. 923 21 Princeton Place 924 Orchard Park, NY 14127 USA 926 Email: ken@oceana.com 928 10. Acknowledgments 930 A significant amount of the authentication text was originally from 931 the NNTP revision or common authentication specs written by Stan 932 Barber. A significant amount of the SASL text was lifted from the 933 revisions to RFC 1734 and RFC 2554 by Rob Siemborski. 935 Special acknowledgment also goes to Russ Allbery, Clive Feather, 936 and others who commented privately on intermediate revisions of 937 this document, as well as the members of the IETF NNTP Working 938 Group for continual (yet sporadic) insight in discussion. 940 11. Intellectual Property Rights 942 The IETF takes no position regarding the validity or scope of any 943 intellectual property or other rights that might be claimed to 944 pertain to the implementation or use of the technology described in 945 this document or the extent to which any license under such rights 946 might or might not be available; neither does it represent that it 947 has made any effort to identify any such rights. Information on 948 the IETF's procedures with respect to rights in standards-track and 949 standards-related documentation can be found in BCP-11. Copies of 950 claims of rights made available for publication and any assurances 951 of licenses to be made available, or the result of an attempt made 952 to obtain a general license or permission for the use of such 953 proprietary rights by implementers or users of this specification 954 can be obtained from the IETF Secretariat. 956 The IETF invites any interested party to bring to its attention any 957 copyrights, patents or patent applications, or other proprietary 958 rights which may cover technology that may be required to practice 959 this standard. Please address the information to the IETF 960 Executive Director. 962 12. Copyright 964 Copyright (C) The Internet Society (2004). This document is 965 subject to the rights, licenses and restrictions contained in BCP 966 78, and except as set forth therein, the authors retain all their 967 rights." 969 This document and the information contained herein are provided on 970 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 971 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 972 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 973 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 974 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 975 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 976 PARTICULAR PURPOSE.