idnits 2.17.1 draft-ietf-nntpext-authinfo-10.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 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1088. ** 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-TLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2980, but the abstract doesn't seem to directly say this. It does mention RFC2980 though, so this could be OK. 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 RFC2980, updated by this document, for RFC5378 checks: 1997-10-13) -- 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 (August 2005) is 6826 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 730, but not defined == Missing Reference: 'S' is mentioned on line 731, but not defined -- Looks like a reference, but probably isn't: '1' on line 446 -- Looks like a reference, but probably isn't: '2' on line 451 -- Looks like a reference, but probably isn't: '3' on line 467 == Unused Reference: 'CRAM-MD5' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'SMTP' is defined on line 1028, 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) ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) -- 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 (~~), 7 warnings (==), 23 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: 2980 (if approved) K. Murchison 5 Expires: February 2006 Oceana Matrix Ltd. 6 C. Newman 7 Sun Microsystems 8 August 2005 10 NNTP Extension for Authentication 11 draft-ietf-nntpext-authinfo-10 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 to 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 This document updates and formalizes the AUTHINFO USER/PASS 50 authentication method specified in RFC 2980 and deprecates the 51 AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. 52 Additionally, this document defines a profile of the Simple 53 Authentication and Security Layer (SASL) for NNTP. 55 Note to the RFC Editor 57 The normative references to RFC 2234 and RFC 3454 may 58 be replaced by draft-crocker-abnf-rfc2234bis and 59 draft-hoffman-rfc3454bis respectively should one or both of those 60 documents reach RFC status before this one. 62 The normative references to [NNTP] and [NNTP-TLS] are documents 63 which are expected to be published simultaneously with this one 64 and so can be replaced by references to the resulting RFCs. 66 Table of Contents 68 1. Introduction ............................................. 3 69 1.1. Conventions Used in this Document ................... 3 70 2. The AUTHINFO Extension ................................... 4 71 2.1. Advertising the AUTHINFO Extension .................. 4 72 2.2. Authenticating with the AUTHINFO Extension .......... 5 73 2.3. AUTHINFO USER/PASS Command .......................... 6 74 2.3.1. Usage .......................................... 6 75 2.3.2. Description .................................... 7 76 2.3.3. Examples ....................................... 9 77 2.4. AUTHINFO SASL Command ............................... 9 78 2.4.1. Usage .......................................... 9 79 2.4.2. Description .................................... 10 80 2.4.3. Examples ....................................... 13 81 3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16 82 3.1. Commands ............................................ 16 83 3.2. Command Continuation ................................ 17 84 3.3. Responses ........................................... 17 85 3.4. Capability entries .................................. 17 86 3.5. General non-terminals ............................... 17 87 4. Summary of Response Codes ................................ 17 88 5. Authentication Tracking/Logging .......................... 18 89 6. Security Considerations .................................. 19 90 7. IANA Considerations ...................................... 19 91 7.1. IANA Considerations for SASL/GSSAPI services ........ 19 92 7.2. IANA Considerations for NNTP extensions ............. 20 93 8. References ............................................... 21 94 8.1. Normative References ................................ 21 95 8.2. Informative References .............................. 22 96 9. Authors' Addresses ....................................... 22 97 10. Acknowledgments ......................................... 23 98 11. Intellectual Property Rights ............................ 23 99 12. Copyright ............................................... 23 101 1. Introduction 103 Although NNTP [NNTP] has traditionally been used to provide public 104 access to newsgroups, authentication is often useful, for example 105 to control resource consumption, to allow abusers of the POST 106 command to be identified, and to restrict access to "local" 107 newsgroups. 109 The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in 110 [NNTP-COMMON], provide a very weak authentication mechanism in 111 widespread use by the installed base. Due to their ubiquity they 112 are formalized in this specification but, because of their 113 insecurity, only for use in combination with appropriate security 114 layers. 116 The ad-hoc AUTHINFO GENERIC command, also documented in 117 [NNTP-COMMON] but much less ubiquitous, provided an NNTP-specific 118 equivalent of the generic SASL [SASL] facility. This document 119 deprecates AUTHINFO GENERIC in favor of an AUTHINFO SASL 120 replacement so that NNTP can benefit from authentication mechanisms 121 developed for other SASL-enabled application protocols including 122 SMTP, POP, IMAP, LDAP, and BEEP. 124 This specification is to be read in conjunction with the NNTP base 125 specification [NNTP]. Except where specifically stated otherwise, 126 in the case of a conflict between these two documents [NNTP] takes 127 precedence over this one. 129 It is also recommended that this specification be read in 130 conjunction with the SASL base specification [SASL]. 132 1.1. Conventions Used in this Document 134 The notational conventions used in this document are the same as 135 those in [NNTP] and any term not defined in this document has the 136 same meaning as in that one. 138 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 139 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 140 as described in "Key words for use in RFCs to Indicate Requirement 141 Levels" [KEYWORDS]. 143 Terms related to authentication are defined in "On Internet 144 Authentication" [AUTH]. 146 In the examples, commands from the client are indicated with [C], 147 and responses from the server are indicated with [S]. 149 2. The AUTHINFO Extension 151 The AUTHINFO extension is used to authenticate a user. Note that 152 authorization is a matter of site policy, not network protocol, and 153 is therefore not discussed in this document. The server determines 154 authorization in whatever manner is defined by its implementation 155 as configured by the site administrator. 157 This extension provides three new commands: AUTHINFO USER, AUTHINFO 158 PASS, and AUTHINFO SASL. The capability label for this extension 159 is AUTHINFO. 161 2.1. Advertising the AUTHINFO Extension 163 A server MUST implement at least one of the AUTHINFO USER or 164 AUTHINFO SASL commands in order to advertise the AUTHINFO 165 capability in the response to the CAPABILITIES command. However, 166 this capability MUST NOT be advertised after successful 167 authentication (see section 2.2). This capability MAY be 168 advertised both before and after any use of MODE READER, with the 169 same semantics. 171 The AUTHINFO capability label contains an argument list detailing 172 which authentication commands are available. 174 The "USER" argument indicates that AUTHINFO USER/PASS is supported 175 as defined by Section 2.3 of this document. The "USER" argument 176 MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD 177 NOT be provided, unless a strong encryption layer (e.g. TLS 178 [NNTP-TLS]) is in use or backward compatibility dictates otherwise. 180 The "SASL" argument indicates that AUTHINFO SASL is supported as 181 defined by Section 2.4 of this document. If the server advertises 182 the "SASL" argument, then it MUST also advertise the "SASL" 183 capability in response to the CAPABILITIES command. The SASL 184 capability is followed by a whitespace-separated list of available 185 SASL mechanism names. 187 The server MAY list the AUTHINFO capability with no arguments, 188 which indicates that it complies with this specification and does 189 not permit any authentication commands in its current state. In 190 this case, the client MUST NOT attempt to utilize any AUTHINFO 191 commands, even if it contains logic to do so (e.g. for backward 192 compatibility with servers that are not compliant with this 193 specification). 195 Future extensions may add additional arguments to this capability. 196 Unrecognized arguments MUST be ignored by the client. 198 As the AUTHINFO command is related to security, cached results of 199 CAPABILITIES from a previous session MUST NOT be relied on, as per 200 section 12.6 of [NNTP]. However, a client MAY use such cached 201 results in order to detect active down-negotiation attacks. 203 Example (here, the STARTTLS extension [NNTP-TLS] is also in use): 205 [C] CAPABILITIES 206 [S] 101 Capability list: 207 [S] VERSION 2 208 [S] READER 209 [S] IHAVE 210 [S] STARTTLS 211 [S] AUTHINFO SASL 212 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI 213 [S] LIST ACTIVE NEWSGROUPS 214 [S] . 215 [C] STARTTLS 216 [S] 382 Continue with TLS negotiation 217 [TLS negotiation proceeds, further commands protected by TLS] 218 [C] CAPABILITIES 219 [S] 101 Capability list: 220 [S] VERSION 2 221 [S] READER 222 [S] IHAVE 223 [S] AUTHINFO USER SASL 224 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL 225 [S] LIST ACTIVE NEWSGROUPS 226 [S] . 228 2.2. Authenticating with the AUTHINFO Extension 230 An NNTP server responds to a client command with a 480 response to 231 indicate that the client MUST authenticate and/or authorize in 232 order to use that command or access the indicated resource. Use of 233 the AUTHINFO command as described below is one such way that a 234 client can authenticate/authorize to the server. The client MAY 235 therefore use an AUTHINFO command after receiving a 480 response. 236 A client intending to use an AUTHINFO command SHOULD issue the 237 CAPABILITIES command to obtain the available authentication 238 commands and mechanisms before attempting authentication. 240 If a server advertises the AUTHINFO capability, a client MAY 241 attempt the first step of authentication at any time during a 242 session to acquire additional privileges without having received a 243 480 response. Servers SHOULD accept such unsolicited 244 authentication requests. A server MUST NOT under any circumstances 245 reply to an AUTHINFO command with a 480 response. 247 A client MUST NOT under any circumstances continue with any steps 248 of authentication beyond the first, unless the response code from 249 the server indicates that the authentication exchange is welcomed. 250 In particular, anything other than a 38x response code indicates 251 that the client MUST NOT continue the authentication exchange. 253 After a successful authentication, the client MUST NOT issue 254 another AUTHINFO command in the same session. A server MUST NOT 255 return the AUTHINFO capability in response to a CAPABILITIES 256 command and a server MUST reject any subsequent AUTHINFO commands 257 with a 502 response. Additionally, the client MUST NOT issue a 258 MODE READER command after authentication and a server MUST NOT 259 advertise the MODE-READER capability. 261 In agreement with [SASL], the server MUST continue to advertise the 262 SASL capability in response to a CAPABILITIES command with the same 263 list of SASL mechanisms as before authentication (thereby enabling 264 the client to detect a possible active down-negotiation attack). 265 Other capabilities returned in response to a CAPABILITIES command 266 received after authentication MAY be different than those returned 267 before authentication. For example, an NNTP server may not want to 268 advertise support for a specific extension unless a client has been 269 authenticated. 271 It should be noted that a server may perform a successful 272 authentication exchange with a client and yet still deny access to 273 some or all resources; the permanent 502 response indicates a 274 resource is unavailable even though authentication has been 275 performed (this is in contrast to the temporary 480 error 276 indicating that a resource is unavailable now but may become 277 available after authentication). 279 2.3. AUTHINFO USER/PASS Command 281 This section supersedes the definition of the AUTHINFO USER and 282 AUTHINFO PASS commands as documented in Section 3.1.1 of 283 [NNTP-COMMON]. 285 2.3.1. Usage 287 These commands MUST NOT be pipelined. 289 Syntax 290 AUTHINFO USER username 291 AUTHINFO PASS password 293 Responses 294 281 Authentication accepted 295 381 Password required [1] 296 481 Authentication failed/rejected 297 482 Authentication commands issued out of sequence 298 502 Command unavailable [2] 300 [1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx 301 codes which indicate that the client may continue the current 302 command, the legacy 381 code means that the AUTHINFO PASS command 303 must be used to complete the authentication exchange. 305 [2] If authentication has already occurred, AUTHINFO USER/PASS are 306 not valid commands (see section 2.2). 308 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 309 return 480 in response to AUTHINFO USER/PASS. 311 Parameters 312 username = string identifying the user/client 313 password = string representing the user's password 315 2.3.2. Description 317 The AUTHINFO USER and AUTHINFO PASS commands are used to present 318 clear text credentials to the server. These credentials consist of 319 a username or a username plus a password (the distinction is that a 320 password is expected to be kept secret while a username is not; 321 this does not directly affect the protocol but may have an impact 322 on user interfaces). The username is supplied through the AUTHINFO 323 USER command, and the password through the AUTHINFO PASS command. 325 If the server requires only a username, it MUST NOT give a 381 326 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO 327 PASS. 329 If the server requires both username and password, the former MUST 330 be sent before the latter. The server will need to cache the 331 username until the password is received; it MAY require the 332 password to be sent in the immediately next command (in other 333 words, only caching the username until the next command is sent). 334 The server: 336 - MUST return a 381 response to AUTHINFO USER; 337 - MUST return a 482 response to AUTHINFO PASS if there is no 338 cached username; 340 - MUST use the argument of the most recent AUTHINFO USER for 341 authentication; 342 - MUST NOT return a 381 response to AUTHINFO PASS. 344 The server MAY determine whether or not a password is needed based 345 on the username. Thus the same server can respond with both 381 346 and other response codes to AUTHINFO USER. 348 Should the client successfully present proper credentials, the 349 server issues a 281 reply. If the server is unable to authenticate 350 the client, it MUST reject the AUTHINFO USER/PASS command with a 351 481 reply. If an AUTHINFO USER/PASS command fails, the client MAY 352 proceed without authentication. Alternatively, the client MAY try 353 another authentication mechanism, or present different credentials 354 by issuing another AUTHINFO command. 356 The AUTHINFO PASS command permits the client to use a clear-text 357 password to authenticate. A compliant implementation MUST NOT 358 implement this command without also implementing support for TLS 359 [NNTP-TLS]. Use of this command without an active strong 360 encryption layer is deprecated, as it exposes the user's password 361 to all parties on the network between the client and the server. 362 Any implementation of this command SHOULD be configurable to 363 disable it whenever a strong encryption layer such as that provided 364 by [NNTP-TLS] is not active, and this configuration SHOULD be the 365 default. The server will use the 483 response code to indicate 366 that the datastream is insufficiently secure for the command being 367 attempted (see section 3.2.1 of [NNTP]). 369 Note that a server MAY, but is not required to, allow white space 370 characters in usernames and passwords. A server implementation MAY 371 blindly split command arguments at white space and therefore not 372 preserve the exact sequence of white space characters in the 373 username or password. Therefore a client SHOULD scan the username 374 and password for whitespace, and if detected, warn the user of the 375 likelihood of problems. The SASL PLAIN [PLAIN] mechanism is 376 recommended as an alternative, as it does not suffer from these 377 issues. 379 Also note that historically the username is not canonicalized in 380 any way. Servers MAY use the [SASLprep] profile of the 381 [StringPrep] algorithm to prepare usernames for comparison, but 382 doing so may cause interoperability problems with legacy 383 implementations. If canonicalization is desired, the SASL PLAIN 384 [PLAIN] mechanism is recommended as an alternative. 386 2.3.3. Examples 388 Example of successful AUTHINFO USER: 390 [C] AUTHINFO USER wilma 391 [S] 281 Authentication accepted 393 Example of successful AUTHINFO USER/PASS: 395 [C] AUTHINFO USER fred 396 [S] 381 Enter passphrase 397 [C] AUTHINFO PASS flintstone 398 [S] 281 Authentication accepted 400 Example of AUTHINFO USER/PASS requiring a security layer: 402 [C] AUTHINFO USER fred@stonecanyon.example 403 [S] 483 Encryption or stronger authentication required 405 Example of failed AUTHINFO USER/PASS: 407 [C] AUTHINFO USER barney 408 [S] 381 Enter passphrase 409 [C] AUTHINFO PASS flintstone 410 [S] 481 Authentication failed 412 Example of AUTHINFO PASS before AUTHINFO USER: 414 [C] AUTHINFO PASS flintstone 415 [S] 482 Authentication commands issued out of sequence 417 2.4. AUTHINFO SASL Command 419 This section defines a formal profile of the Simple Authentication 420 and Security Layer [SASL]. The use of the AUTHINFO GENERIC command 421 as documented in Section 3.1.3 of [NNTP-COMMON] as a way to perform 422 SASL authentication is deprecated in favor of the AUTHINFO SASL 423 command. A server SHOULD NOT advertise AUTHINFO GENERIC in the 424 list of capabilities returned by CAPABILITIES. 426 2.4.1. Usage 428 This command MUST NOT be pipelined. 430 Syntax 431 AUTHINFO SASL mechanism [initial-response] 433 This command MAY exceed 512 octets. The maximum length of this 434 command is increased to that which can accommodate the largest 435 encoded initial response possible for any of the SASL mechanisms 436 supported by the implementation. 438 Responses 439 281 Authentication accepted 440 283 challenge Authentication accepted (with success data) [1] 441 383 challenge Continue with SASL exchange [1] 442 481 Authentication failed/rejected 443 482 SASL protocol error 444 502 Command unavailable [2] 446 [1] These responses MAY exceed 512 octets. The maximum length of 447 these responses is increased to that which can accommodate the 448 largest encoded challenge possible for any of the SASL mechanisms 449 supported by the implementation. 451 [2] If authentication has already occurred, AUTHINFO SASL is not a 452 valid command (see section 2.2). 454 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 455 return 480 in response to AUTHINFO SASL. 457 Parameters 458 mechanism = String identifying a [SASL] authentication 459 mechanism. 460 initial-response = Optional initial client response. 461 If present, the response MUST be encoded as 462 specified in Section 3 of [BASE64]. [3] 463 challenge = Server challenge. 464 The challenge MUST be encoded as specified 465 in Section 3 of [BASE64]. 467 [3] This argument MAY exceed 497 octets. The maximum length of 468 this argument is increased to that which can accommodate the 469 largest encoded initial response possible for any of the SASL 470 mechanisms supported by the implementation. 472 2.4.2. Description 474 The AUTHINFO SASL command initiates a [SASL] authentication 475 exchange between the client and the server. The client identifies 476 the SASL mechanism to use with the first parameter of the AUTHINFO 477 SASL command. If the server supports the requested authentication 478 mechanism, it performs the SASL exchange to authenticate the user. 479 Optionally, it also negotiates a security layer for subsequent 480 protocol interactions during this session. If the requested 481 authentication mechanism is invalid (e.g. is not supported), the 482 server rejects the AUTHINFO SASL command with a 503 reply (see 483 section 3.2.1 of [NNTP]). If the requested authentication 484 mechanism requires an encryption layer, the server rejects the 485 AUTHINFO SASL command with a 483 reply (see section 3.2.1 of 486 [NNTP]). 488 The service name specified by this protocol's profile of SASL is 489 "nntp". 491 The SASL authentication exchange consists of a series of server 492 challenges and client responses that are specific to the chosen 493 [SASL] mechanism. 495 A server challenge is sent as a 383 reply with a single argument 496 containing the [BASE64] encoded string supplied by the SASL 497 mechanism. A server challenge that has zero length MUST be sent as 498 a single equals sign ("=") and not omitted (in order to comply with 499 the [NNTP] requirement that responses always have the same number 500 of arguments). 502 A client response consists of a line containing a [BASE64] encoded 503 string. A client response that has zero length MUST be sent as a 504 single equals sign ("=") and not omitted (for consistency with the 505 server challenge format). If the client wishes to cancel the 506 authentication exchange, it issues a line with a single "*". If 507 the server receives such a response, it MUST reject the AUTHINFO 508 SASL command by sending a 481 reply. 510 Note that these [BASE64] strings can be much longer than normal 511 NNTP responses. Clients and servers MUST be able to handle the 512 maximum encoded size of challenges and responses generated by their 513 supported authentication mechanisms. This requirement is 514 independent of any line length limitations the client or server may 515 have in other parts of its protocol implementation. 517 The optional initial response argument to the AUTHINFO SASL command 518 is used to save a round trip when using authentication mechanisms 519 that support an initial client response. If the initial response 520 argument is omitted and the chosen mechanism requires an initial 521 client response, the server MUST proceed as defined in section 5.1 522 of [SASL]. In NNTP, a server challenge that contains no data is 523 equivalent to a zero length challenge and is encoded as a single 524 equals sign ("="). 526 Note that the [BASE64] encoded initial response argument can exceed 527 497 octets and therefore the AUTHINFO SASL command can exceed 512 528 octets. Clients SHOULD, and servers MUST be able to handle the 529 maximum encoded size of initial responses possible for their 530 supported authentication mechanisms. This requirement is 531 independent of any command or argument length limitations the 532 client or server may have in other parts of its protocol 533 implementation. 535 If use of the initial response argument would cause the AUTHINFO 536 SASL command to exceed 512 octets, the client MAY choose to omit 537 the initial response parameter (and instead proceed as defined in 538 section 5.1 of [SASL]). 540 If the client is transmitting an initial response of zero length, 541 it MUST instead transmit the response as a single equals sign 542 ("="). This indicates that the response is present, but contains 543 no data. 545 If the client uses an initial-response argument to the AUTHINFO 546 SASL command with a SASL mechanism that does not support an initial 547 client response, the server MUST reject the AUTHINFO SASL command 548 with a 482 reply. 550 If the server cannot [BASE64] decode any client response, it MUST 551 reject the AUTHINFO SASL command with a 504 reply (see section 552 3.2.1 of [NNTP]). If the client cannot BASE64 decode any of the 553 server's challenges, it MUST cancel the authentication using the 554 "*" response. In particular, servers and clients MUST reject (and 555 not ignore) any character not explicitly allowed by the BASE64 556 alphabet, and MUST reject any sequence of BASE64 characters that 557 contains the pad character ('=') anywhere other than the end of the 558 string (e.g. "=AAA" and "AAA=BBB" are not allowed). 560 The authorization identity generated by this [SASL] exchange is a 561 simple username, and both client and server MUST use the [SASLprep] 562 profile of the [StringPrep] algorithm to prepare these names for 563 transmission or comparison. If preparation of the authorization 564 identity fails or results in an empty string (unless it was 565 transmitted as the empty string), the server MUST fail the 566 authentication with a 481 reply. 568 Should the client successfully complete the exchange, the server 569 issues either a 281 or 283 reply. If the server is unable to 570 authenticate the client, it MUST reject the AUTHINFO SASL command 571 with a 481 reply. If an AUTHINFO SASL command fails, the client 572 MAY proceed without authentication. Alternatively, the client MAY 573 try another authentication mechanism, or present different 574 credentials by issuing another AUTHINFO command. 576 If the SASL mechanism returns additional data on success (e.g. 578 server authentication), the NNTP server issues a 283 reply with a 579 single argument containing the [BASE64] encoded string supplied by 580 the SASL mechanism. If no additional data is returned on success, 581 the server issues a 281 reply. 583 If a security layer is negotiated during the SASL exchange, it 584 takes effect for the client on the octet immediately following the 585 CRLF that concludes the last response generated by the client. For 586 the server, it takes effect immediately following the CRLF of its 587 success reply. 589 When a security layer takes effect, the NNTP protocol is reset to 590 the state immediately after the initial greeting response (see 5.1 591 of [NNTP]) has been sent, with the exception that if a MODE READER 592 command has been issued, the effects of it (if any) are not 593 reversed. The server MUST discard any knowledge obtained from the 594 client, such as the current newsgroup and article number, that was 595 not obtained from the SASL negotiation itself. Likewise, the 596 client SHOULD discard and MUST NOT rely on any knowledge obtained 597 from the server, such as the capability list, that was not obtained 598 from the SASL negotiation itself. (Note that a client MAY compare 599 the advertised SASL mechanisms before and after authentication in 600 order to detect an active down-negotiation attack.) 602 When both TLS [NNTP-TLS] and SASL security layers are in effect, 603 the TLS encoding MUST be applied after the SASL encoding (the 604 cleartext data is always SASL encoded first and then the resultant 605 data is TLS encoded). 607 To ensure interoperability, client and server implementations of 608 this extension MUST implement the [DIGEST-MD5] SASL mechanism. 610 If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the 611 SASL [PLAIN] mechanism SHOULD also be implemented, as the 612 functionality of DIGEST-MD5 is insufficient for some environments 613 (e.g. the server may need to pass the plaintext password off to an 614 external authentication service). The SASL PLAIN mechanism is 615 preferred over AUTHINFO USER, even if there is not a strong 616 encryption layer active, because it eliminates limitations that 617 AUTHINFO USER/PASS has with regards to white space characters being 618 used in usernames and passwords. 620 2.4.3. Examples 622 Example of the [PLAIN] SASL mechanism under a TLS layer, using an 623 initial client response: 625 [C] CAPABILITIES 626 [S] 101 Capability list: 627 [S] VERSION 2 628 [S] READER 629 [S] STARTTLS 630 [S] AUTHINFO SASL 631 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI 632 [S] LIST ACTIVE NEWSGROUPS 633 [S] . 634 [C] STARTTLS 635 [S] 382 Continue with TLS negotiation 636 [TLS negotiation proceeds, further commands protected by TLS] 637 [C] CAPABILITIES 638 [S] 101 Capability list: 639 [S] VERSION 2 640 [S] READER 641 [S] AUTHINFO USER SASL 642 [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL 643 [S] LIST ACTIVE NEWSGROUPS 644 [S] . 645 [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA== 646 [S] 281 Authentication accepted 648 Example of the EXTERNAL SASL mechanism under a TLS layer, using the 649 authorization identity derived from the client TLS certificate, and 650 thus a zero-length initial client response (commands prior to 651 AUTHINFO SASL are the same as the previous example and have been 652 omitted): 654 [C] AUTHINFO SASL EXTERNAL = 655 [S] 281 Authentication accepted 657 Example of the [DIGEST-MD5] SASL mechanism, which includes a server 658 challenge and server success data (whitespace has been inserted for 659 clarity; base64-encoded data is actually sent as a single line with 660 no embedded whitespace): 662 [C] AUTHINFO SASL DIGEST-MD5 663 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 664 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo 665 LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj 666 NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 667 aG09bWQ1LXNlc3M= 668 [C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j 669 ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp 670 UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J 671 aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy 672 PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs 673 cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= 674 [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ== 676 Example of a failed authentication due to bad [GSSAPI] credentials. 677 Note that while the mechanism can utilize the initial response, the 678 client chooses not to use it because of its length, resulting in a 679 zero-length server challenge (here whitespace has been inserted for 680 clarity; base64-encoded data is actually sent as a single line with 681 no embedded whitespace): 683 [C] AUTHINFO SASL GSSAPI 684 [S] 383 = 685 [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj 686 ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw 687 IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB 688 EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 689 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP 690 ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 691 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ 692 djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6 693 Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj 694 RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL 695 kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0 696 0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF 697 iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw= 698 [S] 481 Authentication error 700 Example of a client aborting in the midst of an exchange: 702 [C] AUTHINFO SASL GSSAPI 703 [S] 383 = 704 [C] * 705 [S] 481 Authentication aborted as requested 707 Example of attempting to use a mechanism that is not supported by 708 the server: 710 [C] AUTHINFO SASL EXAMPLE 711 [S] 503 Mechanism not recognized 713 Example of attempting to use a mechanism that requires a security 714 layer: 716 [C] AUTHINFO SASL PLAIN 717 [S] 483 Encryption or stronger authentication required 719 Example of using an initial response with a mechanism that doesn't 720 support it (server must start the exchange): 722 [C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== 723 [S] 482 SASL protocol error 725 Example of a failed authentication due to an incorrectly encoded 726 response: 728 [C] AUTHINFO SASL CRAM-MD5 729 [S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+ 730 [C] abcd=efg 731 [S] 504 Base64 encoding error 733 3. Augmented BNF Syntax for the AUTHINFO Extension 735 This section describes the formal syntax of the AUTHINFO extension 736 using ABNF [ABNF]. It extends the syntax in section 9 of [NNTP], 737 and non-terminals not defined in this document are defined there. 738 The [NNTP] ABNF should be imported first before attempting to 739 validate these rules. 741 3.1. Commands 743 This syntax extends the non-terminal "command", which represents an 744 NNTP command. 746 command =/ authinfo-sasl-command / 747 authinfo-user-command / 748 authinfo-pass-command 750 authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism 751 [WS initial-response] 752 authinfo-user-command = "AUTHINFO" WS "USER" WS username 753 authinfo-pass-command = "AUTHINFO" WS "PASS" WS password 755 initial-response = base64-opt 756 username = 1*user-pass-char 757 password = 1*user-pass-char 758 user-pass-char = B-CHAR 760 NOTE: A server implementation MAY parse AUTHINFO USER and AUTHINFO 761 PASS specially as to allow white space to be used within the 762 username or password. Such implementations accept the additional 763 syntax (making these two items inconsistent with "token" in section 764 9.8 of [NNTP]): 766 user-pass-char =/ SP / TAB 767 In doing so, the grammar can become ambiguous if the username or 768 password begins or ends with white space. To solve this ambiguity, 769 such implementations typically treat everything after the first 770 white space character following "USER"/"PASS", up to, but not 771 including, the CRLF as the username/password. 773 3.2. Command Continuation 775 This syntax extends the non-terminal "command-continuation", which 776 represents the further material sent by the client in the case of 777 multi-stage commands. 779 command-continuation =/ authinfo-sasl-383-continuation 781 authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF 783 3.3. Responses 785 This syntax extends the non-terminal "initial-response-content", 786 which represents an initial response line sent by the server. 788 initial-response-content =/ response-283-content / 789 response-383-content 791 response-283-content = "283" SP base64 792 response-383-content = "383" SP base64-opt 794 3.4. Capability entries 796 This syntax extends the non-terminal "capability-entry", which rep- 797 resents a capability that may be advertised by the server. 799 capability-entry =/ authinfo-capability / 800 sasl-capability 802 authinfo-capability = "AUTHINFO" *(WS authinfo-variant) 803 authinfo-variant = "USER" / "SASL" 804 sasl-capability = "SASL" 1*(WS mechanism) 806 3.5. General non-terminals 808 base64-opt = "=" / base64 809 mechanism = 1*20mech-char 810 mech-char = UPPER / DIGIT / "-" / "_" 812 4. Summary of Response Codes 813 This section contains a list of every new response code defined in 814 this document, whether it is multi-line, which commands can 815 generate it, what arguments it has, and what its meaning is. 817 Response code 281 818 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 819 Meaning: authentication accepted 821 Response code 283 822 Generated by: AUTHINFO SASL 823 1 argument: challenge 824 Meaning: authentication accepted (with success data) 826 Response code 381 827 Generated by: AUTHINFO USER 828 Meaning: password required via AUTHINFO PASS command. Note 829 that this code is used for backwards compatibility and does 830 not conform to the traditional use of 3xx codes. 832 Response code 383 833 Generated by: AUTHINFO SASL 834 1 argument: challenge 835 Meaning: continue with SASL exchange 837 Response code 481 838 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 839 Meaning: authentication failed/rejected 841 Response code 482 842 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL 843 Meaning: authentication commands issued out of sequence or 844 SASL protocol error 846 5. Authentication Tracking/Logging 848 This section contains implementation suggestions and notes of best 849 current practice, and does not specify further network protocol 850 requirements. 852 Once authenticated, the authorization identity presented in the 853 AUTHINFO exchange (username when using USER/PASS) SHOULD be 854 included in an audit trail associating the identity with any 855 articles supplied during a POST operation, and this configuration 856 SHOULD be the default. This may be accomplished, for example, by 857 inserting headers in the posted articles or by a server logging 858 mechanism. The server MAY provide a facility for disabling the 859 procedure described above, as some users or administrators may 860 consider it a violation of privacy. 862 6. Security Considerations 864 Security issues are discussed throughout this memo. 866 In general, the security considerations of [SASL] and any 867 implemented SASL mechanisms are applicable here; only the most 868 important are highlighted specifically below. Also, this extension 869 is not intended to cure the security considerations described in 870 section 12 of [NNTP]; those considerations remain relevant to any 871 NNTP implementation. 873 Before the [SASL] negotiation has begun, any protocol interactions 874 may have been performed in the clear and may have been modified by 875 an active attacker. For this reason, clients and servers MUST 876 discard any sensitive knowledge obtained prior to the start of the 877 SASL negotiation upon the establishment of a security layer. 878 Furthermore, the CAPABILITIES command SHOULD be re-issued upon the 879 establishment of a security layer, and other protocol state SHOULD 880 be re-negotiated as well. 882 Servers MAY implement a policy whereby the connection is dropped 883 after a number of failed authentication attempts. If they do so, 884 they SHOULD NOT drop the connection until at least 3 attempts at 885 authentication have failed. 887 Implementations MUST support a configuration where authentication 888 mechanisms that are vulnerable to passive eavesdropping attacks 889 (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or 890 used without the presence of an external security layer such as TLS 891 [NNTP-TLS]. 893 When multiple authentication mechanisms are permitted by both 894 client and server, an active attacker can cause a down-negotiation 895 to the weakest mechanism. For this reason, both clients and 896 servers SHOULD be configurable to forbid use of weak mechanisms. 897 The minimum strength acceptable is a policy decision which is 898 outside the scope of this specification. 900 7. IANA Considerations 902 7.1. IANA Considerations for SASL/GSSAPI services 904 Please register the SASL/GSSAPI service name "nntp". This service 905 name refers to authenticated use of Usenet news service when 906 provided via the [NNTP] protocol. 908 o Published Specification: This document. 910 o Contact for Further Information: Authors of this document. 912 o Change Controller: IESG . 914 7.2. IANA Considerations for NNTP extensions 916 This section gives a formal definition of the AUTHINFO extension as 917 required by Section 3.3.3 of [NNTP] for the IANA registry. 919 o This extension provides an extensible mechanism for NNTP 920 authentication via a variety of methods. 922 o The capability label for this extension is "AUTHINFO". 924 o The "AUTHINFO" capability label has two possible optional 925 arguments "USER" and "SASL" (as defined in Section 2.1) 926 indicating which variants of the AUTHINFO command are supported. 928 o This extension also provides the "SASL" capability label whose 929 arguments list the available SASL mechanisms. 931 o This extension defines three new commands, AUTHINFO USER, 932 AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and 933 responses are defined in Sections 2.3 and 2.4. 935 o This extension does not associate any new responses with pre- 936 existing NNTP commands. 938 o This extension may affect the overall behavior of both server 939 and client, in that the AUTHINFO SASL command may require that 940 subsequent communication be transmitted via an intermediary 941 security layer. 943 o The length of the AUTHINFO SASL command (as defined in this 944 document) may exceed 512 octets. The maximum length of this 945 command is increased to that which can accommodate the largest 946 initial response possible for any of the SASL mechanisms 947 supported by the implementation. 949 o This extension defines two new responses, 283 and 383, whose 950 lengths may exceed 512 octets. The maximum length of these 951 responses is increased to that which can accommodate the largest 952 challenge possible for any of the SASL mechanisms supported by 953 the implementation. 955 o This extension does not alter pipelining, but AUTHINFO commands 956 cannot be pipelined. 958 o Use of this extension may alter the capabilities list; once the 959 AUTHINFO command has been used successfully, the AUTHINFO 960 capability can no longer be advertised by CAPABILITIES. 961 Additionally, the MODE-READER capability MUST NOT be advertised 962 after successful authentication. 964 o This extension does not cause any pre-existing command to 965 produce a 401, 480, or 483 response. 967 o This extension is unaffected by any use of the MODE READER 968 command, however the MODE READER command MUST NOT be used in the 969 same session following successful authentication. 971 o Published Specification: This document. 973 o Author, Change Controller, and Contact for Further Information: 974 Author of this document. 976 8. References 978 8.1. Normative References 980 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 981 Specifications: ABNF", RFC 2234, November 1997. 983 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", 984 RFC 1704, October 1994. 986 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 987 Encodings", RFC 3548, July 2003. 989 [DIGEST-MD5] Leach, P., Newman, C., Melnikov, A., 990 "Using Digest Authentication as a SASL Mechanism", 991 draft-ietf-sasl-rfc2831bis-*, Work in Progress. 993 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, March 1997. 996 [NNTP] Feather, C., "Network News Transport Protocol", 997 draft-ietf-nntpext-base-*, Work in Progress. 999 [NNTP-TLS] Murchison, K., Vinocur, J., Newman, C., 1000 "Using TLS with NNTP", draft-ietf-nntpext-tls-nntp-*, 1001 Work in Progress. 1003 [SASL] Melnikov, A. and Zeilenga, K., "Simple Authentication and 1004 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-*, 1005 Work in Progress. 1007 [SASLprep] Zeilega, K., "SASLprep: Stringprep Profile for 1008 User Names and Passwords", RFC 4013, February 2005. 1010 [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of 1011 Internationalized Strings ("stringprep")", 1012 RFC 3454, December 2002. 1014 8.2. Informative References 1016 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", draft- 1017 ietf-sasl-crammd5-*, Work in Progress. 1019 [GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", draft-ietf-sasl- 1020 gssapi-*, Work in Progress. 1022 [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, 1023 October 2000. 1025 [PLAIN] Zeilenga, K., "The PLAIN SASL Mechanism", draft-ietf-sasl- 1026 plain-*, Work in Progress. 1028 [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, 1029 April 2001. 1031 9. Authors' Addresses 1033 Jeffrey M. Vinocur 1034 Department of Computer Science 1035 Upson Hall 1036 Cornell University 1037 Ithaca, NY 14853 USA 1039 Email: vinocur@cs.cornell.edu 1041 Kenneth Murchison 1042 Oceana Matrix Ltd. 1043 2495 Main St, Suite 401 1044 Buffalo, NY 14214 USA 1046 Email: ken@oceana.com 1048 Chris Newman 1049 Sun Microsystems 1050 1050 Lakes Drive, Suite 250 1051 West Covina, CA 91790 USA 1052 Email: Chris.Newman@sun.com 1054 10. Acknowledgments 1056 A significant amount of the authentication text was originally from 1057 the NNTP revision or common authentication specs written by Stan 1058 Barber. A significant amount of the SASL text was lifted from the 1059 revisions to RFC 1734 and RFC 2554 by Rob Siemborski. 1061 Special acknowledgment also goes to Russ Allbery, Clive Feather, 1062 and others who commented privately on intermediate revisions of 1063 this document, as well as the members of the IETF NNTP Working 1064 Group for continual (yet sporadic) insight in discussion. 1066 11. Intellectual Property Rights 1068 The IETF takes no position regarding the validity or scope of any 1069 Intellectual Property Rights or other rights that might be claimed 1070 to pertain to the implementation or use of the technology described 1071 in this document or the extent to which any license under such 1072 rights might or might not be available; nor does it represent that 1073 it has made any independent effort to identify any such rights. 1074 Information on the procedures with respect to rights in RFC 1075 documents can be found in BCP 78 and BCP 79. 1077 Copies of IPR disclosures made to the IETF Secretariat and any 1078 assurances of licenses to be made available, or the result of an 1079 attempt made to obtain a general license or permission for the use 1080 of such proprietary rights by implementers or users of this 1081 specification can be obtained from the IETF on-line IPR repository 1082 at http://www.ietf.org/ipr. 1084 The IETF invites any interested party to bring to its attention any 1085 copyrights, patents or patent applications, or other proprietary 1086 rights that may cover technology that may be required to implement 1087 this standard. Please address the information to the IETF at 1088 ietf-ipr@ietf.org. 1090 12. Copyright 1092 Copyright (C) The Internet Society (2005). 1094 This document is subject to the rights, licenses and restrictions 1095 contained in BCP 78, and except as set forth therein, the authors 1096 retain all their rights. 1098 This document and the information contained herein are provided on 1099 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1100 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1101 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1102 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1103 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1104 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1105 PARTICULAR PURPOSE.