idnits 2.17.1 draft-bryan-ftp-hash-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 23, 2010) is 5147 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3230 (Obsoleted by RFC 9530) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: Experimental March 23, 2010 5 Expires: September 24, 2010 7 FTP Extensions for Cryptographic Hashes 8 draft-bryan-ftp-hash-00 10 Abstract 12 The specification for the File Transfer Protocol does not include 13 methods to obtain cryptographic hashes of files. Cryptographic 14 hashes can be used to identify files and verify intregrity. 15 Unfortunately, because of the desire for this feature, multiple 16 commands that are not formally specified have been implemented in FTP 17 applications leading to non-interoperability and confusion. This 18 specification documents an optional command where FTP clients can 19 request the cryptographic hash of a file from a FTP server. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 24, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 64 3. The HASH Command (HASH) . . . . . . . . . . . . . . . . . . . . 3 65 4. Command Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Appendix A. List of Implementations with Non-standard 72 Cryptographic Hash Command . . . . . . . . . . . . . . 6 73 Appendix B. Acknowledgements and Contributors . . . . . . . . . . 7 74 Appendix C. Document History . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 The specification for the File Transfer Protocol [RFC0959] does not 80 include methods to obtain cryptographic hashes of files. 81 Cryptographic hashes can be used to identify files and verify 82 integrity. Unfortunately, because of the desire for this feature, 83 multiple commands that are not formally specified have been 84 implemented in FTP applications leading to non-interoperability and 85 confusion. This specification documents an optional command where 86 FTP clients can request the cryptographic hash of a file from a FTP 87 server. HTTP has a similar feature named Instance Digests [RFC3230] 88 which allows a client to request the cryptographic hash of a file. 90 1.1. Examples 92 Example of HASH client request: 94 HASH SHA-1 filename.ext 96 HASH server response with Positive Completion code and the requested 97 hash: 99 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 101 2. Notational Conventions 103 This specification describes conformance of FTP Extensions for 104 cryptographic hashes. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in BCP 14, [RFC2119], as 109 scoped to those conformance targets. 111 This document also uses notation defined in STD 9, [RFC0959]. 113 Syntax required is defined using the Augmented BNF defined in 114 [RFC5234]. 116 3. The HASH Command (HASH) 118 The HASH command allows for requesting the cryptographic hash of a 119 file. 121 The syntax for the HASH command is: 123 hash = "HASH" SP SP 125 As with all FTP commands, the "HASH" command label is interpreted in 126 a case-insensitive manner. 128 The HASH command keyword MUST be followed by a single space (ASCII 129 32). Following the space, a hash type MUST be present. Another 130 single space (ASCII 32), MUST be followed by the filename. 132 The IANA registry named "Hash Function Textual Names" defines values 133 for hash types. Hash names should be presented in uppercase, but 134 comparisons should be case-insensitive, e.g. MD5, md5, Md5 are all 135 the same. 137 The filename argument should reference the same file as other file 138 based commands such as STOR or RETR which the same argument would 139 reference. 141 The text returned in response to the HASH command MUST be: 143 hash-response = "213" SP 1*HEXDIGIT CRLF 145 All hash values MUST be encoded in lowercase hexadecimal format. 147 The standard negative error codes 500 and 501 are sufficient to 148 handle all errors involving the HASH command (e.g., syntax errors). 149 Response code 550 is used if the user isn't allowed to use the HASH 150 command. Response code 450 is used to indicate the server is busy, 151 e.g. already hashing other files yet inviting the client to retry in 152 future. 154 A server that supports HASH should advertise it in FEAT response 155 [RFC2389] with a list of all supported hash algorithms in a comma 156 separated list. The "C>" lines are commands from user-PI to 157 server-PI, the "S>" lines are server-PI replies. 159 C> feat 160 S> 211-Extensions supported: 161 S> SIZE 162 S> COMPRESSION 163 S> HASH SHA-1,MD5 164 S> MDTM 165 S> 211 END 167 4. Command Usage 169 Client requests the cryptographic hash of a file with HASH command. 170 Server replies with cryptographic hash of file. Client downloads 171 file. Client hashes the downloaded file and compares its hash to the 172 hash obtained from the server. This command could also be used to 173 verify that an uploaded file is an exact copy. 175 5. IANA Considerations 177 None. 179 6. Security Considerations 181 Calculating a file's hash is a CPU intensive operation and can easily 182 consume the available disk I/O resources. If the HASH command isn't 183 implemented carefully, a server could be vulnerable to a denial of 184 service attack. On an affected server a malicious user could for 185 example continuously send HASH commands over multiple connections and 186 thus consume most CPU and disk I/O resources, leaving little room for 187 other operations. To mitigate this risk, a server should cache the 188 calculated hashes so that the hash of a file is only calculated once 189 even if multiple hash requests are sent for that file. 191 The performance of commonly used hard disk drives is adversely 192 affected by the amount of time the device needs to reposition its 193 read-and-write heads. A server should therefore avoid hashing 194 multiple files at the same time which are located on the same 195 physical media and should instead hash them sequentially. A possible 196 solution is to use the 450 reply code of HASH to indicate that the 197 server is already busy with another HASH operation. 199 In addition, the HASH command can be used to draw conclusions about 200 the contents of a file. If the hash of a file on some server matches 201 the hash of some known, local file, both files are likely identical. 202 To prevent this scenario it suffices to limit use of the HASH command 203 to users who would already be able to download the file. 205 7. References 207 7.1. Normative References 209 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 210 STD 9, RFC 0959, October 1985. 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 216 the File Transfer Protocol", RFC 2389, August 1998. 218 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 219 Specifications: ABNF", STD 68, RFC 5234, January 2008. 221 7.2. Informative References 223 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 224 RFC 3230, January 2002. 226 Appendix A. List of Implementations with Non-standard Cryptographic 227 Hash Command 229 [[ to be removed by the RFC editor before publication as an RFC. ]] 231 An incomplete list of FTP clients and servers that have implemented 232 multiple commands (XMD5, XSHA1, SITE SHOHASH, etc) that are not 233 formally specified, leading to non-interoperability and confusion. 235 o Akamai NetStorage p17-18 236 http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf 237 o Cerberus FTP server http://www.softpedia.com/progChangelog/ 238 Cerberus-FTP-Server-Changelog-1904.html 239 o FileCOPA FTP Server 240 http://www.filecopa-ftpserver.com/features.html 241 o FireFTP http://fireftp.mozdev.org/features.html 242 o Gene6 FTP Server 243 http://www.g6ftpserver.com/en/information#features 244 o GoldenGate FTP (Ftp Full Java Server) 245 o IceWarp FTP Server http://www.icewarp.com/products/ftp_server/ 246 o JAFS http://www.sbbi.net/site/jafs/features.html 247 o MOVEit DMZ 248 o Nofeel FTP server http://www.nftpserver.com/history.php 249 o Null FTP 250 http://www.sharewareconnection.com/null-ftp-client-pro.htm 251 o ProFTPD module mod_digest 252 http://www.smartftp.com/oss/proftpd/mod_digest.html 253 o SmartFTP client http://www.smartftp.com/features/ 254 o Starksoft Ftp Component for .NET / Mono 255 http://www.starksoft.com/prod_ftp.html 256 o RaidenFTPD32 FTP server 257 o WS_FTP client / server http://ipswitchft.custhelp.com/app/answers/ 258 detail/a_id/671/kw/xmd5/r_id/166/sno/1 259 o zFTPServer 261 Appendix B. Acknowledgements and Contributors 263 Thanks to John C. Klensin and Alfred Hoenes. 265 Appendix C. Document History 267 [[ to be removed by the RFC editor before publication as an RFC. ]] 269 Known issues concerning this draft: 270 o None known. 272 -00 : October 19, 2009. 273 o Initial draft. 275 Authors' Addresses 277 Anthony Bryan 278 Pompano Beach, FL 279 USA 281 Email: anthonybryan@gmail.com 282 URI: http://www.metalinker.org 284 Tim Kosse 286 Email: tim.kosse@filezilla-project.org 287 URI: http://filezilla-project.org/