idnits 2.17.1 draft-ietf-nntpext-tls-nntp-06.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 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. ** 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], [TLS]), 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 (May 2005) is 6914 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 371, but not defined == Missing Reference: 'S' is mentioned on line 372, but not defined -- Looks like a reference, but probably isn't: '1' on line 169 ** 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' -- No information found for draft-ietf-tls-rfc2246-bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS' -- No information found for draft-ietf-tls-rfc3546bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS-EXT' -- No information found for draft-ietf-nntpext-auth- - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 15 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: November 2005 J. Vinocur 5 Cornell University 6 C. Newman 7 Sun Microsystems 8 May 2005 10 Using TLS with NNTP 11 draft-ietf-nntpext-tls-nntp-06 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 provide connection-based security (via 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 Table of Contents 52 0. Changes from Previous Version ............................ 2 53 1. Introduction ............................................. 3 54 1.1. Conventions Used in this Document ................... 3 55 2. The STARTTLS Extension ................................... 3 56 2.1. Advertising the STARTTLS Extension .................. 3 57 2.2. STARTTLS Command .................................... 4 58 2.2.1. Usage .......................................... 4 59 2.2.2. Description .................................... 4 60 2.2.2.1. Processing After the STARTTLS Command ..... 5 61 2.2.2.2. Result of the STARTTLS Command ............ 6 62 2.2.3. Examples ....................................... 7 63 3. Augmented BNF Syntax for the STARTTLS Extension .......... 8 64 3.1. Commands ............................................ 8 65 3.2. Capability entries .................................. 9 66 4. Summary of Response Codes ................................ 9 67 5. Security Considerations .................................. 9 68 6. IANA Considerations ...................................... 11 69 7. References ............................................... 12 70 7.1. Normative References ................................ 12 71 7.2. Informative References .............................. 12 72 8. Authors' Addresses ....................................... 12 73 9. Acknowledgments .......................................... 13 74 10. Intellectual Property Rights ............................ 13 75 11. Copyright ............................................... 14 77 0. Changes from Previous Version 79 Changed: 80 o Made Ken the primary author. 81 o Updated to RFC 3978/3979 boilerplate. 82 o Fixed CAPABILITIES responses (specifically LIST arguments) in 83 examples. 84 o Section 5: Consolidated two paragraphs to coincide with language 85 in [NNTP-AUTH]. 87 Clarified: 88 o Section 2.1: STARTTLS MUST NOT be advertised once a TLS layer 89 is active or after successful authentication. 90 o Section 3: This document extends the ABNF in [NNTP], and the 91 [NNTP] ABNF must be imported first before validating the 92 STARTTLS ABNF (based on recommendations of AD regarding 93 IMAPEXT I-Ds). 95 1. Introduction 97 Historically, unencrypted NNTP [NNTP] connections were satisfactory 98 for most purposes. However, sending passwords unencrypted over the 99 network is no longer appropriate, and sometimes strong encryption 100 is desired for the entire connection. 102 The STARTTLS extension provides a way to use the popular TLS [TLS] 103 service with the existing NNTP protocol. The current 104 (unstandardized) use of TLS for NNTP is most commonly on a 105 dedicated TCP port; this practice is discouraged for the reasons 106 documented in section 7 of "Using TLS with IMAP, POP3 and ACAP" 107 [TLS-IMAPPOP]. Therefore, this specification formalizes the 108 STARTTLS command already in occasional use by the installed base. 110 1.1. Conventions Used in this Document 112 The notational conventions used in this document are the same as 113 those in [NNTP] and any term not defined in this document has the 114 same meaning as in that one. 116 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 117 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 118 as described in "Key words for use in RFCs to Indicate Requirement 119 Levels" [KEYWORDS]. 121 In the examples, commands from the client are indicated with [C], 122 and responses from the server are indicated with [S]. 124 2. The STARTTLS Extension 126 This extension provides a new STARTTLS command and has the 127 capability label STARTTLS. 129 2.1. Advertising the STARTTLS Extension 131 A server supporting the STARTTLS command as defined in this 132 document will advertise the "STARTTLS" capability label in response 133 to the CAPABILITIES command. However, this capability MUST NOT be 134 advertised once a TLS layer is active (see section 2.2.2.2), or 135 after successful authentication [NNTP-AUTH]. This capability MAY 136 be advertised both before and after any use of MODE READER, with 137 the same semantics. 139 As the STARTTLS command is related to security, cached results of 140 CAPABILITIES from a previous session MUST NOT be relied on, as per 141 section 12.6 of [NNTP]. 143 Example: 145 [C] CAPABILITIES 146 [S] 101 Capability list: 147 [S] VERSION 2 148 [S] READER 149 [S] IHAVE 150 [S] STARTTLS 151 [S] LIST ACTIVE NEWSGROUPS 152 [S] . 154 2.2. STARTTLS Command 156 2.2.1. Usage 158 This command MUST NOT be pipelined. 160 Syntax 161 STARTTLS 163 Responses 165 382 Continue with TLS negotiation 166 502 Command unavailable [1] 167 580 Can not initiate TLS negotiation 169 [1] If a TLS layer is already active, or authentication has 170 occurred, STARTTLS is not a valid command (see section 2.2.2.2). 172 NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT 173 return either 480 or 483 in response to STARTTLS. 175 2.2.2. Description 177 A client issues the STARTTLS command to request negotiation of TLS. 178 The STARTTLS command is usually used to initiate session security, 179 although it can be used for client certificate authentication 180 and/or data compression. 182 An NNTP server returns the 483 response to indicate that a secure 183 or encrypted connection is required for the command sent by the 184 client. Use of the STARTTLS command as described below is one way 185 to establish a connection with these properties. The client MAY 186 therefore use the STARTTLS command after receiving a 483 response. 188 If a server advertises the STARTTLS capability, a client MAY 189 attempt to use the STARTTLS command at any time during a session to 190 negotiate TLS without having received a 483 response. Servers 191 SHOULD accept such unsolicited TLS negotiation requests. 193 If the server is unable to initiate the TLS negotiation for any 194 reason (e.g. a server configuration or resource problem), the 195 server MUST reject the STARTTLS command with a 580 response. 196 Otherwise, the server issues a 382 response and TLS negotiation 197 begins. A server MUST NOT under any circumstances reply to a 198 STARTTLS command with either a 480 or 483 response. 200 If the client receives a failure response to STARTTLS, the client 201 must decide whether or not to continue the NNTP session. Such a 202 decision is based on local policy. For instance, if TLS was being 203 used for client authentication, the client might try to continue 204 the session in case the server allows it to do so even with no 205 authentication. However, if TLS was being negotiated for 206 encryption, a client that gets a failure response needs to decide 207 whether to continue without TLS encryption, to wait and try again 208 later, or to give up and notify the user of the error. 210 After receiving a 382 response to a STARTTLS command, the client 211 MUST start the TLS negotiation before giving any other NNTP 212 commands. The TLS negotiation begins for both the client and 213 server with the first octet following the CRLF of the 382 response. 214 If, after having issued the STARTTLS command, the client finds out 215 that some failure prevents it from actually starting a TLS 216 handshake, then it SHOULD immediately close the connection. 218 Servers MUST be able to understand backwards-compatible TLS Client 219 Hello messages (provided that client_version is TLS 1.0 or later), 220 and clients MAY use backwards-compatible Client Hello messages. 221 Neither clients nor servers are required to actually support Client 222 Hello messages for anything other than TLS 1.0. However, the TLS 223 extension for Server Name Indication ("server_name") [TLS-EXT] 224 SHOULD be implemented by all clients; it also SHOULD be implemented 225 by any server implementing STARTTLS that is known by multiple names 226 (otherwise it is not possible for a server with several hostnames 227 to present the correct certificate to the client). 229 Although current use of TLS most often involves the dedication of 230 port 563 for NNTP over TLS, the continued use of TLS on a separate 231 port is discouraged for the reasons documented in section 7 of 232 "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP]. 234 2.2.2.1. Processing After the STARTTLS Command 236 After the TLS handshake has been completed, both parties MUST 237 immediately decide whether or not to continue based on the 238 authentication and privacy achieved (if any). The NNTP client and 239 server may decide to move ahead even if the TLS negotiation ended 240 without authentication and/or without privacy because NNTP services 241 are often performed without authentication or privacy, but some 242 NNTP clients or servers may want to continue only if a particular 243 level of authentication and/or privacy was achieved. 245 If the NNTP client decides that the level of authentication or 246 privacy is not high enough for it to continue, it SHOULD issue a 247 QUIT command immediately after the TLS negotiation is complete. If 248 the NNTP server decides that the level of authentication or privacy 249 is not high enough for it to continue, it SHOULD either reject 250 subsequent restricted NNTP commands from the client with a 483 251 response code (possibly with a text string such as "Command refused 252 due to lack of security"), or reject a command with a 400 response 253 code (possibly with a text string such as "Connection closing due 254 to lack of security") and close the connection. 256 The decision of whether or not to believe the authenticity of the 257 other party in a TLS negotiation is a local matter. However, some 258 general rules for the decisions are: 260 o The client MAY check that the identity presented in the server's 261 certificate matches the intended server hostname or domain. 262 This check is not required (and may fail in the absence of the 263 TLS "server_name" extension [TLS-EXT], as described above), but 264 if it is implemented and the match fails, the client SHOULD 265 either request explicit user confirmation, or terminate the 266 connection but allow the user to disable the check in the 267 future. 268 o Generally an NNTP server would want to accept any verifiable 269 certificate from a client, however authentication can be done 270 using the client certificate (perhaps in combination with the 271 SASL EXTERNAL mechanism [NNTP-AUTH], although an implementation 272 supporting STARTTLS is not required to support SASL in general 273 or that mechanism in particular). The server MAY use 274 information about the client certificate for identification of 275 connections or posted articles (either in its logs or directly 276 in posted articles). 278 2.2.2.2. Result of the STARTTLS Command 280 Upon successful completion of the TLS handshake, the NNTP protocol 281 is reset to the state immediately after the initial greeting 282 response (see 5.1 of [NNTP]) has been sent, with the exception that 283 if a MODE READER command has been issued, the effects of it (if 284 any) are not reversed. In this case, as no greeting is sent, the 285 next step is for the client to send a command. The server MUST 286 discard any knowledge obtained from the client, such as the current 287 newsgroup and article number, that was not obtained from the TLS 288 negotiation itself. Likewise, the client SHOULD discard and MUST 289 NOT rely on any knowledge obtained from the server, such as the 290 capability list, which was not obtained from the TLS negotiation 291 itself. 293 Both the client and the server MUST know if there is a TLS session 294 active. A client MUST NOT attempt to start a TLS session if a TLS 295 session is already active. A server MUST NOT return the STARTTLS 296 capability label in response to a CAPABILITIES command received 297 after a TLS handshake has completed, and a server MUST respond with 298 a 502 response code if a STARTTLS command is received while a TLS 299 session is already active. Additionally, the client MUST NOT issue 300 a MODE READER command while a TLS session is active and a server 301 MUST NOT advertise the MODE-READER capability. 303 The capability list returned in response to a CAPABILITIES command 304 received after the TLS handshake MAY be different than the list 305 returned before the TLS handshake. For example, an NNTP server 306 supporting SASL [NNTP-AUTH] might not want to advertise support for 307 a particular mechanism unless a client has sent an appropriate 308 client certificate during a TLS handshake. 310 2.2.3. Examples 312 Example of a client being prompted to use encryption and 313 negotiating it successfully (showing the removal of STARTTLS from 314 the capability list once a TLS layer is active), followed by a 315 successful selection of the group and an (inappropriate) attempt by 316 the client to initiate another TLS negotiation: 318 [C] CAPABILITIES 319 [S] 101 Capability list: 320 [S] VERSION 2 321 [S] READER 322 [S] STARTTLS 323 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 324 [S] OVER 325 [S] . 326 [C] GROUP local.confidential 327 [S] 483 Encryption or stronger authentication required 328 [C] STARTTLS 329 [S] 382 Continue with TLS negotiation 330 [TLS negotiation occurs here] 331 [Following successful negotiation, traffic is protected by TLS] 332 [C] CAPABILITIES 333 [S] 101 Capability list: 334 [S] VERSION 2 336 [S] READER 337 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 338 [S] OVER 339 [S] . 340 [C] GROUP local.confidential 341 [S] 211 1234 3000234 3002322 local.confidential 342 [C] STARTTLS 343 [S] 502 STARTTLS not allowed with active TLS layer 345 Example of a request to begin TLS negotiation declined by the 346 server: 348 [C] STARTTLS 349 [S] 580 Can not initiate TLS negotiation 351 Example of a failed attempt to negotiate TLS, followed by two 352 attempts at selecting groups only available under a security layer 353 (in the first case the server allows the session to continue, in 354 the second it closes the connection). Note that unrestricted 355 commands such as CAPABILITIES are unaffected by the failure: 357 [C] STARTTLS 358 [S] 382 Continue with TLS negotiation 359 [TLS negotiation is attempted here] 360 [Following failed negotiation, traffic resumes without TLS] 361 [C] CAPABILITIES 362 [S] 101 Capability list: 363 [S] VERSION 2 364 [S] READER 365 [S] STARTTLS 366 [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT 367 [S] OVER 368 [S] . 369 [C] GROUP local.confidential 370 [S] 483 Encryption or stronger authentication required 371 [C] GROUP local.private 372 [S] 400 Closing connection due to lack of security 374 3. Augmented BNF Syntax for the STARTTLS Extension 376 This section describes the formal syntax of the STARTTLS extension 377 using ABNF [ABNF]. It extends the syntax in section 9 of [NNTP], 378 and non-terminals not defined in this document are defined there. 379 The [NNTP] ABNF should be imported first before attempting to 380 validate these rules. 382 3.1. Commands 383 This syntax extends the non-terminal "command", which represents an 384 NNTP command. 386 command =/ starttls-command 388 starttls-command = "STARTTLS" 390 3.2. Capability entries 392 This syntax extends the non-terminal "capability-entry", which 393 represents a capability that may be advertised by the server. 395 capability-entry =/ starttls-capability 397 starttls-capability = "STARTTLS" 399 4. Summary of Response Codes 401 This section contains a list of every new response code defined in 402 this document, whether it is multi-line, which commands can 403 generate it, what arguments it has, and what its meaning is. 405 Response code 382 406 Generated by: STARTTLS 407 Meaning: continue with TLS negotiation 409 Response code 580 410 Generated by: STARTTLS 411 Meaning: can not initiate TLS negotiation 413 5. Security Considerations 415 Security issues are discussed throughout this memo. 417 In general, the security considerations of the TLS protocol [TLS] 418 and any implemented extensions [TLS-EXT] are applicable here; only 419 the most important are highlighted specifically below. Also, this 420 extension is not intended to cure the security considerations 421 described in section 12 of [NNTP]; those considerations remain 422 relevant to any NNTP implementation. 424 Before the TLS handshake has begun, any protocol interactions are 425 performed in the clear and may be modified by an active attacker. 426 For this reason, clients and servers MUST discard any sensitive 427 knowledge obtained prior to the start of the TLS handshake upon the 428 establishment of a security layer. Furthermore, the CAPABILITIES 429 command SHOULD be re-issued upon the establishment of a security 430 layer, and other protocol state SHOULD be re-negotiated as well. 432 It should be noted that NNTP is not an end-to-end mechanism. Thus, 433 if an NNTP client/server pair decide to add TLS privacy, they are 434 securing the transport only for that link. Similarly, because 435 delivery of a single piece of news may go between more than two 436 NNTP servers, adding TLS privacy to one pair of servers does not 437 mean that the entire NNTP chain has been made private. 438 Furthermore, just because an NNTP server can authenticate an NNTP 439 client, it does not mean that the articles from the NNTP client 440 were authenticated by the NNTP client when the client received 441 them. 443 Both the NNTP client and server must check the result of the TLS 444 negotiation to see whether an acceptable degree of authentication 445 and privacy was achieved. Ignoring this step completely 446 invalidates using TLS for security. The decision about whether 447 acceptable authentication or privacy was achieved is made locally, 448 is implementation-dependent, and is beyond the scope of this 449 document. 451 The NNTP client and server should note carefully the result of the 452 TLS negotiation. If the negotiation results in no privacy, or if 453 it results in privacy using algorithms or key lengths that are 454 deemed not strong enough, or if the authentication is not good 455 enough for either party, the client may choose to end the NNTP 456 session with an immediate QUIT command, or the server may choose 457 not to accept any more NNTP commands. 459 The client and server should also be aware that the TLS protocol 460 permits privacy and security capabilities to be renegotiated mid- 461 connection (see section 7.4.1 of [TLS]). For example, one of the 462 parties may desire minimal encryption after any authentication 463 steps have been performed. This underscores the fact that security 464 is not present simply because TLS has been negotiated; the nature 465 of the established security layer must be considered. 467 A man-in-the-middle attack can be launched by deleting the STARTTLS 468 capability label in the CAPABILITIES response from the server. 469 This would cause the client not to try to start a TLS session. 470 Another man-in-the-middle attack is to allow the server to announce 471 its STARTTLS capability, but to alter the client's request to start 472 TLS and the server's response. An NNTP client can partially 473 protect against these attacks by recording the fact that a 474 particular NNTP server offers TLS during one session and generating 475 an alarm if it does not appear in the CAPABILITIES response for a 476 later session (of course, the STARTTLS capability would not be 477 listed after a security layer is in place). 479 If the TLS negotiation fails or if the client receives a 483 480 response, the client has to decide what to do next. The client has 481 to choose among three main options: to go ahead with the rest of 482 the NNTP session, to retry TLS later in the session, or to give up 483 and postpone newsreading/transport activity. If a failure or error 484 occurs, the client can assume that the server may be able to 485 negotiate TLS in the future, and should try to negotiate TLS in a 486 later session. However, if the client and server were only using 487 TLS for authentication and no previous 480 response was received, 488 the client may want to proceed with the NNTP session, in case some 489 of the operations the client wanted to perform are accepted by the 490 server even if the client is unauthenticated. 492 6. IANA Considerations 494 This section gives a formal definition of the STARTTLS extension as 495 required by Section 3.3.3 of [NNTP] for the IANA registry. 497 o The STARTTLS extension provides connection-based security via 498 the Transport Layer Security (TLS). 500 o The capability label for this extension is "STARTTLS". 502 o The capability label has no arguments. 504 o This extension defines one new command, STARTTLS, whose 505 behavior, arguments, and responses are defined in Section 2.2. 507 o This extension does not associate any new responses with pre- 508 existing NNTP commands. 510 o This extension does affect the overall behavior of both server 511 and client, in that after successful use of the STARTTLS 512 command, all communication is transmitted with the TLS layer as 513 an intermediary. 515 o This extension does not affect the maximum length of commands or 516 initial response lines. 518 o This extension does not alter pipelining, but the STARTTLS 519 command cannot be pipelined. 521 o Use of this extension does alter the capabilities list; once the 522 STARTTLS command has been used successfully, the STARTTLS 523 capability can no longer be advertised by CAPABILITIES. 524 Additionally, the MODE-READER capability MUST NOT be advertised 525 after a successful TLS negotiation. 527 o This extension does not cause any pre-existing command to 528 produce a 401, 480, or 483 response. 530 o This extension is unaffected by any use of the MODE READER 531 command, however the MODE READER command MUST NOT be used in the 532 same session following a successful TLS negotiation. 534 o Published Specification: This document. 536 o Author, Change Controller, and Contact for Further Information: 537 Author of this document. 539 7. References 541 7.1. Normative References 543 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 544 Specifications: ABNF", RFC 2234, November 1997. 546 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [NNTP] Feather, C., "Network News Transport Protocol", 550 draft-ietf-nntpext-base-*.txt, Work in Progress. 552 [TLS] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 553 draft-ietf-tls-rfc2246-bis-*.txt, Work in Progress. 555 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., 556 Mikkelsen, J., Wright, T., "Transport Layer Security (TLS) 557 Extensions", draft-ietf-tls-rfc3546bis-*.txt, Work in Progress. 559 7.2. Informative References 561 [NNTP-AUTH] Vinocur, J., Murchison, K., Newman, C., "NNTP Extension 562 for Authentication", draft-ietf-nntpext-auth-*.txt, Work in 563 Progress. 565 [TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 566 2595, June 1999. 568 8. Authors' Addresses 570 Kenneth Murchison 571 Oceana Matrix Ltd. 572 21 Princeton Place 573 Orchard Park, NY 14127 USA 575 Email: ken@oceana.com 576 Jeffrey M. Vinocur 577 Department of Computer Science 578 Upson Hall 579 Cornell University 580 Ithaca, NY 14853 582 EMail: vinocur@cs.cornell.edu 584 Chris Newman 585 Sun Microsystems 586 1050 Lakes Drive, Suite 250 587 West Covina, CA 91790 589 EMail: cnewman@iplanet.com 591 9. Acknowledgments 593 A significant amount of the STARTTLS text was lifted from RFC 3207 594 by Paul Hoffman. 596 Special acknowledgment goes also to the people who commented 597 privately on intermediate revisions of this document, as well as 598 the members of the IETF NNTP Working Group for continual insight in 599 discussion. 601 10. Intellectual Property Rights 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed 605 to pertain to the implementation or use of the technology described 606 in this document or the extent to which any license under such 607 rights might or might not be available; nor does it represent that 608 it has made any independent effort to identify any such rights. 609 Information on the procedures with respect to rights in RFC 610 documents can be found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any 613 assurances of licenses to be made available, or the result of an 614 attempt made to obtain a general license or permission for the use 615 of such proprietary rights by implementers or users of this 616 specification can be obtained from the IETF on-line IPR repository 617 at http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at 623 ietf-ipr@ietf.org. 625 11. Copyright 627 Copyright (C) The Internet Society (2005). 629 This document is subject to the rights, licenses and restrictions 630 contained in BCP 78, and except as set forth therein, the authors 631 retain all their rights. 633 This document and the information contained herein are provided on 634 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 635 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 637 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 638 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 639 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 640 PARTICULAR PURPOSE.