idnits 2.17.1 draft-ietf-ftpext2-hash-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2012) is 4385 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: 1 error (**), 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: September 28, 2012 March 27, 2012 7 File Transfer Protocol HASH Command for Cryptographic Hashes 8 draft-ietf-ftpext2-hash-03 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 Editorial Note (To be removed by RFC Editor) 24 Discussion of this draft should take place on the FTPEXT2 working 25 group mailing list (ftpext@ietf.org). The current issues list is at 26 and related 27 documents (including fancy diffs) can be found at 28 . 30 The changes in this draft are summarized in Appendix C. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 28, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4 71 3. The HASH Command (HASH) . . . . . . . . . . . . . . . . . . . 5 72 3.1. FEAT Command Response for HASH Command . . . . . . . . . . 6 73 3.2. OPTS Parameters for HASH . . . . . . . . . . . . . . . . . 7 74 3.3. Partial File Hashes with RANG . . . . . . . . . . . . . . 7 75 3.4. User-PI usage of HASH . . . . . . . . . . . . . . . . . . 8 76 3.5. HASH Command Errors . . . . . . . . . . . . . . . . . . . 9 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 5. Implementation Requirements . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 12 84 Appendix B. List of Non-standard Cryptographic Hash or 85 Checksum Commands and Implementations . . . . . . . . 12 86 Appendix C. Document History . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The File Transfer Protocol [RFC0959] does not offer any method to 92 verify the integrity of a transferred file, nor can two files be 93 compared against each other without actually transferring them first. 94 Cryptographic hashes are a possible solution to this problem. In the 95 past, several attempts have been made to add commands to obtain 96 checksums and hashes, however none have been formally specified, 97 leading to non-interoperability and confusion. (See Appendix B for 98 more information). To solve these issues, this document specifies a 99 new FTP command to be used by clients to request cryptographic hashes 100 of files. HTTP has a similar feature named Instance Digests 101 [RFC3230] which allows a client to request the cryptographic hash of 102 a file. 104 1.1. Example 106 Example of HASH client request: 108 C> HASH filename.ext 110 Server response to HASH command by client with Positive Completion 111 code, the currently selected HASH algorithm, a byte range including 112 the start point and end point of the file that was hashed, the 113 requested hash of the file, and the pathname of the file: 115 S> 213 SHA-1 0-255 80bc95fd391772fa61c91ed68567f09... filename.ext 117 Note: In some examples, the number of characters returned for the 118 hash of a file has been shortened for line length reasons. These end 119 in "...". 121 2. Document Conventions 123 This specification describes conformance of File Transfer Protocol 124 Extension for cryptographic hashes. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in BCP 14, [RFC2119], as 129 scoped to those conformance targets. 131 This document also uses notation defined in STD 9, [RFC0959]. In 132 particular, the terms or commands "reply", "user", "file", "FTP 133 commands", "user-PI" (user protocol interpreter), "server-FTP 134 process", "server-PI", "mode", "Image type", "Stream transfer mode", 135 "type", "STOR", "RETR", and "ASCII", are all used here as defined 136 there. The term "pathname" is used as defined in Section 2.2 of 137 [RFC3659]. 139 In the examples of FTP dialogs presented in this document, lines that 140 begin "C> " were sent over the control connection from the user-PI to 141 the server-PI, and lines that begin "S> " were sent over the control 142 connection from the server-PI to the user-PI. In all cases, the 143 prefixes shown above, including the one space, have been added for 144 the purposes of this document, and are not a part of the data 145 exchanged between client and server. 147 Syntax required is defined using the Augmented BNF defined in 148 [RFC5234]. 150 2.1. Basic Tokens 152 This document imports the core definitions given in Appendix B of 153 [RFC5234]. There definitions will be found for basic ABNF elements 154 like ALPHA, DIGIT, SP, etc. To that, the following term is added for 155 use in this document. 157 TCHAR = VCHAR / SP / HTAB ; visible plus white space 159 The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 160 from varying sub-sets of the ASCII character set for use in various 161 commands and responses. 163 Note that in ABNF, string literals are case insensitive. That 164 convention is preserved in this document, and implies that FTP 165 commands and parameters that are added by this specification have 166 values that can be represented in any case. That is, "HASH" is the 167 same as "hash", "Hash", "HaSh", etc., and "ftp.example.com" is the 168 same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. 170 2.2. Server Replies 172 Section 4.2 of [RFC0959] defines the format and meaning of replies by 173 the server-PI to FTP commands from the user-PI. Those reply 174 conventions are used here without change. 176 error-response = error-code SP *TCHAR CRLF 177 error-code = ("4" / "5") 2DIGIT 179 Implementers should note that the ABNF syntax (which was not used in 180 [RFC0959]) used in this document, and other FTP related documents, 181 sometimes shows replies using the one line format. Unless otherwise 182 explicitly stated, that is not intended to imply that multi-line 183 responses are not permitted. Implementers should assume that, unless 184 stated to the contrary, any reply to any FTP command (including QUIT) 185 can be of the multi-line format described in [RFC0959]. 187 Throughout this document, replies will be identified by the three 188 digit code that is their first element. Thus the term "500 reply" 189 means a reply from the server-PI using the three digit code "500". 191 3. The HASH Command (HASH) 193 A new command "HASH" is added to the FTP command set to allow the 194 client to request the cryptographic hash of a file from a server-FTP 195 process. 197 The syntax for the HASH command is: 199 hash-command = "HASH" SP 201 As with all FTP commands, the "HASH" command word is case 202 independent, and MAY be specified in any character case desired. 204 The HASH command keyword MUST be followed by a single space (ASCII 205 32) followed by the pathname. 207 The pathname argument should reference the same file as other file 208 based commands such as STOR or RETR which the same argument would 209 reference. The pathname argument MUST represent a file path, not a 210 directory path. 212 The text returned in response to the HASH command MUST be: 214 hash-response = hash-ok / error-response 215 hash-ok = "213" SP hashname SP start-point "-" end-point SP filehash SP CRLF 216 hashname = 1*( hchar ) 217 start-point = 1*DIGIT 218 end-point = 1*DIGIT 219 filehash = 1*HEXDIGIT 220 hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / "," 222 The and make up the byte range of the file 223 that has been hashed, and MUST be included. 225 All hash values MUST be encoded in lowercase hexadecimal format. 227 The HASH command uses the currently selected hash algorithm. The 228 currently selected hash algorithm can be determined with FEAT or OPTS 229 HASH, and changed with OPTS HASH. 231 The HASH command is meant to be used for files transmitted in Image 232 type mode (TYPE I) and Stream transfer mode (MODE S). The returned 233 hash MUST be calculated as if a client were to download the full file 234 using TYPE I and MODE S and were to calculate the hash on the 235 received octet data. In other words, if a client were to download a 236 full file using TYPE I and MODE S and were to calculate the hash on 237 the received octet data, it would be identical to the hash returned 238 by HASH. 240 Depending on multiple conditions, the final server response to a HASH 241 command could take long time, so a server could output a "213-" line 242 every 5-10 seconds to avoid the connection being idle and silent. 244 3.1. FEAT Command Response for HASH Command 246 When replying to the FEAT command [RFC2389], a server-FTP process 247 that supports the HASH command MUST include a feature line indicating 248 that the HASH command is supported, along with a list of all 249 supported hash algorithms in a semicolon separated list. The hash 250 algorithm that is currently selected MUST be marked with an asterisk. 251 The order of hash algorithms is insignificant. This command word is 252 case insensitive, and MAY be sent in any mixture of upper or lower 253 case, however it SHOULD be sent in upper case. That is, the response 254 SHOULD be: 256 C> FEAT 257 S> 211-Extensions supported: 258 S> ... 259 S> HASH SHA-256;SHA-512;SHA-1*;MD5 260 S> ... 261 S> 211 END 263 The ellipses indicate place holders where other features may be 264 included, and are not required. The one-space indentation of the 265 feature lines is mandatory [RFC2389]. 267 The IANA registry named "Hash Function Textual Names" defines values 268 for hash algorithms. Hash names SHOULD be presented in uppercase, 269 but comparisons should be case-insensitive, e.g. MD5, md5, Md5 are 270 all the same. 272 hash-feat = SP "HASH" SP hashlist CRLF 273 hashlist = 1*( hashname ["*"] ";" ) 274 hashname = 1*( hchar ) 275 hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / "," 277 3.2. OPTS Parameters for HASH 279 To query the current hash algorithm and to change it, the OPTS 280 command as defined in [RFC2389] is used with HASH as the first 281 argument. 283 If no second argument is passed, OPTS HASH simply returns the 284 currently selected hash algorithm. 286 C> OPTS HASH 287 S> 200 SHA-1 289 To change the algorithm, a valid hash algorithm MUST be given as 290 second argument. A list of valid hash algorithms is available via 291 the FEAT command. If the command is successful, all future calls to 292 HASH until the next successful OPTS HASH command or until the session 293 is reinitialized (REIN) will use the selected hash algorithm. 295 C> OPTS HASH SHA-512 296 S> 200 SHA-512 298 Requesting unknown or unsupported algorithms produces an error 299 response. 301 C> OPTS HASH CRC-37 302 S> 501 Unknown algorithm, current selection not changed 304 The syntax for OPTS HASH: 306 hashopts-cmd = "OPTS HASH" [ SP hashname ] CRLF 307 hashopts-response = hashopts-ok / error-response 308 hashopts-ok = "200" SP hashname CRLF 310 3.3. Partial File Hashes with RANG 312 Full files are always hashed by default. 314 Partial file hashes, as opposed to full file hashes, are available by 315 selecting a byte range with the RANG command [draft-bryan-ftp-range] 316 and then performing the HASH command. To reset the byte range and 317 request the HASH of the full file, "RANG 1 0" is issued. 319 Since the server can always reject a HASH request, it can opt to 320 reject partial hashes if it decides that is the correct behavior. 322 3.4. User-PI usage of HASH 324 The user-PI issues the FEAT command to query the server-PI about 325 which algorithm is currently selected. This also reveals the other 326 algorithms that the server supports. In this example, the SHA-1 327 algorithm is currently selected, as indicated by the asterisk. 329 C> FEAT 330 S> 211-Extensions supported: 331 S> ... 332 S> HASH SHA-256;SHA-512;SHA-1*;MD5 333 S> ... 334 S> 211 END 336 OPTS HASH is an alternative method for the user-PI to query the 337 server-PI about which algorithm is currently selected. 339 C> OPTS HASH 340 S> 200 SHA-1 342 In this example, we wish to select SHA-256, a different algorithm. 344 C> OPTS HASH SHA-256 345 S> 200 SHA-256 347 The user-PI requests a byte range of 0-49 with the RANG command, then 348 immediately followed by a request of the cryptographic hash of a file 349 with HASH command. Server-PI replies with the Positive Completion 350 code, the currently selected HASH algorithm, the byte range, the 351 requested hash of the file, and the pathname of the file. 353 C> RANG 0 49 354 C> HASH filename.ext 355 S> 213- 356 S> 213 SHA-256 0-49 169cd22282da7f147cb491e559e9dd... filename.ext 358 Here, no RANG command is issued before HASH, so by default the whole 359 file is hashed. The user-PI requests the cryptographic hash of a 360 file with HASH command. Server-PI replies with the Positive 361 Completion code, the currently selected HASH algorithm, the requested 362 hash of the file, and the pathname of the file. 364 C> HASH filename.ext 365 S> 213- 366 S> 213 SHA-256 0-99 f0ad929cd259957e160ea442eb8098... filename.ext 368 Client downloads file. Client hashes the downloaded file and 369 compares its hash to the hash obtained from the server. The HASH 370 command could also be used to verify that an uploaded file has the 371 same hash as the local file. 373 3.5. HASH Command Errors 375 The server-PI SHOULD reply with a 450 reply if the server is busy, 376 e.g. already hashing other files yet inviting the client to retry in 377 the future. 379 Where the HASH command is unrecognized or there is a syntax error in 380 parameters or arguments, a 500 or 501 reply can be sent by the 381 server-PI, as specified in [RFC0959]. 383 The server-PI SHOULD reply with a 501 reply to the OPTS HASH command 384 if the user-PI has requested an unknown or unsupported algorithm. 386 The server-PI SHOULD reply with a 550 reply if the HASH command is 387 used on a file that can not be found. 389 The server-PI SHOULD reply with a 551 reply if the server-PI can not 390 calculate the hash of a file because it is unable to deliver the file 391 with TYPE I and MODE S. 393 The server-PI SHOULD reply with a 552 reply if the user is not 394 allowed to use the HASH command. 396 The server-PI SHOULD reply with a 553 reply if the user requests the 397 HASH of a directory, which is not allowed. 399 The server-PI SHOULD reply with a 556 reply if the HASH command is 400 used on a file that cannot be processed for policy reasons. (For 401 example, if the file size exceeds the server's hashing policy.) 403 4. IANA Considerations 405 This new command is added to the "FTP Commands and Extensions" 406 registry created by [RFC5797]. 408 Command Name: HASH 410 Description: Cryptographic Hash of a file 412 FEAT String: HASH 414 Command Type: Service execution 416 Conformance Requirements: Optional 418 Reference: This specification 420 5. Implementation Requirements 422 All conforming implementations MUST at least support the SHA-1 423 algorithm [FIPS-180-3]. Implementations SHOULD NOT make any 424 algorithm the default that is known to be weaker than SHA-1. Support 425 for any additional algorithms is OPTIONAL. 427 6. Security Considerations 429 The server MUST only allow the HASH command to be processable for 430 files which the logged in user has a right to access. 432 Implementing the HASH command may impose a considerable load on the 433 server, which could lead to denial-of-service attacks. Servers have, 434 however, implemented this for many years, without significant 435 reported difficulties. On an affected server a malicious user could, 436 for example, continuously send HASH commands over multiple 437 connections and thus consume most of the FTP server's resources, 438 leaving little room for other operations. To mitigate this risk, a 439 server MAY cache the calculated hashes so that the hash of a file is 440 only calculated once even if multiple hash requests are sent for that 441 file, provided it updates or invalidates the cached hash when the 442 content of the corresponding file changes. A server may refuse to 443 process a HASH command for many reasons, one of which may be a 444 suspected denial-of-service attack. A client MUST be able to 445 understand that refusal to process HASH commands may be transient (if 446 indicated by a 450 response) and MAY be honoured later if the server 447 so decides. A client MUST allow that a HASH command might take a 448 reasonably long time to complete. 450 Server operators might wish to allow the HASH command but restrict 451 its use to certain files, for example, if the file size exceeds the 452 server's hashing policy. A client MUST be able to understand that 453 refusal to process HASH commands may be permanent (if indicated by a 454 556 response) and will not be honoured later. 456 In addition, the HASH command can be used to draw conclusions about 457 the contents of a file. If the hash of a file on some server matches 458 the hash of some known file, then both files are likely identical. 459 By uploading a file, running HASH against it and running HASH against 460 another file location, the client could infer some filesystem 461 deployment information (e.g. that there is a logical link between a 462 pair of directories in the tree). This is probably not an issue if 463 the user has access to both branches of the directory tree, but there 464 is the possibility that this information is exposable. To prevent 465 this scenario it suffices to limit use of the HASH command to users 466 who uploaded the file or would already be able to download the file. 468 This mechanism simply allows the FTP protocol to expose HASH values 469 of files, using the currently chosen mechanism, accessible to the 470 server by the client. The suitability or otherwise of a specific 471 hash algorithm for a specific purpose is an implementation decision. 473 7. References 475 7.1. Normative References 477 [FIPS-180-3] 478 National Institute of Standards and Technology (NIST), 479 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 480 October 2008. 482 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 483 STD 9, RFC 0959, October 1985. 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 489 the File Transfer Protocol", RFC 2389, August 1998. 491 [RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 493 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 494 Specifications: ABNF", STD 68, RFC 5234, January 2008. 496 [draft-bryan-ftp-range] 497 Bryan, A., Tsujikawa, T., and D. Stenberg, "File Transfer 498 Protocol RANG Command for Byte Ranges", 499 draft-bryan-ftp-range-04 (work in progress). 501 7.2. Informative References 503 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 504 RFC 3230, January 2002. 506 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 507 Registry", RFC 5797, March 2010. 509 [draft-twine-ftpmd5] 510 Twine, J., "The MD5 and MMD5 FTP Command Extensions", 511 draft-twine-ftpmd5-00 (work in progress), May 2002. 513 Appendix A. Acknowledgements and Contributors 515 This document is a product of the FTPEXT2 working group of the IETF. 517 Thanks to John C. Klensin, Alfred Hoenes, James Twine, Robert 518 McMurray, Mathias Berchtold, Tatsuhiro Tsujikawa, Paul Ford- 519 Hutchinson, and Robert Oslin. 521 Portions of [RFC3659] were wholly reused in this document. 523 Appendix B. List of Non-standard Cryptographic Hash or Checksum 524 Commands and Implementations 526 [[ to be removed by the RFC editor before publication as an RFC. ]] 528 A number of similar checksum or hash commands exist, but are not 529 formally specified, leading to non-interoperability and confusion. 530 The commands, any specifications, and relevant details: 532 o CKSM: GridFTP v2 Protocol Description 533 http://www.ogf.org/documents/GFD.47.pdf Usage: OPTS CKSM 534 CRLF. Supports ADLER32, MD5, CRC32. 535 o MD5/MMD5: Expired Internet Draft [draft-twine-ftpmd5] from 2002. 536 Usage: MD5 Algorithm specific command. Response codes: 537 251 positive completion, 500 Command Not Recognized, 502 Command 538 Not Implemented, 504 Command Not Implemented for the Specified 539 Argument. 540 o SITE CHECKSUM: Usage: SITE check_login SP CHECKSUM SP pathname 541 CRLF. Supports CRC32 and MD5. 542 o SITE SHOHASH: Usage: site shohash [filename]. Supports MD5. 543 Response codes: 200 positive completion. 545 o XCRC: By GlobalSCAPE in 2001. http://help.globalscape.com/help/ 546 secureserver2/File_Integrity_Checking.htm Usage: XCRC 547 SP EP. SP is starting point and EP is ending point in bytes and 548 are optional parameters. Algorithm specific command. Response 549 codes: 250 positive completion, 450 Requested file action not 550 taken. (File is busy), 550 Requested action not taken. (File not 551 found, no read permission, SP or EP not correct). 552 o XMD5: XMD5 SP EP. Similar to XCRC. Algorithm specific 553 command. 554 o XSHA, XSHA1, XSHA256, XSHA512: Usage similar to XCRC, although 555 SP/EP usage unknown. Algorithm specific commands. 557 An incomplete list of FTP clients and servers that have implemented 558 these commands: 560 o Akamai NetStorage (supports SITE CHKHSH/SITE SHOHASH) p17-18 561 http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf 562 o Apache Ftp Server (supports MD5/MMD5 from draft-twine-ftpmd5) 563 http://cwiki.apache.org/FTPSERVER/documentation.html 564 o Backup4all Pro (supports XCRC) 565 o Backup to FTP (supports XCRC) 566 o BlackMoon FTP Server (supports XCRC) 567 http://www.blackmoonftpserver.com/portal/readmore/features.html 568 o C.P.A. Secure (supports XCRC) 569 http://www.cpasecure.com/CPASecureVsSecureFTP.html 570 o Cerberus FTP server (supports XCRC, XMD5, XSHA1, XSHA256, XSHA512) 571 http://www.softpedia.com/progChangelog/ 572 Cerberus-FTP-Server-Changelog-1904.html 573 o Core FTP Pro (supports XCRC) 574 o Cross FTP Server (supports MD5/MMD5) 575 o FileCOPA FTP Server (supports XCRC, XMD5, XSHA1) 576 http://www.filecopa-ftpserver.com/features.html 577 o File Watchdogs FTP Server (supports XCRC, XMD5, XSHA1, XSHA256, 578 XSHA512) 579 http://www.filewatchdogs.com/ftpsitehosting/help/15559.htm 580 o FireFTP (supports XMD5, XSHA1) 581 http://fireftp.mozdev.org/features.html 582 o FTP Daemon (supports SITE CHECKMETHOD/SITE CHECKSUM) 583 http://www.pro-bono-publico.de/projects/ftpd.html 584 o FTP Voyager (supports XCRC) http://www.ftpvoyager.com/XCRC.asp 585 o Gene6 FTP Server 586 http://www.g6ftpserver.com/en/information#features 587 o GlobalSCAPE's Secure FTP Server / EFT Server / CuteFTP clients 588 (supports XCRC) 589 o Globus FTP client / Globus Toolkit(supports CKSM) http:// 590 www.globus.org/toolkit/releasenotes/3.2.0/gridftp_notes.html 592 o GoldenGate FTP (Ftp Full Java Server) (supports XCRC, XMD5, XSHA1) 593 o IceWarp FTP Server http://www.icewarp.com/products/ftp_server/ 594 o ICS FTP client (supports XCRC, XMD5) 595 http://www.magsys.co.uk/delphi/magics.asp 596 o ioFTPD (supports XCRC) 597 o JAFS (supports XCRC and MD5) 598 http://www.sbbi.net/site/jafs/features.html 599 o Kellerman FTP (supports XCRC) 600 http://sharptoolbox.com/tools/kellerman-ftp 601 o Limagito FTP server (supports XCRC, XMD5, XSHA1) 602 http://www.limagito.com/file-mover-features.html 603 o Lobster IntegrationServer (supports XCRC, XSHA1, XMD5; all with SP 604 and EP). 605 o MOVEit DMZ (supports XSHA1) 606 o Nofeel FTP server (supports XCRC, XMD5, XSHA1) 607 http://www.nftpserver.com/history.php 608 o Null FTP (supports XCRC, XMD5, XSHA) 609 http://www.sharewareconnection.com/null-ftp-client-pro.htm 610 o Orenosv FTP Client (supports XCRC, XMD5) 611 http://www.orenosv.com/orenosv/ftpcli_en.html 612 o ProFTPD module mod_digest (supports XCRC, XMD5, XSHA1, SHA256) 613 http://www.smartftp.com/oss/proftpd/mod_digest.html 614 o PSFTPd Secure FTP Server (supports XCRC, XMD5, XSHA) 615 http://www.psftp.de/psftpd_fo.php 616 o Quick 'n Easy FTP Server (supports XCRC) http:// 617 www.pablosoftwaresolutions.com/html/ 618 quick__n_easy_ftp_server_pro.html 619 o RaidenFTPD32 FTP server (supports XCRC, XMD5) 620 o Robo-FTP Server (supports XCRC, XMD5, XSHA1) 621 http://kb.robo-ftp.com/change_log/show/61 622 o SyncBackPro and SyncBackSE (supports XCRC) 623 http://www.2brightsparks.com/syncback/sbpro-changes.html 624 o Secure FTP Factory (supports XCRC) 625 o Serv-U FTP Server (supports XCRC) http://www.serv-u.com/help/ 626 serv_u_help/additional_ftp_commands_supported_by_serv_u.htm 627 o SmartFTP client (supports XCRC, XMD5, XSHA, CKSM) 628 http://www.smartftp.com/features/ 629 o Starksoft Ftp Component for .NET / Mono (supports XCRC, XMD5, 630 XSHA1) http://www.starksoft.com/prod_ftp.html 631 o Titan FTP Server (supports XCRC) 632 o Turbo FTP (supports XCRC) 633 o WISE-FTP (supports XCRC) http://www.wise-ftp.com/news/ 634 o WS_FTP client / server (supports XSHA1, server also XMD5, XSHA1, 635 XSHA256, XSHA512) http://ipswitchft.custhelp.com/app/answers/ 636 detail/a_id/671/kw/xmd5/r_id/166/sno/1 637 o wuftpd (supports SITE CHECKMETHOD/SITE CHECKSUM) 638 o wzdFTPd (supports XCRC, XMD5) 639 http://www.wzdftpd.net/wiki/index.php/Commands 640 o Zalman FTP Client (supports XCRC) 641 http://www.zalmansoftware.com/download.html 642 o zFTPServer 644 Appendix C. Document History 646 [[ to be removed by the RFC editor before publication as an RFC. ]] 648 Known issues concerning this draft: 649 o Should HASH use "MLSx style" responses? S> 213 Hash.SHA- 650 1=80bc95fd3...;Range=0-199; filename.ext 652 draft-ietf-ftpext2-hash-03 : March 27, 2012 653 o Editorial nits. 655 draft-ietf-ftpext2-hash-02 : July 28, 2011 656 o Refinements. 658 draft-ietf-ftpext2-hash-01 : February 1, 2011 659 o Partial file hashes with RANG command. Mandatory byte range in 660 response. "213-" to avoid timeout. 662 draft-ietf-ftpext2-hash-00 : November 24, 2010 663 o FTPEXT2 Working Group. 665 draft-bryan-ftp-hash-08 : October 25, 2010. 666 o New server reply 556: Servers that allow HASH but restrict its use 667 to certain files. 669 draft-bryan-ftp-hash-07 : August 5, 2010. 670 o Clarify that HASH is only for files, not directories. 672 draft-bryan-ftp-hash-06 : July 9, 2010. 673 o Change server reply format. 675 draft-bryan-ftp-hash-05 : June 29, 2010. 676 o Add Basic Tokens and Server Replies subsections from RFC 3659. 678 draft-bryan-ftp-hash-04 : June 11, 2010. 679 o User-PI usage and command errors sections updated. 681 draft-bryan-ftp-hash-03 : May 21, 2010. 682 o List of non-standard checksum and hash commands and their 683 implementations. 685 draft-bryan-ftp-hash-02 : April 16, 2010. 686 o Error codes section. 688 draft-bryan-ftp-hash-01 : April 7, 2010. 689 o Changing HASH algorithm with OPTS. 690 o Reference RFC 5797 and add IANA Considerations section. 691 o Informative Reference to expired Internet Draft 692 (draft-twine-ftpmd5) which attempted to address this issue (it 693 only supported one hash, MD5). 695 draft-bryan-ftp-hash-00 : October 19, 2009. 696 o Initial draft. 698 Authors' Addresses 700 Anthony Bryan 701 Pompano Beach, FL 702 USA 704 Email: anthonybryan@gmail.com 705 URI: http://www.metalinker.org 707 Tim Kosse 709 Email: tim.kosse@filezilla-project.org 710 URI: http://filezilla-project.org/ 712 Daniel Stenberg 714 Email: daniel@haxx.se 715 URI: http://www.haxx.se/