idnits 2.17.1 draft-murray-auth-ftp-ssl-04.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 25 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 26 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 196 has weird spacing: '...request on th...' -- 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 793, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1579 (ref. 'FTP-SOCKS') -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-DESC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRA-FTP' ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Martin Carpenter 2 IBM UK Ltd 3 Paul Ford-Hutchinson 4 Independent Security Consultant 5 Tim Hudson 6 INTERNET-DRAFT CryptSoft Pty Ltd 7 Eric Murray 8 Independent Security Consultant 9 27th August, 1998 10 This document expires on 27th February, 1999 12 Securing FTP with TLS 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or made obsolete by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as work in progress. 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 Index 33 1. .......... Abstract 34 2. .......... Introduction 35 3. .......... Audience 36 4. .......... Session negotiation on the control port 37 5. .......... Data Connection Behaviour 38 6. .......... Mechanisms for the AUTH Command 39 7. .......... SASL Considerations 40 8. .......... Data Connection Security 41 9. .......... A discussion of negotiation behaviour 42 10. ......... Who negotiates what, where and how 43 11. ......... Timing Diagrams 44 12. ......... Security Considerations 45 13. ......... IANA Considerations 46 14. ......... Network Management 47 15. ......... Internationalization 48 16. ......... Scalability & Limits 49 17. ......... Applicability 50 18. ......... Acknowledgements 51 19. ......... References 52 20. ......... Authors' Contact Addresses 53 Appendices 54 A. .......... Summary of [TLS-DESC] 55 B. .......... Summary of [CAT-FTPSEC] 57 1. Abstract 59 This document describes a mechanism that can be used by FTP clients 60 and servers to implement security and authentication using the TLS 61 protocol defined by the IETF TLS working group and the extensions to 62 the FTP protocol defined by the IETF CAT working group. It describes 63 the subset of the extensions that are required and the parameters to 64 be used; discusses some of the policy issues that clients and servers 65 will need to take; considers some of the implications of those 66 policies and discusses some expected behaviours of implementations to 67 allow interoperation. 69 TLS is not the only mechanism for securing file transfer, however it 70 does offer some of the following positive attributes:- 72 - Flexible security levels. TLS can support privacy, integrity, 73 authentication or some combination of all of these. This allows 74 clients and servers to dynamically, during a session, decide on 75 the level of security required for a particular data transfer, 77 - Formalised public key management. By use of X.509 public 78 certificates during the authentication phase, certificate 79 management can be built into a central function. Whilst this may 80 not be desirable for all uses of secured file transfer, it offers 81 advantages in certain structured environments such as access to 82 corporate data sources. 84 - Co-existence and interoperation with authentication mechanisms 85 that are already in place for the HTTPS protocol. This allows web 86 browsers to incorporate secure file transfer using the same 87 infrastructure that has been set up to allow secure web browsing. 89 The TLS protocol is a development of the Netscape Communication 90 Corporation's SSL protocol and this document can be used to allow the 91 FTP protocol to be used with either SSL or TLS. The actual protocol 92 used will be decided by the negotiation of the protected session by 93 the TLS/SSL layer. 95 Note that this specification is in accordance with the FTP RFC and 96 relies on the TLS protocol and the CAT FTP security extensions. 98 2. Introduction 100 This document is an attempt to describe how three other documents 101 should combined to provide a useful, interoperable, secure file 102 transfer protocol. Those documents are:- 103 RFC 959 [RFC-959] 105 The description of the Internet File Transfer Protocol 107 draft-ietf-tls-protocol-03.txt [TLS-DESC] 109 The description of the Transport Layer Security protocol 110 (developed from the Netscape Secure Sockets Layer (SSL) 111 protocol version 3.0). 113 draft-ietf-cat-ftpsec-09.txt [CAT-FTPSEC] 115 Extensions to the FTP protocol to allow negotiation of security 116 mechanisms to allow authentication, privacy and message 117 integrity. 119 The File Transfer Protocol (FTP) currently defined in [RFC-959] and 120 in place on the Internet is an excellent mechanism for exchanging 121 files. The security extensions to FTP in [CAT-FTPSEC] offer a 122 comprehensive set of commands and responses that can be used to add 123 authentication, integrity and privacy to the FTP protocol. The TLS 124 protocol is a popular (due to its wholesale adoption in the HTTP 125 environment) mechanism for generally securing a socket connection. 126 There are many ways in which these three protocols can be combined 127 which would ensure that interoperation is impossible. This document 128 describes one method by which FTP can operate securely in such a way 129 as to provide both flexibility and interoperation. This necessitates 130 a brief description of the actual negotiation mechanism (if used); a 131 much more detailed description of the policies and practices that 132 would be required and a discussion of the expected behaviours of 133 clients and servers to allow either party to impose their security 134 requirements on the FTP session. 136 3. Audience 138 This document is aimed at developers who wish to use TLS as a 139 security mechanism to secure FTP clients and/or servers. 141 4. Session negotiation on the control port 143 4.1 Negotiated Session Security 145 In this scenario, the server listens on the normal FTP control 146 port {FTP-PORT} and the session initiation is not secured at all. 147 Once the client wishes to secure the session, the AUTH command is 148 sent and the server may then allow TLS negotiation to take place. 150 4.1.1 Client wants a secured session 152 If a client wishes to attempt to secure a session then it 153 should, in accordance with [CAT-FTPSEC] send the AUTH command 154 with the parameter requesting TLS or SSL {TLS-PARM}. 156 The client then needs to behave according to its policies 157 depending on the response received from the server and also the 158 result of the TLS negotiation. 160 4.1.2 Server wants a secured session 162 The FTP protocol does not allow a server to directly dictate 163 client behaviour, however the same effect can be achieved by 164 refusing to accept certain FTP commands until the session is 165 secured to an acceptable level to the server. 167 4.2 Implicit Session Security 169 In this scenario, the server listens on a distinct port {FTP- 170 TLSPORT} to the normal unsecured FTP server. Upon connection, the 171 client is expected to start the TLS negotiation. If the 172 negotiation fails or succeeds at an unacceptable level of security 173 then it will be a client and/or server policy decision to 174 disconnect the session. 176 5. Data Connection Behaviour 178 The Data Connection in the FTP model can be used in one of three 179 ways. (Note: these descriptions are not necessarily placed in exact 180 chronological order, but do describe the steps required.) 182 i) Classic FTP client/server data exchange 184 - The client obtains a port, sends the port number to the 185 server, the server connects to the client. The client issues a 186 send or receive request to the server on the control connection 187 and the data transfer commences on the data connection. 189 ii) Firewall-Friendly client/server data exchange (as discussed 190 in [FTP-SOCKS]) using the PASV command to reverse the direction 191 of the data connection. 193 - The client requests that the server open a port, the server 194 obtains a port and returns it to the client. The client 195 connects to the server on this port. The client issues a send 196 or receive request on the control connection and the data 197 transfer commences on the data connection. 199 iii) Client initiated server/server data exchange (proxy or 200 PASV connections) 202 - The client requests that server A opens a port, server A 203 obtains a port and returns it to the client. The client sends 204 this port number to server B. Server B connects to server A. 205 The client sends a send or receive request to server A and the 206 complement to server B and the data transfer commences. In 207 this model server A is the proxy or PASV host and is a client 208 for the Data Connection to server B. 210 For i) and ii) the FTP client will be the TLS client and the FTP 211 server will be the TLS server. 213 That is to say, it does not matter which side initiates the 214 connection with a connect() call or which side reacts to the 215 connection via the accept() call, the FTP client as defined in [RFC- 216 959] is always the TLS client as defined in [TLS-DESC]. 218 In scenario iii) there is a problem in that neither server A nor 219 server B is the TLS client given the fact that an FTP server must act 220 as a TLS server for Firewall-Friendly FTP [FTP-SOCKS]. Thus this is 221 explicitly excluded in the security extensions document [CAT-FTPSEC], 222 and in this document. 224 6. Mechanisms for the AUTH Command 226 The AUTH command takes a single parameter to define the security 227 mechanism to be negotiated. As the SSL/TLS protocols self-negotiate 228 their levels there is no need to distinguish SSL vs TLS in the 229 application layer. The proposed mechanism name for negotiating 230 SSL/TLS will be the character string "TLS". This will allow the 231 client and server to negotiate SSL or TLS on the control connection 232 without altering the protection of the data channel. To protect the 233 data channel as well, the PBSZ, PROT command sequence should be used. 234 We call this "Explicit Data Channel Protection". 236 However, there are clients and servers that exist today which use the 237 string "SSL" to indicate that negotiation should take place on the 238 control connection and that the data connection should be implicitly 239 protected (i.e. the PBSZ 0, PROT P command sequence is not required 240 but the client and server will protect the data channel as if it 241 had). This is "Implicit Data Channel Protection" and is included 242 primarily for backward compatibility. 244 To allow for streamlining of the negotiation, whilst allowing the 245 "SSL" string to sink peacefully into disuse, the strings "TLS-P" and 246 "TLS-C" will also be defined. "TLS-C" will be a synonym for "TLS" 247 and "TLS-P" a synonym for "SSL". Thus we allow for strict compliance 248 with [CAT-FTPSEC] by use of "TLS" or "TLS-C" and a quicker (2 less 249 commands) and perhaps more sensible option "TLS-P" which will 250 implicitly secure the data connection at the same time as securing 251 the control connection. 253 Note: Regardless of the manner in which the data connection is 254 secured (either implicitly by use of "TLS-P", "SSL" or connection to 255 a well-known port for FTP protocol over TLS, or explicitly by use of 256 the PBSZ/PROT sequence) the data connection state may be modified by 257 the client issuing the PROT command with the new desired level of 258 data channel protection and the server replying in the affirmative. 259 This data channel protection negotiation can happen at any point in 260 the session (even straight after a PORT or PASV command) and as often 261 as is required. 263 See also Section 12, "IANA Considerations". 265 7. SASL Considerations 267 SASL is the Simple Authentication Security Layer. Currently, its 268 definition can be found in the internet draft [SASL]. This document 269 attempts to define the means by which a connection-based protocol may 270 identify and authenticate a client user to a server, with additional 271 optional negotiation of protection for the remainder of that session. 273 Unfortunately, the SASL paradigm does not fit in neatly with the 274 FTP-TLS protocol, mainly due to the fact that FTP uses two 275 (independent) connections, and under FTP-TLS these may be at 276 different (and possibly renegotiable) protection levels. 277 Consequently, it is envisaged that SASL will sit underneath TLS on 278 the control connection, and TLS (on both, either or neither 279 connection) will be used for privacy and integrity (with optional 280 authentication from TLS on either connection). 282 8. Data Connection Security 284 The Data Connection security level is determined by two factors. 286 1) The mechanism used to negotiate security on the control 287 connection will dictate the default (i.e. un-negotiated) security 288 level of the data port. 290 2) The PROT command, as specified in [CAT-FTPSEC] allows 291 client/server negotiation of the security level of the data 292 connection. Once a PROT command has been issued by the client and 293 accepted by the server, the security of subsequent data 294 connections should be at that level until another PROT command is 295 issued, the session ends, or the security of the session (via an 296 AUTH command) is re-negotiated). 298 Data Connection Security Negotiation (the PROT command) 300 Note: In line with [CAT-FTPSEC], there is no facility for securing 301 the Data connection with an insecure Control connection. 303 The command defined in [CAT-FTPSEC] to negotiate data connection 304 security is the PROT command. As defined there are four values 305 that the PROT command parameter can take. 307 "C" - Clear - neither Integrity nor Privacy 309 "S" - Safe - Integrity without Privacy 311 "E" - Confidential - Privacy without Integrity 313 "P" - Private - Integrity and Privacy 315 As TLS negotiation encompasses (and exceeds) the 316 Safe/Confidential/Private distinction, only Private (use TLS) and 317 Clear (don't use TLS) are used. 319 For TLS, the data connection can have one of two security levels. 321 1) Clear 323 2)Private 325 With "Clear" protection level, the data connection is made without 326 TLS at all. Thus the connection is unauthenticated and has no 327 privacy or integrity. This might be the desired behaviour for 328 servers sending file lists, pre-encrypted data or non-sensitive 329 data (e.g. for anonymous FTP servers). 331 If the data connection security level is 'Private' then a TLS 332 negotiation must take place, to the satisfaction of the Client and 333 Server prior to any data being transmitted over the connection. 334 The TLS layers of the Client and Server will be responsible for 335 negotiating the exact TLS Cipher Suites that will be used (and 336 thus the eventual security of the connection). 338 In addition, the PBSZ (protection buffer size) command, as 339 detailed in [CAT-FTPSEC], is compulsory prior to any PROT command. 340 This document also defines a data channel encapsulation mechanism 341 for protected data buffers. For FTP-TLS, which appears to the FTP 342 application as a streaming protection mechanism, this is not 343 required. Thus the PBSZ command must still be issued, but must 344 have a parameter of "0" to indicate that no buffering is taking 345 place and the data connection should not be encapsulated. 347 Initial Data Connection Security 349 For backward compatibility and ease of implementation the 350 following rules govern the initial expected protection setting of 351 the data connection. 353 Connections accepted on the 'secure FTP' port (see 354 {FTP-TLSPORT}). 355 The initial state of the data connection will be "Private" 356 (Although this does not follow [CAT-FTPSEC], this is how 357 such clients tend to work today). 359 Connections accepted on the normal FTP port {FTP-PORT} with 360 TLS/SSL negotiated via an "AUTH SSL" command. 361 The initial state of the data connection will be "Private" 362 (Although this does not follow [CAT-FTPSEC], this is how 363 such clients tend to work today). 365 Connections accepted on the normal FTP port {FTP-PORT} with 366 TLS/SSL negotiated via an "AUTH " command. 367 The initial state of the data connection will be "Clear" 368 (this is the correct behaviour as indicated by [CAT- 369 FTPSEC].) 371 Note: Connections made on other ports may be still behave in one 372 of these ways, but that will be a local configuration issue. 374 9. A Discussion of Negotiation Behaviour 376 All these discussions assume that the negotiation has taken place by 377 issuing the AUTH command with a mechanism that does not implicitly 378 protect the data channel. Using a mechanism which does implicitly 379 secure the data channel or connecting to a port which is implicitly 380 protected will have similar issues. 382 9.1. The server's view of the control connection 384 A server may have a policy statement somewhere that might: 386 - Deny any command before TLS is negotiated (this might cause 387 problems if a SITE or some such command is required prior to 388 login) 389 - Deny certain commands before TLS is negotiated (such as USER, 390 PASS or ACCT) 391 - Deny insecure USER commands for certain users (e.g. not 392 ftp/anonymous) 393 - Deny secure USER commands for certain users (e.g. 394 ftp/anonymous) 395 - Define the level(s) of TLS/SSL to be allowed 396 - Define the CipherSuites allowed to be used (perhaps on a per 397 host/domain/... basis) 398 - Allow TLS authentication as a substitute for local 399 authentication. 400 - Define data connection policies (see next section) 402 Note: The TLS negotiation may not be completed satisfactorily 403 for the server, in which case it can be one of these states. 405 The TLS negotiation failed completely 407 In this case, the control connection should still be up in 408 unprotected mode and the server should issue an unprotected 421 409 reply to end the session. 411 The TLS negotiation completed successfully, but the server 412 decides that the session parameters are not acceptable (e.g. 413 Distinguished Name in the client certificate is not 414 permitted to use the server) 416 In this case, the control connection should still be up in a 417 protected state, so the server can either continue to refuse to 418 service commands or issue a 421 reply and close the connection. 420 The TLS negotiation failed during the TLS handshake 422 In this case, the control connection is in an unknown state and 423 the server should simply drop the control connection. 425 Server code will be responsible for implementing the required 426 policies and ensuring that the client is prevented from 427 circumventing the chosen security by refusing to service those 428 commands that are against policy. 430 9.2. The server's view of the data connection 432 The server can take one of four basic views of the data connection 434 1 - Don't allow encryption at all (in which case the PROT 435 command should not allow any value other than 'C' - if it is 436 allowed at all) 437 2 - Allow the client to choose protection or not 438 3 - Insist on data protection (in which case the PROT command 439 must be issued prior to the first attempted data transfer) 440 4 - Decide on one of the above three for each and every data 441 connection 443 The server should only check the status of the data protection 444 level (for options 3 and 4 above) on the actual command that will 445 initiate the data transfer (and not on the PORT or PASV). The 446 following commands cause data connections to be opened and thus 447 may be rejected (before any 1xx) message due to an incorrect PROT 448 setting. 450 STOR 451 RETR 452 NLST 453 LIST 454 STOU 455 APPE 457 The reply to indicate that the PROT setting is incorrect is "521 458 data connection cannot be opened with this PROT setting" 459 If the protection level indicates that TLS is required, then it 460 should be negotiated once the data connection is made. Thus, the 461 150 reply only states that the command can be used given the 462 current PROT level. Should the server not like the TLS 463 negotiation then it will close the data port immediately and 464 follow the 150 command with a 522 reply indicating that the TLS 465 negotiation failed or was unacceptable. (Note: this means that 466 the application can pass a standard list of CipherSuites to the 467 TLS layer for negotiation and review the one negotiated for 468 applicability in each instance). 470 It is quite reasonable for the server to insist that the data 471 connection uses a TLS cached session. This might be a cache of a 472 previous data connection or of the control connection. If this is 473 the reason for the the refusal to allow the data transfer then the 474 522 reply should indicate this. 475 Note: this has an important impact on client design, but allows 476 servers to minimise the cycles used during TLS negotiation by 477 refusing to perform a full negotiation with a previously 478 authenticated client. 480 It should be noted that the TLS authentication of the server will 481 be authentication of the server host itself and not a user on the 482 server host. 484 9.3. The client's view of the control connection 486 In most cases it is likely that the client will be using TLS 487 because the server would refuse to interact insecurely. To allow 488 for this, clients must be able to be flexible enough to manage the 489 securing of a session at the appropriate time and still allow the 490 user/server policies to dictate exactly when in the session the 491 security is negotiated. 493 In the case where it is the client that is insisting on the 494 securing of the session, it will need to ensure that the 495 negotiations are all completed satisfactorily and will need to be 496 able to inform the user sensibly should the server not support, or 497 be prepared to use, the required security levels. 499 Clients must be coded in such a manner as to allow the timing of 500 the AUTH, PBSZ and PROT commands to be flexible and dictated by 501 the server. It is quite reasonable for a server to refuse certain 502 commands prior to these commands, similarly it is quite possible 503 that a SITE or quoted command might be needed by a server prior to 504 the AUTH. A client must allow a user to override the timing of 505 these commands to suit a specific server. 506 For example, a client should not insist on sending the AUTH as the 507 first command in a session, nor should it insist on issuing a 508 PBSZ, PROT pair directly after the AUTH. This may well be the 509 default behaviour, but must be overridable by a user. 511 Note: The TLS negotiation may not be completed satisfactorily for 512 the client, in which case it will be in one of these states: 514 The TLS negotiation failed completely 516 In this case, the control connection should still be up in 517 unprotected mode and the client should issue an unprotected 518 QUIT command to end the session. 520 The TLS negotiation completed successfully, but the client 521 decides that the session parameters are not acceptable (e.g. 522 Distinguished Name in certificate is not the actual server 523 expected) 524 In this case, the control connection should still be up in a 525 protected state, so the client should issue a protected QUIT 526 command to end the session. 528 The TLS negotiation failed during the TLS handshake 530 In this case, the control connection is in an unknown state 531 and the client should simply drop the control connection. 533 9.4. The client's view of the data connection 535 Client security policies 537 Clients do not typically have 'policies' as such, instead they 538 rely on the user defining their actions and, to a certain extent, 539 are reactive to the server policy. Thus a client will need to 540 have commands that will allow the user to switch the protection 541 level of the data connection dynamically, however, there may be a 542 general 'policy' that attempts all LIST and NLST commands on a 543 Clear connection first (and automatically switches to Private if 544 it fails). In this case there would need to be a user command 545 available to ensure that a given data transfer was not attempted 546 on an insecure data connection. 548 Clients also need to understand that the level of the PROT setting 549 is only checked for a particular data transfer after that transfer 550 has been requested. Thus a refusal by the server to accept a 551 particular data transfer should not be read by the client as a 552 refusal to accept that data protection level in toto, as not only 553 may other data transfers be acceptable at that protection level, 554 but it is entirely possible that the same transfer may be accepted 555 at the same protection level at a later point in the session. 557 It should be noted that the TLS authentication of the client 558 should be authentication of a user on the client host and not the 559 client host itself. 561 10. Who negotiates what, where and how 563 10.1. Do we protect at all ? 565 Client issues AUTH , server accepts or rejects. 566 If server needs AUTH, then it refuses to accept certain commands 567 until it gets a successfully protected session. 569 10.2. What level of protection do we use ? 571 Decided entirely by the TLS CipherSuite negotiation. 573 10.3. Do we protect data connections in general ? 575 Client issues PROT command, server accepts or rejects. 577 10.4. Is protection required for a particular data transfer ? 579 A client would already have issued a PROT command if it required 580 the connection to be protected. 581 If a server needs to have the connection protected then it will 582 reply to the STOR/RETR/NLST/... command with a 522 indicating that 583 the current state of the data connection protection level is not 584 sufficient for that data transfer at that time. 586 10.5. What level of protection is required for a particular data 587 transfer ? 589 Decided entirely by the TLS CipherSuite negotiation. 591 Thus it can be seen that, for flexibility, it is desirable for the 592 FTP application to be able to interact with the TLS layer upon which 593 it sits to define and discover the exact TLS CipherSuites that are to 594 be/have been negotiated and make decisions accordingly. However it 595 should be entirely possible, using the mechanisms described in this 596 document, to have a TLS client or server sitting on top of a generic 597 'TLS socket layer'. In this case, interoperability for a client with 598 a smart TLS-aware server may not be possible due to server policies. 600 11. Timing Diagrams 602 11.1. Establishing a protected session 604 Client Server 605 control data data control 606 ==================================================================== 608 socket() 609 bind() 610 socket() 611 connect() ----------------------------------------------> accept() 612 AUTH TLS ----------------------------------------------> 613 <---------------------------------------------- 234 614 TLSneg() <----------------------------------------------> TLSneg() 615 PBSZ 0 ----------------------------------------------> 616 <---------------------------------------------- 200 617 PROT P ----------------------------------------------> 618 <---------------------------------------------- 200 619 USER fred ----------------------------------------------> 620 <---------------------------------------------- 331 621 PASS pass ----------------------------------------------> 622 <---------------------------------------------- 230 624 Note: the order of the PBSZ/PROT pair and the USER/PASS pair (with 625 respect to each other) is not important (i.e. the USER/PASS can happen 626 prior to the PBSZ/PROT - or indeed the server can refuse to allow a 627 PBSZ/PROT pair until the USER/PASS pair has happened). 629 11.2. A standard data transfer without protection. 631 Client Server 632 control data data control 633 ==================================================================== 635 socket() 636 bind() 637 PORT w,x,y,z,a,b -----------------------------------------> 638 <----------------------------------------------------- 200 639 STOR file ------------------------------------------------> 640 socket() 641 bind() 642 <----------------------------------------------------- 150 643 accept() <----------- connect() 644 write() -----------> read() 645 close() -----------> close() 646 <----------------------------------------------------- 226 648 11.3. A firewall-friendly data transfer without protection 650 Client Server 651 control data data control 652 ==================================================================== 654 PASV --------------------------------------------------------> 655 socket() 656 bind() 657 <------------------------------------------ 227 (w,x,y,z,a,b) 658 socket() 659 STOR file ---------------------------------------------------> 660 connect() ----------> accept() 661 <-------------------------------------------------------- 150 662 write() ----------> read() 663 close() ----------> close() 664 <-------------------------------------------------------- 226 666 Note: Implementors should be aware that then connect()/accept() 667 function is performed prior to the receipt of the reply from the 668 STOR command. This contrasts with situation when (non-firewall- 669 friendly) PORT is used prior to the STOR, and the accept()/connect() 670 is performed after the reply from the aforementioned STOR has been 671 dealt with. 673 11.4. A standard data transfer with protection 675 Client Server 676 control data data control 677 ==================================================================== 679 socket() 680 bind() 681 PORT w,x,y,z,a,b --------------------------------------------> 682 <-------------------------------------------------------- 200 683 STOR file ---------------------------------------------------> 684 socket() 685 bind() 686 <-------------------------------------------------------- 150 687 accept() <---------- connect() 688 TLSneg() <----------> TLSneg() 689 TLSwrite() ----------> TLSread() 690 close() ----------> close() 691 <-------------------------------------------------------- 226 693 11.5. A firewall-friendly data transfer with protection 695 Client Server 696 control data data control 697 ==================================================================== 699 PASV --------------------------------------------------------> 700 socket() 701 bind() 702 <------------------------------------------ 227 (w,x,y,z,a,b) 703 socket() 704 STOR file ---------------------------------------------------> 705 connect() ----------> accept() 706 <-------------------------------------------------------- 150 707 TLSneg() <---------> TLSneg() 708 TLSwrite() ---------> TLSread() 709 close() ---------> close() 710 <-------------------------------------------------------- 226 712 12. Security Considerations 714 This entire document deals with security considerations related to 715 the File Transfer Protocol. 717 13. IANA Considerations 719 {FTP-PORT} - The port assigned to the FTP control connection is 21. 721 {FTP-TLSPORT} - A port to be assigned by the IANA for native TLS FTP 722 connections on the control socket. This has been provisionally 723 reserved as port 990. 725 {TLS-PARM} - A parameter for the AUTH command to indicate that TLS is 726 required. It is recommended that "TLS", "TLS-C", "SSL" and "TLS-P" 727 (all uppercase only) are acceptable, and mean the following :- 729 "TLS" or "TLS-C" - the TLS protocol or the SSL protocol will be 730 negotiated on the control connection. The default protection 731 setting for the Data connection is "Clear". 733 "SSL" or "TLS-P" - the TLS protocol or the SSL protocol will be 734 negotiated on the control connection. The default protection 735 setting for the Data connection is "Private". 737 14. Network Management 739 NONE 741 15. Internationalization 743 NONE 745 16. Scalability & Limits 747 There are no issues other than those concerned with the ability of 748 the server to refuse to have a complete TLS negotiation for each and 749 every data connection, which will allow servers to retain throughput 750 whilst using cycles only when necessary. 752 17. Applicability 754 This mechanism is generally applicable as a mechanism for securing 755 the FTP protocol. It is unlikely that anonymous FTP clients or 756 servers will require such security (although some might like the 757 authentication features without the privacy). 759 18. Acknowledgements 761 o Netscape Communications Corporation for the original SSL protocol. 763 o Eric Young for the SSLeay libraries. 765 o University of California, Berkley for the original implementations 766 of FTP and ftpd on which the initial implementation of these 767 extensions were layered. 769 o IETF CAT working group. 771 o IETF TLS working group. 773 o IETF FTPEXT working group. 775 19. References 777 [FTP-SOCKS] Bellovin, S., "Firewall-Friendly FTP" 778 RFC 1579, February 1994. 780 [TLS-DESC] A description of the TLS protocol. 781 TLS (Transport Layer Security) is the IETF version of and 782 enhancement to the Netscape SSL protocol. TLS is highly backwards 783 compatible with SSL and discussions in this document are relevant 784 to all versions of TLS and SSL. The current version of TLS is 785 described in 787 T. Dierks, C. Allen, "The TLS Protocol Version 1.0" 788 draft-ietf-tls-protocol-05.txt. 790 [RFC-959] J. Postel, "File Transfer Protocol" 791 RFC 959, October 1985. 793 [SRA-FTP] "SRA - Secure RPC Authentication for TELNET and FTP Version 794 1.1" 795 file://ftp.funet.fi/security/login/telnet/doc/sra/sra.README 797 [CAT-FTPSEC] M. Horowitz, S. Lunt, "FTP Security Extensions" 798 RFC 2228, October 1997. 800 [SASL] J. Myers, "Simple Authentication and Security Layer" 801 RFC 2222, October 1997. 803 20. Authors' Contact Addresses 805 Tim Hudson Martin Carpenter 806 CryptSoft Pty Ltd IBM UK Ltd 807 PO Box 6324 PO Box 31 808 Fairfield 4103 Birmingham Road 809 Queensland Warwick 810 Australia United Kingdom 811 tel - +61 7 32781581 +44 1926 464834 812 fax - +44 1926 496482 813 email - tjh@cryptsoft.com mjc@uk.ibm.com 815 Paul Ford-Hutchinson Eric Murray 816 Rich Reeve Ltd LNE Consulting 817 tel - +61 7 32781581 818 fax - 819 email - pfh@dial.pipex.com ericm@lne.com 820 Appendices 822 A. Summary of [TLS-DESC] 824 The TLS protocol is developed by the IETF TLS working group. It is 825 based on the SSL protocol proposed by Netscape Communications 826 Corporation. The structure of the start of a TLS session allows 827 negotiation of the level of the protocol to be used - in this way, a 828 client or server can simultaneously support TLS and SSL and negotiate 829 the most appropriate for the connection. 831 The TLS protocol defines three security mechanisms that may be used 832 (almost) independently. They are Authentication, Integrity and 833 Privacy. It is possible to have an Authenticated session with no 834 Privacy and with or without Integrity (useful for anonymous FTP 835 sites, or sites with pre-encrypted data). For example, sessions with 836 Authentication, Privacy and Integrity would be useful for control 837 connections over an insecure network and data connections 838 transferring confidential material. 840 The TLS protocol allows unauthenticated sessions; server 841 authentication or client and server authentication. There is no 842 mechanism for authenticating a client without first authenticating 843 the server. 845 The basic mechanism of the TLS protocol is that (for an 846 Authenticated, Private session) asymmetric encryption is used to 847 authenticate clients and servers and exchange a session key for 848 symmetric encryption which is to be used for the rest of the session. 850 The structure of the TLS session initialisation is that the client 851 initiates the session with a "ClientHello" message. The server will 852 respond with a "ServerHello" and the session negotiation will 853 continue. 855 The TLS protocol allows session caching which is achieved by the 856 client requesting that the server re-use a session context (Cipher 857 Suite and symmetric key) in the ClientHello message. There is no 858 reason why a second connection could not request a 'cached' session 859 with the same context as an existing session. 861 B. Summary of [CAT-FTPSEC] 863 Extensions to FTP 865 The FTP Security Extensions document has 8 new commands to enhance 866 the FTP protocol to allow negotiation of security and exchange of 867 security data. Three of these commands (the AUTH, PBSZ and PROT 868 commands) are used by this document to allow an FTP client to 869 negotiate TLS with the server. The other commands are not required. 871 i) AUTH 873 This command is a request by the client to use an authentication 874 and/or security mechanism. 876 The client will issue an "AUTH " command which will be 877 a request to the server to secure the control connection using the 878 TLS (or SSL) protocol. It also governs the initial protection 879 setting of the data channel (which may be changed by a subsequent 880 PROT command). 882 ii) ADAT 884 This command is used to transmit security data required by the 885 security mechanism agreed in a preceding AUTH command. 886 This document does not use the ADAT command. 888 iii) PROT 890 This command is used by the client to instruct the type of 891 security that is required on the Data connection. 893 The "PROT C" command will mean that TLS should not be used to 894 secure the data connection; "PROT P" means that TLS should be 895 used. "PROT E" and "PROT S" are not defined and generate a 536 896 reply from the server. 898 iv) PBSZ 900 This command is used to negotiate the size of the buffer to be 901 used during secured data transfer. 903 The PBSZ command must be issued prior to the PROT command. The 904 PBSZ command cannot be sent on an insecure control connection. 905 For FTP and TLS the only valid value for the parameter is "0", all 906 other values should receive a 200 reply with the text "PBSZ=0" 907 included. 909 v) CCC 911 This command is used to specify that the control channel no longer 912 requires protection. 913 This document does not use the CCC command. 915 vi) MIC 917 This command is used to send a normal FTP command with integrity 918 protection. 919 This document does not use the MIC command. 921 vii) CONF 923 This command is used to send a normal FTP command with 924 confidentiality protection (encrypted). 925 This document does not use the CONF command. 927 viii) ENC 929 This command is used to send a normal FTP command with 930 confidentiality and integrity protection. 931 This document does not use the ENC command. 933 This document expires on 27th February, 1999