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