idnits 2.17.1 draft-ietf-nntpext-tls-nntp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 (February 2003) is 7733 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 111, but not defined == Missing Reference: 'S' is mentioned on line 118, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'AUTH') == Outdated reference: A later version (-27) exists of draft-ietf-nntpext-base-16 ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Vinocur 3 INTERNET DRAFT Cornell University 4 Document: draft-ietf-nntpext-tls-nntp-00.txt C. Newman 5 Sun Microsystems 6 February 2003 8 Using TLS with NNTP 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.html. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This memo defines an extension to the Network News Transport 39 Protocol [NNTP] to provide connection-based encryption (via 40 Transport Layer Security [TLS]). The primary goal is to provide 41 encryption for single-link confidentiality purposes, but data 42 integrity and (optional) certificate-based peer entity 43 authentication are also described. 45 Table of Contents 47 1. Introduction ............................................. 2 48 1.1. Conventions Used in this Document ................... 2 49 2. Advertising Capabilities with the Extensions Mechanism ... 3 50 3. Authentication Response Codes ............................ 3 51 4. STARTTLS Command ......................................... 4 52 4.1. STARTTLS Responses .................................. 5 53 4.2. Processing After the STARTTLS Command ............... 5 54 4.3. Result of the STARTTLS Command ...................... 6 55 4.4. STARTTLS Formal Syntax .............................. 6 56 5. MULTIDOMAIN Extension .................................... 7 57 6. Security Considerations .................................. 8 58 7. Acknowledgements ......................................... 9 59 8. Normative References ..................................... 9 60 9. Informative References ................................... 10 61 10. Authors' Addresses ...................................... 10 63 1. Introduction 65 Historically, unencrypted NNTP [NNTP] connections were satisfactory 66 for most purposes. However, sending passwords unencrypted over the 67 network is no longer appropriate, and sometimes strong encryption 68 is desired for the entire connection. 70 The STARTTLS extension provides a way to use the popular TLS [TLS] 71 service with the existing NNTP protocol. The current 72 (unstandardized) use of TLS for NNTP is most commonly on a 73 dedicated TCP port; this practice is discouraged for the reasons 74 documented in section 7 of "Using TLS with IMAP, POP3 and ACAP" 75 [TLS-IMAPPOP]. Therefore, this specification formalizes and 76 extends the STARTTLS command already in occasional use by the 77 installed base. 79 1.1. Conventions Used in this Document 81 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 82 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 83 as described in "Key words for use in RFCs to Indicate Requirement 84 Levels" [KEYWORDS]. 86 Terms related to authentication are defined in "On Internet 87 Authentication" [AUTH]. 89 This document assumes you are familiar with NNTP [NNTP] and TLS 90 [TLS]. 92 In the examples, commands from the client are indicated with [C], 93 and responses from the server are indicated with [S]. 95 2. Advertising Capabilities with the Extensions Mechanism 97 The "LIST EXTENSIONS" command, documented in section 8 of [NNTP], 98 provides a mechanism for clients to discover what extensions are 99 available. 101 A server supporting the STARTTLS command as defined in section 4 102 will advertise the "STARTTLS" capability in response to the "LIST 103 EXTENSIONS" command issued when no TLS layer is active (see section 104 4.3). 106 A server supporting multiple domains as defined in section 5 will 107 advertise the "MULTIDOMAIN" capability in response to the "LIST 108 EXTENSIONS" command. 110 Example: 111 [C] LIST EXTENSIONS 112 [S] 202 Extensions supported: 113 [S] OVER 114 [S] PAT 115 [S] LISTGROUP 116 [S] STARTTLS 117 [S] MULTIDOMAIN 118 [S] . 120 Note that the STARTTLS command constitutes a mode changes and thus 121 clients MUST wait for completion prior to sending additional 122 commands. 124 3. Authentication Response Codes 126 An NNTP server MAY respond to any client command with a 483 127 response indicating that a strong encryption layer is required; in 128 general this response will be given to commands which may send 129 authentication data as plaintext. A client MAY react to a 483 130 response by establishing an encryption layer (for example, via 131 STARTTLS), though a 483 response is not required prior to 132 initiating encryption. The client also MAY try a different command 133 (for example, a type of authentication that would not risk password 134 compromise, QUIT, or any other command). 136 A server SHOULD only respond to a particular command as indicated 137 in this document, however a client MUST support unexpected response 138 codes by handling them based on the first digit as specified in 139 [NNTP]. 141 4. STARTTLS Command 143 STARTTLS [domain] 145 A client issues the STARTTLS command to request negotiation of TLS. 146 The client MUST NOT send any additional commands on the socket 147 until after it has received the server response to the command. 148 The STARTTLS command is usually used to request session encryption, 149 although it can be used for client certificate authentication. The 150 optional argument to STARTTLS is only permitted if the MULTIDOMAIN 151 extension is implemented as described in section 5. 153 If the client receives a failure response to STARTTLS, the client 154 must decide whether or not to continue the NNTP session. Such a 155 decision is based on local policy. For instance, if TLS was being 156 used for client authentication, the client might try to continue 157 the session, in case the server allows it to do so even with no 158 authentication. However, if TLS was being negotiated for 159 encryption, a client that gets a failure response needs to decide 160 whether to continue without TLS encryption, to wait and try again 161 later, or to give up and notify the user of the error. 163 An NNTP server MAY require the client to perform a TLS negotiation 164 before accepting any commands. In this case, the server SHOULD 165 return the 483 encryption-required response code to every command 166 other than HELP, LIST EXTENSIONS, QUIT, and any commands that 167 establish encryption, such as STARTTLS; the server MUST NOT return 168 483 in response to those commands. 170 After receiving a 382 response to a STARTTLS command, the client 171 MUST start the TLS negotiation before giving any other NNTP 172 commands. If, after having issued the STARTTLS command, the client 173 finds out that some failure prevents it from actually starting a 174 TLS handshake, then it SHOULD immediately close the connection. 176 Servers MUST be able to understand backwards-compatible TLS Client 177 Hello messages (provided that client_version is TLS 1.0 or later), 178 and clients MAY use backwards-compatible Client Hello messages. 179 Neither clients or servers are required to actually support Client 180 Hello messages for anything other than TLS 1.0. 182 Although current use of TLS most often involves the dedication of 183 port 563 for NNTP over TLS, the continued use of TLS on a separate 184 port is discouraged for the reasons documented in section 7 of 185 "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP]. 187 4.1. STARTTLS Responses 189 382 Continue with TLS negotiation 190 403 TLS temporarily not available 191 501 Command not supported or command syntax error 192 580 Security layer already active 194 Clients MUST support other response codes by processing them based 195 on the first digit. 197 4.2. Processing After the STARTTLS Command 199 After the TLS handshake has been completed, both parties MUST 200 immediately decide whether or not to continue based on the 201 authentication and privacy achieved. The NNTP client and server may 202 decide to move ahead even if the TLS negotiation ended with no 203 authentication and/or no privacy because NNTP services are often 204 performed without authentication or privacy, but some NNTP clients 205 or servers may want to continue only if a particular level of 206 authentication and/or privacy was achieved. 208 If the NNTP client decides that the level of authentication or 209 privacy is not high enough for it to continue, it SHOULD issue a 210 QUIT command immediately after the TLS negotiation is complete. If 211 the NNTP server decides that the level of authentication or privacy 212 is not high enough for it to continue, it SHOULD do at least one of 213 (1) close the connection, being aware that the client may interpret 214 this behavior as a network problem and immediately reconnect and 215 issue the same command sequence, or (2) keep the connection open 216 and reply to NNTP commands from the client with the 483 response 217 code (with a possible text string such as "Command refused due to 218 lack of security"), however this behavior may tie up resources 219 unacceptably. 221 The decision of whether or not to believe the authenticity of the 222 other party in a TLS negotiation is a local matter. However, some 223 general rules for the decisions are: 225 o The client MAY check that the identity presented in the server's 226 certificate matches the intended server hostname or domain. 227 This check is not required (and is probably unwise unless the 228 MULTIDOMAIN extension defined in section 5 has been used), but 229 if it is implemented and the match fails, the client SHOULD 230 either request explicit user confirmation, or terminate the 231 connection but allow the user to disable the check in the 232 future. 233 o Generally an NNTP server would want to accept any verifiable 234 certificate from a client, however authentication can be done 235 using the client certificate (perhaps in combination with the 236 SASL EXTERNAL mechanism [SASL-NNTP], although an implementation 237 supporting STARTTLS is not required to support that mechanism). 238 The server MAY use information about the client certificate for 239 identification of connections or posted articles (either in its 240 logs or directly in posted articles). 242 4.3. Result of the STARTTLS Command 244 Upon completion of the TLS handshake, the NNTP protocol is reset to 245 the initial state (the state in NNTP directly after the connection 246 is established). The server MUST discard any knowledge obtained 247 from the client, such as the result of a previous authentication, 248 which was not obtained from the TLS negotiation itself; immediately 249 after the TLS handshake, the server MUST issue a welcome banner 250 (response code 200 or 201) without the client issuing any further 251 command. The client MUST discard any knowledge obtained from the 252 server, such as the list of NNTP service extensions, which was not 253 obtained from the TLS negotiation itself. 255 The extensions returned in response to a LIST EXTENSIONS command 256 received after the TLS handshake MAY be different than the list 257 returned before the TLS handshake. For example, an NNTP server 258 supporting SASL [SASL-NNTP] might not want to advertise support for 259 a particular mechanism unless a client has sent an appropriate 260 client certificate during a TLS handshake. 262 Both the client and the server MUST know if there is a TLS session 263 active. A client MUST NOT attempt to start a TLS session if a TLS 264 session is already active. A server MUST NOT return the STARTTLS 265 extension in response to a LIST EXTENSIONS command received after a 266 TLS handshake has completed, and a server MUST respond with a 580 267 response code if a STARTTLS command is received while a TLS session 268 is already active. 270 4.4. STARTTLS Formal Syntax 272 This amends the formal syntax for NNTP [NNTP] to add the STARTTLS 273 command. The syntax is defined using ABNF [ABNF], including the 274 core rules from section 6 of [ABNF]. 276 An optional domain argument is available. The MULTIDOMAIN 277 extension defined in section 5 describes when this argument may and 278 may not be sent. The syntax for the domain element is as defined 279 in section 4.1.2 of the revised SMTP specification [SMTP]. 281 command /= starttls-command 282 starttls-command = "STARTTLS" [1*WSP domain] *WSP CRLF 283 ; domain is defined in sec. 4.1.2 of [SMTP] 284 ; WSP and CRLF are defined in sec. 13 of [NNTP] 286 5. MULTIDOMAIN Extension 288 Note to implementors of this draft specification: 289 A facility analagous to the one described below may be 290 provided in a future extension to the TLS specification 291 [TLS-EXT]. Standardization of that facility would obsolete 292 the extension described below, meaning that MULTIDOMAIN may 293 be entirely removed in a future revision of this draft in 294 favor of the protocol-independent implementation. 296 Many modern Internet servers host several domain names using the 297 same IP address, and each domain might have its own TLS server 298 certificate. Unless the client communicates the domain name it is 299 using to the server, the server can only use the IP address to 300 which the client connected to determine the appropriate server 301 certificate to present; this interferes with the client's ability 302 to compare the domain name it expects to the one listed in the 303 certificate. (The HTTP protocol [HTTP] added the "Host" request- 304 header in order to resolve this issue.) 306 If the MULTIDOMAIN extension is advertised, then clients SHOULD 307 send the domain name used to connect to the server as the argument 308 to the STARTTLS command. Clients MAY send the domain argument 309 without checking the result of LIST EXTENSIONS, but if the server 310 does not implement this extension it may respond with a 501 error 311 code (even if a STARTTLS command without argument would have been 312 accepted). The server MAY decline to enter TLS negotation if it 313 supports this extension and the domain argument is not given. The 314 client SHOULD send a fully qualified domain whenever that 315 information is available. 317 The server MAY use the domain argument to select an appropriate 318 server certificate to present to the client during TLS, though the 319 method by which the server selects a certificate is beyond the 320 scope of this document. However, the server should be prepared to 321 receive STARTTLS commands that lack the domain argument. 323 The domain argument MUST be discarded following successful 324 negotiation as discussed in section 4.3 and therefore cannot be 325 used later to determine how to authenticate a client. However, 326 usernames of the form user@host provide a viable alternative for 327 this functionality. 329 6. Security Considerations 331 In general, the security considerations of the TLS protocol [TLS] 332 are applicable here; only the most important are highlighted 333 specifically below. Also, this extension is not intended to cure 334 the security considerations described in section 14 of [NNTP]; 335 those considerations remain relevant to any NNTP implementation. 337 Use of STARTTLS cannot protect protocol exchanges conducted prior 338 to authentication. For this reason, the LIST EXTENSIONS command 339 SHOULD be re-issued after successful negotiation of a security 340 layer, and other protocol state SHOULD be re-negotiated as well. 342 It should be noted that NNTP is not an end-to-end mechanism. Thus, 343 if an NNTP client/server pair decide to add TLS privacy, they are 344 securing the transport only for that link. Further, because 345 delivery of a single piece of news may go between more than two 346 NNTP servers, adding TLS privacy to one pair of servers does not 347 mean that the entire NNTP chain has been made private. Further, 348 just because an NNTP server can authenticate an NNTP client, it 349 does not mean that the articles from the NNTP client were 350 authenticated by the NNTP client when the client received them. 352 Both the NNTP client and server must check the result of the TLS 353 negotiation to see whether an acceptable degree of authentication 354 and privacy was achieved. Ignoring this step completely 355 invalidates using TLS for security. The decision about whether 356 acceptable authentication or privacy was achieved is made locally, 357 is implementation-dependent, and is beyond the scope of this 358 document. 360 The NNTP client and server should note carefully the result of the 361 TLS negotiation. If the negotiation results in no privacy, or if 362 it results in privacy using algorithms or key lengths that are 363 deemed not strong enough, or if the authentication is not good 364 enough for either party, the client may choose to end the NNTP 365 session with an immediate QUIT command, or the server may choose 366 not to accept any more NNTP commands. 368 The client and server should also be aware that the TLS protocol 369 permits privacy and security capabilities to be renegotiated mid- 370 connection (see section 7.4.1 of [TLS]). For example, one of the 371 parties may desire minimal encryption after any authentication 372 steps have been performed. This underscores the fact that security 373 is not present simply because TLS has been negotiated; the nature 374 of the established security layer must be considered. 376 A man-in-the-middle attack can be launched by deleting the 382 377 response from the server. This would cause the client not to try to 378 start a TLS session. Another man-in-the-middle attack is to allow 379 the server to announce its STARTTLS capability, but to alter the 380 client's request to start TLS and the server's response. An NNTP 381 client can partially protect against these attacks by recording the 382 fact that a particular NNTP server offers TLS during one session 383 and generating an alarm if it does not appear in the LIST 384 EXTENSIONS response for a later session (of course, the STARTTLS 385 extension would not be listed after a security layer is in place). 387 If the TLS negotiation fails or if the client receives a 483 388 response, the client has to decide what to do next. The client has 389 to choose among three main options: to go ahead with the rest of 390 the NNTP session, to retry TLS at a later time, or to give up and 391 postpone newsreading activity. If a failure or error occurs, the 392 client can assume that the server may be able to negotiate TLS in 393 the future, and should try to negotiate TLS in a later session. 394 However, if the client and server were only using TLS for 395 authentication and no previous 480 response was received, the 396 client may want to proceed with the NNTP session, in case some of 397 the operations the client wanted to perform are accepted by the 398 server even if the client is unauthenticated. 400 Before the TLS handshake has begun, any protocol interactions are 401 performed in the clear and may be modified by an active attacker. 402 For this reason, clients and servers MUST discard any sensitive 403 knowledge obtained prior to the start of the TLS handshake upon 404 completion of the TLS handshake. 406 7. Acknowledgements 408 A significant amount of the STARTTLS text was lifted from RFC 3207 409 by Paul Hoffman. 411 Special acknowledgement goes also to the people who commented 412 privately on intermediate revisions of this document, as well as 413 the members of the IETF NNTP Working Group for continual insight in 414 discussion. 416 8. Normative References 418 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 419 Specifications: ABNF", RFC 2234, November 1997. 421 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", RFC 1704, 422 Bell Communications Research, October 1994. 424 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", RFC 2119, Harvard University, March 1997. 427 [NNTP] Barber, S., "Network News Transport Protocol" 428 (draft-ietf-nntpext-base-16.txt). 430 [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, AT&T 431 Laboratories, April 2001. 433 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 434 Certicom, January 1999. 436 [TLS-EXT] Blake-Wilson, S., Nystrom, M., "Transport Layer Security (TLS) 437 Extensions" (draft-ietf-tls-extensions-06.txt). 439 [TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 440 2595, Innosoft, June 1999. 442 9. Informative References 444 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 445 L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol -- 446 HTTP/1.1", RFC 2616, June 1999. 448 [SASL-NNTP] Vinocur, J., Newman, C., "Using SASL with NNTP", Work 449 in Progress. 451 10. Authors' Addresses 453 Jeffrey M. Vinocur 454 Department of Computer Science 455 Upson Hall 456 Cornell University 457 Ithaca, NY 14853 459 EMail: vinocur@cs.cornell.edu 461 Chris Newman 462 Sun Microsystems 463 1050 Lakes Drive, Suite 250 464 West Covina, CA 91790 466 EMail: cnewman@iplanet.com 468 Full Copyright Statement 470 Copyright (C) The Internet Society (2002). All Rights Reserved. 472 This document and translations of it may be copied and furnished to 473 others, and derivative works that comment on or otherwise explain 474 it or assist in its implementation may be prepared, copied, 475 published and distributed, in whole or in part, without restriction 476 of any kind, provided that the above copyright notice and this 477 paragraph are included on all such copies and derivative works. 478 However, this document itself may not be modified in any way, such 479 as by removing the copyright notice or references to the Internet 480 Society or other Internet organizations, except as needed for the 481 purpose of developing Internet standards in which case the 482 procedures for copyrights defined in the Internet Standards process 483 must be followed, or as required to translate it into languages 484 other than English. 486 The limited permissions granted above are perpetual and will not be 487 revoked by the Internet Society or its successors or assigns. 489 This document and the information contained herein is provided on 490 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 491 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 492 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 493 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.