1 2 3 4 5 6 7Network Working Group M. Horowitz 8Request for Comments: 2228 Cygnus Solutions 9Updates: 959 S. Lunt 10Category: Standards Track Bellcore 11 October 1997 12 13 FTP Security Extensions 14 15Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (1997). All Rights Reserved. 26 27Abstract 28 29 This document defines extensions to the FTP specification STD 9, RFC 30 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions 31 provide strong authentication, integrity, and confidentiality on both 32 the control and data channels with the introduction of new optional 33 commands, replies, and file transfer encodings. 34 35 The following new optional commands are introduced in this 36 specification: 37 38 AUTH (Authentication/Security Mechanism), 39 ADAT (Authentication/Security Data), 40 PROT (Data Channel Protection Level), 41 PBSZ (Protection Buffer Size), 42 CCC (Clear Command Channel), 43 MIC (Integrity Protected Command), 44 CONF (Confidentiality Protected Command), and 45 ENC (Privacy Protected Command). 46 47 A new class of reply types (6yz) is also introduced for protected 48 replies. 49 50 None of the above commands are required to be implemented, but 51 interdependencies exist. These dependencies are documented with the 52 commands. 53 54 Note that this specification is compatible with STD 9, RFC 959. 55 56 57 58Horowitz & Lunt Standards Track [Page 1] 59 60RFC 2228 FTP Security Extensions October 1997 61 62 631. Introduction 64 65 The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 66 and in place on the Internet uses usernames and passwords passed in 67 cleartext to authenticate clients to servers (via the USER and PASS 68 commands). Except for services such as "anonymous" FTP archives, 69 this represents a security risk whereby passwords can be stolen 70 through monitoring of local and wide-area networks. This either aids 71 potential attackers through password exposure and/or limits 72 accessibility of files by FTP servers who cannot or will not accept 73 the inherent security risks. 74 75 Aside from the problem of authenticating users in a secure manner, 76 there is also the problem of authenticating servers, protecting 77 sensitive data and/or verifying its integrity. An attacker may be 78 able to access valuable or sensitive data merely by monitoring a 79 network, or through active means may be able to delete or modify the 80 data being transferred so as to corrupt its integrity. An active 81 attacker may also initiate spurious file transfers to and from a site 82 of the attacker's choice, and may invoke other commands on the 83 server. FTP does not currently have any provision for the encryption 84 or verification of the authenticity of commands, replies, or 85 transferred data. Note that these security services have value even 86 to anonymous file access. 87 88 Current practice for sending files securely is generally either: 89 90 1. via FTP of files pre-encrypted under keys which are manually 91 distributed, 92 93 2. via electronic mail containing an encoding of a file encrypted 94 under keys which are manually distributed, 95 96 3. via a PEM message, or 97 98 4. via the rcp command enhanced to use Kerberos. 99 100 None of these means could be considered even a de facto standard, and 101 none are truly interactive. A need exists to securely transfer files 102 using FTP in a secure manner which is supported within the FTP 103 protocol in a consistent manner and which takes advantage of existing 104 security infrastructure and technology. Extensions are necessary to 105 the FTP specification if these security services are to be introduced 106 into the protocol in an interoperable way. 107 108 109 110 111 112 113 114Horowitz & Lunt Standards Track [Page 2] 115 116RFC 2228 FTP Security Extensions October 1997 117 118 119 Although the FTP control connection follows the Telnet protocol, and 120 Telnet has defined an authentication and encryption option [TELNET- 121 SEC], [RFC-1123] explicitly forbids the use of Telnet option 122 negotiation over the control connection (other than Synch and IP). 123 124 Also, the Telnet authentication and encryption option does not 125 provide for integrity protection only (without confidentiality), and 126 does not address the protection of the data channel. 127 1282. FTP Security Overview 129 130 At the highest level, the FTP security extensions seek to provide an 131 abstract mechanism for authenticating and/or authorizing connections, 132 and integrity and/or confidentiality protecting commands, replies, 133 and data transfers. 134 135 In the context of FTP security, authentication is the establishment 136 of a client's identity and/or a server's identity in a secure way, 137 usually using cryptographic techniques. The basic FTP protocol does 138 not have a concept of authentication. 139 140 Authorization is the process of validating a user for login. The 141 basic authorization process involves the USER, PASS, and ACCT 142 commands. With the FTP security extensions, authentication 143 established using a security mechanism may also be used to make the 144 authorization decision. 145 146 Without the security extensions, authentication of the client, as 147 this term is usually understood, never happens. FTP authorization is 148 accomplished with a password, passed on the network in the clear as 149 the argument to the PASS command. The possessor of this password is 150 assumed to be authorized to transfer files as the user named in the 151 USER command, but the identity of the client is never securely 152 established. 153 154 An FTP security interaction begins with a client telling the server 155 what security mechanism it wants to use with the AUTH command. The 156 server will either accept this mechanism, reject this mechanism, or, 157 in the case of a server which does not implement the security 158 extensions, reject the command completely. The client may try 159 multiple security mechanisms until it requests one which the server 160 accepts. This allows a rudimentary form of negotiation to take 161 place. (If more complex negotiation is desired, this may be 162 implemented as a security mechanism.) The server's reply will 163 indicate if the client must respond with additional data for the 164 165 166 167 168 169 170Horowitz & Lunt Standards Track [Page 3] 171 172RFC 2228 FTP Security Extensions October 1997 173 174 175 security mechanism to interpret. If none is needed, this will 176 usually mean that the mechanism is one where the password (specified 177 by the PASS command) is to be interpreted differently, such as with a 178 token or one-time password system. 179 180 If the server requires additional security information, then the 181 client and server will enter into a security data exchange. The 182 client will send an ADAT command containing the first block of 183 security data. The server's reply will indicate if the data exchange 184 is complete, if there was an error, or if more data is needed. The 185 server's reply can optionally contain security data for the client to 186 interpret. If more data is needed, the client will send another ADAT 187 command containing the next block of data, and await the server's 188 reply. This exchange can continue as many times as necessary. Once 189 this exchange completes, the client and server have established a 190 security association. This security association may include 191 authentication (client, server, or mutual) and keying information for 192 integrity and/or confidentiality, depending on the mechanism in use. 193 194 The term "security data" here is carefully chosen. The purpose of 195 the security data exchange is to establish a security association, 196 which might not actually include any authentication at all, between 197 the client and the server as described above. For instance, a 198 Diffie-Hellman exchange establishes a secret key, but no 199 authentication takes place. If an FTP server has an RSA key pair but 200 the client does not, then the client can authenticate the server, but 201 the server cannot authenticate the client. 202 203 Once a security association is established, authentication which is a 204 part of this association may be used instead of or in addition to the 205 standard username/password exchange for authorizing a user to connect 206 to the server. A username specified by the USER command is always 207 required to specify the identity to be used on the server. 208 209 In order to prevent an attacker from inserting or deleting commands 210 on the control stream, if the security association supports 211 integrity, then the server and client must use integrity protection 212 on the control stream, unless it first transmits a CCC command to 213 turn off this requirement. Integrity protection is performed with 214 the MIC and ENC commands, and the 63z reply codes. The CCC command 215 and its reply must be transmitted with integrity protection. 216 Commands and replies may be transmitted without integrity (that is, 217 in the clear or with confidentiality only) only if no security 218 association is established, the negotiated security association does 219 not support integrity, or the CCC command has succeeded. 220 221 222 223 224 225 226Horowitz & Lunt Standards Track [Page 4] 227 228RFC 2228 FTP Security Extensions October 1997 229 230 231 Once the client and server have negotiated with the PBSZ command an 232 acceptable buffer size for encapsulating protected data over the data 233 channel, the security mechanism may also be used to protect data 234 channel transfers. 235 236 Policy is not specified by this document. In particular, client and 237 server implementations may choose to implement restrictions on what 238 operations can be performed depending on the security association 239 which exists. For example, a server may require that a client 240 authorize via a security mechanism rather than using a password, 241 require that the client provide a one-time password from a token, 242 require at least integrity protection on the command channel, or 243 require that certain files only be transmitted encrypted. An 244 anonymous ftp client might refuse to do file transfers without 245 integrity protection in order to insure the validity of files 246 downloaded. 247 248 No particular set of functionality is required, except as 249 dependencies described in the next section. This means that none of 250 authentication, integrity, or confidentiality are required of an 251 implementation, although a mechanism which does none of these is not 252 of much use. For example, it is acceptable for a mechanism to 253 implement only integrity protection, one-way authentication and/or 254 encryption, encryption without any authentication or integrity 255 protection, or any other subset of functionality if policy or 256 technical considerations make this desirable. Of course, one peer 257 might require as a matter of policy stronger protection than the 258 other is able to provide, preventing perfect interoperability. 259 2603. New FTP Commands 261 262 The following commands are optional, but dependent on each other. 263 They are extensions to the FTP Access Control Commands. 264 265 The reply codes documented here are generally described as 266 recommended, rather than required. The intent is that reply codes 267 describing the full range of success and failure modes exist, but 268 that servers be allowed to limit information presented to the client. 269 For example, a server might implement a particular security 270 mechanism, but have a policy restriction against using it. The 271 server should respond with a 534 reply code in this case, but may 272 respond with a 504 reply code if it does not wish to divulge that the 273 disallowed mechanism is supported. If the server does choose to use 274 a different reply code than the recommended one, it should try to use 275 a reply code which only differs in the last digit. In all cases, the 276 server must use a reply code which is documented as returnable from 277 the command received, and this reply code must begin with the same 278 digit as the recommended reply code for the situation. 279 280 281 282Horowitz & Lunt Standards Track [Page 5] 283 284RFC 2228 FTP Security Extensions October 1997 285 286 287 AUTHENTICATION/SECURITY MECHANISM (AUTH) 288 289 The argument field is a Telnet string identifying a supported 290 mechanism. This string is case-insensitive. Values must be 291 registered with the IANA, except that values beginning with "X-" 292 are reserved for local use. 293 294 If the server does not recognize the AUTH command, it must respond 295 with reply code 500. This is intended to encompass the large 296 deployed base of non-security-aware ftp servers, which will 297 respond with reply code 500 to any unrecognized command. If the 298 server does recognize the AUTH command but does not implement the 299 security extensions, it should respond with reply code 502. 300 301 If the server does not understand the named security mechanism, it 302 should respond with reply code 504. 303 304 If the server is not willing to accept the named security 305 mechanism, it should respond with reply code 534. 306 307 If the server is not able to accept the named security mechanism, 308 such as if a required resource is unavailable, it should respond 309 with reply code 431. 310 311 If the server is willing to accept the named security mechanism, 312 but requires security data, it must respond with reply code 334. 313 314 If the server is willing to accept the named security mechanism, 315 and does not require any security data, it must respond with reply 316 code 234. 317 318 If the server is responding with a 334 reply code, it may include 319 security data as described in the next section. 320 321 Some servers will allow the AUTH command to be reissued in order 322 to establish new authentication. The AUTH command, if accepted, 323 removes any state associated with prior FTP Security commands. 324 The server must also require that the user reauthorize (that is, 325 reissue some or all of the USER, PASS, and ACCT commands) in this 326 case (see section 4 for an explanation of "authorize" in this 327 context). 328 329 330 331 332 333 334 335 336 337 338Horowitz & Lunt Standards Track [Page 6] 339 340RFC 2228 FTP Security Extensions October 1997 341 342 343 AUTHENTICATION/SECURITY DATA (ADAT) 344 345 The argument field is a Telnet string representing base 64 encoded 346 security data (see Section 9, "Base 64 Encoding"). If a reply 347 code indicating success is returned, the server may also use a 348 string of the form "ADAT=base64data" as the text part of the reply 349 if it wishes to convey security data back to the client. 350 351 The data in both cases is specific to the security mechanism 352 specified by the previous AUTH command. The ADAT command, and the 353 associated replies, allow the client and server to conduct an 354 arbitrary security protocol. The security data exchange must 355 include enough information for both peers to be aware of which 356 optional features are available. For example, if the client does 357 not support data encryption, the server must be made aware of 358 this, so it will know not to send encrypted command channel 359 replies. It is strongly recommended that the security mechanism 360 provide sequencing on the command channel, to insure that commands 361 are not deleted, reordered, or replayed. 362 363 The ADAT command must be preceded by a successful AUTH command, 364 and cannot be issued once a security data exchange completes 365 (successfully or unsuccessfully), unless it is preceded by an AUTH 366 command to reset the security state. 367 368 If the server has not yet received an AUTH command, or if a prior 369 security data exchange completed, but the security state has not 370 been reset with an AUTH command, it should respond with reply code 371 503. 372 373 If the server cannot base 64 decode the argument, it should 374 respond with reply code 501. 375 376 If the server rejects the security data (if a checksum fails, for 377 instance), it should respond with reply code 535. 378 379 If the server accepts the security data, and requires additional 380 data, it should respond with reply code 335. 381 382 If the server accepts the security data, but does not require any 383 additional data (i.e., the security data exchange has completed 384 successfully), it must respond with reply code 235. 385 386 If the server is responding with a 235 or 335 reply code, then it 387 may include security data in the text part of the reply as 388 specified above. 389 390 391 392 393 394Horowitz & Lunt Standards Track [Page 7] 395 396RFC 2228 FTP Security Extensions October 1997 397 398 399 If the ADAT command returns an error, the security data exchange 400 will fail, and the client must reset its internal security state. 401 If the client becomes unsynchronized with the server (for example, 402 the server sends a 234 reply code to an AUTH command, but the 403 client has more data to transmit), then the client must reset the 404 server's security state. 405 406 PROTECTION BUFFER SIZE (PBSZ) 407 408 The argument is a decimal integer representing the maximum size, 409 in bytes, of the encoded data blocks to be sent or received during 410 file transfer. This number shall be no greater than can be 411 represented in a 32-bit unsigned integer. 412 413 This command allows the FTP client and server to negotiate a 414 maximum protected buffer size for the connection. There is no 415 default size; the client must issue a PBSZ command before it can 416 issue the first PROT command. 417 418 The PBSZ command must be preceded by a successful security data 419 exchange. 420 421 If the server cannot parse the argument, or if it will not fit in 422 32 bits, it should respond with a 501 reply code. 423 424 If the server has not completed a security data exchange with the 425 client, it should respond with a 503 reply code. 426 427 Otherwise, the server must reply with a 200 reply code. If the 428 size provided by the client is too large for the server, it must 429 use a string of the form "PBSZ=number" in the text part of the 430 reply to indicate a smaller buffer size. The client and the 431 server must use the smaller of the two buffer sizes if both buffer 432 sizes are specified. 433 434 DATA CHANNEL PROTECTION LEVEL (PROT) 435 436 The argument is a single Telnet character code specifying the data 437 channel protection level. 438 439 This command indicates to the server what type of data channel 440 protection the client and server will be using. The following 441 codes are assigned: 442 443 C - Clear 444 S - Safe 445 E - Confidential 446 P - Private 447 448 449 450Horowitz & Lunt Standards Track [Page 8] 451 452RFC 2228 FTP Security Extensions October 1997 453 454 455 The default protection level if no other level is specified is 456 Clear. The Clear protection level indicates that the data channel 457 will carry the raw data of the file transfer, with no security 458 applied. The Safe protection level indicates that the data will 459 be integrity protected. The Confidential protection level 460 indicates that the data will be confidentiality protected. The 461 Private protection level indicates that the data will be integrity 462 and confidentiality protected. 463 464 It is reasonable for a security mechanism not to provide all data 465 channel protection levels. It is also reasonable for a mechanism 466 to provide more protection at a level than is required (for 467 instance, a mechanism might provide Confidential protection, but 468 include integrity-protection in that encoding, due to API or other 469 considerations). 470 471 The PROT command must be preceded by a successful protection 472 buffer size negotiation. 473 474 If the server does not understand the specified protection level, 475 it should respond with reply code 504. 476 477 If the current security mechanism does not support the specified 478 protection level, the server should respond with reply code 536. 479 480 If the server has not completed a protection buffer size 481 negotiation with the client, it should respond with a 503 reply 482 code. 483 484 The PROT command will be rejected and the server should reply 503 485 if no previous PBSZ command was issued. 486 487 If the server is not willing to accept the specified protection 488 level, it should respond with reply code 534. 489 490 If the server is not able to accept the specified protection 491 level, such as if a required resource is unavailable, it should 492 respond with reply code 431. 493 494 Otherwise, the server must reply with a 200 reply code to indicate 495 that the specified protection level is accepted. 496 497 CLEAR COMMAND CHANNEL (CCC) 498 499 This command does not take an argument. 500 501 502 503 504 505 506Horowitz & Lunt Standards Track [Page 9] 507 508RFC 2228 FTP Security Extensions October 1997 509 510 511 It is desirable in some environments to use a security mechanism 512 to authenticate and/or authorize the client and server, but not to 513 perform any integrity checking on the subsequent commands. This 514 might be used in an environment where IP security is in place, 515 insuring that the hosts are authenticated and that TCP streams 516 cannot be tampered, but where user authentication is desired. 517 518 If unprotected commands are allowed on any connection, then an 519 attacker could insert a command on the control stream, and the 520 server would have no way to know that it was invalid. In order to 521 prevent such attacks, once a security data exchange completes 522 successfully, if the security mechanism supports integrity, then 523 integrity (via the MIC or ENC command, and 631 or 632 reply) must 524 be used, until the CCC command is issued to enable non-integrity 525 protected control channel messages. The CCC command itself must 526 be integrity protected. 527 528 Once the CCC command completes successfully, if a command is not 529 protected, then the reply to that command must also not be 530 protected. This is to support interoperability with clients which 531 do not support protection once the CCC command has been issued. 532 533 This command must be preceded by a successful security data 534 exchange. 535 536 If the command is not integrity-protected, the server must respond 537 with a 533 reply code. 538 539 If the server is not willing to turn off the integrity 540 requirement, it should respond with a 534 reply code. 541 542 Otherwise, the server must reply with a 200 reply code to indicate 543 that unprotected commands and replies may now be used on the 544 command channel. 545 546 INTEGRITY PROTECTED COMMAND (MIC) and 547 CONFIDENTIALITY PROTECTED COMMAND (CONF) and 548 PRIVACY PROTECTED COMMAND (ENC) 549 550 The argument field of MIC is a Telnet string consisting of a base 551 64 encoded "safe" message produced by a security mechanism 552 specific message integrity procedure. The argument field of CONF 553 is a Telnet string consisting of a base 64 encoded "confidential" 554 message produced by a security mechanism specific confidentiality 555 procedure. The argument field of ENC is a Telnet string 556 consisting of a base 64 encoded "private" message produced by a 557 security mechanism specific message integrity and confidentiality 558 procedure. 559 560 561 562Horowitz & Lunt Standards Track [Page 10] 563 564RFC 2228 FTP Security Extensions October 1997 565 566 567 The server will decode and/or verify the encoded message. 568 569 This command must be preceded by a successful security data 570 exchange. 571 572 A server may require that the first command after a successful 573 security data exchange be CCC, and not implement the protection 574 commands at all. In this case, the server should respond with a 575 502 reply code. 576 577 If the server cannot base 64 decode the argument, it should 578 respond with a 501 reply code. 579 580 If the server has not completed a security data exchange with the 581 client, it should respond with a 503 reply code. 582 583 If the server has completed a security data exchange with the 584 client using a mechanism which supports integrity, and requires a 585 CCC command due to policy or implementation limitations, it should 586 respond with a 503 reply code. 587 588 If the server rejects the command because it is not supported by 589 the current security mechanism, the server should respond with 590 reply code 537. 591 592 If the server rejects the command (if a checksum fails, for 593 instance), it should respond with reply code 535. 594 595 If the server is not willing to accept the command (if privacy is 596 required by policy, for instance, or if a CONF command is received 597 before a CCC command), it should respond with reply code 533. 598 599 Otherwise, the command will be interpreted as an FTP command. An 600 end-of-line code need not be included, but if one is included, it 601 must be a Telnet end-of-line code, not a local end-of-line code. 602 603 The server may require that, under some or all circumstances, all 604 commands be protected. In this case, it should make a 533 reply 605 to commands other than MIC, CONF, and ENC. 606 6074. Login Authorization 608 609 The security data exchange may, among other things, establish the 610 identity of the client in a secure way to the server. This identity 611 may be used as one input to the login authorization process. 612 613 614 615 616 617 618Horowitz & Lunt Standards Track [Page 11] 619 620RFC 2228 FTP Security Extensions October 1997 621 622 623 In response to the FTP login commands (AUTH, PASS, ACCT), the server 624 may choose to change the sequence of commands and replies specified 625 by RFC 959 as follows. There are also some new replies available. 626 627 If the server is willing to allow the user named by the USER command 628 to log in based on the identity established by the security data 629 exchange, it should respond with reply code 232. 630 631 If the security mechanism requires a challenge/response password, it 632 should respond to the USER command with reply code 336. The text 633 part of the reply should contain the challenge. The client must 634 display the challenge to the user before prompting for the password 635 in this case. This is particularly relevant to more sophisticated 636 clients or graphical user interfaces which provide dialog boxes or 637 other modal input. These clients should be careful not to prompt for 638 the password before the username has been sent to the server, in case 639 the user needs the challenge in the 336 reply to construct a valid 640 password. 641 6425. New FTP Replies 643 644 The new reply codes are divided into two classes. The first class is 645 new replies made necessary by the new FTP Security commands. The 646 second class is a new reply type to indicate protected replies. 647 648 5.1. New individual reply codes 649 650 232 User logged in, authorized by security data exchange. 651 234 Security data exchange complete. 652 235 [ADAT=base64data] 653 ; This reply indicates that the security data exchange 654 ; completed successfully. The square brackets are not 655 ; to be included in the reply, but indicate that 656 ; security data in the reply is optional. 657 658 334 [ADAT=base64data] 659 ; This reply indicates that the requested security mechanism 660 ; is ok, and includes security data to be used by the client 661 ; to construct the next command. The square brackets are not 662 ; to be included in the reply, but indicate that 663 ; security data in the reply is optional. 664 335 [ADAT=base64data] 665 ; This reply indicates that the security data is 666 ; acceptable, and more is required to complete the 667 ; security data exchange. The square brackets 668 ; are not to be included in the reply, but indicate 669 ; that security data in the reply is optional. 670 671 672 673 674Horowitz & Lunt Standards Track [Page 12] 675 676RFC 2228 FTP Security Extensions October 1997 677 678 679 336 Username okay, need password. Challenge is "...." 680 ; The exact representation of the challenge should be chosen 681 ; by the mechanism to be sensible to the human user of the 682 ; system. 683 684 431 Need some unavailable resource to process security. 685 686 533 Command protection level denied for policy reasons. 687 534 Request denied for policy reasons. 688 535 Failed security check (hash, sequence, etc). 689 536 Requested PROT level not supported by mechanism. 690 537 Command protection level not supported by security mechanism. 691 692 5.2. Protected replies. 693 694 One new reply type is introduced: 695 696 6yz Protected reply 697 698 There are three reply codes of this type. The first, reply 699 code 631 indicates an integrity protected reply. The 700 second, reply code 632, indicates a confidentiality and 701 integrity protected reply. the third, reply code 633, 702 indicates a confidentiality protected reply. 703 704 The text part of a 631 reply is a Telnet string consisting 705 of a base 64 encoded "safe" message produced by a security 706 mechanism specific message integrity procedure. The text 707 part of a 632 reply is a Telnet string consisting of a base 708 64 encoded "private" message produced by a security 709 mechanism specific message confidentiality and integrity 710 procedure. The text part of a 633 reply is a Telnet string 711 consisting of a base 64 encoded "confidential" message 712 produced by a security mechanism specific message 713 confidentiality procedure. 714 715 The client will decode and verify the encoded reply. How 716 failures decoding or verifying replies are handled is 717 implementation-specific. An end-of-line code need not be 718 included, but if one is included, it must be a Telnet end- 719 of-line code, not a local end-of-line code. 720 721 A protected reply may only be sent if a security data 722 exchange has succeeded. 723 724 The 63z reply may be a multiline reply. In this case, the 725 plaintext reply must be broken up into a number of 726 fragments. Each fragment must be protected, then base 64 727 728 729 730Horowitz & Lunt Standards Track [Page 13] 731 732RFC 2228 FTP Security Extensions October 1997 733 734 735 encoded in order into a separate line of the multiline 736 reply. There need not be any correspondence between the 737 line breaks in the plaintext reply and the encoded reply. 738 Telnet end-of-line codes must appear in the plaintext of the 739 encoded reply, except for the final end-of-line code, which 740 is optional. 741 742 The multiline reply must be formatted more strictly than the 743 continuation specification in RFC 959. In particular, each 744 line before the last must be formed by the reply code, 745 followed immediately by a hyphen, followed by a base 64 746 encoded fragment of the reply. 747 748 For example, if the plaintext reply is 749 750 123-First line 751 Second line 752 234 A line beginning with numbers 753 123 The last line 754 755 then the resulting protected reply could be any of the 756 following (the first example has a line break only to fit 757 within the margins): 758 759 631 base64(protect("123-First line\r\nSecond line\r\n 234 A line 760 631-base64(protect("123-First line\r\n")) 761 631-base64(protect("Second line\r\n")) 762 631-base64(protect(" 234 A line beginning with numbers\r\n")) 763 631 base64(protect("123 The last line")) 764 765 631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b")) 766 631 base64(protect("eginning with numbers\r\n123 The last line\r\n")) 767 7686. Data Channel Encapsulation 769 770 When data transfers are protected between the client and server (in 771 either direction), certain transformations and encapsulations must be 772 performed so that the recipient can properly decode the transmitted 773 file. 774 775 The sender must apply all protection services after transformations 776 associated with the representation type, file structure, and transfer 777 mode have been performed. The data sent over the data channel is, 778 for the purposes of protection, to be treated as a byte stream. 779 780 When performing a data transfer in an authenticated manner, the 781 authentication checks are performed on individual blocks of the file, 782 rather than on the file as a whole. Consequently, it is possible for 783 784 785 786Horowitz & Lunt Standards Track [Page 14] 787 788RFC 2228 FTP Security Extensions October 1997 789 790 791 insertion attacks to insert blocks into the data stream (i.e., 792 replays) that authenticate correctly, but result in a corrupted file 793 being undetected by the receiver. To guard against such attacks, the 794 specific security mechanism employed should include mechanisms to 795 protect against such attacks. Many GSS-API mechanisms usable with 796 the specification in Appendix I, and the Kerberos mechanism in 797 Appendix II do so. 798 799 The sender must take the input byte stream, and break it up into 800 blocks such that each block, when encoded using a security mechanism 801 specific procedure, will be no larger than the buffer size negotiated 802 by the client with the PBSZ command. Each block must be encoded, 803 then transmitted with the length of the encoded block prepended as a 804 four byte unsigned integer, most significant byte first. 805 806 When the end of the file is reached, the sender must encode a block 807 of zero bytes, and send this final block to the recipient before 808 closing the data connection. 809 810 The recipient will read the four byte length, read a block of data 811 that many bytes long, then decode and verify this block with a 812 security mechanism specific procedure. This must be repeated until a 813 block encoding a buffer of zero bytes is received. This indicates 814 the end of the encoded byte stream. 815 816 Any transformations associated with the representation type, file 817 structure, and transfer mode are to be performed by the recipient on 818 the byte stream resulting from the above process. 819 820 When using block transfer mode, the sender's (cleartext) buffer size 821 is independent of the block size. 822 823 The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE 824 command if the current protection level is not at the level dictated 825 by the server's security requirements for the particular file 826 transfer. 827 828 If any data protection services fail at any time during data transfer 829 at the server end (including an attempt to send a buffer size greater 830 than the negotiated maximum), the server will send a 535 reply to the 831 data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE). 832 833 834 835 836 837 838 839 840 841 842Horowitz & Lunt Standards Track [Page 15] 843 844RFC 2228 FTP Security Extensions October 1997 845 846 8477. Potential policy considerations 848 849 While there are no restrictions on client and server policy, there 850 are a few recommendations which an implementation should implement. 851 852 - Once a security data exchange takes place, a server should require 853 all commands be protected (with integrity and/or confidentiality), 854 and it should protect all replies. Replies should use the same 855 level of protection as the command which produced them. This 856 includes replies which indicate failure of the MIC, CONF, and ENC 857 commands. In particular, it is not meaningful to require that 858 AUTH and ADAT be protected; it is meaningful and useful to require 859 that PROT and PBSZ be protected. In particular, the use of CCC is 860 not recommended, but is defined in the interest of 861 interoperability between implementations which might desire such 862 functionality. 863 864 - A client should encrypt the PASS command whenever possible. It is 865 reasonable for the server to refuse to accept a non-encrypted PASS 866 command if the server knows encryption is available. 867 868 - Although no security commands are required to be implemented, it 869 is recommended that an implementation provide all commands which 870 can be implemented, given the mechanisms supported and the policy 871 considerations of the site (export controls, for instance). 872 8738. Declarative specifications 874 875 These sections are modelled after sections 5.3 and 5.4 of RFC 959, 876 which describe the same information, except for the standard FTP 877 commands and replies. 878 879 8.1. FTP Security commands and arguments 880 881 AUTH <SP> <mechanism-name> <CRLF> 882 ADAT <SP> <base64data> <CRLF> 883 PROT <SP> <prot-code> <CRLF> 884 PBSZ <SP> <decimal-integer> <CRLF> 885 MIC <SP> <base64data> <CRLF> 886 CONF <SP> <base64data> <CRLF> 887 ENC <SP> <base64data> <CRLF> 888 889 <mechanism-name> ::= <string> 890 <base64data> ::= <string> 891 ; must be formatted as described in section 9 892 <prot-code> ::= C | S | E | P 893 <decimal-integer> ::= any decimal integer from 1 to (2^32)-1 894 895 896 897 898Horowitz & Lunt Standards Track [Page 16] 899 900RFC 2228 FTP Security Extensions October 1997 901 902 903 8.2. Command-Reply sequences 904 905 Security Association Setup 906 AUTH 907 234 908 334 909 502, 504, 534, 431 910 500, 501, 421 911 ADAT 912 235 913 335 914 503, 501, 535 915 500, 501, 421 916 Data protection negotiation commands 917 PBSZ 918 200 919 503 920 500, 501, 421, 530 921 PROT 922 200 923 504, 536, 503, 534, 431 924 500, 501, 421, 530 925 Command channel protection commands 926 MIC 927 535, 533 928 500, 501, 421 929 CONF 930 535, 533 931 500, 501, 421 932 ENC 933 535, 533 934 500, 501, 421 935 Security-Enhanced login commands (only new replies listed) 936 USER 937 232 938 336 939 Data channel commands (only new replies listed) 940 STOR 941 534, 535 942 STOU 943 534, 535 944 RETR 945 534, 535 946 947 948 949 950 951 952 953 954Horowitz & Lunt Standards Track [Page 17] 955 956RFC 2228 FTP Security Extensions October 1997 957 958 959 LIST 960 534, 535 961 NLST 962 534, 535 963 APPE 964 534, 535 965 966 In addition to these reply codes, any security command can return 967 500, 501, 502, 533, or 421. Any ftp command can return a reply 968 code encapsulated in a 631, 632, or 633 reply once a security data 969 exchange has completed successfully. 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Horowitz & Lunt Standards Track [Page 18] 1011 1012RFC 2228 FTP Security Extensions October 1997 1013 1014 10159. State Diagrams 1016 1017 This section includes a state diagram which demonstrates the flow of 1018 authentication and authorization in a security enhanced FTP 1019 implementation. The rectangular blocks show states where the client 1020 must issue a command, and the diamond blocks show states where the 1021 server must issue a response. 1022 1023 1024 ,------------------, USER 1025 __\| Unauthenticated |_________\ 1026 | /| (new connection) | /| 1027 | `------------------' | 1028 | | | 1029 | | AUTH | 1030 | V | 1031 | / \ | 1032 | 4yz,5yz / \ 234 | 1033 |<--------< >------------->. | 1034 | \ / | | 1035 | \_/ | | 1036 | | | | 1037 | | 334 | | 1038 | V | | 1039 | ,--------------------, | | 1040 | | Need Security Data |<--. | | 1041 | `--------------------' | | | 1042 | | | | | 1043 | | ADAT | | | 1044 | V | | | 1045 | / \ | | | 1046 | 4yz,5yz / \ 335 | | | 1047 `<--------< >-----------' | | 1048 \ / | | 1049 \_/ | | 1050 | | | 1051 | 235 | | 1052 V | | 1053 ,---------------. | | 1054 ,--->| Authenticated |<--------' | After the client and server 1055 | `---------------' | have completed authenti- 1056 | | | cation, command must be 1057 | | USER | integrity-protected if 1058 | | | integrity is available. The 1059 | |<-------------------' CCC command may be issued to 1060 | V relax this restriction. 1061 1062 1063 1064 1065 1066Horowitz & Lunt Standards Track [Page 19] 1067 1068RFC 2228 FTP Security Extensions October 1997 1069 1070 1071 | / \ 1072 | 4yz,5yz / \ 2yz 1073 |<--------< >------------->. 1074 | \ / | 1075 | \_/ | 1076 | | | 1077 | | 3yz | 1078 | V | 1079 | ,---------------. | 1080 | | Need Password | | 1081 | `---------------' | 1082 | | | 1083 | | PASS | 1084 | V | 1085 | / \ | 1086 | 4yz,5yz / \ 2yz | 1087 |<--------< >------------->| 1088 | \ / | 1089 | \_/ | 1090 | | | 1091 | | 3yz | 1092 | V | 1093 | ,--------------. | 1094 | | Need Account | | 1095 | `--------------' | 1096 | | | 1097 | | ACCT | 1098 | V | 1099 | / \ | 1100 | 4yz,5yz / \ 2yz | 1101 `<--------< >------------->| 1102 \ / | 1103 \_/ | 1104 | | 1105 | 3yz | 1106 V | 1107 ,-------------. | 1108 | Authorized |/________| 1109 | (Logged in) |\ 1110 `-------------' 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122Horowitz & Lunt Standards Track [Page 20] 1123 1124RFC 2228 FTP Security Extensions October 1997 1125 1126 112710. Base 64 Encoding 1128 1129 Base 64 encoding is the same as the Printable Encoding described in 1130 Section 4.3.2.4 of [RFC-1421], except that line breaks must not be 1131 included. This encoding is defined as follows. 1132 1133 Proceeding from left to right, the bit string resulting from the 1134 mechanism specific protection routine is encoded into characters 1135 which are universally representable at all sites, though not 1136 necessarily with the same bit patterns (e.g., although the character 1137 "E" is represented in an ASCII-based system as hexadecimal 45 and as 1138 hexadecimal C5 in an EBCDIC-based system, the local significance of 1139 the two representations is equivalent). 1140 1141 A 64-character subset of International Alphabet IA5 is used, enabling 1142 6 bits to be represented per printable character. (The proposed 1143 subset of characters is represented identically in IA5 and ASCII.) 1144 The character "=" signifies a special processing function used for 1145 padding within the printable encoding procedure. 1146 1147 The encoding process represents 24-bit groups of input bits as output 1148 strings of 4 encoded characters. Proceeding from left to right 1149 across a 24-bit input group output from the security mechanism 1150 specific message protection procedure, each 6-bit group is used as an 1151 index into an array of 64 printable characters, namely "[A-Z][a- 1152 z][0-9]+/". The character referenced by the index is placed in the 1153 output string. These characters are selected so as to be universally 1154 representable, and the set excludes characters with particular 1155 significance to Telnet (e.g., "<CR>", "<LF>", IAC). 1156 1157 Special processing is performed if fewer than 24 bits are available 1158 in an input group at the end of a message. A full encoding quantum 1159 is always completed at the end of a message. When fewer than 24 1160 input bits are available in an input group, zero bits are added (on 1161 the right) to form an integral number of 6-bit groups. Output 1162 character positions which are not required to represent actual input 1163 data are set to the character "=". Since all canonically encoded 1164 output is an integral number of octets, only the following cases can 1165 arise: (1) the final quantum of encoding input is an integral 1166 multiple of 24 bits; here, the final unit of encoded output will be 1167 an integral multiple of 4 characters with no "=" padding, (2) the 1168 final quantum of encoding input is exactly 8 bits; here, the final 1169 unit of encoded output will be two characters followed by two "=" 1170 padding characters, or (3) the final quantum of encoding input is 1171 exactly 16 bits; here, the final unit of encoded output will be three 1172 characters followed by one "=" padding character. 1173 1174 1175 1176 1177 1178Horowitz & Lunt Standards Track [Page 21] 1179 1180RFC 2228 FTP Security Extensions October 1997 1181 1182 1183 Implementors must keep in mind that the base 64 encodings in ADAT, 1184 MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily 1185 long. Thus, the entire line must be read before it can be processed. 1186 Several successive reads on the control channel may be necessary. It 1187 is not appropriate to for a server to reject a command containing a 1188 base 64 encoding simply because it is too long (assuming that the 1189 decoding is otherwise well formed in the context in which it was 1190 sent). 1191 1192 Case must not be ignored when reading commands and replies containing 1193 base 64 encodings. 1194 119511. Security Considerations 1196 1197 This entire document deals with security considerations related to 1198 the File Transfer Protocol. 1199 1200 Third party file transfers cannot be secured using these extensions, 1201 since a security context cannot be established between two servers 1202 using these facilities (no control connection exists between servers 1203 over which to pass ADAT tokens). Further work in this area is 1204 deferred. 1205 120612. Acknowledgements 1207 1208 I would like to thank the members of the CAT WG, as well as all 1209 participants in discussions on the "cat-ietf@mit.edu" mailing list, 1210 for their contributions to this document. I would especially like to 1211 thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, 1212 Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk 1213 for their contributions to this work. Of course, without Steve Lunt, 1214 the author of the first six revisions of this document, it would not 1215 exist at all. 1216 121713. References 1218 1219 [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption 1220 Option", Work in Progress. 1221 1222 [RFC-1123] Braden, R., "Requirements for Internet Hosts -- 1223 Application and Support", STD 3, RFC 1123, October 1989. 1224 1225 [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic 1226 Mail: Part I: Message Encryption and Authentication Procedures", 1227 RFC 1421, February 1993. 1228 1229 1230 1231 1232 1233 1234Horowitz & Lunt Standards Track [Page 22] 1235 1236RFC 2228 FTP Security Extensions October 1997 1237 1238 123914. Author's Address 1240 1241 Marc Horowitz 1242 Cygnus Solutions 1243 955 Massachusetts Avenue 1244 Cambridge, MA 02139 1245 1246 Phone: +1 617 354 7688 1247 EMail: marc@cygnus.com 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290Horowitz & Lunt Standards Track [Page 23] 1291 1292RFC 2228 FTP Security Extensions October 1997 1293 1294 1295Appendix I: Specification under the GSSAPI 1296 1297 In order to maximise the utility of new security mechanisms, it is 1298 desirable that new mechanisms be implemented as GSSAPI mechanisms 1299 rather than as FTP security mechanisms. This will enable existing 1300 ftp implementations to support the new mechanisms more easily, since 1301 little or no code will need to be changed. In addition, the 1302 mechanism will be usable by other protocols, such as IMAP, which are 1303 built on top of the GSSAPI, with no additional specification or 1304 implementation work needed by the mechanism designers. 1305 1306 The security mechanism name (for the AUTH command) associated with 1307 all mechanisms employing the GSSAPI is GSSAPI. If the server 1308 supports a security mechanism employing the GSSAPI, it must respond 1309 with a 334 reply code indicating that an ADAT command is expected 1310 next. 1311 1312 The client must begin the authentication exchange by calling 1313 GSS_Init_Sec_Context, passing in 0 for input_context_handle 1314 (initially), and a targ_name equal to output_name from 1315 GSS_Import_Name called with input_name_type of Host-Based Service and 1316 input_name_string of "ftp@hostname" where "hostname" is the fully 1317 qualified host name of the server with all letters in lower case. 1318 (Failing this, the client may try again using input_name_string of 1319 "host@hostname".) The output_token must then be base 64 encoded and 1320 sent to the server as the argument to an ADAT command. If 1321 GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client 1322 must expect a token to be returned in the reply to the ADAT command. 1323 This token must subsequently be passed to another call to 1324 GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns 1325 no output_token, then the reply code from the server for the previous 1326 ADAT command must have been 235. If GSS_Init_Sec_Context returns 1327 GSS_S_COMPLETE, then no further tokens are expected from the server, 1328 and the client must consider the server authenticated. 1329 1330 The server must base 64 decode the argument to the ADAT command and 1331 pass the resultant token to GSS_Accept_Sec_Context as input_token, 1332 setting acceptor_cred_handle to NULL (for "use default credentials"), 1333 and 0 for input_context_handle (initially). If an output_token is 1334 returned, it must be base 64 encoded and returned to the client by 1335 including "ADAT=base64string" in the text of the reply. If 1336 GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be 1337 235, and the server must consider the client authenticated. If 1338 GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code 1339 must be 335. Otherwise, the reply code should be 535, and the text 1340 of the reply should contain a descriptive error message. 1341 1342 1343 1344 1345 1346Horowitz & Lunt Standards Track [Page 24] 1347 1348RFC 2228 FTP Security Extensions October 1997 1349 1350 1351 The chan_bindings input to GSS_Init_Sec_Context and 1352 GSS_Accept_Sec_Context should use the client internet address and 1353 server internet address as the initiator and acceptor addresses, 1354 respectively. The address type for both should be GSS_C_AF_INET. No 1355 application data should be specified. 1356 1357 Since GSSAPI supports anonymous peers to security contexts, it is 1358 possible that the client's authentication of the server does not 1359 actually establish an identity. 1360 1361 The procedure associated with MIC commands, 631 replies, and Safe 1362 file transfers is: 1363 1364 GSS_Wrap for the sender, with conf_flag == FALSE 1365 1366 GSS_Unwrap for the receiver 1367 1368 The procedure associated with ENC commands, 632 replies, and Private 1369 file transfers is: 1370 1371 GSS_Wrap for the sender, with conf_flag == TRUE 1372 GSS_Unwrap for the receiver 1373 1374 CONF commands and 633 replies are not supported. 1375 1376 Both the client and server should inspect the value of conf_avail to 1377 determine whether the peer supports confidentiality services. 1378 1379 When the security state is reset (when AUTH is received a second 1380 time, or when REIN is received), this should be done by calling the 1381 GSS_Delete_sec_context function. 1382 1383Appendix II: Specification under Kerberos version 4 1384 1385 The security mechanism name (for the AUTH command) associated with 1386 Kerberos Version 4 is KERBEROS_V4. If the server supports 1387 KERBEROS_V4, it must respond with a 334 reply code indicating that an 1388 ADAT command is expected next. 1389 1390 The client must retrieve a ticket for the Kerberos principal 1391 "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name 1392 of "ftp", an instance equal to the first part of the canonical host 1393 name of the server with all letters in lower case (as returned by 1394 krb_get_phost(3)), the server's realm name (as returned by 1395 krb_realmofhost(3)), and an arbitrary checksum. The ticket must then 1396 be base 64 encoded and sent as the argument to an ADAT command. 1397 1398 1399 1400 1401 1402Horowitz & Lunt Standards Track [Page 25] 1403 1404RFC 2228 FTP Security Extensions October 1997 1405 1406 1407 If the "ftp" principal name is not a registered principal in the 1408 Kerberos database, then the client may fall back on the "rcmd" 1409 principal name (same instance and realm). However, servers must 1410 accept only one or the other of these principal names, and must not 1411 be willing to accept either. Generally, if the server has a key for 1412 the "ftp" principal in its srvtab, then that principal only must be 1413 used, otherwise the "rcmd" principal only must be used. 1414 1415 The server must base 64 decode the argument to the ADAT command and 1416 pass the result to krb_rd_req(3). The server must add one to the 1417 checksum from the authenticator, convert the result to network byte 1418 order (most significant byte first), and sign it using 1419 krb_mk_safe(3), and base 64 encode the result. Upon success, the 1420 server must reply to the client with a 235 code and include 1421 "ADAT=base64string" in the text of the reply. Upon failure, the 1422 server should reply 535. 1423 1424 Upon receipt of the 235 reply from the server, the client must parse 1425 the text of the reply for the base 64 encoded data, decode it, 1426 convert it from network byte order, and pass the result to 1427 krb_rd_safe(3). The client must consider the server authenticated if 1428 the resultant checksum is equal to one plus the value previously 1429 sent. 1430 1431 The procedure associated with MIC commands, 631 replies, and Safe 1432 file transfers is: 1433 1434 krb_mk_safe(3) for the sender 1435 krb_rd_safe(3) for the receiver 1436 1437 The procedure associated with ENC commands, 632 replies, and Private 1438 file transfers is: 1439 1440 krb_mk_priv(3) for the sender 1441 krb_rd_priv(3) for the receiver 1442 1443 CONF commands and 633 replies are not supported. 1444 1445 Note that this specification for KERBEROS_V4 contains no provision 1446 for negotiating alternate means for integrity and confidentiality 1447 routines. Note also that the ADAT exchange does not convey whether 1448 the peer supports confidentiality services. 1449 1450 In order to stay within the allowed PBSZ, implementors must take note 1451 that a cleartext buffer will grow by 31 bytes when processed by 1452 krb_mk_safe(3) and will grow by 26 bytes when processed by 1453 krb_mk_priv(3). 1454 1455 1456 1457 1458Horowitz & Lunt Standards Track [Page 26] 1459 1460RFC 2228 FTP Security Extensions October 1997 1461 1462 1463Full Copyright Statement 1464 1465 Copyright (C) The Internet Society (1997). All Rights Reserved. 1466 1467 This document and translations of it may be copied and furnished to 1468 others, and derivative works that comment on or otherwise explain it 1469 or assist in its implmentation may be prepared, copied, published 1470 andand distributed, in whole or in part, without restriction of any 1471 kind, provided that the above copyright notice and this paragraph are 1472 included on all such copies and derivative works. However, this 1473 document itself may not be modified in any way, such as by removing 1474 the copyright notice or references to the Internet Society or other 1475 Internet organizations, except as needed for the purpose of 1476 developing Internet standards in which case the procedures for 1477 copyrights defined in the Internet Standards process must be 1478 followed, or as required to translate it into languages other than 1479 English. 1480 1481 The limited permissions granted above are perpetual and will not be 1482 revoked by the Internet Society or its successors or assigns. 1483 1484 This document and the information contained herein is provided on an 1485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514Horowitz & Lunt Standards Track [Page 27] 1515 1516