idnits 2.17.00 (12 Aug 2021) /tmp/idnits63901/draft-ietf-cat-ftpdsaauth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC959, but the abstract doesn't seem to directly say this. It does mention RFC959 though, so this could be OK. 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.) -- The document date (July 1997) is 9076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 299, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAT Working Group Russell Housley (SPYRUS) 2 William A. Nace (NSA) 3 Updates: RFC 959 Peter Yee (SPYRUS) 4 Internet-Draft Expire in six months 5 July 1997 7 FTP Authentication Using DSA 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are Draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ''work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Distribution of this memo is unlimited. Please send comments to the 27 mailing list. 29 Abstract 31 This document defines a method to secure file transfers using the FTP 32 specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985) 33 and the work in progress document "FTP Security Extensions" [1]. This method will use the extensions pro- 35 posed in the "FTP Security Extensions" Draft document along with a 36 public/private digital signature. 38 1 Introduction 40 The File Transfer Protocol (FTP) provides no protocol security except 41 for a user authentication password which is transmitted in the clear. 42 In addition, the protocol does not protect the file transfer session 43 beyond the original authentication phase. 45 The Internet Engineering Task Force (IETF) Common Authentication 46 Technology (CAT) Working Group has specified security extensions to 47 FTP. These extensions allow the protocol to use more flexible secu- 48 rity schemes, and in particular allows for various levels of protec- 49 tion for the FTP command and data connections. This document 50 describes a profile for the FTP Security Extensions by which these 51 mechanisms may be provisioned using the DSA[2] and SHA-1[3] algo- 52 rithms. The FTP Security Extensions do not attempt to provide for 53 security when FTP is used in proxy mode. The profile proposed in 54 this document does not remove this limitation. 56 2 FTP Security Extensions 58 The IETF CAT Working Group has produced an Internet Draft that seeks 59 to improve the security of FTP. This Internet Draft is likely to 60 become a standards track RFC in 1997. It provides: 62 * user authentication -- augmenting the normal password mechanism; 64 * server authentication -- normally done in conjunction with user 65 authentication; 67 * session parameter negotiation -- in particular, encryption keys 68 and attributes; 70 * command connection protection -- integrity, confidentiality, or 71 both; 73 * data transfer protection -- same as for command connection 74 protection. 76 In order to support the above security services, the two FTP entities 77 negotiate a mechanism. This process is open-ended and completes when 78 both entities agree on an acceptable mechanism or when the initiating 79 party (always the client) is unable to suggest an agreeable mecha- 80 nism. Once the entities agree upon a mechanism, they may commence 81 authentication and/or parameter negotiation. 83 Authentication and parameter negotiation occur within an unbounded 84 series of exchanges. At the completion of the exchanges, the enti- 85 ties will either be authenticated (unilateral or mutually), and may 86 be ready to protect FTP commands and data. 88 Following the exchanges, the entities negotiate the size of the 89 buffers they will use in protecting the commands and data that fol- 90 low. This process is accomplished in two steps: the client offers a 91 suggested buffer size and the server may either refuse it, counter 92 it, or accept it. 94 At this point, the entities may issue protected commands within the 95 bounds of the parameters negotiated through the security exchanges. 96 Protected commands are issued by applying the protection services 97 required to the normal commands and Base64 encoding the results. The 98 encoded results are sent as the data field within a MIC (integrity). 99 Base64 is an encoding for mapping binary data onto a textual charac- 100 ter set that is able to pass through 7-bit systems without loss. The 101 server sends back responses in new result codes which allow the iden- 102 tical protections and Base64 encoding to be applied to the results. 103 Protection of the data transfers can be specified via the PROT com- 104 mand which supports the same protections as those afforded the other 105 FTP commands. PROT commands may be sent on a transfer-by-transfer 106 basis, however, the session parameters may not be changed within a 107 session. 109 3 Use of Digital Signature Algorithm (DSA) 111 This paper a profile in which DSA may be used to achieve certain 112 security services when used in conjunction with the FTP Security 113 Extensions framework. As stated above, the reader should be familiar 114 with the extensions in order to understand the protocol steps that 115 follow. In the context of the FTP Security Extensions, we use DSA 116 with SHA-1 for authentication and integrity. 118 3.1 DSA Profile 120 FTP entities may use DSA to give either unilateral or mutual authen- 121 tication as well as to provide integrity services for commands and 122 data transfers. This specification follows the tokens and exchanges 123 defined in FIPS PUB 196[4], including Appendix A on ASN.1 encoding of 124 messages and tokens. 126 3.1.1 Unilateral Authentication with DSA 128 A client may unilaterally authenticate its identity to a server. 129 What follows are the protocol steps necessary to perform DSA authen- 130 tication as specified in FIPS PUB 196 under the FTP Security Exten- 131 sions framework. Where failure modes are encountered, the return 132 codes follow those specified in the Extensions. They are not enumer- 133 ated here as they are invariant among mechanisms. FIPS PUB 196 134 employs a set of exchanges which are transferred to provide authenti- 135 cation. Each exchange employs various fields and tokens, some of 136 which are optional. In addition, each token has several subfields 137 that are optional. A conformant subset of the fields and subfields 138 for use with FTP have been selected. Therefore, the exchanges below 139 do not show the FIPS PUB 196 notation indicating optional fields, 140 while only the mandatory subfields are allowed. The tokens are ASN.1 141 encoded per Appendix A of FIPS PUB 196, and each token is named to 142 indicate the direction in which it flows (i.e., TokenBA flows from 143 Party B to Party A). In Figure 1, the client binds the last trans- 144 mission (token identifier, certificate, and token) together as an 145 ASN.1 sequence. 147 The exchanges detailed below presume a knowledge of FIPS PUB 196 and 148 the FTP Security Extensions. The client is Party A, while the server 149 is Party B. The notation for concatenation is " || ". The pseudo- 150 function Sequence is used to indicate that its parameters are to be 151 joined as an ASN.1 SEQUENCE. Verification of signed data, and in 152 particular certification path verification is implicitly assumed, but 153 is not shown. 155 --------------------------------------------------------------------- 156 Client Server 158 AUTH DSS-CLIENT-UNILATERAL --> 159 <-- 334 ADAT=Base64(Sequence( 160 TokenID || TokenBA)) 161 ADAT Base64(Sequence(TokenID || 162 CertA || TokenAB || 163 absigValue)) --> 164 <-- 234 165 --------------------------------------------------------------------- 166 Figure 1 168 With this example, the client is now authenticated to the server. 169 Additional functionality available to client and server includes the 170 use of MIC protected commands and the ability to send signed data. 171 The Sign function used in the figures below appends a nonce to the 172 end of the parameter, and then computes a DSA with SHA-1 signature 173 over the parameter followed by a nonce. The 40 octet signature 174 value, as described in FIPS PUB 186, is composed of two 20 octet val- 175 ues, r followed by s. The nonce is comprised of a two octet command 176 counter and the Ra value from TokenAB. Since both the client and 177 server have the Ra value from TokenAB and both can calculate the com- 178 mand counter, the nonce is not transmitted. The command counter is 179 initialized to the least significant two octets of the Ra value from 180 TokenAB, and it is incremented each time the client issues a command. 181 The Sign function output is composed of the 40 octet signature value 182 followed by the parameter. An example follows: 184 --------------------------------------------------------------------- 185 Client Server 187 MIC Base64(Sign("PBSZ 65535")) --> 188 <-- 200 PBSZ=32767 189 MIC Base64(Sign("USER yee")) --> 190 <-- 331 191 MIC Base64(Sign("PASS fortezza")) --> 192 <-- 230 193 MIC Base64(Sign("PROT S")) --> 194 <-- 200 195 MIC Base64(Sign("STOR foo.bar")) --> 196 <-- 150 197 --------------------------------------------------------------------- 198 Figure 2 200 Data now flows from the client to the server as specified in the 201 Extensions. Specifically, the file is broken up into blocks of data 202 of less than the negotiated protection buffer size (32768 bytes in 203 the example exchanges). Each protection buffer contains a safe token 204 followed by file data. A common safe token structure is used for 205 unilateral and mutual authentication. The safe token structure is 206 described in section 3.1.3. 208 3.1.2 Mutual Authentication with DSA 210 The PDU flow for mutual authentication is slightly more complex, as 211 shown: 213 --------------------------------------------------------------------- 214 Client Server 216 AUTH DSS-MUTUAL --> 217 <-- 334 ADAT=Base64(Sequence( 218 TokenID || TokenBA1)) 219 ADAT Base64(Sequence(TokenID || 220 CertA || TokenAB || 221 absigValue)) --> 222 <-- 235 ADAT=Base64(Sequence( 223 TokenID || CertB || 224 TokenBA2 || ba2sigValue)) 225 --------------------------------------------------------------------- 226 Figure 3 228 Data retrieval and other FTP operations can now be performed with 229 signature protection. As before, the FTP entities negotiate a pro- 230 tection buffer size. Likewise, a two octet command counter combined 231 with the Ra value from TokenAB is used as a nonce in the Sign 232 function. 234 --------------------------------------------------------------------- 235 Client Server 237 MIC Base64(Sign("PBSZ 65535")) --> 238 <-- 631 Base64(Sign 239 ("200 PBSZ=32767")) 240 MIC Base64(Sign("USER yee")) --> 241 <-- 631 Base64(Sign("331")) 242 MIC Base64(Sign("PASS fortezza")) --> 243 <-- 631 Base64(Sign("230")) 244 MIC Base64(Sign("PROT S")) --> 245 <-- 631 Base64(Sign("200")) 246 MIC Base64(Sign("RETR foo.bar")) --> 247 --------------------------------------------------------------------- 248 Figure 4 250 Data now flows from the client to the server as well as the server to 251 the client as specified in the Extensions. Specifically, the file is 252 broken up into blocks of data of less than the negotiated protection 253 buffer size. Each protection buffer contains a safe token followed 254 by file data. A common safe token structure is used for unilateral 255 and mutual authentication. The safe token structure is described in 256 section 3.1.3. 258 3.1.3 File Protection with DSA 260 The next figure shows the structure of the safe token and file data. 262 --------------------------------------------------------------------- 263 Signature 40 octets 264 Buffer Size 4 octets 265 Nonce 8 octets 266 File Count 2 octets 267 Buffer Count 4 octets 268 File Data Buffer Buffer Size 269 --------------------------------------------------------------------- 270 Figure 5 272 The safe token is comprised of the signature value, buffer size, 273 nonce, file count, and buffer count. The signature covers the buffer 274 size, nonce, file count, buffer count, and the file data buffer. 275 Buffer size is the number of octets contained in file data buffer. 276 This buffer size must be less than the negotiated PBSZ value, and the 277 maximum buffer size is PBSZ minus 58. If the buffer size is not 278 equal to PBSZ minus 58, then this buffer is the final buffer of the 279 file. If the file ends on a full buffer boundary, a buffer with the 280 buffer size set to zero will be sent. The nonce is the least signif- 281 icant 64 bits of the Rb field of TokenBA1. File count is a sequence 282 counter of protected files transferred, starting at zero. Buffer 283 count is the number of protected buffers sent for this file, starting 284 at zero. 286 4.0 Security Considerations 288 This entire memo is about security mechanisms. For DSA to provide 289 the authentication discussed, the implementation must protect the 290 private key from disclosure. 292 5.0 Acknowledgements 294 I would like to thank Todd Horting for insights gained during imple- 295 mentation of this specification. 297 6.0 References 299 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 300 Internet-Draft , 301 November, 1996. 303 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 304 May 19, 1994. 306 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 308 [4] - Standard for Entity Authentication Using Public Key 309 Cryptography. FIPS Pub 196. February 18, 1997. 311 7.0 Author's Address 313 Russell Housley 314 SPYRUS 315 PO Box 1198 316 Herndon, VA 20172 317 USA 319 Phone: +1 703 435-7344 320 Email: housley@spyrus.com 322 DIRNSA 323 Attn: X22 (W. Nace) 324 9800 Savage Road 325 Fort Meade, MD 20755-6000 326 USA 328 Phone: +1 410 859-4464 329 Email: WANace@missi.ncsc.mil 331 Peter Yee 332 SPYRUS 333 2460 N. First Street 334 Suite 100 335 San Jose, CA 95131-1023 336 USA 338 Phone: +1 408 432-8180 339 Email: yee@spyrus.com