idnits 2.17.1 draft-ietf-nntpext-authinfo-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 13) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 7 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 (June 2004) is 7227 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: 'NNTP-COM-MON' is mentioned on line 232, but not defined == Missing Reference: 'C' is mentioned on line 604, but not defined == Missing Reference: 'S' is mentioned on line 605, but not defined -- Looks like a reference, but probably isn't: '1' on line 358 == Missing Reference: 'TLS' is mentioned on line 492, but not defined == Unused Reference: 'ABNF' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'CRAM-MD5' is defined on line 866, 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' ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) -- 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: 9 errors (**), 0 flaws (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Vinocur 2 Internet Draft Cornell University 3 Document: draft-ietf-nntpext-authinfo-01.txt C. Newman 4 Sun Microsystems 5 K. Murchison 6 Oceana Matrix Ltd. 7 June 2004 9 NNTP Extension for Authentication 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines a profile of the Simple Authentication and 36 Security Layer [SASL] for the Network News Transport Protocol 37 [NNTP] protocol and updates/deprecates information contained in 38 Section 3.1 of [NNTP-COMMON]. This extension allows an NNTP client 39 to indicate an authentication mechanism to the server, perform an 40 authentication protocol exchange, and optionally negotiate a secu- 41 rity layer for subsequent protocol interactions during the remain- 42 der of an NNTP session. 44 Table of Contents 46 1. Introduction ............................................. 2 47 1.1. Conventions Used in this Document ................... 3 48 2. The AUTHINFO Extension ................................... 3 49 2.1. AUTHINFO USER/PASS .................................. 5 50 2.1.2. Description .................................... 6 51 2.1.3. Examples ....................................... 7 52 2.2. AUTHINFO SASL ....................................... 8 53 2.2.1. Usage .......................................... 8 54 2.2.2. Description .................................... 8 55 2.2.3. Examples ....................................... 11 56 3. Augmented BNF Syntax for the AUTHINFO Extension .......... 13 57 3.1. Commands ............................................ 13 58 3.2. Command Continuation ................................ 14 59 3.3. Responses ........................................... 14 60 3.4. LIST EXTENSIONS responses ........................... 14 61 3.5. General non-terminals ............................... 14 62 4. Summary of Response Codes ................................ 15 63 5. Authentication Tracking/Logging .......................... 15 64 6. Security Considerations .................................. 16 65 7. IANA Considerations ...................................... 16 66 7.1. IANA Considerations for SASL/GSSAPI services ........ 17 67 7.2. IANA Considerations for NNTP extensions ............. 17 68 8. Normative References ..................................... 18 69 9. Informative References ................................... 19 70 10. Authors' Addresses ...................................... 19 71 11. Acknowledgments ......................................... 19 72 12. Intellectual Property Rights ............................ 20 73 13. Copyright ............................................... 20 75 1. Introduction 77 Although NNTP [NNTP] has traditionally provided public access to 78 newsgroups, authentication is often useful, for example to control 79 resource consumption, to allow abusers of the POST command to be 80 identified, and to restrict access to "local" newsgroups. 82 The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in 83 [NNTP-COMMON], provide a very weak authentication mechanism in 84 widespread use by the installed base. Due to their insecurity and 85 ubiquity they are formalized in this specification, but only for 86 use in combination with appropriate security layers. 88 The ad-hoc AUTHINFO GENERIC command, also documented in [NNTP-COM- 89 MON] but much less ubiquitous, provided an NNTP-specific equivalent 90 of the generic SASL [SASL] facility. This document deprecates 91 AUTHINFO GENERIC in favor of an AUTHINFO SASL replacement so that 92 NNTP can benefit from authentication mechanisms developed for other 93 SASL-enabled application protocols including SMTP, POP, IMAP, LDAP, 94 and BEEP. 96 This specification is to be read in conjunction with the NNTP base 97 specification [NNTP]. Except where specifically stated otherwise, 98 in the case of a conflict between these two documents [NNTP] takes 99 precedence over this one. 101 It is also recommended that this specification be read in conjunc- 102 tion with the SASL base specification [SASL]. 104 1.1. Conventions Used in this Document 106 The notational conventions used in this document are the same as 107 those in [NNTP] and any term not defined in this document has the 108 same meaning as in that one. 110 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 111 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 112 as described in "Key words for use in RFCs to Indicate Requirement 113 Levels" [KEYWORDS]. 115 Terms related to authentication are defined in "On Internet Authen- 116 tication" [AUTH]. 118 In the examples, commands from the client are indicated with [C], 119 and responses from the server are indicated with [S]. 121 2. The AUTHINFO Extension 123 A server MAY provide this extension, independently of any other 124 extension defined elsewhere. If the server provides the extension, 125 it MUST include the AUTHINFO extension label in the response to 126 LIST EXTENSIONS. If it does not provide it, it MUST NOT include 127 the extension label. The remainder of this specification is written 128 as if the extension is provided. 130 This extension provides three new commands: AUTHINFO USER, AUTHINFO 131 PASS, and AUTHINFO SASL. At least one of the AUTHINFO USER or 132 AUTHINFO SASL commands MUST be implemented in order to advertise 133 the AUTHINFO extension label. The AUTHINFO extension label con- 134 tains an argument list detailing which authentication commands are 135 available. 137 The "USER" argument indicates that AUTHINFO USER/PASS is supported 138 as defined by Section 2.1 of this document. The "USER" argument 139 MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD 140 NOT be provided, unless a strong encryption layer (e.g. TLS [NNTP- 141 TLS]) is in use or backward compatibility dictates otherwise. 143 The "SASL:" argument indicates that AUTHINFO SASL is supported as 144 defined by Section 2.2 of this document. The "SASL:" argument is 145 followed immediately (no intervening whitespace) by a comma-sepa- 146 rated list of available SASL mechanism names, and the colon (":") 147 is always included even if no mechanisms are available. 149 The server may list the AUTHINFO capability with no arguments, 150 which indicates that it complies with this draft and does not per- 151 mit any authentication commands in its current state. In this 152 case, the client MUST NOT attempt to utilize any AUTHINFO commands, 153 even if it contains logic to do so (e.g. for backward compatibility 154 with servers that are not compliant with this specification). 156 Future extensions may add additional arguments to this capability. 157 Unrecognized arguments SHOULD be ignored or brought to the atten- 158 tion of the user. 160 Example: 161 [C] LIST EXTENSIONS 162 [S] 202 Extensions supported: 163 [S] STARTTLS 164 [S] AUTHINFO SASL:CRAM-MD5,DIGEST-MD5,GSSAPI 165 [S] . 166 [C] STARTTLS 167 [S] 382 Continue with TLS negotiation 168 [TLS negotiation proceeds, further commands protected by TLS layer] 169 [C] LIST EXTENSIONS 170 [S] 202 Extensions supported: 171 [S] AUTHINFO USER SASL:CRAM-MD5,DIGEST-MD5,GSSAPI,PLAIN,EXTERNAL 172 [S] . 174 The AUTHINFO extension is used to authenticate a user. Note that 175 authorization is a matter of site policy, not network protocol, and 176 is therefore not discussed in this document. The server determines 177 authorization in whatever manner is defined by its implementation 178 as configured by the site administrator. 180 When an NNTP server responds to a client command with a 480 181 response, this indicates the client MUST authenticate using the 182 AUTHINFO command in order to use that command or access the indi- 183 cated resource. A client intending to use AUTHINFO may issue the 184 LIST EXTENSIONS command to obtain the available authentication com- 185 mands and mechanisms before attempting authentication. 187 A client MAY attempt the first step of authentication at any time 188 during a session to acquire additional privileges without having 189 received a 480 response. The client MUST NOT under any circum- 190 stances continue with any steps of authentication beyond the first, 191 unless the response code from the server indicates that the authen- 192 tication exchange is welcomed. In particular, anything other than 193 a 38x response code indicates that the client MUST NOT continue the 194 authentication exchange. 196 Servers are not required to accept unsolicited authentication 197 information from the client, therefore clients MUST accommodate 198 servers that reject such authentication information. Additionally, 199 servers may accept authentication information and yet still deny 200 access to some or all resources; the permanent 502 response indi- 201 cates a resource is unavailable even though authentication has been 202 performed (this is in contrast to the temporary 480 error indicat- 203 ing that a resource is unavailable now but may become available 204 after authentication). 206 After a successful authentication, the client may retry the origi- 207 nal command (if any) to which the server replied with the 480 208 response, or continue with some other command (for example, the 209 client may wish to re-fetch the list of newsgroups). 211 After an AUTHINFO command has been successfully completed, no more 212 AUTHINFO commands may be issued in the same session. After a suc- 213 cessful AUTHINFO command completes, a server MUST reject any fur- 214 ther AUTHINFO commands with a 502 response. 216 A server MUST NOT under any circumstances reply to an AUTHINFO com- 217 mand with a 480 response. 219 Note that a successful AUTHINFO command may cause the output of the 220 LIST EXTENSIONS command to change. Any successful authentication 221 MAY result in the server listing different arguments (perhaps list- 222 ing zero arguments) for AUTHINFO, but MUST NOT result in the 223 AUTHINFO capability being removed entirely from LIST EXTENSIONS (as 224 this might falsely indicate to clients that they were dealing with 225 a non-compliant server). Additionally, after a successful AUTHINFO 226 SASL, the SASL: capability MUST continue to be advertised as 227 described in section 2.2.2. 229 2.1. AUTHINFO USER/PASS 231 This section supersedes the definition of the AUTHINFO USER and 232 AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP-COM- 233 MON]. 235 These commands MUST NOT be pipelined. 237 2.1.1. Usage 239 Syntax 240 AUTHINFO USER username 241 AUTHINFO PASS password 243 Responses 244 281 Authentication accepted 245 381 Password required [1] 246 481 Authentication failed/rejected 247 482 Authentication commands issued out of sequence 249 [1] Only valid for AUTHINFO USER. 251 Parameters 252 username = UTF-8 string identifying the user/client 253 password = UTF-8 string representing the user's password 255 2.1.2. Description 257 The AUTHINFO USER and AUTHINFO PASS commands are used to present 258 clear text credentials to the server. These credentials consist of 259 a username or a username plus a password (the distinction is that a 260 password is expected to be kept secret while a username is not; 261 this does not directly affect the protocol but may have an impact 262 on user interfaces). The username is supplied through the AUTHINFO 263 USER command and the password through the AUTHINFO PASS command. 265 If the server requires only a username, it MUST NOT give a 381 266 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO 267 PASS. 269 If the server requires both username and password, the former MUST 270 be sent before the latter. The server will need to cache the user- 271 name until the password is received; it MAY require the password to 272 be sent in the immediately next command (in other words, only 273 caching the username until the next command is sent). The server: 275 - MUST return a 381 response to AUTHINFO USER; 276 - MUST return a 482 response to AUTHINFO PASS if there is no cached 277 username; 278 - MUST use the argument of the most recent AUTHINFO USER for 279 authentication; 280 - MUST NOT return a 381 response to AUTHINFO PASS. 282 The server MAY determine whether or not a password is needed based 283 on the username. Thus the same server can respond with both 381 and 284 other response codes to AUTHINFO USER. 286 The AUTHINFO PASS command permits the client to use a clear-text 287 password to authenticate. A compliant implementation MUST NOT 288 implement this mechanism without also implementing support for TLS 289 [NNTP-TLS] or the DIGEST-MD5 SASL [DIGEST-MD5] authentication mech- 290 anism. Use of this mechanism without an active strong encryption 291 layer is deprecated as it exposes the user's password to all par- 292 ties on the network between the client and the server. Any imple- 293 mentation of this mechanism SHOULD be configurable to disable it 294 unless a strong encryption layer such as that provided by [NNTP- 295 TLS] is active, and this configuration SHOULD be the default. The 296 server will use the 483 response code to indicate that the 297 datastream is insufficiently secure for the command being 298 attempted. 300 Usernames and passwords MUST use the UTF-8 [UTF-8] character set 301 and client MUST convert any user input to UTF-8 if necessary. 303 Note that usernames and passwords containing whitespace are quite 304 likely not to work as desired, due to the command argument syntax 305 [NNTP]. (A client may wish to scan the username and password for 306 whitespace, and if detected, warn the user of the likelihood of 307 problems.) The SASL PLAIN [PLAIN] mechanism is recommended as an 308 alternative, as it is more robust with regard to character set. 310 2.1.3. Examples 312 Example of successful AUTHINFO USER: 314 [C] AUTHINFO USER wilma 315 [S] 281 Authentication accepted 317 Example of successful AUTHINFO USER/PASS: 319 [C] AUTHINFO USER fred 320 [S] 381 Enter passphrase 321 [C] AUTHINFO PASS flintstone 322 [S] 281 Authentication accepted 324 Example of AUTHINFO USER/PASS requiring a security layer: 326 [C] AUTHINFO USER fred@stonecanyon.example 327 [S] 483 Encryption or stronger authentication required 329 Example of failed AUTHINFO USER/PASS: 331 [C] AUTHINFO USER barney 332 [S] 381 Enter passphrase 333 [C] AUTHINFO PASS flintstone 335 [S] 481 Authentication failed 337 Example of AUTHINFO PASS before AUTHINFO USER: 339 [C] AUTHINFO PASS flintstone 340 [S] 482 Authentication commands issued out of sequence 342 2.2. AUTHINFO SASL 344 2.2.1. Usage 346 This command MUST NOT be pipelined. 348 Syntax 349 AUTHINFO SASL sasl-mech-name [sasl-init-resp] 351 Responses 352 281 Authentication accepted 353 283 sasl-server-chal Authentication accepted (with success data) [1] 354 383 sasl-server-chal Continue with SASL exchange [1] 355 481 Authentication failed/rejected 356 482 SASL protocol error 358 [1] These responses MAY exceed 512 octets. The maximum length of 359 these responses is increased to that which can accommodate the 360 largest encoded challenge possible for any of the SASL mechanisms 361 supported by the implementation. 363 Parameters 364 sasl-mech-name = String identifying a [SASL] authentication mechanism 365 sasl-init-resp = Optional initial client response. If present, the 366 response MUST be encoded as specified in Section 3 367 of [BASE64]. 368 sasl-server-chal = Server challenge. The challenge MUST be encoded as 369 specified in Section 3 of [BASE64]. 371 2.2.2. Description 373 This section deprecates the definition of the AUTHINFO GENERIC com- 374 mand as documented in Section 3.1.3 of [NNTP-COMMON]. (An imple- 375 mentation MAY support AUTHINFO GENERIC for backward compatibility 376 and still be compliant with this specification. However, this doc- 377 ument does not provide a formal specification of AUTHINFO GENERIC, 378 and does not permit it to be reported in LIST EXTENSIONS.) 380 The AUTHINFO SASL command initiates a [SASL] authentication 381 exchange between the client and the server. The client identifies 382 the SASL mechanism to use with the first parameter of the AUTHINFO 383 SASL command. If the server supports the requested authentication 384 mechanism, it performs the SASL exchange to authenticate the user. 385 Optionally, it also negotiates a security layer for subsequent pro- 386 tocol interactions during this session. If the requested authenti- 387 cation mechanism is invalid (e.g. is not supported), the server 388 rejects the AUTHINFO SASL command with a 501 reply. If the 389 requested authentication mechanism requires an encryption layer, 390 the server rejects the AUTHINFO SASL command with a 483 reply. 392 The SASL authentication exchange consists of a series of server 393 challenges and client responses that are specific to the chosen 394 [SASL] mechanism. 396 A server challenge is sent as a 383 reply with a single argument 397 containing the [BASE64] encoded string supplied by the SASL mecha- 398 nism. If the server challenge has zero length, it MUST instead be 399 sent as a single equals sign ("="), making the complete response 400 "383 =". 402 A client response consists of a line containing a [BASE64] encoded 403 string. If the client wishes to cancel the authentication 404 exchange, it issues a line with a single "*". If the server 405 receives such a response, it MUST reject the AUTHINFO SASL command 406 by sending a 481 reply. 408 Note that these [BASE64] strings can be much longer than normal 409 NNTP responses. Clients and servers MUST be able to handle the 410 maximum encoded size of challenges and responses generated by their 411 supported authentication mechanisms. This requirement is indepen- 412 dent of any line length limitations the client or server may have 413 in other parts of its protocol implementation. 415 The optional initial response argument to the AUTHINFO SASL command 416 is used to save a round trip when using authentication mechanisms 417 that support an initial client response. If the initial response 418 argument is omitted and the chosen mechanism requires an initial 419 client response, the server MUST proceed as defined in section 5.1 420 of [SASL]. In NNTP, a server challenge that contains no data is 421 defined to be the same as a zero-length challenge as described 422 above. 424 Note that the AUTHINFO SASL command is still subject to the line 425 length limitations defined in [NNTP]. If use of the initial 426 response argument would cause the AUTHINFO SASL command to exceed 427 this length, the client MUST NOT use the initial response parameter 428 (and instead proceed as defined in section 5.1 of [SASL]). 430 If the client is transmitting an initial response of zero length, 431 it MUST instead transmit the response as a single equals sign 432 ("="). This indicates that the response is present, but contains 433 no data. 435 If the client uses an initial-response argument to the AUTHINFO 436 SASL command with a SASL mechanism that does not support an initial 437 client send, the server MUST reject the AUTHINFO SASL command with 438 a 482 reply. 440 If the server cannot [BASE64] decode any client response, it MUST 441 reject the AUTHINFO SASL command with a 482 reply. If the client 442 cannot BASE64 decode any of the server's challenges, it MUST cancel 443 the authentication using the "*" response. In particular, servers 444 and clients MUST reject (and not ignore) any character not explic- 445 itly allowed by the BASE64 alphabet, and MUST reject any sequence 446 of BASE64 characters that contains the pad character ('=') anywhere 447 other than the end of the string (e.g. "=AAA" and "AAA=BBB" are not 448 allowed). 450 The authorization identity generated by this [SASL] exchange is a 451 simple username, and both client and server MUST use the [SASLprep] 452 profile of the [StringPrep] algorithm to prepare these names for 453 transmission or comparison. If preparation of the authorization 454 identity fails or results in an empty string (unless it was trans- 455 mitted as the empty string), the server MUST fail the authentica- 456 tion with a 481 reply. 458 Should the client successfully complete the exchange, the server 459 issues either a 283 or 281 reply. If the server is unable to 460 authenticate the client, it MUST reject the AUTHINFO SASL command 461 with a 481 reply. If an AUTHINFO command fails, the client MAY 462 proceed without authentication. Alternatively, the client MAY try 463 another authentication mechanism or present different credentials 464 by issuing another AUTHINFO command. 466 If the SASL mechanism returns additional data on success (e.g. 467 server authentication), the NNTP server issues a 283 reply with a 468 single argument containing the [BASE64] encoded string supplied by 469 the SASL mechanism. If no additional data is returned on success, 470 the server issues a 281 reply. 472 If a security layer is negotiated during the SASL exchange, it 473 takes effect for the client on the octet immediately following the 474 CRLF that concludes the last response generated by the client. For 475 the server, it takes effect immediately following the CRLF of its 476 success reply. 478 When a security layer takes effect, the server MUST discard any 479 knowledge obtained from the client that was not obtained from the 480 SASL negotiation itself. Likewise, the client MUST discard any 481 knowledge obtained from the server, such as the list of NNTP exten- 482 sions, that was not obtained from the SASL negotiation itself. 483 (Note that a client MAY compare the advertised SASL mechanisms 484 before and after authentication in order to detect an active down- 485 negotiation attack.) 487 After a security layer is established, the server MUST continue to 488 advertise the AUTHINFO capability and "SASL:" argument (with the 489 same mechanism list as before authentication) and SHOULD NOT adver- 490 tise the STARTTLS [NNTP-TLS] capability. 492 When both [TLS] and SASL security layers are in effect, the TLS 493 encoding MUST be applied after the SASL encoding, regardless of the 494 order in which the layers were negotiated. 496 To ensure interoperability, client and server implementations of 497 this extension MUST implement the [DIGEST-MD5] SASL mechanism. 499 If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the 500 SASL [PLAIN] mechanism SHOULD also be implemented, as the function- 501 ality of DIGEST-MD5 is insufficient for some environments (e.g. the 502 server may need to pass the raw password off to an external authen- 503 tication service). The SASL PLAIN mechanism is preferred over 504 AUTHINFO USER, even if there is not a strong encryption layer 505 active, because it eliminates limitations that AUTHINFO USER/PASS 506 has on the character set used for usernames and passwords. 508 The service name specified by this protocol's profile of SASL is 509 "nntp". 511 2.2.3. Examples 513 Example of the [PLAIN] SASL mechanism under a TLS layer, using an 514 initial client response: 516 [C] LIST EXTENSIONS 517 [S] 202 Extensions supported: 518 [S] STARTTLS 519 [S] AUTHINFO SASL:CRAM-MD5,DIGEST-MD5,GSSAPI 520 [S] . 521 [C] STARTTLS 522 [S] 382 Continue with TLS negotiation 523 [TLS negotiation proceeds, further commands protected by TLS layer] 524 [C] LIST EXTENSIONS 525 [S] 202 Extensions supported: 526 [S] AUTHINFO USER SASL:CRAM-MD5,DIGEST-MD5,GSSAPI,PLAIN,EXTERNAL 528 [S] . 529 [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA== 530 [S] 281 Authentication accepted 532 Example of the EXTERNAL SASL mechanism under a TLS layer, using the 533 derived authorization ID, and thus a zero-length initial client 534 response (commands prior to AUTHINFO SASL are the same as the pre- 535 vious example and have been omitted): 537 [C] AUTHINFO SASL EXTERNAL = 538 [S] 281 Authentication accepted 540 Example of the [DIGEST-MD5] SASL mechanism, which includes a server 541 challenge and server success data (whitespace has been inserted for 542 clarity; base64-encoded data is sent as a single line with no 543 embedded whitespace): 545 [C] AUTHINFO SASL DIGEST-MD5 546 [S] 383 bm9uY2U9IlBKUE9GczJKa05VYWhraDNjRmVUN2dZZjFKY0VJakVCSHRK 547 NzFycmNDMTg9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo 548 IixtYXhidWY9NDA5NixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vz 549 cw== 550 [C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j 551 ZT0iUEpQT0ZzMkprTlVhaGtoM2NGZVQ3Z1lmMUpjRUlqRUJIdEo3MXJyY0Mx 552 OD0iLGNub25jZT0iUmVkV2VqM3JNdFY5U09XSE5BNUVtZFNmVWRFajNCMlpL 553 YTNIeFlHbzJCWT0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLG1heGJ1Zj0xMDI0 554 LGRpZ2VzdC11cmk9Im5ld3MvbG9jYWxob3N0IixyZXNwb25zZT0zOTg2NWIy 555 NTk0Nzk4ZjY4ZmY5ZWEwNDg1NGE2NGQ1ZQ== 556 [S] 283 cnNwYXV0aD0xYzc0NjdmMTY0OTQ3NmM4ZDJjNzM5ZTY4MjgwMzE2OA== 558 Example of a failed authentication due to bad [GSSAPI] credentials. 559 Note that while the mechanism can utilize the initial response, the 560 client does not send it because of the limitation on command 561 lengths, resulting in a zero-length server challenge (here whites- 562 pace has been inserted for clarity; base64-encoded data is sent as 563 a single line with no embedded whitespace): 565 [C] AUTHINFO SASL GSSAPI 566 [S] 383 = 567 [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj 568 ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw 569 IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB 570 EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 571 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP 572 ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 573 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ 574 djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6 575 Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj 576 RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL 577 kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0 578 0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF 579 iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw= 580 [S] 481 Authentication error 582 Example of a client aborting in the midst of an exchange: 584 [C] AUTHINFO SASL GSSAPI 585 [S] 383 = 586 [C] * 587 [S] 481 Sequence successfully aborted 589 Example of attempting to use a mechanism that is not supported by 590 the server: 592 [C] AUTHINFO SASL EXAMPLE 593 [S] 501 Mechanism not recognized 595 Example of attempting to use a mechanism that requires a security 596 layer: 598 [C] AUTHINFO SASL PLAIN 599 [S] 483 Encryption or stronger authentication required 601 Example of using an initial response with a mechanism that doesn't 602 support it (server must start the exchange): 604 [C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== 605 [S] 482 SASL protocol error 607 3. Augmented BNF Syntax for the AUTHINFO Extension 609 This section describes the syntax of the AUTHINFO extension. It 610 extends the syntax in [NNTP], and non-terminals not defined in this 611 document are defined there. 613 3.1. Commands 615 This syntax extends the non-terminal "command", which represents an 616 NNTP command. 618 command /= authinfo-user-command / 619 authinfo-pass-command / 620 authinfo-sasl-command 622 authinfo-user-command = "AUTHINFO" WS "USER" WS username 623 authinfo-pass-command = "AUTHINFO" WS "PASS" WS password 624 authinfo-sasl-command = "AUTHINFO" WS "SASL" WS sasl-mech-name 625 [WS sasl-init-resp] 627 username = 1*P-CHAR 628 password = 1*P-CHAR 629 sasl-init-resp = "=" / base64 631 3.2. Command Continuation 633 This syntax extends the non-terminal "command-continuation", which 634 represents the further material sent by the client in the case of 635 multi-stage commands. 637 command-continuation /= authinfo-sasl-continuation 638 authinfo-sasl-continuation = *([sasl-client-resp] CRLF) 639 ; client waits for a "383" response from the server before 640 ; sending each line 641 sasl-client-resp = "*" / base64 643 3.3. Responses 645 This syntax extends the non-terminal "simple-response-content" for 646 the various commands in this specification. 648 simple-response-content /= response-x83-content 649 response-x83-content = ("283" / "383") SP sasl-server-chal 650 sasl-server-chal = "=" / base64 652 3.4. LIST EXTENSIONS responses 654 This syntax defines the specific LIST EXTENSIONS responses for the 655 AUTHINFO extension. 657 extension-descriptor /= authinfo-extension 658 authinfo-extension = %x41.55.54.48.49.4E.46.4F ; "AUTHINFO" 659 *(SPA authinfo-extension-arg) 660 authinfo-extension-arg = "USER" / 661 "SASL:" [sasl-mech-name *("," sasl-mech-name)] 663 3.5. General non-terminals 665 sasl-mech-name = 1*20sasl-mech-char 666 sasl-mech-char = %x41-5A / DIGIT / "-" / "_" 667 ; mechanism names restricted to uppercase letters, 668 ; digits, "-" and "_" 670 base64 = *(4base64-char) [base64-terminal] 671 base64-terminal = 2base64-char "==" / 3base64-char "=" 672 base64-char = UPPER / LOWER / DIGIT / "+" / "/" 673 LOWER = %x61-7A 675 4. Summary of Response Codes 677 This section contains a list of every new response code defined in 678 this document, whether it is multi-line, which commands can gener- 679 ate it, what arguments it has, and what its meaning is. 681 Response code 281 682 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 683 Meaning: authentication accepted 685 Response code 283 686 Generated by: AUTHINFO SASL 687 1 argument: sasl-server-chal 688 Meaning: authentication accepted (with success data) 690 Response code 381 691 Generated by: AUTHINFO USER 692 Meaning: password required 694 Response code 383 695 Generated by: AUTHINFO SASL 696 1 argument: sasl-server-chal 697 Meaning: continue with SASL exchange 699 Response code 481 700 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 701 Meaning: authentication failed/rejected 703 Response code 482 704 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 705 Meaning: authentication commands issued out of sequence or 706 SASL protocol error 708 5. Authentication Tracking/Logging 710 This section contains implementation suggestions and notes of best 711 current practice, and does not specify further network protocol 712 requirements. 714 When authentication succeeds, the server will create an "identity" 715 (the syntax resembles that of an email address) for the client 716 using a technique such as the following (note that when using SASL, 717 "username" corresponds to the authorization identity), for example: 719 (1) Lookup the supplied username in an implementation-specific 720 database or directory to determine the primary email address 721 for that user. 722 (2) Use the username directly as the email address if it is fully 723 qualified (i.e., includes "@hostname"), otherwise append a con- 724 figured "default domain" based on the IP address the client 725 connected to. 726 (3) Use the username followed by "@" and then the result of a 727 reverse DNS lookup on the client's IP address. If the reverse 728 lookup fails, the domain literal syntax defined in SMTP [SMTP] 729 is appropriate. 731 Once authenticated, the server SHOULD be configurable to generate 732 an audit trail associating the authentication identity with any 733 articles supplied during a POST operation, and this configuration 734 SHOULD be the default. This may be accomplished, for example, by 735 inserting headers in the posted articles, or by a server logging 736 mechanism. The server MAY provide a facility for disabling the 737 procedure described above, as some users or administrators may con- 738 sider it a violation of privacy. 740 6. Security Considerations 742 Security issues are discussed throughout this memo. 744 Before the [SASL] negotiation has begun, any protocol interactions 745 may have been performed in the clear and may have been modified by 746 an active attacker. For this reason, clients and servers MUST dis- 747 card any knowledge obtained prior to the start of the SASL negotia- 748 tion upon the establishment of a security layer. 750 Servers MAY implement a policy whereby the connection is dropped 751 after a number of failed authentication attempts. If they do so, 752 they SHOULD NOT drop the connection until at least 3 attempts at 753 authentication have failed. 755 Implementations MUST support a configuration where authentication 756 mechanisms that are vulnerable to passive eavesdropping attacks 757 (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or 758 used without the presence of an external security layer such as TLS 759 [NNTP-TLS]. 761 When multiple authentication mechanisms are permitted by both 762 client and server, an active attacker can cause a down-negotiation 763 to the weakest mechanism. For this reason, both clients and 764 servers SHOULD be configurable to forbid use of weaker mechanisms. 766 7. IANA Considerations 767 7.1. IANA Considerations for SASL/GSSAPI services 769 Please register the SASL/GSSAPI service name "nntp". This service 770 name refers to authenticated use of Usenet news service when pro- 771 vided via the [NNTP] protocol. 773 7.2. IANA Considerations for NNTP extensions 775 Below is a formal definition of the AUTHINFO extension as required 776 by Section 8 of [NNTP] for the IANA registry. 778 o This extension provides an extensible mechanism for NNTP authen- 779 tication via a variety of methods. 781 o The extension-label is "AUTHINFO". 783 o The extension-label has two possible optional arguments "USER" 784 and "SASL:" (as defined in Section 2) indicating which variants 785 of the AUTHINFO command are supported. 787 o The extension defines three new commands, AUTHINFO USER, 788 AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and 789 responses are defined in Section 2. 791 o The extension does not associate any new responses with pre- 792 existing NNTP commands. 794 o The extension may affect the overall behavior of both server and 795 client, in that the AUTHINFO SASL command requires that subse- 796 quent communication to be transmitted via an intermediary secu- 797 rity layer. 799 o The extension does not affect the maximum length of commands or 800 of initial response lines of pre-existing responses. 802 o The extension defines two new responses, 283 and 383, whose 803 lengths may exceed 512 octets. The maximum length of these 804 responses is increased to that which can accommodate the largest 805 encoded challenge possible for any of the SASL mechanisms sup- 806 ported by the implementation. 808 o The extension does not alter pipelining, but AUTHINFO commands 809 cannot be pipelined. 811 o Use of this extension may alter the output from LIST EXTENSIONS. 812 Once any AUTHINFO command has been used successfully, the server 813 may alter the list of arguments for the AUTHINFO capability 814 (although the capability itself must still be listed, even with 815 zero arguments). However, if a SASL security layer has been 816 negotiated, the server SHOULD continue to advertise the "SASL:" 817 argument with the same list of mechanisms, because the client 818 may wish to compare the pre- and post-authentication list of 819 SASL mechanisms in order to detect active down-negotiation 820 attacks. 822 o The extension does not cause any pre-existing command to produce 823 a 401, 480, or 483 response. 825 o The AUTHINFO commands can be used before or after the MODE 826 READER command, with the same semantics. 828 8. Normative References 830 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 831 Specifications: ABNF", RFC 2234, November 1997. 833 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", RFC 1704, 834 Bell Communications Research, October 1994. 836 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 837 Encodings", RFC 3548, July 2003. 839 [DIGEST-MD5] Leach, P., Newman, C., "Using Digest Authentication as a 840 SASL Mechanism", RFC 2831, May 2000. 842 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", RFC 2119, Harvard University, March 1997. 845 [NNTP] Feather, C., "Network News Transport Protocol", 846 draft-ietf-nntpext-base-*.txt, Work in Progress. 848 [NNTP-TLS] Vinocur, J., "Using TLS with NNTP", 849 draft-ietf-nntpext-tls-nntp-*.txt, Work in Progress. 851 [SASL] Melnikov, A., "Simple Authentication and Security Layer 852 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, Work in Progress. 854 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names 855 and passwords", draft-ietf-sasl-saslprep-*.txt, Work in Progress. 857 [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of 858 Internationalized Strings ("stringprep")", 859 draft-hoffman-rfc3454bis-*.txt, Work in Progress. 861 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 862 2279, Alis Technologies, January 1998. 864 9. Informative References 866 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", draft- 867 ietf-sasl-crammd5-*.txt, Work in Progress. 869 [GSSAPI] Melnikov, A., "SASL GSSAPI Mechanisms", draft-ietf-sasl- 870 gssapi-*.txt, Work in Progress. 872 [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, Aca- 873 dem Consulting Services, October 2000. 875 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", draft-ietf-sasl- 876 plain-*.txt, Work in Progress. 878 [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, 879 AT&T Laboratories, April 2001. 881 10. Authors' Addresses 883 Jeffrey M. Vinocur 884 Department of Computer Science 885 Upson Hall 886 Cornell University 887 Ithaca, NY 14853 USA 889 Email: vinocur@cs.cornell.edu 891 Chris Newman 892 Sun Microsystems 893 1050 Lakes Drive, Suite 250 894 West Covina, CA 91790 USA 896 Email: cnewman@iplanet.com 898 Kenneth Murchison 899 Oceana Matrix Ltd. 900 21 Princeton Place 901 Orchard Park, NY 14127 USA 903 Email: ken@oceana.com 905 11. Acknowledgments 907 A significant amount of the authentication text was originally from 908 the NNTP revision or common authentication specs written by Stan 909 Barber. A significant amount of the SASL text was lifted from the 910 revisions to RFC 1734 and RFC 2554 by Rob Siemborski. 912 Special acknowledgment also goes to Russ Allbery, Clive Feather, 913 and others who commented privately on intermediate revisions of 914 this document, as well as the members of the IETF NNTP Working 915 Group for continual (yet sporadic) insight in discussion. 917 12. Intellectual Property Rights 919 The IETF takes no position regarding the validity or scope of any 920 intellectual property or other rights that might be claimed to per- 921 tain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; neither does it represent that it 924 has made any effort to identify any such rights. Information on 925 the IETF's procedures with respect to rights in standards-track and 926 standards-related documentation can be found in BCP-11. Copies of 927 claims of rights made available for publication and any assurances 928 of licenses to be made available, or the result of an attempt made 929 to obtain a general license or permission for the use of such pro- 930 prietary rights by implementers or users of this specification can 931 be obtained from the IETF Secretariat. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights which may cover technology that may be required to practice 936 this standard. Please address the information to the IETF Execu- 937 tive Director. 939 13. Copyright 941 Copyright (C) The Internet Society (2004). All Rights Reserved. 943 This document and translations of it may be copied and furnished to 944 others, and derivative works that comment on or otherwise explain 945 it or assist in its implementation may be prepared, copied, pub- 946 lished and distributed, in whole or in part, without restriction of 947 any kind, provided that the above copyright notice and this para- 948 graph are included on all such copies and derivative works. How- 949 ever, this document itself may not be modified in any way, such as 950 by removing the copyright notice or references to the Internet 951 Society or other Internet organizations, except as needed for the 952 purpose of developing Internet standards in which case the proce- 953 dures for copyrights defined in the Internet Standards process must 954 be followed, or as required to translate it into languages other 955 than English. 957 The limited permissions granted above are perpetual and will not be 958 revoked by the Internet Society or its successors or assigns. 960 This document and the information contained herein is provided on 961 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 962 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 963 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 964 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 965 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.