idnits 2.17.1 draft-ietf-nntpext-authinfo-08.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. 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 : ---------------------------------------------------------------------------- ** 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. -- The draft header indicates that this document updates RFC2970, but the abstract doesn't seem to mention this, which it should. 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). (Using the creation date from RFC2970, updated by this document, for RFC5378 checks: 1999-07-02) -- 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 (May 2005) is 6921 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 723, but not defined == Missing Reference: 'S' is mentioned on line 724, but not defined -- Looks like a reference, but probably isn't: '1' on line 440 -- Looks like a reference, but probably isn't: '2' on line 445 -- Looks like a reference, but probably isn't: '3' on line 461 == Unused Reference: 'CRAM-MD5' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'SMTP' is defined on line 1021, 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) -- No information found for draft-ietf-sasl-rfc2831bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIGEST-MD5' -- 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' ** Obsolete normative reference: RFC 4013 (ref. 'SASLprep') (Obsoleted by RFC 7613) -- 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: 8 errors (**), 0 flaws (~~), 7 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NNTP Extensions Working Group J. Vinocur 3 Internet Draft Cornell University 4 Updates: 2970 (if approved) K. Murchison 5 Expires: November 2005 Oceana Matrix Ltd. 6 C. Newman 7 Sun Microsystems 8 May 2005 10 NNTP Extension for Authentication 11 draft-ietf-nntpext-authinfo-08 13 Status of this memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document defines an extension the Network News Transport 44 Protocol [NNTP] which allows a client to indicate an authentication 45 mechanism to the server, perform an authentication protocol 46 exchange, and optionally negotiate a security layer for subsequent 47 protocol interactions during the remainder of an NNTP session. 49 Section 3.1 of [NNTP-COMMON] summarizes some ad-hoc authentication 50 methods currently used in the NNTP protocol. This document updates 51 and formalizes the AUTHINFO USER/PASS authentication method and 52 deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication 53 methods. Additionally, this document defines a profile of the 54 Simple Authentication and Security Layer [SASL] for NNTP. 56 Table of Contents 58 0. Changes from Previous Version ............................ 2 59 1. Introduction ............................................. 3 60 1.1. Conventions Used in this Document ................... 3 61 2. The AUTHINFO Extension ................................... 4 62 2.1. Advertising the AUTHINFO Extension .................. 4 63 2.2. Authenticating with the AUTHINFO Extension .......... 5 64 2.3. AUTHINFO USER/PASS Command .......................... 6 65 2.3.1. Usage .......................................... 7 66 2.3.2. Description .................................... 7 67 2.3.3. Examples ....................................... 8 68 2.4. AUTHINFO SASL Command ............................... 9 69 2.4.1. Usage .......................................... 9 70 2.4.2. Description .................................... 10 71 2.4.3. Examples ....................................... 13 72 3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16 73 3.1. Commands ............................................ 16 74 3.2. Command Continuation ................................ 16 75 3.3. Responses ........................................... 17 76 3.4. Capability entries .................................. 17 77 3.5. General non-terminals ............................... 17 78 4. Summary of Response Codes ................................ 17 79 5. Authentication Tracking/Logging .......................... 18 80 6. Security Considerations .................................. 18 81 7. IANA Considerations ...................................... 19 82 7.1. IANA Considerations for SASL/GSSAPI services ........ 19 83 7.2. IANA Considerations for NNTP extensions ............. 19 84 8. References ............................................... 21 85 8.1. Normative References ................................ 21 86 8.2. Informative References .............................. 21 87 9. Authors' Addresses ....................................... 22 88 10. Acknowledgments ......................................... 22 89 11. Intellectual Property Rights ............................ 23 90 12. Copyright ............................................... 23 92 0. Changes from Previous Version 94 Changed: 95 o Updated to RFC 3978/3979 boilerplate. 96 o Uses new ABNF tokens from [NNTP]. 98 o Fixed a typo in note regarding AUTHINFO SASL and 480 response. 99 o Section 6: Sync'd language with [NNTP-TLS]. 101 Clarified: 102 o Section 3: This document extends the ABNF in [NNTP], and the 103 [NNTP] ABNF must be imported first before validating the 104 AUTHINFO ABNF (based on recommendations of AD regarding 105 IMAPEXT I-Ds). 107 1. Introduction 109 Although NNTP [NNTP] has traditionally been used to provide public 110 access to newsgroups, authentication is often useful, for example 111 to control resource consumption, to allow abusers of the POST 112 command to be identified, and to restrict access to "local" 113 newsgroups. 115 The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in 116 [NNTP-COMMON], provide a very weak authentication mechanism in 117 widespread use by the installed base. Due to their ubiquity they 118 are formalized in this specification but, because of their 119 insecurity, only for use in combination with appropriate security 120 layers. 122 The ad-hoc AUTHINFO GENERIC command, also documented in 123 [NNTP-COMMON] but much less ubiquitous, provided an NNTP-specific 124 equivalent of the generic SASL [SASL] facility. This document 125 deprecates AUTHINFO GENERIC in favor of an AUTHINFO SASL 126 replacement so that NNTP can benefit from authentication mechanisms 127 developed for other SASL-enabled application protocols including 128 SMTP, POP, IMAP, LDAP, and BEEP. 130 This specification is to be read in conjunction with the NNTP base 131 specification [NNTP]. Except where specifically stated otherwise, 132 in the case of a conflict between these two documents [NNTP] takes 133 precedence over this one. 135 It is also recommended that this specification be read in 136 conjunction with the SASL base specification [SASL]. 138 1.1. Conventions Used in this Document 140 The notational conventions used in this document are the same as 141 those in [NNTP] and any term not defined in this document has the 142 same meaning as in that one. 144 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 145 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 146 as described in "Key words for use in RFCs to Indicate Requirement 147 Levels" [KEYWORDS]. 149 Terms related to authentication are defined in "On Internet 150 Authentication" [AUTH]. 152 In the examples, commands from the client are indicated with [C], 153 and responses from the server are indicated with [S]. 155 2. The AUTHINFO Extension 157 The AUTHINFO extension is used to authenticate a user. Note that 158 authorization is a matter of site policy, not network protocol, and 159 is therefore not discussed in this document. The server determines 160 authorization in whatever manner is defined by its implementation 161 as configured by the site administrator. 163 This extension provides three new commands: AUTHINFO USER, AUTHINFO 164 PASS, and AUTHINFO SASL. The capability label for this extension 165 is AUTHINFO. 167 2.1. Advertising the AUTHINFO Extension 169 A server MUST implement at least one of the AUTHINFO USER or 170 AUTHINFO SASL commands in order to advertise the AUTHINFO 171 capability in the response to the CAPABILITIES command. However, 172 this capability MUST NOT be advertised after successful 173 authentication (see section 2.2). This capability MAY be 174 advertised both before and after any use of MODE READER, with the 175 same semantics. 177 The AUTHINFO capability label contains an argument list detailing 178 which authentication commands are available. 180 The "USER" argument indicates that AUTHINFO USER/PASS is supported 181 as defined by Section 2.3 of this document. The "USER" argument 182 MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD 183 NOT be provided, unless a strong encryption layer (e.g. TLS 184 [NNTP-TLS]) is in use or backward compatibility dictates otherwise. 186 The "SASL" argument indicates that AUTHINFO SASL is supported as 187 defined by Section 2.4 of this document. If the server advertises 188 the "SASL" argument, then it MUST also advertise the "SASL" 189 capability in response to the CAPABILITIES command. The SASL 190 capability is followed by a whitespace-separated list of available 191 SASL mechanism names. 193 The server may list the AUTHINFO capability with no arguments, 194 which indicates that it complies with this specification and does 195 not permit any authentication commands in its current state. In 196 this case, the client MUST NOT attempt to utilize any AUTHINFO 197 commands, even if it contains logic to do so (e.g. for backward 198 compatibility with servers that are not compliant with this 199 specification). 201 Future extensions may add additional arguments to this capability. 202 Unrecognized arguments SHOULD be ignored or brought to the 203 attention of the user. 205 As the AUTHINFO command is related to security, cached results of 206 CAPABILITIES from a previous session MUST NOT be relied on, as per 207 section 12.6 of [NNTP]. 209 Example (here, the STARTTLS extension [NNTP-TLS] is also in use): 211 [C] CAPABILITIES 212 [S] 101 Capability list: 213 [S] VERSION 2 214 [S] READER 215 [S] IHAVE 216 [S] STARTTLS 217 [S] AUTHINFO SASL 218 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI 219 [S] LIST ACTIVE NEWSGROUPS 220 [S] . 221 [C] STARTTLS 222 [S] 382 Continue with TLS negotiation 223 [TLS negotiation proceeds, further commands protected by TLS] 224 [C] CAPABILITIES 225 [S] 101 Capability list: 226 [S] VERSION 2 227 [S] READER 228 [S] IHAVE 229 [S] AUTHINFO USER SASL 230 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL 231 [S] LIST ACTIVE NEWSGROUPS 232 [S] . 234 2.2. Authenticating with the AUTHINFO Extension 236 An NNTP server responds to a client command with a 480 response to 237 indicate that the client MUST authenticate and/or authorize in 238 order to use that command or access the indicated resource. Use of 239 the AUTHINFO command as described below is one such way that a 240 client can authenticate/authorize to the server. The client MAY 241 therefore use an AUTHINFO command after receiving a 480 response. 243 A client intending to use an AUTHINFO command SHOULD issue the 244 CAPABILITIES command to obtain the available authentication 245 commands and mechanisms before attempting authentication. 247 If a server advertises the AUTHINFO capability, a client MAY 248 attempt the first step of authentication at any time during a 249 session to acquire additional privileges without having received a 250 480 response. Servers SHOULD accept such unsolicited 251 authentication requests. A server MUST NOT under any circumstances 252 reply to an AUTHINFO command with a 480 response. 254 A client MUST NOT under any circumstances continue with any steps 255 of authentication beyond the first, unless the response code from 256 the server indicates that the authentication exchange is welcomed. 257 In particular, anything other than a 38x response code indicates 258 that the client MUST NOT continue the authentication exchange. 260 After a successful authentication, the client MUST NOT issue 261 another AUTHINFO command in the same session. A server MUST NOT 262 return the AUTHINFO capability in response to a CAPABILITIES 263 command and a server MUST reject any subsequent AUTHINFO commands 264 with a 502 response. Additionally, the client MUST NOT issue a 265 MODE READER command after authentication and a server MUST NOT 266 advertise the MODE-READER capability. 268 In agreement with [SASL], the server MUST continue to advertise the 269 SASL capability in response to a CAPABILITIES command with the same 270 list of SASL mechanisms as before authentication (thereby enabling 271 the client to detect a possible active down-negotiation attack). 272 Other capabilities returned in response to a CAPABILITIES command 273 received after authentication MAY be different than those returned 274 before authentication. For example, an NNTP server may not want to 275 advertise support for a specific extension unless a client has been 276 authenticated. 278 It should be noted that a server may perform a successful 279 authentication exchange with a client and yet still deny access to 280 some or all resources; the permanent 502 response indicates a 281 resource is unavailable even though authentication has been 282 performed (this is in contrast to the temporary 480 error 283 indicating that a resource is unavailable now but may become 284 available after authentication). 286 2.3. AUTHINFO USER/PASS Command 288 This section supersedes the definition of the AUTHINFO USER and 289 AUTHINFO PASS commands as documented in Section 3.1.1 of 290 [NNTP-COMMON]. 292 2.3.1. Usage 294 These commands MUST NOT be pipelined. 296 Syntax 297 AUTHINFO USER username 298 AUTHINFO PASS password 300 Responses 301 281 Authentication accepted 302 381 Password required [1] 303 481 Authentication failed/rejected 304 482 Authentication commands issued out of sequence 305 502 Command unavailable [2] 307 [1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx 308 codes which indicate that the client may continue the current 309 command, the legacy 381 code means that the AUTHINFO PASS command 310 must be used to complete the authentication exchange. 312 [2] If authentication has already occurred, AUTHINFO USER/PASS are 313 not valid commands (see section 2.2). 315 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 316 return 480 in response to AUTHINFO USER/PASS. 318 Parameters 319 username = UTF-8 string identifying the user/client 320 password = UTF-8 string representing the user's password 322 2.3.2. Description 324 The AUTHINFO USER and AUTHINFO PASS commands are used to present 325 clear text credentials to the server. These credentials consist of 326 a username or a username plus a password (the distinction is that a 327 password is expected to be kept secret while a username is not; 328 this does not directly affect the protocol but may have an impact 329 on user interfaces). The username is supplied through the AUTHINFO 330 USER command, and the password through the AUTHINFO PASS command. 332 If the server requires only a username, it MUST NOT give a 381 333 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO 334 PASS. 336 If the server requires both username and password, the former MUST 337 be sent before the latter. The server will need to cache the 338 username until the password is received; it MAY require the 339 password to be sent in the immediately next command (in other 340 words, only caching the username until the next command is sent). 341 The server: 343 - MUST return a 381 response to AUTHINFO USER; 344 - MUST return a 482 response to AUTHINFO PASS if there is no 345 cached username; 346 - MUST use the argument of the most recent AUTHINFO USER for 347 authentication; 348 - MUST NOT return a 381 response to AUTHINFO PASS. 350 The server MAY determine whether or not a password is needed based 351 on the username. Thus the same server can respond with both 381 352 and other response codes to AUTHINFO USER. 354 The AUTHINFO PASS command permits the client to use a clear-text 355 password to authenticate. A compliant implementation MUST NOT 356 implement this command without also implementing support for TLS 357 [NNTP-TLS]. Use of this command without an active strong 358 encryption layer is deprecated, as it exposes the user's password 359 to all parties on the network between the client and the server. 360 Any implementation of this command SHOULD be configurable to 361 disable it whenever a strong encryption layer such as that provided 362 by [NNTP-TLS] is not active, and this configuration SHOULD be the 363 default. The server will use the 483 response code to indicate 364 that the datastream is insufficiently secure for the command being 365 attempted. 367 Usernames and passwords MUST use the UTF-8 [UTF-8] character set 368 and a client MUST convert any user input to UTF-8 if necessary. 370 Note that a server MAY, but is not required to, allow white space 371 characters in usernames and passwords. A server implementation MAY 372 blindly split command arguments at white space and therefore not 373 preserve the exact sequence of white space characters in the 374 username or password. Therefore a client SHOULD scan the username 375 and password for whitespace, and if detected, warn the user of the 376 likelihood of problems. The SASL PLAIN [PLAIN] mechanism is 377 recommended as an alternative, as it does not suffer from these 378 issues. 380 2.3.3. Examples 382 Example of successful AUTHINFO USER: 384 [C] AUTHINFO USER wilma 385 [S] 281 Authentication accepted 387 Example of successful AUTHINFO USER/PASS: 389 [C] AUTHINFO USER fred 390 [S] 381 Enter passphrase 391 [C] AUTHINFO PASS flintstone 392 [S] 281 Authentication accepted 394 Example of AUTHINFO USER/PASS requiring a security layer: 396 [C] AUTHINFO USER fred@stonecanyon.example 397 [S] 483 Encryption or stronger authentication required 399 Example of failed AUTHINFO USER/PASS: 401 [C] AUTHINFO USER barney 402 [S] 381 Enter passphrase 403 [C] AUTHINFO PASS flintstone 404 [S] 481 Authentication failed 406 Example of AUTHINFO PASS before AUTHINFO USER: 408 [C] AUTHINFO PASS flintstone 409 [S] 482 Authentication commands issued out of sequence 411 2.4. AUTHINFO SASL Command 413 This section defines a formal profile of the Simple Authentication 414 and Security Layer [SASL]. The use of the AUTHINFO GENERIC command 415 as documented in Section 3.1.3 of [NNTP-COMMON] as a way to perform 416 SASL authentication is deprecated in favor of the AUTHINFO SASL 417 command. A server SHOULD NOT advertise AUTHINFO GENERIC in the 418 list of capabilities returned by CAPABILITIES. 420 2.4.1. Usage 422 This command MUST NOT be pipelined. 424 Syntax 425 AUTHINFO SASL mechanism [initial-response] 427 This command MAY exceed 512 octets. The maximum length of this 428 command is increased to that which can accommodate the largest 429 encoded initial response possible for any of the SASL mechanisms 430 supported by the implementation. 432 Responses 433 281 Authentication accepted 434 283 challenge Authentication accepted (with success data) [1] 435 383 challenge Continue with SASL exchange [1] 436 481 Authentication failed/rejected 437 482 SASL protocol error 438 502 Command unavailable [2] 440 [1] These responses MAY exceed 512 octets. The maximum length of 441 these responses is increased to that which can accommodate the 442 largest encoded challenge possible for any of the SASL mechanisms 443 supported by the implementation. 445 [2] If authentication has already occurred, AUTHINFO SASL is not a 446 valid command (see section 2.2). 448 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 449 return 480 in response to AUTHINFO SASL. 451 Parameters 452 mechanism = String identifying a [SASL] authentication 453 mechanism. 454 initial-response = Optional initial client response. 455 If present, the response MUST be encoded as 456 specified in Section 3 of [BASE64]. [3] 457 challenge = Server challenge. 458 The challenge MUST be encoded as specified 459 in Section 3 of [BASE64]. 461 [3] This argument MAY exceed 497 octets. The maximum length of 462 this argument is increased to that which can accommodate the 463 largest encoded initial response possible for any of the SASL 464 mechanisms supported by the implementation. 466 2.4.2. Description 468 The AUTHINFO SASL command initiates a [SASL] authentication 469 exchange between the client and the server. The client identifies 470 the SASL mechanism to use with the first parameter of the AUTHINFO 471 SASL command. If the server supports the requested authentication 472 mechanism, it performs the SASL exchange to authenticate the user. 473 Optionally, it also negotiates a security layer for subsequent 474 protocol interactions during this session. If the requested 475 authentication mechanism is invalid (e.g. is not supported), the 476 server rejects the AUTHINFO SASL command with a 503 reply. If the 477 requested authentication mechanism requires an encryption layer, 478 the server rejects the AUTHINFO SASL command with a 483 reply. 480 The service name specified by this protocol's profile of SASL is 481 "nntp". 483 The SASL authentication exchange consists of a series of server 484 challenges and client responses that are specific to the chosen 485 [SASL] mechanism. 487 A server challenge is sent as a 383 reply with a single argument 488 containing the [BASE64] encoded string supplied by the SASL 489 mechanism. A server challenge that has zero length MUST be sent as 490 a single equals sign ("=") and not omitted (in order to comply with 491 the [NNTP] requirement that responses always have the same number 492 of arguments). 494 A client response consists of a line containing a [BASE64] encoded 495 string. A client response that has zero length MUST be sent as a 496 single equals sign ("=") and not omitted (for consistency with the 497 server challenge format). If the client wishes to cancel the 498 authentication exchange, it issues a line with a single "*". If 499 the server receives such a response, it MUST reject the AUTHINFO 500 SASL command by sending a 481 reply. 502 Note that these [BASE64] strings can be much longer than normal 503 NNTP responses. Clients and servers MUST be able to handle the 504 maximum encoded size of challenges and responses generated by their 505 supported authentication mechanisms. This requirement is 506 independent of any line length limitations the client or server may 507 have in other parts of its protocol implementation. 509 The optional initial response argument to the AUTHINFO SASL command 510 is used to save a round trip when using authentication mechanisms 511 that support an initial client response. If the initial response 512 argument is omitted and the chosen mechanism requires an initial 513 client response, the server MUST proceed as defined in section 5.1 514 of [SASL]. In NNTP, a server challenge that contains no data is 515 equivalent to a zero length challenge and is encoded as a single 516 equals sign ("="). 518 Note that the [BASE64] encoded initial response argument can exceed 519 497 octets and therefore the AUTHINFO SASL command can exceed 512 520 octets. Clients SHOULD, and servers MUST be able to handle the 521 maximum encoded size of initial responses possible for their 522 supported authentication mechanisms. This requirement is 523 independent of any command or argument length limitations the 524 client or server may have in other parts of its protocol 525 implementation. 527 If use of the initial response argument would cause the AUTHINFO 528 SASL command to exceed 512 octets, the client MAY choose to omit 529 the initial response parameter (and instead proceed as defined in 530 section 5.1 of [SASL]). 532 If the client is transmitting an initial response of zero length, 533 it MUST instead transmit the response as a single equals sign 534 ("="). This indicates that the response is present, but contains 535 no data. 537 If the client uses an initial-response argument to the AUTHINFO 538 SASL command with a SASL mechanism that does not support an initial 539 client response, the server MUST reject the AUTHINFO SASL command 540 with a 482 reply. 542 If the server cannot [BASE64] decode any client response, it MUST 543 reject the AUTHINFO SASL command with a 504 reply. If the client 544 cannot BASE64 decode any of the server's challenges, it MUST cancel 545 the authentication using the "*" response. In particular, servers 546 and clients MUST reject (and not ignore) any character not 547 explicitly allowed by the BASE64 alphabet, and MUST reject any 548 sequence of BASE64 characters that contains the pad character ('=') 549 anywhere other than the end of the string (e.g. "=AAA" and 550 "AAA=BBB" are not allowed). 552 The authorization identity generated by this [SASL] exchange is a 553 simple username, and both client and server MUST use the [SASLprep] 554 profile of the [StringPrep] algorithm to prepare these names for 555 transmission or comparison. If preparation of the authorization 556 identity fails or results in an empty string (unless it was 557 transmitted as the empty string), the server MUST fail the 558 authentication with a 481 reply. 560 Should the client successfully complete the exchange, the server 561 issues either a 281 or 283 reply. If the server is unable to 562 authenticate the client, it MUST reject the AUTHINFO SASL command 563 with a 481 reply. If an AUTHINFO SASL command fails, the client 564 MAY proceed without authentication. Alternatively, the client MAY 565 try another authentication mechanism, or present different 566 credentials by issuing another AUTHINFO command. 568 If the SASL mechanism returns additional data on success (e.g. 569 server authentication), the NNTP server issues a 283 reply with a 570 single argument containing the [BASE64] encoded string supplied by 571 the SASL mechanism. If no additional data is returned on success, 572 the server issues a 281 reply. 574 If a security layer is negotiated during the SASL exchange, it 575 takes effect for the client on the octet immediately following the 576 CRLF that concludes the last response generated by the client. For 577 the server, it takes effect immediately following the CRLF of its 578 success reply. 580 When a security layer takes effect, the NNTP protocol is reset to 581 the state immediately after the initial greeting response (see 5.1 582 of [NNTP]) has been sent, with the exception that if a MODE READER 583 command has been issued, the effects of it (if any) are not 584 reversed. The server MUST discard any knowledge obtained from the 585 client, such as the current newsgroup and article number, that was 586 not obtained from the SASL negotiation itself. Likewise, the 587 client SHOULD discard and MUST NOT rely on any knowledge obtained 588 from the server, such as the capability list, that was not obtained 589 from the SASL negotiation itself. (Note that a client MAY compare 590 the advertised SASL mechanisms before and after authentication in 591 order to detect an active down-negotiation attack.) 593 When both TLS [NNTP-TLS] and SASL security layers are in effect, 594 the TLS encoding MUST be applied after the SASL encoding (the 595 cleartext data is always SASL encoded first and then the resultant 596 data is TLS encoded). 598 To ensure interoperability, client and server implementations of 599 this extension MUST implement the [DIGEST-MD5] SASL mechanism. 601 If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the 602 SASL [PLAIN] mechanism SHOULD also be implemented, as the 603 functionality of DIGEST-MD5 is insufficient for some environments 604 (e.g. the server may need to pass the plaintext password off to an 605 external authentication service). The SASL PLAIN mechanism is 606 preferred over AUTHINFO USER, even if there is not a strong 607 encryption layer active, because it eliminates limitations that 608 AUTHINFO USER/PASS has with regards to white space characters being 609 used in usernames and passwords. 611 2.4.3. Examples 613 Example of the [PLAIN] SASL mechanism under a TLS layer, using an 614 initial client response: 616 [C] CAPABILITIES 617 [S] 101 Capability list: 618 [S] VERSION 2 619 [S] READER 620 [S] STARTTLS 621 [S] AUTHINFO SASL 622 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI 623 [S] LIST ACTIVE NEWSGROUPS 624 [S] . 625 [C] STARTTLS 626 [S] 382 Continue with TLS negotiation 627 [TLS negotiation proceeds, further commands protected by TLS] 629 [C] CAPABILITIES 630 [S] 101 Capability list: 631 [S] VERSION 2 632 [S] READER 633 [S] AUTHINFO USER SASL 634 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL 635 [S] LIST ACTIVE NEWSGROUPS 636 [S] . 637 [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA== 638 [S] 281 Authentication accepted 640 Example of the EXTERNAL SASL mechanism under a TLS layer, using the 641 authorization identity derived from the client TLS certificate, and 642 thus a zero-length initial client response (commands prior to 643 AUTHINFO SASL are the same as the previous example and have been 644 omitted): 646 [C] AUTHINFO SASL EXTERNAL = 647 [S] 281 Authentication accepted 649 Example of the [DIGEST-MD5] SASL mechanism, which includes a server 650 challenge and server success data (whitespace has been inserted for 651 clarity; base64-encoded data is actually sent as a single line with 652 no embedded whitespace): 654 [C] AUTHINFO SASL DIGEST-MD5 655 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 656 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo 657 LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj 658 NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 659 aG09bWQ1LXNlc3M= 660 [C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j 661 ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp 662 UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J 663 aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy 664 PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs 665 cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= 666 [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ== 668 Example of a failed authentication due to bad [GSSAPI] credentials. 669 Note that while the mechanism can utilize the initial response, the 670 client chooses not to use it because of its length, resulting in a 671 zero-length server challenge (here whitespace has been inserted for 672 clarity; base64-encoded data is actually sent as a single line with 673 no embedded whitespace): 675 [C] AUTHINFO SASL GSSAPI 676 [S] 383 = 678 [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj 679 ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw 680 IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB 681 EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 682 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP 683 ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 684 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ 685 djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6 686 Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj 687 RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL 688 kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0 689 0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF 690 iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw= 691 [S] 481 Authentication error 693 Example of a client aborting in the midst of an exchange: 695 [C] AUTHINFO SASL GSSAPI 696 [S] 383 = 697 [C] * 698 [S] 481 Authentication aborted as requested 700 Example of attempting to use a mechanism that is not supported by 701 the server: 703 [C] AUTHINFO SASL EXAMPLE 704 [S] 503 Mechanism not recognized 706 Example of attempting to use a mechanism that requires a security 707 layer: 709 [C] AUTHINFO SASL PLAIN 710 [S] 483 Encryption or stronger authentication required 712 Example of using an initial response with a mechanism that doesn't 713 support it (server must start the exchange): 715 [C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== 716 [S] 482 SASL protocol error 718 Example of a failed authentication due to an incorrectly encoded 719 response: 721 [C] AUTHINFO SASL CRAM-MD5 722 [S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+ 723 [C] abcd=efg 724 [S] 504 Base64 encoding error 726 3. Augmented BNF Syntax for the AUTHINFO Extension 728 This section describes the formal syntax of the AUTHINFO extension 729 using ABNF [ABNF]. It extends the syntax in section 9 of [NNTP], 730 and non-terminals not defined in this document are defined there. 731 The [NNTP] ABNF should be imported first before attempting to 732 validate these rules. 734 3.1. Commands 736 This syntax extends the non-terminal "command", which represents an 737 NNTP command. 739 command =/ authinfo-sasl-command / 740 authinfo-user-command / 741 authinfo-pass-command 743 authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism 744 [WS initial-response] 745 authinfo-user-command = "AUTHINFO" WS "USER" WS username 746 authinfo-pass-command = "AUTHINFO" WS "PASS" WS password 748 initial-response = base64-opt 749 username = 1*user-pass-char 750 password = 1*user-pass-char 751 user-pass-char = P-CHAR 753 NOTE: A server implementation MAY parse AUTHINFO USER and AUTHINFO 754 PASS specially as to allow white space to be used within the 755 username or password. Such implementations accept the additional 756 syntax (making these two items inconsistent with "token" in section 757 9.8 of [NNTP]): 759 user-pass-char =/ SP / TAB 761 In doing so, the grammar can become ambiguous if the username or 762 password begins or ends with white space. To solve this ambiguity, 763 such implementations typically treat everything after the first 764 white space character following "USER"/"PASS", up to, but not 765 including, the CRLF as the username/password. 767 3.2. Command Continuation 769 This syntax extends the non-terminal "command-continuation", which 770 represents the further material sent by the client in the case of 771 multi-stage commands. 773 command-continuation =/ authinfo-sasl-383-continuation 775 authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF 777 3.3. Responses 779 This syntax extends the non-terminal "initial-response-content", 780 which represents an initial response line sent by the server. 782 initial-response-content =/ response-283-content / 783 response-383-content 785 response-283-content = "283" SP base64 786 response-383-content = "383" SP base64-opt 788 3.4. Capability entries 790 This syntax extends the non-terminal "capability-entry", which rep- 791 resents a capability that may be advertised by the server. 793 capability-entry =/ authinfo-capability / 794 sasl-capability 796 authinfo-capability = "AUTHINFO" *(WS authinfo-variant) 797 authinfo-variant = "USER" / "SASL" 798 sasl-capability = "SASL" 1*(WS mechanism) 800 3.5. General non-terminals 802 base64-opt = "=" / base64 803 mechanism = 1*20mech-char 804 mech-char = UPPER / DIGIT / "-" / "_" 806 4. Summary of Response Codes 808 This section contains a list of every new response code defined in 809 this document, whether it is multi-line, which commands can 810 generate it, what arguments it has, and what its meaning is. 812 Response code 281 813 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 814 Meaning: authentication accepted 816 Response code 283 817 Generated by: AUTHINFO SASL 818 1 argument: challenge 819 Meaning: authentication accepted (with success data) 821 Response code 381 822 Generated by: AUTHINFO USER 823 Meaning: password required via AUTHINFO PASS command. Note 824 that this code is used for backwards compatibility and does 825 not conform to the traditional use of 3xx codes. 827 Response code 383 828 Generated by: AUTHINFO SASL 829 1 argument: challenge 830 Meaning: continue with SASL exchange 832 Response code 481 833 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 834 Meaning: authentication failed/rejected 836 Response code 482 837 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 838 Meaning: authentication commands issued out of sequence or 839 SASL protocol error 841 5. Authentication Tracking/Logging 843 This section contains implementation suggestions and notes of best 844 current practice, and does not specify further network protocol 845 requirements. 847 Once authenticated, the authorization identity presented in the 848 AUTHINFO exchange (username when using USER/PASS) SHOULD be 849 included in an audit trail associating the identity with any 850 articles supplied during a POST operation, and this configuration 851 SHOULD be the default. This may be accomplished, for example, by 852 inserting headers in the posted articles or by a server logging 853 mechanism. The server MAY provide a facility for disabling the 854 procedure described above, as some users or administrators may 855 consider it a violation of privacy. 857 6. Security Considerations 859 Security issues are discussed throughout this memo. 861 In general, the security considerations of [SASL] and any 862 implemented SASL mechanisms are applicable here; only the most 863 important are highlighted specifically below. Also, this extension 864 is not intended to cure the security considerations described in 865 section 12 of [NNTP]; those considerations remain relevant to any 866 NNTP implementation. 868 Before the [SASL] negotiation has begun, any protocol interactions 869 may have been performed in the clear and may have been modified by 870 an active attacker. For this reason, clients and servers MUST 871 discard any sensitive knowledge obtained prior to the start of the 872 SASL negotiation upon the establishment of a security layer. 873 Furthermore, the CAPABILITIES command SHOULD be re-issued upon the 874 establishment of a security layer, and other protocol state SHOULD 875 be re-negotiated as well. 877 Servers MAY implement a policy whereby the connection is dropped 878 after a number of failed authentication attempts. If they do so, 879 they SHOULD NOT drop the connection until at least 3 attempts at 880 authentication have failed. 882 Implementations MUST support a configuration where authentication 883 mechanisms that are vulnerable to passive eavesdropping attacks 884 (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or 885 used without the presence of an external security layer such as TLS 886 [NNTP-TLS]. 888 When multiple authentication mechanisms are permitted by both 889 client and server, an active attacker can cause a down-negotiation 890 to the weakest mechanism. For this reason, both clients and 891 servers SHOULD be configurable to forbid use of weak mechanisms. 892 The minimum strength acceptable is a policy decision which is 893 outside the scope of this specification. 895 7. IANA Considerations 897 7.1. IANA Considerations for SASL/GSSAPI services 899 Please register the SASL/GSSAPI service name "nntp". This service 900 name refers to authenticated use of Usenet news service when 901 provided via the [NNTP] protocol. 903 o Published Specification: This document. 905 o Author, Change Controller, and Contact for Further Information: 906 Author of this document. 908 7.2. IANA Considerations for NNTP extensions 910 This section gives a formal definition of the AUTHINFO extension as 911 required by Section 3.3.3 of [NNTP] for the IANA registry. 913 o This extension provides an extensible mechanism for NNTP 914 authentication via a variety of methods. 916 o The capability label for this extension is "AUTHINFO". 918 o The "AUTHINFO" capability label has two possible optional 919 arguments "USER" and "SASL" (as defined in Section 2.1) 920 indicating which variants of the AUTHINFO command are supported. 922 o This extension also provides the "SASL" capability label whose 923 arguments list the available SASL mechanisms. 925 o This extension defines three new commands, AUTHINFO USER, 926 AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and 927 responses are defined in Sections 2.3 and 2.4. 929 o This extension does not associate any new responses with pre- 930 existing NNTP commands. 932 o This extension may affect the overall behavior of both server 933 and client, in that the AUTHINFO SASL command may require that 934 subsequent communication be transmitted via an intermediary 935 security layer. 937 o The length of the AUTHINFO SASL command (as defined in this 938 document) may exceed 512 octets. The maximum length of this 939 command is increased to that which can accommodate the largest 940 initial response possible for any of the SASL mechanisms 941 supported by the implementation. 943 o This extension defines two new responses, 283 and 383, whose 944 lengths may exceed 512 octets. The maximum length of these 945 responses is increased to that which can accommodate the largest 946 challenge possible for any of the SASL mechanisms supported by 947 the implementation. 949 o This extension does not alter pipelining, but AUTHINFO commands 950 cannot be pipelined. 952 o Use of this extension may alter the capabilities list; once the 953 AUTHINFO command has been used successfully, the AUTHINFO 954 capability can no longer be advertised by CAPABILITIES. 955 Additionally, the MODE-READER capability MUST NOT be advertised 956 after successful authentication. 958 o This extension does not cause any pre-existing command to 959 produce a 401, 480, or 483 response. 961 o This extension is unaffected by any use of the MODE READER 962 command, however the MODE READER command MUST NOT be used in the 963 same session following successful authentication. 965 o Published Specification: This document. 967 o Author, Change Controller, and Contact for Further Information: 968 Author of this document. 970 8. References 972 8.1. Normative References 974 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 975 Specifications: ABNF", RFC 2234, November 1997. 977 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", 978 RFC 1704, October 1994. 980 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 981 Encodings", RFC 3548, July 2003. 983 [DIGEST-MD5] Leach, P., Newman, C., Melnikov, A., 984 "Using Digest Authentication as a SASL Mechanism", 985 draft-ietf-sasl-rfc2831bis-*.txt, Work in Progress. 987 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", BCP 14, RFC 2119, March 1997. 990 [NNTP] Feather, C., "Network News Transport Protocol", 991 draft-ietf-nntpext-base-*.txt, Work in Progress. 993 [NNTP-TLS] Murchison, K., Vinocur, J., Newman, C., 994 "Using TLS with NNTP", draft-ietf-nntpext-tls-nntp-*.txt, 995 Work in Progress. 997 [SASL] Melnikov, A., "Simple Authentication and Security Layer 998 (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, Work in Progress. 1000 [SASLprep] Zeilega, K., "SASLprep: Stringprep Profile for 1001 User Names and Passwords", RFC 4013, February 2005. 1003 [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of 1004 Internationalized Strings ("stringprep")", 1005 draft-hoffman-rfc3454bis-*.txt, Work in Progress. 1007 8.2. Informative References 1009 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", 1010 draft-ietf-sasl-crammd5-*.txt, Work in Progress. 1012 [GSSAPI] Melnikov, A., "SASL GSSAPI Mechanisms", 1013 draft-ietf-sasl-gssapi-*.txt, Work in Progress. 1015 [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, 1016 October 2000. 1018 [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", 1019 draft-ietf-sasl-plain-*.txt, Work in Progress. 1021 [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, 1022 April 2001. 1024 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 1025 RFC 3629, November 2003. 1027 9. Authors' Addresses 1029 Jeffrey M. Vinocur 1030 Department of Computer Science 1031 Upson Hall 1032 Cornell University 1033 Ithaca, NY 14853 USA 1035 Email: vinocur@cs.cornell.edu 1037 Kenneth Murchison 1038 Oceana Matrix Ltd. 1039 21 Princeton Place 1040 Orchard Park, NY 14127 USA 1042 Email: ken@oceana.com 1044 Chris Newman 1045 Sun Microsystems 1046 1050 Lakes Drive, Suite 250 1047 West Covina, CA 91790 USA 1049 Email: cnewman@iplanet.com 1051 10. Acknowledgments 1053 A significant amount of the authentication text was originally from 1054 the NNTP revision or common authentication specs written by Stan 1055 Barber. A significant amount of the SASL text was lifted from the 1056 revisions to RFC 1734 and RFC 2554 by Rob Siemborski. 1058 Special acknowledgment also goes to Russ Allbery, Clive Feather, 1059 and others who commented privately on intermediate revisions of 1060 this document, as well as the members of the IETF NNTP Working 1061 Group for continual (yet sporadic) insight in discussion. 1063 11. Intellectual Property Rights 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed 1067 to pertain to the implementation or use of the technology described 1068 in this document or the extent to which any license under such 1069 rights might or might not be available; nor does it represent that 1070 it has made any independent effort to identify any such rights. 1071 Information on the procedures with respect to rights in RFC 1072 documents can be found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use 1077 of such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository 1079 at http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. Please address the information to the IETF at 1085 ietf-ipr@ietf.org. 1087 12. Copyright 1089 Copyright (C) The Internet Society (2005). 1091 This document is subject to the rights, licenses and restrictions 1092 contained in BCP 78, and except as set forth therein, the authors 1093 retain all their rights. 1095 This document and the information contained herein are provided on 1096 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1097 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1098 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1099 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1100 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1101 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1102 PARTICULAR PURPOSE.