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