THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| No Format |
|---|
NetworkINTERNET-DRAFT Working Group JRTwine Software, LLC draft-twine-ftpmd5-00.txt M. Allman Request for Comments: 2428 NASA Lewis/Sterling Software Category: Standards Track May, 2002 The 'MD5' and "MMD5" FTP Command Extensions Status of This Document This document is an Internet-Draft S.and Ostermann is subject to all provisions of Section 10 of RFC2026. 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 Ohioa University 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 C. Metzhttp://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies two additions to the File Transfer Protocol (FTP). These additions (new Server commands) would give FTP Servers the ability to generate (or otherwise obtain) and return MD5 checksums for Thethe Innerfiles Net it has available for transfer. It is the author's belief that this would provide a great benefit to the Internet community, because it would allow automated transfer agents, as well as Web Browsers and other "click-to-download" applications to be able to automatically verify the data of a September 1998 downloaded file, and hence be able to detect any data tampering and/or corruption that may occurred while "on the wire", FTP Extensions for IPv6 and NATs Status of this Memoor possibly while the file was on the Server (a virus infection). Copyright Notice This document specifiesis anin Internetthe standardspublic trackdomain. protocol forAny the and all copyright Internet community, and requests discussion and suggestions forprotection that might apply in any jurisdiction is expressly improvementsdisclaimed. Please Comments refer to the current edition ofComments theshould "Internet be directed to OfficialJames ProtocolR. Standards"Twine (STD 1) for the standardization state jtwine@jrtwine.com). J.Twine and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Internet-Draft Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future. 1. Introduction The keywords, such as MUST and SHOULD, found in this document are used as defined in RFC 2119 [Bra97]. The File Transfer Protocol [PR85] only provides the ability to communicate information about IPv4 data connections. FTP assumes network addresses will be 32 bits in length. However, with the deployment of version 6 of the Internet Protocol [DH96] addresses will no longer be 32 bits long. RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. Unfortunately, the mechanism can fail in a multi-protocol environment. During the transition between IPv4 and IPv6, FTP needs the ability to negotiate the network protocol that will be used for data transfer. Allman, et. al. Standards Track [Page 1] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 This document provides a specification for a way that FTP can communicate data connection endpoint information for network protocols other than IPv4. In this specification, the FTP commands PORT and PASV are replaced with EPRT and EPSV, respectively. This document is organized as follows. Section 2 outlines the EPRT command and Section 3 outlines the EPSV command. Section 4 defines the utilization of these two new FTP commands. Section 5 briefly presents security considerations. Finally, Section 6 provides conclusions. 2. The EPRT Command The EPRT command allows for the specification of an extended address for the data connection. The extended address MUST consist of the network protocol as well as the network and transport addresses. The format of EPRT is: EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d> The EPRT command keyword MUST be followed by a single space (ASCII 32). Following the space, a delimiter character (<d>) MUST be specified. The delimiter character MUST be one of the ASCII characters in range 33-126 inclusive. The character "|" (ASCII 124) is recommended unless it coincides with a character needed to encode the network address. The <net-prt> argument MUST be an address family number defined by IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the writing of this document). This number indicates the protocol to be used (and, implicitly, the address length). This document will use two of address family numbers from [RP94] as examples, according to the following table: AF Number Protocol --------- -------- 1 Internet Protocol, Version 4 [Pos81a] 2 Internet Protocol, Version 6 [DH96] The <net-addr> is a protocol specific string representation of the network address. For the two address families specified above (AF Number 1 and 2), addresses MUST be in the following format: AF Number Address Format Example --------- -------------- ------- 1 dotted decimal 132.235.1.2 2 IPv6 string 1080::8:800:200C:417A representations defined in [HD96] Allman, et. al.[Page 1] INTERNET-DRAFT The 'MD5' and "MMD5" FTP Command Extensions May 2002 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Server Requirements . . . . . . . . . . . . . . . . . . . . 3 3.1 Command Format (MD5) . . . . . . . . . . . . . . . . . . . 4 3.1.1 MD5 Examples . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Command Format (MMD5) . . . . . . . . . . . . . . . . . . . 5 3.2.1 MMD5 Examples . . . . . . . . . . . . . . . . . . . . . . 5 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 J.Twine Internet-Draft [Page 2] INTERNET-DRAFT The 'MD5' and "MMD5" FTP Command Extensions May 2002 1. Introduction This Draft is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. 2. Rational FTP is still very much in use on the Internet. These days, some servers make available files that contain the checksums for some of the files that are available. These available checksums allow users to be able to verify the content of the files that they have downloaded. However, this introduces some additional overhead: these MD5 checksums must be manually generated, put into a file, the file placed where it can be accessed. Then, users must manually download the file containing the checksum, generate an MD5 checksum from the file they just downloaded, and (usually) visually compare the two checksums to determine the validity of the file. Having these tasks automated, by making the MD5 checksums available directly from the FTP Server proper, and having file-transfer implementations use them, alleviates some of the user intervention that would otherwise be required. 3. Server Requirements FTP Servers would have to implement a new server-side command, called "MD5", this command would normally generate and return a MD5 for the specified file. Optionally, the FTP Server could also implement the "MMD5" command, which is used to obtain MD5 checksums for multiple files using a single request. (These commands impose no specific or additional syntax on the formatting of a filepath, they use the Server's existing conventions.) The Server implementation is also free to use some form of caching to keep the generated MD5 checksums, so that the MD5 checksum values do not have to be regenerated over and over again when requested. This also allows the Server implementations to maintain some level of security: the Server can expose administrative commands that regenerate the cache of MD5 checksums on command, thus allowing for "known good" checksums to be kept, and would be insensitive to things like the file becoming corrupted or otherwise tampered with after the "known good" MD5 checksum was generated. J.Twine Standards Track Internet-Draft [Page 23] RFCINTERNET-DRAFT 2428 The 'MD5' and "MMD5" FTP Command Extensions May FTP2002 Extensions for IPv6A andServer NATsimplementation could even take that approach Septemberone 1998 step The <tcp-port> argument must be the string representation of the number of the TCP port on which the host is listening for the data connection. The following are sample EPRT commands: EPRT |1|132.235.1.2|6275| EPRT |2|1080::8:800:200C:417A|5282| The first command specifies that the server should use IPv4 to open a data connection to the host "132.235.1.2" on TCP port 6275. The second command specifies that the server should use the IPv6 network protocol and the network address "1080::8:800:200C:417A" to open a TCP data connection on port 5282. Upon receipt of a valid EPRT command, the server MUST return a code of 200 (Command OK). The standard negative error code 500 and 501 [PR85] are sufficient to handle most errors (e.g., syntax errors) involving the EPRT command. However, an additional error code is needed. The response code 522 indicates that the server does not support the requested network protocol. The interpretation of this new error code is: 5yz Negative Completion x2z Connections xy2 Extended Port Failure - unknown network protocol The text portion of the response MUST indicate which network protocols the server does support. If the network protocol is unsupported, the format of the response string MUST be: <text stating that the network protocol is unsupported> \ (prot1,prot2,...,protn) Both the numeric code specified above and the protocol information between the characters '(' and ')' are intended for the software automata receiving the response; the textual message between the numeric code and the '(' is intended for the human user and can be any arbitrary text, but MUST NOT include the characters '(' and ')'. In the above case, the text SHOULD indicate that the network protocol in the EPRT command is not supported by the server. The list of protocols inside the parenthesis MUST be a comma separated list of address family numbers. Two example response strings follow: Network protocol not supported, use (1) Network protocol not supported, use (1,2) Allman, et. al. Standards Track [Page 3] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 3. The EPSV Command The EPSV command requests that a server listen on a data port and wait for a connection. The EPSV command takes an optional argument. The response to this command includes only the TCP port number of the listening connection. The format of the response, however, is similar to the argument of the EPRT command. This allows the same parsing routines to be used for both commands. In addition, the format leaves a place holder for the network protocol and/or network address, which may be needed in the EPSV response in the future. The response code for entering passive mode using an extended address MUST be 229. The interpretation of this code, according to [PR85] is: 2yz Positive Completion x2z Connections xy9 Extended Passive Mode Entered The text returned in response to the EPSV command MUST be: <text indicating server is entering extended passive mode> \ (<d><d><d><tcp-port><d>) The portion of the string enclosed in parentheses MUST be the exact string needed by the EPRT command to open the data connection, as specified above. The first two fields contained in the parenthesis MUST be blank. The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The network protocol used by the data connection will be the same network protocol used by the control connection. In addition, the network address used to establish the data connection will be the same network address used for the control connection. An example response string follows: Entering Extended Passive Mode (|||6446|) The standard negative error codes 500 and 501 are sufficient to handle all errors involving the EPSV command (e.g., syntax errors). When the EPSV command is issued with no argument, the server will choose the network protocol for the data connection based on the protocol used for the control connection. However, in the case of proxy FTP, this protocol might not be appropriate for communication between the two servers. Therefore, the client needs to be able to request a specific protocol. If the server returns a protocol that is not supported by the host that will be connecting to the port, the Allman, et. al. Standards Track [Page 4] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 client MUST issue an ABOR (abort) command to allow the server to close down the listening connection. The client can then send an EPSV command requesting the use of a specific network protocol, as follows: EPSV<space><net-prt> If the requested protocol is supported by the server, it SHOULD use the protocol. If not, the server MUST return the 522 error messages as outlined in section 2. Finally, the EPSV command can be used with the argument "ALL" to inform Network Address Translators that the EPRT command (as well as other data commands) will no longer be used. An example of this command follows: EPSV<space>ALL Upon receipt of an EPSV ALL command, the server MUST reject all data connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et al.). This use of the EPSV command is further explained in section 4. 4. Command Usage For all FTP transfers where the control and data connection(s) are being established between the same two machines, the EPSV command MUST be used. Using the EPSV command benefits performance of transfers that traverse firewalls or Network Address Translators (NATs). RFC 1579 [Bel94] recommends using the passive command when behind firewalls since firewalls do not generally allow incoming connections (which are required when using the PORT (EPRT) command). In addition, using EPSV as defined in this document does not require NATs to change the network address in the traffic as it is forwarded. The NAT would have to change the address if the EPRT command was used. Finally, if the client issues an "EPSV ALL" command, NATs may be able to put the connection on a "fast path" through the translator, as the EPRT command will never be used and therefore, translation of the data portion of the segments will never be needed. When a client only expects to do two-way FTP transfers, it SHOULD issue this command as soon as possible. If a client later finds that it must do a three-way FTP transfer after issuing an EPSV ALL command, a new FTP session MUST be started. Allman, et. al. Standards Track [Page 5] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 5. Security Issues The authors do not believe that these changes to FTP introduce new security problems. A companion Work in Progress [AO98] is a more general discussion of FTP security issues and techniques to reduce these security problems. 6. Conclusions The extensions specified in this paper will enable FTP to operate over a variety of network protocols. References [AO98] Allman, M., and S. Ostermann, "FTP Security Considerations", Work in Progress. [Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994. [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994. [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html Allman, et. al. Standards Track [Page 6] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 Authors' Addresses Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 Phone: (216) 433-6586 EMail: mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman/ Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701 Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu Craig Metz The Inner Net Box 10314-1954 Blacksburg, VA 24062-0314 Phone: (DSN) 754-8590 EMail: cmetz@inner.net Allman, et. al. Standards Track [Page 7] RFC 2428 FTP Extensions for IPv6 and NATs September 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.further: by generating additional MD5 checksums "on the fly" and comparing them to the "known good" values that were stored earlier, the Server would now have the ability to detect file corruption and/or tampering earlier than the user would normally discover. The command would support a full or relative path, so that a directory change would not be necessary in order to obtain the MD5 checksum of a particular file. Of course, the command should normally be restricted to the directory tree and/or files that the connected user would normally have access to. 3.1 Command Format (MD5) The "MD5" command is used to obtain a MD5 checksum for a single file, and is specified as follows: MD5 [Filepath] Possible responses to this command would normally include: 251 [FilePath] E67DED2886048D308532042B777D53CF 500 Command Not Recognized 502 Command Not Implemented 504 Command Not Implemented for the Specified Argument (Note that the returned MD5 checksum is in UPPERCASE.) A successful response of "251" would contain the specified filepath (verbatim) followed by a space (or some amount of whitespace), and then followed by the MD5 checksum value in ASCII format. An error return of "500" would be for an obvious reason: the FTP Server does not recognize the "MD5" command. An error return of "502" would be appropriate if the FTP Server regocnized the command, but did not support it, or the FTP Server administrator disabled it. An error return of "504" would be appropriate if the user requested an MD5 checksum for a directory (for example). 3.1.1 MD5 Examples This first example demonstrates a request for a MD5 checksum of a single file ("C>" is Client input, and "S>" is Server response): C> MD5 filename.ext S> 251 filename.ext E67DED2886048D308532042B777D53CF This second example demonstrates a request for a MD5 checksum of a directory: J.Twine Internet-Draft [Page 4] INTERNET-DRAFT The 'MD5' and "MMD5" FTP Command Extensions May 2002 C> MD5 ".." S> 504 Command Not Implemented for the Specified Argument This third example demonstrates a request for a MD5 checksum of a file using a relative path: C> MD5 "../SomeDir/A File.txt" S> 251 "../SomeDir/A File.txt" 604E67DED8D308B777D53CF532042288 3.2 Command Format (MMD5) The "MMD5" command is used to obtain MD5 checksums for multiple files by a single request. Filepaths are comma separated, and are specified as follows (it is to be considered valid to specify a single filepath with with MMD5 command): MMD5 [Filepath1], [Filepath2] [...] Possible responses to this command would normally include: 252 [FilePath1] E67DED2886048D308532042B777D53CF,[Filepath2] 308536048D20E67D77D53CFED28842B7 [...] 500 Command Not Recognized 502 Command Not Implemented 504 Command Not Implemented for the Specified Argument A successful response of "252" would contain comma separated "groups" of MD5 checksum information. Each group would contain the specified filepath (verbatim) followed by a space (or some amount of whitespace) followed by the MD5 checksum value in ASCII format. An error return of "500" would be the same as described for the "MD5" command. An error return of "502" would be appropriate if the "MMD5" command was not implemented or disabled. An error return of "504" would be the same as described form the "MD5" command, with this exception: of any of the specified filepaths were invalid, the server would return this error code (i.e. it would no MD5 checksums at all). 3.2.1 MMD5 Examples This first example demonstrates a request for a MD5 checksum of a single file: C> MMD5 filename.ext S> 251 filename.ext E67DED2886048D308532042B777D53CF J.Twine Internet-Draft [Page 5] INTERNET-DRAFT The 'MD5' and "MMD5" FTP Command Extensions May 2002 This second example demonstrates a request for the MD5 checksums for two files: C> MMD5 filename.ext, "../SomeDir/A File.txt" S> 252 filename.ext E67DED2886048D308532042B777D53CF, "../SomeDir/A File.txt" 604E67DED8D308B777D53CF532042288 This third example demonstrates a request for the MD5 checksums of a file and a directory: C> MD5 filename.ext, ".." S> 504 Command Not Implemented for the Specified Argument 4. References [1] Postel, J., Reynolds J., "Instructions to RFC Authors", RFC 2223, October 1997 [2] Postel, J., Reynolds J., "FILE TRANSFER PROTOCOL (FTP)", RFC 959, October 1958 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 [4] Various, "Guidelines to Authors of Internet-Drafts", http://www.ietf.org/ietf/1id-guidelines.txt 4. Author's Address James R. Twine JRTwine Software, LLC 379 Shirley Hill Road Goffstown, NH, 03045 (USA) Phone: +1 603-644-1307 EMail: jtwine@jrtwine.com Allman, et. al.J.Twine Standards Track Internet-Draft [Page 86] |