idnits 2.17.1 draft-bryan-ftp-hash-01.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 (April 7, 2010) is 5104 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: 0 errors (**), 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 D. Stenberg 5 Expires: October 9, 2010 April 7, 2010 7 FTP Extensions for Cryptographic Hashes 8 draft-bryan-ftp-hash-01 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 October 9, 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. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 59 3. The HASH Command (HASH) . . . . . . . . . . . . . . . . . . . . 3 60 3.1. FEAT response for HASH . . . . . . . . . . . . . . . . . . 4 61 3.2. Changing the HASH algorithm . . . . . . . . . . . . . . . . 5 62 4. Command Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Implementation Requirements . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 7 70 Appendix B. List of Implementations with Non-standard 71 Cryptographic Hash Command . . . . . . . . . . . . . . 8 72 Appendix C. Document History . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The File Transfer Protocol [RFC0959] does not offer any method to 78 verify the integrity of a transferred file, nor can two files be 79 compared against each other without actually transferring them first. 80 Cryptographic hashes are a possible solution to this problem. In the 81 past, several attempts have been made to add commands to obtain 82 checksums and hashes, however none have been formally specified, 83 leading to non-interoperability and confusion. To solve these 84 issues, this document specifies a new FTP command to be used by 85 clients to request cryptographic hashes of files. HTTP has a similar 86 feature named Instance Digests [RFC3230] which allows a client to 87 request the cryptographic hash of a file. 89 [[ Discussion of this draft should take place on 90 apps-discuss@ietf.org. ]] 92 1.1. Examples 94 Example of HASH client request: 96 HASH filename.ext 98 HASH server response with Positive Completion code and the requested 99 hash using the currently selected algorithm: 101 213 80bc95fd391772fa61c91ed68567f0980bb45fd9 103 2. Notational Conventions 105 This specification describes conformance of FTP Extensions for 106 cryptographic hashes. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in BCP 14, [RFC2119], as 111 scoped to those conformance targets. 113 This document also uses notation defined in STD 9, [RFC0959]. 115 Syntax required is defined using the Augmented BNF defined in 116 [RFC5234]. 118 3. The HASH Command (HASH) 120 The HASH command allows for requesting the cryptographic hash of a 121 file. 123 The syntax for the HASH command is: 125 hash = "HASH" SP 127 As with all FTP commands, the "HASH" command label is interpreted in 128 a case-insensitive manner. 130 The HASH command keyword MUST be followed by a single space (ASCII 131 32) followed by the pathname. 133 The pathname argument should reference the same file as other file 134 based commands such as STOR or RETR which the same argument would 135 reference. 137 The text returned in response to the HASH command MUST be: 139 hash-response = "213" SP 1*HEXDIGIT CRLF 141 All hash values MUST be encoded in lowercase hexadecimal format. 143 The standard negative error codes 500 and 501 are sufficient to 144 handle all errors involving the HASH command (e.g., syntax errors). 145 Response code 550 is used if the file can not be found. Response 146 code 552 is used if the user isn't allowed to use the HASH command. 147 Response code 450 is used to indicate the server is busy, e.g. 148 already hashing other files yet inviting the client to retry in 149 future. 151 The HASH command is useful for files transmitted in Image type mode 152 (TYPE I) and Stream transfer mode (MODE S). 154 3.1. FEAT response for HASH 156 A server that supports HASH should advertise it in FEAT response 157 [RFC2389] with a list of all supported hash algorithms in a semicolon 158 separated list. The hash algorithm that is currently selected is 159 marked with an asterisk. In the example below, the "C>" lines are 160 commands from user-PI to server-PI, the "S>" lines are server-PI 161 replies. 163 C> feat 164 S> 211-Extensions supported: 165 S> SIZE 166 S> COMPRESSION 167 S> HASH SHA-1*;MD5 168 S> MDTM 169 S> 211 END 171 The IANA registry named "Hash Function Textual Names" defines values 172 for hash types. Hash names should be presented in uppercase, but 173 comparisons should be case-insensitive, e.g. MD5, md5, Md5 are all 174 the same. 176 hash-feat = SP "HASH" SP hashlist CRLF 177 hashlist = 1*( hashname ["*"] ";" ) 178 hashtype = 1*( hchar ) 179 hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / "," 181 3.2. Changing the HASH algorithm 183 To query the current hash algorithm and to change it, the OPTS 184 command as defined in [RFC2389] is used with HASH as the first 185 argument. If no second argument is passed, OPTS HASH simply returns 186 the currently selected hash algorithm. To change the algorithm, a 187 valid hashtype has to be given as second argument. If the command is 188 successful, all future calls to HASH until the next successful OPTS 189 HASH command or until the session is reinitialized (REIN) will use 190 the selected hash algorithm. 192 C> OPTS HASH 193 S> 200 SHA-1 194 C> OPTS HASH SHA-512 195 S> 200 SHA-512 196 C> OPTS HASH CRC-37 197 S> 501 Unknown algorithm, current selection not changed 199 hashopts-cmd = "OPTS HASH" [ SP hashtype ] CRLF 200 hashopts-response = "200" SP hashtype CRLF 202 4. Command Usage 204 Client requests the cryptographic hash of a file with HASH command. 205 Server replies with cryptographic hash of file. Client downloads 206 file. Client hashes the downloaded file and compares its hash to the 207 hash obtained from the server. This command could also be used to 208 verify that an uploaded file is an exact copy. 210 5. IANA Considerations 212 This new command is added to the "FTP Commands and Extensions" 213 registry created by [RFC5797]. 215 Command Name: HASH 217 Description: Cryptographic Hash of a file 219 FEAT String: HASH 221 Command Type: Service execution 223 Conformance Requirements: Optional 225 Reference: This specification 227 6. Implementation Requirements 229 All conforming implementations MUST at least support the SHA-1 230 algorithm. Implementations SHOULD NOT make any algorithm the default 231 that is known to be weaker than SHA-1. Support for any additional 232 algorithms is optional. 234 7. Security Considerations 236 Calculating a file's hash is a CPU intensive operation and can easily 237 consume the available disk I/O resources. If the HASH command isn't 238 implemented carefully, a server could be vulnerable to a denial of 239 service attack. On an affected server a malicious user could, for 240 example, continuously send HASH commands over multiple connections 241 and thus consume most of the FTP server's CPU and disk I/O resources, 242 leaving little room for other operations. To mitigate this risk, a 243 server SHOULD cache the calculated hashes so that the hash of a file 244 is only calculated once even if multiple hash requests are sent for 245 that file. 247 The performance of commonly used hard disk drives is adversely 248 affected by the amount of time the device needs to reposition its 249 read-and-write heads. A server SHOULD therefore avoid hashing 250 multiple files at the same time which are located on the same 251 physical media and SHOULD instead hash them sequentially. A possible 252 solution is to use the 450 reply code of HASH to indicate that the 253 server is already busy with another HASH operation. 255 In addition, the HASH command can be used to draw conclusions about 256 the contents of a file. If the hash of a file on some server matches 257 the hash of some known, local file, both files are likely identical. 258 To prevent this scenario it suffices to limit use of the HASH command 259 to users who would already be able to download the file. 261 8. References 263 8.1. Normative References 265 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 266 STD 9, RFC 0959, October 1985. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 272 the File Transfer Protocol", RFC 2389, August 1998. 274 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 275 Specifications: ABNF", STD 68, RFC 5234, January 2008. 277 8.2. Informative References 279 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 280 RFC 3230, January 2002. 282 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 283 Registry", RFC 5797, March 2010. 285 [draft-twine-ftpmd5] 286 Twine, J., "The MD5 and MMD5 FTP Command Extensions", 287 draft-twine-ftpmd5-00 (work in progress), May 2002. 289 Appendix A. Acknowledgements and Contributors 291 Thanks to John C. Klensin, Alfred Hoenes, Daniel Stenberg, and James 292 Twine. 294 Appendix B. List of Implementations with Non-standard Cryptographic 295 Hash Command 297 [[ to be removed by the RFC editor before publication as an RFC. ]] 299 At least one previous Internet Draft [draft-twine-ftpmd5] attempted 300 to address this issue (it only supported one hash, MD5). 302 An incomplete list of FTP clients and servers that have implemented 303 multiple commands (XMD5, XSHA1, SITE SHOHASH, etc) that are not 304 formally specified, leading to non-interoperability and confusion. 306 o Akamai NetStorage p17-18 307 http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf 308 o Apache Ftp Server (supports draft-twine-ftpmd5) 309 http://cwiki.apache.org/FTPSERVER/documentation.html 310 o Cerberus FTP server http://www.softpedia.com/progChangelog/ 311 Cerberus-FTP-Server-Changelog-1904.html 312 o FileCOPA FTP Server 313 http://www.filecopa-ftpserver.com/features.html 314 o FireFTP http://fireftp.mozdev.org/features.html 315 o Gene6 FTP Server 316 http://www.g6ftpserver.com/en/information#features 317 o GoldenGate FTP (Ftp Full Java Server) 318 o IceWarp FTP Server http://www.icewarp.com/products/ftp_server/ 319 o JAFS http://www.sbbi.net/site/jafs/features.html 320 o MOVEit DMZ 321 o Nofeel FTP server http://www.nftpserver.com/history.php 322 o Null FTP 323 http://www.sharewareconnection.com/null-ftp-client-pro.htm 324 o ProFTPD module mod_digest 325 http://www.smartftp.com/oss/proftpd/mod_digest.html 326 o SmartFTP client http://www.smartftp.com/features/ 327 o Starksoft Ftp Component for .NET / Mono 328 http://www.starksoft.com/prod_ftp.html 329 o RaidenFTPD32 FTP server 330 o WS_FTP client / server http://ipswitchft.custhelp.com/app/answers/ 331 detail/a_id/671/kw/xmd5/r_id/166/sno/1 332 o wuftpd ('SITE CHECKMETHOD' and 'SITE CHECKSUM') 333 o zFTPServer 335 Appendix C. Document History 337 [[ to be removed by the RFC editor before publication as an RFC. ]] 339 Known issues concerning this draft: 341 o Local HASH command: "Toggles number sign (#) printing for each 342 data block that is transferred." 343 o Underspecification of the representation of the file that shall 344 undergo the hash calculation. 345 o Correct response code to use for completion and errors. 346 o Need to include some more general advice on algorithms just in 347 case algorithm X is found to be broken the day after this draft is 348 released. 349 o Possibly we should suggest that servers calculate the hash numbers 350 in advance, like when the file gets uploaded to avoid the risk of 351 this becoming a DOS-vector. 352 o The FTP server's right to refuse to calculate the hash is of 353 course important to help against DOS risks. 354 o Partial file hashes. 356 -01 : April 7, 2010. 357 o Changing HASH algorithm with OPTS. 358 o Reference RFC 5797 and add IANA Considerations section. 359 o Informative Reference to expired Internet Draft 360 (draft-twine-ftpmd5) which attempted to address this issue (it 361 only supported one hash, MD5). 363 -00 : October 19, 2009. 364 o Initial draft. 366 Authors' Addresses 368 Anthony Bryan 369 Pompano Beach, FL 370 USA 372 Email: anthonybryan@gmail.com 373 URI: http://www.metalinker.org 375 Tim Kosse 377 Email: tim.kosse@filezilla-project.org 378 URI: http://filezilla-project.org/ 380 Daniel Stenberg 382 Email: daniel@haxx.se 383 URI: http://www.haxx.se/