idnits 2.17.1 draft-ietf-nntpext-tls-nntp-07.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 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 616. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([NNTP-AUTH], [NNTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6887 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 345, but not defined == Missing Reference: 'S' is mentioned on line 346, but not defined -- Looks like a reference, but probably isn't: '1' on line 175 ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-ietf-nntpext-base- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NNTP' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. 'TLS-EXT') (Obsoleted by RFC 4366) -- No information found for draft-ietf-nntpext-auth- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NNTP Extensions Working Group K. Murchison 3 Internet Draft Oceana Matrix Ltd. 4 Expires: December 2005 J. Vinocur 5 Cornell University 6 C. Newman 7 Sun Microsystems 8 June 2005 10 Using TLS with NNTP 11 draft-ietf-nntpext-tls-nntp-07 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 memo defines an extension to the Network News Transport 44 Protocol (NNTP) to allow an NNTP client and server to use Transport 45 Layer Security (TLS). The primary goal is to provide encryption 46 for single-link confidentiality purposes, but data integrity, 47 (optional) certificate-based peer entity authentication, and 48 (optional) data compression are also possible. 50 Note to the RFC Editor 52 The normative references to RFC 2234, RFC 2246, and RFC 3546, and the 53 informative reference to RFC 2222 may 54 be replaced by draft-crocker-abnf-rfc2234bis, 55 draft-ietf-tls-rfc2246-bis draft-ietf-tls-rfc3526bis, and 56 draft-ietf-sasl-rfc2222bis 57 respectively should any or all of those documents reach RFC status 58 before this one. 60 The normative reference to [NNTP] and the informative reference to 61 [NNTP-AUTH] are documents which are expected to be published 62 simultaneously with this one and so can be replaced by references 63 to the resulting RFCs. 65 Table of Contents 67 1. Introduction ............................................. 2 68 1.1. Conventions Used in this Document ................... 3 69 2. The STARTTLS Extension ................................... 3 70 2.1. Advertising the STARTTLS Extension .................. 3 71 2.2. STARTTLS Command .................................... 4 72 2.2.1. Usage .......................................... 4 73 2.2.2. Description .................................... 4 74 2.2.3. Examples ....................................... 6 75 3. Augmented BNF Syntax for the STARTTLS Extension .......... 8 76 3.1. Commands ............................................ 8 77 3.2. Capability entries .................................. 8 78 4. Summary of Response Codes ................................ 8 79 5. Security Considerations .................................. 9 80 6. IANA Considerations ...................................... 11 81 7. References ............................................... 12 82 7.1. Normative References ................................ 12 83 7.2. Informative References .............................. 12 84 8. Authors' Addresses ....................................... 12 85 9. Acknowledgments .......................................... 13 86 10. Intellectual Property Rights ............................ 13 87 11. Copyright ............................................... 13 89 1. Introduction 91 Historically, unencrypted NNTP [NNTP] connections were satisfactory 92 for most purposes. However, sending passwords unencrypted over the 93 network is no longer appropriate, and sometimes integrity and/or 94 confidentiality protection is desired for the entire connection. 96 The TLS protocol (formerly known as SSL) provides a way to secure 97 an application protocol from tampering and eavesdropping. Although 98 advanced SASL authentication mechanisms [NNTP-AUTH] can provide a 99 lightweight version of this service, TLS is complimentary to both 100 simple authentication-only SASL mechanisms and deployed clear-text 101 password login commands. 103 In some existing implementations, TCP port 563 has been dedicated 104 to NNTP over TLS. These implementations begin the TLS negotiation 105 immediately upon connection, and then continue with the initial 106 steps of an NNTP session. This use of TLS on a separate port is 107 discouraged for the reasons documented in section 7 of "Using TLS 108 with IMAP, POP3 and ACAP" [TLS-IMAPPOP]. 110 This specification formalizes the STARTTLS command already in 111 occasional use by the installed base. The STARTTLS command 112 rectifies a number of the problems with using a separate port for a 113 "secure" protocol variant, and is the preferred way of using TLS 114 with NNTP. 116 1.1. Conventions Used in this Document 118 The notational conventions used in this document are the same as 119 those in [NNTP] and any term not defined in this document has the 120 same meaning as in that one. 122 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 123 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 124 as described in "Key words for use in RFCs to Indicate Requirement 125 Levels" [KEYWORDS]. 127 In the examples, commands from the client are indicated with [C], 128 and responses from the server are indicated with [S]. 130 2. The STARTTLS Extension 132 This extension provides a new STARTTLS command and has the 133 capability label STARTTLS. 135 2.1. Advertising the STARTTLS Extension 137 A server supporting the STARTTLS command as defined in this 138 document will advertise the "STARTTLS" capability label in response 139 to the CAPABILITIES command. However, this capability MUST NOT be 140 advertised once a TLS layer is active (see section 2.2.2.2), or 141 after successful authentication [NNTP-AUTH]. This capability MAY 142 be advertised both before and after any use of MODE READER, with 143 the same semantics. 145 As the STARTTLS command is related to security, cached results of 146 CAPABILITIES from a previous session MUST NOT be relied on, as per 147 section 12.6 of [NNTP]. 149 Example: 151 [C] CAPABILITIES 152 [S] 101 Capability list: 153 [S] VERSION 2 154 [S] READER 155 [S] IHAVE 156 [S] STARTTLS 157 [S] LIST ACTIVE NEWSGROUPS 158 [S] . 160 2.2. STARTTLS Command 162 2.2.1. Usage 164 This command MUST NOT be pipelined. 166 Syntax 167 STARTTLS 169 Responses 171 382 Continue with TLS negotiation 172 502 Command unavailable [1] 173 580 Can not initiate TLS negotiation 175 [1] If a TLS layer is already active, or authentication has 176 occurred, STARTTLS is not a valid command (see section 2.2.2.2). 178 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 179 return either 480 or 483 in response to STARTTLS. 181 2.2.2. Description 183 A client issues the STARTTLS command to request negotiation of TLS. 184 The STARTTLS command is usually used to initiate session security, 185 although it can also be used for client and/or server certificate 186 authentication and/or data compression. 188 An NNTP server returns the 483 response to indicate that a secure 189 or encrypted connection is required for the command sent by the 190 client. Use of the STARTTLS command as described below is one way 191 to establish a connection with these properties. The client MAY 192 therefore use the STARTTLS command after receiving a 483 response. 194 If a server advertises the STARTTLS capability, a client MAY 195 attempt to use the STARTTLS command at any time during a session to 196 negotiate TLS without having received a 483 response. Servers 197 SHOULD accept such unsolicited TLS negotiation requests. 199 If the server is unable to initiate the TLS negotiation for any 200 reason (e.g. a server configuration or resource problem), the 201 server MUST reject the STARTTLS command with a 580 response. 202 Otherwise, the server issues a 382 response and TLS negotiation 203 begins. A server MUST NOT under any circumstances reply to a 204 STARTTLS command with either a 480 or 483 response. 206 Upon receiving a 382 response to a STARTTLS command, the client 207 MUST start the TLS negotiation before giving any other NNTP 208 commands. The TLS negotiation begins for both the client and 209 server with the first octet following the CRLF of the 382 response. 210 If, after having issued the STARTTLS command, the client finds out 211 that some failure prevents it from actually starting a TLS 212 handshake, then it SHOULD immediately close the connection. 214 Servers MUST be able to understand backwards-compatible TLS Client 215 Hello messages (provided that client_version is TLS 1.0 or later), 216 and clients MAY use backwards-compatible Client Hello messages. 217 Neither clients nor servers are required to actually support Client 218 Hello messages for anything other than TLS 1.0. However, the TLS 219 extension for Server Name Indication ("server_name") [TLS-EXT] 220 SHOULD be implemented by all clients; it also SHOULD be implemented 221 by any server implementing STARTTLS that is known by multiple names 222 (otherwise it is not possible for a server with several hostnames 223 to present the correct certificate to the client). 225 The server remains in the non-authenticated state, even if client 226 credentials are supplied during the TLS negotiation. The AUTHINFO 227 SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be 228 used to authenticate once TLS client credentials are successfully 229 exchanged, but servers supporting the STARTTLS command are not 230 required to support AUTHINFO in general or that mechanism in 231 particular. The server MAY use information from the client 232 certificate for identification of connections or posted articles 233 (either in its logs or directly in posted articles). 235 If the client receives a failure response to STARTTLS or if the TLS 236 negotiation fails, the client must decide whether or not to 237 continue the NNTP session. Such a decision is based on local 238 policy. For instance, if TLS was being used for client 239 authentication, the client might try to continue the session in 240 case the server allows it to do so even with no authentication. 241 However, if TLS was being negotiated for encryption, a client that 242 gets a failure response needs to decide whether to continue without 243 TLS encryption, to wait and try again later, or to give up and 244 notify the user of the error. 246 If the server is unable to initiate the TLS negotiation or if the 247 TLS negotiation fails, the server SHOULD either reject subsequent 248 restricted NNTP commands from the client with a 483 response code 249 (possibly with a text string such as "Command refused due to lack 250 of security"), or reject a command with a 400 response code 251 (possibly with a text string such as "Connection closing due to 252 lack of security") and close the connection. 254 Upon successful completion of the TLS handshake, the NNTP protocol 255 is reset to the state immediately after the initial greeting 256 response (see 5.1 of [NNTP]) has been sent, with the exception that 257 if a MODE READER command has been issued, the effects of it (if 258 any) are not reversed. In this case, as no greeting is sent, the 259 next step is for the client to send a command. The server MUST 260 discard any knowledge obtained from the client, such as the current 261 newsgroup and article number, that was not obtained from the TLS 262 negotiation itself. Likewise, the client SHOULD discard and MUST 263 NOT rely on any knowledge obtained from the server, such as the 264 capability list, which was not obtained from the TLS negotiation 265 itself. 267 Both the client and the server MUST know if there is a TLS session 268 active. A client MUST NOT attempt to start a TLS session if a TLS 269 session is already active. A server MUST NOT return the STARTTLS 270 capability label in response to a CAPABILITIES command received 271 after a TLS handshake has completed, and a server MUST respond with 272 a 502 response code if a STARTTLS command is received while a TLS 273 session is already active. Additionally, the client MUST NOT issue 274 a MODE READER command while a TLS session is active and a server 275 MUST NOT advertise the MODE-READER capability. 277 The capability list returned in response to a CAPABILITIES command 278 received after a successful TLS handshake MAY be different than the 279 list returned before the TLS handshake. For example, an NNTP 280 server supporting SASL [NNTP-AUTH] might not want to advertise 281 support for a particular mechanism unless a client has sent an 282 appropriate client certificate during a TLS handshake. 284 2.2.3. Examples 286 Example of a client being prompted to use encryption and 287 negotiating it successfully (showing the removal of STARTTLS from 288 the capability list once a TLS layer is active), followed by a 289 successful selection of the group and an (inappropriate) attempt by 290 the client to initiate another TLS negotiation: 292 [C] CAPABILITIES 293 [S] 101 Capability list: 294 [S] VERSION 2 295 [S] READER 296 [S] STARTTLS 297 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 298 [S] OVER 299 [S] . 300 [C] GROUP local.confidential 301 [S] 483 Encryption or stronger authentication required 302 [C] STARTTLS 303 [S] 382 Continue with TLS negotiation 304 [TLS negotiation occurs here] 305 [Following successful negotiation, traffic is protected by TLS] 306 [C] CAPABILITIES 307 [S] 101 Capability list: 308 [S] VERSION 2 309 [S] READER 310 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 311 [S] OVER 312 [S] . 313 [C] GROUP local.confidential 314 [S] 211 1234 3000234 3002322 local.confidential 315 [C] STARTTLS 316 [S] 502 STARTTLS not allowed with active TLS layer 318 Example of a request to begin TLS negotiation declined by the 319 server: 321 [C] STARTTLS 322 [S] 580 Can not initiate TLS negotiation 324 Example of a failed attempt to negotiate TLS, followed by two 325 attempts at selecting groups only available under a security layer 326 (in the first case the server allows the session to continue, in 327 the second it closes the connection). Note that unrestricted 328 commands such as CAPABILITIES are unaffected by the failure: 330 [C] STARTTLS 331 [S] 382 Continue with TLS negotiation 332 [TLS negotiation is attempted here] 333 [Following failed negotiation, traffic resumes without TLS] 334 [C] CAPABILITIES 335 [S] 101 Capability list: 336 [S] VERSION 2 337 [S] READER 339 [S] STARTTLS 340 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 341 [S] OVER 342 [S] . 343 [C] GROUP local.confidential 344 [S] 483 Encryption or stronger authentication required 345 [C] GROUP local.private 346 [S] 400 Closing connection due to lack of security 348 3. Augmented BNF Syntax for the STARTTLS Extension 350 This section describes the formal syntax of the STARTTLS extension 351 using ABNF [ABNF]. It extends the syntax in section 9 of [NNTP], 352 and non-terminals not defined in this document are defined there. 353 The [NNTP] ABNF should be imported first before attempting to 354 validate these rules. 356 3.1. Commands 358 This syntax extends the non-terminal "command", which represents an 359 NNTP command. 361 command =/ starttls-command 363 starttls-command = "STARTTLS" 365 3.2. Capability entries 367 This syntax extends the non-terminal "capability-entry", which 368 represents a capability that may be advertised by the server. 370 capability-entry =/ starttls-capability 372 starttls-capability = "STARTTLS" 374 4. Summary of Response Codes 376 This section contains a list of every new response code defined in 377 this document, whether it is multi-line, which commands can 378 generate it, what arguments it has, and what its meaning is. 380 Response code 382 381 Generated by: STARTTLS 382 Meaning: continue with TLS negotiation 384 Response code 580 385 Generated by: STARTTLS 386 Meaning: can not initiate TLS negotiation 388 5. Security Considerations 390 Security issues are discussed throughout this memo. 392 In general, the security considerations of the TLS protocol [TLS] 393 and any implemented extensions [TLS-EXT] are applicable here; only 394 the most important are highlighted specifically below. Also, this 395 extension is not intended to cure the security considerations 396 described in section 12 of [NNTP]; those considerations remain 397 relevant to any NNTP implementation. 399 NNTP client and server implementations MUST implement the 400 TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement 401 the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is 402 important as it assures that any two compliant implementations can 403 be configured to interoperate. All other cipher suites are 404 OPTIONAL. 406 Before the TLS handshake has begun, any protocol interactions are 407 performed in the clear and may be modified by an active attacker. 408 For this reason, clients and servers MUST discard any sensitive 409 knowledge obtained prior to the start of the TLS handshake upon the 410 establishment of a security layer. Furthermore, the CAPABILITIES 411 command SHOULD be re-issued upon the establishment of a security 412 layer, and other protocol state SHOULD be re-negotiated as well. 414 It should be noted that NNTP is not an end-to-end mechanism. Thus, 415 if an NNTP client/server pair decide to add TLS confidentiality, 416 they are securing the transport only for that link. Similarly, 417 because delivery of a single piece of news may go between more than 418 two NNTP servers, adding TLS confidentiality to one pair of servers 419 does not mean that the entire NNTP chain has been made private. 420 Furthermore, just because an NNTP server can authenticate an NNTP 421 client, it does not mean that the articles from the NNTP client 422 were authenticated by the NNTP client when the client received 423 them. 425 During the TLS negotiation, the client MUST check its understanding 426 of the server hostname against the server's identity as presented 427 in the server Certificate message, in order to prevent man-in-the- 428 middle attacks. Matching is performed according to these rules: 430 - The client MUST use the server hostname it used to open the 431 connection (or the hostname specified in TLS "server_name" 432 extension [TLS-EXT]) as the value to compare against the server 433 name as expressed in the server certificate. The client MUST 434 NOT use any form of the server hostname derived from an insecure 435 remote source (e.g., insecure DNS lookup). CNAME 436 canonicalization is not done. 438 - If a subjectAltName extension of type dNSName is present in the 439 certificate, it SHOULD be used as the source of the server's 440 identity. 442 - Matching is case-insensitive. 444 - A "*" wildcard character MAY be used as the left-most name 445 component in the certificate. For example, *.example.com would 446 match a.example.com, foo.example.com, etc. but would not match 447 example.com. 449 - If the certificate contains multiple names (e.g. more than one 450 dNSName field), then a match with any one of the fields is 451 considered acceptable. 453 If the match fails, the client SHOULD either ask for explicit user 454 confirmation, or terminate the connection with a QUIT command and 455 indicate the server's identity is suspect. 457 A man-in-the-middle attack can be launched by deleting the STARTTLS 458 capability label in the CAPABILITIES response from the server. 459 This would cause the client not to try to start a TLS session. 460 Another man-in-the-middle attack is to allow the server to announce 461 its STARTTLS capability, but to alter the client's request to start 462 TLS and the server's response. An NNTP client can partially 463 protect against these attacks by recording the fact that a 464 particular NNTP server offers TLS during one session and generating 465 an alarm if it does not appear in the CAPABILITIES response for a 466 later session (of course, the STARTTLS capability would not be 467 listed after a security layer is in place). 469 If the TLS negotiation fails or if the client receives a 483 or 580 470 response, the client has to decide what to do next. The client has 471 to choose among three main options: to go ahead with the rest of 472 the NNTP session, to (re)try TLS later in the session, or to give 473 up and postpone newsreading/transport activity. If a failure or 474 error occurs, the client can assume that the server may be able to 475 negotiate TLS in the future, and should try to negotiate TLS in a 476 later session. However, if the client and server were only using 477 TLS for authentication and no previous 480 response was received, 478 the client may want to proceed with the NNTP session, in case some 479 of the operations the client wanted to perform are accepted by the 480 server even if the client is unauthenticated. 482 6. IANA Considerations 484 This section gives a formal definition of the STARTTLS extension as 485 required by Section 3.3.3 of [NNTP] for the IANA registry. 487 o The STARTTLS extension provides connection-based security via 488 the Transport Layer Security (TLS). 490 o The capability label for this extension is "STARTTLS". 492 o The capability label has no arguments. 494 o This extension defines one new command, STARTTLS, whose 495 behavior, arguments, and responses are defined in Section 2.2. 497 o This extension does not associate any new responses with pre- 498 existing NNTP commands. 500 o This extension does affect the overall behavior of both server 501 and client, in that after successful use of the STARTTLS 502 command, all communication is transmitted with the TLS layer as 503 an intermediary. 505 o This extension does not affect the maximum length of commands or 506 initial response lines. 508 o This extension does not alter pipelining, but the STARTTLS 509 command cannot be pipelined. 511 o Use of this extension does alter the capabilities list; once the 512 STARTTLS command has been used successfully, the STARTTLS 513 capability can no longer be advertised by CAPABILITIES. 514 Additionally, the MODE-READER capability MUST NOT be advertised 515 after a successful TLS negotiation. 517 o This extension does not cause any pre-existing command to 518 produce a 401, 480, or 483 response. 520 o This extension is unaffected by any use of the MODE READER 521 command, however the MODE READER command MUST NOT be used in the 522 same session following a successful TLS negotiation. 524 o Published Specification: This document. 526 o Author, Change Controller, and Contact for Further Information: 527 Author of this document. 529 7. References 531 7.1. Normative References 533 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 534 Specifications: ABNF", RFC 2234, November 1997. 536 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [NNTP] Feather, C., "Network News Transport Protocol", 540 draft-ietf-nntpext-base-*.txt, Work in Progress. 542 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 543 RFC 2246, January 1999. 545 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., 546 Mikkelsen, J., Wright, T., "Transport Layer Security (TLS) 547 Extensions", RFC 3546, June 2003. 549 7.2. Informative References 551 [NNTP-AUTH] Vinocur, J., Murchison, K., Newman, C., "NNTP Extension 552 for Authentication", draft-ietf-nntpext-auth-*.txt, Work in 553 Progress. 555 [SASL] Myers, J., "Simple Authentication and Security Layer 556 (SASL)", RFC 2222, October 1997. 558 [TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 559 2595, June 1999. 561 8. Authors' Addresses 563 Kenneth Murchison 564 Oceana Matrix Ltd. 565 21 Princeton Place 566 Orchard Park, NY 14127 USA 568 Email: ken@oceana.com 570 Jeffrey M. Vinocur 571 Department of Computer Science 572 Upson Hall 573 Cornell University 574 Ithaca, NY 14853 575 EMail: vinocur@cs.cornell.edu 577 Chris Newman 578 Sun Microsystems 579 1050 Lakes Drive, Suite 250 580 West Covina, CA 91790 582 EMail: Chris.Newman@sun.com 584 9. Acknowledgments 586 A significant amount of the text in this document was lifted from 587 RFC 2595 by Chris Newman and RFC 3207 by Paul Hoffman. 589 Special acknowledgment goes also to the people who commented 590 privately on intermediate revisions of this document, as well as 591 the members of the IETF NNTP Working Group for continual insight in 592 discussion. 594 10. Intellectual Property Rights 596 The IETF takes no position regarding the validity or scope of any 597 Intellectual Property Rights or other rights that might be claimed 598 to pertain to the implementation or use of the technology described 599 in this document or the extent to which any license under such 600 rights might or might not be available; nor does it represent that 601 it has made any independent effort to identify any such rights. 602 Information on the procedures with respect to rights in RFC 603 documents can be found in BCP 78 and BCP 79. 605 Copies of IPR disclosures made to the IETF Secretariat and any 606 assurances of licenses to be made available, or the result of an 607 attempt made to obtain a general license or permission for the use 608 of such proprietary rights by implementers or users of this 609 specification can be obtained from the IETF on-line IPR repository 610 at http://www.ietf.org/ipr. 612 The IETF invites any interested party to bring to its attention any 613 copyrights, patents or patent applications, or other proprietary 614 rights that may cover technology that may be required to implement 615 this standard. Please address the information to the IETF at 616 ietf-ipr@ietf.org. 618 11. Copyright 620 Copyright (C) The Internet Society (2005). 622 This document is subject to the rights, licenses and restrictions 623 contained in BCP 78, and except as set forth therein, the authors 624 retain all their rights. 626 This document and the information contained herein are provided on 627 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 628 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 629 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 630 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 631 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 632 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 633 PARTICULAR PURPOSE.