idnits 2.17.1 draft-twine-ftpmd5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Filepath' on line 137 -- Looks like a reference, but probably isn't: 'FilePath' on line 141 -- Looks like a reference, but probably isn't: 'Filepath1' on line 190 -- Looks like a reference, but probably isn't: 'Filepath2' on line 194 -- Looks like a reference, but probably isn't: 'FilePath1' on line 194 == Unused Reference: '1' is defined on line 239, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 242, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 245, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 248, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. '1') (Obsoleted by RFC 7322) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 J. Twine 2 INTERNET-DRAFT JRTwine Software, LLC 3 draft-twine-ftpmd5-00.txt May, 2002 5 The 'MD5' and "MMD5" FTP Command Extensions 7 Status of This Document 9 This document is an Internet-Draft and is subject to all provisions 10 of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use 20 Internet-Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This document specifies two additions to the File Transfer Protocol 32 (FTP). These additions (new Server commands) would give FTP 33 Servers the ability to generate (or otherwise obtain) and return 34 MD5 checksums for the files it has available for transfer. 36 It is the author's belief that this would provide a great benefit 37 to the Internet community, because it would allow automated 38 transfer agents, as well as Web Browsers and other 39 "click-to-download" applications to be able to automatically verify 40 the data of a downloaded file, and hence be able to detect any data 41 tampering and/or corruption that may occurred while "on the wire", 42 or possibly while the file was on the Server (a virus infection). 44 Copyright Notice 46 This document is in the public domain. Any and all copyright 47 protection that might apply in any jurisdiction is expressly 48 disclaimed. 50 Comments 52 Comments should be directed to James R. Twine (jtwine@jrtwine.com). 54 Table of Contents 56 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 57 Table of Contents . . . . . . . . . . . . . . . . . . . . . 2 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Server Requirements . . . . . . . . . . . . . . . . . . . . 3 61 3.1 Command Format (MD5) . . . . . . . . . . . . . . . . . . . 4 62 3.1.1 MD5 Examples . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2 Command Format (MMD5) . . . . . . . . . . . . . . . . . . . 5 64 3.2.1 MMD5 Examples . . . . . . . . . . . . . . . . . . . . . . 5 65 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This Draft is being distributed to members of the Internet 71 community in order to solicit their reactions to the proposals 72 contained in it. 74 2. Rational 76 FTP is still very much in use on the Internet. These days, some 77 servers make available files that contain the checksums for some of 78 the files that are available. These available checksums allow 79 users to be able to verify the content of the files that they have 80 downloaded. 82 However, this introduces some additional overhead: these MD5 83 checksums must be manually generated, put into a file, the file 84 placed where it can be accessed. Then, users must manually 85 download the file containing the checksum, generate an MD5 checksum 86 from the file they just downloaded, and (usually) visually compare 87 the two checksums to determine the validity of the file. 89 Having these tasks automated, by making the MD5 checksums available 90 directly from the FTP Server proper, and having file-transfer 91 implementations use them, alleviates some of the user intervention 92 that would otherwise be required. 94 3. Server Requirements 96 FTP Servers would have to implement a new server-side command, 97 called "MD5", this command would normally generate and return a 98 MD5 for the specified file. 100 Optionally, the FTP Server could also implement the "MMD5" command, 101 which is used to obtain MD5 checksums for multiple files using a 102 single request. 104 (These commands impose no specific or additional syntax on the 105 formatting of a filepath, they use the Server's existing 106 conventions.) 108 The Server implementation is also free to use some form of 109 caching to keep the generated MD5 checksums, so that the MD5 110 checksum values do not have to be regenerated over and over again 111 when requested. 113 This also allows the Server implementations to maintain some level 114 of security: the Server can expose administrative commands that 115 regenerate the cache of MD5 checksums on command, thus allowing 116 for "known good" checksums to be kept, and would be insensitive to 117 things like the file becoming corrupted or otherwise tampered with 118 after the "known good" MD5 checksum was generated. 120 A Server implementation could even take that approach one step 121 further: by generating additional MD5 checksums "on the fly" and 122 comparing them to the "known good" values that were stored earlier, 123 the Server would now have the ability to detect file corruption 124 and/or tampering earlier than the user would normally discover. 126 The command would support a full or relative path, so that a 127 directory change would not be necessary in order to obtain the 128 MD5 checksum of a particular file. Of course, the command 129 should normally be restricted to the directory tree and/or files 130 that the connected user would normally have access to. 132 3.1 Command Format (MD5) 134 The "MD5" command is used to obtain a MD5 checksum for a single 135 file, and is specified as follows: 137 MD5 [Filepath] 139 Possible responses to this command would normally include: 141 251 [FilePath] E67DED2886048D308532042B777D53CF 142 500 Command Not Recognized 143 502 Command Not Implemented 144 504 Command Not Implemented for the Specified Argument 146 (Note that the returned MD5 checksum is in UPPERCASE.) 148 A successful response of "251" would contain the specified 149 filepath (verbatim) followed by a space (or some amount of 150 whitespace), and then followed by the MD5 checksum value in 151 ASCII format. 153 An error return of "500" would be for an obvious reason: the FTP 154 Server does not recognize the "MD5" command. 156 An error return of "502" would be appropriate if the FTP Server 157 regocnized the command, but did not support it, or the FTP Server 158 administrator disabled it. 160 An error return of "504" would be appropriate if the user requested 161 an MD5 checksum for a directory (for example). 163 3.1.1 MD5 Examples 165 This first example demonstrates a request for a MD5 checksum of a 166 single file ("C>" is Client input, and "S>" is Server response): 168 C> MD5 filename.ext 169 S> 251 filename.ext E67DED2886048D308532042B777D53CF 171 This second example demonstrates a request for a MD5 checksum of a 172 directory: 174 C> MD5 ".." 175 S> 504 Command Not Implemented for the Specified Argument 177 This third example demonstrates a request for a MD5 checksum of a 178 file using a relative path: 180 C> MD5 "../SomeDir/A File.txt" 181 S> 251 "../SomeDir/A File.txt" 604E67DED8D308B777D53CF532042288 183 3.2 Command Format (MMD5) 185 The "MMD5" command is used to obtain MD5 checksums for multiple 186 files by a single request. Filepaths are comma separated, and are 187 specified as follows (it is to be considered valid to specify a 188 single filepath with with MMD5 command): 190 MMD5 [Filepath1], [Filepath2] [...] 192 Possible responses to this command would normally include: 194 252 [FilePath1] E67DED2886048D308532042B777D53CF,[Filepath2] 195 308536048D20E67D77D53CFED28842B7 [...] 196 500 Command Not Recognized 197 502 Command Not Implemented 198 504 Command Not Implemented for the Specified Argument 200 A successful response of "252" would contain comma separated 201 "groups" of MD5 checksum information. Each group would contain the 202 specified filepath (verbatim) followed by a space (or some amount 203 of whitespace) followed by the MD5 checksum value in 204 ASCII format. 206 An error return of "500" would be the same as described for the "MD5" 207 command. 209 An error return of "502" would be appropriate if the "MMD5" command 210 was not implemented or disabled. 212 An error return of "504" would be the same as described form the "MD5" 213 command, with this exception: of any of the specified filepaths were 214 invalid, the server would return this error code (i.e. it would 215 no MD5 checksums at all). 217 3.2.1 MMD5 Examples 219 This first example demonstrates a request for a MD5 checksum of a 220 single file: 222 C> MMD5 filename.ext 223 S> 251 filename.ext E67DED2886048D308532042B777D53CF 224 This second example demonstrates a request for the MD5 checksums 225 for two files: 227 C> MMD5 filename.ext, "../SomeDir/A File.txt" 228 S> 252 filename.ext E67DED2886048D308532042B777D53CF, 229 "../SomeDir/A File.txt" 604E67DED8D308B777D53CF532042288 231 This third example demonstrates a request for the MD5 checksums of 232 a file and a directory: 234 C> MD5 filename.ext, ".." 235 S> 504 Command Not Implemented for the Specified Argument 237 4. References 239 [1] Postel, J., Reynolds J., "Instructions to RFC Authors", 240 RFC 2223, October 1997 242 [2] Postel, J., Reynolds J., "FILE TRANSFER PROTOCOL (FTP)", 243 RFC 959, October 1958 245 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 246 April 1992 248 [4] Various, "Guidelines to Authors of Internet-Drafts", 249 http://www.ietf.org/ietf/1id-guidelines.txt 251 4. Author's Address 253 James R. Twine 254 JRTwine Software, LLC 255 379 Shirley Hill Road 256 Goffstown, NH, 03045 257 (USA) 259 Phone: +1 603-644-1307 260 EMail: jtwine@jrtwine.com