idnits 2.17.1 draft-bryan-ftp-hash-05.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 (June 29, 2010) is 5043 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 Network Working Group A. Bryan 3 Internet-Draft T. Kosse 4 Intended status: Standards Track D. Stenberg 5 Expires: December 31, 2010 June 29, 2010 7 File Transfer Protocol HASH Command for Cryptographic Hashes 8 draft-bryan-ftp-hash-05 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 December 31, 2010. 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 10 73 Appendix B. List of Non-standard Cryptographic Hash or 74 Checksum Commands and Implementations . . . . . . . . 11 75 Appendix C. Document History . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 and the requested 103 hash using the currently selected algorithm: 105 S> 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 107 2. Document Conventions 109 This specification describes conformance of File Transfer Protocol 110 Extension for cryptographic hashes. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, [RFC2119], as 115 scoped to those conformance targets. 117 This document also uses notation defined in STD 9, [RFC0959]. In 118 particular, the terms or commands "reply", "user", "file", 119 "pathname", "FTP commands", "user-PI" (user protocol interpreter), 120 "server-FTP process", "server-PI", "mode", "type", "STOR", "RETR", 121 and "ASCII", are all used here as defined there. 123 In the examples of FTP dialogs presented in this document, lines that 124 begin "C> " were sent over the control connection from the user-PI to 125 the server-PI, and lines that begin "S> " were sent over the control 126 connection from the server-PI to the user-PI. In all cases, the 127 prefixes shown above, including the one space, have been added for 128 the purposes of this document, and are not a part of the data 129 exchanged between client and server. 131 Syntax required is defined using the Augmented BNF defined in 132 [RFC5234]. 134 2.1. Basic Tokens 136 This document imports the core definitions given in Appendix B of 137 [RFC5234]. There definitions will be found for basic ABNF elements 138 like ALPHA, DIGIT, SP, etc. To that, the following term is added for 139 use in this document. 141 TCHAR = VCHAR / SP / HTAB ; visible plus white space 143 The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 144 from varying sub-sets of the ASCII character set for use in various 145 commands and responses. 147 Note that in ABNF, string literals are case insensitive. That 148 convention is preserved in this document, and implies that FTP 149 commands and parameters that are added by this specification have 150 values that can be represented in any case. That is, "HASH" is the 151 same as "hash", "Hash", "HaSh", etc., and "ftp.example.com" is the 152 same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. 154 2.2. Server Replies 156 Section 4.2 of [RFC0959] defines the format and meaning of replies by 157 the server-PI to FTP commands from the user-PI. Those reply 158 conventions are used here without change. 160 error-response = error-code SP *TCHAR CRLF 161 error-code = ("4" / "5") 2DIGIT 163 Implementers should note that the ABNF syntax (which was not used in 164 [RFC0959]) used in this document, and other FTP related documents, 165 sometimes shows replies using the one line format. Unless otherwise 166 explicitly stated, that is not intended to imply that multi-line 167 responses are not permitted. Implementers should assume that, unless 168 stated to the contrary, any reply to any FTP command (including QUIT) 169 can be of the multi-line format described in [RFC0959]. 171 Throughout this document, replies will be identified by the three 172 digit code that is their first element. Thus the term "500 reply" 173 means a reply from the server-PI using the three digit code "500". 175 3. The HASH Command (HASH) 177 A new command "HASH" is added to the FTP command set to allow the 178 client to request the cryptographic hash of a file from a server-FTP 179 process. 181 The syntax for the HASH command is: 183 hash-command = "HASH" SP 185 As with all FTP commands, the "HASH" command word is case 186 independent, and MAY be specified in any character case desired. 188 The HASH command keyword MUST be followed by a single space (ASCII 189 32) followed by the pathname. 191 The pathname argument should reference the same file as other file 192 based commands such as STOR or RETR which the same argument would 193 reference. The pathname argument MUST represent a file path, not a 194 directory path. 196 The text returned in response to the HASH command MUST be: 198 hash-response = hash-ok / error-response 199 hash-ok = "213" SP 1*HEXDIGIT CRLF 201 All hash values MUST be encoded in lowercase hexadecimal format. 203 The HASH command uses the currently selected hash algorithm. The 204 currently selected hash algorithm can be determined with FEAT or OPTS 205 HASH, and changed with OPTS HASH. 207 The HASH command is meant to be used for files transmitted in Image 208 type mode (TYPE I) and Stream transfer mode (MODE S). The returned 209 hash MUST be calculated over the raw octet data of the file 210 irrespective of the selected data type, transfer mode or any other 211 state affecting the transfer. In other words, if a client were to 212 download a full file using TYPE I and MODE S and were to calculate 213 the hash on the received octet data, it would be identical to the 214 hash returned by HASH. 216 3.1. FEAT Command Response for HASH Command 218 When replying to the FEAT command [RFC2389], a server-FTP process 219 that supports the HASH command MUST include a feature line indicating 220 that the HASH command is supported, along with a list of all 221 supported hash algorithms in a semicolon separated list. The hash 222 algorithm that is currently selected MUST be marked with an asterisk. 223 The order of hash algorithms is insignificant. This command word is 224 case insensitive, and MAY be sent in any mixture of upper or lower 225 case, however it SHOULD be sent in upper case. That is, the response 226 SHOULD be: 228 C> FEAT 229 S> 211-Extensions supported: 230 S> ... 231 S> HASH SHA-256;SHA-512;SHA-1*;MD5 232 S> ... 233 S> 211 END 235 The ellipses indicate place holders where other features may be 236 included, and are not required. The one-space indentation of the 237 feature lines is mandatory [RFC2389]. 239 The IANA registry named "Hash Function Textual Names" defines values 240 for hash algorithms. Hash names should be presented in uppercase, 241 but comparisons should be case-insensitive, e.g. MD5, md5, Md5 are 242 all the same. 244 hash-feat = SP "HASH" SP hashlist CRLF 245 hashlist = 1*( hashname ["*"] ";" ) 246 hashname = 1*( hchar ) 247 hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / "," 249 3.2. OPTS Parameters for HASH 251 To query the current hash algorithm and to change it, the OPTS 252 command as defined in [RFC2389] is used with HASH as the first 253 argument. 255 If no second argument is passed, OPTS HASH simply returns the 256 currently selected hash algorithm. 258 C> OPTS HASH 259 S> 200 SHA-1 261 To change the algorithm, a valid hash algorithm MUST be given as 262 second argument. A list of valid hash algorithms is available via 263 the FEAT command. If the command is successful, all future calls to 264 HASH until the next successful OPTS HASH command or until the session 265 is reinitialized (REIN) will use the selected hash algorithm. 267 C> OPTS HASH SHA-512 268 S> 200 SHA-512 270 Requesting unknown or unsupported algorithms produces an error 271 response. 273 C> OPTS HASH CRC-37 274 S> 501 Unknown algorithm, current selection not changed 276 The syntax for OPTS HASH: 278 hashopts-cmd = "OPTS HASH" [ SP hashname ] CRLF 279 hashopts-response = hashopts-ok / error-response 280 hashopts-ok = "200" SP hashname CRLF 282 3.3. User-PI usage of HASH 284 The user-PI issues the FEAT command to query the server-PI about 285 which algorithm is currently selected. This also reveals the other 286 algorithms that the server supports. In this example, the SHA-1 287 algorithm is currently selected. 289 C> FEAT 290 S> 211-Extensions supported: 291 S> ... 292 S> HASH SHA-256;SHA-512;SHA-1*;MD5 293 S> ... 294 S> 211 END 296 OPTS HASH is an alternative method for the user-PI to query the 297 server-PI about which algorithm is currently selected. 299 C> OPTS HASH 300 S> 200 SHA-1 302 In this example, we wish to select SHA-256, a different algorithm. 304 C> OPTS HASH SHA-256 305 S> 200 SHA-256 307 The user-PI requests the cryptographic hash of a file with HASH 308 command. Server-PI replies with cryptographic hash of file. 310 C> HASH filename.ext 311 S> 213 f0ad929cd259957e160ea442eb80986b5f01... 313 Client downloads file. Client hashes the downloaded file and 314 compares its hash to the hash obtained from the server. The HASH 315 command could also be used to verify that an uploaded file has the 316 same hash as the local file. 318 3.4. HASH Command Errors 320 The server-PI SHOULD reply with a 500 reply if the HASH command is 321 unrecognized or unimplemented. 323 The server-PI SHOULD reply with a 501 reply to the OPTS HASH command 324 if the user-PI has requested an unknown or unsupported algorithm. 326 The server-PI SHOULD reply with a 550 reply if the HASH command is 327 used on a file that can not be found. 329 The server-PI SHOULD reply with a 552 reply if the user is not 330 allowed to use the HASH command. 332 The server-PI SHOULD reply with a 450 reply if the server is busy, 333 e.g. already hashing other files yet inviting the client to retry in 334 the future. 336 4. IANA Considerations 338 This new command is added to the "FTP Commands and Extensions" 339 registry created by [RFC5797]. 341 Command Name: HASH 343 Description: Cryptographic Hash of a file 344 FEAT String: HASH 346 Command Type: Service execution 348 Conformance Requirements: Optional 350 Reference: This specification 352 5. Implementation Requirements 354 All conforming implementations MUST at least support the SHA-1 355 algorithm [FIPS-180-3]. Implementations SHOULD NOT make any 356 algorithm the default that is known to be weaker than SHA-1. Support 357 for any additional algorithms is OPTIONAL. 359 6. Security Considerations 361 Implementing the HASH command may impose a considerable load on the 362 server, which could lead to denial-of-service attacks. Servers have, 363 however, implemented this for many years, without significant 364 reported difficulties. On an affected server a malicious user could, 365 for example, continuously send HASH commands over multiple 366 connections and thus consume most of the FTP server's resources, 367 leaving little room for other operations. To mitigate this risk, a 368 server SHOULD cache the calculated hashes so that the hash of a file 369 is only calculated once even if multiple hash requests are sent for 370 that file. 372 For performance reasons, a server SHOULD a avoid hashing multiple 373 files at the same time which are located on the same physical media 374 and SHOULD instead hash them sequentially. The FTP server's right to 375 refuse to calculate the hash is of course important to help against 376 denial-of-service risks. A possible solution is to use the 450 reply 377 code of HASH to indicate that the server is already busy with another 378 HASH operation. 380 In addition, the HASH command can be used to draw conclusions about 381 the contents of a file. If the hash of a file on some server matches 382 the hash of some known file, then both files are likely identical. 383 To prevent this scenario it suffices to limit use of the HASH command 384 to users who would already be able to download the file. 386 Currently, some of the hash algorithms defined in the IANA registry 387 named "Hash Function Textual Names" are considered insecure. These 388 include the whole Message Digest family of algorithms that are not 389 suitable for cryptographically strong verification. Malicious people 390 could provide files that appear to be identical to another file 391 because of a collision, i.e., the weak cryptographic hashes of the 392 intended file and a substituted malicious file could match. 394 7. References 396 7.1. Normative References 398 [FIPS-180-3] 399 National Institute of Standards and Technology (NIST), 400 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 401 October 2008. 403 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 404 STD 9, RFC 0959, October 1985. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 410 the File Transfer Protocol", RFC 2389, August 1998. 412 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 413 Specifications: ABNF", STD 68, RFC 5234, January 2008. 415 7.2. Informative References 417 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 418 RFC 3230, January 2002. 420 [RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 422 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 423 Registry", RFC 5797, March 2010. 425 [draft-twine-ftpmd5] 426 Twine, J., "The MD5 and MMD5 FTP Command Extensions", 427 draft-twine-ftpmd5-00 (work in progress), May 2002. 429 Appendix A. Acknowledgements and Contributors 431 Thanks to John C. Klensin, Alfred Hoenes, James Twine, Robert 432 McMurray, Mathias Berchtold, and Tatsuhiro Tsujikawa. 434 Portions of [RFC3659] were wholly reused in this document. 436 Appendix B. List of Non-standard Cryptographic Hash or Checksum 437 Commands and Implementations 439 [[ to be removed by the RFC editor before publication as an RFC. ]] 441 A number of similar checksum or hash commands exist, but are not 442 formally specified, leading to non-interoperability and confusion. 443 The commands, any specifications, and relevant details: 445 o CKSM: GridFTP v2 Protocol Description 446 http://www.ogf.org/documents/GFD.47.pdf Usage: OPTS CKSM 447 CRLF. Supports ADLER32, MD5, CRC32. 448 o MD5/MMD5: Expired Internet Draft [draft-twine-ftpmd5] from 2002. 449 Usage: MD5 Algorithm specific command. Response codes: 450 251 positive completion, 500 Command Not Recognized, 502 Command 451 Not Implemented, 504 Command Not Implemented for the Specified 452 Argument. 453 o SITE CHECKSUM: Usage: SITE check_login SP CHECKSUM SP pathname 454 CRLF. Supports CRC32 and MD5. 455 o SITE SHOHASH: Usage: site shohash [filename]. Supports MD5. 456 Response codes: 200 positive completion. 457 o XCRC: By GlobalSCAPE in 2001. http://help.globalscape.com/help/ 458 secureserver2/File_Integrity_Checking.htm Usage: XCRC 459 SP EP. SP is starting point and EP is ending point in bytes and 460 are optional parameters. Algorithm specific command. Response 461 codes: 250 positive completion, 450 Requested file action not 462 taken. (File is busy), 550 Requested action not taken. (File not 463 found, no read permission, SP or EP not correct). 464 o XMD5: XMD5 SP EP. Similar to XCRC. Algorithm specific 465 command. 466 o XSHA, XSHA1, XSHA256, XSHA512: Usage similar to XCRC, although 467 SP/EP usage unknown. Algorithm specific commands. 469 An incomplete list of FTP clients and servers that have implemented 470 these commands: 472 o Akamai NetStorage (supports SITE CHKHSH/SITE SHOHASH) p17-18 473 http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf 474 o Apache Ftp Server (supports MD5/MMD5 from draft-twine-ftpmd5) 475 http://cwiki.apache.org/FTPSERVER/documentation.html 476 o Backup4all Pro (supports XCRC) 477 o Backup to FTP (supports XCRC) 478 o BlackMoon FTP Server (supports XCRC) 479 http://www.blackmoonftpserver.com/portal/readmore/features.html 480 o C.P.A. Secure (supports XCRC) 481 http://www.cpasecure.com/CPASecureVsSecureFTP.html 483 o Cerberus FTP server (supports XCRC, XMD5, XSHA1, XSHA256, XSHA512) 484 http://www.softpedia.com/progChangelog/ 485 Cerberus-FTP-Server-Changelog-1904.html 486 o Core FTP Pro (supports XCRC) 487 o Cross FTP Server (supports MD5/MMD5) 488 o FileCOPA FTP Server (supports XCRC, XMD5, XSHA1) 489 http://www.filecopa-ftpserver.com/features.html 490 o File Watchdogs FTP Server (supports XCRC, XMD5, XSHA1, XSHA256, 491 XSHA512) 492 http://www.filewatchdogs.com/ftpsitehosting/help/15559.htm 493 o FireFTP (supports XMD5, XSHA1) 494 http://fireftp.mozdev.org/features.html 495 o FTP Daemon (supports SITE CHECKMETHOD/SITE CHECKSUM) 496 http://www.pro-bono-publico.de/projects/ftpd.html 497 o FTP Voyager (supports XCRC) http://www.ftpvoyager.com/XCRC.asp 498 o Gene6 FTP Server 499 http://www.g6ftpserver.com/en/information#features 500 o GlobalSCAPE's Secure FTP Server / EFT Server / CuteFTP clients 501 (supports XCRC) 502 o Globus FTP client / Globus Toolkit(supports CKSM) http:// 503 www.globus.org/toolkit/releasenotes/3.2.0/gridftp_notes.html 504 o GoldenGate FTP (Ftp Full Java Server) (supports XCRC, XMD5, XSHA1) 505 o IceWarp FTP Server http://www.icewarp.com/products/ftp_server/ 506 o ICS FTP client (supports XCRC, XMD5) 507 http://www.magsys.co.uk/delphi/magics.asp 508 o ioFTPD (supports XCRC) 509 o JAFS (supports XCRC and MD5) 510 http://www.sbbi.net/site/jafs/features.html 511 o Kellerman FTP (supports XCRC) 512 http://sharptoolbox.com/tools/kellerman-ftp 513 o Limagito FTP server (supports XCRC, XMD5, XSHA1) 514 http://www.limagito.com/file-mover-features.html 515 o MOVEit DMZ (supports XSHA1) 516 o Nofeel FTP server (supports XCRC, XMD5, XSHA1) 517 http://www.nftpserver.com/history.php 518 o Null FTP (supports XCRC, XMD5, XSHA) 519 http://www.sharewareconnection.com/null-ftp-client-pro.htm 520 o Orenosv FTP Client (supports XCRC, XMD5) 521 http://www.orenosv.com/orenosv/ftpcli_en.html 522 o ProFTPD module mod_digest (supports XCRC, XMD5, XSHA1, SHA256) 523 http://www.smartftp.com/oss/proftpd/mod_digest.html 524 o PSFTPd Secure FTP Server (supports XCRC, XMD5, XSHA) 525 http://www.psftp.de/psftpd_fo.php 526 o Quick 'n Easy FTP Server (supports XCRC) http:// 527 www.pablosoftwaresolutions.com/html/ 528 quick__n_easy_ftp_server_pro.html 530 o RaidenFTPD32 FTP server (supports XCRC, XMD5) 531 o Robo-FTP Server (supports XCRC, XMD5, XSHA1) 532 http://kb.robo-ftp.com/change_log/show/61 533 o SyncBackPro and SyncBackSE (supports XCRC) 534 http://www.2brightsparks.com/syncback/sbpro-changes.html 535 o Secure FTP Factory (supports XCRC) 536 o Serv-U FTP Server (supports XCRC) http://www.serv-u.com/help/ 537 serv_u_help/additional_ftp_commands_supported_by_serv_u.htm 538 o SmartFTP client (supports XCRC, XMD5, XSHA, CKSM) 539 http://www.smartftp.com/features/ 540 o Starksoft Ftp Component for .NET / Mono (supports XCRC, XMD5, 541 XSHA1) http://www.starksoft.com/prod_ftp.html 542 o Titan FTP Server (supports XCRC) 543 o Turbo FTP (supports XCRC) 544 o WISE-FTP (supports XCRC) http://www.wise-ftp.com/news/ 545 o WS_FTP client / server (supports XSHA1, server also XMD5, XSHA1, 546 XSHA256, XSHA512) http://ipswitchft.custhelp.com/app/answers/ 547 detail/a_id/671/kw/xmd5/r_id/166/sno/1 548 o wuftpd (supports SITE CHECKMETHOD/SITE CHECKSUM) 549 o wzdFTPd (supports XCRC, XMD5) 550 http://www.wzdftpd.net/wiki/index.php/Commands 551 o Zalman FTP Client (supports XCRC) 552 http://www.zalmansoftware.com/download.html 553 o zFTPServer 555 Appendix C. Document History 557 [[ to be removed by the RFC editor before publication as an RFC. ]] 559 Known issues concerning this draft: 560 o Should HASH support partial file hashes, similar to the Content- 561 MD5 HTTP Header. 562 o Underspecification of the representation of the file that shall 563 undergo the hash calculation. 564 o Should the server response include the algorithm? i.e. "S> 213 565 SHA-256 xxxxxxxxxxxxxxx" 567 -05 : June 29, 2010. 568 o Add Basic Tokens and Server Replies subsections from RFC 3659. 570 -04 : June 11, 2010. 571 o User-PI usage and command errors sections updated. 573 -03 : May 21, 2010. 574 o List of non-standard checksum and hash commands and their 575 implementations. 577 -02 : April 16, 2010. 578 o Error codes section. 580 -01 : April 7, 2010. 581 o Changing HASH algorithm with OPTS. 582 o Reference RFC 5797 and add IANA Considerations section. 583 o Informative Reference to expired Internet Draft 584 (draft-twine-ftpmd5) which attempted to address this issue (it 585 only supported one hash, MD5). 587 -00 : October 19, 2009. 588 o Initial draft. 590 Authors' Addresses 592 Anthony Bryan 593 Pompano Beach, FL 594 USA 596 Email: anthonybryan@gmail.com 597 URI: http://www.metalinker.org 599 Tim Kosse 601 Email: tim.kosse@filezilla-project.org 602 URI: http://filezilla-project.org/ 604 Daniel Stenberg 606 Email: daniel@haxx.se 607 URI: http://www.haxx.se/