idnits 2.17.1 draft-ietf-cat-ftpsec-09.txt: 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-26) 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 21 longer pages, the longest (page 2) being 61 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC959, but the abstract doesn't seem to directly say this. It does mention RFC959 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TELNET-SEC' ** Downref: Normative reference to an Historic RFC: RFC 1421 Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Horowitz 2 Cygnus Solutions 3 Updates: RFC 959 S. J. Lunt 4 Internet-Draft Bellcore 5 Expire in six months November, 1996 7 FTP Security Extensions 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. Please send comments to the 28 mailing list. 30 Abstract 32 This document defines extensions to the FTP specification RFC 959, 33 "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions 34 provide strong authentication, integrity, and confidentiality on both 35 the control and data channels with the introduction of new optional 36 commands, replies, and file transfer encodings. 38 The following new optional commands are introduced in this 39 specification: 41 AUTH (Authentication/Security Mechanism), 42 ADAT (Authentication/Security Data), 43 PROT (Data Channel Protection Level), 44 PBSZ (Protection Buffer Size), 45 CCC (Clear Command Channel), 46 MIC (Integrity Protected Command), 47 CONF (Confidentiality Protected Command), and 48 ENC (Privacy Protected Command). 50 A new class of reply types (6yz) is also introduced for protected 51 replies. 53 None of the above commands are required to be implemented, but 54 interdependencies exist. These dependencies are documented with the 55 commands. 57 Note that this specification is compatible with RFC 959. 59 1. Introduction 61 The File Transfer Protocol (FTP) currently defined in RFC 959 and in 62 place on the Internet uses usernames and passwords passed in 63 cleartext to authenticate clients to servers (via the USER and PASS 64 commands). Except for services such as 'anonymous' FTP archives, 65 this represents a security risk whereby passwords can be stolen 66 through monitoring of local and wide-area networks. This either aids 67 potential attackers through password exposure and/or limits 68 accessibility of files by FTP servers who cannot or will not accept 69 the inherent security risks. 71 Aside from the problem of authenticating users in a secure manner, 72 there is also the problem of authenticating servers, protecting 73 sensitive data and/or verifying its integrity. An attacker may be 74 able to access valuable or sensitive data merely by monitoring a 75 network, or through active means may be able to delete or modify the 76 data being transferred so as to corrupt its integrity. An active 77 attacker may also initiate spurious file transfers to and from a site 78 of the attacker's choice, and may invoke other commands on the 79 server. FTP does not currently have any provision for the encryption 80 or verification of the authenticity of commands, replies, or 81 transferred data. Note that these security services have value even 82 to anonymous file access. 84 Current practice for sending files securely is generally either: 86 1. via FTP of files pre-encrypted under keys which are manually 87 distributed, 89 2. via electronic mail containing an encoding of a file encrypted 90 under keys which are manually distributed, 92 3. via a PEM message, or 94 4. via the rcp command enhanced to use Kerberos. 96 None of these means could be considered even a de facto standard, and 97 none are truly interactive. A need exists to securely transfer files 98 using FTP in a secure manner which is supported within the FTP 99 protocol in a consistent manner and which takes advantage of existing 100 security infrastructure and technology. Extensions are necessary to 101 the FTP specification if these security services are to be introduced 102 into the protocol in an interoperable way. 104 Although the FTP control connection follows the Telnet protocol, and 105 Telnet has defined an authentication and encryption option [TELNET- 106 SEC], [RFC-1123] explicitly forbids the use of Telnet option 107 negotiation over the control connection (other than Synch and IP). 109 Also, the Telnet authentication and encryption option does not 110 provide for integrity protection only (without confidentiality), and 111 does not address the protection of the data channel. 113 2. FTP Security Overview 115 At the highest level, the FTP security extensions seek to provide an 116 abstract mechanism for authenticating and/or authorizing connections, 117 and integrity and/or confidentiality protecting commands, replies, 118 and data transfers. 120 In the context of FTP security, authentication is the establishment 121 of a client's identity and/or a server's identity in a secure way, 122 usually using cryptographic techniques. The basic FTP protocol does 123 not have a concept of authentication. 125 Authorization is the process of validating a user for login. The 126 basic authorization process involves the USER, PASS, and ACCT 127 commands. With the FTP security extensions, authentication 128 established using a security mechanism may also be used to make the 129 authorization decision. 131 Without the security extensions, authentication of the client, as 132 this term is usually understood, never happens. FTP authorization is 133 accomplished with a password, passed on the network in the clear as 134 the argument to the PASS command. The possessor of this password is 135 assumed to be authorized to transfer files as the user named in the 136 USER command, but the identity of the client is never securely 137 established. 139 An FTP security interaction begins with a client telling the server 140 what security mechanism it wants to use with the AUTH command. The 141 server will either accept this mechanism, reject this mechanism, or, 142 in the case of a server which does not implement the security 143 extensions, reject the command completely. The client may try 144 multiple security mechanisms until it requests one which the server 145 accepts. This allows a rudimentary form of negotiation to take 146 place. (If more complex negotiation is desired, this may be 147 implemented as a security mechanism.) The server's reply will 148 indicate if the client must respond with additional data for the 149 security mechanism to interpret. If none is needed, this will 150 usually mean that the mechanism is one where the password (specified 151 by the PASS command) is to be interpreted differently, such as with a 152 token or one-time password system. 154 If the server requires additional security information, then the 155 client and server will enter into a security data exchange. The 156 client will send an ADAT command containing the first block of 157 security data. The server's reply will indicate if the data exchange 158 is complete, if there was an error, or if more data is needed. The 159 server's reply can optionally contain security data for the client to 160 interpret. If more data is needed, the client will send another ADAT 161 command containing the next block of data, and await the server's 162 reply. This exchange can continue as many times as necessary. Once 163 this exchange completes, the client and server have established a 164 security association. This security association may include 165 authentication (client, server, or mutual) and keying information for 166 integrity and/or confidentiality, depending on the mechanism in use. 168 The term ``security data'' here is carefully chosen. The purpose of 169 the security data exchange is to establish a security association, 170 which might not actually include any authentication at all, between 171 the client and the server as described above. For instance, a 172 Diffie-Hellman exchange establishes a secret key, but no 173 authentication takes place. If an FTP server has an RSA key pair but 174 the client does not, then the client can authenticate the server, but 175 the server cannot authenticate the client. 177 Once a security association is established, authentication which is a 178 part of this association may be used instead of or in addition to the 179 standard username/password exchange for authorizing a user to connect 180 to the server. A username specified by the USER command is always 181 required to specify the identity to be used on the server. 183 In order to prevent an attacker from inserting or deleting commands 184 on the control stream, if the security association supports 185 integrity, then the server and client must use integrity protection 186 on the control stream, unless it first transmits a CCC command to 187 turn off this requirement. Integrity protection is performed with 188 the MIC and ENC commands, and the 63z reply codes. The CCC command 189 and its reply must be transmitted with integrity protection. 190 Commands and replies may be transmitted without integrity (that is, 191 in the clear or with confidentiality only) only if no security 192 association is established, the negotiated security association does 193 not support integrity, or the CCC command has succeeded. 195 Once the client and server have negotiated with the PBSZ command an 196 acceptable buffer size for encapsulating protected data over the data 197 channel, the security mechanism may also be used to protect data 198 channel transfers. 200 Policy is not specified by this document. In particular, client and 201 server implementations may choose to implement restrictions on what 202 operations can be performed depending on the security association 203 which exists. For example, a server may require that a client 204 authorize via a security mechanism rather than using a password, 205 require that the client provide a one-time password from a token, 206 require at least integrity protection on the command channel, or 207 require that certain files only be transmitted encrypted. An 208 anonymous ftp client might refuse to do file transfers without 209 integrity protection in order to insure the validity of files 210 downloaded. 212 No particular set of functionality is required, except as 213 dependencies described in the next section. This means that none of 214 authentication, integrity, or confidentiality are required of an 215 implementation, although a mechanism which does none of these is not 216 of much use. For example, it is acceptable for a mechanism to 217 implement only integrity protection, one-way authentication and/or 218 encryption, encryption without any authentication or integrity 219 protection, or any other subset of functionality if policy or 220 technical considerations make this desirable. Of course, one peer 221 might require as a matter of policy stronger protection than the 222 other is able to provide, preventing perfect interoperability. 224 3. New FTP Commands 226 The following commands are optional, but dependent on each other. 227 They are extensions to the FTP Access Control Commands. 229 The reply codes documented here are generally described as 230 recommended, rather than required. The intent is that reply codes 231 describing the full range of success and failure modes exist, but 232 that servers be allowed to limit information presented to the client. 233 For example, a server might implement a particular security 234 mechanism, but have a policy restriction against using it. The 235 server should respond with a 534 reply code in this case, but may 236 respond with a 504 reply code if it does not wish to divulge that the 237 disallowed mechanism is supported. If the server does choose to use 238 a different reply code than the recommended one, it should try to use 239 a reply code which only differs in the last digit. In all cases, the 240 server must use a reply code which is documented as returnable from 241 the command received, and this reply code must begin with the same 242 digit as the recommended reply code for the situation. 244 AUTHENTICATION/SECURITY MECHANISM (AUTH) 246 The argument field is a Telnet string identifying a supported 247 mechanism. This string is case-insensitive. Values must be 248 registered with the IANA, except that values beginning with "X-" 249 are reserved for local use. 251 If the server does not recognize the AUTH command, it must respond 252 with reply code 500. This is intended to encompass the large 253 deployed base of non-security-aware ftp servers, which will 254 respond with reply code 500 to any unrecognized command. If the 255 server does recognize the AUTH command but does not implement the 256 security extensions, it should respond with reply code 502. 258 If the server does not understand the named security mechanism, it 259 should respond with reply code 504. 261 If the server is not willing to accept the named security 262 mechanism, it should respond with reply code 534. 264 If the server is not able to accept the named security mechanism, 265 such as if a required resource is unavailable, it should respond 266 with reply code 431. 268 If the server is willing to accept the named security mechanism, 269 but requires security data, it must respond with reply code 334. 271 If the server is willing to accept the named security mechanism, 272 and does not require any security data, it must respond with reply 273 code 234. 275 If the server is responding with a 334 reply code, it may include 276 security data as described in the next section. 278 Some servers will allow the AUTH command to be reissued in order 279 to establish new authentication. The AUTH command, if accepted, 280 removes any state associated with prior FTP Security commands. 281 The server must also require that the user reauthorize (that is, 282 reissue some or all of the USER, PASS, and ACCT commands) in this 283 case (see section 4 for an explanation of "authorize" in this 284 context). 286 AUTHENTICATION/SECURITY DATA (ADAT) 288 The argument field is a Telnet string representing base 64 encoded 289 security data (see Section 9, "Base 64 Encoding"). If a reply 290 code indicating success is returned, the server may also use a 291 string of the form "ADAT=base64data" as the text part of the reply 292 if it wishes to convey security data back to the client. 294 The data in both cases is specific to the security mechanism 295 specified by the previous AUTH command. The ADAT command, and the 296 associated replies, allow the client and server to conduct an 297 arbitrary security protocol. The security data exchange must 298 include enough information for both peers to be aware of which 299 optional features are available. For example, if the client does 300 not support data encryption, the server must be made aware of 301 this, so it will know not to send encrypted command channel 302 replies. It is strongly recommended that the security mechanism 303 provide sequencing on the command channel, to insure that commands 304 are not deleted, reordered, or replayed. 306 The ADAT command must be preceded by a successful AUTH command, 307 and cannot be issued once a security data exchange completes 308 (successfully or unsuccessfully), unless it is preceded by an AUTH 309 command to reset the security state. 311 If the server has not yet received an AUTH command, or if a prior 312 security data exchange completed, but the security state has not 313 been reset with an AUTH command, it should respond with reply code 314 503. 316 If the server cannot base 64 decode the argument, it should 317 respond with reply code 501. 319 If the server rejects the security data (if a checksum fails, for 320 instance), it should respond with reply code 535. 322 If the server accepts the security data, and requires additional 323 data, it should respond with reply code 335. 325 If the server accepts the security data, but does not require any 326 additional data (i.e., the security data exchange has completed 327 successfully), it must respond with reply code 235. 329 If the server is responding with a 235 or 335 reply code, then it 330 may include security data in the text part of the reply as 331 specified above. 333 If the ADAT command returns an error, the security data exchange 334 will fail, and the client must reset its internal security state. 335 If the client becomes unsynchronized with the server (for example, 336 the server sends a 234 reply code to an AUTH command, but the 337 client has more data to transmit), then the client must reset the 338 server's security state. 340 PROTECTION BUFFER SIZE (PBSZ) 342 The argument is a decimal integer representing the maximum size, 343 in bytes, of the encoded data blocks to be sent or received during 344 file transfer. This number shall be no greater than can be 345 represented in a 32-bit unsigned integer. 347 This command allows the FTP client and server to negotiate a 348 maximum protected buffer size for the connection. There is no 349 default size; the client must issue a PBSZ command before it can 350 issue the first PROT command. 352 The PBSZ command must be preceded by a successful security data 353 exchange. 355 If the server cannot parse the argument, or if it will not fit in 356 32 bits, it should respond with a 501 reply code. 358 If the server has not completed a security data exchange with the 359 client, it should respond with a 503 reply code. 361 Otherwise, the server must reply with a 200 reply code. If the 362 size provided by the client is too large for the server, it must 363 use a string of the form "PBSZ=number" in the text part of the 364 reply to indicate a smaller buffer size. The client and the 365 server must use the smaller of the two buffer sizes if both buffer 366 sizes are specified. 368 DATA CHANNEL PROTECTION LEVEL (PROT) 370 The argument is a single Telnet character code specifying the data 371 channel protection level. 373 This command indicates to the server what type of data channel 374 protection the client and server will be using. The following 375 codes are assigned: 377 C - Clear 378 S - Safe 379 E - Confidential 380 P - Private 382 The default protection level if no other level is specified is 383 Clear. The Clear protection level indicates that the data channel 384 will carry the raw data of the file transfer, with no security 385 applied. The Safe protection level indicates that the data will 386 be integrity protected. The Confidential protection level 387 indicates that the data will be confidentiality protected. The 388 Private protection level indicates that the data will be integrity 389 and confidentiality protected. 391 It is reasonable for a security mechanism not to provide all data 392 channel protection levels. It is also reasonable for a mechanism 393 to provide more protection at a level than is required (for 394 instance, a mechanism might provide Confidential protection, but 395 include integrity-protection in that encoding, due to API or other 396 considerations). 398 The PROT command must be preceded by a successful protection 399 buffer size negotiation. 401 If the server does not understand the specified protection level, 402 it should respond with reply code 504. 404 If the current security mechanism does not support the specified 405 protection level, the server should respond with reply code 536. 407 If the server has not completed a protection buffer size 408 negotiation with the client, it should respond with a 503 reply 409 code. 411 The PROT command will be rejected and the server should reply 503 412 if no previous PBSZ command was issued. 414 If the server is not willing to accept the specified protection 415 level, it should respond with reply code 534. 417 If the server is not able to accept the specified protection 418 level, such as if a required resource is unavailable, it should 419 respond with reply code 431. 421 Otherwise, the server must reply with a 200 reply code to indicate 422 that the specified protection level is accepted. 424 CLEAR COMMAND CHANNEL (CCC) 426 This command does not take an argument. 428 It is desirable in some environments to use a security mechanism 429 to authenticate and/or authorize the client and server, but not to 430 perform any integrity checking on the subsequent commands. This 431 might be used in an environment where IP security is in place, 432 insuring that the hosts are authenticated and that TCP streams 433 cannot be tampered, but where user authentication is desired. 435 If unprotected commands are allowed on any connection, then an 436 attacker could insert a command on the control stream, and the 437 server would have no way to know that it was invalid. In order to 438 prevent such attacks, once a security data exchange completes 439 successfully, if the security mechanism supports integrity, then 440 integrity (via the MIC or ENC command, and 631 or 632 reply) must 441 be used, until the CCC command is issued to enable non-integrity 442 protected control channel messages. The CCC command itself must 443 be integrity protected. 445 Once the CCC command completes successfully, if a command is not 446 protected, then the reply to that command must also not be 447 protected. This is to support interoperability with clients which 448 do not support protection once the CCC command has been issued. 450 This command must be preceded by a successful security data 451 exchange. 453 If the command is not integrity-protected, the server must respond 454 with a 533 reply code. 456 If the server is not willing to turn off the integrity 457 requirement, it should respond with a 534 reply code. 459 Otherwise, the server must reply with a 200 reply code to indicate 460 that unprotected commands and replies may now be used on the 461 command channel. 463 INTEGRITY PROTECTED COMMAND (MIC) and 464 CONFIDENTIALITY PROTECTED COMMAND (CONF) and 465 PRIVACY PROTECTED COMMAND (ENC) 467 The argument field of MIC is a Telnet string consisting of a base 468 64 encoded "safe" message produced by a security mechanism 469 specific message integrity procedure. The argument field of CONF 470 is a Telnet string consisting of a base 64 encoded "confidential" 471 message produced by a security mechanism specific confidentiality 472 procedure. The argument field of ENC is a Telnet string 473 consisting of a base 64 encoded "private" message produced by a 474 security mechanism specific message integrity and confidentiality 475 procedure. 477 The server will decode and/or verify the encoded message. 479 This command must be preceded by a successful security data 480 exchange. 482 A server may require that the first command after a successful 483 security data exchange be CCC, and not implement the protection 484 commands at all. In this case, the server should respond with a 485 502 reply code. 487 If the server cannot base 64 decode the argument, it should 488 respond with a 501 reply code. 490 If the server has not completed a security data exchange with the 491 client, it should respond with a 503 reply code. 493 If the server has completed a security data exchange with the 494 client using a mechanism which supports integrity, and requires a 495 CCC command due to policy or implementation limitations, it should 496 respond with a 503 reply code. 498 If the server rejects the command because it is not supported by 499 the current security mechanism, the server should respond with 500 reply code 537. 502 If the server rejects the command (if a checksum fails, for 503 instance), it should respond with reply code 535. 505 If the server is not willing to accept the command (if privacy is 506 required by policy, for instance, or if a CONF command is received 507 before a CCC command), it should respond with reply code 533. 509 Otherwise, the command will be interpreted as an FTP command. An 510 end-of-line code need not be included, but if one is included, it 511 must be a Telnet end-of-line code, not a local end-of-line code. 513 The server may require that, under some or all circumstances, all 514 commands be protected. In this case, it should make a 533 reply 515 to commands other than MIC, CONF, and ENC. 517 4. Login Authorization 519 The security data exchange may, among other things, establish the 520 identity of the client in a secure way to the server. This identity 521 may be used as one input to the login authorization process. 523 In response to the FTP login commands (AUTH, PASS, ACCT), the server 524 may choose to change the sequence of commands and replies specified 525 by RFC 959 as follows. There are also some new replies available. 527 If the server is willing to allow the user named by the USER command 528 to log in based on the identity established by the security data 529 exchange, it should respond with reply code 232. 531 If the security mechanism requires a challenge/response password, it 532 should respond to the USER command with reply code 336. The text 533 part of the reply should contain the challenge. The client must 534 display the challenge to the user before prompting for the password 535 in this case. This is particularly relevant to more sophisticated 536 clients or graphical user interfaces which provide dialog boxes or 537 other modal input. These clients should be careful not to prompt for 538 the password before the username has been sent to the server, in case 539 the user needs the challenge in the 336 reply to construct a valid 540 password. 542 5. New FTP Replies 544 The new reply codes are divided into two classes. The first class is 545 new replies made necessary by the new FTP Security commands. The 546 second class is a new reply type to indicate protected replies. 548 5.1. New individual reply codes 550 232 User logged in, authorized by security data exchange. 551 234 Security data exchange complete. 552 235 [ADAT=base64data] 553 ; This reply indicates that the security data exchange 554 ; completed successfully. The square brackets are not 555 ; to be included in the reply, but indicate that 556 ; security data in the reply is optional. 558 334 [ADAT=base64data] 559 ; This reply indicates that the requested security mechanism 560 ; is ok, and includes security data to be used by the client 561 ; to construct the next command. The square brackets are not 562 ; to be included in the reply, but indicate that 563 ; security data in the reply is optional. 564 335 [ADAT=base64data] 565 ; This reply indicates that the security data is 566 ; acceptable, and more is required to complete the 567 ; security data exchange. The square brackets 568 ; are not to be included in the reply, but indicate 569 ; that security data in the reply is optional. 570 336 Username okay, need password. Challenge is "...." 571 ; The exact representation of the challenge should be chosen 572 ; by the mechanism to be sensible to the human user of the 573 ; system. 575 431 Need some unavailable resource to process security. 577 533 Command protection level denied for policy reasons. 578 534 Request denied for policy reasons. 579 535 Failed security check (hash, sequence, etc). 580 536 Requested PROT level not supported by mechanism. 581 537 Command protection level not supported by security mechanism. 583 5.2. Protected replies. 585 One new reply type is introduced: 587 6yz Protected reply 588 There are three reply codes of this type. The first, reply 589 code 631 indicates an integrity protected reply. The 590 second, reply code 632, indicates a confidentiality and 591 integrity protected reply. the third, reply code 633, 592 indicates a confidentiality protected reply. 594 The text part of a 631 reply is a Telnet string consisting 595 of a base 64 encoded "safe" message produced by a security 596 mechanism specific message integrity procedure. The text 597 part of a 632 reply is a Telnet string consisting of a base 598 64 encoded "private" message produced by a security 599 mechanism specific message confidentiality and integrity 600 procedure. The text part of a 633 reply is a Telnet string 601 consisting of a base 64 encoded "confidential" message 602 produced by a security mechanism specific message 603 confidentiality procedure. 605 The client will decode and verify the encoded reply. How 606 failures decoding or verifying replies are handled is 607 implementation-specific. An end-of-line code need not be 608 included, but if one is included, it must be a Telnet end- 609 of-line code, not a local end-of-line code. 611 A protected reply may only be sent if a security data 612 exchange has succeeded. 614 The 63z reply may be a multiline reply. In this case, the 615 plaintext reply must be broken up into a number of 616 fragments. Each fragment must be protected, then base 64 617 encoded in order into a separate line of the multiline 618 reply. There need not be any correspondence between the 619 line breaks in the plaintext reply and the encoded reply. 620 Telnet end-of-line codes must appear in the plaintext of the 621 encoded reply, except for the final end-of-line code, which 622 is optional. 624 The multiline reply must be formatted more strictly than the 625 continuation specification in RFC 959. In particular, each 626 line before the last must be formed by the reply code, 627 followed immediately by a hyphen, followed by a base 64 628 encoded fragment of the reply. 630 For example, if the plaintext reply is 632 123-First line 633 Second line 634 234 A line beginning with numbers 635 123 The last line 637 then the resulting protected reply could be any of the 638 following (the first example has a line break only to fit 639 within the margins): 641 631 base64(protect("123-First line\r\nSecond line\r\n 234 A line 642 beginning with numbers\r\n123 The last line\r\n")) 644 631-base64(protect("123-First line\r\n")) 645 631-base64(protect("Second line\r\n")) 646 631-base64(protect(" 234 A line beginning with numbers\r\n")) 647 631 base64(protect("123 The last line")) 649 631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b")) 650 631 base64(protect("eginning with numbers\r\n123 The last line\r\n")) 652 6. Data Channel Encapsulation 654 When data transfers are protected between the client and server (in 655 either direction), certain transformations and encapsulations must be 656 performed so that the recipient can properly decode the transmitted 657 file. 659 The sender must apply all protection services after transformations 660 associated with the representation type, file structure, and transfer 661 mode have been performed. The data sent over the data channel is, 662 for the purposes of protection, to be treated as a byte stream. 664 The sender must take the input byte stream, and break it up into 665 blocks such that each block, when encoded using a security mechanism 666 specific procedure, will be no larger than the buffer size negotiated 667 by the client with the PBSZ command. Each block must be encoded, 668 then transmitted with the length of the encoded block prepended as a 669 four byte unsigned integer, most significant byte first. 671 When the end of the file is reached, the sender must encode a block 672 of zero bytes, and send this final block to the recipient before 673 closing the data connection. 675 The recipient will read the four byte length, read a block of data 676 that many bytes long, then decode and verify this block with a 677 security mechanism specific procedure. This must be repeated until a 678 block encoding a buffer of zero bytes is received. This indicates 679 the end of the encoded byte stream. 681 Any transformations associated with the representation type, file 682 structure, and transfer mode are to be performed by the recipient on 683 the byte stream resulting from the above process. 685 When using block transfer mode, the sender's (cleartext) buffer size 686 is independent of the block size. 688 The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE 689 command if the current protection level is not at the level dictated 690 by the server's security requirements for the particular file 691 transfer. 693 If any data protection services fail at any time during data transfer 694 at the server end (including an attempt to send a buffer size greater 695 than the negotiated maximum), the server will send a 535 reply to the 696 data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE). 698 7. Potential policy considerations 700 While there are no restrictions on client and server policy, there 701 are a few recommendations which an implementation should implement. 703 - Once a security data exchange takes place, a server should require 704 all commands be protected (with integrity and/or confidentiality), 705 and it should protect all replies. Replies should use the same 706 level of protection as the command which produced them. This 707 includes replies which indicate failure of the MIC, CONF, and ENC 708 commands. In particular, it is not meaningful to require that 709 AUTH and ADAT be protected; it is meaningful and useful to require 710 that PROT and PBSZ be protected. In particular, the use of CCC is 711 not recommended, but is defined in the interest of 712 interoperability between implementations which might desire such 713 functionality. 715 - A client should encrypt the PASS command whenever possible. It is 716 reasonable for the server to refuse to accept a non-encrypted PASS 717 command if the server knows encryption is available. 719 - Although no security commands are required to be implemented, it 720 is recommended that an implementation provide all commands which 721 can be implemented, given the mechanisms supported and the policy 722 considerations of the site (export controls, for instance). 724 8. Declarative specifications 726 These sections are modelled after sections 5.3 and 5.4 of RFC 959, 727 which describe the same information, except for the standard FTP 728 commands and replies. 730 8.1. FTP Security commands and arguments 732 AUTH 733 ADAT 734 PROT 735 PBSZ 736 MIC 737 CONF 738 ENC 740 ::= 741 ::= 742 ; must be formatted as described in section 9 743 ::= C | S | E | P 744 ::= any decimal integer from 1 to (2^32)-1 746 8.2. Command-Reply sequences 748 Security Association Setup 749 AUTH 750 234 751 334 752 502, 504, 534, 431 753 500, 501, 421 754 ADAT 755 235 756 335 757 503, 501, 535 758 500, 501, 421 759 Data protection negotiation commands 760 PBSZ 761 200 762 503 763 500, 501, 421, 530 764 PROT 765 200 766 504, 536, 503, 534, 431 767 500, 501, 421, 530 768 Command channel protection commands 769 MIC 770 535, 533 771 500, 501, 421 772 CONF 773 535, 533 774 500, 501, 421 775 ENC 776 535, 533 777 500, 501, 421 778 Security-Enhanced login commands (only new replies listed) 779 USER 780 232 781 336 782 Data channel commands (only new replies listed) 783 STOR 784 534, 535 785 STOU 786 534, 535 787 RETR 788 534, 535 789 LIST 790 534, 535 791 NLST 792 534, 535 793 APPE 794 534, 535 796 In addition to these reply codes, any security command can return 797 500, 501, 502, 533, or 421. Any ftp command can return a reply 798 code encapsulated in a 631, 632, or 633 reply once a security data 799 exchange has completed successfully. 801 9. State Diagrams 803 This section includes a state diagram which demonstrates the flow of 804 authentication and authorization in a security enhanced FTP 805 implementation. The rectangular blocks show states where the client 806 must issue a command, and the diamond blocks show states where the 807 server must issue a response. 809 ,------------------, USER 810 __\| Unauthenticated |_________\ 811 | /| (new connection) | /| 812 | `------------------' | 813 | | | 814 | | AUTH | 815 | V | 816 | / \ | 817 | 4yz,5yz / \ 234 | 818 |<--------< >------------->. | 819 | \ / | | 820 | \_/ | | 821 | | | | 822 | | 334 | | 823 | V | | 824 | ,--------------------, | | 825 | | Need Security Data |<--. | | 826 | `--------------------' | | | 827 | | | | | 828 | | ADAT | | | 829 | V | | | 830 | / \ | | | 831 | 4yz,5yz / \ 335 | | | 832 `<--------< >-----------' | | 833 \ / | | 834 \_/ | | 835 | | | 836 | 235 | | 837 V | | 838 ,---------------. | | 839 ,--->| Authenticated |<--------' | After the client and server 840 | `---------------' | have completed authenti- 841 | | | cation, command must be 842 | | USER | integrity-protected if 843 | | | integrity is available. The 844 | |<-------------------' CCC command may be issued to 845 | V relax this restriction. 846 | / \ 847 | 4yz,5yz / \ 2yz 848 |<--------< >------------->. 849 | \ / | 850 | \_/ | 851 | | | 852 | | 3yz | 853 | V | 854 | ,---------------. | 855 | | Need Password | | 856 | `---------------' | 857 | | | 858 | | PASS | 859 | V | 860 | / \ | 861 | 4yz,5yz / \ 2yz | 862 |<--------< >------------->| 863 | \ / | 864 | \_/ | 865 | | | 866 | | 3yz | 867 | V | 868 | ,--------------. | 869 | | Need Account | | 870 | `--------------' | 871 | | | 872 | | ACCT | 873 | V | 874 | / \ | 875 | 4yz,5yz / \ 2yz | 876 `<--------< >------------->| 877 \ / | 878 \_/ | 879 | | 880 | 3yz | 881 V | 882 ,-------------. | 883 | Authorized |/________| 884 | (Logged in) |\ 885 `-------------' 887 10. Base 64 Encoding 889 Base 64 encoding is the same as the Printable Encoding described in 890 Section 4.3.2.4 of [RFC-1421], except that line breaks must not be 891 included. This encoding is defined as follows. 893 Proceeding from left to right, the bit string resulting from the 894 mechanism specific protection routine is encoded into characters 895 which are universally representable at all sites, though not 896 necessarily with the same bit patterns (e.g., although the character 897 "E" is represented in an ASCII-based system as hexadecimal 45 and as 898 hexadecimal C5 in an EBCDIC-based system, the local significance of 899 the two representations is equivalent). 901 A 64-character subset of International Alphabet IA5 is used, enabling 902 6 bits to be represented per printable character. (The proposed 903 subset of characters is represented identically in IA5 and ASCII.) 904 The character "=" signifies a special processing function used for 905 padding within the printable encoding procedure. 907 The encoding process represents 24-bit groups of input bits as output 908 strings of 4 encoded characters. Proceeding from left to right 909 across a 24-bit input group output from the security mechanism 910 specific message protection procedure, each 6-bit group is used as an 911 index into an array of 64 printable characters, namely "[A-Z][a- 912 z][0-9]+/". The character referenced by the index is placed in the 913 output string. These characters are selected so as to be universally 914 representable, and the set excludes characters with particular 915 significance to Telnet (e.g., "", "", IAC). 917 Special processing is performed if fewer than 24 bits are available 918 in an input group at the end of a message. A full encoding quantum 919 is always completed at the end of a message. When fewer than 24 920 input bits are available in an input group, zero bits are added (on 921 the right) to form an integral number of 6-bit groups. Output 922 character positions which are not required to represent actual input 923 data are set to the character "=". Since all canonically encoded 924 output is an integral number of octets, only the following cases can 925 arise: (1) the final quantum of encoding input is an integral 926 multiple of 24 bits; here, the final unit of encoded output will be 927 an integral multiple of 4 characters with no "=" padding, (2) the 928 final quantum of encoding input is exactly 8 bits; here, the final 929 unit of encoded output will be two characters followed by two "=" 930 padding characters, or (3) the final quantum of encoding input is 931 exactly 16 bits; here, the final unit of encoded output will be three 932 characters followed by one "=" padding character. 934 Implementors must keep in mind that the base 64 encodings in ADAT, 935 MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily 936 long. Thus, the entire line must be read before it can be processed. 937 Several successive reads on the control channel may be necessary. It 938 is not appropriate to for a server to reject a command containing a 939 base 64 encoding simply because it is too long (assuming that the 940 decoding is otherwise well formed in the context in which it was 941 sent). 943 Case must not be ignored when reading commands and replies containing 944 base 64 encodings. 946 11. Security Considerations 948 This entire document deals with security considerations related to 949 the File Transfer Protocol. 951 Third party file transfers cannot be secured using these extensions, 952 since a security context cannot be established between two servers 953 using these facilities (no control connection exists between servers 954 over which to pass ADAT tokens). Further work in this area is 955 deferred. 957 12. Acknowledgements 959 I would like to thank the members of the CAT WG, as well as all 960 participants in discussions on the "cat-ietf@mit.edu" mailing list, 961 for their contributions to this document. I would especially like to 962 thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, 963 Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Kerri Balk 964 for their contributions to this work. Of course, without Steve Lunt, 965 the author of the first six revisions of this document, it would not 966 exist at all. 968 13. References 970 [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption 971 Option", Internet Draft, Cray Research, Inc, April 1993. 973 [RFC-1123] Braden, R., "Requirements for Internet Hosts -- 974 Application and Support", RFC 1123, October 1989. 976 [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic 977 Mail: Part I: Message Encryption and Authentication Procedures", 978 RFC 1421, February 1993. 980 14. Author's Address 982 Marc Horowitz 983 Cygnus Solutions 984 955 Massachusetts Avenue 985 Cambridge, MA 02139 987 Phone: +1 617 354 7688 988 Email: marc@cygnus.com 990 Appendix I: Specification under the GSSAPI 992 In order to maximise the utility of new security mechanisms, it is 993 desirable that new mechanisms be implemented as GSSAPI mechanisms 994 rather than as FTP security mechanisms. This will enable existing 995 ftp implementations to support the new mechanisms more easily, since 996 little or no code will need to be changed. In addition, the 997 mechanism will be usable by other protocols, such as IMAP, which are 998 built on top of the GSSAPI, with no additional specification or 999 implementation work needed by the mechanism designers. 1001 The security mechanism name (for the AUTH command) associated with 1002 all mechanisms employing the GSSAPI is GSSAPI. If the server 1003 supports a security mechanism employing the GSSAPI, it must respond 1004 with a 334 reply code indicating that an ADAT command is expected 1005 next. 1007 The client must begin the authentication exchange by calling 1008 GSS_Init_Sec_Context, passing in 0 for input_context_handle 1009 (initially), and a targ_name equal to output_name from 1010 GSS_Import_Name called with input_name_type of Host-Based Service and 1011 input_name_string of "ftp@hostname" where "hostname" is the fully 1012 qualified host name of the server with all letters in lower case. 1013 (Failing this, the client may try again using input_name_string of 1014 "host@hostname".) The output_token must then be base 64 encoded and 1015 sent to the server as the argument to an ADAT command. If 1016 GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client 1017 must expect a token to be returned in the reply to the ADAT command. 1018 This token musr subsequently be passed to another call to 1019 GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns 1020 no output_token, then the reply code from the server for the previous 1021 ADAT command must have been 235. If GSS_Init_Sec_Context returns 1022 GSS_S_COMPLETE, then no further tokens are expected from the server, 1023 and the client must consider the server authenticated. 1025 The server must base 64 decode the argument to the ADAT command and 1026 pass the resultant token to GSS_Accept_Sec_Context as input_token, 1027 setting acceptor_cred_handle to NULL (for "use default credentials"), 1028 and 0 for input_context_handle (initially). If an output_token is 1029 returned, it must be base 64 encoded and returned to the client by 1030 including "ADAT=base64string" in the text of the reply. If 1031 GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be 1032 235, and the server must consider the client authenticated. If 1033 GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code 1034 must be 335. Otherwise, the reply code should be 535, and the text 1035 of the reply should contain a descriptive error message. 1037 The chan_bindings input to GSS_Init_Sec_Context and 1038 GSS_Accept_Sec_Context should use the client address and server 1039 internet address as the initiator and acceptor addresses, 1040 respectively. The address type for both should be GSS_C_AF_INET. No 1041 application data should be specified. 1043 Since GSSAPI supports anonymous peers to security contexts, it is 1044 possible that the client's authentication of the server or vice versa 1045 does not actually establish an identity. 1047 The procedure associated with MIC commands, 631 replies, and Safe 1048 file transfers is: 1050 GSS_Wrap for the sender, with conf_flag == FALSE 1051 GSS_Unwrap for the receiver 1053 The procedure associated with ENC commands, 632 replies, and Private 1054 file transfers is: 1056 GSS_Wrap for the sender, with conf_flag == TRUE 1057 GSS_Unwrap for the receiver 1059 CONF commands and 633 replies are not supported. 1061 Both the client and server should inspect the value of conf_avail to 1062 determine whether the peer supports confidentiality services. 1064 When the security state is reset (when AUTH is received a second 1065 time, or when REIN is received), this should be done by calling the 1066 GSS_Delete_sec_context function. 1068 Appendix II: Specification under Kerberos version 4 1070 The security mechanism name (for the AUTH command) associated with 1071 Kerberos Version 4 is KERBEROS_V4. If the server supports 1072 KERBEROS_V4, it must respond with a 334 reply code indicating that an 1073 ADAT command is expected next. 1075 The client must retrieve a ticket for the Kerberos principal 1076 "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name 1077 of "ftp", an instance equal to the first part of the canonical host 1078 name of the server with all letters in lower case (as returned by 1079 krb_get_phost(3)), the server's realm name (as returned by 1080 krb_realmofhost(3)), and an arbitrary checksum. The ticket must then 1081 be base 64 encoded and sent as the argument to an ADAT command. 1083 If the "ftp" principal name is not a registered principal in the 1084 Kerberos database, then the client may fall back on the "rcmd" 1085 principal name (same instance and realm). However, servers must 1086 accept only one or the other of these principal names, and must not 1087 be willing to accept either. Generally, if the server has a key for 1088 the "ftp" principal in its srvtab, then that principal only must be 1089 used, otherwise the "rcmd" principal only must be used. 1091 The server must base 64 decode the argument to the ADAT command and 1092 pass the result to krb_rd_req(3). The server must add one to the 1093 checksum from the authenticator, convert the result to network byte 1094 order (most significant byte first), and sign it using 1095 krb_mk_safe(3), and base 64 encode the result. Upon success, the 1096 server must reply to the client with a 235 code and include 1097 "ADAT=base64string" in the text of the reply. Upon failure, the 1098 server should reply 535. 1100 Upon receipt of the 235 reply from the server, the client must parse 1101 the text of the reply for the base 64 encoded data, decode it, 1102 convert it from network byte order, and pass the result to 1103 krb_rd_safe(3). The client must consider the server authenticated if 1104 the resultant checksum is equal to one plus the value previously 1105 sent. 1107 The procedure associated with MIC commands, 631 replies, and Safe 1108 file transfers is: 1110 krb_mk_safe(3) for the sender 1111 krb_rd_safe(3) for the receiver 1113 The procedure associated with ENC commands, 632 replies, and Private 1114 file transfers is: 1116 krb_mk_priv(3) for the sender 1117 krb_rd_priv(3) for the receiver 1119 CONF commands and 633 replies are not supported. 1121 Note that this specification for KERBEROS_V4 contains no provision 1122 for negotiating alternate means for integrity and confidentiality 1123 routines. Note also that the ADAT exchange does not convey whether 1124 the peer supports confidentiality services. 1126 In order to stay within the allowed PBSZ, implementors must take note 1127 that a cleartext buffer will grow by 31 bytes when processed by 1128 krb_mk_safe(3) and will grow by 26 bytes when processed by 1129 krb_mk_priv(3).