idnits 2.17.1 draft-murray-auth-ftp-ssl-07.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages -- Found 30 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-959], [RFC-2817], [RFC-2487], [RFC-2228], [RFC-2246]), 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 == Line 963 has weird spacing: '....com.au pau...' == Line 967 has weird spacing: '...ign.com eri...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The REIN command, defined in [RFC-959], allows the user to reset the state of the FTP session. From [RFC-959]: REINITIALIZE (REIN) This command terminates a USER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to the default settings and the control connection is left open. This is identical to the state in which a user finds himself immediately after the control connection is opened. A USER command may be expected to follow. When this command is processed by the server, the TLS session(s) MUST be cleared and the control and data connections revert to unprotected, clear communications. It MAY be acceptable to use cached TLS sessions for subsequent connections, however a server MUST not mandate this. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SRA-FTP' is defined on line 944, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1579 ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2487 (Obsoleted by RFC 3207) ** Downref: Normative reference to an Informational RFC: RFC 2577 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-16) exists of draft-ietf-ftpext-mlst-12 -- Possible downref: Non-RFC (?) normative reference: ref. 'SRA-FTP' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Paul Ford-Hutchinson 3 IBM UK Ltd 4 Martin Carpenter 5 Verisign Inc 6 Tim Hudson 7 INTERNET-DRAFT (draft) RSA Australia Ltd 8 Eric Murray 9 Wave Systems Inc 10 Volker Wiegand 11 SuSE Linux 13 5th April, 2001 14 This document expires on 5th October, 2001 16 Securing FTP with TLS 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Index 40 1. .......... Abstract 41 2. .......... Introduction 42 3. .......... Audience 43 4. .......... Session negotiation on the control port 44 5. .......... Response to FEAT command 45 6. .......... Data Connection Behaviour 46 7. .......... Mechanisms for the AUTH Command 47 8. .......... SASL Considerations 48 9. .......... Data Connection Security 49 10. ......... A discussion of negotiation behaviour 50 11. ......... Who negotiates what, where and how 51 12. ......... Timing Diagrams 52 13. ......... Implications of [FTP-EXT] 53 14. ......... Discussion of the REIN command 54 15. ......... Security Considerations 55 16. ......... IANA Considerations 56 17. ......... Network Management 57 18. ......... Internationalization 58 19. ......... Scalability & Limits 59 20. ......... Applicability 60 21. ......... Acknowledgements 61 22. ......... References 62 23. ......... Authors' Contact Addresses 63 Appendices 64 A. .......... Summary of [RFC-2246] 65 B. .......... Summary of [RFC-2228] 67 1. Abstract 69 This document describes a mechanism that can be used by FTP clients 70 and servers to implement security and authentication using the TLS 71 protocol defined by [RFC-2246] and the extensions to the FTP protocol 72 defined by [RFC-2228]. It describes the subset of the extensions 73 that are required and the parameters to be used; discusses some of 74 the policy issues that clients and servers will need to take; 75 considers some of the implications of those policies and discusses 76 some expected behaviours of implementations to allow interoperation. 77 This document is intended to provide TLS support for FTP in a similar 78 way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817]. 80 TLS is not the only mechanism for securing file transfer, however it 81 does offer some of the following positive attributes:- 83 - Flexible security levels. TLS can support confidentiality, 84 integrity, authentication or some combination of all of these. 85 This allows clients and servers to dynamically, during a session, 86 decide on the level of security required for a particular data 87 transfer, 89 - It is possible to use X.509 certificates to authenticate client 90 users and not just client hosts. 92 - Formalised public key management. By use of X.509 public 93 certificates during the authentication phase, certificate 94 management can be built into a central function. Whilst this may 95 not be desirable for all uses of secured file transfer, it offers 96 advantages in certain structured environments. 98 - Co-existence and interoperation with authentication mechanisms 99 that are already in place for the HTTPS protocol. This allows web 100 browsers to incorporate secure file transfer using the same 101 infrastructure that has been set up to allow secure web browsing. 103 The TLS protocol is a development of the Netscape Communication 104 Corporation's SSL protocol and this document can be used to allow the 105 FTP protocol to be used with either SSL or TLS. The actual protocol 106 used will be decided by the negotiation of the protected session by 107 the TLS/SSL layer. This document will only refer to the TLS 108 protocol, however, it is understood that the Client and Server MAY 109 actually be using SSL if they are so configured. 111 Note that this specification is in accordance with the FTP RFC 112 [RFC-959] and relies on the TLS protocol [RFC-2246] and the FTP 113 security extensions [RFC-2228]. 115 2. Introduction 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 118 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and 119 "OPTIONAL" that appear in this document are to be interpreted as 120 described in [RFC-2119]. 122 This document is an attempt to describe how three other documents 123 should combined to provide a useful, interoperable, secure file 124 transfer protocol. Those documents are:- 126 RFC 959 [RFC-959] 128 The description of the Internet File Transfer Protocol 130 RFC 2246 [RFC-2246] 132 The description of the Transport Layer Security protocol 133 (developed from the Netscape Secure Sockets Layer (SSL) 134 protocol version 3.0). 136 RFC 2228 [RFC-2228] 138 Extensions to the FTP protocol to allow negotiation of security 139 mechanisms to allow authentication, confidentiality and message 140 integrity. 142 The File Transfer Protocol (FTP) currently defined in [RFC-959] and 143 in place on the Internet is an excellent mechanism for exchanging 144 files. The security extensions to FTP in [RFC-2228] offer a 145 comprehensive set of commands and responses that can be used to add 146 authentication, integrity and confidentiality to the FTP protocol. 147 The TLS protocol is a popular (due to its wholesale adoption in the 148 HTTP environment) mechanism for generally securing a socket 149 connection. 150 There are many ways in which these three protocols can be combined 151 which would ensure that interoperation is impossible. This document 152 describes one method by which FTP can operate securely in such a way 153 as to provide both flexibility and interoperation. This necessitates 154 a brief description of the actual negotiation mechanism ; a much more 155 detailed description of the policies and practices that would be 156 required and a discussion of the expected behaviours of clients and 157 servers to allow either party to impose their security requirements 158 on the FTP session. 160 3. Audience 161 This document is aimed at developers who wish to implement TLS as a 162 security mechanism to secure FTP clients and/or servers. 164 4. Session negotiation on the control port 166 4.1 Negotiated Session Security 168 The server listens on the normal FTP control port {FTP-PORT} and 169 the session initiation is not secured at all. Once the client 170 wishes to secure the session, the AUTH command is sent and the 171 server MAY then allow TLS negotiation to take place. 173 4.1.1 Client wants a secured session 175 If a client wishes to attempt to secure a session then it 176 SHOULD, in accordance with [RFC-2228] send the AUTH command with 177 the parameter requesting TLS {TLS-PARM}. 179 The client then needs to behave according to its policies 180 depending on the response received from the server and also the 181 result of the TLS negotiation. i.e. A client which receives an 182 AUTH rejection MAY choose to continue with the session 183 unprotected if it so desires. 185 4.1.2 Server wants a secured session 187 The FTP protocol does not allow a server to directly dictate 188 client behaviour, however the same effect can be achieved by 189 refusing to accept certain FTP commands until the session is 190 secured to an acceptable level to the server. 192 The server response to an 'AUTH TLS' command which it will honour, is 193 '234'. 195 The '334' response as defined in [RFC-2228] implies that an ADAT 196 exchange will folow. This document does not use the ADAT command 197 and so the '334' reply is incorrect. 199 Note. The FTP protocol insists that a USER command be used to 200 identify the entity attempting to use the ftp server. Although the 201 TLS negotiation may be providing authentication information (in the 202 form of a client's X.509 certificate), the USER command must still be 203 isssued by the client. However, it will be a server implementation 204 issue to decide which credentials to accept and what consistency 205 checks to make between any client cert and the parameter on the USER 206 command. 208 5. Response to the FEAT command 210 The FEAT command (introduced in [RFC-2389]) allows servers with 211 additional features to advertise these to a client by responding to 212 the FEAT command. If a server supports the FEAT command then it MUST 213 advertise supported AUTH, PBSZ and PROT commands in the reply as 214 described in section 3.2 of [RFC-2389]. Additionally, the AUTH 215 command should have a reply that identifies 'TLS' as one of the 216 possible parameters to AUTH. It is not necessary to identify the 217 'TLS-C' synonym separately. 219 Example reply (in same style is [RFC-2389]) 220 C> FEAT 221 S> 211-Extensions supported 222 S> AUTH TLS 223 S> PBSZ 224 S> PROT 225 S> 211 END 227 6. Data Connection Behaviour 229 The Data Connection in the FTP model can be used in one of three 230 ways. (Note: these descriptions are not necessarily placed in exact 231 chronological order, but do describe the steps required. - See 232 diagrams later for clarification) 234 i) Classic FTP client/server data exchange 236 - The client obtains a port; sends the port number to the 237 server; the server connects to the client. The client issues a 238 send or receive request to the server on the control connection 239 and the data transfer commences on the data connection. 241 ii) Firewall-Friendly client/server data exchange (as discussed 242 in [RFC-1579]) using the PASV command to reverse the direction 243 of the data connection. 245 - The client requests that the server open a port; the server 246 obtains a port and returns the address and port number to the 247 client; the client connects to the server on this port. The 248 client issues a send or receive request on the control 249 connection and the data transfer commences on the data 250 connection. 252 iii) Client initiated server/server data exchange (proxy or 253 PASV connections) 254 - The client requests that server A opens a port; server A 255 obtains a port and returns it to the client; the client sends 256 this port number to server B. Server B connects to server A. 257 The client sends a send or receive request to server A and the 258 complement to server B and the data transfer commences. In 259 this model server A is the proxy or PASV host and is a client 260 for the Data Connection to server B. 262 For i) and ii) the FTP client MUST be the TLS client and the FTP 263 server MUST be the TLS server. 265 That is to say, it does not matter which side initiates the 266 connection with a connect() call or which side reacts to the 267 connection via the accept() call; the FTP client as defined in 268 [RFC-959] is always the TLS client as defined in [RFC-2246]. 270 In scenario iii) there is a problem in that neither server A nor 271 server B is the TLS client given the fact that an FTP server must act 272 as a TLS server for Firewall-Friendly FTP [RFC-1579]. Thus this is 273 explicitly excluded in the security extensions document [RFC-2228], 274 and in this document. 276 7. Mechanisms for the AUTH Command 278 The AUTH command takes a single parameter to define the security 279 mechanism to be negotiated. As the SSL/TLS protocols self-negotiate 280 their levels there is no need to distinguish SSL vs TLS in the 281 application layer. The proposed mechanism name for negotiating TLS 282 will be the character string identified in {TLS-PARM}. This will 283 allow the client and server to negotiate TLS on the control 284 connection without altering the protection of the data channel. To 285 protect the data channel as well, the PBSZ:PROT command sequence MUST 286 be used. 288 Note: The data connection state MAY be modified by the client issuing 289 the PROT command with the new desired level of data channel 290 protection and the server replying in the affirmative. This data 291 channel protection negotiation can happen at any point in the session 292 (even straight after a PORT or PASV command) and as often as is 293 required. 295 See also Section 16, "IANA Considerations". 297 8. SASL Considerations 298 SASL is the Simple Authentication Security Layer. Currently, its 299 definition can be found in [RFC-2222]. This document attempts to 300 define the means by which a connection-based protocol may identify 301 and authenticate a client user to a server, with additional optional 302 negotiation of protection for the remainder of that session. 304 Unfortunately, the SASL paradigm does not fit in neatly with the FTP- 305 TLS protocol, mainly due to the fact that FTP uses two (independent) 306 connections, and under FTP-TLS these may be at different (and 307 possibly renegotiable) protection levels. Consequently, it is 308 envisaged that SASL will sit underneath TLS on the control 309 connection, and TLS (on both, either or neither connection) will be 310 used for confidentiality and integrity (with optional authentication 311 from TLS on either connection). 313 9. Data Connection Security 315 The Data Connection security level is determined by the PROT command 317 The PROT command, as specified in [RFC-2228] allows client/server 318 negotiation of the security level of the data connection. Once a 319 PROT command has been issued by the client and accepted by the 320 server returning the '200' reply, the security of subsequent data 321 connections MUST be at that level until another PROT command is 322 issued and accepted; the session ends; a REIN command is issued; 323 or the security of the session (via an AUTH command) is re- 324 negotiated). 326 Data Connection Security Negotiation (the PROT command) 328 Note: In line with [RFC-2228], there is no facility for securing 329 the Data connection with an insecure Control connection. 330 Specifically, the PROT command MUST be preceded by a PBSZ command 331 and a PBSZ command MUST be preceded by a successful security data 332 exchange (the TLS negotiation in this case) 334 The command defined in [RFC-2228] to negotiate data connection 335 security is the PROT command. As defined there are four values 336 that the PROT command parameter can take. 338 'C' - Clear - neither Integrity nor Privacy 340 'S' - Safe - Integrity without Privacy 342 'E' - Confidential - Privacy without Integrity 344 'P' - Private - Integrity and Privacy 346 As TLS negotiation encompasses (and exceeds) the Safe / 347 Confidential / Private distinction, only Private (use TLS) and 348 Clear (don't use TLS) are used. 350 For TLS, the data connection can have one of two security levels. 352 1)Clear (requested by 'PROT C') 354 2)Private (requested by 'PROT P') 356 With 'Clear' protection level, the data connection is made without 357 TLS at all. Thus the connection is unauthenticated and has no 358 confidentiality or integrity. This might be the desired behaviour 359 for servers sending file lists, pre-encrypted data or non- 360 sensitive data (e.g. for anonymous FTP servers). 362 If the data connection security level is 'Private' then a TLS 363 negotiation must take place on the data connection, to the 364 satisfaction of the 365 Client and Server prior to any data being transmitted over the 366 connection. The TLS layers of the Client and Server will be 367 responsible for negotiating the exact TLS Cipher Suites that will 368 be used (and thus the eventual security of the connection). 370 In addition, the PBSZ (protection buffer size) command, as 371 detailed in [RFC-2228], is compulsory prior to any PROT command. 372 This document also defines a data channel encapsulation mechanism 373 for protected data buffers. For FTP-TLS, which appears to the FTP 374 application as a streaming protection mechanism, this is not 375 required. Thus the PBSZ command must still be issued, but must 376 have a parameter of '0' to indicate that no buffering is taking 377 place and the data connection should not be encapsulated. 378 Note that PBSZ 0 is not in the grammar of [RFC-2228], section 379 8.1, where it is stated: 380 PBSZ ::= any 381 decimal integer from 1 to (2^32)-1 382 However it should be noted that using a value of '0' to mean a 383 streaming protocol is a reasonable use of '0' for that parameter 384 and is not ambiguous. 386 Initial Data Connection Security 388 The initial state of the data connection MUST be 'Clear' (this is 389 the behaviour as indicated by [RFC-2228].) 391 10. A Discussion of Negotiation Behaviour 392 10.1. The server's view of the control connection 394 A server MAY have a policy statement somewhere that might: 396 - Deny any command before TLS is negotiated (this might cause 397 problems if a SITE or some such command is required prior to 398 login) 399 - Deny certain commands before TLS is negotiated (such as USER, 400 PASS or ACCT) 401 - Deny insecure USER commands for certain users (e.g. not 402 ftp/anonymous) 403 - Deny secure USER commands for certain users (e.g. 404 ftp/anonymous) 405 - Define the level(s) of TLS to be allowed 406 - Define the CipherSuites allowed to be used (perhaps on a per 407 host/domain/... basis) 408 - Allow TLS authentication as a substitute for local 409 authentication. 410 - Define data connection policies (see next section) 412 Note: The TLS negotiation may not be completed satisfactorily 413 for the server, in which case it can be one of these states. 415 The TLS negotiation failed completely 417 In this case, the control connection should still be up in 418 unprotected mode and the server should issue an unprotected 419 '421' reply to end the session. 421 The TLS negotiation completed successfully, but the server 422 decides that the session parameters are not acceptable (e.g. 423 Distinguished Name in the client certificate is not 424 permitted to use the server) 426 In this case, the control connection should still be up in a 427 protected state, so the server can either continue to refuse to 428 service commands or issue a '421' reply and close the 429 connection. 431 The TLS negotiation failed during the TLS handshake 433 In this case, the control connection is in an unknown state and 434 the server should simply drop the control connection. 436 Server code will be responsible for implementing the required 437 policies and ensuring that the client is prevented from 438 circumventing the chosen security by refusing to service those 439 commands that are against policy. 441 10.2. The server's view of the data connection 443 The server can take one of four basic views of the data connection 445 1 - Don't allow encryption at all (in which case the PROT 446 command should not allow any value other than 'C' - if it is 447 allowed at all) 448 2 - Allow the client to choose protection or not 449 3 - Insist on data protection (in which case the PROT command 450 must be issued prior to the first attempted data transfer) 451 4 - Decide on one of the above three for each and every data 452 connection 454 The server SHOULD only check the status of the data protection 455 level (for options 3 and 4 above) on the actual command that will 456 initiate the data transfer (and not on the PORT or PASV). The 457 following commands cause data connections to be opened and thus 458 may be rejected (before any 1xx) message due to an incorrect PROT 459 setting. 461 STOR 462 RETR 463 NLST 464 LIST 465 STOU 466 APPE 467 MLST (if [FTP-EXT] is implemented) 468 MLSD (if [FTP-EXT] is implemented) 470 The reply to indicate that the PROT setting is incorrect is 471 '521 data connection cannot be opened with this PROT setting' 472 If the protection level indicates that TLS is required, then it 473 should be negotiated once the data connection is made. Thus, the 474 '150' reply only states that the command can be used given the 475 current PROT level. Should the server not like the TLS 476 negotiation then it will close the data port immediately and 477 follow the '150' command with a '522' reply indicating that the 478 TLS negotiation failed or was unacceptable. (Note: this means 479 that the application can pass a standard list of CipherSuites to 480 the TLS layer for negotiation and review the one negotiated for 481 applicability in each instance). 483 It is quite reasonable for the server to insist that the data 484 connection uses a TLS cached session. This might be a cache of a 485 previous data connection or of the control connection. If this is 486 the reason for the the refusal to allow the data transfer then the 487 '522' reply should indicate this. 488 Note: this has an important impact on client design, but allows 489 servers to minimise the cycles used during TLS negotiation by 490 refusing to perform a full negotiation with a previously 491 authenticated client. 493 It should be noted that the TLS authentication of the server will 494 be authentication of the server host itself and not a user on the 495 server host. 497 10.3. The client's view of the control connection 499 In most cases it is likely that the client will be using TLS 500 because the server would refuse to interact insecurely. To allow 501 for this, clients must be able to be flexible enough to manage the 502 securing of a session at the appropriate time and still allow the 503 user/server policies to dictate exactly when in the session the 504 security is negotiated. 506 In the case where it is the client that is insisting on the 507 securing of the session, it will need to ensure that the 508 negotiations are all completed satisfactorily and will need to be 509 able to inform the user sensibly should the server not support, or 510 be prepared to use, the required security levels. 512 Clients must be coded in such a manner as to allow the timing of 513 the AUTH, PBSZ and PROT commands to be flexible and dictated by 514 the server. It is quite reasonable for a server to refuse certain 515 commands prior to these commands, similarly it is quite possible 516 that a SITE or quoted command might be needed by a server prior to 517 the AUTH. A client must allow a user to override the timing of 518 these commands to suit a specific server. 519 For example, a client should not insist on sending the AUTH as the 520 first command in a session, nor should it insist on issuing a 521 PBSZ, PROT pair directly after the AUTH. This may well be the 522 default behaviour, but must be overridable by a user. 524 Note: The TLS negotiation may not be completed satisfactorily for 525 the client, in which case it will be in one of these states: 527 The TLS negotiation failed completely 529 In this case, the control connection should still be up in 530 unprotected mode and the client should issue an unprotected 531 QUIT command to end the session. 533 The TLS negotiation completed successfully, but the client 534 decides that the session parameters are not acceptable (e.g. 536 Distinguished Name in certificate is not the actual server 537 expected) 539 In this case, the control connection should still be up in a 540 protected state, so the client should issue a protected QUIT 541 command to end the session. 543 The TLS negotiation failed during the TLS handshake 545 In this case, the control connection is in an unknown state 546 and the client should simply drop the control connection. 548 10.4. The client's view of the data connection 550 Client security policies 552 Clients do not typically have 'policies' as such, instead they 553 rely on the user defining their actions and, to a certain extent, 554 are reactive to the server policy. Thus a client will need to 555 have commands that will allow the user to switch the protection 556 level of the data connection dynamically, however, there may be a 557 general 'policy' that attempts all LIST and NLST commands on a 558 Clear connection first (and automatically switches to Private if 559 it fails). In this case there would need to be a user command 560 available to ensure that a given data transfer was not attempted 561 on an insecure data connection. 563 Clients also need to understand that the level of the PROT setting 564 is only checked for a particular data transfer after that transfer 565 has been requested. Thus a refusal by the server to accept a 566 particular data transfer should not be read by the client as a 567 refusal to accept that data protection level in toto, as not only 568 may other data transfers be acceptable at that protection level, 569 but it is entirely possible that the same transfer may be accepted 570 at the same protection level at a later point in the session. 572 It should be noted that the TLS authentication of the client 573 should be authentication of a user on the client host and not the 574 client host itself. 576 11. Who negotiates what, where and how 578 11.1. Do we protect at all ? 580 Client issues AUTH , server accepts or rejects. 581 If server needs AUTH, then it refuses to accept certain commands 582 until it gets a successfully protected session. 584 11.2. What level of protection do we use on the Control connection ? 586 Decided entirely by the TLS CipherSuite negotiation. 588 11.3. Do we protect data connections in general ? 590 Client issues PROT command, server accepts or rejects. 592 11.4. Is protection required for a particular data transfer ? 594 A client would already have issued a PROT command if it required 595 the connection to be protected. 596 If a server needs to have the connection protected then it will 597 reply to the STOR/RETR/NLST/... command with a '522' indicating 598 that the current state of the data connection protection level is 599 not sufficient for that data transfer at that time. 601 11.5. What level of protection is required for a particular data 602 transfer ? 604 Decided entirely by the TLS CipherSuite negotiation. 606 Thus it can be seen that, for flexibility, it is desirable for the 607 FTP application to be able to interact with the TLS layer upon which 608 it sits to define and discover the exact TLS CipherSuites that are to 609 be/have been negotiated and make decisions accordingly. 611 12. Timing Diagrams 613 12.1. Establishing a protected session 615 Client Server 616 control data data control 617 ==================================================================== 619 socket() 620 bind() 621 socket() 622 connect() ----------------------------------------------> accept() 623 AUTH TLS ----------------------------------------------> 624 <---------------------------------------------- 234 625 TLSneg() <----------------------------------------------> TLSneg() 626 PBSZ 0 ----------------------------------------------> 627 <---------------------------------------------- 200 628 PROT P ----------------------------------------------> 629 <---------------------------------------------- 200 630 USER fred ----------------------------------------------> 631 <---------------------------------------------- 331 632 PASS pass ----------------------------------------------> 633 <---------------------------------------------- 230 635 Note 1: the order of the PBSZ/PROT pair and the USER/PASS pair (with 636 respect to each other) is not important (i.e. the USER/PASS can happen 637 prior to the PBSZ/PROT - or indeed the server can refuse to allow a 638 PBSZ/PROT pair until the USER/PASS pair has happened). 640 Note 2: the PASS command might not be required at all (if the USER 641 parameter and any X.509 client certificate presented provide sufficient 642 authentication). The server would indicate this by issuing a '232' 643 reply to the USER command instead of the '331' which requests a PASS 644 from the client. 646 12.2. A standard data transfer without protection. 648 Client Server 649 control data data control 650 ==================================================================== 652 socket() 653 bind() 654 PORT w,x,y,z,a,b -----------------------------------------> 655 <----------------------------------------------------- 200 656 STOR file ------------------------------------------------> 657 socket() 658 bind() 659 <----------------------------------------------------- 150 660 accept() <----------- connect() 661 write() -----------> read() 662 close() -----------> close() 663 <----------------------------------------------------- 226 665 12.3. A firewall-friendly data transfer without protection 667 Client Server 668 control data data control 669 ==================================================================== 671 PASV --------------------------------------------------------> 672 socket() 673 bind() 674 <------------------------------------------ 227 (w,x,y,z,a,b) 675 socket() 676 STOR file ---------------------------------------------------> 677 connect() ----------> accept() 678 <-------------------------------------------------------- 150 679 write() ----------> read() 680 close() ----------> close() 681 <-------------------------------------------------------- 226 683 Note: Implementors should be aware that then connect()/accept() 684 function is performed prior to the receipt of the reply from the 685 STOR command. This contrasts with situation when (non-firewall- 686 friendly) PORT is used prior to the STOR, and the accept()/connect() 687 is performed after the reply from the aforementioned STOR has been 688 dealt with. 690 12.4. A standard data transfer with protection 692 Client Server 693 control data data control 694 ==================================================================== 696 socket() 697 bind() 698 PORT w,x,y,z,a,b --------------------------------------------> 699 <-------------------------------------------------------- 200 700 STOR file ---------------------------------------------------> 701 socket() 702 bind() 703 <-------------------------------------------------------- 150 704 accept() <---------- connect() 705 TLSneg() <----------> TLSneg() 706 TLSwrite() ----------> TLSread() 707 close() ----------> close() 708 <-------------------------------------------------------- 226 710 12.5. A firewall-friendly data transfer with protection 712 Client Server 713 control data data control 714 ==================================================================== 716 PASV --------------------------------------------------------> 717 socket() 718 bind() 719 <------------------------------------------ 227 (w,x,y,z,a,b) 720 socket() 721 STOR file ---------------------------------------------------> 722 connect() ----------> accept() 723 <-------------------------------------------------------- 150 724 TLSneg() <---------> TLSneg() 725 TLSwrite() ---------> TLSread() 726 close() ---------> close() 727 <-------------------------------------------------------- 226 729 13. Implications of [FTP-EXT] 731 13.1. MLST and MLSD 733 MLST and MLSD are directory listing commands and should be treated 734 in the same manner as NLST and LIST for the purposes of this 735 document. 737 14. Discussion of the REIN command 739 The REIN command, defined in [RFC-959], allows the user to reset the 740 state of the FTP session. From [RFC-959]: 741 REINITIALIZE (REIN) 742 This command terminates a USER, flushing all I/O and account 743 information, except to allow any transfer in progress to be 744 completed. All parameters are reset to the default settings 745 and the control connection is left open. This is identical to 746 the state in which a user finds himself immediately after the 747 control connection is opened. A USER command may be expected 748 to follow. 749 When this command is processed by the server, the TLS session(s) 750 MUST be cleared and the control and data connections revert to 751 unprotected, clear communications. It MAY be acceptable to use 752 cached TLS sessions for subsequent connections, however a server MUST 753 not mandate this. 755 15. Security Considerations 757 This entire document deals with security considerations related to 758 the File Transfer Protocol. 760 15.1. Verification of Authentication tokens 762 15.1.1. Server Certificates 764 Although it is entirely an implementation decision, it is 765 recommended that certificates used for server authentication of 766 the TLS session contain the server identification information 767 in a similar manner to those used for http servers. (see 768 [RFC-2818]) 770 Note that, if there is any future extensions to the FTP 771 protocol to allow multi-homed servers, then the interaction of 772 such a mechanism, the REIN commands and the certificate 773 presented by the server in the TLS handshake will need to be 774 considered carefully. 776 15.1.2. Client Certificates 778 - Deciding which client certificates to allow and defining 779 which fields define what authentication information is entirely 780 a server implementation issue. 782 - It is also server implementation issue to decide if the 783 authentication token presented for the data connection must 784 match the one used for the corresponding control connection. 786 15.2. Addressing FTP Security Considerations [RFC-2577] 788 15.2.1. Bounce Attack 790 A bounce attack should be harder in a secured FTP environment 791 because: 793 - The FTP server that is being used to initiate a false 794 connection will always be a 'server' in the TLS context. 795 Therefore, only services that act as 'clients' in the TLS 796 context could be vulnerable. This would be a counter- 797 intuitive way to implement TLS on a service. 799 - The FTP server would detect that the authentication 800 credentials for the data connection are not the same as 801 those for the control connection, thus the server policies 802 COULD be set to drop the data connection. 804 - Genuine users are less likely to initiate such attacks 805 when the authentication is strong and malicious users are 806 less likely to gain access to the FTP server if the 807 authentication is not easily subverted (password guessing, 808 network tracing, etc...) 810 15.2.2. Restricting Access 812 This document presents a strong mechanism for solving the issue 813 raised in this section. 815 15.2.3. Protecting Passwords 817 The twin solutions of strong authentication and data 818 confidentiality ensure that this is not an issue when TLS is 819 used to protect the control session. 821 15.2.4. Privacy 823 The TLS protocol ensures data confidentiality by encryption. 824 Privacy (e.g. access to download logs, user profile 825 information, etc...) is outside the scope of this document (and 826 [RFC-2577] presumably) 828 15.2.5. Protecting Usernames 830 This is not an issue when TLS is used as the primary 831 authentication mechanism. 833 15.2.6. Port Stealing 835 This proposal will do little for the Denial of Service element 836 of this section, however, strong authentication on the data 837 connection will prevent unauthorised connections retrieving or 838 submitting files. 840 15.2.7. Software-Base Security Problems 842 Nothing in this proposal will affect the discussion in this 843 section. 845 16. IANA Considerations 847 {FTP-PORT} - The port assigned to the FTP control connection is 21. 849 {FTP-TLSPORT} - A port assigned by the IANA for native TLS FTP 850 connections on the control socket. This has been reserved as port 851 990. 852 N.B. This approach is no longer recommended by the IETF and has 853 been deprecated. 855 {TLS-PARM} - The parameter for the AUTH command to indicate that TLS 856 is required. To request the TLS protocol in accordance with this 857 document, the client MUST use 'TLS' 859 To manintain backward compatability with older versions of this 860 document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS' 862 Note - [RFC-2228] states that these parameters are case- 863 insensitive. 865 17. Network Management 867 NONE 869 18. Internationalization 871 NONE 873 19. Scalability & Limits 875 There are no issues other than those concerned with the ability of 876 the server to refuse to have a complete TLS negotiation for each and 877 every data connection, which will allow servers to retain throughput 878 whilst using cycles only when necessary. 880 20. Applicability 882 This mechanism is generally applicable as a mechanism for securing 883 the FTP protocol. It is unlikely that anonymous FTP clients or 884 servers will require such security (although some might like the 885 authentication features without the confidentiality). 887 21. Acknowledgements 889 o Netscape Communications Corporation for the original SSL protocol. 891 o Eric Young for the SSLeay libraries. 893 o University of California, Berkley for the original implementations 894 of FTP and ftpd on which the initial implementation of these 895 extensions were layered. 897 o IETF CAT working group. 899 o IETF TLS working group. 901 o IETF FTPEXT working group. 903 22. References 905 [RFC-959] J. Postel, "File Transfer Protocol" 906 RFC 959, October 1985. 908 [RFC-1579] S. Bellovin, "Firewall-Friendly FTP" 909 RFC 1579, February 1994. 911 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 912 Requirement Levels" 913 RFC 2119, March 1997. 915 [RFC-2222] J. Myers, "Simple Authentication and Security Layer" 916 RFC 2222, October 1997. 918 [RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions" 919 RFC 2228, October 1997. 921 [RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" 922 RFC 2246, January 1999. 924 [RFC-2389] P Hethmon, R.Elz, "Feature Negotiation Mechanism for the 925 File Transfer Protocol" 926 RFC 2389, August 1998. 928 [RFC-2487] P Hoffman, "SMTP Service Extension for Secure SMTP over 929 TLS" 930 RFC 2487, January 1999. 932 [RFC-2577] M Allman, S Ostermann, "FTP Security Considerations" 933 RFC 2577, May 1999. 935 [RFC-2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" 936 RFC 2817, May 2000. 938 [RFC-2818] E. Rescorla, "HTTP Over TLS" 939 RFC 2818, May 2000. 941 [FTP-EXT] R Elz, P Hethmon "Extensions to FTP" 942 draft-ietf-ftpext-mlst-12.txt, September 2000. 944 [SRA-FTP] "SRA - Secure RPC Authentication for TELNET and FTP Version 945 1.1" 946 file://ftp.funet.fi/security/login/telnet/doc/sra/sra.README 948 23. Authors' Contact Addresses 950 The FTP-TLS draft information site is at http://www.ford- 951 hutchinson.com/~fh-1-pfh/ftps-ext.html 953 Please send comments to Paul Ford-Hutchinson at the address below 955 Tim Hudson Paul Ford-Hutchinson 956 RSA Data Security IBM UK Ltd 957 Australia Pty Ltd PO Box 31 958 Birmingham Road 959 Warwick 960 United Kingdom 961 tel - +61 7 3227 4444 +44 1926 462005 962 fax - +61 7 3227 4400 +44 1926 496482 963 email - tjh@rsasecurity.com.au paulfordh@uk.ibm.com 965 Martin Carpenter Eric Murray 966 Verisign Ltd Wave Systems Inc. 967 email - mcarpenter@verisign.com ericm@lne.com 969 Volker Wiegand 970 SuSE Linux 971 email - wiegand@suse.de 972 Appendices 974 A. Deprecated SSL negotiation mechanisms 976 There are two other mechanisms that have been used for FTP over SSL, 977 these mechanisms do not conform to [RFC-2228] and so are now 978 deprecated. They are documented below. 980 i) Implicit SSL protection of the FTP session 982 There is a port, registered with the IANA, for secure FTP using 983 ssl {FTP-TLSPORT}. This approach can be likened to the [RFC-2818] 984 approach for https, in that the SSL negotiation happens upon 985 connection (for the control and all data connections). This 986 approach is not favoured by the IETF and should not be used for 987 new FTP-TLS implementations. 989 ii) Protection using the 'AUTH SSL' command 991 Early implementations of the negotiated SSL upgrade, using the 992 AUTH command implemented it in a slightly different way that that 993 used in this document. 995 The parameter on the the AUTH command is 'SSL' and not 'TLS' and, 996 once the control connection is secured, the state of the data 997 connection is implicitly secure. This approach is in direct 998 disagreement with [RFC-2228] which requires the PROT command to be 999 issued and so should not be used in new implementations 1001 As a historical note, very early implementation of this approach 1002 issued and expected a '334' reply from the 'AUTH SSL' command. 1003 This should be contrasted to the '234' reply defined in this 1004 document. 1006 Full Copyright Statement 1008 Copyright (C) The Internet Society (2000). All Rights Reserved. 1010 This document and translations of it may be copied and furnished to 1011 others, and derivative works that comment on or otherwise explain it 1012 or assist in its implementation may be prepared, copied, published 1013 and distributed, in whole or in part, without restriction of any 1014 kind, provided that the above copyright notice and this paragraph are 1015 included on all such copies and derivative works. However, this 1016 document itself may not be modified in any way, such as by removing 1017 the copyright notice or references to the Internet Society or other 1018 Internet organizations, except as needed for the purpose of 1019 developing Internet standards in which case the procedures for 1020 copyrights defined in the Internet Standards process must be 1021 followed, or as required to translate it into languages other than 1022 English. 1024 The limited permissions granted above are perpetual and will not be 1025 revoked by the Internet Society or its successors or assigns. 1027 This document and the information contained herein is provided on an 1028 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1029 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1030 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1031 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1032 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1034 This document expires on 5th October, 2001