idnits 2.17.1 draft-ietf-ftpext2-hash-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2010) is 4900 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Obsolete informational reference (is this intentional?): RFC 3230 (Obsoleted by RFC 9530) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT2 Working Group A. Bryan 3 Internet-Draft T. Kosse 4 Intended status: Standards Track D. Stenberg 5 Expires: May 28, 2011 November 24, 2010 7 File Transfer Protocol HASH Command for Cryptographic Hashes 8 draft-ietf-ftpext2-hash-00 10 Abstract 12 The File Transfer Protocol does not offer any method to verify the 13 integrity of a transferred file, nor can two files be compared 14 against each other without actually transferring them first. 15 Cryptographic hashes are a possible solution to this problem. In the 16 past, several attempts have been made to add commands to obtain 17 checksums and hashes, however none have been formally specified, 18 leading to non-interoperability and confusion. To solve these 19 issues, this document specifies a new FTP command to be used by 20 clients to request cryptographic hashes of files. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The HASH Command (HASH) . . . . . . . . . . . . . . . . . . . 5 62 3.1. FEAT Command Response for HASH Command . . . . . . . . . . 6 63 3.2. OPTS Parameters for HASH . . . . . . . . . . . . . . . . . 6 64 3.3. User-PI usage of HASH . . . . . . . . . . . . . . . . . . 7 65 3.4. HASH Command Errors . . . . . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 5. Implementation Requirements . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 11 73 Appendix B. List of Non-standard Cryptographic Hash or 74 Checksum Commands and Implementations . . . . . . . . 11 75 Appendix C. Document History . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 The File Transfer Protocol [RFC0959] does not offer any method to 81 verify the integrity of a transferred file, nor can two files be 82 compared against each other without actually transferring them first. 83 Cryptographic hashes are a possible solution to this problem. In the 84 past, several attempts have been made to add commands to obtain 85 checksums and hashes, however none have been formally specified, 86 leading to non-interoperability and confusion. (See Appendix B for 87 more information). To solve these issues, this document specifies a 88 new FTP command to be used by clients to request cryptographic hashes 89 of files. HTTP has a similar feature named Instance Digests 90 [RFC3230] which allows a client to request the cryptographic hash of 91 a file. 93 [[ Discussion of this draft should take place on ftpext@ietf.org (or 94 apps-discuss@ietf.org if necessary). ]] 96 1.1. Example 98 Example of HASH client request: 100 C> HASH filename.ext 102 HASH server response with Positive Completion code, the currently 103 selected HASH algorithm, the requested hash of the file, and the 104 pathname of the file: 106 S> 213 SHA-1 80bc95fd391772fa61c91ed68567f0980bb45fd9 filename.ext 108 2. Document Conventions 110 This specification describes conformance of File Transfer Protocol 111 Extension for cryptographic hashes. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14, [RFC2119], as 116 scoped to those conformance targets. 118 This document also uses notation defined in STD 9, [RFC0959]. In 119 particular, the terms or commands "reply", "user", "file", "FTP 120 commands", "user-PI" (user protocol interpreter), "server-FTP 121 process", "server-PI", "mode", "type", "STOR", "RETR", and "ASCII", 122 are all used here as defined there. The term "pathname" is used as 123 defined in Section 2.2 of [RFC3659]. 125 In the examples of FTP dialogs presented in this document, lines that 126 begin "C> " were sent over the control connection from the user-PI to 127 the server-PI, and lines that begin "S> " were sent over the control 128 connection from the server-PI to the user-PI. In all cases, the 129 prefixes shown above, including the one space, have been added for 130 the purposes of this document, and are not a part of the data 131 exchanged between client and server. 133 Syntax required is defined using the Augmented BNF defined in 134 [RFC5234]. 136 2.1. Basic Tokens 138 This document imports the core definitions given in Appendix B of 139 [RFC5234]. There definitions will be found for basic ABNF elements 140 like ALPHA, DIGIT, SP, etc. To that, the following term is added for 141 use in this document. 143 TCHAR = VCHAR / SP / HTAB ; visible plus white space 145 The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 146 from varying sub-sets of the ASCII character set for use in various 147 commands and responses. 149 Note that in ABNF, string literals are case insensitive. That 150 convention is preserved in this document, and implies that FTP 151 commands and parameters that are added by this specification have 152 values that can be represented in any case. That is, "HASH" is the 153 same as "hash", "Hash", "HaSh", etc., and "ftp.example.com" is the 154 same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. 156 2.2. Server Replies 158 Section 4.2 of [RFC0959] defines the format and meaning of replies by 159 the server-PI to FTP commands from the user-PI. Those reply 160 conventions are used here without change. 162 error-response = error-code SP *TCHAR CRLF 163 error-code = ("4" / "5") 2DIGIT 165 Implementers should note that the ABNF syntax (which was not used in 166 [RFC0959]) used in this document, and other FTP related documents, 167 sometimes shows replies using the one line format. Unless otherwise 168 explicitly stated, that is not intended to imply that multi-line 169 responses are not permitted. Implementers should assume that, unless 170 stated to the contrary, any reply to any FTP command (including QUIT) 171 can be of the multi-line format described in [RFC0959]. 173 Throughout this document, replies will be identified by the three 174 digit code that is their first element. Thus the term "500 reply" 175 means a reply from the server-PI using the three digit code "500". 177 3. The HASH Command (HASH) 179 A new command "HASH" is added to the FTP command set to allow the 180 client to request the cryptographic hash of a file from a server-FTP 181 process. 183 The syntax for the HASH command is: 185 hash-command = "HASH" SP 187 As with all FTP commands, the "HASH" command word is case 188 independent, and MAY be specified in any character case desired. 190 The HASH command keyword MUST be followed by a single space (ASCII 191 32) followed by the pathname. 193 The pathname argument should reference the same file as other file 194 based commands such as STOR or RETR which the same argument would 195 reference. The pathname argument MUST represent a file path, not a 196 directory path. 198 The text returned in response to the HASH command MUST be: 200 hash-response = hash-ok / error-response 201 hash-ok = "213" SP hashname SP 1*HEXDIGIT SP CRLF 203 All hash values MUST be encoded in lowercase hexadecimal format. 205 The HASH command uses the currently selected hash algorithm. The 206 currently selected hash algorithm can be determined with FEAT or OPTS 207 HASH, and changed with OPTS HASH. 209 The HASH command is meant to be used for files transmitted in Image 210 type mode (TYPE I) and Stream transfer mode (MODE S). The returned 211 hash MUST be calculated as if a client were to download the full file 212 using TYPE I and MODE S and were to calculate the hash on the 213 received octet data. In other words, if a client were to download a 214 full file using TYPE I and MODE S and were to calculate the hash on 215 the received octet data, it would be identical to the hash returned 216 by HASH. 218 3.1. FEAT Command Response for HASH Command 220 When replying to the FEAT command [RFC2389], a server-FTP process 221 that supports the HASH command MUST include a feature line indicating 222 that the HASH command is supported, along with a list of all 223 supported hash algorithms in a semicolon separated list. The hash 224 algorithm that is currently selected MUST be marked with an asterisk. 225 The order of hash algorithms is insignificant. This command word is 226 case insensitive, and MAY be sent in any mixture of upper or lower 227 case, however it SHOULD be sent in upper case. That is, the response 228 SHOULD be: 230 C> FEAT 231 S> 211-Extensions supported: 232 S> ... 233 S> HASH SHA-256;SHA-512;SHA-1*;MD5 234 S> ... 235 S> 211 END 237 The ellipses indicate place holders where other features may be 238 included, and are not required. The one-space indentation of the 239 feature lines is mandatory [RFC2389]. 241 The IANA registry named "Hash Function Textual Names" defines values 242 for hash algorithms. Hash names SHOULD be presented in uppercase, 243 but comparisons should be case-insensitive, e.g. MD5, md5, Md5 are 244 all the same. 246 hash-feat = SP "HASH" SP hashlist CRLF 247 hashlist = 1*( hashname ["*"] ";" ) 248 hashname = 1*( hchar ) 249 hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / "," 251 3.2. OPTS Parameters for HASH 253 To query the current hash algorithm and to change it, the OPTS 254 command as defined in [RFC2389] is used with HASH as the first 255 argument. 257 If no second argument is passed, OPTS HASH simply returns the 258 currently selected hash algorithm. 260 C> OPTS HASH 261 S> 200 SHA-1 263 To change the algorithm, a valid hash algorithm MUST be given as 264 second argument. A list of valid hash algorithms is available via 265 the FEAT command. If the command is successful, all future calls to 266 HASH until the next successful OPTS HASH command or until the session 267 is reinitialized (REIN) will use the selected hash algorithm. 269 C> OPTS HASH SHA-512 270 S> 200 SHA-512 272 Requesting unknown or unsupported algorithms produces an error 273 response. 275 C> OPTS HASH CRC-37 276 S> 501 Unknown algorithm, current selection not changed 278 The syntax for OPTS HASH: 280 hashopts-cmd = "OPTS HASH" [ SP hashname ] CRLF 281 hashopts-response = hashopts-ok / error-response 282 hashopts-ok = "200" SP hashname CRLF 284 3.3. User-PI usage of HASH 286 The user-PI issues the FEAT command to query the server-PI about 287 which algorithm is currently selected. This also reveals the other 288 algorithms that the server supports. In this example, the SHA-1 289 algorithm is currently selected, as indicated by the asterisk. 291 C> FEAT 292 S> 211-Extensions supported: 293 S> ... 294 S> HASH SHA-256;SHA-512;SHA-1*;MD5 295 S> ... 296 S> 211 END 298 OPTS HASH is an alternative method for the user-PI to query the 299 server-PI about which algorithm is currently selected. 301 C> OPTS HASH 302 S> 200 SHA-1 304 In this example, we wish to select SHA-256, a different algorithm. 306 C> OPTS HASH SHA-256 307 S> 200 SHA-256 309 The user-PI requests the cryptographic hash of a file with HASH 310 command. Server-PI replies with the Positive Completion code, the 311 currently selected HASH algorithm, the requested hash of the file, 312 and the pathname of the file. 314 C> HASH filename.ext 315 S> 213 SHA-256 f0ad929cd259957e160ea442eb80986b5f... filename.ext 317 Client downloads file. Client hashes the downloaded file and 318 compares its hash to the hash obtained from the server. The HASH 319 command could also be used to verify that an uploaded file has the 320 same hash as the local file. 322 3.4. HASH Command Errors 324 The server-PI SHOULD reply with a 450 reply if the server is busy, 325 e.g. already hashing other files yet inviting the client to retry in 326 the future. 328 The server-PI SHOULD reply with a 500 reply if the HASH command is 329 unrecognized or unimplemented. 331 The server-PI SHOULD reply with a 501 reply to the OPTS HASH command 332 if the user-PI has requested an unknown or unsupported algorithm. 334 The server-PI SHOULD reply with a 550 reply if the HASH command is 335 used on a file that can not be found. 337 The server-PI SHOULD reply with a 551 reply if the server-PI can not 338 calculate the hash of a file because it is unable to deliver the file 339 with TYPE I and MODE S. 341 The server-PI SHOULD reply with a 552 reply if the user is not 342 allowed to use the HASH command. 344 The server-PI SHOULD reply with a 553 reply if the user requests the 345 HASH of a directory, which is not allowed. 347 The server-PI SHOULD reply with a 556 reply if the HASH command is 348 used on a file that cannot be processed for policy reasons. (For 349 example, if the file size exceeds the server's hashing policy.) 351 4. IANA Considerations 353 This new command is added to the "FTP Commands and Extensions" 354 registry created by [RFC5797]. 356 Command Name: HASH 358 Description: Cryptographic Hash of a file 360 FEAT String: HASH 362 Command Type: Service execution 364 Conformance Requirements: Optional 366 Reference: This specification 368 5. Implementation Requirements 370 All conforming implementations MUST at least support the SHA-1 371 algorithm [FIPS-180-3]. Implementations SHOULD NOT make any 372 algorithm the default that is known to be weaker than SHA-1. Support 373 for any additional algorithms is OPTIONAL. 375 6. Security Considerations 377 The server MUST only allow the HASH command to be processable for 378 files which the logged in user has a right to access. 380 Implementing the HASH command may impose a considerable load on the 381 server, which could lead to denial-of-service attacks. Servers have, 382 however, implemented this for many years, without significant 383 reported difficulties. On an affected server a malicious user could, 384 for example, continuously send HASH commands over multiple 385 connections and thus consume most of the FTP server's resources, 386 leaving little room for other operations. To mitigate this risk, a 387 server MAY cache the calculated hashes so that the hash of a file is 388 only calculated once even if multiple hash requests are sent for that 389 file, provided it updates or invalidates the cached hash when the 390 content of the corresponding file changes. A server may refuse to 391 process a HASH command for many reasons, one of which may be a 392 suspected denial-of-service attack. A client MUST be able to 393 understand that refusal to process HASH commands may be transient (if 394 indicated by a 4yz response) and MAY be honoured later if the server 395 so decides. A client MUST allow that a HASH command might take a 396 reasonably long time to complete. 398 Server operators might wish to allow the HASH command but restrict 399 its use to certain files, for example, if the file size exceeds the 400 server's hashing policy. A client MUST be able to understand that 401 refusal to process HASH commands may be permanent (if indicated by a 402 556 response) and will not be honoured later. 404 In addition, the HASH command can be used to draw conclusions about 405 the contents of a file. If the hash of a file on some server matches 406 the hash of some known file, then both files are likely identical. 407 By uploading a file, running HASH against it and running HASH against 408 another file location, the client could infer some filesystem 409 deployment information (e.g. that there is a logical link between a 410 pair of directories in the tree). This is probably not an issue if 411 the user has access to both branches of the directory tree, there is 412 the possibility that this information is exposable. To prevent this 413 scenario it suffices to limit use of the HASH command to users who 414 would already be able to download the file. 416 This mechanism simply allows the FTP protocol to expose HASH values 417 of files, using the currently chosen mechanism, accessible to the 418 server by the client. The suitability or otherwise of a specific 419 hash algorithm for a specific purpose is an implementation decision. 421 7. References 423 7.1. Normative References 425 [FIPS-180-3] 426 National Institute of Standards and Technology (NIST), 427 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 428 October 2008. 430 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 431 STD 9, RFC 0959, October 1985. 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 437 the File Transfer Protocol", RFC 2389, August 1998. 439 [RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 441 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 442 Specifications: ABNF", STD 68, RFC 5234, January 2008. 444 7.2. Informative References 446 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 447 RFC 3230, January 2002. 449 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 450 Registry", RFC 5797, March 2010. 452 [draft-twine-ftpmd5] 453 Twine, J., "The MD5 and MMD5 FTP Command Extensions", 454 draft-twine-ftpmd5-00 (work in progress), May 2002. 456 Appendix A. Acknowledgements and Contributors 458 Thanks to John C. Klensin, Alfred Hoenes, James Twine, Robert 459 McMurray, Mathias Berchtold, Tatsuhiro Tsujikawa, and Paul Ford- 460 Hutchinson. 462 Portions of [RFC3659] were wholly reused in this document. 464 Appendix B. List of Non-standard Cryptographic Hash or Checksum 465 Commands and Implementations 467 [[ to be removed by the RFC editor before publication as an RFC. ]] 469 A number of similar checksum or hash commands exist, but are not 470 formally specified, leading to non-interoperability and confusion. 471 The commands, any specifications, and relevant details: 473 o CKSM: GridFTP v2 Protocol Description 474 http://www.ogf.org/documents/GFD.47.pdf Usage: OPTS CKSM 475 CRLF. Supports ADLER32, MD5, CRC32. 476 o MD5/MMD5: Expired Internet Draft [draft-twine-ftpmd5] from 2002. 477 Usage: MD5 Algorithm specific command. Response codes: 478 251 positive completion, 500 Command Not Recognized, 502 Command 479 Not Implemented, 504 Command Not Implemented for the Specified 480 Argument. 481 o SITE CHECKSUM: Usage: SITE check_login SP CHECKSUM SP pathname 482 CRLF. Supports CRC32 and MD5. 484 o SITE SHOHASH: Usage: site shohash [filename]. Supports MD5. 485 Response codes: 200 positive completion. 486 o XCRC: By GlobalSCAPE in 2001. http://help.globalscape.com/help/ 487 secureserver2/File_Integrity_Checking.htm Usage: XCRC 488 SP EP. SP is starting point and EP is ending point in bytes and 489 are optional parameters. Algorithm specific command. Response 490 codes: 250 positive completion, 450 Requested file action not 491 taken. (File is busy), 550 Requested action not taken. (File not 492 found, no read permission, SP or EP not correct). 493 o XMD5: XMD5 SP EP. Similar to XCRC. Algorithm specific 494 command. 495 o XSHA, XSHA1, XSHA256, XSHA512: Usage similar to XCRC, although 496 SP/EP usage unknown. Algorithm specific commands. 498 An incomplete list of FTP clients and servers that have implemented 499 these commands: 501 o Akamai NetStorage (supports SITE CHKHSH/SITE SHOHASH) p17-18 502 http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf 503 o Apache Ftp Server (supports MD5/MMD5 from draft-twine-ftpmd5) 504 http://cwiki.apache.org/FTPSERVER/documentation.html 505 o Backup4all Pro (supports XCRC) 506 o Backup to FTP (supports XCRC) 507 o BlackMoon FTP Server (supports XCRC) 508 http://www.blackmoonftpserver.com/portal/readmore/features.html 509 o C.P.A. Secure (supports XCRC) 510 http://www.cpasecure.com/CPASecureVsSecureFTP.html 511 o Cerberus FTP server (supports XCRC, XMD5, XSHA1, XSHA256, XSHA512) 512 http://www.softpedia.com/progChangelog/ 513 Cerberus-FTP-Server-Changelog-1904.html 514 o Core FTP Pro (supports XCRC) 515 o Cross FTP Server (supports MD5/MMD5) 516 o FileCOPA FTP Server (supports XCRC, XMD5, XSHA1) 517 http://www.filecopa-ftpserver.com/features.html 518 o File Watchdogs FTP Server (supports XCRC, XMD5, XSHA1, XSHA256, 519 XSHA512) 520 http://www.filewatchdogs.com/ftpsitehosting/help/15559.htm 521 o FireFTP (supports XMD5, XSHA1) 522 http://fireftp.mozdev.org/features.html 523 o FTP Daemon (supports SITE CHECKMETHOD/SITE CHECKSUM) 524 http://www.pro-bono-publico.de/projects/ftpd.html 525 o FTP Voyager (supports XCRC) http://www.ftpvoyager.com/XCRC.asp 526 o Gene6 FTP Server 527 http://www.g6ftpserver.com/en/information#features 528 o GlobalSCAPE's Secure FTP Server / EFT Server / CuteFTP clients 529 (supports XCRC) 531 o Globus FTP client / Globus Toolkit(supports CKSM) http:// 532 www.globus.org/toolkit/releasenotes/3.2.0/gridftp_notes.html 533 o GoldenGate FTP (Ftp Full Java Server) (supports XCRC, XMD5, XSHA1) 534 o IceWarp FTP Server http://www.icewarp.com/products/ftp_server/ 535 o ICS FTP client (supports XCRC, XMD5) 536 http://www.magsys.co.uk/delphi/magics.asp 537 o ioFTPD (supports XCRC) 538 o JAFS (supports XCRC and MD5) 539 http://www.sbbi.net/site/jafs/features.html 540 o Kellerman FTP (supports XCRC) 541 http://sharptoolbox.com/tools/kellerman-ftp 542 o Limagito FTP server (supports XCRC, XMD5, XSHA1) 543 http://www.limagito.com/file-mover-features.html 544 o MOVEit DMZ (supports XSHA1) 545 o Nofeel FTP server (supports XCRC, XMD5, XSHA1) 546 http://www.nftpserver.com/history.php 547 o Null FTP (supports XCRC, XMD5, XSHA) 548 http://www.sharewareconnection.com/null-ftp-client-pro.htm 549 o Orenosv FTP Client (supports XCRC, XMD5) 550 http://www.orenosv.com/orenosv/ftpcli_en.html 551 o ProFTPD module mod_digest (supports XCRC, XMD5, XSHA1, SHA256) 552 http://www.smartftp.com/oss/proftpd/mod_digest.html 553 o PSFTPd Secure FTP Server (supports XCRC, XMD5, XSHA) 554 http://www.psftp.de/psftpd_fo.php 555 o Quick 'n Easy FTP Server (supports XCRC) http:// 556 www.pablosoftwaresolutions.com/html/ 557 quick__n_easy_ftp_server_pro.html 558 o RaidenFTPD32 FTP server (supports XCRC, XMD5) 559 o Robo-FTP Server (supports XCRC, XMD5, XSHA1) 560 http://kb.robo-ftp.com/change_log/show/61 561 o SyncBackPro and SyncBackSE (supports XCRC) 562 http://www.2brightsparks.com/syncback/sbpro-changes.html 563 o Secure FTP Factory (supports XCRC) 564 o Serv-U FTP Server (supports XCRC) http://www.serv-u.com/help/ 565 serv_u_help/additional_ftp_commands_supported_by_serv_u.htm 566 o SmartFTP client (supports XCRC, XMD5, XSHA, CKSM) 567 http://www.smartftp.com/features/ 568 o Starksoft Ftp Component for .NET / Mono (supports XCRC, XMD5, 569 XSHA1) http://www.starksoft.com/prod_ftp.html 570 o Titan FTP Server (supports XCRC) 571 o Turbo FTP (supports XCRC) 572 o WISE-FTP (supports XCRC) http://www.wise-ftp.com/news/ 573 o WS_FTP client / server (supports XSHA1, server also XMD5, XSHA1, 574 XSHA256, XSHA512) http://ipswitchft.custhelp.com/app/answers/ 575 detail/a_id/671/kw/xmd5/r_id/166/sno/1 576 o wuftpd (supports SITE CHECKMETHOD/SITE CHECKSUM) 577 o wzdFTPd (supports XCRC, XMD5) 578 http://www.wzdftpd.net/wiki/index.php/Commands 579 o Zalman FTP Client (supports XCRC) 580 http://www.zalmansoftware.com/download.html 581 o zFTPServer 583 Appendix C. Document History 585 [[ to be removed by the RFC editor before publication as an RFC. ]] 587 Known issues concerning this draft: 588 o Section needs improvement: which files should a server process a 589 HASH command for a logged in user? 591 draft-ietf-ftpext2-hash-00 : November 24, 2010 592 o FTPEXT2 Working Group. 594 draft-bryan-ftp-hash-08 : October 25, 2010. 595 o New server reply 556: Servers that allow HASH but restrict its use 596 to certain files. 598 draft-bryan-ftp-hash-07 : August 5, 2010. 599 o Clarify that HASH is only for files, not directories. 601 draft-bryan-ftp-hash-06 : July 9, 2010. 602 o Change server reply format. 604 draft-bryan-ftp-hash-05 : June 29, 2010. 605 o Add Basic Tokens and Server Replies subsections from RFC 3659. 607 draft-bryan-ftp-hash-04 : June 11, 2010. 608 o User-PI usage and command errors sections updated. 610 draft-bryan-ftp-hash-03 : May 21, 2010. 611 o List of non-standard checksum and hash commands and their 612 implementations. 614 draft-bryan-ftp-hash-02 : April 16, 2010. 615 o Error codes section. 617 draft-bryan-ftp-hash-01 : April 7, 2010. 618 o Changing HASH algorithm with OPTS. 619 o Reference RFC 5797 and add IANA Considerations section. 620 o Informative Reference to expired Internet Draft 621 (draft-twine-ftpmd5) which attempted to address this issue (it 622 only supported one hash, MD5). 624 draft-bryan-ftp-hash-00 : October 19, 2009. 625 o Initial draft. 627 Authors' Addresses 629 Anthony Bryan 630 Pompano Beach, FL 631 USA 633 Email: anthonybryan@gmail.com 634 URI: http://www.metalinker.org 636 Tim Kosse 638 Email: tim.kosse@filezilla-project.org 639 URI: http://filezilla-project.org/ 641 Daniel Stenberg 643 Email: daniel@haxx.se 644 URI: http://www.haxx.se/