idnits 2.17.1 draft-ietf-cat-ftpdsaauth-01.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 (2024-04-25) 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) 2024 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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- 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 9566 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 302, 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: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 the work in progress document ''FTP Security Extensions'' [1]. This method will use the extensions 36 proposed in the ''FTP Security Extensions'' Draft document along with a 37 public/private digital signature. 39 1 Introduction 41 The File Transfer Protocol (FTP) provides no protocol security except 42 for a user authentication password which is transmitted in the clear. 43 In addition, the protocol does not protect the file transfer session 44 beyond the original authentication phase. 46 The Internet Engineering Task Force (IETF) Common Authentication 47 Technology (CAT) Working Group has specified security extensions to 48 FTP. These extensions allow the protocol to use more flexible 49 security schemes, and in particular allows for various levels of 50 protection for the FTP command and data connections. This document 51 describes a profile for the FTP Security Extensions by which these 52 mechanisms may be provisioned using the DSA[2] and SHA-1[3] 53 algorithms. The FTP Security Extensions do not attempt to provide 54 for security when FTP is used in proxy mode. The profile proposed in 55 this document does not remove this limitation. 57 2 FTP Security Extensions 59 The IETF CAT Working Group has produced an Internet Draft that seeks 60 to improve the security of FTP. This Internet Draft is likely to 61 become a standards track RFC in 1997. It provides: 63 * user authentication -- augmenting the normal password mechanism; 65 * server authentication -- done in conjunction with user 66 authentication or authenticates the server to an anonymous user; 68 * session parameter negotiation -- in particular, encryption keys 69 and attributes; 71 * command connection protection -- integrity, confidentiality, or 72 both; 74 * data transfer protection -- same as for command connection 75 protection. 77 In order to support the above security services, the two FTP entities 78 negotiate a mechanism. This process is open-ended and completes when 79 both entities agree on an acceptable mechanism or when the initiating 80 party (always the client) is unable to suggest an agreeable 81 mechanism. Once the entities agree upon a mechanism, they may 82 commence authentication and/or parameter negotiation. 84 Authentication and parameter negotiation occur within an unbounded 85 series of exchanges. At the completion of the exchanges, the 86 entities will either be authenticated (unilateral or mutually), and 87 may be ready to protect FTP commands and data. 89 Following the exchanges, the entities negotiate the size of the 90 buffers they will use in protecting the commands and data that 91 follow. This process is accomplished in two steps: the client offers 92 a suggested buffer size and the server may either refuse it, counter 93 it, or accept it. 95 At this point, the entities may issue protected commands within the 96 bounds of the parameters negotiated through the security exchanges. 97 Protected commands are issued by applying the protection services 98 required to the normal commands and Base64 encoding the results. The 99 encoded results are sent as the data field within a MIC (integrity). 100 Base64 is an encoding for mapping binary data onto a textual 101 character set that is able to pass through 7-bit systems without 102 loss. The server sends back responses in new result codes which 103 allow the identical protections and Base64 encoding to be applied to 104 the results. Protection of the data transfers can be specified via 105 the PROT command which supports the same protections as those 106 afforded the other FTP commands. PROT commands may be sent on a 107 transfer-by-transfer basis; however, the session parameters, such as 108 PBSZ, may not be changed without sending another AUTH command. Be 109 aware that support for subsequent AUTH commands may not be permitted 110 by all implementations. 112 3 Use of Digital Signature Algorithm (DSA) 114 This paper a profile in which DSA may be used to achieve certain 115 security services when used in conjunction with the FTP Security 116 Extensions framework. As stated above, the reader should be familiar 117 with the extensions in order to understand the protocol steps that 118 follow. In the context of the FTP Security Extensions, we use DSA 119 with SHA-1 for authentication and integrity. 121 3.1 DSA Profile 123 FTP entities may use DSA to give either unilateral or mutual 124 authentication as well as to provide integrity services for commands 125 and data transfers. This specification follows the tokens and 126 exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1 127 encoding of messages and tokens. 129 3.1.1 Unilateral Authentication with DSA 131 A client may unilaterally authenticate its identity to a server. 132 What follows are the protocol steps necessary to perform DSA 133 authentication as specified in FIPS PUB 196 under the FTP Security 134 Extensions framework. Where failure modes are encountered, the 135 return codes follow those specified in the Extensions. They are not 136 enumerated here as they are invariant among mechanisms. FIPS PUB 196 137 employs a set of exchanges which are transferred to provide 138 authentication. Each exchange employs various fields and tokens, 139 some of which are optional. In addition, each token has several 140 subfields that are optional. A conformant subset of the fields and 141 subfields for use with FTP have been selected. Therefore, the 142 exchanges below do not show the FIPS PUB 196 notation indicating 143 optional fields, while only the mandatory subfields are allowed. The 144 tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each 145 token is named to indicate the direction in which it flows (i.e., 146 TokenBA flows from Party B to Party A). In Figure 1, the client 147 binds the last transmission (token identifier, certificate, and 148 token) together as an ASN.1 sequence. 150 The exchanges detailed below presume a knowledge of FIPS PUB 196 and 151 the FTP Security Extensions. The client is Party A, while the server 152 is Party B. The notation for concatenation is " || ". The pseudo- 153 function Sequence is used to indicate that its parameters are to be 154 joined as an ASN.1 SEQUENCE. Verification of signed data, and in 155 particular certification path verification is implicitly assumed, but 156 is not shown. 158 --------------------------------------------------------------------- 159 Client Server 161 AUTH DSS-CLIENT-UNILATERAL --> 162 <-- 334 ADAT=Base64(Sequence( 163 TokenID || TokenBA)) 164 ADAT Base64(Sequence(TokenID || 165 CertA || TokenAB || 166 absigValue)) --> 167 <-- 234 168 --------------------------------------------------------------------- 169 Figure 1 171 With this example, the client is now authenticated to the server. 172 Additional functionality available to client and server includes the 173 use of MIC protected commands and the ability to send signed data. 174 The Sign function used in the figures below appends a nonce to the 175 end of the parameter, and then computes a DSA with SHA-1 signature 176 over the parameter followed by a nonce. The 40 octet signature 177 value, as described in FIPS PUB 186, is composed of two 20 octet 178 values, r followed by s. The nonce is comprised of a two octet 179 command counter and the Ra value from TokenAB. Since both the client 180 and server have the Ra value from TokenAB and both can calculate the 181 command counter, the nonce is not transmitted. The command counter 182 is initialized to the least significant two octets of the Ra value 183 from TokenAB, and it is incremented each time the client issues a 184 command. The Sign function output is composed of the 40 octet 185 signature value followed by the parameter. An example follows: 187 --------------------------------------------------------------------- 188 Client Server 190 MIC Base64(Sign("PBSZ 65535")) --> 191 <-- 200 PBSZ=32767 192 MIC Base64(Sign("USER yee")) --> 193 <-- 331 194 MIC Base64(Sign("PASS fortezza")) --> 195 <-- 230 196 MIC Base64(Sign("PROT S")) --> 197 <-- 200 198 MIC Base64(Sign("STOR foo.bar")) --> 199 <-- 150 200 --------------------------------------------------------------------- 201 Figure 2 203 Data now flows from the client to the server as specified in the 204 Extensions. Specifically, the file is broken up into blocks of data 205 of less than the negotiated protection buffer size (32767 bytes in 206 the example exchanges). Each protection buffer contains a safe token 207 followed by file data. A common safe token structure is used for 208 unilateral and mutual authentication. The safe token structure is 209 described in section 3.1.3. 211 3.1.2 Mutual Authentication with DSA 213 The PDU flow for mutual authentication is slightly more complex, as 214 shown: 216 --------------------------------------------------------------------- 217 Client Server 219 AUTH DSS-MUTUAL --> 220 <-- 334 ADAT=Base64(Sequence( 221 TokenID || TokenBA1)) 222 ADAT Base64(Sequence(TokenID || 223 CertA || TokenAB || 224 absigValue)) --> 225 <-- 235 ADAT=Base64(Sequence( 226 TokenID || CertB || 227 TokenBA2 || ba2sigValue)) 228 --------------------------------------------------------------------- 229 Figure 3 231 Data retrieval and other FTP operations can now be performed with 232 signature protection. As before, the FTP entities negotiate a 233 protection buffer size. Likewise, a two octet command counter 234 combined with the Ra value from TokenAB is used as a nonce in the 235 Sign function. 237 --------------------------------------------------------------------- 238 Client Server 240 MIC Base64(Sign("PBSZ 65535")) --> 241 <-- 631 Base64(Sign 242 ("200 PBSZ=32767")) 243 MIC Base64(Sign("USER yee")) --> 244 <-- 631 Base64(Sign("331")) 245 MIC Base64(Sign("PASS fortezza")) --> 246 <-- 631 Base64(Sign("230")) 247 MIC Base64(Sign("PROT S")) --> 248 <-- 631 Base64(Sign("200")) 249 MIC Base64(Sign("RETR foo.bar")) --> 250 --------------------------------------------------------------------- 251 Figure 4 253 Data now flows from the client to the server as well as the server to 254 the client as specified in the Extensions. Specifically, the file is 255 broken up into blocks of data of less than the negotiated protection 256 buffer size. Each protection buffer contains a safe token followed 257 by file data. A common safe token structure is used for unilateral 258 and mutual authentication. The safe token structure is described in 259 section 3.1.3. 261 3.1.3 File Protection with DSA 263 The next figure shows the structure of the safe token and file data. 265 --------------------------------------------------------------------- 266 Signature 40 octets 267 Buffer Size 4 octets 268 Nonce 8 octets 269 File Count 2 octets 270 Buffer Count 4 octets 271 File Data Buffer Buffer Size 272 --------------------------------------------------------------------- 273 Figure 5 275 The safe token is comprised of the signature value, buffer size, 276 nonce, file count, and buffer count. The signature covers the buffer 277 size, nonce, file count, buffer count, and the file data buffer. 278 Buffer size is the number of octets contained in file data buffer. 279 This buffer size must be less than the negotiated PBSZ value, and the 280 maximum buffer size is PBSZ minus 58. If the buffer size is not 281 equal to PBSZ minus 58, then this buffer is the final buffer of the 282 file. If the file ends on a full buffer boundary, a buffer with the 283 buffer size set to zero will be sent. The nonce is the least 284 significant 64 bits of the Rb field of TokenBA1. File count is a 285 sequence counter of protected files transferred, starting at zero. 286 Buffer count is the number of protected buffers sent for this file, 287 starting at zero. 289 4.0 Security Considerations 291 This entire memo is about security mechanisms. For DSA to provide 292 the authentication discussed, the implementation must protect the 293 private key from disclosure. 295 5.0 Acknowledgements 297 I would like to thank Todd Horting for insights gained during 298 implementation of this specification. 300 6.0 References 302 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 303 Internet-Draft , 304 November, 1996. 306 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 307 May 19, 1994. 309 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 311 [4] - Standard for Entity Authentication Using Public Key 312 Cryptography. FIPS Pub 196. February 18, 1997. 314 7.0 Author's Address 316 Russell Housley 317 SPYRUS 318 PO Box 1198 319 Herndon, VA 20172 320 USA 322 Phone: +1 703 435-7344 323 Email: housley@spyrus.com 325 DIRNSA 326 Attn: X22 (W. Nace) 327 9800 Savage Road 328 Fort Meade, MD 20755-6000 329 USA 331 Phone: +1 410 859-4464 332 Email: WANace@missi.ncsc.mil 334 Peter Yee 335 SPYRUS 336 2460 N. First Street 337 Suite 100 338 San Jose, CA 95131-1023 339 USA 341 Phone: +1 408 432-8180 342 Email: yee@spyrus.com