[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                             March 23, 2010
Expires: September 24, 2010


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

Abstract

   The specification for the File Transfer Protocol does not include
   methods to obtain cryptographic hashes of files.  Cryptographic
   hashes can be used to identify files and verify intregrity.
   Unfortunately, because of the desire for this feature, multiple
   commands that are not formally specified have been implemented in FTP
   applications leading to non-interoperability and confusion.  This
   specification documents an optional command where FTP clients can
   request the cryptographic hash of a file from a FTP server.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 24, 2010.

Copyright Notice

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




Bryan & Kosse          Expires September 24, 2010               [Page 1]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


   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
   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 BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  The HASH Command (HASH) . . . . . . . . . . . . . . . . . . . . 3
   4.  Command Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Appendix A.  List of Implementations with Non-standard
                Cryptographic Hash Command . . . . . . . . . . . . . . 6
   Appendix B.  Acknowledgements and Contributors  . . . . . . . . . . 7
   Appendix C.  Document History . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7























Bryan & Kosse          Expires September 24, 2010               [Page 2]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


1.  Introduction

   The specification for the File Transfer Protocol [RFC0959] does not
   include methods to obtain cryptographic hashes of files.
   Cryptographic hashes can be used to identify files and verify
   integrity.  Unfortunately, because of the desire for this feature,
   multiple commands that are not formally specified have been
   implemented in FTP applications leading to non-interoperability and
   confusion.  This specification documents an optional command where
   FTP clients can request the cryptographic hash of a file from a FTP
   server.  HTTP has a similar feature named Instance Digests [RFC3230]
   which allows a client to request the cryptographic hash of a file.

1.1.  Examples

   Example of HASH client request:

           HASH SHA-1 filename.ext

   HASH server response with Positive Completion code and the requested
   hash:

           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].

   Syntax required is defined using the Augmented BNF defined in
   [RFC5234].


3.  The HASH Command (HASH)

   The HASH command allows for requesting the cryptographic hash of a
   file.

   The syntax for the HASH command is:




Bryan & Kosse          Expires September 24, 2010               [Page 3]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


           hash = "HASH" SP <hash type> SP <filename>

   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).  Following the space, a hash type MUST be present.  Another
   single space (ASCII 32), MUST be followed by the filename.

   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.

   The filename 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 standard negative error codes 500 and 501 are sufficient to
   handle all errors involving the HASH command (e.g., syntax errors).
   Response code 550 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.

   A server that supports HASH should advertise it in FEAT response
   [RFC2389] with a list of all supported hash algorithms in a comma
   separated list.  The "C>" lines are commands from user-PI to
   server-PI, the "S>" lines are server-PI replies.


           C> feat
           S> 211-Extensions supported:
           S>  SIZE
           S>  COMPRESSION
           S>  HASH SHA-1,MD5
           S>  MDTM
           S> 211 END






Bryan & Kosse          Expires September 24, 2010               [Page 4]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


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

   None.


6.  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 CPU and disk I/O resources, leaving little room for
   other operations.  To mitigate this risk, a 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.  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.


7.  References

7.1.  Normative References

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




Bryan & Kosse          Expires September 24, 2010               [Page 5]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


   [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.

7.2.  Informative References

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


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

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

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

   o  Akamai NetStorage p17-18
      http://pigdogslow.dyndns.org/NetStorage_UserGuide.pdf
   o  Cerberus FTP server http://www.softpedia.com/progChangelog/
      Cerberus-FTP-Server-Changelog-1904.html
   o  FileCOPA FTP Server
      http://www.filecopa-ftpserver.com/features.html
   o  FireFTP http://fireftp.mozdev.org/features.html
   o  Gene6 FTP Server
      http://www.g6ftpserver.com/en/information#features
   o  GoldenGate FTP (Ftp Full Java Server)
   o  IceWarp FTP Server http://www.icewarp.com/products/ftp_server/
   o  JAFS http://www.sbbi.net/site/jafs/features.html
   o  MOVEit DMZ
   o  Nofeel FTP server http://www.nftpserver.com/history.php
   o  Null FTP
      http://www.sharewareconnection.com/null-ftp-client-pro.htm
   o  ProFTPD module mod_digest
      http://www.smartftp.com/oss/proftpd/mod_digest.html
   o  SmartFTP client http://www.smartftp.com/features/
   o  Starksoft Ftp Component for .NET / Mono
      http://www.starksoft.com/prod_ftp.html
   o  RaidenFTPD32 FTP server





Bryan & Kosse          Expires September 24, 2010               [Page 6]


Internet-Draft   FTP Extensions for Cryptographic Hashes      March 2010


   o  WS_FTP client / server http://ipswitchft.custhelp.com/app/answers/
      detail/a_id/671/kw/xmd5/r_id/166/sno/1
   o  zFTPServer


Appendix B.  Acknowledgements and Contributors

   Thanks to John C. Klensin and Alfred Hoenes.


Appendix C.  Document History

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

   Known issues concerning this draft:
   o  None known.

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


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/
















Bryan & Kosse          Expires September 24, 2010               [Page 7]


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