idnits 2.17.00 (12 Aug 2021) /tmp/idnits63154/draft-ietf-cat-ftpdsaauth-02.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 (February 1998) is 8861 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) -- 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 (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CAT Working Group Russell Housley (SPYRUS) 3 William A. Nace (NSA) 4 Updates: RFC 959 Peter Yee (SPYRUS) 5 Internet-Draft Expire in six months 6 February 1998 8 FTP Authentication Using DSA 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are Draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ''work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Distribution of this memo is unlimited. Please send comments to the 28 mailing list. 30 Abstract 32 This document defines a method to secure file transfers using the FTP 33 specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985) 34 and RFC 2228 "FTP Security Extensions" (October 1997) [1]. This 35 method will use the extensions proposed in the "FTP Security 36 Extensions" along with a 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 48 security schemes, and in particular allows for various levels of 49 protection 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] 52 algorithms. The FTP Security Extensions do not attempt to provide 53 for 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 -- done in conjunction with user 65 authentication or authenticates the server to an anonymous user; 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 80 mechanism. Once the entities agree upon a mechanism, they may 81 commence 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 85 entities will either be authenticated (unilateral or mutually), and 86 may 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 90 follow. This process is accomplished in two steps: the client offers 91 a 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 100 character set that is able to pass through 7-bit systems without 101 loss. The server sends back responses in new result codes which 102 allow the identical protections and Base64 encoding to be applied to 103 the results. Protection of the data transfers can be specified via 104 the PROT command which supports the same protections as those 105 afforded the other FTP commands. PROT commands may be sent on a 106 transfer-by-transfer basis; however, the session parameters, such as 107 PBSZ, may not be changed without sending another AUTH command. Be 108 aware that support for subsequent AUTH commands may not be permitted 109 by all implementations. 111 3 Use of Digital Signature Algorithm (DSA) 113 This paper a profile in which DSA may be used to achieve certain 114 security services when used in conjunction with the FTP Security 115 Extensions framework. As stated above, the reader should be familiar 116 with the extensions in order to understand the protocol steps that 117 follow. In the context of the FTP Security Extensions, we use DSA 118 with SHA-1 for authentication and integrity. 120 3.1 DSA Profile 122 FTP entities may use DSA to give either unilateral or mutual 123 authentication as well as to provide integrity services for commands 124 and data transfers. This specification follows the tokens and 125 exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1 126 encoding of messages and tokens. 128 3.1.1 Unilateral Authentication with DSA 130 A client may unilaterally authenticate its identity to a server. 131 What follows are the protocol steps necessary to perform DSA 132 authentication as specified in FIPS PUB 196 under the FTP Security 133 Extensions framework. Where failure modes are encountered, the 134 return codes follow those specified in the Extensions. They are not 135 enumerated here as they are invariant among mechanisms. FIPS PUB 196 136 employs a set of exchanges which are transferred to provide 137 authentication. Each exchange employs various fields and tokens, 138 some of which are optional. In addition, each token has several 139 subfields that are optional. A conformant subset of the fields and 140 subfields for use with FTP have been selected. Therefore, the 141 exchanges below do not show the FIPS PUB 196 notation indicating 142 optional fields, while only the mandatory subfields are allowed. The 143 tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each 144 token is named to indicate the direction in which it flows (i.e., 145 TokenBA flows from Party B to Party A). In Figure 1, the client 146 binds the last transmission (token identifier, certificate, and 147 token) together as an ASN.1 sequence. 149 The exchanges detailed below presume a knowledge of FIPS PUB 196 and 150 the FTP Security Extensions. The client is Party A, while the server 151 is Party B. The notation for concatenation is " || ". The pseudo- 152 function Sequence is used to indicate that its parameters are to be 153 joined as an ASN.1 SEQUENCE. Verification of signed data, and in 154 particular certification path verification is implicitly assumed, but 155 is not shown. 157 --------------------------------------------------------------------- 158 Client Server 160 AUTH DSS-CLIENT-UNILATERAL --> 161 <-- 334 ADAT=Base64(Sequence( 162 TokenID || TokenBA)) 163 ADAT Base64(Sequence(TokenID || 164 CertA || TokenAB || 165 absigValue)) --> 166 <-- 234 167 --------------------------------------------------------------------- 168 Figure 1 170 With this example, the client is now authenticated to the server. 171 Additional functionality available to client and server includes the 172 use of MIC protected commands and the ability to send signed data. 173 The Sign function used in the figures below appends a nonce to the 174 end of the parameter, and then computes a DSA with SHA-1 signature 175 over the parameter followed by a nonce. The 40 octet signature 176 value, as described in FIPS PUB 186, is composed of two 20 octet 177 values, r followed by s. The nonce is comprised of a two octet 178 command counter and the Ra value from TokenAB. Since both the client 179 and server have the Ra value from TokenAB and both can calculate the 180 command counter, the nonce is not transmitted. The command counter 181 is initialized to the least significant two octets of the Ra value 182 from TokenAB, and it is incremented each time the client issues a 183 command. The Sign function output is composed of the 40 octet 184 signature value followed by the parameter. An example follows: 186 --------------------------------------------------------------------- 187 Client Server 189 MIC Base64(Sign("PBSZ 65535")) --> 190 <-- 200 PBSZ=32767 191 MIC Base64(Sign("USER yee")) --> 192 <-- 331 193 MIC Base64(Sign("PASS fortezza")) --> 194 <-- 230 195 MIC Base64(Sign("PROT S")) --> 196 <-- 200 197 MIC Base64(Sign("STOR foo.bar")) --> 198 <-- 150 199 --------------------------------------------------------------------- 200 Figure 2 202 Data now flows from the client to the server as specified in the 203 Extensions. Specifically, the file is broken up into blocks of data 204 of less than the negotiated protection buffer size (32767 bytes in 205 the example exchanges). Each protection buffer contains a safe token 206 followed by file data. A common safe token structure is used for 207 unilateral and mutual authentication. The safe token structure is 208 described in section 3.1.3. 210 3.1.2 Mutual Authentication with DSA 212 The PDU flow for mutual authentication is slightly more complex, as 213 shown: 215 --------------------------------------------------------------------- 216 Client Server 218 AUTH DSS-MUTUAL --> 219 <-- 334 ADAT=Base64(Sequence( 220 TokenID || TokenBA1)) 221 ADAT Base64(Sequence(TokenID || 222 CertA || TokenAB || 223 absigValue)) --> 224 <-- 235 ADAT=Base64(Sequence( 225 TokenID || CertB || 226 TokenBA2 || ba2sigValue)) 227 --------------------------------------------------------------------- 228 Figure 3 230 Data retrieval and other FTP operations can now be performed with 231 signature protection. As before, the FTP entities negotiate a 232 protection buffer size. Likewise, a two octet command counter 233 combined with the Ra value from TokenAB is used as a nonce in the 234 Sign function. 236 --------------------------------------------------------------------- 237 Client Server 239 MIC Base64(Sign("PBSZ 65535")) --> 240 <-- 631 Base64(Sign 241 ("200 PBSZ=32767")) 242 MIC Base64(Sign("USER yee")) --> 243 <-- 631 Base64(Sign("331")) 244 MIC Base64(Sign("PASS fortezza")) --> 245 <-- 631 Base64(Sign("230")) 246 MIC Base64(Sign("PROT S")) --> 247 <-- 631 Base64(Sign("200")) 248 MIC Base64(Sign("RETR foo.bar")) --> 249 --------------------------------------------------------------------- 250 Figure 4 252 Data now flows from the client to the server as well as the server to 253 the client as specified in the Extensions. Specifically, the file is 254 broken up into blocks of data of less than the negotiated protection 255 buffer size. Each protection buffer contains a safe token followed 256 by file data. A common safe token structure is used for unilateral 257 and mutual authentication. The safe token structure is described in 258 section 3.1.3. 260 3.1.3 File Protection with DSA 262 The next figure shows the structure of the safe token and file data. 264 --------------------------------------------------------------------- 265 Signature 40 octets 266 Buffer Size 4 octets 267 Nonce 8 octets 268 File Count 2 octets 269 Buffer Count 4 octets 270 File Data Buffer Buffer Size 271 --------------------------------------------------------------------- 272 Figure 5 274 The safe token is comprised of the signature value, buffer size, 275 nonce, file count, and buffer count. The signature covers the buffer 276 size, nonce, file count, buffer count, and the file data buffer. 277 Buffer size is the number of octets contained in file data buffer. 278 This buffer size must be less than the negotiated PBSZ value, and the 279 maximum buffer size is PBSZ minus 58. If the buffer size is not 280 equal to PBSZ minus 58, then this buffer is the final buffer of the 281 file. If the file ends on a full buffer boundary, a buffer with the 282 buffer size set to zero will be sent. The nonce is the least 283 significant 64 bits of the Rb field of TokenBA1. File count is a 284 sequence counter of protected files transferred, starting at zero. 285 Buffer count is the number of protected buffers sent for this file, 286 starting at zero. 288 4.0 Security Considerations 290 This entire memo is about security mechanisms. For DSA to provide 291 the authentication discussed, the implementation must protect the 292 private key from disclosure. 294 5.0 Acknowledgements 296 I would like to thank Todd Horting for insights gained during 297 implementation of this specification. 299 6.0 References 301 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 302 RFC 2228, October, 1997 304 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 305 May 19, 1994. 307 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 309 [4] - Standard for Entity Authentication Using Public Key 310 Cryptography. FIPS Pub 196. February 18, 1997. 312 7.0 Author's Address 314 Russell Housley 315 SPYRUS 316 PO Box 1198 317 Herndon, VA 20172 318 USA 320 Phone: +1 703 435-7344 321 Email: housley@spyrus.com 323 DIRNSA 324 Attn: X22 (W. Nace) 325 9800 Savage Road 326 Fort Meade, MD 20755-6000 327 USA 329 Phone: +1 410 859-4464 330 Email: WANace@missi.ncsc.mil 332 Peter Yee 333 SPYRUS 334 2460 N. First Street 335 Suite 100 336 San Jose, CA 95131-1023 337 USA 339 Phone: +1 408 432-8180 340 Email: yee@spyrus.com