[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-twine-ftpmd5) 00 01 02 03 04 05 06 07 08 draft-ietf-ftpext2-hash

Network Working Group                                           A. Bryan
Internet-Draft                                                  T. Kosse
Intended status: Experimental                                D. Stenberg
Expires: October 18, 2010                                 April 16, 2010


                FTP Extensions for Cryptographic Hashes
                        draft-bryan-ftp-hash-02

Abstract

   The File Transfer Protocol does not offer any method to verify the
   integrity of a transferred file, nor can two files be compared
   against each other without actually transferring them first.
   Cryptographic hashes are a possible solution to this problem.  In the
   past, several attempts have been made to add commands to obtain
   checksums and hashes, however none have been formally specified,
   leading to non-interoperability and confusion.  To solve these
   issues, this document specifies a new FTP command to be used by
   clients to request cryptographic hashes of files.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 18, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Bryan, et al.           Expires October 18, 2010                [Page 1]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   3.  The HASH Command (HASH)  . . . . . . . . . . . . . . . . . . .  4
     3.1.  HASH Command Errors  . . . . . . . . . . . . . . . . . . .  4
     3.2.  FEAT Command Response for HASH Command . . . . . . . . . .  4
     3.3.  Changing the HASH algorithm  . . . . . . . . . . . . . . .  5
   4.  Command Usage  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Implementation Requirements  . . . . . . . . . . . . . . . . .  6
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Acknowledgements and Contributors . . . . . . . . . .  8
   Appendix B.  List of Implementations with Non-standard
                Cryptographic Hash Command  . . . . . . . . . . . . .  8
   Appendix C.  Document History  . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
























Bryan, et al.           Expires October 18, 2010                [Page 2]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


1.  Introduction

   The File Transfer Protocol [RFC0959] does not offer any method to
   verify the integrity of a transferred file, nor can two files be
   compared against each other without actually transferring them first.
   Cryptographic hashes are a possible solution to this problem.  In the
   past, several attempts have been made to add commands to obtain
   checksums and hashes, however none have been formally specified,
   leading to non-interoperability and confusion.  To solve these
   issues, this document specifies a new FTP command to be used by
   clients to request cryptographic hashes of files.  HTTP has a similar
   feature named Instance Digests [RFC3230] which allows a client to
   request the cryptographic hash of a file.

   [[ Discussion of this draft should take place on
   apps-discuss@ietf.org. ]]

1.1.  Example

   Example of HASH client request:

           HASH filename.ext

   HASH server response with Positive Completion code and the requested
   hash using the currently selected algorithm:

           213 80bc95fd391772fa61c91ed68567f0980bb45fd9


2.  Notational Conventions

   This specification describes conformance of FTP Extensions for
   cryptographic hashes.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.

   This document also uses notation defined in STD 9, [RFC0959].  In
   particular, the terms "reply", "user", "file", "pathname", "FTP
   commands", "user-PI", "server-FTP process", "server-PI", "mode",
   "type", and "ASCII", are all used here as defined there.

   In examples, the "C>" lines are commands from user-PI to server-PI,
   and the "S>" lines are server-PI replies.

   Syntax required is defined using the Augmented BNF defined in



Bryan, et al.           Expires October 18, 2010                [Page 3]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   [RFC5234].


3.  The HASH Command (HASH)

   A new command "HASH" is added to the FTP command set to request the
   cryptographic hash of a file from a server-FTP process.

   The syntax for the HASH command is:


           hash = "HASH" SP <pathname>

   As with all FTP commands, the "HASH" command label is interpreted in
   a case-insensitive manner.

   The HASH command keyword MUST be followed by a single space (ASCII
   32) followed by the pathname.

   The pathname argument should reference the same file as other file
   based commands such as STOR or RETR which the same argument would
   reference.

   The text returned in response to the HASH command MUST be:


           hash-response = "213" SP 1*HEXDIGIT CRLF

   All hash values MUST be encoded in lowercase hexadecimal format.

   The HASH command is useful for files transmitted in Image type mode
   (TYPE I) and Stream transfer mode (MODE S).

3.1.  HASH Command Errors

   The standard negative error codes 500 and 501 are sufficient to
   handle errors involving the HASH command (e.g., syntax errors).
   Response code 550 is used if the file can not be found.  Response
   code 552 is used if the user isn't allowed to use the HASH command.
   Response code 450 is used to indicate the server is busy, e.g.
   already hashing other files yet inviting the client to retry in
   future.

3.2.  FEAT Command Response for HASH Command

   A server that supports the HASH command MUST advertise it in FEAT
   response [RFC2389] with a list of all supported hash algorithms in a
   semicolon separated list.  The hash algorithm that is currently



Bryan, et al.           Expires October 18, 2010                [Page 4]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   selected MUST be marked with an asterisk.  This command word is case
   insensitive, but it SHOULD be transmitted in upper case only.  That
   is, the response SHOULD be:


           C> feat
           S> 211-Extensions supported:
           S>  ...
           S>  HASH SHA-1*;MD5
           S>  ...
           S> 211 END

   The ellipses indicate place holders where other features may be
   included, and are not required.  The single space indentation of each
   feature line is mandatory [RFC2389].

   The IANA registry named "Hash Function Textual Names" defines values
   for hash types.  Hash names should be presented in uppercase, but
   comparisons should be case-insensitive, e.g.  MD5, md5, Md5 are all
   the same.


           hash-feat = SP "HASH" SP hashlist CRLF
           hashlist = 1*( hashname ["*"] ";" )
           hashtype = 1*( hchar )
           hchar = ALPHA / DIGIT / "-" / "_" / "/" / "." / ","


3.3.  Changing the HASH algorithm

   To query the current hash algorithm and to change it, the OPTS
   command as defined in [RFC2389] is used with HASH as the first
   argument.  If no second argument is passed, OPTS HASH simply returns
   the currently selected hash algorithm.  To change the algorithm, a
   valid hashtype MUST be given as second argument.  If the command is
   successful, all future calls to HASH until the next successful OPTS
   HASH command or until the session is reinitialized (REIN) will use
   the selected hash algorithm.


           C> OPTS HASH
           S> 200 SHA-1
           C> OPTS HASH SHA-512
           S> 200 SHA-512
           C> OPTS HASH CRC-37
           S> 501 Unknown algorithm, current selection not changed





Bryan, et al.           Expires October 18, 2010                [Page 5]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


           hashopts-cmd = "OPTS HASH" [ SP hashtype ] CRLF
           hashopts-response = "200" SP hashtype CRLF


4.  Command Usage

   Client requests the cryptographic hash of a file with HASH command.
   Server replies with cryptographic hash of file.  Client downloads
   file.  Client hashes the downloaded file and compares its hash to the
   hash obtained from the server.  This command could also be used to
   verify that an uploaded file is an exact copy.


5.  IANA Considerations

   This new command is added to the "FTP Commands and Extensions"
   registry created by [RFC5797].

   Command Name: HASH

   Description: Cryptographic Hash of a file

   FEAT String: HASH

   Command Type: Service execution

   Conformance Requirements: Optional

   Reference: This specification


6.  Implementation Requirements

   All conforming implementations MUST at least support the SHA-1
   algorithm.  Implementations SHOULD NOT make any algorithm the default
   that is known to be weaker than SHA-1.  Support for any additional
   algorithms is optional.


7.  Security Considerations

   Calculating a file's hash is a CPU intensive operation and can easily
   consume the available disk I/O resources.  If the HASH command isn't
   implemented carefully, a server could be vulnerable to a denial of
   service attack.  On an affected server a malicious user could, for
   example, continuously send HASH commands over multiple connections
   and thus consume most of the FTP server's CPU and disk I/O resources,
   leaving little room for other operations.  To mitigate this risk, a



Bryan, et al.           Expires October 18, 2010                [Page 6]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   server SHOULD cache the calculated hashes so that the hash of a file
   is only calculated once even if multiple hash requests are sent for
   that file.

   The performance of commonly used hard disk drives is adversely
   affected by the amount of time the device needs to reposition its
   read-and-write heads.  A server SHOULD therefore avoid hashing
   multiple files at the same time which are located on the same
   physical media and SHOULD instead hash them sequentially.  The FTP
   server's right to refuse to calculate the hash is of course important
   to help against DOS risks.  A possible solution is to use the 450
   reply code of HASH to indicate that the server is already busy with
   another HASH operation.

   In addition, the HASH command can be used to draw conclusions about
   the contents of a file.  If the hash of a file on some server matches
   the hash of some known, local file, both files are likely identical.
   To prevent this scenario it suffices to limit use of the HASH command
   to users who would already be able to download the file.

   Currently, some of the hash types defined in the IANA registry named
   "Hash Function Textual Names" are considered insecure.  These include
   the whole Message Digest family of algorithms which are not suitable
   for cryptographically strong verification.  Malicious people could
   provide files that appear to be identical to another file because of
   a collision, i.e. the weak cryptographic hashes of the intended file
   and a substituted malicious file could match.


8.  References

8.1.  Normative References

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 0959, October 1985.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2389]  Hethmon, P. and R. Elz, "Feature negotiation mechanism for
              the File Transfer Protocol", RFC 2389, August 1998.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.







Bryan, et al.           Expires October 18, 2010                [Page 7]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


8.2.  Informative References

   [RFC3230]  Mogul, J. and A. Van Hoff, "Instance Digests in HTTP",
              RFC 3230, January 2002.

   [RFC5797]  Klensin, J. and A. Hoenes, "FTP Command and Extension
              Registry", RFC 5797, March 2010.

   [draft-twine-ftpmd5]
              Twine, J., "The MD5 and MMD5 FTP Command Extensions",
              draft-twine-ftpmd5-00 (work in progress), May 2002.


Appendix A.  Acknowledgements and Contributors

   Thanks to John C. Klensin, Alfred Hoenes, James Twine, and Robert
   McMurray.


Appendix B.  List of Implementations with Non-standard Cryptographic
             Hash Command

   [[ to be removed by the RFC editor before publication as an RFC. ]]

   At least one previous Internet Draft [draft-twine-ftpmd5] attempted
   to address this issue (it only supported one hash, MD5).

   An incomplete list of FTP clients and servers that have implemented
   multiple commands (XCRC, MD5/MMD5, XMD5, XSHA, XSHA1, XSHA256,
   XSHA512, SITE SHOHASH, SITE CHECKSUM, etc) that are not formally
   specified, leading to non-interoperability and confusion.

   o  Akamai NetStorage (supports SITE CHKHSH/SITE SHOHASH) p17-18
      http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf
   o  Apache Ftp Server (supports MD5, MMD5 from draft-twine-ftpmd5)
      http://cwiki.apache.org/FTPSERVER/documentation.html
   o  Backup4all Pro (supports XCRC)
   o  Backup to FTP (supports XCRC)
   o  BlackMoon FTP Server (supports XCRC)
      http://www.blackmoonftpserver.com/portal/readmore/features.html
   o  C.P.A. Secure (supports XCRC)
      http://www.cpasecure.com/CPASecureVsSecureFTP.html
   o  Cerberus FTP server (supports XCRC, XMD5, XSHA1, XSHA256, XSHA512)
      http://www.softpedia.com/progChangelog/
      Cerberus-FTP-Server-Changelog-1904.html
   o  Core FTP Pro (supports XCRC)





Bryan, et al.           Expires October 18, 2010                [Page 8]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   o  Cross FTP Server (supports MD5/MMD5)
   o  FileCOPA FTP Server (supports XMD5, XSHA1, XCRC)
      http://www.filecopa-ftpserver.com/features.html
   o  File Watchdogs FTP Server (supports XCRC, XMD5, XSHA1, XSHA256,
      XSHA512)
      http://www.filewatchdogs.com/ftpsitehosting/help/15559.htm
   o  FireFTP (supports XMD5, XSHA1)
      http://fireftp.mozdev.org/features.html
   o  FTP Daemon (supports SITE CHECKMETHOD/SITE CHECKSUM)
      http://www.pro-bono-publico.de/projects/ftpd.html
   o  FTP Voyager (supports XCRC) http://www.ftpvoyager.com/XCRC.asp
   o  Gene6 FTP Server
      http://www.g6ftpserver.com/en/information#features
   o  GlobalSCAPE's Secure FTP Server / EFT Server / CuteFTP clients
      (supports XCRC)
   o  GoldenGate FTP (Ftp Full Java Server) (supports XCRC, XMD5, XSHA1)
   o  IceWarp FTP Server http://www.icewarp.com/products/ftp_server/
   o  ICS FTP client (supports XCRC, XMD5)
      http://www.magsys.co.uk/delphi/magics.asp
   o  ioFTPD (supports XCRC)
   o  JAFS (supports XCRC and MD5)
      http://www.sbbi.net/site/jafs/features.html
   o  Kellerman FTP (supports XCRC)
      http://sharptoolbox.com/tools/kellerman-ftp
   o  Limagito FTP server (supports XCRC, XMD5, XSHA1)
      http://www.limagito.com/file-mover-features.html
   o  MOVEit DMZ (supports XSHA1)
   o  Nofeel FTP server (supports XCRC, XMD5, XSHA1)
      http://www.nftpserver.com/history.php
   o  Null FTP (supports XCRC, XMD5, XSHA)
      http://www.sharewareconnection.com/null-ftp-client-pro.htm
   o  Orenosv FTP Client (supports XCRC, XMD5)
      http://www.orenosv.com/orenosv/ftpcli_en.html
   o  ProFTPD module mod_digest (supports XCRC, XMD5, XSHA1, SHA256)
      http://www.smartftp.com/oss/proftpd/mod_digest.html
   o  PSFTPd Secure FTP Server (supports XCRC, XMD5, XSHA)
      http://www.psftp.de/psftpd_fo.php
   o  Quick 'n Easy FTP Server (supports XCRC) http://
      www.pablosoftwaresolutions.com/html/
      quick__n_easy_ftp_server_pro.html
   o  RaidenFTPD32 FTP server (supports XCRC, XMD5)
   o  Robo-FTP Server (supports XCRC, XMD5, XSHA1)
      http://kb.robo-ftp.com/change_log/show/61
   o  SyncBackPro and SyncBackSE (supports XCRC)
      http://www.2brightsparks.com/syncback/sbpro-changes.html
   o  Secure FTP Factory (supports XCRC)





Bryan, et al.           Expires October 18, 2010                [Page 9]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


   o  Serv-U FTP Server (supports XCRC) http://www.serv-u.com/help/
      serv_u_help/additional_ftp_commands_supported_by_serv_u.htm
   o  SmartFTP client (supports XCRC, XMD5, XSHA)
      http://www.smartftp.com/features/
   o  Starksoft Ftp Component for .NET / Mono (supports XCRC, XMD5,
      XSHA1) http://www.starksoft.com/prod_ftp.html
   o  Titan FTP Server (supports XCRC)
   o  Turbo FTP (supports XCRC)
   o  WISE-FTP (supports XCRC) http://www.wise-ftp.com/news/
   o  WS_FTP client / server (supports XSHA1, server also XMD5, XSHA1,
      XSHA256, XSHA512) http://ipswitchft.custhelp.com/app/answers/
      detail/a_id/671/kw/xmd5/r_id/166/sno/1
   o  wuftpd (supports SITE CHECKMETHOD/SITE CHECKSUM)
   o  wzdFTPd (supports XCRC, XMD5)
      http://www.wzdftpd.net/wiki/index.php/Commands
   o  Zalman FTP Client (supports XCRC)
      http://www.zalmansoftware.com/download.html
   o  zFTPServer


Appendix C.  Document History

   [[ to be removed by the RFC editor before publication as an RFC. ]]

   Known issues concerning this draft:
   o  Partial file hashes, similar to the Content-MD5 HTTP Header.
   o  Underspecification of the representation of the file that shall
      undergo the hash calculation.
   o  Possibly we should suggest that servers calculate the hash numbers
      in advance, like when the file gets uploaded to avoid the risk of
      this becoming a DOS-vector.

   -02 : April , 2010.
   o  Error codes section.

   -01 : April 7, 2010.
   o  Changing HASH algorithm with OPTS.
   o  Reference RFC 5797 and add IANA Considerations section.
   o  Informative Reference to expired Internet Draft
      (draft-twine-ftpmd5) which attempted to address this issue (it
      only supported one hash, MD5).

   -00 : October 19, 2009.
   o  Initial draft.







Bryan, et al.           Expires October 18, 2010               [Page 10]


Internet-Draft   FTP Extensions for Cryptographic Hashes      April 2010


Authors' Addresses

   Anthony Bryan
   Pompano Beach, FL
   USA

   Email: anthonybryan@gmail.com
   URI:   http://www.metalinker.org


   Tim Kosse

   Email: tim.kosse@filezilla-project.org
   URI:   http://filezilla-project.org/


   Daniel Stenberg

   Email: daniel@haxx.se
   URI:   http://www.haxx.se/































Bryan, et al.           Expires October 18, 2010               [Page 11]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/