CAT Working Group Russell Housley (SPYRUS) William A. Nace (NSA) Updates: RFC 959 Peter Yee (SPYRUS) Internet-Draft Expire in six months December 1999 FTP Authentication Using DSA Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Please send comments to yee@spyrus.com. Abstract This document defines a method to secure file transfers using the FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985) and RFC 2228 "FTP Security Extensions" (October 1997) [1]. This method will use the extensions proposed in the "FTP Security Extensions" along with a public/private digital signature. 1 Introduction The File Transfer Protocol (FTP) provides no protocol security except for a user authentication password which is transmitted in the clear. Housley, Nace & Yee [Page 1] INTERNET DRAFT December 3, 1999 In addition, the protocol does not protect the file transfer session beyond the original authentication phase. The Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) Working Group has specified security extensions to FTP. These extensions allow the protocol to use more flexible security schemes, and in particular allows for various levels of protection for the FTP command and data connections. This document describes a profile for the FTP Security Extensions by which these mechanisms may be provisioned using the DSA[2] and SHA-1[3] algorithms. The FTP Security Extensions do not attempt to provide for security when FTP is used in proxy mode. The profile proposed in this document does not remove this limitation. 2 FTP Security Extensions The IETF CAT Working Group has produced an Internet Draft that seeks to improve the security of FTP. This Internet Draft is likely to become a standards track RFC in 1997. It provides: * user authentication -- augmenting the normal password mechanism; * server authentication -- done in conjunction with user authentication or authenticates the server to an anonymous user; * session parameter negotiation -- in particular, encryption keys and attributes; * command connection protection -- integrity, confidentiality, or both; * data transfer protection -- same as for command connection protection. In order to support the above security services, the two FTP entities negotiate a mechanism. This process is open-ended and completes when both entities agree on an acceptable mechanism or when the initiating party (always the client) is unable to suggest an agreeable mechanism. Once the entities agree upon a mechanism, they may commence authentication and/or parameter negotiation. Authentication and parameter negotiation occur within an unbounded series of exchanges. At the completion of the exchanges, the entities will either be authenticated (unilateral or mutually), and may be ready to protect FTP commands and data. Following the exchanges, the entities negotiate the size of the Housley, Nace & Yee [Page 2] INTERNET DRAFT December 3, 1999 buffers they will use in protecting the commands and data that follow. This process is accomplished in two steps: the client offers a suggested buffer size and the server may either refuse it, counter it, or accept it. At this point, the entities may issue protected commands within the bounds of the parameters negotiated through the security exchanges. Protected commands are issued by applying the protection services required to the normal commands and Base64 encoding the results. The encoded results are sent as the data field within a MIC (integrity). Base64 is an encoding for mapping binary data onto a textual character set that is able to pass through 7-bit systems without loss. The server sends back responses in new result codes which allow the identical protections and Base64 encoding to be applied to the results. Protection of the data transfers can be specified via the PROT command which supports the same protections as those afforded the other FTP commands. PROT commands may be sent on a transfer-by-transfer basis; however, the session parameters, such as PBSZ, may not be changed without sending another AUTH command. Be aware that support for subsequent AUTH commands may not be permitted by all implementations. 3 Use of Digital Signature Algorithm (DSA) This paper a profile in which DSA may be used to achieve certain security services when used in conjunction with the FTP Security Extensions framework. As stated above, the reader should be familiar with the extensions in order to understand the protocol steps that follow. In the context of the FTP Security Extensions, we use DSA with SHA-1 for authentication and integrity. 3.1 DSA Profile FTP entities may use DSA to give either unilateral or mutual authentication as well as to provide integrity services for commands and data transfers. This specification follows the tokens and exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1 encoding of messages and tokens. 3.1.1 Unilateral Authentication with DSA A client may unilaterally authenticate its identity to a server. What follows are the protocol steps necessary to perform DSA authentication as specified in FIPS PUB 196 under the FTP Security Extensions framework. Where failure modes are encountered, the return codes follow those specified in the Extensions. They are not enumerated here as they are invariant among mechanisms. FIPS PUB 196 employs a set of exchanges which are transferred to provide Housley, Nace & Yee [Page 3] INTERNET DRAFT December 3, 1999 authentication. Each exchange employs various fields and tokens, some of which are optional. In addition, each token has several subfields that are optional. A conformant subset of the fields and subfields for use with FTP have been selected. Therefore, the exchanges below do not show the FIPS PUB 196 notation indicating optional fields, while only the mandatory subfields are allowed. The tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each token is named to indicate the direction in which it flows (i.e., TokenBA flows from Party B to Party A). In Figure 1, the client binds the last transmission (token identifier, certificate, and token) together as an ASN.1 SEQUENCE. The exchanges detailed below presume a knowledge of FIPS PUB 196 and the FTP Security Extensions. The client is Party A, while the server is Party B. The notation for concatenation is " || ". The pseudo- function Sequence is used to indicate that its parameters are to be joined as an ASN.1 SEQUENCE. Verification of signed data, and in particular certification path verification is implicitly assumed, but is not shown. --------------------------------------------------------------------- Client Server AUTH DSS-CLIENT-UNILATERAL --> <-- 334 ADAT=Base64(Sequence( TokenID || TokenBA)) ADAT Base64(Sequence(TokenID || CertA || TokenAB || absigValue)) --> <-- 234 --------------------------------------------------------------------- Figure 1 With this example, the client is now authenticated to the server. Additional functionality available to client and server includes the use of MIC protected commands and the ability to send signed data. The Sign function used in the figures below appends a nonce to the end of the parameter, and then computes a DSA with SHA-1 signature over the parameter followed by a nonce. The 40 octet signature value, as described in FIPS PUB 186, is composed of two 20 octet values, r followed by s. The nonce is comprised of a two octet command counter and the Ra value from TokenAB. Since both the client and server have the Ra value from TokenAB and both can calculate the command counter, the nonce is not transmitted. The command counter is initialized to the least significant two octets of the Ra value from TokenAB, and it is incremented each time the client issues a command. The Sign function output is composed of the 40 octet signature value followed by the parameter. An example follows: Housley, Nace & Yee [Page 4] INTERNET DRAFT December 3, 1999 --------------------------------------------------------------------- Client Server MIC Base64(Sign("PBSZ 65535")) --> <-- 200 PBSZ=32767 MIC Base64(Sign("USER yee")) --> <-- 331 MIC Base64(Sign("PASS fortezza")) --> <-- 230 MIC Base64(Sign("PROT S")) --> <-- 200 MIC Base64(Sign("STOR foo.bar")) --> <-- 150 --------------------------------------------------------------------- Figure 2 Data now flows from the client to the server as specified in the Extensions. Specifically, the file is broken up into blocks of data of less than the negotiated protection buffer size (32767 bytes in the example exchanges). Each protection buffer contains a safe token followed by file data. A common safe token structure is used for unilateral and mutual authentication. The safe token structure is described in section 3.1.3. 3.1.2 Mutual Authentication with DSA The PDU flow for mutual authentication is slightly more complex, as shown: --------------------------------------------------------------------- Client Server AUTH DSS-MUTUAL --> <-- 334 ADAT=Base64(Sequence( TokenID || TokenBA1)) ADAT Base64(Sequence(TokenID || CertA || TokenAB || absigValue)) --> <-- 235 ADAT=Base64(Sequence( TokenID || CertB || TokenBA2 || ba2sigValue)) --------------------------------------------------------------------- Figure 3 Data retrieval and other FTP operations can now be performed with signature protection. As before, the FTP entities negotiate a protection buffer size. Likewise, a two octet command counter combined with the Ra value from TokenAB is used as a nonce in the Housley, Nace & Yee [Page 5] INTERNET DRAFT December 3, 1999 Sign function. --------------------------------------------------------------------- Client Server MIC Base64(Sign("PBSZ 65535")) --> <-- 631 Base64(Sign ("200 PBSZ=32767")) MIC Base64(Sign("USER yee")) --> <-- 631 Base64(Sign("331")) MIC Base64(Sign("PASS fortezza")) --> <-- 631 Base64(Sign("230")) MIC Base64(Sign("PROT S")) --> <-- 631 Base64(Sign("200")) MIC Base64(Sign("RETR foo.bar")) --> --------------------------------------------------------------------- Figure 4 Data now flows from the client to the server as well as the server to the client as specified in the Extensions. Specifically, the file is broken up into blocks of data of less than the negotiated protection buffer size. Each protection buffer contains a safe token followed by file data. A common safe token structure is used for unilateral and mutual authentication. The safe token structure is described in section 3.1.3. 3.1.3 File Protection with DSA The next figure shows the structure of the safe token and file data. --------------------------------------------------------------------- Signature 40 octets Buffer Size 4 octets Nonce 8 octets File Count 2 octets Buffer Count 4 octets File Data Buffer Buffer Size --------------------------------------------------------------------- Figure 5 The safe token is comprised of the signature value, buffer size, nonce, file count, and buffer count. The signature covers the buffer size, nonce, file count, buffer count, and the file data buffer. Buffer size is the number of octets contained in file data buffer. This buffer size must be less than the negotiated PBSZ value, and the maximum buffer size is PBSZ minus 58. If the buffer size is not equal to PBSZ minus 58, then this buffer is the final buffer of the file. If the file ends on a full buffer boundary, a buffer with the Housley, Nace & Yee [Page 6] INTERNET DRAFT December 3, 1999 buffer size set to zero will be sent. The nonce is the least significant 64 bits of the Rb field of TokenBA1. File count is a sequence counter of protected files transferred, starting at zero. Buffer count is the number of protected buffers sent for this file, starting at zero. 4.0 Security Considerations This entire memo is about security mechanisms. For DSA to provide the authentication discussed, the implementation must protect the private key from disclosure. 5.0 Acknowledgements I would like to thank Todd Horting for insights gained during implementation of this specification. 6.0 References [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. RFC 2228, October, 1997 [2] - Digital Signature Standard (DSS). FIPS Pub 186. May 19, 1994. [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. [4] - Standard for Entity Authentication Using Public Key Cryptography. FIPS Pub 196. February 18, 1997. Housley, Nace & Yee [Page 7] INTERNET DRAFT December 3, 1999 7.0 Author's Address Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA Email: housley@spyrus.com DIRNSA Attn: X22 (W. Nace) 9800 Savage Road Fort Meade, MD 20755-6000 USA Email: WANace@missi.ncsc.mil Peter Yee SPYRUS 5303 Betsy Rose Drive Santa Clara, CA 95054 USA Email: yee@spyrus.com Housley, Nace & Yee [Page 8]